Patterns for mapping objects to relational databases

The Object-Relational Mismatch

[10]

The difference between how Object models work and Relational Databases is known as the “Object-Relational Impedance Mismatch”. This is just nerd-speak for “they are different”. In analogy, we could consider the example of the ball and shape game. It's the same thing; you can’t fit a square in a triangle hole.[10]

Object-orientation and the relational model are different paradigms of programming. When objects need to be stored in relational databases, the gap between the two different sights needs to be bridged. If only data abstraction modules have to be mapped to a relational database, life is comparably easy [Kel+97]. With full blown object models the concepts of object oriented programming have to be mapped to relational table structures.[1]

The Object-Relational Mismatch The object paradigm is based on building applications out of objects that have both data and behavior, whereas the relational paradigm is based on storing data. The “impedance mismatch” comes into play 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 duplicate data to join the rows in tables. This fundamental difference results in a non-ideal combination of the two paradigms, although when have you ever used two different things together without a few hitches? One of the secrets of success for mapping objects to relational databases is to understand both paradigms, and their differences, and then make intelligent tradeoffs based on that knowledge.[2]

Most modern business application development projects use object technology such as Java or C# to build the application software and relational databases to store the data. This isn’t to say that you don’t have other options, there are many applications built with procedural languages such as COBOL and many systems will use object databases or XML databases to store data. However, because object and relational technologies are by far the norm that’s what I assume you’re working with in this article. If you’re working with different storage technologies then many of the concepts are still applicable, albeit with modification (don’t worry, Realistic XML overviews mapping issues pertaining to objects and XML). Unfortunately we need to deal with the object relational (O/R) impedance mismatch, and to do so you need to understand two things: the process of mapping objects to relational databases and how to implement those mappings. in this article the term “mapping” will be used to refer to how objects and their relationships are mapped to the tables and relationships between them in a database. As you’ll soon find out it isn’t quite as straightforward as it sounds although it isn’t too bad either.[3]

Designing software to connect an object-oriented business system with a relational database is a tedious task. Object-orientation and the relational paradigm differ quite a bit. An application that maps between the two paradigms needs to be designed with respect to performance, maintainability and cost to name just a few requirements. Luckily there are numerous patterns of object/relational access layers, but looking at the body of pattern literature you will find that some patterns are still to be mined, while there's no generative "one stop" pattern language for the problem domain. This paper provides a systematic roadmap of the patterns in the field, and fills some pot holes on the road towards a full pattern language for object/relational access layers by providing some missing patterns and links.[4]

Developers of object-oriented systems that use a relational database usually spend a lot of time making objects persistent. This is because of a fundamental impedance mismatch1 between the two paradigms; objects consist of both data and behavior and often have inheritance while relational databases consist of tables, relations and basic predicate calculus functions to return desired values. One way to avoid the impedance mismatch between objects and relations is to use an object-oriented database. However, systems often need to store objects in a relational database. Sometimes a system needs relational calculus or the maturity of a relational database. Other times the corporate policy is to use a relational database rather than an object-oriented database. Whatever the reason, a system that stores objects in a relational database needs to provide a design that reduces the impedance mismatch. This paper describes only a part of a pattern language for mapping objects to relations, but it describes the patterns that we thought were not adequately described elsewhere. An overview of the entire pattern language can be found in [Keller 98-2]. Some of the patterns that are described well are the patterns for designing the relational database and optimizing it [Brown 96] [Keller 97-1, 97-2, 98-1]. The Serializer pattern [Riehle et al. 1998] describes how to serialize objects so they can be stored and retrieved from different backends, such as flat files, relational databases, and RPC buffers.[5]

Concurrency Patterns

Read/Write Access Pattern

Conclusion

The concurrency patterns discussed above involve coordinating concurrent operations. They address two types of problems:[5]

Shared resources - When concurrent operations access the same data or another type of shared resource, operations may interfere with each other if they access the resource at the same time. To ensure that operations on shared resources execute correctly, the operations must be sufficiently constrained to access their shared resource one at a time. However, if the operations are overly constrained, then they may deadlock and not be able to finish executing.

Sequence of operations - If operations are constrained to access a shared resource one at a time, it may be necessary to ensure that they access the shared resource in a particular order. For example, an object cannot be removed from a data structure before it is added to the data structure.

References

[1] Wolfgang Keller, Mapping Objects to Tables - A Pattern Language http://www.objectarchitects.de/ObjectArchitects/papers/Published/ZippedPapers/mappings04.pdf

[2] Scott W. Ambler, President, Ronin International, Mapping Objects To Relational Databases http://www.crionics.com/products/opensource/faq/docs/mappingObjects.pdf

[3] Scott W. Ambler, Mapping Objects to Relational Databases: O/R Mapping In Detail http://www.agiledata.org/essays/mappingObjects.html

[4] Wolfgang Keller, Object/Relational Access Layers - A Roadmap, Missing Links and More Patterns http://citeseer.ist.psu.edu/4328.html

[5] Joseph W. Yoder, Ralph E. Johnson, Quince D. Wilson, Connecting Business Objects to Relational Databases http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.34.7703&rep=rep1&type=pdf

[6] Michael R. Blaha, William J. Premerlani and James E. Rumbaugh, Relational Database Design using an Object-Oriented Methodology http://www.sims.monash.edu.au/subjects/ims2501/seminars/oomodelling.pdf

[7] http://www.cetus-links.org/oo_db_systems_3.html

[8] http://www.ibm.com/developerworks/library/ws-mapping-to-rdb/

[9] http://www.objectarchitects.de/ObjectArchitects/orpatterns/index.htm?MappingObjects2Tables/mapping_object.htm

[10] http://cantgrokwontgrok.blogspot.com/2009/03/tech-day-1-nhibernate.html

[11] http://www.adobe.com/newsletters/edge/october2008/articles/article2/index.html?trackingid=DWZST