Re: Can we solve this -- NFNF and non-1NF at Loggerheads

"Alan" <alan_at_erols.com> wrote in message news:36htmvF54uqs0U1_at_individual.net... <snip>
> Nothing has changed. 1NF means (and has always meant) that all values are
> atomic (simple, indivisible),

This would put you in a separate camp from Date (and Alfredo). Many relational theorists today have given up on the atomin/scalar concept. Any attempt to define these relates them to the domain for the type. As soon as you can have user-defined types, then you can have a list meet a definition of "atomic" for an attribute with lists as the domain. You should be able to find plenty of information on this at dbdebunk.com, for example.

> and any value must be a single value from the
> domain of that attribute (E.g., if the attribute is date_of_birth, then
> the
> value must be a date_of_birth, not a hire_date or last_name). It does not
> allow nested data.
> It does not allow multi-valued or composite attributes.

Are you not familiar with relation-valued attributes?

> It is very simple. It has been explained. Oracle, (and other RDBMSes)
> support NFNF, in that they have constructs for nested tables, varying
> arrays
> and other "relation within relation", or "collection" situations.

Yet many continue to believe and teach the old version of 1NF (from before the definition was changed to say that if you have a relation, then it must be in 1NF by definition). Even you seem to be retaining that old definition, which requires you to make 1NF an axiom since it cannot be derived from even such non-obvious statements as the relational information principle. If folks had not redefined the term, but rather spread the word that 1NF (as it was defined, in terms of scalar values) is now dead, the industry would likely move forward faster in this particular area. That would have been a significant blow to relational theory, however, so it was handled more quietly, hoping not to rock the boat (I'm guessing).

--dawn Received on Sat Feb 05 2005 - 15:36:28 CET