Re: MV Keys

In article <1141662881.772158.68960_at_j52g2000cwj.googlegroups.com>, jog_at_cs.nott.ac.uk says...
> > > Because some appear to be missing this point, and hence confusing
> > > actually what a compound type is. A comma seperated string, for
> > > example, sitting in a relational database is hardly a compound type as
> > > far as the RM is concerned. It is merely a string.
> >
> > 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?

> > > Perhaps you're still
> > > confusing a multi-attribute system with a system that supports compound
> > > data types?
> >
> > Perhaps. What is the difference, in your opinion?
>
> 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?

And I don't understand how you can talk about "more than one value" without specifying how these multiple values are organised---as a set, bag or list? I am under the impression that in Pick (which I am led to believe is an archetypal MV system), it is a list---i.e. you can specify the order; the order is preserved; and duplicates are allowed.

> > > > That doesn't make sense to me. Compound attributes are valid if the
> > > > system can decompose them, and if the system can't decompose them,
> > > > they're not compound?
> > >
> > > Yes. What about that doesn't make sense to you?
> >
> > It is an overly complicated way of saying that compound attributes are
> > by definition always "valid". What, then, is the point of making the
> > distinction between simple and compound?
>
> It doesn't mean that at all.

Perhaps that's not what you meant, but it is what you said. Below, don't you say that if there are no "decomposition operators", the type is not compound (and hence not a problem for the RM); and if there are such operators, it is also not a problem for the RM?

> It is stating that one cannot talk about
> items that we view in our heads as "compound" (sets say) being plugged
> into a model without explaining how the type will be manipulated by the
> algebra underpinning the system. Ignore this and as far as I can see
> you no longer have a compound datatype at all.

Well, yes. A type must have operators in order to be of much use---but the way I see it, the relational algebra (RA) doesn't care, as long as there exists an equality operator.

> I understand this appears a truism, but I worry it is being neglected
> in some of the MV debate- this is why it is so easy to get into
> tangential discussion about whether a string or an int is actually a
> compound datatype, which of course goes nowhere. An example maybe - a
> system using the relational algebra can only feasibly have RVA's as
> possible compound datatypes period.

I disagree, because I don't think the operators for manipulating types are necessarily a part of the relational algebra as such. The algebra engine must be capable of invoking such operators, of course---but the don't have to be system-defined. Is (numeric) addition part of the RA? Dataphor uses the RA, and it has lists as compound datatypes. Or do you claim that is does *not* use the RA, *because* it supports lists?

-- 
Jon