Re: a union is always a join!

paul c wrote:

>Criticisms, please (preferably ones based on some formal logic or other).
>
>It is inescapable that every relation is a join (eg., Heath's theorem).

As Brian writes, this is one step too far. Every relation can be decomposed into smaller ones based on its nontrivial functional dependencies, but if it hasn't any - and the resulting relations don't - it is only a join of itself.

Perhaps by join you mean something like the AND in Darwen's 'A New Relational Algebra' (thanks for giving its URL earlier), which has the join and and union of relational algebra as special cases. We can also decompose relations by writing them as the unions of other relations (someone I know wrote a PhD thesis about it), but Heath isn't about that.

>So every relvar points to a join. If we can't 'delete' through a join,
>we can't delete from any relvar (my father, who thought a disk buffer
>was a polishing material could have concluded this - also, I surmise, we
>can't logically express some number of otherwise possible relations
>when we have some purpose besides defining a 'view').

I don't follow. If we know the dependencies, some deletions are possible, while others aren't. How is this relevant if you don't make a distinction between 'base' and 'virtual' relations? (Or 'time varying' relations and views, whatever.)

>The reason for every relation being a join has nothing to do with the
>expression that forms a join 'view'. I think it's a consequence of
>Codd's algebra that every relation that has more than one subset of
>attributes is a join of two or more relations.

If by 'subset of attributes' you mean 'key', you're right.

>By Heath, there will
>always be two heading subsets (at least one of them having the same
>heading as the relation) that will determine the other possible pairs of
>heading subsets in a join.

Heath has an 'if' clause; aren't you overlooking it?

>Because the join on all of a relation's
>attributes with any subset of them is algebraically equal to the
>relation, it looks to me that the number of possible and irreducible
>join expressions is at least equal to the number of subsets of
>attributes in a relation heading. (This is implicit. Explicit
>constraints may have a number of expressions that are fewer and still
>sufficient to express all the possible expressions.)

Yes, but what are trivial joins good for?

>For the same reason, every 'insert' is through a join, even if the
>'insert' is also to a 'view' formed by union.

An insert extends a relation vertically (it adds tuples); a relational algebra join horizontally (it extends tuples with attributes and values), but when projecting these attributes away again, hasn't added anything). An insert can be expressed as a (relational algebra) union of the existing relation with the inserted tuples, but no nontrivial r.a. union is a r.a. join (and vice versa). Using the term 'join' for Darwen's AND operator, which combines r.a. union and join, doesn't change this.

What are you trying to achieve?

>One can equally say that
>some relations involve union, but this doesn't change the fact that they
>are also joins, in other words, not all joins are algebraically equal to
>some union or other, ie., if a relation is formed by join, it is not
>always also a union.

In the relational algebra, a nontrivial union is never a join or vice versa. What does combining them into "AND" buy you?

>If so, it should be far more productive to design a language based on
>axioms that are universal, the theorems that are always true, rather
>than on statements that are true only sometimes.

I don't see what this has to do with anything you wrote before.

-- 
Reinier