Relational and Object Oriented Models


(special thanks to Richard Scoop)

I have encountered, both in newgroups and mailinglists, some discussions about Object Oriented Models vs Relational Models. This post tries to describe some problems and the solutions of both approaches for a programmer’s day to day work.

The relational approach presents the information the way its stored. This provides easy translation, which results in some productivity with a low learning curve. The model does not make any translation. The table in the database becomes a list (or grid) in the application, each row of the list has information entered in a form. As simple as that.

The first, second and third normalization rules, divide information so that it can be stored in a relational database. The Client from an Order gets its own table, the order items get another and the application evolves in step with the database. The business rules treat the order clients thru their ID and joins them with their orders, components read the database register in order for a query to be constructed in a few clicks. A query, not queries. For each table, the application needs an insert, an update and a delete.

Although the relational model has other problems, such as making and maintaining a lot queries, its Achilles heel is in the distance that exists between the model and the real world information. In the real world, someone applying for a credit can be either a person or a company, even though a person and a company are different entities. For a relation to exist in the relational model, the person and the company should share the same table and therefore share the same attributes, or they should share three tables (a common one and two with the specific information for each one), making the storage very difficult. But there is more, the natural person might have different behaviors than the business entity for credit evaluation, thereby making the programmer sprinkle IFs throughout his code making it more difficult to maintain.

On the other hand, treating with information in the object oriented model is more coherent. The business rules are clearer, simpler to execute and to keep because they deal with real objects, and not with abstract lists. An order points to an object customer and not a number. This order contains a container with several items instead of having a list of items pointing to the order. In other words, there is nothing of Master-Detail, Open/Close, Editing/Presenting, to Block/Release, there are only objects in memory that at some point will be either persisted or discarded.

In the Object Oriented Model, the database follows the evolution of the model and the application, not the reverse. Programmers need to worry only with the classes (for the objects) and rules, and a framework will understand these classes and rules to maintain the database.

The Object Oriented Model starts to get into trouble in specific situations such as batch updates, complex search, or something of this sort. While, in the relational model, everything is under the programmer’s control, in the Object Oriented model much of the work is under the control of the framework and it can behave in ways that the programmer does not expect. Or still, the framework might be missing some resource, or the programmer does not have enough ability to extract all that the framework offers.

This point, along with the steeper learning curve of the Object Oriented Model, makes the relational model the number one choice of a lot of programmers.