Re: Grammatical Inconsistencies

From: Dawn M. Wolthuis <dwolt_at_tincat-group.com>
Date: Sun, 25 Apr 2004 10:34:52 -0500
Message-ID: <c6hb62$5rf$3_at_news.netins.net>


"Timothy J. Bruce" <uniblab_at_hotmail.com> wrote in message news:34519632.0404232048.5fc63c30_at_posting.google.com...
> et al:
>
> A special note is on order:
> If we were to state that relation F was _equal_to_ the cartesian
> product of sets A and B, rather than a _subset_of_ the cartesian
> product of sets A and B we would have the unintelligible relation:
> F = {
> (1, chicken),
> (1, cat),
> (1, dog),
> (1, cow),
> (2, chicken),
> (2, cat),
> (2, dog),
> (2, cow),
> (3, chicken),
> (3, cat),
> (3, dog),
> (3, cow),
> (4, chicken),
> (4, cat),
> (4, dog),
> (4, cow)
> }
>
> Obviously the complete _permutation_ is useless,

Yes, and my point is that is the reason for restrictions. If you take all restriction operations together without designating which are for the purpose of ensuring we don't get a non-sensical resultset as it relates to the join, then you can do the cross-product and then apply all restrictions and you would get the same result as if you apply the join (which, as I understand it now, is the cross-product with the associated row restrictions to get "good rows" against which you would then apply the other row restrictions.

It is fine if there is an unusable result in the midst of the process of evaluating a select statement -- in the end, the resultset you get by applying the restricted cross-product and the one I get from applying a cross-product and then the restrictions is the same.

While I'd prefer to have the operations of JOIN, RESTRICT, and PROJECT as distinct operations, if the norm in the industry is to overlap the terms JOIN & RESTRICT or to separate restrictions into two parts and put one set into JOIN and the other into RESTRICT (I'm still not sure which of those is the preferred way to define it), then I can adjust. Cheers! --dawn Received on Sun Apr 25 2004 - 17:34:52 CEST

Original text of this message