The Object-Relational Impedance Mismatch

www.agiledata.org: Techniques for Successful Evolutionary/Agile Database Development

Object-oriented technology supports the building of applications out of objects that have both data and behavior. Relational technologies support the storage of data in tables and manipulation of that data via data manipulation language (DML) internally within the database via stored procedures and externally via SQL calls. Some relational databases go further and now support objects internally as well, a trend that will only grow stronger over time. It is clear that object technologies and relational technologies are in common use in most organizations, that both are here to stay for quite awhile, and that both are being used together to build complex software-based systems. It is also clear that the fit between the two technologies isn’t perfect, that there is an “impedance mismatch” between the two.

In the early 1990s the differences between the two approaches was labeled the “object-relational impedance mismatch”, or simply “impedance mismatch” for short, labels that are still in common use today. Much of the conversation about the impedance mismatch focus on the technical differences between object and relational technologies, and rightfully so because although there are deceptive similarities there are also subtle yet important differences. Luckily, there are strategies for overcoming the O/R impedance mismatch.

1. The O/R Impedance Mismatch

Why does this impedance mismatch exist? The object-oriented paradigm is based on proven software engineering principles. The relational paradigm, however, is based on proven mathematical principles. Because the underlying paradigms are different the two technologies do not work together seamlessly. The impedance mismatch becomes apparent when you look at the preferred approach to access: With the object paradigm you traverse objects via their relationships whereas with the relational paradigm you join the data rows of tables. This fundamental difference results in a non-ideal combination of object and relational technologies, although when have you ever used two different things together without a few hitches?

To succeed using objects and relational databases together you need to understand both paradigms, and their differences, and then make intelligent tradeoffs based on that knowledge. Relational Databases 101 overviews relational databases and Data Modeling 101 describes the basics of data modeling, providing you with sufficient background to understand the relational paradigm. Similarly Object-Orientation 101 overviews object-orientation and the UML, explaining the basics of the object-oriented paradigm. Until you understand both paradigms, and gain real-world experience working in both technologies, it will be very difficult to see past the deceptive similarities between the two.

2. Deceptive Similarities, Subtle Differences

The easiest similarity/difference to observe is the different types in object languages and in relational databases. On the subtle side, Java has a string and an int whereas Oracle has a varchar and a smallint. Although values are stored and manipulated differently, it's fairly straightforward to convert back and forth and DB access libraries such as JDBC handle them automatically. However, on the not-so-subtle side Java has collections whereas Oracle has tables, clearly not the same concepts. Oracle has blobs whereas Java has objects, once again clearly not the same concepts.

Figure 1 depicts a physical data model (PDM) using UML data modeling notation. Figure 2 depicts a UML class diagram. On the surface they look like very similar diagrams, and on the surface they in fact are. It’s how you arrive at the two diagrams that can be very different.

Figure 1. A physical data model (UML notation).

Let’s consider the deceptive similarities between the two diagrams. Both diagrams depict structure, the PDM shows four database tables and the relationships between them whereas the UML class diagram shows four classes and their corresponding relationships. Both diagrams depict data, the PDM shows the columns within the tables and the class model the attributes of the classes. Both diagrams also depict behavior, the Customer table of Figure 1 includes a delete trigger and the Customer class of Figure 2 includes two operations. The two diagrams also use similar notations, something that I did on purpose, although the UML data modeling notation is little different than other industry notations.

Figure 2. A UML class model.

Differences in your modeling approaches will result in subtle differences between your object schema and your data schema:

By considering both data and behavior in the class diagram the modeler created a different structure than in the data model that only considered data
Data normalization in data modeling versus class normalization in class modeling
The application of data analysis patterns (Hay 1996) versus object-oriented analysis patterns (Fowler 1997; Ambler 1997) and design patterns (Gamma et. al. 1995)

There are differences in the types of relationships that each model supports, with class diagrams being slightly more robust than physical data models for relational databases. This is because of the inherent nature of the technologies. For example, you see that there is a many-to-many relationship between Customer and Address in Figure 2, a relationship that was resolved in Figure 1 via the CustomerAddress associative table. Object technology natively supports this type of relationship but relational databases do not, which is why the associative table was introduced.

Figure 3 also reveals a schism within the object community. It is common practice to not show keys on class diagrams (Ambler 2003/2005), for example there isn’t any shown on Figure 2. However, the reality is that when you are using a relational database to store your objects then each object must maintain enough information to be able to successfully write itself, and the relationships it is involved with, back out to the database. This is something that I call “shadow information”, which you can see has been added in Figure 3 in the form of attributes with implementation visibility (no visibility symbol is shown). For example the Address class now includes the attribute addressID which corresponds to AddressID in the Address table (the attributes customers, state, and zipCode are required to maintain the relationships to the Customer, State, and ZipCode classes respectively).

Figure 3. A fully attributed UML class model.

The schism is that the object community has a tendency to underestimate the importance of object persistence. Symptoms of this problem include:

The lack of an official data model in the UML (see The Unofficial UML Data Modeling Profile)
The practice of not modeling keys on class diagrams
The misguided belief that you can model the persistent aspects of your system by applying a few stereotypes to a UML class diagram
Many popular OOA&D books spend little or no time discussing object persistence issues

Yet in reality object developers discover that they need to spend significant portions of their time making their object persistent, perhaps because they’ve run into performance problems after improper mappings or perhaps because they’ve discovered that they didn’t take legacy data constraints into account in their design. My experience is that persistence is a significant blind spot for many object developers, one that promotes the cultural impedance mismatch.

3. Strategies for Overcoming the Object-Relational Impedance Mismatch

Object and relational technologies are real, you are very likely working with both, and they are here to stay. Unfortunately the two technologies differ, these differences being referred to as “the object-relational impedance mismatch”. In this article you learned that there are two aspects to the impedance mismatch: technical and cultural.

The technical mismatch can be overcome by ensuring that project team members, including both application developers and Agile DBAs, understand the basics of both technologies. Furthermore, you should actively try to reduce the coupling that your database schema is involved with by encapsulating access to your database(s) as best you can, by designing your database well, and by keeping the design clean through database refactoring.

4. The Cultural Impedance Mismatch

Unfortunately there has been less attention spent on the cultural differences between the object-oriented community and the data community. These differences are often revealed when object professionals and data professionals argue with each other regarding the approach that should be taken by a project team. For a detailed discussion, see The Cultural Impedance Mismatch Between Data Professionals and Application Developers.

5. References and Suggested Online Readings

This book describes the philosophies and skills required for developers and database administrators to work together effectively on project teams following evolutionary software processes such as Extreme Programming (XP), the Rational Unified Process (RUP), the Agile Unified Process (AUP), Feature Driven Development (FDD), Dynamic System Development Method (DSDM), or The Enterprise Unified Process (EUP). In March 2004 it won a Jolt Productivity award.

This book describes, in detail, how to refactor a database schema to improve its design. The first section of the book overviews the fundamentals evolutionary database techniques in general and of database refactoring in detail. More importantly it presents strategies for implementing and deploying database refactorings, in the context of both "simple" single application databases and in "complex" multi-application databases. The second section, the majority of the book, is a database refactoring reference catalog. It describes over 60 database refactorings, presenting data models overviewing each refactoring and the code to implement it.

This book presents a full-lifecycle, agile model driven development (AMDD) approach to software development. It is one of the few books which covers both object-oriented and data-oriented development in a comprehensive and coherent manner. Techniques the book covers include Agile Modeling (AM), Full Lifecycle Object-Oriented Testing (FLOOT), over 30 modeling techniques, agile database techniques, refactoring, and test driven development (TDD). If you want to gain the skills required to build mission-critical applications in an agile manner, this is the book for you.

6. Let Me Help

I actively work with clients around the world to improve their information technology (IT) practices as both a mentor/coach and trainer. A full description of what I do, and how to contact me, can be found here.