Re: MV Keys

In article <1141311212.487197.167020_at_t39g2000cwt.googlegroups.com>, jog_at_cs.nott.ac.uk says...
> 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
> values)?
>
> 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?
> Anyone?

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):

Join is crucial, and depends on equality between "cells". But with multiple values, how do you define equality?

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.

-- 
Jon