Re: what is union?

From: paul c <toledobythesea_at_oohay.ac>
Date: Wed, 16 Sep 2009 21:53:41 GMT
Message-ID: <F7dsm.44182$Db2.12044_at_edtnps83>


Here's a little more detail about why I think formal arguments about deciding 'inserts' skip a base or two. Take two single-attribute relations, C and S, predicate of C, say PC, is "c is a customer" and predicate of S, say PS is "s is a supplier". The facts that satisfy the predicate PC OR PS can be expressed relationally as C <OR> S.

Say c and s share the domain {n1,n2,n3}. If the value of C is {<c n1>} and S is {<s n2>}, the value of C <OR> S is:

c s
n1 n1
n1 n2
n1 n3
n2 n2
n3 n2

The facts/propositions, ie., the of C <OR> S can be read as: n1 is a customer OR n1 is a supplier
AND
n1 is a customer OR n2 is a supplier
AND
n1 is a customer OR n3 is a supplier
AND
n2 is a customer OR n2 is a supplier
AND
n3 is a customer OR n2 is a supplier.

Note that this reading concerns only propositions, attribute/free variable names have been eliminated.

Most dbms', invoking "union-compatibility", will not record the value <OR>, rather they implement a "UNION" operator that requires equal headings of its operands. This means they can't express C <OR> S. If the attributes 'c' and 's' are renamed to 'x', C UNION S would have the value:

x
n1
n2

The value of C UNION S with predicate "x is a customer OR x is a supplier". can be read as:
n1 is a customer OR n1 is a supplier
AND
n2 is a customer OR n2 is a supplier.

Again, note that this value involves only propositions, no attribute or free variable names.

It should be clear that the second relation's value is not at all the same as the first value. This seems simple as mud to me. In effect, the "UNION" relation value is a restriction (involving equality) of the "<OR>" relation value. This is why a dbms that implements "union-compatibility" doesn't produce the same value as logical OR, ie., it doesn't implement logical OR, eg., an operator akin to D&D <OR>. That's why I think arguments about indeterminate union inserts that invoke OR are bogus (and probably ignore the Information Principle to boot).

(Even If a dbms' implemented an unconstrained <OR> operator, I wouldn't buy the 'indeterminate/undecideable' argument, because the relation value produced with 'c' and 's' attributes would allow all possible combinations to be recorded!) Received on Wed Sep 16 2009 - 23:53:41 CEST

Original text of this message