Re: Constraints and Functional Dependencies

Bob Badour wrote:
> paul c wrote:
>

>> paul c wrote:
>>
>>> paul c wrote:
>>>
>>>> Marshall wrote:
>>>>
>>>>> ...
>>>>> Hmmm. Can we express keyness otherwise? I can't think how.
>>>>> ...
>>>>
>>>>
>>>> ... I sometimes wonder whether an alternative concept or two, such 
>>>> as a variation on D&D's GROUP/UNGROUP operators might allow 
>>>> definition of keys without rename or your prime operator.  ...
>>>
>>>
>>> eg., if you GROUP the non-key attributes of R, I think the result 
>>> will equal R in the most literal way if the remaining attributes 
>>> constitute a key (maybe somebody will correct me if that's wrong).
>>
>>
>> ie. to the eg. - I might be violating TTM's definition of equality 
>> here, not sure.

I don't know exactly how to answer, maybe I should have emphasized that I wasn't talking about SQL GROUP BY which I have no knowledge of at all.

Let me give a simplified small example relation that I hope will either show I don't understand TTM's GROUP or maybe show what I thought I meant:

R:
a b

---
1 1
2 1

For this value of R, "a" looks like it could be a key.

I think R GROUP {b} as b would give:

R2:
a {b}
-----
1 {1}
2 {1}

Even though R and R2 are of different types, I would like them to 
compare as equal. I'm pretty sure but haven't tried to write a proof, 
that when "a" is a ck, R and R2 will always have the same number of rows 
and the different values for {b} will always be singletons.

Whereas if I have

R3:
a b
---
1 1
1 2

R3 GROUP {b} would give

R4:
a {b}
-----
1 {1
    2}

My little picture here may not be very clear but I'm trying to show that 
R4 has only one row and no singletons in the {b} attribute.  I was 
thinking that maybe there's a logical way to say that R and R2 are equal 
because the unwrapped singletons in R2 could give exactly R, what we 
started with.  Whereas I wouldn't like to call R4 equal to R3 as it 
doesn't even have the same number of tuples.

I suspect this kind of interpretation, if I can call it that, where 
"{b}" sometimes means "b" would seem outrageous to some and it might 
have other implications regarding the basic relational operators, such 
as join that I haven't figured out.

p