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

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 Received on Fri Feb 04 2005 - 18:58:55 CET