Re: Lucid statement of the MV vs RM position?

From: paul c <toledobythesea_at_oohay.ac>
Date: Wed, 03 May 2006 00:12:27 GMT
Message-ID: <LzS5g.108016$7a.8274_at_pd7tw1no>


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

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

thanks for comment,
p Received on Wed May 03 2006 - 02:12:27 CEST

Original text of this message