Re: Lucid statement of the MV vs RM position?

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.

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

-- 
Jon