Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Usenet -> comp.databases.theory -> Re: Grammatical Inconsistencies

Re: Grammatical Inconsistencies

From: Jonathan Leffler <>
Date: Fri, 23 Apr 2004 04:27:18 GMT
Message-ID: <GW0ic.5860$>

Timothy J. Bruce wrote:

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

Are you talking math or relational database theory?

Depending on exactly which variant of the relational model of data you subscribe to, you might get different answers. And the SQL answer is definitely different again.

In the more austere or spartan versions of RM, then A JOIN B is a natural join of A and B over the common columns. The common columns must be identical in name and type, and any mismatches where the same name appears in both A and B but have different types is an error (unless, possibly, inheritance is involved and the type of one column is a TTM subtype of the other). The result consists of three groups of columns - those found in A only, those found in B only, and those in both A and B. Let's label them AA, BB, and AB respectively. Each tuple in the resulting relation consists of the AA and AB parts of a row from A combined with the BB and AB parts of a row from B, where the AB parts are the same. There's a bit more to it than that; if there are 3 rows in A and 6 rows in B which share the same values in the AB columns, then there are 18 rows in the result set, such that each of the candidate rows from A is combined with each of the candidate rows from B. If the AB set of columns is empty - there are no common columns (attributes, I suppose I should be saying) - then the result is equivalent to the cartesian product of the two tables. This is because the empty set of columns is a subset of the columns in both A and B, so each row in A matches each row in B over the common subset of columns.

Jonathan Leffler                   #include <disclaimer.h>
Guardian of DBD::Informix v2003.04 --
Received on Thu Apr 22 2004 - 23:27:18 CDT

Original text of this message