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

"falcon" <shahbazc_at_gmail.com> wrote in message news:1143134130.259128.181350_at_g10g2000cwb.googlegroups.com...
>
> 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.
>

I'm with you up to this point. Notice that the tuple you flag as missing is missing because you preformed an INNER join. See below.

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

Yes. Coming from and SQL background, my reaction would be "what the hell did they do with the outer join?" Once they provide an outer join (to satisfy information requirements), it will give you the answer you outlined above, null and all.

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

Too bad. This is one of the differences between relational algebra and the relational data model. The model was closely based on the algebra, with due attention to detail. But the relational data model is a DATA model, and not a mathematical model. Received on Thu Mar 23 2006 - 19:51:18 CET