Re: MV Keys

Jon Heggland wrote:
> 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):
> [ ruthless snip]

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

Neither of these. I was referring to a case where specifiying an attribute-name may map to more than one "cell" as you refer to it. i.e. not a one-one functional mapping but a generalised one-many mapping. However I think the answer to my question anyhow is that it generates direct complications for the join mechanism, and that will require mulling and tea (what doesn't eh?).

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

Well this has to be specified to the system as with all equality matches. Is 15.0 equal to 15? Is "HELLO" equal to "Hello"? How is a date greater or less than another? These subjective equality decisions are already being made in numerous domains without significant issue..

In a sense this is no different in nature to something such as a C++ sort template where one has to specify a comparison function. Here, when a type is created one can define how comparisons are made, and I don't see a problem there. Received on Thu Mar 02 2006 - 18:30:28 CET