Re: 3vl 2vl and NULL

On Fri, 16 Dec 2005 17:17:08 +0100, Jon Heggland wrote:

>In article <2jp3q1dtipgsm9vh54vvhocnin3vpp43eg_at_4ax.com>,
>hugo_at_pe_NO_rFact.in_SPAM_fo says...
(snip)
>> >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.
>>
>> I'll give you a table of values:
>
>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.

Hi Jon,

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.

>
>> Position | Value1 | Value2
>> ----------+--------+--------
>> first | 1 | 2
>> second | | 7
>> third | 3 |
>> fourth | 12 | 118
>>
>> What is the sum of the first and second Value1?
>
>There is apparently no second Value1.
>
>> If the third Value2 less than the third Value1?
>
>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.

(snip)
>> (Note: when I wrote "mapping to RM", I should have written "mapping to a
>> SQL-relational DB" or whatever the politically correct term for
>> not-truly-R-implementations-of-RM is).
>
>Please don't call this distinction political correctness. SQL is *not*
>relational; it allows and produces tables that are not relations by
>*any* definition.

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

And I sometimes forget to watch my tongue when writing here, since I spent the majority of my Usenet time in practical peer-to-peer groups, answering questions about how to do this or how to fix that. In those groups, trying to explain that SQL is not relational is the best way to guarantee that nobody understands me. :-)

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

(snip)
>> The transition from NIAM to SQL-Relational is just a change in
>> representation. No facts should be added or removed during this
>> transition. That's why the corresponding SQL-relational model:
>> 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". Most versions of NIAM require modelers to supply these patterns too. I omitted them from my explanation because I felt that it was irrelevant in the context.

Best, Hugo

-- 

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