Re: more algebra

From: paul c <toledobythesea_at_oohay.ac>
Date: Thu, 08 Apr 2010 18:19:38 GMT
Message-ID: <_6pvn.1121$z%6.955_at_edtnps83>


Vadim Tropashko wrote:
> 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/)
>

By 'key constraint', I meant also what you call 'functional dependency constraint', not inclusion dependency. Received on Thu Apr 08 2010 - 20:19:38 CEST

Original text of this message