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.