Re: Relations contain Objects

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.

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?

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

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

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

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

I don't think you want to have "instantiate" on two different sides of the equivalence sign. Specifying a tuple would not seem to be the same as inserting into a table. Would it?

I have no great issue with anything you've said, just these lot of quibbles. Maybe I should burn the Date book and look for another technical/theoretical reference. Suggestions welcome.

Joshua Stern Received on Fri Jun 14 2002 - 04:51:50 CEST