# Re: Grammatical Inconsistencies

Date: Fri, 23 Apr 2004 09:46:06 -0400

Message-ID: <c6b6ms$a2np6$1_at_ID-114862.news.uni-berlin.de>

I give you an exact definition from a noted, well-respected, definitive source that is used in many well-respected universities, and you argue with it. Elmasri and Navathe are not using the terms loosely. They are PhDs. They are precise to a fault. They are defining the terms. The terms are mutually exclusive. They mean different things. They have different meanings. They are not the same thing. JOIN means one thing, CARTESIAN PRODUCT means another. I don't know how else to put it.

"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
news:c69co3$jul$1_at_news.netins.net...

> I would agree that join conditions (e.g. restrictions on the rows) are

used

> to keep from having a full cartesian cross-product in the result set, but

*> otherwise I suspect they are using these terms loosely, which is fine if
**> they are not trying to be precise. Yes, a where clause or JOIN ON clause
*

is

> required to perform the restriction otherwise your cartesian cross-product

*> will have no restrictions. In other words, I think the statements below
**> might be helpful to give a beginner an idea of how this works, but surely
*

a

> cartesian cross-product and a join are not mutually exclusive operations.

*>
**> --dawn
**>
**> "Alan" <alan_at_erols.com> wrote in message
**> news:c699gc$8t3bd$1_at_ID-114862.news.uni-berlin.de...
**> > According to Elmasri & Navathe...
**> >
**> > In Relational Theory, the term JOIN implies a "join condition" that
**> prevents
**> > a Cartesian product. So, there are two terms used, JOIN and CARTESIAN
**> > PRODUCT. They are mutually exclusive. You might specify
**> >
**> > on dept_nbr
**> >
**> > or, you might, for some unknown reason specify
**> >
**> > employees CARTESIAN PRODUCT departments
**> >
**> > Of course, thge above would be expressed in relational algebra, which
**> can't
**> > be reproduced in text. But, you can see that I have specified two
**> completely
**> > different operation. Note that you can't specify
**> >
**> > employees JOIN departments
**> >
**> > as this is incorrect.
**> >
**> > Now, we understand in a certain way what we perceive to be really going
**> on,
**> > and that's where the confusion comes in. In SQL, we know that when you
**> > SELECT from > 1 table, all tuples are "joined" so that there is one new
**> > tuple for each possible combination- and the result is a Cartesian
**> product.
**> > But the "joining" is just our mental interpretation of what we imagine
*

to

*> be
*

> > happening. If you want to truly, relationally JOIN the two tables, you

*> need
**> > a WHERE clause to specify the JOIN criteria.
**> >
**> > "Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
**> > news:c697n2$fis$1_at_news.netins.net...
**> > > OK -- I thought all of these operations were on relations and
*

returning

> > > relations.

*> > >
**> > > Thanks for enlightening me EVEN THOUGH you said you would filter me
*

out.

> > > 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
**> > >
**> > > Timothy J. Bruce" <uniblab_at_hotmail.com> wrote in message
**> > > news:b4Vhc.1344$17.159553_at_news1.epix.net...
**> > > > [I'm going to hate myself in the morning for this...]
**> > > >
**> > > > The cartesian product of any number of sets defines a RELATION.
**> > > > The intersection, union, and symetric difference of any number of
*

sets

> > > > defines a SET.

*> > > >
**> > > > Patrick Suppes: ``Introduction to Logic'', Van Norstrand Company,
*

Inc

*> > > > (August 1968)
*

> > > > Ralph P. Grimaldi: ``Discrete and Combinatorial Mathematics'',

*> > > > Reading-Mass.: Addison-Wesley (1985)
**> > > > Larry J. Goldstein, David I. Schneider, Martha J. Siegel: ``Finite
**> > > > Mathematics And Its Applications'', Prentice-Hall, Inc (1995)
**> > > > Kolman, Bubsy, Ross: ``Discrete Mathematical Structures'',
**> Prentice-Hall
**> > > > (2000)
**> > > > Donald E. Knuth: ``The Art of Computer Programming: Volume 1:
**> > Fundamental
**> > > > Algorithms (third edition)'', Addison-Wesley (1997)
**> > > > Donald E. Knuth: ``The Art of Computer Programming: Volume 3:
*

Sorting

> > and

*> > > > Searching (second edition)'', Addison-Wesley (1998)
**> > > >
**> > > > But what would Knuth know since he isn't a ``relational guy'',
**> > > > Timothy J. Bruce
**> > > > uniblab_at_hotmail.com
**> > > > </RANT>
**> > > >
**> > > >
**> > >
**> > >
**> >
**> >
**>
**>
*

Received on Fri Apr 23 2004 - 15:46:06 CEST