Re: relations aren't types?

"John Jacob" <jingleheimerschmitt_at_hotmail.com> wrote in message news:72f08f6c.0312272102.59fc0e54_at_posting.google.com...
> > 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.

Define a scalar type. The relation value in the attribute for each tuple is a single value with defined operations. How does that differ from an integer?

> > > 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.

Sorry. Time is just as atomic as any other type including relation types.

> > 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?

I cannot remember: Is alpha the type with an empty set of values and the entire universe of operations? Or is alpha the type with the entire universe of values and the empty set of operations?

I see no use for relvars with attributes of type alpha or omega, but I have no particular objections to relations with such attributes.

> > > 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?

Implicit type conversions between tuple-valued types and independent attributes? You don't see how that sacrifices integrity and clarity? I can only conclude you don't want to look for it.

I once worked on a C++ project where the lead developer adopted a naive String class (in the bad old days before STL) that had a cast operator or constructor that would convert any common type to a string and vice versa--in the name of brevity. In a long block of s += ... statements to build a dynamic SQL command, there was one s =+ ... statement.

s += ...;
s += ...;
s =+ " FROM "; // s == "0" after this statement s += ...;
s += ...;

The code compiled without a warning, and it was not at all clear to the lead developer why it wouldn't give a compile error. Received on Sun Dec 28 2003 - 10:28:14 CET