Re: MV Keys
Date: Thu, 2 Mar 2006 17:44:50 +0100
In article <1141311212.487197.167020_at_t39g2000cwt.googlegroups.com>,
> What is the advantage if any of this functional mapping (one-one, where
> an attribute maps to a single value) over the more general
> mathematical-relational mapping (where an attribute may map to many
> Is this just so the resulting constructs can be visualised as nice neat
> regular tables? I am yet to hear any other reasons, but I don't
> preclude their existence. Does it unduly affect the algebra somehow?
It depends on precisely what you mean. If you envision a relational-like model where each "cell" (speaking loosely) can contain several values, several questions arise (to me, at least):
Is (apples, pears) equal to (pears, apples)? Or to (apples, apples, pears)?
Should the last one even be allowed?
The answers to these questions determines what the data type of my cells *really* is---it is definitely not fruit, but is it list, set or bag of fruit? Or shouldn't we care enough about strong typing to distinguish between a value and a singleton set (list, bag...) containing said value?
Should we support different kinds of collections in our multi-valued cells? Should they then be comparable? How should we then define equality between them?
And so on.
If you instead say that a "cell" can and must contain exactly one value, *but* that value may very well be a list, or a set, or a relation---then there are no problems (in theory). The algebra is not affected at all--- except if we want to support (e.g.) RVAs with GROUP/UNGROUP operators and stuff like that. Textual tabular presentation of relations becomes more tricky/messy, but not impossible.
-- JonReceived on Thu Mar 02 2006 - 17:44:50 CET