Re: Lots of Idiotic Silly Braces?
Date: Fri, 20 Jul 2007 05:54:00 GMT
Message-ID: <Y5Yni.38897$YL5.701_at_newssvr29.news.prodigy.net>
"paul c" <toledobythesea_at_oohay.ac> wrote in message news:lSVmi.123823$xq1.100625_at_pd7urf1no...
> Bob Badour wrote:
>> paul c wrote:
>>
>>> Bob Badour wrote:
>>>
>>>> paul c wrote:
>>>
>>>
>>> ...
>>>
>>>>> The predicate somebody intends by this grouping could be "Shipment S
>>>>> included the set of parts {P}". If we then ask "what combinations of
>>>>> parts have been shipped?", a knee-jerk reation might be to project
>>>>> away the S attribute:
>>>>>
>>>>> {P}:
>>>>> {3,4}
>>>>> {3}
>>>>
>>>>
>>>>
>>>>
>>>> This represents it as one table.
>>>> ...
>>>
>>>
>>> I guess I was using the word "table" pretty casually. I'm fairly sure
>>> Codd didn't mention it much, talking rather of "normalization", and
>>> maybe I shouldn't suggest to compare the two, eg., he said:
>>>
>>> "Normalization proceeds as follows. Starting with the relation
>>> at the top of the tree, take its primary key and expand
>>> each of the immediately subordinate relations by
>>> inserting this primary key domain or domain combination.
>>> The primary key of each expanded relation consists of the
>>> primary key before expansion augmented by the primary
>>> key copied down from the parent relation. Now, strike out
>>> from the parent relation all nonsimple domains, remove the
>>> top node of the tree, and repeat the same sequence of
>>> operations on each remaining subtree."
>>>
>>> If I follow this literally, I suppose the fact that I can't "strike out
>>> ... all nonsimple domains", means that I am left with what I started
>>> with, namely a relation, you are saying that the table and relation in
>>> this case are one and the same, and you might say I am grasping at
>>> graphical representation that is an impossible over-simplification!
>>
>>
>> Because the primary key is {P}, if you follow the instructions literally,
>> you will normalize the relation to:
>>
>> {P} P
>> ==== ----
>> {3,4} 3
>> {3,4} 4
>> {3} 3
>>
>> I do not believe his instructions anticipated a relation valued primary
>> key.
> > I didn't read it that way, but I guess the paragraph does leave it a > little open to that interpretation. Anyway, thanks, I suspect you are > right about it not covering rva's that are keys. I imagine that if he had > tried to cover every last detail, that paper might not have had the impact > it did, but what do I know? (don't answer that!) >
Can rva's be keys? A relation value being the extension of a predicate, the
set of tuples in a relation value represents a set of positive atomic
formulae, and under the closed world assumption, that set implies the
negation of each atomic formula that conforms to the schema but is not
represented by a tuple. How, then, can a relation valued attribute be a
key? Consider, the schema R{S{A, B}}, and the following relation value, r:
r = {{S={{A=3, B=4}, {A=3, B=5}}}, {S={A=3, B=4}}}
Now, suppose that P(A, B) is the predicate of S. The first tuple of r
asserts that P(3, 5) is true, but the second tuple implies that P(3, 5) is
false. It stands to reason that P(3, 5) cannot be both true and false. As
r' = {{A=3, B=4}, {A=3, B=5}}
but r' GROUP {A, B} AS S yields either
(1) {{S={{A=3, B=4}}}, {S={{A=3, B=5}}}}
or
(2) {{S={{A=3, B=4}, {A=3, B=5}}}}
I can't be sure, but neither (1) nor (2) is identical to r. So clearly information is lost when you ungroup a relation expression that has only an rva in its heading. Furthermore, due to the definition of a functional dependency, it follows that the duality of GROUP and UNGROUP can only hold when the rva is a dependent attribute.
For these reasons, I believe that rvas cannot be keys or components of keys--at least not for base relations. Have I overlooked something?
> p Received on Fri Jul 20 2007 - 07:54:00 CEST