Re: Proposal: 6NF

David Cressey wrote:
> "paul c" <toledobythesea_at_oohay.ac> wrote in message
> news:tFBVg.100563$1T2.19259_at_pd7urf2no...
>

>>Hugo Kornelis wrote:
>>
>>>On Fri, 06 Oct 2006 08:32:36 GMT, Brian Selzer wrote:
>>>
>>>
>>>>"JOG" <jog_at_cs.nott.ac.uk> wrote in message
>>>>news:1159970386.339044.87090_at_i42g2000cwa.googlegroups.com...
>>>>
>>>>>Brian Selzer wrote:
>>>>>
>>>>>>"JOG" <jog_at_cs.nott.ac.uk> wrote in message
>>>>>>news:1159954091.119164.155490_at_m73g2000cwd.googlegroups.com...
>>>>>>
>>>>>>>All of your points represent a wild goose chase in my eyes Brian. A
>>>>>>>proposition with a NULL in it is no proposition at all. From a

>>>>>>>perspective, case closed. A relation tuple with a NULL in it is no
>>>>>>>relation tuple at all. From a mathematical perspective, case closed.
>>>>>>>Trying to invoke the 'kludge perspective' is hardly going to

>>>>>>>theoretical newsgroup.
>>>>>>>
>>>>>>
>>>>>>Is the empty set a value?  Yes, it is.  So why can't a null be?
>>>>>
>>>>>Because an empty set is a value and a NULL is not.
>>>>>
>>>>
>>>>Why not?
>>>
>>>Hi Brian,
>>>
>>>Because relational databases supporting NULL *define* it as a marker
>>>denoting the absence of a value. Dawn actually makes a good point about
>>>context: in C for instance, NULL has a completely different meaning.
>>>...

There's a bit of a wrinkle here: NULL -- as found in those non-relational databases which claim to be relational -- is a marker that denotes several things, only one of which is absence of a value. It is because those NULLs have no clear genesis that one can't make sense of anything holding a NULL. We can say, "There's a NULL here because ___ or because ___ or because ___ ..." In other words, it's impossible to know what any given NULL means. Consequently, it's impossible to construct declarative, conjunctive-only, quantifiable statements using some thing that holds one of those NULLs.

Yes, Codd did make some proposals regarding NULLs. His RM/V2 also described TJOINs. At some point, in some circles, there was an idea that RESTRICT and SELECT were different operations. All of these ideas have been investigated -- and discarded. Lately, COMPOSE and TCLOSE have been incorporated into relational theory.

The point? The theory has been explored and refined for more than 30 years. Not everything ever written was correct and NULLs are a good example of a mistake.

>>
>>Since it has a different meaning in C, there is no point bringing C into
>>play here.
>>

Actually, I wish that C had called the magic value NIL. I suspect that it was familiarity with the ASCII NUL - which happens to represent the same value as C's NULL - that lead to the on-going confusion. But point that there is no point bringing C into the discussion is correct.

>
> I disagree.
>
> Advancing the state of database theory involves (among many other things)
> looking at parts of existing theory (including the supposed theory behind
> existing implementations) and finding improvements.
>
> The theorists in this newsgroup have demonstrated, repeatedly, that the
> problems that SQL NULL solves can be obviated by appropriate table
> decomposition. They have also demonstrated that fully normalized relvars do
> not need to support NULLS.

Decomposition and normalization are not the only methods one can use to develop a normal design. In fact, a "normalized" design probably started out as a non-normalized design. (Not a de-normalized design, which is a very different thing! In other words, normalization is not the only path to a sufficiently normal design.) I, for one, prefer another path.

> Even though I take issue with such theorists, the fact is that their answer
> *does* fall under the rule of "a systematic treatment of missing data".
> "Always obviate the need for nullable columns" *is* a systematic treatment
> of the problem.
>
> My issue with that is not that it's a theoretically incorrect solution, but
> that it's often a lousy solution in practical terms. There are many in this
> news group who emphatically assert that, when theory and practice give
> divergent guidance concerning design, that practice must always yield to
> theory. That's the surest recipe for stagnation in the art of design.

If one wishes to denote a magic values in a type system which mean "ain't none" or "don't know" or "maybe," that's fine with most of the theory crowd. All they demand is that one appearance of "ain't none" can be compared to another in order to determine whether or not they're the same value. An equality comparison operator is necessary if the system is to assemble and operate on sets of values. That's all the theorists want; if you want a number named blue: fine.

> I have very little use for such a stance. I have even less use for the
> opposing stance, namely that when theory and practice diverge, theory
> should always yield to practice.
>
> So what does all this have to do with C? Well, it's possible that C has
> come up with a systematic way of dealing with missing data that is neither
> as unfortunate as SQL's way, nor as convoluted as the way of current
> relational theorists. And that's why it's possibly relevant to the
> discussion.

Actually, no: C's NULL is nothing more than a zero value which marks the end of a string of characters or, by convention, the end of a list of pointers or an uninitialized pointer or a field of reset bits. (There was some use of an empty string called NULL, but that was a horrible mistake.)

In fact, other than use as an end-of-string marker, I suspect that most uses of NULL are just C-programmer conventions rather than a language feature. It certainly isn't anything as sophisticated as a systematic way of dealing with missing data. Received on Wed Oct 11 2006 - 04:59:26 CEST