Re: MV Keys

From: JOG <jog_at_cs.nott.ac.uk>
Date: 7 Mar 2006 06:40:02 -0800
Message-ID: <1141742402.182770.192620_at_z34g2000cwc.googlegroups.com>


Jon Heggland wrote:
> In article <1141662881.772158.68960_at_j52g2000cwj.googlegroups.com>,
[snip]
> > >
> > > What difference does it make to the RM?
> >
> > I don't follow your question.
>
> 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?

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? If so then we are talking at cross-ends because that is then not a compound-datatype in the sense that an RVA is.

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

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.

All best, Jim. Received on Tue Mar 07 2006 - 15:40:02 CET

Original text of this message