Re: Why bother with Logical data model?

"David Portas" <REMOVE_BEFORE_REPLYING_dportas_at_acm.org> wrote in message news:1155127722.826576.24760_at_i3g2000cwc.googlegroups.com...
> 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,

I agree with your response in principle. However, Brian is by no means the only person in this newsgroup to use the the terminology "logical/physical" to describe the distinction that I'll call "idealized/realized". I originally learned the terminology
before learning relational databases, and the logical model definition agrees with what you state here and in another response in this thread. I'll call this the "public/private" distinction, without disparaging your claim that the standard meanings of "logical/physical" covers the concept quite adequately.

There are a lot of other people who use the term "logical model" to mean something like "preliminary design". I'll admit to such usage myself, on occasion, even though I recognize you are technically correct.

"Denormalization" is an over used term. It covers at least three cases: departure from normalization because the designer was ignorant of some or all normal forms; departure from normalization as a deliberate design decision, in order to support certain other goals in spite of the update anomalies that are a consequence of the departure; and departure from normalization because the designer was following a different design discipline such as star schema. The consequences are the same, regardless of the motive. But the arguments for or against (more) complete normalization will be very different. Received on Thu Aug 10 2006 - 13:34:44 CEST