Re: relations aren't types?

"Marshall Spight" <mspight_at_dnai.com> wrote in message news:hX1Hb.658122$HS4.4681246_at_attbi_s01...
> "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.

No, Marshall, the reasoning is not circular. How many named attributes does the unary relation have? How many named attributes does the n-ary relation have? Is degree a logical attribute of a relation? Is the degree the same for the unary relation as for the n-ary relation?

> The question (at least, what I consider to be
> the question) is whether they should be considered logically the same
> or not.

They are not logically the same. Considering them logically the same would not make them logically the same and would only confuse people just as you are confused right now.

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

If they are the same, how could the degrees differ?

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

No, it will not. A unary relation has only one attribute and that attribute has a name. Even if that attribute represents a tuple type or a relation type, the unary relation still has only one attribute, and it must have a name. The relation is logically similar to all other unary relations in respect of degree. You now want to say that some unary relations are logically similar in degree to unary relations and others are logically similar in degree to n-ary relations where n > 1. What, if not the internal structure of the attribute, makes the unary relation logically similar in degree to n-ary relations where n > 1?

A unary relation with a tuple-valued attribute has a named attribute whose name is not necessarily the same as any relvar name and is not necessarily the same as any attribute name in the set of attributes defined for the tuple type. An n-ary relation with attributes corresponding to the n attributes of the unary relation's n-ary tuple-valued attribute has no such name. To manipulate the value of an attribute in the unary relation's tuple-valued attribute, one must use some operation defined for the tuple type and referencing the unary relation's single attribute name.

> How is physical independence improved by requiring all user
> defined types to be atomic?

Do you understand what atomic means and that a tuple-valued attribute is atomic? To the dbms, a tuple-valued attribute has a single value. The type defines operations by which one may derive other values. These operations include operations for each component of each possible representation.

> The atomicity of such types is
> simple an implementation artifact

No, it is inherent to the logical model, and is (or should be) totally independent of the physical implementation. Regardless of the implementation, a tuple-valued type represents a single value--consider it a single point in an n-space if that helps you.

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

No, they are not any less manipulable. One has operations by which to manipulate the values.

> So the physical independence
> argument is actually *against* opacity.

You are confused.

> Put another way: what's something you can accomplish with
> atomic user-defined types that you can't accomplish with
> transparent user-defined types?

Physical independence. I already pointed that out. Why do you make me repeat myself?

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

Since all values are atomic, your statement is essentially meaningless. What would one see instead of a value if attributes do not contain atomic values?

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

Your proposal exposes physical structure. If your proposal did not, the type would be opaque and atomic just as the relational model requires.

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

Not at all. You simply continue to ignore the extra name you omitted in the first place. Please do not expect anyone to find such a straw many convincing.

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

Look again.

> Strings and integers support a different
> set of operations

A single tuple-valued attribute supports a different set of operations than n independent attributes.

>, and there is no sensible semantics associated
> with combining them.

Just as there is no sensible semantics associated with pretending a unary relation is an n-ary relation or vice-versa. What would the degree operation return, for instance?

> Addition on strings, for example, makes
> no sense.

Addition on tuples, for example, makes no sense either.

> But the semantics I'm proposing are both straightforward
> and useful.

What exactly are those semantics? How does the name of the unary attribute come into play in your proposal? What does the degree operation return for a unary relation? For an n-ary relation? You have simply ignored the semantics and pretended there is something useful.

> (And anyway, integers are necessarily atomic
> types, although strings are not.)

Strings are atomic types. All types--including strings and integers--have multiple possible representations that each have internally representable structure. One possible representation of an integer is an array of bits and another is an array of octets. One possible representation of a string is the number representing its position in a well-defined collation of all valid strings. How is an integer any more atomic than a string? Received on Sat Dec 27 2003 - 07:22:33 CET