what is the logical difference

From: pc <magoo_at_pssstoff.org>
Date: Thu, 09 Dec 2004 00:40:25 GMT
Message-ID: <Z9Ntd.20604$6f6.415_at_edtnps89>



To some, this may just seem a tiresome rehash of various articles on how to avoid "nulls" in the RM. My questions are for anybody who doesn't think so.

Suppose I have a relation value "THINGS" with the following in it (ID is the "key" for the relations below):

ID NAME COLOUR
==

1	Sky	Blue
2	Grass	Green

Suppose I also have relation value "NAMES" with this value:

ID NAME
==

1	Sky
2	Grass

and relation value "COLOURS" with this value:

ID COLOUR
==

1	Blue
2	Green

Assuming that "ID" is drawn from the same domain (I mean that in as specific as possible a sense) for all three relations, the "THINGS" value doesn't contain any more information than the "combination" (speaking loosely) of the two other relation values. (Given the values above, the values of "NAMES" and "COLOURS" are projections of the value of "THINGS".)

(just an aside - I think this would be true even if ID were not a "key".)

Now, if the "NAMES" value became:

ID NAME
==

1	Sky
2	Grass
3	Water

then the "THINGS" value would contain less information than the "combination" of the "NAMES" and "COLOURS" values.

I must say that I agree with the people who eschew nulls. So at this moment, I don't see how to guarantee that there will be no logical difference FOR ALL TIME between "THINGS" and the combination or natural join of "NAMES" and "COLOURS" without the use of foreign keys.

Comments?

Secondly, assuming that some way of avoiding update anomalies is inherent in whatever system one might use, is there any reason why all three tables couldn't be base tables?

(I won't be offended if people choose to vote rather than explain their answers - for example, "that's a stupid question" is an OK answer to me, but if you want to call me an idiot, please explain why!)

thanks,
pc Received on Thu Dec 09 2004 - 01:40:25 CET

Original text of this message