Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Usenet -> comp.databases.theory -> Re: Possible bridges between OO programming proponents and relational model

Re: Possible bridges between OO programming proponents and relational model

From: Alvin Ryder <>
Date: 3 Jun 2006 16:30:55 -0700
Message-ID: <>

Cimode wrote:
> I noticed a recurring commercial argumentation about creating
> *behavior* into components (named classes). This caracteristics is
> often presented as being a differentiation of relational model where no
> such thing really exists (and in fact is not necessary). In a word, In
> OO approach (for whatever it may rely on), one of the main limitation
> of relational model would be not to allow its elementary components to
> emulate elementary predefined processes (transformations for instance).

[I added comp.object since we're talking about bridging and OOP].

Actually the relational model (RM) allows for and expects "user defined types", a user defined type without operators is useless so it also expects user defined operators. Operators are also called functions or methods and that is what OOP proponents refer to as "behavior". Data+code.

But most commercial DBMS don't make it easy to create user (programmer) defined attribute types. You can easily use the vendor supplied types but defining your own is another story. However this limitation was never imposed by the RM.

> I have the impression, there is a concept, unbearable to some
> programmers that data management systems can not be anything else than
> a mechanized set of tool that could help structuring data for human
> interpretation. On that standpoint, relational model components
> reflect an approximation of *meaning* concept as being a contextualized
> and specific combination of constraints, business rules to make
> predefined inferences about that data for preparing interpretation.
> Processes are defined only according to specifically defined
> inferences. On the other side, OO approach seems to advocate that some
> level of elementary process autonomy will end up creating *some* form
> of intelligence thanks to some cumulative effect. On such perspective,
> I start suspecting all debate stating behavior lacking in the
> relational model is an empty unfounded attempt of some IT professional
> to project their scifi fantasies about what system could do and what
> they can actually do in a realistic manner.
> On the other side, some OO advocates state that OO approach brings some
> features that would seem to better implementations of subtype and
> supertypes features through inheritance as well as a better in memory
> physical handling of non primitive types than what we are accustomed to
> with traditional SQL implementations.
> I am curious about your opinion about this matter as this is a new
> board for me. (Sorry if you have noticed some english errors as it is
> not my native language) so bear with me please.

The biggest bridge between the RM and OOP appears to be coming from Chris Date and co.

In earlier editions of "Introduction to Databases ..." he uses the word "atomic" and gives clear examples where a Set is *not* allowed as an attribute (column). The set elements {A, B, C} had to be "decomposed and normalized".

But later, in books like "Database in Depth", this definition was "clarified" - "domains are types", now you *can* have an attribute (column) of type Array, Set and whatever else. As long as you only have a single value or instance of a type like Set it's OK.

For example: Set instances like {A, B, C} are allowed in a column, other tuples (rows) might have {A, B}, {A}, {} in that same column. But none can have {A, B, C} + {X, Y Z} because that isn't a /single/ value or instance.

You can even have an attribute of type Relation and plug an entire relation into an attribute (RVA). Now since we already have operators to handle relations why not allow it to be decomposed?

I hope it can be seen this "reclarified" definition is no small step in bridging OOP and the RM. If you use relational keys instead of in memory pointers, in theory, you now have enough to support "object based" programming (ie OOP with no inheritence)!

In "The Third Manifesto" we go one step further, sub-types are covered which opens up the inheritence door as well.

In practice most people I've encountered are stuck on the earlier "Intro to databases" definitions, they'll get a shock when they see ADT's in SQL 3. But all SQL aside, in theory the gap between OOP and RM is much smaller.

As Date urges in "Db in depth" "now all we need is to implement the relational model" (paraphrased).

Cheers. Received on Sat Jun 03 2006 - 18:30:55 CDT

Original text of this message