Re: MV Keys

Jon Heggland wrote:
> marshall.spight_at_gmail.com says...
> >
> > "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......?

Not that I can see. A subset of a relation is a relation; the non-proper
subset is also a relation, etc. Doesn't cause any problems.

> How does a relation
> literal look like in your world? Or a tuple literal, for that matter?

I don't think the syntax matters, particularly. But since you asked, I see nothing wrong with using a tuple-specific syntax for relations that happen to have only one element. :-)

> 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". :)

As I mentioned in another post, the RA doesn't have any operations on elements, so this issue doesn't come up. The operations on tuples that are sometimes described are just special cases of the relational operations; they may be discarded without loss of generality. Operations on attributes are as they ever were; specific to the attribute type and not part of the RA.

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

It's simpler. You have fewer kinds of types. You also have fewer things to implement.

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

"Some connection" is fine; having a value, which is a runtime concept, require a type as a subcomponent, which is a compile-time concept, is not necessary. It's not unsound, but it's not required, either. Note that plenty of successful programming languages discard all type information prior to the start of a program run. This can even be done in safe languages.

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

The runtime type of a Java class is not the same thing as the static type of an expression. In the strictest sense of of the word "type", the result of getClass() is not a type; it's a runtime tag. Few people use this strict of a terminology, but it has some value in that it emphasizes the distinction between compile-time/static properties and runtime/dynamic properties. They are not the same.

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

Okay, so you've drawn a distinction here between the nonrelational operator of extracting the singleton attribute value from a tuple vs. a relational projection that results in a tuple of just one attribute with
that same value.

So, what are you going to do with this string now that you've got it? You might pass it to a function. And what do the arguments to a function look like? Hmmm. A set of named attribute values. So we reconstitute it into a tuple and then apply the function.

Why did we bother to decompose the tuple, only to reconstitute it? What did we gain?  

Marshall Received on Tue Mar 07 2006 - 20:38:47 CET