Re: 3vl 2vl and NULL

From: Jon Heggland <heggland_at_idi.ntnu.no>
Date: Thu, 15 Dec 2005 10:18:00 +0100
Message-ID: <MPG.1e0b5332d42db4bf98974a_at_news.ntnu.no>


In article <g4a1q158gmk0vnklaogelgfcpgsnkb027q_at_4ax.com>, hugo_at_pe_NO_rFact.in_SPAM_fo says...
>
> I object to the choice of words "It is unknown", because in fact Uncle
> Vernon's age IS known. Not to you and me, but it is known to many
> others.

I'd rather say that the important thing is that Uncle Vernon *has* an age, even if nobody (including himself) knows it.

> >This sounds like an agreement on that "value is missing" is essentially
> >the same as "value is unknown". Or do you draw some separation between
> >"unknown in the database" and "unknown in the real world"?
>
> You've got it.
>
> In many of the discussions about NULL, people get distracted by the
> notion that NULL is suggested to mean "unknown".

I though that *was* the discussion. :)

> Then they find examples
> where there's other reasons to use NULL (inapplicable, e.g.), which
> leads to the discussion that there should be two, three, or whatever
> number of NULLs to denote the various reasons why data can be missing.

I thought it was commonly accepted that "inapplicable NULLs" are an artifact of wrong database design. Inapplicable data are *not* missing. Furthermore, to use SQL NULLs for "inapplicable" does not make sense with the current rules; that is my point. It should be an error to try to perform an operation on inapplicable data; it should not just result in another NULL or in an UNKNOWN truth value.

> To avoid that misunderstanding as much as possible, I always make the
> distinction between the MEANING of NULL ("no value is here") and the
> RESULT of NULL (that the DB doesn't know which value to substitute for a
> variable or column name in an expression).

If this is the RESULT (with capital letters) of NULL, then it seems obvious that it means "unknown", and not "inapplicable". If it could mean "inapplicable", there wouldn't *be* any value to substitute.

> >So the fact type for the one tuple is not the same as for the other.
> >
> >It seems, though, that you use "fact type" in a manner unfamiliar to me.
> >In the descriptions of the RM and predicate logic I have seen, "fact
> >type" is synonymous with "predicate", and each relation has one (and one
> >only, though different (equivalent) formulations are of course
> >possible). (Though of course, NULLs have no counterpart in predicate
> >logic that I'm aware of.)
>
> My background is NIAM, a Dutch version of ORM. That's probably why you
> are unfamiliar with my use of the term "fact type". You're right that
> the terms "fact type" and "predicate" are almost synonymous.
>
> In ORM/NIAM, each predicate has it's own "table". As a result, there are
> no NULLS in ORM/NIAM. For the example above, there simply would be no
> fact at all for Uncle Vernon in the fact table for a person's age.

I'd say that this is how the RM works too. In my opinion, ORM/NIAM is a graphical representation of the RM.

> When mapping ORM/NIAM to RM, a fixed set of rules dictates which fact
> types are combined. The resulting tables combine the data from the
> combined fact tables.

But you don't need to combine fact types. It's just as much RM (more, in fact, since you avoid NULLs:) if you don't. Do the rules ever produce NULLs that don't mean "unknown"?

> In the readings above, I assumed that the tuples (Aunt Marge, 47) and
> (Uncle Vernon, NULL) are the result of combining a unary fact type that
> enumerates the people in my family with a binary fact type that holds
> the age for members of my family.

Based on the reasonable assumption that all your family members have ages, I guess. And in that case, I think it is more correct to interpret the tuples as

---i.e. that tuples with NULLs have the same interpretation as when the NULLs are projected away.

-- 
Jon
Received on Thu Dec 15 2005 - 10:18:00 CET

Original text of this message