Re: relations aren't types?

"John Jacob" <jingleheimerschmitt_at_hotmail.com> wrote in message news:72f08f6c.0312262346.18755d7c_at_posting.google.com...
> > My thinking on this issue has changed a bit. Now it strikes me that the
> > important question is: what is an atomic type? It does not make
> > sense to have a unary relation over an unnamed atomic type. But
> > considering a unary relation over a non-atomic type to be logically
> > identical to an n-ary relation over the named subcomponents
> > of the type strikes me as quite a valuable idea. The fact that the
> > subcomponents already have names makes it easy.
>
> 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.

> > It is clear that system-defined types like int, char, and float
> > are atomic. What's not so clear is whether user-defined types
> > will be atomic. TTM seems to assume that they will be; I
> > claim it is better if they aren't.
> >
> > Put another way: I don't see the value to user-defined opaque
> > types. Clearly the system has to have a few opaque types:
> > int, float, relation are necessarily opaque.
>
> Relation is not an opaque type like int and float. In order to deal
> with values of a given relation type, I need to know the attributes of
> the type, in general.

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.

> > But if one is
> > interested in data management, then one should not have
> > opacity: you can't manage what you can't see. Because of
> > this, I propose that all user-defined types *must* be transparent
> > and not opaque. If that's so, then it makes sense to consider
> > a relation as a generic type that can be parameterized with
> > a *single* user defined type, which specifies the named
> > attributes of the relation.
>
> What about types like DateTime and TimeSpan. Clearly there is value
> in defining a type whose possible representation includes multiple
> components, each with an arbitrary type. We could certainly define a
> language which did not allow user-defined types and only allow the
> user to define relation types over a pre-determined set of native
> types (int, float, string, maybe even DateTime) but we take the
> extremely presumptious position that we have correctly identified the
> only possible native types of value to the user. I would prefer to
> see a language that, like Tutorial D, allowed the user to define any
> type of interest, and let them make the decision about what should be
> modeled as a type, and what should be modeled as a relation variable.
> 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.

> > I'm less cautious. It strikes me that languages with support for generic
> > programming have had substantial success, and I see no reason to
> > believe their success won't transfer to a relation-centered language.
>
> Not only do I agree, but I believe that there is a huge benefit to
> doing so. For example, I could define an event handler (trigger)
> which updated a column named LastUpdated to the current date and time.
> If the operator handling the event takes only a generic tuple as a
> parameter, the handler can be written generically and attached to any
> relation variable having at least an attribute named LastUpdated of
> type DateTime.

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.

> > I say: why bother with the conversion? Why not just declare the two
> > cases as identical? I don't see any advantage to distinguishing between
> > the two cases. (Maybe there is an implementation advantage.)
>
> 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. Received on Sat Dec 27 2003 - 23:51:50 CET