Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Usenet -> comp.databases.theory -> Re: Objects and Relations

Re: Objects and Relations

From: David BL <>
Date: 1 Feb 2007 17:52:37 -0800
Message-ID: <>

On Feb 2, 3:46 am, "Marshall" <> wrote:
> On Feb 1, 12:37 am, "David BL" <> wrote:
> > On Feb 1, 4:04 pm, "Marshall" <> wrote:
> > > Um, but isn't the number of different possible, joins say, a
> > > function of the number of attributes? So we shouldn't be
> > > surprised that relations with fewer attributes have fewer
> > > possible joins.
> > Yes. However it seems to me that the fact that you're willing to use
> > nested relations for strings reveals that you don't expect a string
> > relation to join usefully with the other relations. Does that
> > willingness to isolate the relation indicate something?
> Uh, I would disagree with the word "isolate." If anything,
> wanting to treat strings as relations is a endorsement of
> the use of the RA. Current DBMSs treat strings as something
> non-relational; a special purpose attribute type. My feeling
> is that we should treat everything as relations as can be,
> including attributes (where appropriate,) and including lists

I would say an RVA has been isolated from the relations "above" it. I note that eqi-joins only select tuples from the cross product based on equality testing of the attributes as *value types*.

There is no contradiction with attributes that are identifiers of external entities, because identifiers are value types.

> > In my OP for this thread I distinguished between entities that are
> > part of the abstract computational machine, and external entities.
> > Do you agree that the distinction is well defined? Note that one of
> > the "fights" on comp.object was over this question.
> I agree it's a clear distinction ...
> > If the distinction is meaningful, then it seems to follow that you
> > wouldn't want to mix facts about internal entities and facts about
> > external entities at the one level of abstraction.
> I suppose so, but I think what this is saying is that we need
> logical/physical separation. If you have a language in which
> you don't have that, you have no choice but to mix.

Yes but it sounds a little vague.

I'm saying there's a fundamental dichotomy in the entities relevant to a system. Think of it this way: When a string appears as an ADT used for attributes, it is merely a value type and string identity is irrelevant. This is not merely an implementation detail; it has important consequences at the logical level.

Consider again a relation that stores all strings (and therefore introduces a StringId attribute). The problem goes beyond performance issues. It has introduced a concept of string identity into the problem domain (which should only state facts about external entities) that shouldn't be there in the first place.

I think the rule should be: A relational model should have no more identifiable entities than it needs.

Note that (as I said in an early post) head-tail representation of strings within a flat relational model commits an even greater crime because all the tail sub-strings have been given identity within the model.

> > Is it possible that your willingness to use a nested relation exactly
> > correlates with the distinction between internal and external
> > entities?
> I see no reason to think so.

Do you still think that given my point above about the importance of value-types in the logical model?

> > At the very least I find this to be an interesting
> > conjecture. It makes strong predictions about relational designs.
> > The conjecture that OO should keep away from storing information about
> > external entities is also powerful. It puts the OO animal in a nice
> > little cage.
> I have some sympathy with your position, but it appears impractical
> to someone who is currently writing software in an OOPL.

I think it's only impractical for those who misuse OO. There are legions of confused programmers who use OO for problems best tackled by RM.

The restriction is not so limiting as it sounds. Virtually all the examples in the GoF book meet the semantic requirements of object identity.

The crime is committed if and only if the perspective changes from "build a device" to "state knowledge about things". It appears to me that OO is a good choice for the former, and nothing is better than logic (and hence RM) for the latter.

That being said, it is useful to have very rich ADT's in order to help state factual knowledge about external entities. Eg an ADT can represent a tri-surface. A predicate can state the simple fact that some given external entity's surface geometry is described by a given tri-surface. A language like C++ can do what it's good at (fast and efficient implementation of geometry primitives) without going so far as to create objects that pretend to be the external entities themselves.

I'm a great believer in the "multi-paradigm" philosophy for language design. It seems to me that when we divide and conquer problems into sub-problems we may need to change paradigms. RM provides that shift with its requirements for ADTs for attribute domains. As another example within the context of OO it often seems useful to calculate something from inputs in a very pure way with an emphasis on the FP style.

> > It seems a little peculiar to me to store facts about entities that
> > are in fact part of the abstract computational machine. Why would a
> > machine store facts about its own working parts? To me a machine just
> > "is". Now I guess this is a rather weak argument because a machine
> > may be based on logic or set theory. In any case it is an interesting
> > conjecture just in case RM indeed proves to be deficient for
> > constructing computational machines. Curiously RM would be ideal for
> > storing facts about a given computational machine.
> I figure one wants reflection and you want a "system catalog."
Received on Thu Feb 01 2007 - 19:52:37 CST

Original text of this message