# Re: what is union?

Date: Tue, 15 Sep 2009 02:14:22 GMT

Message-ID: <2MCrm.45042$PH1.13390_at_edtnps82>

That last post was a bit of a short circuit, sorry for that, I got carried away trying to keep it short Let me go at it slightly differently and sorry this is so long, .

Take two single-attribute relations, C and S, predicate of C is "c is a
customer" and predicate of S is "s is a supplier". In theory we could

*"insert" to C <OR> S because its heading allows all possible *

combinations of c and s values.

In practice, because machine recordings are finite, we don't use unrestricted <OR>, rather the restricted/"union compatible" UNION operator. In practice, just to express the union, let alone insert to it, we need to do some "renaming", eg., change the headings of C and S to {x} and the predicates to "x is a customer" and "x is a supplier". No logical change by doing that as long as all other expressions reflect the change.

We could join the original, un-renamed C and S with the expression C <AND> S. All original tuples of C are in a projection {c} of that join, likewise for S and {s} and the two projections have no tuples that aren't in C and S respectively, so there are two projections that are equal to C and S respectively.

If we rename the single attributes c and s of the two projections to x and take their union, I think we have the predicate "x is a customer OR x is a supplier".

Call the renamed-projections CR and SR. So their union is CR UNION SR with attribute x.

If we want to assert a matching proposition, say assuming an integer domain for x, that proposition might be "1 is a customer OR 1 is a supplier", the usual argument is that there are three ways to assert that fact. If CR UNION SR were a base relvar, we could certainly insert that fact. Since we can't record infinite relations on a finite machine, the individual relvars CR and SR can never be base, they are always views of a join.

Suppose further that C and S are empty before the join, rename, projections and union. Before asking what should the resulting C and S relvar values be, I think we need to ask does the join allow the new proposition to be asserted. It doesn't allow us to assert "1 is not a customer AND 1 is a supplier". nor "1 is a customer AND 1 is not a supplier", only "1 is a customer AND 1 is a supplier".

Perhaps people will object that a join can't express a union or that OR
doesn't mean AND, but I see no problem at all in the above because the

*"union" has been defined as a join without any loss of possible tuples *

or introduction of spurious ones and if the tuple <c 1, s 1> is inserted
to the join's relvar there is still no loss. It seems simple enough to
define views such that we always insert to join and we always delete
from union. Just as submarines don't swim and sun-dials don't tell
time, computers don't actually assert propositions, they insert tuples.

Predicates aren't recorded. When a union is defined, the dbms designer has had no previous knowledge and no way of ensuring the db now reflects a predicate that even involves logical OR, same goes for logical AND (with suitable constraints, possible the db designer has such a way). Assuming either of AND or OR is probably an example of mysticism, or possibly an attempt to duplicate pred/prop logic rather than merely apply it, eg., the result of the D&D "<OR>" operator is defined in terms of tuple values, not logical OR. While logical OR is present in the definition, it is not recorded in the result, Only what is recorded and what the user or db designer knows has any significance. Users and designers must choose the recording forms that suit their purposes..

I think that without taking all of the above into account, defining INSERT I TO V as V:= V UNION I = V <OR> I = V OR I amounts to nothing else but preventing insert to union, same as what happens when people start painting the floor at the door sill. Received on Mon Sep 14 2009 - 21:14:22 CDT