Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Usenet -> comp.databases.theory -> Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

From: J M Davitt <>
Date: Mon, 05 Jun 2006 23:37:05 GMT
Message-ID: <Be3hg.51650$>

Sasa wrote:
> Marshall wrote:

>> Sasa wrote:
>>> mAsterdam wrote:
>>>> And all tables, columns and constraints in your schema
>>>> were designed and named by the object-persistence layer
>>>> designers/programmers, for programs.
>>>> ...
>>> No. They should be designed semi-independently of the object persistence
>>> layer. The client (app(s)) dictates what it wants. The DBMS chooses how
>>> will it present it. The mapper, simply translates.
>> Why would you do that? The requirements dictate the conceptual
>> model. The conceptual model dictates the logical model. The
>> logical model is the database schema. The conceptual model
>> also dictates what the application code needs to do.
>> If you have done the above correctly, there is no "separation"
>> between the schematic needs of the database and those
>> of the application. There is certainly no need for "independence."

> Given the fact that same model is described in OO and relational world,
> one using things such as classes, class hierarchies and aggregations,
> and the other using tables. Is it not to be expected that there will be
> difference in each design?

If you stipulate that the differences are due to virtually all OOPLs inability deal with types as lattices then, I might find some agreement with this last paragraph. But lining-up "classes, class hierarchies, and aggregations" on one side of the question and only "tables" on the other is casting light on only a tiny bit of the problems most systems address.

> Of course, they are both driven by the same model, with the possible
> option that the database describes broader model if it serves more than
> one applications. Hence the semi independence.

Semi-independence? You seem to be alluding to an application which deals with a subset of a system's data. If such an application does deal with such a subset, it can't be independent of the system's data; one can't justify a design which observes some of the rules because it's dealing with only some of the data.

Granted, it often seems appealing to enforce some of the rules in both the database and the application, but there's no doubt in my mind that all integrity must be maintained in the database system.

The fact that a conceptual model exists is sometimes a bane. It is often used as a reference when developing what many seem to see as the "application" part of the system and the "application" designers use knowledge of the conceptual model to deliver a more "user-friendly" or "better performing" or "more easily integrated" or "whatever" interface or application or front end. Or whatever.

That approach invariably increases complexity and redundancy. Any supposed benefits carry costs and are often uneconomic. In the long run, such features do nothing to ensure the integrity or increase the currency of the data.

Is it easy to do? It seems like it. In fact, architects devise all sorts of layers through which they "design-in" decoupling and independence. They have mistakenly applied what they perceive to be functional decomposition to "decomposition by choice of technology."

(May I have a Zeroth, too, please?)

> Sasa
Received on Mon Jun 05 2006 - 18:37:05 CDT

Original text of this message