Re: Constraints and Functional Dependencies

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Sun, 25 Feb 2007 20:45:11 GMT
Message-ID: <rzmEh.1271$PV3.18036@ursa-nb00s0.nbnet.nb.ca>

paul c wrote:

> 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.
>>
>> Frankly, Paul, I haven't got a clue what you are suggesting. When you 
>> say you are grouping the non-key attributes, do you mean to create an 
>> RVA with all of the non-key attributes? Or do you mean to create an 
>> RVA of the key attributes grouped on the non-key attributes?
>>
>> If you create an RVA with all of the non-key attributes grouped on a 
>> key, each relation value will have cardinality 1.
>>
>> If you create an RVA with all of the key attributes grouped on the 
>> non-key attributes, the cardinality of each relation value could be 
>> anything greater than zero.

>
> 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.

Simply put, b != {b} because the type of b is different from the type of {b}. Equating them would be the exact same error as equating {} with {{}}.

You are correct that R GROUP {all but some superkey} will have the same cardinality as R and the relation valued attribute would have cardinality 1. Received on Sun Feb 25 2007 - 14:45:11 CST