Re: MV Keys

In article <1141720100.794765.5770_at_e56g2000cwe.googlegroups.com>, marshall.spight_at_gmail.com says...
> Jon Heggland wrote:
> > marshall.spight_at_gmail.com says...
> > >
> > > But isn't a tuple a subtype of a relation?
> >
> > Not according to the definitions I prefer. I feel uncomfortable with the
> > circularity this would entail: That a relation is a set of relations(?).
>
> Relation: a subset of a product of sets
> Tuple: a subset of cardinality 1 of a product of sets.
>
> Seems like a subtype to me. Every place a relation value
> could be used, a tuple value could be used instead.
>
> Note there is no circularity required.

Ah, so a relation is not a set of tuples? What do you call an element of a relation, then?

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

> > That depends on which definition you consider "the" definition. I like
> > Date's: A relation consists of a heading (a set of attribute name /
> > domain pairs), and a body, which is a set of tuples conforming to the
> > heading. A tuple is a set of attribute name / domain / value triplets.
>
> That definition includes the type as part of the value. The relation
> heading is not part of the relation value, no more than "int" is
> part of 1. The heading is associated with the value, but it is
> not a part of the value per se.

Fair enough, but you have to specify the heading *somewhere*. A relation literal must necessarily somehow include attribute names (and types, but that is easier to do implicitly). Where/how do you do it?

> > As for subtypes, I'm undecided. I like the TTM subtype definition
> > (subset; specialisation by constraint) because it is clean, precise and
> > sound---but it seems a bit useless in practise. :)
>
> Well, the "subset" part certainly applies.

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.  

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

> > * Tuples also have a join operation that is different from the relation
> > join: If you join two singleton relations, you get a relation with zero
> > or one tuples, depending on whether the common attributes (if any) have
> > the same value. When you join two tuples, you get a run-time error if
> > there are any common attributes that don't have the same values.
>
> Same problem here.

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.

-- 
Jon