Re: relations aren't types?

From: John Jacob <jingleheimerschmitt_at_hotmail.com>
Date: 27 Dec 2003 21:02:47 -0800
Message-ID: <72f08f6c.0312272102.59fc0e54_at_posting.google.com>


> > Given a unary relation over some type, we could certainly invoke an
> > operator with a single scalar-valued parameter using a conversion, and
> > perhaps the compiler could even make it implicit as a short-hand. We
> > could also generalize the notion and allow tuples and relations to be
> > used as arguments to operators with multiple parameters, with binding
> > occurring by name.
>
> The TTM already allows that.

Let me give a concrete example.

create operator Foo(const AString : String, const ADate : Date) begin
  ...
end;

create table InvokeWith { AString : String, ADate : Date, key { AString } };

Foo(InvokeWith where AString = 'A');

While implicit conversions such as these are not explicitly prohibited by TTM, they are certainly not encouraged, and I would argue they are definitely against the spirit of TTM.

> From the perspective of a relation, its relation valued attributes are
> opaque. Those attributes have operations defined that operate on values of
> the attributes' types--that's all the relational model cares about.

Even when a relation type is used to define an attribute of another relation type, it is still not a scalar type. When you say opaque, I assume you mean scalar. If you do not, then we need some clarification of terms.

> > As an example of a unary relation variable over a "non-atomic" type,
> > consider TimeOfDay.
>
> TimeOfDay is just as atomic as any other type. It has values and operations.

TimeOfDay is not a type, as I said it is a relation variable with a relation type having a single attribute of type Time. At any given moment it has a relation value with precisely one tuple, containing the value of the current time for it's single attribute TimeOfDay.

create table TimeOfDay { TimeOfDay : Time, key { } };

Clearly this would be a system-defined relation variable whose value was materialized on request, but conceptually, it is as valid as any other relation variable. It was intended as a counter-example to Marshall's statement that there was no value in defining a unary relation variable over a "non-atomic" type. Again, I am assuming that atomic means scalar. Of course, Time is a scalar type, but it is an excellent example of a scalar type with a compound representation.

> There is a difference between defining generic operations and defining
> attributes with generic types. The only attribute mentioned in your example
> has a type of DateTime, which is quite specific. You have described a
> generic operation that operates on any generic relvar with a LastUpdated
> attribute. You have not provided an argument favouring any attribute with a
> generic type.

Agreed. Would you object to a relation with an attribute of type Alpha?

> > At least one advantage is brevity. This could certainly be claimed as
> > an implementation advantage, but it is an important one. Indeed, I
> > argued above that in order to realize this behavior, both concepts are
> > necessary. While I do think that allowing implicit conversions of
> > this type could be extremely useful in a database language, it must
> > never be done at the expense of a more primitive behavior, and it must
> > be done extremely carefully to avoid destroying the primary reason for
> > types in the first place, namely semantic verification.
>
> Brevity at the expense of integrity or of clarity is a fool's bargain.

These proposals certainly do not sacrifice integrity. I fail to see how integrity is relevant at all to the discussion. As for clarity, what specifically do you see as the disadvantages of the proposals given? Received on Sun Dec 28 2003 - 06:02:47 CET

Original text of this message