Re: Data Display & Modeling

From: Paul <paul_at_test.com>
Date: Mon, 10 May 2004 13:24:31 +0100
Message-ID: <%vKnc.2119$NK4.191091_at_stones.force9.net>


Laconic2 wrote:

>>to keep the model as simple as possible (but no simpler).  But
>>mathematically simple and conceptually simple are not the same thing.  So,
>>even if you have to map the more mathematically complex, but conceptually
>>easier, approach of permitting types with internal structure in your model
>>to the relational model for some reason, it is worth it.  A significant
>>number of relational theorists seem to now permit attributes with internal
>>structures, at least relation-valued attributes now.

>
> I'd like to suggest that Codd had a reason for this requirement that is
> neither mathematical nor conceptual simplicity.
>
> If you read Codd carefully, I believe you'll find that he acknowledges that
> there's no rule in relational math to prevent a relation from having an
> attribute that has a domain that is, itself, a relation. He surely doesn't
> impose this rule for mathematical simplicity. I'm less sure about
> conceptual simplicity, but I speculate that Codd did not have much
> divergence, in his own head, between conceptual simplicity and mathematical
> elegance.
>
> I'd suggest that the reason for the simple attributes rule is, perhaps,
> "implementation simplicity". Essentially, telling whether two relations
> are or are not equal involves comparing the elements, and that involves
> sorting them. Putting the necessity for sorting things implicitly into the
> RDM, while at the same time explicitly stating that order has no meaning in
> a relation, was just goin to confuse the engineers who built the first
> RDBMS systems.

Doesn't the need for sorting go into the type engine, not the relational engine? Essentially if you allow relation-valued attributes, you are creating a type that has its own little relational engine built in that is totally separate from the external relational engine. There's no way you could compare your "real" relations with your relations that occur as attributes - they're from two totally different universes.

Imagine a dog that has fleas. The fleas might themselves have some smaller parasites living on them:

"So, naturalists observe, a flea
Hath smaller fleas that on him prey;
And these have smaller still to bite 'em; And so proceed ad infinitum."
(Jonathan Swift)

Now the fleas that live on the fleas are in a totally different world to the fleas that live on the dog.

I think it boils down to the difference between "sets" and "types":

In set theory members of a set are themselves sets. Indeed everything is a set and there is no concept of some sets being at different levels to orher sets, they're all the same. This can lead to paradoxes such as sets being members of themselves, so to resove that you have the Axiom of Foundation: http://en.wikipedia.org/wiki/Axiom_of_foundation

Type theory gets round the problem a different way: things are at different levels, you have a hierarchy. So you don't compare things at different levels and thus a type can never be contained within itself by definition.

So if you have relation-valued attributes, you might call them 0-relations, 1-relations, 2-relations etc., where 0-relations are your top-level relations and 1,2,3...-relations are members of "relation types" or "relation type attribute types", etc. Because the relations in your relation-valued attributes might themselves have relation-valued attributes, etc. As long as you keep them all totally separate I can't see that you'll run into problems (at least, not theoretical ones).

Paul. Received on Mon May 10 2004 - 14:24:31 CEST

Original text of this message