Re: Lots of Idiotic Silly Braces?

From: Brian Selzer <>
Date: Fri, 20 Jul 2007 05:54:00 GMT
Message-ID: <Y5Yni.38897$>

"paul c" <> 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 a consequence, I don't think that a relation valued attribute can stand on its own. Lending support to this is the fact that the duality of GROUP and UNGROUP does not hold for R. r UNGROUP S yields the relation value (call it r'),

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


(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

Original text of this message