Re: MV Keys

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

Yes, of course. But you say that an *element* of a relation is also a relation---which by definition also have elements that are relations that have elements that are relations...

To recap, with a concrete example: You said

> Relation: a subset of a product of sets
> Tuple: a subset of cardinality 1 of a product of sets.

Given sets I { 1, 2 } and C { a, b }.
The product is { (1,a), (1,b), (2,a), (2,b) }, right? A possible relation is then R { (1,b) }, right? This relation is also a tuple by your definition, right?

So I ask: What do you call an element of a relation? For example the sole element of R, which is (1,b)? You say:

> "Tuple," "element" and "relation" all seem valid to me.

Yet (1,b) is obviously not a relation, and equally obviously not a tuple by your definition! It is not the subset of anything, because it is not a set. Do you still not see the problem?

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

Perhaps not, but I ask because I believe specifying this will help reveal either the flaw in my thinking, or the one in yours.

> But since you asked,
> I see nothing wrong with using a tuple-specific syntax for relations
> that happen to have only one element. :-)

Even though you make a point of treating relations and tuples the same for simplicity? Seems to me that you lose whatever gain you may have had.

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

I don't see what that has to do with it. Don't you agree that the ability to specify relation literals and tuple literals is needed?

> so this issue doesn't come up.

It did come up for me trying to understand your system.

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

But how can anyone ever get to the attributes? It's sets all the way down!

> > Anyway, what is *good* about this definition? :)
>
> It's simpler. You have fewer kinds of types. You also have
> fewer things to implement.

I think you are mixing interface/model and implementation here. But consider this example: I have a procedure that takes/wants a tuple as an argument. It only works on tuples, or singleton relations in your world. With tuple types, this is fairly trivial. Without, it seems to me you must do a lot of extra work for this to function reliably:

• Either, you must in your procedure check that the relation indeed contains exactly one element, and throw a run-time error if it doesn't.
• Or, you must at compile time check that no invocation of the procedure ever uses a non-singleton relation as an argument. That may be hard, but more importantly: You then probably have to indicate to the compiler that your procedure expects/demands a singleton relation---by using some special syntax/annotation/metadata, I guess. And if you do, what is the meaningful difference between a proper tuple type and a singleton- -type-with-special-syntax?

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

I think it's convenient, though. The definition of relation as subset of product of sets fails to mention attribute names and types, the difference between set product and relation product, the lack of ordering of attributes, the equality (or lack thereof) of empty relations... You need a *lot* of extra explanation.

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

That's neither here nor there, IMO. When defining what a relation is, I don't want to have to think about programming language implementations. Anyway, this is not a big issue for me; I am far more skeptical to relations defined as sets of relations (of the same type).

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

Compare it to another string? Put it into a variable of type String? Examine its third character?

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

So you envision a system where the arguments to a function are identified by name, not position?

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

If the decomposition is impossible, how can your function do anything useful with its parameter? It can apply other functions, true, but in the end, someone/something must be able to get at the attribute values!

-- 
Jon