Re: RA with MV attributes

David wrote:
> Marshall wrote:
> > Interesting post. Some comments inline.
> >
> > On Jan 16, 12:40 am, "David" <davi..._at_iinet.net.au> wrote:
> > >
> > > Definition: A relation r consists of a relation-type A(r) together
> > > with a set of tuples T(r), where each tuple is a map from each
> > > attribute a in A(r) to a subset of D(a).
> >
> > I realize it's becoming fashionable, but I still dislike the idea
> > that a relation "consists of" its type and its value, both.
> > It's type is its type and its value is its value; it doesn't
> > make sense to me otherwise. If we consider the relation
> > as being a combination of two things, we ought to be
> > able to consider those two things separately. In which
> > case we can ask the question, what is the type of a
> > relation's value? Presumably that is also its type, and
> > so we have infinite regress.
> >
> > Or consider how it sounds for a value of a non-parameterized
> > type: "An integer consists of a numeric-type int together with
> > an int." ???
> >
> > Yet another reason to dislike it is that it combines in a single
> > construct both a static construct and a dynamic one. It is
> > entirely reasonable to consider a system where types exist
> > at compile time and do not exist at runtime, and values exist
> > at runtime and do not exist at compile time. So how could we
> > combine them?
> >
> > Anyway, this is a diversion from your main point.
>
> I agree with your points. Note that we can't define a join on two
> relation values without access to their type information. A weakly
> typed language that allows for joins on two relations would be forced
> to explicitly store the type together with the relation-value as part
> of the run-time state. As you suggest above, a strongly typed
> language allows values to be stored without explicit run time type
> information.
>
> I regard the combination of type and value into a single construct as a
> convenience for the exposition.

After thinking about it some more I've changed my mind. The join operation needs to *calculate* the "type" of the result. Therefore it seems better to regard the "type information" as part of the relation value.

To avoid the infinite regress you should say

1.   A relation value r comprises both A(r) and T(r).
2.   The *type* of all relation values is the same:  ie "relation"
3.   T(r) on its own is not a relation value
4.   The type of T(r) is "set of tuples", not "relation"

BTW saying "r is a relation value" is naff. Really should say "r is a relation".

I presume in a proper general purpose system strong typing of relvars won't work. Having to specify the type of relvars would be painful.

It would also disallow conditional projection, such as

   relation r = test ? r1 : proj(r1,B)

...not that I have an example of where that would be useful. Received on Wed Jan 17 2007 - 01:48:58 CET