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

"Dawn M. Wolthuis" <dwolt_at_tincat-group.comREMOVE> wrote in message news:cu0d51$efm$1_at_news.netins.net...
> NFNF, NF2, or NF^2 = Non-First-Normal-Form is how products such as IBM U2
> databases describe themselves
>
ftp://ftp.software.ibm.com/software/data/u2/pubs/whitepapers/nested_rdbms.pdf
>
> Some NF2 products are also called MultiValue or PICK(-like) and include:
> Revelation, jBASE, D3, UniData, UniVerse, UniVision, Reality, and open
> source projects Maverick and OpenQM.
> Other NF2 products stem from other parentage, with a similar feature of
not
> meeting what used to be the relational requirement called 1NF.
>
> The NF2 products I work with use a two-valued logic and a "null" value is
a
> value [it could be modeled as if it were a null set, for example, and null
> sets can surely be compared to other sets of values for equality] NULL is
> not the absence of value in this model. Additionally, all relations are
> functions -- they all have an explicitly-designated key. So, two parts of
> what Alfredo, David Cressey, Lauri, mAsterdam and others have told me are
> part of the def of 1NF are definitely in tact -- no (three-valued logic)
> null values and no duplicate rows.
>
> So, what IBM means by "NF2" is that the other part of 1NF is missing --
the
> data model includes what was once called "non-scalar" values. Unlike the
> new variations in relational theory that now permit relation-valued
> attributes, these non-scalar values are really a collection of a slightly
> different ilk as they are not necessarily relations in their own right (as
> their parents are). The order of the values in such attributes may be
> accessed by the "user" of the products, for example. So, the NF2 aspect
of
> the underlying model looks more like a relation where the domain of an
> attribute may be an indexed (logically) array (single or multidimensional,
> with the included tools having relatively low limits for these dimensions,
> 2-4).
>
> Now, with the redefinition of 1NF at the core of relational theory
> development, because these NF2 products work exclusively with functions, a
> subset of all relations, they are necessarily in 1NF -- according to the
NEW
> definitions. However, these databases define themselves as NF2.
>
> So, can you see the confusion this redefinition of what was once a
> fundamental concept in relational theory has prompted? Perhaps you can
feel
> my frustration in having a new definition of First Normal Form that causes
> all of these Non-First-Normal-Form databases to suddenly be in First
Normal
> Form!
>
> Now that the entire industry (almost) is ready to adopt what has been
called
> Non-First-Normal-Form in our data models, instead of announcing this
loudly,
> which might sound like a "win" for this almost invisible community of NF2
> practitioners, the relational theorists are quick to not conceed this
> point -- that would sound like a loss, but instead, rather quietly,
redefine
> their underlying terms and claim that what we were calling
> Non-First-Normal-Form is now in First Normal Form BY DEFINITION!
>
> [As aside for blatant advertising because I'm excited about it: We are
about
> to have a milestone in the NF2 community with elections now underway for
the
> first elected board of the International U2 User Group (working in
> conjunction with, but not as a branch of IBM's U2 group). www.u2ug.org ]
>
> So, please let's not confuse everyone by redefining 1NF and/or let's come
up
> with a one or two-word name that we, as an industry, can give to
> that-aspect-of-1NF to which products are referring when they say they are
> NF2 (or non-1NF). So, the old 1NF is dead as a theory, but is still very
> alive in practice, and redefining the term simply obscures the death of
> what-was-formerly-termed-1NF, thereby perpetuating the old practices.
>
> Thanks in advance for any advice you have for cleaning up this terminology
> issue. --dawn
>
>

Nothing has changed. 1NF means (and has always meant) that all values are atomic (simple, indivisible), 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. 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. Received on Fri Feb 04 2005 - 19:37:17 CET