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

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