| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
Home -> Community -> Usenet -> comp.databases.theory -> Re: Data Display & Modeling
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.
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 - 07:24:31 CDT
![]() |
![]() |