Re: relations aren't types?

"Marshall Spight" <mspight_at_dnai.com> wrote in message news:y8_Gb.205873$_M.909925_at_attbi_s54... > "Bob Badour" <bbadour_at_golden.net> wrote in message news:1NCdnXt3dKvOR3qi4p2dnA_at_golden.net...
> > "Marshall Spight" <mspight_at_dnai.com> 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
has
> > > > 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
physical
> > 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.

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
can
> > 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
from
> > pursuing generic attributes until we know more about the effects of
allowing
> > 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
either
> > 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