Re: Lucid statement of the MV vs RM position?

From: paul c <toledobythesea_at_oohay.ac>
Date: Thu, 04 May 2006 15:32:02 GMT
Message-ID: <S7p6g.121620$7a.76035_at_pd7tw1no>


Jon Heggland wrote:
> paul c wrote:
>

>>Jon Heggland wrote:
>>
>>>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

>
>
> GUNF intuitively seems very simple to me; like most NFs, it's just
> formalised common sense. Consider an example of the relvar keys relvar (1):
>
> Relvar|Key
> ======+========
> R1 { A }
> R2 { B }
> R1 { C, D }
>
> ---i.e. relvar R1 has two keys, { A } and { C, D }, while R2 has but
> one, { B }. Ungrouping (unnesting) it produces the following relation (2):
>
> Relvar|Key component
> ======+=============
> R1 A
> R2 B
> R1 C
> R1 D
>
> ---and grouping it again produces this (3):
>
> Relvar|Key (wrong)
> ======+-----------
> R1 { A, C, D }
> R2 { B }
>
> (3) is different from (1), hence (1) is in GUNF, and the use of an RVA
> is justified. (Actually, Darwen's GUNF formulation is slightly
> different, but I believe my example captures its intent. The point is (I
> think) that there does not exist any relation of type (2) that when
> grouped produces (1).)
>
> In contrast, the Barney/Oscar relvar (1):
>
> Name |Colours
> ======+-------
> Barney { green, purple }
> Oscar { green, black }
>
> is *not* in GUNF, because there exists a relation (2)
>
> Name |Colour
> ======+======
> Barney green
> Barney purple
> Oscar green
> Oscar black
>
> that when grouped produces (1). Switching names and colours does not
> help, of course.
>
> Your supplier/parts example is probably equivalent to one of the above;
> I'm not sure which, since you don't give all the necessary details (viz.
> keys/FDs).

Thanks for those effective examples, Jon. I mean effective because they seem to show that some relations can't be expressed without rva's (even though I don't know how to prove it formally), which was basically the only point I was trying to make.

The reasons I wanted to avoid the catalogue relvar example were two: 1) it's harder for me to be clear about them when I end thinking about "keys of keys" (eg., the key of your relvar (1) is the attributes Relvar and Key) and 2) it brings in metadata which I find harder to talk about in a careful way (eg., having to always distinguish between the types of the attribute names in the catalogue versus the types of the attributes in the base/view relvars they refer to).

BTW, I did have in mind as you probably suspect that {S#, {P#}} was "all-key". When I first read about GUNF, I seem to remember my quibble was the inclusion of 'normal form' in the term. Admittedly, a better mind than mine thought it up but at what seems to me to be a preliminary point, I'd rather label it temporarily as group-ungroup equivalence or somesuch. I say preliminary because at least for me ttm's group and ungroup examples seem to operate on one rva at a time and I wasn't sure what happens when more than one rva is involved and whether that might have something to do with the typical examples of multi-valued dependencies (group and ungroup seem to always imply a key, possibly a different one from the input relvar's key and this seemed a little chicken and egg to me). Plus, I wondered whether there's anything canonical/axiomatical that can be said about the results of specifying all or none of the attributes in a group or ungroup expression.

Perhaps my troubles here are just the result of misconceptions but I'm tempted to go even further and wonder if the concept of relvars is even necessary to discuss the subject of rva's, eg., when are two relations, written down differently, the same? I know that to put it loosely, ttm says they are the same when they have the same value, so the relation of 'integer 3' doesn't have the same value as the relation of 'integer 6 divided by integer 2' as far as the system is concerned (although they might well in the eyes of the beholders who agree on what divide means).

   The very term 'relation-valued attribute' seems to suggest that I'm wrong about this and that relvars are necessary but either I don't have the vocabulary to argue against them or such vocabulary isn't possible, which I also can't prove. Maybe it's all merely a gut feeling that something is missing. And I don't mean NULLS!

(I didn't try to pursue this with the ttm people because that would seem like either ignorance or insolence to me, questioning ttm's starting points without having a systematic replacement for it whereas ignorance is tolerated here, at least up to a point, by more knowledgeable people such as you. Maybe I've reached that point!)

p Received on Thu May 04 2006 - 17:32:02 CEST

Original text of this message