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.

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.

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