I have just invented a new layer called the 'conceptalogical layer'.
It's meaningless obviously but sounds like just the sort of thing I
could build a software business on. It's a winner I tell you
</cynicism>
David Cressey wrote:
> "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 - 07:20:08 CDT
