Re: relations aren't types?

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

That's circular reasoning. The question (at least, what I consider to be the question) is whether they should be considered logically the same or not. One cannot effectively argue that question simply by asserting that they are not the same. Consider: I could just as well assert that they *are* the same.

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

On the contrary: this will improve physical independence.

How is physical independence improved by requiring all user defined types to be atomic? The atomicity of such types is simple an implementation artifact, and the visibility of such a thing at the logical level is the antithesis of physical independence.

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

If user defined types are opaque, they are necessarily less amenable to manipulation. So the physical independence argument is actually *against* opacity.

Put another way: what's something you can accomplish with atomic user-defined types that you can't accomplish with transparent user-defined types? Answer: nothing. What's something that can be accomplished with transparent UDTs that can't be accomplished with atomic UDTs? Answer: they can be recombined to create new types.

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

Exactly. That's why the attribute of atomicity should not be visible at the logical level.

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

I think for that phrase to be a convincing argument, you have to demonstrate that some aspect of physical independence is lost by my proposal.

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

Again: circular.

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

I see the absurdity with your example, but I do not see any way to relate it to my idea. Strings and integers support a different set of operations, and there is no sensible semantics associated with combining them. Addition on strings, for example, makes no sense. But the semantics I'm proposing are both straightforward and useful. (And anyway, integers are necessarily atomic types, although strings are not.)

Marshall Received on Fri Dec 26 2003 - 22:42:38 CET