Re: Transitive Closure

From: Paul <paul_at_test.com>
Date: Sun, 16 May 2004 20:56:42 +0100
Message-ID: <SHPpc.4910$NK4.486732_at_stones.force9.net>


Mikito Harakiri wrote:
> In relational world operator commutativity is very important.

Why is it important? It might be handy from a physical implementation point of view to have commuting operators but I can't see any logical reason to exclude non-commuting operators.

Lack of commutativity is probably just a consequence of moving away from first-order logic. If you want greater power in your query expressions, the price you pay is more complexity in your physical implementation.

> Although Relational Algebra appears to be more procedural than
> relational calculus (apply this selection, then, apply this
> projection, and so on), this syntactic order doesn't really matter as
> selection and projection commute to about every other operator. This
> is why select-project-join is expressed in good old SQL as:
>
> select ... from A,B,C where ...
>
> without any emphasis into the order of those operations.
>
> Relational implementation terminology coined this phenomenon as "move
> around predicates".

Well I think you can cut down the necessary relational operators to just two: projection and either "nor" or "nand". (This is in the Third Manifesto book where their version of projection is called "remove".) Projection corresponds to a "there exists" in logic, and nor/nand are just the usual logic operators. Although nor/nand are binary operators, you can have a kind of commutativity over the relevant operand i.e. p(n(R,S)) = n(p(R),S) where p is projecting over an attribute of R. Or just think of the operator "nS" as being a unary operator: nS(R) = R nor S.

So I think it's only because your basic algebra is very small that you have commutativity, and it's no problem that it breaks when you extend your model.

Paul. Received on Sun May 16 2004 - 21:56:42 CEST

Original text of this message