Re: MV Keys

On Wed, 1 Mar 2006 12:05:28 +0100, Jon Heggland <heggland_at_idi.ntnu.no> wrote:

> I have searched about a dozen textbooks on
>data modelling for 1NF definitions, and there are basically three camps:
>
>1. "1NF means only atomic attributes." This of course begs the question:
>What does "atomic" mean, and why are strings and dates considered
>atomic? I have seen only one book with this definition that actually
>makes a point of this crucial question---and it has no good answer.
>
>2. "1NF means no repeating groups of columns." I.e. no tables like this:
>Order(OrderID, CustomerID, Item1, Amount1, Item2, Amount2, Item3,
>Amount3, Item4, Amount4). The possible anomalies here are apparent, but
>the definition is still informal: It depends on the requirements of the
>database. If an order always has exactly four items, the design above is
>not that bad. And what about FootballMatch(MatchID, ..., Team1, Team2)?
>This definition also has the unfortunate property that a relvar can be
>in 5NF, but not in 1NF.
>
>3. "1NF is subsumed in the definition of a relation." Date's position,
>which means it is really pointless to talk about 1NF in any case. If a
>"relation" is not in 1NF, it isn't a relation, and normalisation doesn't
>apply.

Good stuff, Jon. What bothers me most is that there is no apparent formal distinction between this:

OrderID|CustomerID|Item1 |Item2 |Item3 | Item4 (...)

      1|foo_123   |     apples|     pears|  bananas| oranges
      2|bar_123   |      pears|   bananas|  oranges|
      3|bar_123   |    bananas|          |         |

etc., and this:

OrderID|CustomerID|Items

      1|foo_123   | apples;pears;bananas;oranges
      2|bar_123   | pears;bananas;oranges
      3|bar_123   | bananas

Conceptually speaking, I think that most would agree that neither example is in 1NF, whereas technically speaking, either the first or the second example would be, depending on which textbooks you read, but certainly not both.

--
Bob Hairgrove
NoSpamPlease_at_Home.com