Re: 3vl 2vl and NULL

On Mon, 12 Dec 2005 13:06:18 +0100, Jon Heggland wrote:

>In article <aaepp1l4g1h3ud0imb120471k08g9rdaf0_at_4ax.com>,
>hugo_at_pe_NO_rFact.in_SPAM_fo says...
>> On Fri, 9 Dec 2005 23:34:03 +0100, Jon Heggland wrote:
>>
>> > but nobody knows what it is. It is unknown.
>>
>> I would hasard a guess that at least Uncle Vernon knows his age. His
>> parents, his wife and his children too.
>
>Relevance?

Hi Jon,

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.

If you think I'm nitpicking, read on.

>
>> But *within the context of the database*, Uncle Vernon's age is indeed
>> unknown. That's the result of the value for the proposition "Age of
>> <person> is <age> years" being missing in the database.
>
>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". 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. Read the "what's null if it's not nothing" thread for an excellent example of this Babylonian confusion of tongues (is this expression valid in English?)

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).

>
>> >> "The age of Aunt Marge is 47 years" is a fact.
>> >> "The age of Uncle Vernon is unknown" is also a fact - but it's not the
>> >> same fact type as the former.
>> >
>> >Then what is the interpretation of the tuple (Uncle Vernon, NULL), given
>> >your interpretation of (Aunt Marge, 47)?
>>
>> For (Aunt Marge, 47), my interpretation would be:
>>
>> - I have a family member who is uniquely identified (in the UoD of my
>> family database) by the name "Aunt Marge";
>> - My family member Aunt Marge has an age of 47 years.
>>
>> For (Uncle Vernon, NULL), my interpretation would be:
>>
>> - I have a family member who is uniquely identified (in the UoD of my
>> family database) by the name "Uncle Vernon".
>
>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.

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.

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. In Aunt Marge's case, there was a fact in both of the combined fact tables; Uncle Vernon was missing from the second.

(snip remainder)

Best, Hugo

-- 

(Remove _NO_ and _SPAM_ to get my e-mail address)