Re: Why bother with Logical data model?

David Cressey wrote:
> "Brian Selzer" <brian_at_selzer-software.com> wrote in message
> news:2tjCg.4506$o27.308_at_newssvr21.news.prodigy.com...
> > Why? Because it saves time--perhaps not initially, but definitely in the
> > long run. In most of the databases I've worked with there is a disparity
> > between the logical model and the physical model. The logical model
> should
> > at a minimum be in BCNF, but if possible, 5NF, but that is not always true
> > in the physical model. Sometimes tables must be split for valid business
> > reasons, such as security. Sometimes, though seldom, a denormalized table
> > performs better--at least for the particular application where it is most
> > used. The logical model should remain independent of such considerations,
> > so that you can focus on the structure of the data that is to be stored
>
> The above is a very, very good point. It deserves careful attention by most
> of the readers of this newsgroup.
>

I disagree. It is the logical / physical confusion at work again. Normalization applies only at the logical level (relations or tables) whereas Brian's reply assumes that tables (and therefore normalization) are also the building blocks of the physical model (implementation and storage).

In principle the logical model is supposed to be the level at which users and applications interract with the DBMS. In Brian's view however, the logical model presumably exists largely in a design document or in the designer's head. Obviously this confusion arises because SQL DBMSs commonly use the CREATE TABLE statement as the main method or even the only method to define the physical model as well as the logical one. The Table = Physical assumption is therefore a painful necessity for many SQL users. Readers of this newsgroup should not be misled about the real difference though.

Further to what Brian said. If the logical model has to be denormalized or otherwise compromised in the interests of making physical changes then you should consider applying sufficient constraints to maintain the integrity features of the original version.

-- 
David Portas