Re: 3vl 2vl and NULL

From: Jon Heggland <heggland_at_idi.ntnu.no>
Date: Thu, 22 Dec 2005 11:58:36 +0100
Message-ID: <MPG.1e14a534449f6fdf989760_at_news.ntnu.no>


In article <matjq1d2tt7utdnqkolibgajee78blnnfn_at_4ax.com>, hugo_at_pe_NO_rFact.in_SPAM_fo says...
> On Fri, 16 Dec 2005 17:17:08 +0100, Jon Heggland wrote:
>
> >Very well, but you don't address my point: You say that the DB doesn't
> >know which value to substitute; which implies that there *is* a value to
> >substitute.
>
> No, it implies that the DB engine *has* to substitute a value (because
> there's an expression waiting to be evaluated) and no value is found at
> the specified location.

Same thing, IMO. We pretend there's an unknown value here.

> >There is apparently no second Value1.
> >
> >I think these answers (or error messages) are better than "I don't
> >know".
>
> Agreed. You are leading me to believe that the _NAME_ for the third
> truth value is improperly chosen. A better name would be something like
> "CAN'T BE DETERMINED".
Do you also think a reference to a non-existing column should return "CAN'T BE DETERMINED"?
> This would not change anything in how the DB should handle the various
> cases. It's just a name change to clarify what this third truth value
> actually means.

I think SQL-99 actually got it right: As I interpret it, the truth values are TRUE and FALSE; and NULL is used for a boolean that in reality is either TRUE or FALSE, but we (the database) don't know which.

> I know. I am very aware of the fact that SQL is not relational. I just
> don't know what other term to use over here when I try to refer to the
> family of SQL-supporting databases (as opposed to other database
> families, e.g. Pick, hierarchical, network, ...)

The SQL model. SQL DBMSs (not databases, to be even more nitpicky:).

> >Well, in the RM, all the tuples in the same relation have to use the
> >same predicate for reading the fact. Your interpretation breaks this.
>
> My interpretation was based on common practice in SQL databases where
> any predicates are combined in one table.

Sure. Any time you perform a join, you combine predicates (using AND). The result has *one* predicate, though, not many.

> >> Name | Age
> >> -------------+-----
> >> Uncle Vernon | NULL
> >> Aunt Marge | 47
> >>
> >> means nothing more and nothing less than
> >> - I have a family member who is uniquely identified (in the UoD of my
> >> family database) by the name "Aunt Marge";
> >> - I have a family member who is uniquely identified (in the UoD of my
> >> family database) by the name "Uncle Vernon".
> >> - My family member Aunt Marge has an age of 47 years.
> >
> >Yes, I understand your point of view. But this means that the connection
> >between relations and predicate logic is weakened. For instance, what is
> >the meaning of your table above projected on Age? It seems you will have
> >a row that doesn't have a meaning at all.
>
> The meaning would be "There exists an age that is uniquely identified by
> the number of 47 years".

Not that row, the other one:

Age



NULL
What does that mean?

Besides, the RM interpretation of the "47" row is "There exists a family member with the age 47 years". This is important; your interpretation leads to problems with the closed world assumption.

-- 
Jon
Received on Thu Dec 22 2005 - 11:58:36 CET

Original text of this message