Re: MV Keys
Date: Wed, 8 Mar 2006 12:00:12 +0200
Message-ID: <dum9vg$e4e$1_at_emma.aioe.org>
"Jon Heggland" <heggland_at_idi.ntnu.no> wrote in message
news:MPG.1e78b657fc0865e1989799_at_news.ntnu.no...
> 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...
Tuple=Relation. What elements ?
> 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?
Have you heard of multiple inheritance ?
> > > 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?
Have you heard of multiple inheritance ?
> > 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!
Have you heard of multiple inheritance ?
> > > 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-
> relation-type-with-special-syntax?
Why would you design a procedure that only works on singleton relations ?
> > 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?
What stop you to do the same if you only have relations and domains ? Maybe you want to be able to define the domain operators needed to do that. For example how would you implement the operator "the third character of this string".
> > 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?
Ada allow that. PL/SQL allow that. MS VB allow that. ... Aren't functions a particular kind of relation ? ;-)
> > 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!
And he/it will get them. All he/it have to do is ask. Received on Wed Mar 08 2006 - 11:00:12 CET