Re: Lucid statement of the MV vs RM position?
From: paul c <toledobythesea_at_oohay.ac>
Date: Wed, 03 May 2006 03:26:07 GMT
Message-ID: <jpV5g.108789$P01.69371_at_pd7tw3no>
>
>
> 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
>
>
>
> 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?
> ...
Date: Wed, 03 May 2006 03:26:07 GMT
Message-ID: <jpV5g.108789$P01.69371_at_pd7tw3no>
Bob Badour wrote:
> 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?
> ...
if you mean some part of a dbms, mentioning the relation might be the
same way as a developer might do that, eg., SP { S#, {P#} }. But to
sort of answer the question about what it is made up of, I don't think
it's necessary at this point to answer it, except to say that, obeying
the IP, one could regurgitate the parts set for the supplier one might
have in mind.
p
Received on Wed May 03 2006 - 05:26:07 CEST