# Re: Lots of Idiotic Silly Braces?

Date: Fri, 20 Jul 2007 15:10:35 GMT

Message-ID: <Lf4oi.131821$xq1.73460_at_pd7urf1no>

Brian Selzer wrote:

...

> 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. ...
*

I think "S" here is an attribute name, not a relation. S refers to two different relation values which happen to appear as tuples in r. The first tuple of of r asserts that the ("first", relation-valued) tuple that combines (P(3,4) AND P(3,5)) is true in one relation value. The second tuple implies that (P (3,5)) is false in the "second" relation value.

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

If r' has two tuples and one attribute and S refers to a relation with attributes A and B, r' GROUP {A,B} has one tuple. I find it hard to read this notation, but I think I see two tuples in (1) so I would reject it and I think (2) is right.

> 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.
**> ...
*

It holds when the attributes that are not grouped are dependents.

> For these reasons, I believe that rvas cannot be keys or
components of

> keys--at least not for base relations. Have I overlooked something?

S is the key of r above.

p Received on Fri Jul 20 2007 - 17:10:35 CEST