Re: What to call this operator?

Mikito Harakiri wrote:
> Marshall Spight wrote:
> > In chapter 4 or The Third Manifesto, D&D define a "new relational
> > algebra."
> > This algebra includes two operations named "<AND>" and "<OR>". (They
> > use some weird triangle characters which I'm approximating with <>.)
> >
> > Given relations S and T, having sets of attributes a (only in S),
> > b (in both S and T) and c (only in T), they define:
> >
> > <AND> as { (a, b, c) | (a, b) in S, (b, c) in T }
> >
> > <OR> as { (a, b, c) | (a, b) in S, c unconstrained UNION
> > (a, b, c) | (b, c) in T, a unconstrained }
> >
> > "unconstrained" means that all values from the domain are present.
> >
> > They go on to point out that <AND> is the natural join, but they
> > don't give a name to <OR>.
> >
> > Does anyone have a good idea for what it should be called?
> > I don't like "or" because it's ambiguous with the boolean
> > operator. "<OR>" isn't great for syntactic reasons. "Disjunction"
> > is cumbersome. I'd like to hear something analogous to "join."
> > What about "meet", does that work? It's the usual counterpart to
> > "join" but I don't know enough math to decide if it's appropriate.
> >
> > Anyone have any other ideas?
>
> The outer union operator dates back to Codd
> "Extending Relational Model to capture more meaning"
>
> See also Galindo-Legaria "Outer joins as disjunctions"
>
> In my opinion this definition of union is less interesting than
> http://arxiv.org/pdf/cs.DB/0501053

I skimmed that paper and it looks quite interesting. (I'll try to give it a deeper read tonight.) I'm unfamiliar with the tensor product, and Googling only gave me vector definitions which I couldn't map into relations.

As a math paper it makes sense, but I wouldn't expect to be able to use those concepts unmodified in trying to build a computer system because of the use of infinite relations. It might be possible to specify these intensionally but of course not extensionally. So for example in sect 3.2, selection is defined in terms of join + an infinite relation. I don't know that it's all that much of a difference to supply the relation intentionally, aka with a selection predicate. Of course, this means adding back in selection as a primitive. Hmmm; maybe you could extend join so it works with explicitly intentional relations. Hmmm.

My intuition is that there might be some advantage to building systems with as few primitives as possible because it would simplify the optimizer. But that's not immediately clear.

Very interesting.

Marshall Received on Mon Jun 27 2005 - 22:22:05 CEST