Re: MV Keys

From: Marshall Spight <marshall.spight_at_gmail.com>
Date: 7 Mar 2006 07:41:28 -0800
Message-ID: <1141746088.470141.73280_at_j33g2000cwa.googlegroups.com>


Jon Heggland wrote:
> marshall.spight_at_gmail.com says...
>
> Ah, so a relation is not a set of tuples? What do you call an element of
> a relation, then?

"Tuple," "element" and "relation" all seem valid to me. A tuple meets the definition for a constrainted kind of relation, unless you specifically
define it not to. I am not 100% confident that this works, but so far I haven't been able to find a reason why it won't, and I've put some effort into trying.

> And where do the attribute names and domains come into this definition?
> Do you use attribute ordering and typeless sets?

Nah, I'm a static type weenie. I like the named and typed attributes. But I actually don't think that particular question affects the tuple/relation
schism question.

> Well, given your definition, I agree that tuple is a subtype of a
> relation. It is just the question of whether I think your definition is
> good or not.

I agree that that is the important question!

> > > * Tuples have an operator (Column Extraction) that returns a value,
> > > given an attribute name. Note that this is not the same as projection:
> > > projection on relations returns a relation, and projection on tuples
> > > returns a tuple (disregarding the fact that tuples and relations are
> > > also values; I hope you know what I mean).
> >
> > The distinction drawn here, between tuple projection and
> > relation projection, depends on the idea that tuples and
> > relations are different, so we can't use *that* to decide if
> > tuples and relation are different or we'd be assuming the
> > conclusion.
>
> I didn't mean to draw the distinction between the two projections, but
> between Column Extraction and projection. A Column Extraction would fail
> run-time if used on a relation with cardinality other than 1. Tuple
> types means I (and the system) don't have to worry about this.

Why do you need both ColumnExtraction and Projection? I don't see what it buys you. If you know, statically, that a given relation has cardinality 1, then you know, statically, that a projection of that relation will also have cardinality 1. Isn't that all that the column extraction operator does?

> I did say this was pragmatical, not theoretical. I have no doubt that
> you can implement a system where tuples are singleton relations, but I
> also believe that such a system would be more difficult to both use,
> understand and implement than one where the distinction is drawn.

I believe the opposite! However it's important to get the design right. Also, my claim is still unproven.

Marshall Received on Tue Mar 07 2006 - 16:41:28 CET

Original text of this message