Re: RA with MV attributes

Marshall wrote:
> On Jan 16, 4:48 pm, "David" <davi..._at_iinet.net.au> wrote:
> > 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.
>
> The calculation of the result type can be performed knowing only
> the operand *types* and not the operand values. Yes, this could
> be deferred to runtime, but it doesn't have to be, and if it is, the
> same calculation will be done, with the same result, at every run,
> whereas the calculation could be performed just once, statically.
>
> Furthermore you will find that this property holds true of many
> functions over generic types. Consider a simple generic list
> type supporting a "get first element" operation. The type of
> the generic list is parameterized by the element type T.
> The type of getFirstElement() is int -> T. Hence the getFirstElement
> operation could also be said to "calculate the type" but if you
> code this up in, say, C++, the type calculating occurs entirely
> at compile time.
>
>
> > 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".
>
> That doesn't work for me. In 2, your proposal only considers
> abstract, parameterized type "relation" and doesn't consider
> concrete relation types.

1 & 2 are saying *by definition* there is a type called "relation".  It is neither abstract nor parameterised.

Why can't we say that *by definition* the set of attributes of a relation is part of its state not its type?

Here's an analogy. A C++ library provides a matrix class that is not parameterised on the number of rows and columns. You can write this

    void foo(int n,int m)
    {

        Matrix A(n,3), B(3,m);
        Matrix C = A * B;       // Size = n x m

The non-parameterised type also allows for mutative operations that add or remove rows and columns.

> In 4, you draw a distinction between
> a set of tuples and a relation, but those are equivalent as far
> as I know. Can you explain the distinction?

4 follows from 1 which is a definition of the type "relation". My point is that it is self consistent.

Consider this: In mathematics a function is defined on a particular domain and codomain. Restrict the domain and you have a *different* function. Otherwise we can't make statements about whether a given function is 1:1 or onto. This suggests that domain and codomain should be regarded as *properties* of a given function. A similar thing seems to be true for a relation - it is more than its set of tuples. Note in any case that I defined a tuple to be a mapping on A(r), so therefore you can't really disconnect the tuple from the set of attributes anyway.

> > 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.
>
> Well, the term "strong typing" is fraught with peril, but assuming
> you mean "static typing" then I don't see why you think this
> would be an issue. Consider that a CREATE TABLE statement
> specifies the type of relvars.
>
>
> > 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.
>
> I think you will find that *every* language with a ? : operator
> does not allow the two possible results to have incompatible types.

That's my point. That's why it seems better to have a non-parameterized type called "relation". Received on Wed Jan 17 2007 - 03:51:57 CET