Re: constraints in algebra instead of calculus

paul c wrote:
> paul c wrote:
>

>> ...
>>
>> 3) Use TTM-style GROUP/UNGROUP to test that
>> UNGROUP {NK}
>>    (GROUP ( (A GROUP {NK} as NK ))
>> = A
>> ...

Marshall, this mis-step has bugged me for days, for no reason that I can explain, except that at one time it all seemed crystal-clear and I'm not sure now whether my memory is bad or whether I was flat-out wrong to think of GROUP et cetera in this way. This might be what I was trying to remember:

(Assuming D&D's Tutorial D syntax which I've probably mangled but hoping you get the drift. I've tried to write it slow-motion with a bunch of relvars and assignments, because I don't think I could avoid those without error, even when wide-awake and sober.)

R is relvar name, A is candidate key, B is set of all the non-key attributes.

1. R1 := R GROUP ( {A} as gA )
2. R2 := R1 GROUP ( {B} as gB)
3. R3 := R GROUP ( {B} as gB )
4. R4 := R3 GROUP ( {A} as gA )
5. R5 := R4{gB} <AND> R2
6. R6 := UNGROUP ( R5 UNGROUP (gB)) (gA) )
7. (constraint) R6 = R

I'm pretty useless at proving this stuff formally, but my rationale, if I can call it that, is: A is a candidate key if no two rows in R have the same A value. Now need to show that no two rows in R5 have the same A value. In step 5, only rows with R4.gB singleton values will match R2 rows (because R2 has only singleton gB values in each row). No matching R2 row could have two gA tuples with common A values, because if they did, their gB.B tuples wouldn't match.

I realize that this must seem (if it's right in the first place) an elaborate way to assert a candidate key and I would be very curious to know of a shorter way, if there is one. Or indeed any comment from you or the others that might help me see that it is wrong. I'm always nervous when I have to write as much as this, that I've got it totally balled up.

Somewhere, I read CJ Date mocking a book that suggested constraints and assertions were different and his example which I forget but which had to with birds made me chuckle and think he was right. Although the above is intricate according to my experience, it interested me because it avoided cardinality (if not singularity) and 'rename' (although TD does have this 'AS' keyword, it seems more or less founded on the D&D 'A-algebra', which I like because it is so minimal as far as concepts are concerned). Also, I'm not sure how far this might go when it comes to 'group'-ing all of a relvar's attributes or none of them, because I don't think I understand D&D's intent when they define that operator. Apart from trying to answer your original question, the exercise interests me mainly as a way to possibly understand equivalence of two relations one of which 'contains' rva's and one which doesn't. Received on Fri Jun 15 2007 - 04:46:27 CEST