By The Dawn's Normal Light
Date: Thu, 21 Oct 2004 16:20:36 -0400
Message-ID: <J_OdnQb_GuO9h-XcRVn-2Q_at_comcast.com>
A little while ago, Dawn thanked me for my succinct phrasing of the 1NF definitions, and the issues around them.
This is an effort to make the phrasing either even more succinct, or at least clearer:
So here's the rephrasing I'm proposing:
Zero Normal Form:
A table represents a set if and only if there is a candidate key.
The columns that make up a candidate keys must have no missing (NULL) Values, and different rows must have distinct values for the candidate key columns, taken together.
So this is tantamount to saying that different rows must be distinct.
(Where NULL is not distinct from 23 or 'Laconic' or 9/11/2001)
First Normal form:
A Relation is in first normal form if and only if none of the domains of its
attributes permit compound or multivalued values.
(At least I think that's right).
Second Normal Form:
A Relation is in second normal form if it is in First normal form, and.... etc. etc.
I'm not even close to agreeing with Dawn, although I have come to terms with the fact that I'm never going to change her mind. (What Learned in college: never argue with the professor. You'll only hurt yourself) I just want the discussion, if and when it surfaces again, to have a minimal entanglement due to fuzzy terminology.
Also, note that Dawn's favorite data model, the Nelson-Pick model diverges from 1NF because 1NF forbids multivalued domain elements, not because 1NF forbids compound domain elements.
As to the difference between a list and a table, that is a fairly trivial difference. Performance may be different. Direct access may be different. And as Dawn says, "sometimes order matters, sometimes it doesn't" It might be nice to have some metadata that tells us whether order matters or not. At the very least, it might cut some list searches in half. Received on Thu Oct 21 2004 - 22:20:36 CEST