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_at_ursa-nb00s0.nbnet.nb.ca>
>
> 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.
Date: Sun, 25 Feb 2007 20:45:11 GMT
Message-ID: <rzmEh.1271$PV3.18036_at_ursa-nb00s0.nbnet.nb.ca>
paul c 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.
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 - 21:45:11 CET