Re: Mixing OO and DB

From: H. S. Lahman <>
Date: Fri, 08 Feb 2008 21:46:34 GMT
Message-ID: <_44rj.125$gg1.2_at_trnddc01>

Responding to Porton...

> I know both object oriented programming and DB (SQL). But it seems
> that these are incompatible. Or may somebody advice how to meddle them
> together?

Superficially they are not. An OO Class Model and a Data Model (nee Entity Relationship Diagram) use essentially the same notation and both are normalized using the same NF criteria.

The difference lies in the way the models are constructed and the way that elements of the entire model (the Class Diagram is only one component of an OOA/D model and cannot be separated from the other components) play together. While the construction paradigms are not directly incompatible, they will typically lead to different models because different things are abstracted (problem space subject matters vs data) and there are different goals in creating the model.

One manifestation of that is that the OO model will be highly tailored to the unique rules and policies needed to solve the problem in hand. In contrast, the goal of a Data Model is to represent data in a generic, usage-independent manner.

Thus there is an inherent incompatibility but it lies in the goals and construction methodologies rather than the notation syntax or element semantics.

Generally speaking the OO paradigm is overkill for pure data processing (i.e., classic CRUD/USER processing). In addition the RAD IDEs have largely automated much of what one would construct from scratch in an OO context. In doing so, though, the RAD IDEs have limited themselves to situations where 2D layered models apply and one can provide 1:1 mapping between the UI and the DB (i.e., form-based UIs that map conveniently to stored tables). For that sort of pure data processing the RAD paradigm is much better suited.

OTOH, when one has to solve a large problem using complex business rules and policies in a manner that is unique to the problem, one begins to realize the benefits of the OO paradigm -- particularly when the requirements are volatile over time. But for those sorts of applications, both the UI and the persistence mechanisms are of relatively little importance. Thus the problem solution doesn't care if one communicates with the user via a GUI, a web browser, or smoke signals. Nor does the problem solution care if the data store is an RDB, an OODB, flat files, or clay tablets.

So in OO applications, the UI and persistence access tend to be isolated and encapsulated as low level service subsystems. The subsystem interface then allows the mechanisms to be substituted transparently without touching the problem solution.

A corollary is that because such subsystems are narrowly defined around a particular subject matter like an RDB, one can abstract the invariants of the paradigm. Thus for an RDB access subsystem one abstracts classes like Schema, Table, Tuple, and Query rather than objects like Customer, Order, and Shipment. That, in turn, allows one to express detailed differences in terms of external configuration data. (In an RDB, the schema itself becomes an identity mapping mechanism; one just needs to link interface messages to schema names.) So typically one only needs to design and implement a UI or DB paradigm once in an OO fashion; one can then reuse the subsystem across different applications by simply providing an appropriate configuration file and an interface (think: GoF Facade pattern).

> Being strong in both OOP and DB development, I am yet weak in writing
> object oriented programs which use DB.

If you are solving CRUD/USER problems my advice would be to forget about using OO and employ traditional RAD techniques. If you are solving non-CRUD/USER problems, then I think all you have to do is isolate, encapsulate, and abstract the invariants of the DB paradigm.

> Maybe somebody may suggest me some article about mixing together DB
> and OOP?

You might check out Fig. 17.2 in "Executable UML" by Mellor and Balcer. The example is about abstracting a web browser UI but it is a good example of abstracting the paradigm invariants. Exactly the same model could be used for any application that talks to a web browser; all that changes is what instances are initialized and what their attribute values are -- all provided by configuration data. The extrapolation to a model with objects like Table and Query should be fairly obvious.

There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
Pathfinder Solutions
"Model-Based Translation: The Next Step in Agile Development".  Email for your copy.
Pathfinder is hiring:
Received on Fri Feb 08 2008 - 22:46:34 CET

Original text of this message