Re: MV Keys

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.

> > What definition of subtype
> > would you care to use? Consisder the defintion of a relation:
> > doesn't a tuple qualify?
>
> 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.

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

> > > The operators
> > > of the respective type kinds are also rather different, of course.
> >
> > Can you be more specific? What different operators are there?
>
> (Note that I'm talking about a specific DBMS here; I don't claim this is
> universal truth.)
>
> * 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.

> * 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 would have to say that the above distinctions are a *consequence* of deciding that tuples and relations are different, and not a cause.

Marshall Received on Tue Mar 07 2006 - 09:28:20 CET