A lot has been discussed and written on the Object-Relational Impedance Mismatch; the conflicts that arise due to the differences of principles driving these paradigms. Religious wars have been fought between Application developers that practice Object Orientation, and Database Administrators, Data Modelers that implement Relational Database concepts. It’s a common occurrence in almost every IT organization that OO developers and RDBMS specialists often engage in sumo wrestling contest on what should come first, the relational database model or the component/entity model. These feelings are highly charged and often emotional, and never ending.

OO methodology is based on software engineering concepts, while relational databases are based on mathematical models such as Calculus and Set Theory. There is no question a solution to a problem will be looked at quite differently in these two worlds. Most of today’s applications both internal to the organization and external applications such as eCommerce applications use both Relational Databases and OO technologies to build out the solution. Yet, this battle never ends, and both sides try to influence the others in every organization on how it should be implemented.

In most cases the precedence for the implementation of this combination is set by which comes first – chicken or egg? And, also which group has more power in the organizational setting. It’s unfortunate, but it’s true. I present 2 extreme cases to manifest the problem of O/R impedance mismatch and how it’s handled in IT organizations.

Case 1:
The story goes something like this. The database group has some strong feelings about how application software needs to be developed and they were able to prevail. The result was a very clean, highly normalized relational database, and an entity model that’s a mirror representation of the database. The object model became totally devoid of simple object orientation concepts such as inheritance, abstraction. With the early success, the database guys pushed the envelope little further, by arguing that all the business logic should reside in the database, not in the application. The logic was if the business logic resides close to the database, the performance will be better, and the database group can help tune the application better than the developers ever can. The database guys did win that battle. When, some hesitant developer questioned how a different application can leverage the business logic that’s embedded in the stored procedures, the database group came up with an immediate solution. They Web Service enabled the stored procedure, and the argument was as a web service consumer, you shouldn’t worry how the service is built, that’s inherent to the service. Basically, they put a SOAP wrapper around the stored procedure. You just got to love this!

The big problem here is the business logic became so dependant on the database. The object model became nothing but a transport object from the stored procedure to the client application. It left no scope for object orientation at the entity model level, object reusability, and business logic modeling. It’s sort of compiling a C program with a C++ compiler in the old days! Unfortunately, six months after the rollout, the company was acquired, and this project was shelved as the new management wanted to bring in a different database vendor, and it was decided that the cost of migrating all the stored procedures in the original system to the new setup was cost prohibitive.

Case 2:
In this case, the application developer arrived first on the scene. The guys created great entity model that can be attested as one of the best object models implemented. They used the O/R mapping provided by persistence providers such as Hibernate, and EJB3. The tables were generated from the entity model with every class mapped to their own table in the relational database. The pros of this approach from an application development perspective were huge. As EJB3 annotations were used for O/R mapping and persistence service, the data access programming and persistence programming were next to nil. Also, developers can make a simple one to one mapping from the objects to the database tables. It was interesting to see the inheritance concepts dubbed into the database world. For example, if you have a class hierarchy with a base class of Person, and an Employee class and a CustomerContact class that subclass Person, and an Executive class that subclasses Employee, you will have one table for each of these classes to store class specific properties.

In addition to the rapid development this model achieved, application developers can cheer up for eliminating the data modeler from the organization with this scheme. This model does have its own inherent issues. One major issue is performance. If one wants to query the Executives, now they have to join 3 tables to get information of the executive. Note that this is not accounting for the ancillary data that’s associated with the entity. The deeper the class hierarchy is the more number of tables you will end up looking to get entity level information. Without careful physical database partitioning and layout concerns, this can become a severe issue for the applications performance. Another major issue is reporting and the productivity of power users. No IT organization has the bandwidth to support all the ad-hoc and analytical reporting needs of their internal users. Often times, IT organizations make alliances with power users in different departments to meet these needs. Power users are business users that can find their way in the database, slice and dice the data for various analytical needs by using simple query tools and somewhat advanced SQL skills. This scheme of object model influencing relational database design may turn off the power users as the table design is out of their usual comfort zone. Application developers point out that this can be eliminated by creating materialized views on the tables and exposing the materialized views to the power users so they feel that they are working with one table rather than a number of tables underneath. But, the early savings of rapid development are offset with this later development of materialized views and opens up new issues in terms of inconsistencies of data representation.

So, what comes first? Object model or the relational model? Both! I think they both can be developed in parallel. They can co-exist the way they are. Object developers develop their own object model based on the domain analysis; implement the behavior in their business logic layers to gain most of out of what OO has to offer. Data Modelers and Database Administrators can develop their own version of the data model based on performance, accessibility, stability concerns. I don’t advice them to work in silos, but the problem is studied together, solution discussed, and modeled in their own versions. Most successful software project implementations follow this model. There are several enterprise projects, where we have built object model and relational models in parallel. Object and Relational models are different for a reason, and I don’t see any need for influencing each other, or coming up with one unified model. They both serve their purpose in their own way, and they can work together very well as long as they don’t hijack each other.

The idea is Relational databases deal with data storage, accessibility with performance considerations as underpinning, and Object models deal with data, the behavior and of course should be performance conscious. They will use O/R mapping to build the bridge. The idea is not to hijack the other technology, but to create a transparent and loosely coupled medium to bond the two technologies. This concept gives the two groups enough leverage to address the real concerns that are at hand for each, and work together for a stable and scalable solution. Application developers and Data modelers will work in unison by making sensible compromises. Compromises need to be looked at as part of working together, and reviewed over time. Not all compromises yield the best outcomes, but both parties need to be willing to see the problem the way it is, review and resolve it with adjustments to the original compromise. That’s why I call for the need for ‘sensible’ compromises.

Handling the O/R impedance mismatch is not just an implementation level battle to leave it to the application developers and database administrators. IT management has a serious stake in this. As an IT manager for my enterprise applications, I want database vendor independence, loosely coupled technologies, elimination of performance bottlenecks, scalable solutions, rapid development, and an IT team that works together towards the goals of my organization. O/R impedance mismatch is not a technology problem, just another opportunity for implementers to work together.