Re: Lucid statement of the MV vs RM position?

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Wed, 03 May 2006 00:54:35 GMT
Message-ID: <fbT5g.2240$A26.64195@ursa-nb00s0.nbnet.nb.ca>

paul c wrote:

> Bob Badour wrote:
>

>> paul c wrote:
>>
>>> Jon Heggland wrote:
>>>
>>>> David Cressey wrote:
>>>>
>>>>> In Ted Codd's 1970 paper,  he points out that when a system of 
>>>>> relations is
>>>>> devised to store a body of facts,  there are other systems of 
>>>>> relations that
>>>>> will express precisely the same body of facts.  He then points out 
>>>>> that
>>>>> within a group of such systems that are all logically equivalent,  
>>>>> there
>>>>> will be (at least) one that contains no sets, lists, or RVAs as 
>>>>> elements of
>>>>> a tuple.
>>>>
>>>> ....on two conditions:
>>>>
>>>> "(1) The graph of interrelationships of the nonsimple
>>>> domains is a collection of trees.
>>>> (2) No primary key has a component domain which is
>>>> nonsimple.
>>>> The writer knows of no application which would require
>>>> any relaxation of these conditions."
>>>>
>>>> Other writers claim they *do* know of such applications, however, and
>>>> have proposed (semi-)formal guidelines for identifying cases where RVAs
>>>> may be appropriate.
>>>> ...
>>>
>>> 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 problem with SP { S#, {P#} } in base relations is it brushes up 
>> against the information principle. It introduces a 'thing' that one 
>> cannot discuss as a simple value, and that 'thing' is a set of parts.
>> ...

>
> Interesting you should say that. I thought it was adhering quite well
> to the IP, more so than the tack the practical people I've known would
> likely have taken.

I said it brushes up against it. It doesn't violate it in the sense that one can still refer to a set {P#} by the value of the entire set. But that's an awkward way to refer to it -- especially when the value can change with time.

   But most of them were excessively practical and I
> admit I'm not, probably excessively impractical for that matter. If I
> were a supplier, I must admit I'd give my part set offerings
> names/identifiers, otherwise nobody would order them. But I'd prefer
> the system to make them up for me.

Nothing I said precludes that. However, if SP { S#, {P#} } is your base relation, how is the dbms going to refer to what it makes up?

>> While I can see no particular argument against SP { S#, {P#} } as a 
>> view, I can see some potential problems with having it as a base 
>> relation. Of course, those problems are only potential problems.

>
> My interest is mostly so that I can reconcile such perhaps oddball views
> before I finish with my little engine. Actually, I'm interested in it
> as an internal expression for want of a better term, more so than as a
> view, even though I wouldn't want to prevent such a view. I'm always
> suspicious of restrictions in systems since they *usually* end up
> demonstrating that the implementor didn't know exactly what to do next
> (like most of the developers in the average large project, can't resist).

Certainly such a construct would be useful for describing physical clustering of data as well, but that ventures beyond the realm of the RM per se.

> thanks for comment,
> p

You are very welcome. Received on Tue May 02 2006 - 19:54:35 CDT