Re: MV Keys

In article <1141742402.182770.192620_at_z34g2000cwc.googlegroups.com>, jog_at_cs.nott.ac.uk says...
> > Why should the RM be concerned whether something is a compound type or
> > not?
>
> This seems very clear to me. But perhaps it highlights we may have
> different definitions of what a compound type is. If the RM is not
> concerned then you are saying that some other meta-layer is responsible
> for decomposing these types no? Something similar to SQL's string
> processing functions or arithmetic functions?

Yes.

> Let me explain - to me a string is not a compound datatype. Yet I can
> perform a join against a foreign key which is equal to the 1st letter,
> say, of a string from some other column. I have broken down that string
> to make that match - as far as I currently understand your logic that
> is the exact same process you are talking about with sets, lists and
> bags?

Yes.

> If so then we are talking at cross-ends because that is then not
> a compound-datatype in the sense that an RVA is.

Because by definition, only relations are "natively understood" by the relational engine? Still, I don't see what difference it makes.

> > > Well, clearly its just my distinction, but a multi-attribute system is
> > > one where attribute names map to more than one value,
> > This definition is imprecise and under-specified. When you talk about
> > attribute names mapping to one or more values, do you mean within the
> > context of a single tuple?
> > Or do you mean "attribute name" in another
> > sense than I interpret it (I.e. as "column name"), e.g. as in "objects"
> > with attributes?
> [snip]
>
> No, the description is fine - a mapping has a formal mathematical
> definition as does an attribute as far as RM is concerned.

"Attribute" has several; that was my problem.

> An RM-tuple represents a mapping of the form:
> { (attribute_1, value1), (attribute_2, value2), ... }
> and an RM-relation is a set of these tuples. There is a one-one
> corresponce with attributes and their values, and hence this mapping is
> a function. I am suggesting a 'multi-attribute' system (or whatever you
> would like to call it) is not constrained to this one-one mapping, and
> hence tuples may be of the form:
> { (attribute_1, value1), (attribute_2, value2), (attribute_2, value3),
> ... }.
>
> This is distinct from a 'compound-datatype' system which would be
> something such as:
> { (attribute_1, {value1}), (attribute_2, {value2, value3} ), ... }.
>
> Both approaches as I understand it fall under the umbrella of MV.

I see. Are there any implementations that use this approach?

-- 
Jon