Re: relations aren't types?

From: Bob Badour <>
Date: Fri, 26 Dec 2003 13:21:40 -0500
Message-ID: <>

"Marshall Spight" <> wrote in message news:y8_Gb.205873$_M.909925_at_attbi_s54... > "Bob Badour" <> wrote in message
> > "Marshall Spight" <> wrote in message
> > news:FXFFb.177009$_M.808167_at_attbi_s54...
> > > > >
> > > > > I have to agree. I don't see any logical difference between a row
> > > > > in a relation and an object. (Alternatively, between a relation
> > > > > heading type and a class.)
> > > >
> > > > One has transparent structure and generic operations while the other
> > > > opaque structure and specific operations. You really see no logical
> > > > difference? The differences glare at me.
> > >
> > > I see no *logical* difference between transparent structure and opaque
> > > structure. That's an implementation detail.
> >
> > We are talking about logical structure in tuples and relations not
> > structure so the transparency or opacity is a logical feature.

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

Except that they are not identical. One is a unary relation over a single named attribute and the other is an n-ary relation over n named attributes.

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

TTM does not assume it. TTM insists on it just as the relational model insists on it, and this includes the types of relation valued and tuple valued attributes.

Your claim amounts to a claim that discarding physical independence improves the model. Doing so does not improve anything.

> Put another way: I don't see the value to user-defined opaque > types.

Physical independence.

> Clearly the system has to have a few opaque types:
> int, float, relation are necessarily opaque. But if one is
> interested in data management, then one should not have
> opacity: you can't manage what you can't see.

When one manages data, one wants to see data and not internal implementation.

> If I'm missing something, please let me know.

Physical independence.

> > Keep in mind that each tuple and each relation does have a type, and one
> > have tuple-valued and relation-valued attributes. The key question is
> > whether one can have generic tuple-valued or generic relation-valued
> > attributes. I suggest the principle of cautious design should deter us
> > pursuing generic attributes until we know more about the effects of
> > them.

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

The relational model already supports generic types. The question is whether to support generic types in relation variable attributes. I suggest doing so would weaken the type system, and it is not clear to me it would provide any compensating benefit for the loss.

> > > Simple example: a Point relation with int x, int y columns vs.
> > > a unary relation on a tuple-type with attributes int x, int y.
> > > What's the logical difference?
> >
> > One has a single attribute (for which you forgot to specify the name)
with a
> > tuple type and the other has two numeric attributes. One can convert
> > one into the other, but this requires an additional operation.
> I say: why bother with the conversion?

Because they are logically different, a conversion is required.

> Why not just declare the two
> cases as identical?

Why not declare strings and integers identical and avoid all those pesky conversions too? Do you see the absurdity? Received on Fri Dec 26 2003 - 19:21:40 CET

Original text of this message