Mapping Classes to Relational Tables
Meet the challenge of impedance mismatch with object to relational mapping. Part 1 overviews best practice approaches and looks at horizontal mapping
by Richard Jensen
Posted April 28, 2004
Editor's Note: This is the first of a two-part article on best practices for object to relational mapping. Part 1 provides an overview of the necessity to overcome the challenge of impedance mismatch between object-oriented and relational data and of using the horizontal mapping approach. Part 2 will look at the union and vertical mapping approaches and provide examples of both.
The object to relational (O/R) mapping layer is a critical component of any enterprise system. Whether you're writing new code or porting legacy applications to a new platform, the impedance mismatch between object technologies and relational databases presents a difficult challenge.
Complex systems often require a rich data model with inheritance and complex relationships to take advantage of the object-oriented language in which they are being written. Depending on the platform and development tools, the process of mapping the data model to the physical database schema may be completely manual, automated, or somewhere in between.
However, regardless of the process, simplistic and/or inefficient mapping can have a detrimental effect on applications at run time. Under load, data access can easily become a bottleneck for the whole application. While we can alleviate some of the risk by realistic testing and subsequent tweaking of the mappings, such tweaking by hand can become a maintenance nightmare.
Let's look at several best practice approaches for mapping object classes to relational tables. In particular, we'll discuss the pros and cons for various approaches to mapping object inheritance hierarchies to relational tables.
In the ideal developer-centric world, developers would be free to define the most expressive data model and let tools create the most efficient schema mapping automatically for it. At times, this approach would require restructuring an existing database schema.
Unfortunately for developers, they rarely have complete control over the relational schema. In an enterprise environment, there are often multiple data sources accessed by many different applications. The needs of a particular application need to be weighed against the needs of the many. The flexibility usually declines when an application must access legacy data.
In the ideal database administrator (DBA)-centric world, the database would be normalized to the desired form, and the administrator would be able to enforce all the constraints necessary to ensure database integrity. Applications would be required to have explicit knowledge of the relational schema and access it in a well-behaved fashion.
Unfortunately, this approach results in a great deal of unnecessary complexity being exposed to all applications that access the database. Designing applications in a relational-centric way removes many of the benefits of object-oriented development.
Back to top