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

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. Received on Thu Mar 23 2006 - 18:15:30 CET