Re: On formal HAS-A definition

On May 12, 11:54 am, Erwin <e.sm..._at_myonline.be> wrote:
> On page 95, bottom paragraph of the section discussing "the definition
> of a table", we find for example :
>
> "Even the empty set is a table.  In fact, under Definition 5-1 (...),
> the empty set is a table over any set.  ..."
>
> (Between brackets : the choice of the term "table" here is because the
> intended audience of the book is, first and foremost, SQL
> practitioners.  I'm quite sure that the authors knew what the better
> term is.)

This is shocking revelation to me. I failed to imagine somebody would ever consider the two relations

PersonSalary = [name salary];

and

PersonName = [name];

to be identical. An informal argument is that any nonempty relation carries over information about the header (attribute set), and empty relation loses it. This is very unnatural break of continuity from mathematical perspective. I'm pretty sure if somebody would ever come with axiomatization of their table algebra, it would have weird properties. For one thing, if I add it to RL axioms:

x ^ y = y ^ x.
(x ^ y) ^ z = x ^ (y ^ z).
x ^ (x v y) = x.
x v y = y v x.
(x v y) v z = x v (y v z).
x v (x ^ y) = x.

x ^ (y v z) = (x ^ (z v (R00 ^ y))) v (x ^ (y v (R00 ^ z))).

x ^ R00 = y ^ R00.

then it immediately derives distributivity of ^ over v. There certainly is a counterexample for distributivity with all three relations being nonempty:

z = [p q r]

     0  a  0
     0  c  0
     1  a  0

     a
;
x = [p]

     1
;

> I suspect that the "multiple typed empty relations versus one single
> empty relation for all (relation) types" relates closely to whether
> the intent is to define a data manipulation language.  D&D have that
> intent, so they need assignment, so they need to address/resolve the
> issues caused by "one single empty relation for all types".  AM4DP
> does not have that intent (its prime intent is to define a database
> design specification language that has solid foundations in maths), so
> they don't run into things such as 'assignment' and 'compile-time type
> checking' and such.  So they can cleanly get away with the "one single
> empty relation for all relation types" position.

Now I that you are kindly explained this passage, I'll venture off, because they start with the false premise that there is a single empty relation. Received on Wed May 12 2010 - 23:36:29 CEST