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 Tue May 02 2006 - 22:26:07 CDT
