Re: Lots of Idiotic Silly Braces?

"paul c" <toledobythesea_at_oohay.ac> wrote in message news:cs8pi.221$fJ5.172_at_pd7urf1no...
> Brian Selzer wrote:
> ...
>> How can a relation schema have more than one relation value at the same
>> time? ...
>
> With different names referring to the schema, whereas there is no such
> thing as two values for the same relation.
>
>> ... Or using Date's term, how can a relvar have two different values at
>> the same time? ...
>
> It can't. But this shows the difficulty casual language has when
> referring to database devices. "Time" really has nothing to do with
> relations but people let the word creep in because they are often assuming
> the database is inextricably tied up with some sequential language or
> other. (People who write about transactions fall into the same trap.
> Please don't confuse the above with a database that abstracts time with
> values for some application purpose.)
>
> ...
>> I think you're making my point for me. When a relation with a dependent
>> rva is UNGROUPed, there is no information loss. When a relation is
>> GROUPed, forming a dependent rva, there is no information loss. This is
>> clearly not the case for a relation that has an rva as the only key. I
>> think it is of critical importance that there is information loss when an
>> rva that is the only attribute is UNGROUPed.
>
> If that were so, I think one would need to define a different "UNGROUP"
> operator. Join and Project also lose information. Why is it critical not
> to?
>

JOIN is a binary operation, and the semantics of PROJECT are such that information is always lost, except in the trivial case that involves the entire heading.

Why is it critical?

Due to the information principle. If information is lost during an UNGROUP, then that means that the set of tuples in an rva is greater than the sum of its parts.

And also due to the Closed World Assumption:

Consider, if A, B and C are distinct tuples, then

(1) {{D={A, B}}, {D={A, C}}} ungrouped yields {A, B, C}
(2) {{D={A, B, C}}} ungrouped yields {A, B, C}
(3) {A, B, C} grouped yields {{D={A, B, C}}}

If {{D={A, B}}, {D={A, C}}} is valid, then the result of the ungroup operator,

{A, B, C}, is also valid,

and if {A, B, C} is valid, then the result of the group operator,

{D={A, B, C}}, is also valid.

So it follows that if {{D={A, B}}, {D={A, C}}} is valid, then

the proposition represented by the tuple, {D={A, B, C}}, is TRUE.

But under the closed world assumption,

{{D={A, B}}, {D={A, C}}} denies the existence of the following tuples:

{D={}}, {D={A}}, {D={B}}, {D={C}}, {D={B, C}} and {D={A, B, C}},

meaning that

the proposition represented by the tuple, {D={A, B, C}}, is FALSE.

the proposition cannot be both TRUE and FALSE; therefore, it follows that

{{D={A, B}}, {D={A, C}}} is not valid.

> Nothing wrong with different definitions as long as they hold up as well
> as the ones they replace.
>
> p
Received on Tue Jul 24 2007 - 19:48:42 CEST