Re: more algebra

On Apr 8, 10:18 am, Sampo Syreeni <de..._at_iki.fi> wrote:
> On Apr 8, 6:59 pm, Vadim Tropashko <vadim..._at_gmail.com> wrote:
>
> > > How about A join project_K(A)=A?
>
> > This is not a constraint. [...]
>
> As I spelled it, no, it indeed isn't; a hardy remainder of why I
> should never try to do any mental calculation or to device any new
> notation to suit my intuitions. But I'll try again: perhaps I meant to
> say A join_K A=A instead, without renaming attributes.. We want to
> express K_1=K_2 => (A\K)_1=(A\K)_2, algebraically and point-free. The
> basic idea remains the same: no extra tuples.

Algebraically and point free -- no argument there. Unless I understand your idea differently, from my perspective "point-free" algebraic notation means no mentioning attribute sets whatsoever. I'm not sure what Paul meant by "key constraint", but inclusion dependency is expressed algebraically (http://arxiv.org/abs/0902.3532) as

r v x < s v x

To think of it: this kind of inequality is the simplest expressionn that one can manufacture from 3 relation symbols and relational operations, so no wonder it is important.

The functional depndency constraint, is entirely different animal, however. It can be expressed with the count ("given a function argument the number of values in the range of is no more than one"), but this is outside the scope of relational algebra. The other (rather neat) construction from database folklore involves partitions (http:// vadimtropashko.wordpress.com/relational-lattice/lattice-perspective- into-funcional-dependencies/) Received on Thu Apr 08 2010 - 19:43:03 CEST