Re: constraints in algebra instead of calculus

From: paul c <toledobythesea_at_oohay.ac>
Date: Sat, 26 May 2007 14:27:59 GMT
Message-ID: <PtX5i.224844$aG1.197340@pd7urf3no>

Vadim Tropashko wrote:
> On May 20, 9:08 pm, paul c <toledobythe..._at_oohay.ac> wrote:
>

>>Marshall wrote:
>>
>>>Okay, a while back we were talking about writing constraints
>>>in a language with aspects of the relational calculus, specifically
>>>the existential and universal quantifiers. The point was made
>>>that that's unnecessary; the calculus is no more expressive
>>>than the algebra.
>>
>>>So it ought to be possible to write any constraint from the
>>>calculus in the algebra.
>>
>>>Well, I'm having a hard time figuring out how to do it. Can
>>>anyone help?
>>
>>>How does one write a functional dependency in the algebra?
>>>A foreign key?
>>
>>>Marshall
>>
>>I thought that one was easy, if FK is the set of 'foreign key'
>>attributes and A is the 'referencing table' and using an op like D&D
>><AND>, then it's something like A{FK} <AND> B{FK} = A{FK}.  (I like this
>>one because it's particularly easy to implement.)-

>
>
> FK is easy indeed. Assuming that we rename attributes of A and B in
> such a way that x becomes a common FK attribute, a FK constraint is
> written in relational lattice as
>
> A \/ X < B \/ X
>
> where X is the empty relation with attribute x. Naturally, I'd suggest
> too call the constraint between arbitrary 3 relations
>
> A \/ C < B \/ C
>
> as a generalized FK...
>

Regarding the FD, or key for short, which hasn't been mentioned much so far, here's what I've seen so far, assuming one relvar A with non-overlapping attribute sets K and FK:

Use a COUNT function to test that the projection on K has the same cardinality as A. (I've seen this approach in a number of different places, so maybe it is most common.)
Take the PRODUCT of A and A with K and NK RENAME'd to RK and RNK and test that RNK = NK whenever K = RK.
Use TTM-style GROUP/UNGROUP to test that UNGROUP {NK} (GROUP ( (A GROUP {NK} as NK )) = A

I've seen 1) and 2) suggested here and there. For some personal/illogical reason I can't explain, I like the third one better even though the formal definitions of GROUP and UNGROUP seem more complicated than those of COUNT and RENAME and even though I'm not sure I've seen it written in so many words. Also I guess one could argue that GROUP/UNGROUP as we usually know them, involve RENAME.

(Seems a little awkward that something as basic as the key concept is more involved to test for than references/foreign keys.)

Like Marshall, I'm curious what other methods people have used or thought of.

p Received on Sat May 26 2007 - 09:27:59 CDT