Re: Normalization and DBMS

"x" <x-false_at_yahoo.com> wrote in message news:40a1e7a4$1_at_post.usenet.com...
> **** Post for FREE via your newsreader at post.usenet.com ****
>
>
> "Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
> news:c7rbtq$tle$1_at_news.netins.net...
> > "x" <x-false_at_yahoo.com> wrote in message
> news:40a0f206$1_at_post.usenet.com...
> > > **** Post for FREE via your newsreader at post.usenet.com ****
> > >
> > > Codd 1970 ACM paper:
> > > "A first-order predicate calculus suffices if the collection of
> relations
> > is
> > > in normal form."
> > > "Such a language would provide a YARDSTICK of linguistic power for all
> > other
> > > proposed data languages."
> > >
> > > Someone claimed in this group that normalization is not "good" .
> > > How powerful is the data language of an (existing) DBMS not based on
> > > "normalization" ?
> >
> > It is 1NF with which I disagree and all other normal forms are based on
> > this. 2nd and 3rd normal forms (for example) are semantic and related
to
> > "functional dependencies" and they make a lot of sense for designing for
> > minimizing the costs of the database over time as requirements change.
> 1NF
> > is not based on semantics, but on a "guess" that making our mathematics
> > simplest wrt to the language of the propositions/predicates would make
the
> > most sense. That is the only logic I can find behind 1NF and I have
found
> > absolutely NO and I mean NO emperical data to suggest that putting data
> into
> > 1NF helps minimize the cost of the system for the long haul. In fact,
the
> > anecdotal evidence that I have seen (which could very well be skewed as
I
> > have done no scientific survey) is heavily skewed toward databases that
> are
> > not in 1NF.
> >
> > If you use Date's terminology, you need GROUP and UNGROUP operators in
> your
> > language. This could also be NEST and UNNEST. The language used with
> PICK,
> > for example, reads easier than SQL and includes such language as "WITH
> > EVERY" so you get
> >
> > LIST STUDENTS WITH EVERY MAJOR <> "MATH"
> >
> > Did that answer the question? --dawn
>
> No. PICK is an inferential or a non-inferential DBMS ?

Not inferential. In fact, when I first saw it, I declared that it was not a DBMS either! (a matter of definition, of course). [I'm not an old-time pickie -- I worked with "real DBMS's" first]

> If it is an inferential DBMS, what logic does it use ?
> How this logic compare to first order logic in a RDBMS (in terms of
> linguistic power, not performance)
>
> If it is not an inferential DBMS, how it manages to enforce data integrity
?

I suspect that some of the reason why it is easier to change over time is that developers have "enough rope to hang themselves" and, therefore, enough rope to alter the system as needed over time. Having watched construction workers build houses, I'm really glad that they have blue prints and equally pleased that they have flexibility to make changes when needed. The blueprint is not physically locked in. --dawn Received on Wed May 12 2004 - 16:31:19 CEST