Marshall Spight wrote:

you're right; the '2 b' tuple shouldn't be there.

thanks,
paul c

If the above is indeed the <OR> definition,  then I do not understand how it
handles relations with the same header..

Let a tuple be a set of triples <A, T, v> (attribute, type and value).
Further, let r1 and r2 be relations with the same header H.  Now,  what
would be the result of tr1 union tr2 ?  Obviously it's not a relational
tuple any more because there are two attributes with the same name in the
union.  E.g.

tr1 = { <x,int,4>, <y, char,'a'}
tr2 = {<x,int,5>, <y, char,'b'}

tr1 union tr2 = { <x,int,4>, <y, char,'a'>,  <x,int,5>, <y, char,'b'> }

What am I missing ?

i like the precise way you put this.  for one thing, it makes it clearer
what <OR> means (ie. 'insert') and almost as clearly what <NOT> <AND>
(ie. 'delete') mean.

i may be missing the question (wouldn't be the first time) regarding 'no
way for headers to match', but i presume that's why they have <REMOVE>
in A-algebra (they also require projection in TutorialDee). i'm assuming
you mean something like a db with a couple of hundred relations each of
which had, say, ten attributes of which only one is common with some
other relation, so the equivalent single relation for that database
would have something like 9 X 200 = 1800 attributes (plus many,many,many
tuples!  likely, no person could compose that expression, but maybe
there's a reason for a machine to do it.  i don't know why, though.  if
that's what you mean by 'break', i guess you're right in theory.

FWIW, i tend to think that the headers keep expanding as long as i'm
talking about different things.  as soon as i start talking about the
same things, the headers stay the same.

from what i've read, D & D seem to want the traditional 'closure' idea
of an relational expression, always resulting in a single relation. i've
wondered why we couldn't have two or more relations in a result.  there
must be times when that's just as pragmatic and cheaper in space terms.
still, the A-algebra seems a very neat way to get the single closure effect.

p

Ha! That's happened to me before as well.

My understanding of the classical definition is that an algebra
is boolean iff:
for binary operators +, *, unary operator ', and elements 1, 0
1) +, * are commutative
2) +, * are distributive
3) for all A, A+0=A, A*1=A  (identity)
4) for all A, A+A'=1, A*A'=0  (complement)

It seems to me that compliment is the problem. The algebra
is obviously commutative. Elsewhere you've said it's distributive
(which seems right.) If we define 0=dum and 1=dee (or what
we've elsewhere called 00 and 01) we get identity, but it breaks
down at complement over <OR>.

A+A'= universal set for header(A)
A*A'=10

Both of these fail to satisfy 4).

Now, we could choose the 1 element to be a+a', and the 0 element
to be A*A'. Then identity and complement work. But it means that
the 1 and 0 elements are specific to some header(A), so you
could say it's a boolean algebra schema, rather than a boolean
algebra. (That is, for every header, you can construct a boolean
algebra for it, but it's not bollean in general.)

I have recently learned that there's an alternative way to specify
a boolean algebra. It is much simpler but I find it harder to
understand.

A "Robbins Algebra" is an algebra that satisfies these equations:
1. commutative
2. associative
3. Robbins Equation: n(n(A+B)+n(A+n(B))) = A.

where n() is the compliment function.

It turns out that every Boolean Algebra is a Robbins Algebra,
and vice versa. Which IIUC means that satisfying the Roobbins
Equation is sufficient to prove distributivity.

Anyway, it's all very complicated.

Oh, one last thought: I understand that every boolean algebra
will be defined over a set that has a cardinality that is a power
of two. This suggests power sets to me, which in turn reminds
me of the fact that we keep running into these algebras as
being specific to a given header.

Marshall

[...]

The above transformation ain't correct.  In fact such transformation cannot
be performed because x,y and z's domains are not specified.

I try to use the 'x:T' form exclusively to mean 'x has type T.'
Above I'm trying to say, "A has the type: set of (set of attributes
a with type(s) Ta, and set of attributes ab with types Tab.)"

Ordinarily I wouldn't find it necessary to bring the types in,
but in this case we need to name Ta and Tb specifically because
<OR> has us doing a cross product with the entire set of values
of the type.

The more I think about it, the more I agree that it should be {}.

Marshall