Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Usenet -> comp.databases.theory -> Re: Grammatical Inconsistencies
"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message news:c6hb62$5rf$3_at_news.netins.net...
> 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.
> 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
Historically JOIN was defined as a NATURAL JOIN that was similar to
binary relations composition "o".
Let A=A1xA2x...xAm, B=B1xB2x...xBn, C=C1xC2x...xCp.
Let R1 be a binary relation on domains A,B.
Let R2 be a binary relation on domains B,C.
R1 o R2 is a binary relation on domains A,C R1 JOIN R2 is a ternary relation on domains A,B,C.
Taking advantage of associativity and commutativity of cartesian product (by using explicit naming of domains) Codd defined his algebra on relations of any degree.
Restricting the algebra to unary relations, JOIN become INTERSECT.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=