Re: MV Keys

In article <1141412132.778340.104120_at_i40g2000cwc.googlegroups.com>, jog_at_cs.nott.ac.uk says...
> Jon Heggland wrote:
> > In article <1141387926.092588.82100_at_v46g2000cwv.googlegroups.com>,
> > jog_at_cs.nott.ac.uk says...
> > > A crucial point is that this is only true if the system offers a
> > > mechanism to perform the decomposition. If it does not, then to the
> > > system itself your compound datatype is a single value.
> >
> > Why is this crucial?
>
> 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?

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

> > > This is the reason that nested relations is a valid approach within
> > > traditional RM - a compound datatype with a mechanism for its
> > > manipulation.
> >
> > 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?

> In the system marshall
> is involved with I'm sure his list/set constructs will be provided with
> mechanism for their manipulation and for extraction of individual
> values.

Yes, I don't see how they can be of any use otherwise. How can you possibly envision a (collection) type without operators/manipulation?

-- 
Jon