Re: MV Keys

In article <1141746088.470141.73280_at_j33g2000cwa.googlegroups.com>, marshall.spight_at_gmail.com says...
> 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.

Maybe I'm being dense here, but doesn't that entail that a relation is a set of set of set of set of set of set of......? How does a relation literal look like in your world? Or a tuple literal, for that matter?

Let's see: A tuple is a singleton set, say { X }. Its element, X, is a tuple, which again is a singleton set, say { Y }. Hence, the tuple is really { { Y } }. And what is Y? A tuple, which is a singleton set, say { Z }---so the relation really is { { { Z } } }... Maybe I don't fully understand the finer points of recursion, but this is what I mean by "difficult to understand". :)

Anyway, what is *good* about this definition? :)

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

I brought this up to justify Date including the heading in his relation definition. A value must have some connection to its type; I don't see why this way is so bad. In Java, you can call getClass() on any object; so isn't the type (~= heading) part of its value? What alternative mechanism for this do you suggest?

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

var RowVariable := row { "Jon" FirstName, "Heggland" LastName }; select RowVariable.FirstName;
// Column extraction; result is a String "Jon" select RowVariable over { FirstName };
// Tuple projection; result is a row { "Jon" FirstName }

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

No, the type of the result is also different, as shown above. I realise, though, that you can define column extraction on relations (with cardinality one), but you then have to be able to check statically that its cardinality is never anything but 1 in order for it to provide the same functionality as row types. I think that is probably more trouble than it is worth (what does that buy you, really?), if it is at all possible---but I have never implemented a DMBS, so I can't say for sure. :)

-- 
Jon