Re: Date, Darwen, Pascal and the alternative to Nulls in the RM

From: paul c <toledobythesea_at_oohay.ac>
Date: Thu, 23 Mar 2006 18:24:57 GMT
Message-ID: <ZJBUf.173242$sa3.62767_at_pd7tw1no>


falcon wrote:
> JOG wrote:
>

>>Paul Mansour wrote:
>>
>>>Assume one accepts, as I do,  the argument against nulls put forward by
>>>Date et al. Would it be fair to say that at this point in time they
>>>really don't have a solution to missing information?
>>>anything better.  Am I wrong here?
>>
>>[huge snip of interesting stuff]
>>
>>They propose a system that decomposes all relations down to irreducible
>>tuples (hence eradicating nulls). The horrendous joins and
>>consequential problems this might leave are handled by their closed
>>source "transrelational model (tm)" in a manner which currently eludes
>>my recall. As far as I know this system is yet to see the light of day.

>
>
> So their solution to the null problem is to convert n-ary relations to
> binary relations? If that is the case then that is what I was thinking
> in my previous message.
>
> As far as I know, transrelational has to do with how data is stored on
> disk, not how it is logically represented...no? If we ignore the
> problem of 'horrendous joins,' don't we still have the issue of nulls
> showing up when we 're-construct' a tuple with joins (as mentioned
> previously by another poster)?
>
> If a user enters data into an sql database in the following manner:
> (primkey(soc), name, age grade)
> [111-11-1111, jim, 21, A]
> [222-22-2222, joe, null, C] <==no age available for joe
> [333-33-3333, jack, 23, B]
>
> their logical meaning should be:
> [111-11-1111, jim]
> [111-11-1111, 21]
> [111-11-1111, A]
> [222-22-2222, joe]
> [222-22-2222, C]
> [333-33-3333, jack]
> [333-33-3333, 23]
> [333-33-3333, B]
> (notice missing entry [222-22-2222,null] <=joe has no age)
>
> now in a logically consistent system, a query for soc, name, grade
> should return the following:
> [111-11-1111, jim, A]
> [222-22-2222, joe, C]
> [333-33-3333, jack, B]
>
> but the query for soc, name, AGE, grade should return the following???:
> [111-11-1111, jim, 21, A]
> [333-33-3333, jack, 23, B]
> Notice the missing [222-22-2222, joe, null, C] entry since this tuple
> doesn't evaulate to TRUE (due to the null), it can not be part of any
> result set.
>
> The missing entry for 'joe' in the last query might be very difficult
> for someone coming from an sql background, working at a real company.
> I understand that logical models should not worry about 'real-world'
> matters. As far as I can see, this problem of missing joe can be
> mitigated by allowing something similar to outer joins when the
> result-set does indeed include a null, such as follows:
> [111-11-1111, jim, 21, A]
> [222-22-2222, joe, null, C]
> [333-33-3333, jack, 23, B]
>
> But then, this is not a relation. In other words, the previous three
> lines may appear on a user's computer screen, but they can no longer be
> part any further relational operations.
>

I think that is very well said, especially the last paragraph. A table with all four columns is reasonable, a relation with all four attributes is a myth. (Elsewhere, people sometimes ascribe notions of 'when-ness' to the four-attribute relation but I think this is a red herring. Such a relation doesn't exist if we don't know Joe's age.)

pc Received on Thu Mar 23 2006 - 19:24:57 CET

Original text of this message