Re: more algebra

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.

The right to left inclusion is trivial: by the definition of an equijoin: a self-equijoin cannot lose tuples, nor can you project downto something which losslessly joins back because all attributes are present on either side. The left to right direction remains to be shown. First suppose the key constraint holds. In this case a join along the key will match precisely one tuple in either direction, so the result of the join is an identity, and inclusion holds. Contrariwise suppose that the above "constraint" does not apply. Then there are at least two tuples for which K is equal but A\K differ. That means that they would be crossmatched in the join. Now choose one of the crossmatched cases from the right side and project back to left; either you now have values which weren't in the original A or a contradiction in the tuples not agreeing on K. The latter case shows that K is not in fact a key.

True, this is still hazy logic, but not quite as bad as my previous post. And even if it needs emendation, the gist of the argument should be clear.

--
Sampo