Re: Relations contain Objects

"JRStern" <JXSternChangeX2R_at_gte.net> wrote in message news:3d095742.43288415_at_news.verizon.net...
> On Thu, 13 Jun 2002 20:53:20 -0400, "Bob Badour" <bbadour_at_golden.net>
> wrote:
> >> I don't know if "relation" is supposed to mean the semantic function
> >> that groups fields, or a particular set of values that fulfills the
> >> function. That is, I forget if it's supposed to mean a table or a
> >> row.
> >
> >A relation, in this case, is a generic type with generic operations
> >consisting of header with a set of N named, typed attributes and a set of
> >N-dimensional tuples where a value in each dimension of each tuple
> >corresponds to one of the named, typed attributes.
>
> OK, I'll get that ol' Date book and open it up.
>
> "'Relation' is just a mathematical term for a table." (p 63, An
> Introduction to Database Systems, 2000).
>
> Thanks for nuthin, C.J.

Chris writes at different levels of formality and precision at different times and for different purposes. Obviously, he chose on page 63 to give a very informal definition.

> Bob, I think you've given it more effort that Date does here, but I'm
> still rather unclear, now that we're talking about it, on just what's
> what. It seems rather odd to have a term that describes a generic
> type plus a set of specific instances. You don't have a specific
> type, which can instantiate actual tuples, until you have some kind of
> specifier. I'm suspicious that any term can effectively cover all of
> these levels.
>
> As a matter of fact, when I hear "relation" I also tend to think of
> the referential integrity constraints or even more dynamic
> relationships (sic) between tables. What's up with that?

If you are talking about the idea (often repeated) that the relational model is named after "relationships" (ie. referential integrity), that's just ignorance.

The relational algebra or equivalently the relational calculus has a sound mathematical basis allowing one to describe both integrity constraints, derived relations (views) and data manipulations. The first allows the dbms to fulfill its integrity function and the second allows logical independence. Good data management principles require integrity, manipulation and logical independence.

> "Relational database" seems to include all of these, without quite
> enough ceremony.

Relation is a generic type. I don't know what's so difficult about that. Integer is a specific type. We have integer values and integer variables just as we have relation values and relation variables. We have operations on integers just as we have operations on relations. Collection is a generic type too.

> >> But the term "object" is used loosely to mean class or instance, so
> >> "object" doesn't map exactly to anything.
> >
> >What does class or instance mean?
> >ie:
> >How does a class differ from a type?
> >How does an instance differ from a variable?
>
> class is a type.
> instance is an instance of the class, eg a tuple.

Tuples have no operations and visible internal structure. I suppose they are impure classes. Most people like classes to have behaviour and no visible internal structure, though.

> >> IOW:
> >>
> >> table == class
> >> row == instance
> >
> >I find the above comparison lacking at a number of levels. I would
propose
> >different ones that I think are much more useful.
> >
> >Since the values in relations can have arbitrary complexity:
> >
> >type == class
> >value == object value
> >tuple (row) == set of associated object values--equally an N-ary
postulate
> >relation == set of N-ary object value postulates
> >relation variable (table) == set of N-ary object *variable* postulates
> >insert into relation variable == instantiate
> >instantiate == specify a tuple value
>
> I dunno that an n-ary type is a postulate, ... or, wait, maybe you're
> onto something there. Would you like to say more about it? Do you
> have any reference to a book that treats things that way?

Any book on first order predicate logic.

> If you have an entity which is a relational variable, then I still
> have an issue with whether its value is the tuples, or the
> specification of those tuples, or both. I'm uncomfortable with
> "both".

It's value is its value. A value carries its type with it. For instance, the value 3 is an integer.

> I don't think you want to have "instantiate" on two different sides of
> the equivalence sign.

Why not? It has different meanings depending on whether we are on the relational side or the object side.

> Specifying a tuple would not seem to be the
> same as inserting into a table. Would it?

They are very different concepts with the same name, which is a point I wanted to illustrate. This exchange is cross-posted to comp.databases and comp.databases.theory as well as comp.databases.object and comp.object. When one uses a term like instance or instantiate in such an exchange, one has to take extra care for clarity. Received on Fri Jun 14 2002 - 07:36:10 CEST