Re: MV Keys

Jon Heggland wrote:
> 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?

I don't follow your question.

>
> > 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, and a compound datatype system is one that supports single values that may be decomposed (and the sytem must support this decomposition). Traditional RM is neither. Implementing RVA's in RM allows it to become the latter, while the former (multi-attributes) are strictly forbidden by Codd in the RM period.

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

It doesn't mean that at all. 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.

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.

>
> > 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
Received on Mon Mar 06 2006 - 17:34:41 CET