Re: Does Codd's view of a relational database differ from that of Date & Darwin? [M.Gittens]

Ged Byrne wrote:
> Date does recognise the problem of missing information, which NULLs
> attempt to address, RM Very Strong Suggestion number 8 states:
> "D should provide some kind of special values mechanism for
> dealing with "missing information."
>
> This is the candidate method for dealing with missing information.
>
> Special Values could be considered a superset of the use of NULL. For
> example, a special value NULL could be defined and given the same
> behaviour as the existing null.

I think the difference is that NULL is supposed to be a DBMS-wide thing, whereas Date & Darwen's "missing information" suggestion described in "Foundations for Future Database Systems" is explicitly a per-type thing.

Here's a thought though:

Suppose I have a column "col" of a integer type that has an UNKNOWN special value using Date & Darwen's scheme.

Then I do "SELECT COUNT(*) FROM rel WHERE col != 2"

Now the DBMS will have to understand the semantics of this UNKNOWN special value to return a result. Should it return a count ignoring any rows that have an UNKNOWN value in that column? I would argue it shouldn't, but should return some kind of "unknown" result instead. But what type does it use for the answer? The COUNT aggregate function presupposes there exists an integer domain (specifially, a non-negative integer domain). Maybe here is a case where a DBMS-wide "unknown" marker is necessary?

What about "SELECT SUM(col1) FROM rel where col2 != 5" ?

If the column col2 (of type type2) can contain special values like unknown, then also the type (type1) of column col1 would need a "unknown" special value, *even if it was never used directly as an attribute*.

Does this show that DBMS-wide NULLs or their equivalents are an inevitable consequence of allowing type-specific unknown values?

Or just that every type must have an "unknown" special value with identical semantics to each other (but possibly different representations?)

Paul. Received on Thu Jun 09 2005 - 13:36:59 CEST