Re: 3vl 2vl and NULL

Jon Heggland wrote:
> 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.

Why pretend? It is simply a fact!

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

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

To nitpick your use of terminology here is somewhat sloppy IMO. Domain values are not truth values! Just because the domain in question is the Boolean domain does not confer the ability to mix the conceptual aspects of domain values and truth tables. I wouldn't comment normally except your penchant for this strange distinction between a case where the domain implies a value "should exist" versus a situation where the attribute is not applicable to the tuple. eg. a relation of persons both male and female with a boolean attribute "has_a_beard" - Carnival sideshow bearded ladies excepted :-)

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

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

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

In that context it means we have at least one tuple in the source relation where the domain value is unknown for any number of possible reasons. Furthermore it means if that is a "bad thing" tm you should get off your bum and do something to rectify that state of affairs!

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

Que!

Seasonal Greetings Frank. Received on Fri Dec 23 2005 - 00:34:59 CET