# Re: Grammatical Inconsistencies

Date: Fri, 23 Apr 2004 14:32:18 -0500

Message-ID: <c6br0j$rak$1_at_news.netins.net>

"Timothy J. Bruce" <uniblab_at_hotmail.com> wrote in message
news:34519632.0404230942.c6067d8_at_posting.google.com...

> [...It's morning all right]

*>
**> > Are you willing to bother showing me an example of the use of a join
*

within

> > the relational theory framework where it is not the same as the

*> > cross-product -- or pointing me to some such example? I suppose I'm
*

pushing

*> > my luck, eh?
**> > --dawn
**> Let us have the sets A, B, and C, where A = {1, 2, 3, 4} and B =
**> {chicken, cat, dog, cow}.
*

> Let relation F be a subset of the cartesian product of sets A and B,

*> that is F is a subset of A x B, such as {(1, chicken), (2, cat), (3,
**> dog), (4, cow)}.
**> Let relation G be a subset of the cartesian product of C and no other
**> sets, such that C = {(1), (4)}.
**> If relation F was the predicate `Animals I own', and relation G was
**> the unary predicate `Animals of which I own I like to eat', the notion
**> of `I like to eat 1' does not make any sense. If we define G.C as a
**> subset of F.A (that is a fairly good definition of FOREIGN KEY, btw),
**> we are on the right track, but still not finished. We would like the
**> phrase `I like to eat chicken' in place of `I like to eat 1'.
**> The most obvious solution is to perform a join of some sort against
**> relations F and G, and by doing so we are concerned with the
**> _INTERSECTION_ between sets A and C (specifically sets F.A and G.C),
**> and then performing a projection of relation F.
**> This is no doubt the source of confusion in the matter. We join
**> relations by performing an intersection, union, or symetric difference
**> on attributes (read: sets) of those relations and performing a
**> projection on the relations in question.
**>
**> I have, on occasion, suggested to someone `Intersect relations A and B
**> via relation C' (which may have amplified this obviously confusing
**> matter), in an informal instruction of how to solve for many-to-many
**> relationships between relations A and B. It is not the relations
**> themselves, per sé, which are being intersected, but the sets
**> (specifically the keys) which are in consideration.
*

<snip>

Thanks for your civil and actually helpful response, Mr. Bruce!.

If we take your example above, when I have taught SQL (scary thought, eh?) I have taught how to get your result set by applying JOIN, RESTRICT, and PROJECT functions for a simple select statement on two tables like this:

**PROJECT(RESTRICT(JOIN(G,F)))
**
(Using f(x) notation for functions)

where ALL restrictions were in the RESTRICT function.

It sounds like others would divide out the restrictions related to the join (those that might go in an ON clause if there were one) and those that are not and the JOIN would be a combination of the cross product with the restrictions applied. So, eliminating the JOIN function for now, if we have CROSS, JOINRESTRICT (the restrictions related to the join), OTHERRESTRICT (those that are not) and PROJECT and we want to determine the result set we could do

**PROJECT(OTHERRESTRICT(JOINRESTRICT(CROSS(G,F)))
**
My apparently flawed understanding of the terms was that the JOIN function
equated to the CROSS function in the above (so that it didn't overlap with
the RESTRICT function) and I think you all are telling me that JOIN is a
function that, when applied, results in the same thing as the join
restrictions applied with the cross product function (in one swoop).

So, others might perform:

**PROJECT(OTHERRESTRICT(JOIN(G,F))
**
Did that make sense? If not, I'll study more and try to align my
terminology with "the majority" where feasible. Thanks. --dawn
Received on Fri Apr 23 2004 - 21:32:18 CEST