Re: The Practical Benefits of the Relational Model
Date: Tue, 22 Oct 2002 17:45:25 +0100
Message-ID: <ap3vcg$1lqo$1_at_sp15at20.hursley.ibm.com>
"Paul" <pbrazier_at_cosmos-uk.co.uk> wrote in message
news:51d64140.0210220458.3f5b1862_at_posting.google.com...
> > Now it might be a bit of a pain to have a RDBMS that did not allow two
> > tables to have the same attribute names (and types) in the same
*database*,
> > but frankly I could live with such a restriction if it enforced the
> > Orthogonal Design Principle (and if any local relvars we not seen as part
of
> > the main database)
>
> I was thinking of something related to this from a slightly diferent
> angle: relational theory is built on first-order predicate logic but
> also I've often heard it said that it is also based on set theory. Now
> set theory is built on first order predicate logic so I'm not sure if
> relational theory *requires* set theory or maybe just a weak subset of
> it or what.
>
> So the relations are the sets and the tuples are the elements of that
> set.
>
> But one of the axioms of set theory (extension) says that two sets
> with the same elements are equal. But you could easily have two
> relations with identical tuples but different "meanings". For example
> consider a relation with columns in domains "person" and "country".
> One could be from the predicate "lives in" e.g. "Fred" lives in "the
> UK". Another with identical domains and tuples could be from the
> predicate "was born in".
As Leandro said:
"Codd's first paper it is clear that a relvar header can have the
same domain twice, and then their names must be different."
Two tuples can only be identical if they have the same set of <attribute name, datatype> pairs.
If you don't match on attribute names then with these relvars
does this relation value
CREATE TABLE R (A INTEGER, B INTEGER);
CREATE TABLE S (C INTEGER, D INTEGER);
CREATE TABLE T (C INTEGER, D INTEGER);
R := VALUES(1, 2)
equal this relation value?
S := VALUES (1, 2)
T := VALUES (2, 1)
If you answered YES, YES to the above, then after
R := R UNION (3,4); S := S UNION(3,4); T := T UNION (3,4);
Does R = S?
Does R = T?
If you answered YES, NO, then you have just admited that
given
R = T
then
R UNION (3,4) <> T UNION (3,4) !
Unless you do some attribute renaming R can never equal either S or T.
> It might just happen that for the universe of people at one particular
> snapshot that everyone is living in their country of birth.
>
> Maybe there is a need to distinguish between equality and identity
> here i.e. two relations can be "equal" for a database snapshot but not
> "identical" or tautologically equivalent for all possible values of
> the database?
No.
Regards
Paul Vernon
Business Intelligence, IBM Global Services
Received on Tue Oct 22 2002 - 18:45:25 CEST