Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: relations aren't types?

Re: relations aren't types?

From: Bob Badour <bbadour_at_golden.net>
Date: Tue, 23 Dec 2003 01:01:35 -0500
Message-ID: <1NCdnXt3dKvOR3qi4p2dnA@golden.net>


"Marshall Spight" <mspight_at_dnai.com> wrote in message news:FXFFb.177009$_M.808167_at_attbi_s54...
> "Bob Badour" <bbadour_at_golden.net> wrote in message
news:DuGdncCm4O1a3Xui4p2dnA_at_golden.net...
> >
> > >
> > > 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.

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.

> Or, another way to look
> at it: "no user-visible components" is just a nullological issue. It's
> just a special case of having a nonnegative number of visible components.
>
> As far as generic operations vs. specific operations, I see no reason
> to deny generic operations to scalars nor specific operations to tuples.

What would a generic operation entail for a specific type? It does not seem to make sense to me. Can you give an example? Of course, one can have specific operations for tuples and relations. Degree and cardinality come to mind. They would have a numeric result regardless of the specific operand type, and fixing the type of the single operand would make an entirely specific operation.

> > If there is no difference between a tuple and a type, what difference
exists
> > between an n-ary relation and a unary relation?
>
> What indeed? What need is there for such a difference?

The relational operations depend heavily on this difference. The difference affects project, join, intersect and union.

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

> Why should there be operations
> that are allowed on one but not on the other?

There are no such operations.

> What value
> would such a restriction provide?

Since no such restriction exists, I will ignore this question.

> > > Well, maybe one thing. OOPLs are heavily into use of pointers or
> > > references, and these don't work well with relational data management.
> > > But that's not a showstopper in my book. It seems eminently possible
> > > to design a data-management OO (or "OO-like") PL that didn't have
> > > pointers or references, but leaned heavily on relations instead.
> >
> > I agree. It's called the relational model, and you can find a suggested
> > language template in _TTM_.
>
> We agree then.
>
> But certainly relation-oriented languages occupy a very broad
> design space.

Of course. They occupy set theory and predicate logic for a start. One can choose very different primitive operations from which to derive the others. I can see the wisdom of choosing rename and join as primitives over choosing cartesian product as a primitive, for instance. Received on Tue Dec 23 2003 - 00:01:35 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US