Re: Lucid statement of the MV vs RM position?
Date: Wed, 03 May 2006 00:54:35 GMT
Message-ID: <fbT5g.2240$A26.64195_at_ursa-nb00s0.nbnet.nb.ca>
paul c 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.
>> 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 Wed May 03 2006 - 02:54:35 CEST