Re: relations aren't types?

From: Alfredo Novoa <>
Date: 23 Dec 2003 04:32:59 -0800
Message-ID: <>

"Bob Badour" <> wrote in message news:<>...

> Keep in mind that each tuple and each relation does have a type, and one can
> have tuple-valued and relation-valued attributes. The key question is
> whether one can have generic tuple-valued or generic relation-valued
> attributes. I suggest the principle of cautious design should deter us from
> pursuing generic attributes until we know more about the effects of allowing
> them.

IMO they should be allowed, and the question is when to use them. I suggest the principle of minimal effort.

The only good use of relation valued attributes I can imagine now is something like this catalog relvar:

var CandidateKeys relation { RelVar Char, Key relation { Attribute Char } }

    key { RelVar, Key }

We would need aditional integrity constraints, but it could be a good starting point.

> What would a generic operation entail for a specific type? It does not seem
> to make sense to me. Can you give an example?

The only I can imagine are the THE_ operators.

> > Simple example: a Point relation with int x, int y columns vs.
> > a unary relation on a tuple-type with attributes int x, int y.
> > What's the logical difference?
> One has a single attribute (for which you forgot to specify the name) with a
> tuple type and the other has two numeric attributes. One can convert either
> one into the other, but this requires an additional operation.

And imagine a Points monadic relation with an attribute type Point with possrep components int x, y, z. And a "projection" over x and z. Which would be the type of the result's monadic relation attribute?

  Alfredo Received on Tue Dec 23 2003 - 13:32:59 CET

Original text of this message