Re: Lucid statement of the MV vs RM position?
From: paul c <toledobythesea_at_oohay.ac>
Date: Wed, 03 May 2006 15:06:17 GMT
Message-ID: <JF36g.113324$WI1.32273_at_pd7tw2no>
>
>
> The standard examples of Date & co. is relvars and their keys, and
> (iirc) functional dependencies. Those two both involve set-valued
> attributes, and they can't be "flattened" without losing information
> (unless you introduce an identifying attribute for each set). Your
> example is equivalent, I think. Anyway, isn't that you on the TTM list?
> You should know about Darwen's group-ungroup normal form, then.
Date: Wed, 03 May 2006 15:06:17 GMT
Message-ID: <JF36g.113324$WI1.32273_at_pd7tw2no>
Jon Heggland wrote:
> paul c wrote:
>
>>An example that some may not find very interesting, ie., too simple but
>>still troubles me might be "the sets/combinations of parts that a
>>supplier will agree to ship" having no other attributes than S# and P#,
>>eg., SP { S#, {P#}} where I'm intending {P#} to mean a set of parts. I'm
>>interested to know of the other writers or what they say.
>
>
> The standard examples of Date & co. is relvars and their keys, and
> (iirc) functional dependencies. Those two both involve set-valued
> attributes, and they can't be "flattened" without losing information
> (unless you introduce an identifying attribute for each set). Your
> example is equivalent, I think. Anyway, isn't that you on the TTM list?
> You should know about Darwen's group-ungroup normal form, then.
Yes and I admire Darwen's approach to things even though there is much in TTM and elsewhere that I'm not yet capable of understanding. There seems to be something elemental about g-unf but I was trying to step back from that because ttm's machinery is a little vast for me and the strictures often trip me up (was also trying to think of an example with as few technical connotations as possible or other baggage such as telephone number examples). Of course going at it this way has the big disadvantage that one is often left at a loss for words, ie. concepts!
p Received on Wed May 03 2006 - 17:06:17 CEST