CSC/ECE 517 Fall 2007/wiki2 2 d4

Topic

Object-relational mapping. Ruby's ActiveRecord is one attempt to allow an object-oriented program to use a relational database. The Crossing Chasms pattern is another. Look up several approaches to mapping relational databases to o-o programs, include hyperlinks to all of them, and explain how they differ. Report on the strengths of various approaches (making sure to credit the authors for their insights)

Object Relational Mapping (ORM)

Object-relational mapping (ORM) is the technique used to marshal database records into classes of object-oriented (o-o) languages and vice-versa. The technique is usually developed into a tool that can be used by the developer to alleviate some of the complexity in this mapping. The complexity derives from the inherently different data types that are used by relational databases and o-o languages. Database data types are typically scalar in nature while classes are more typically composed of a mix of non-scalar and scalar types.

Figure 1. Position of ORM Layer in Database Architecture

In addition to mapping data structures in ORM, o-o concepts often need to “bridge the chasm” between the object layer and the database layer. These concepts include: inheritance, aggregation, polymorphism, class associations, and data encapsulation⁶. This conceptual difference between the database structure and o-o data storage is known as the impedance mismatch,which can create a fragile bridge across the chasm. A solution to this problem would be to create o-o databases, which has been done, but these databases do not have the structural stability or mathematical foundation that relational databases have. Even if o-o databases were to catch on, the ORM problem would still exist for years to come with the many legacy relational databases.

There have been many ORM models developed to bridge the chasm, and we will compare and contrast a handful of them in terms of their utility for developers. Some issues that should be considered when comparing ORM models are the degree of coupling between the layers, performance issues, storage space usage, and maybe even concurrency and synchronization issues. Often improving one issue will come at the expense of another issue, e.g., decoupling the layers, maybe by separating their physical locations, can increase response time thus degrading performance⁶.

Why these techniques are necessary?

1. There is not a one-to-one relationship between database object types and O-O language types

Approaches

Popular Approaches

Crossing the Chasm Pattern Language

One of the first ORMs, the name implies the difficulty involved in mapping between the two disjoint data structures.

Active Record

Limitations

1. No Foreign Key Support: Although RoR lets you define has_many relationships, it makes no effort to create foreign key constraints in the underlying database to ensure relational integrity.
2. No Multi-column Primary Key Support: Multi-column primary keys are a staple of relational database schema definition.

Data Mapper

Popular Products

These patterns in practice can be found in

Lafcadio

1. Another ORM for Ruby that currently only supports MySQL databases
2. Treats each table row as a class object
3. see http://lafcadio.rubyforge.org/ and http://www.zenspider.com/dl/rubyconf2003/lafcadio.pdf

References

1. ORM articles
2. Active Record was mentioned in this book
3. A video from RailsEnvy giving a quick and clean introduction to Active Record
4. A comparison of datamapper and Active Record implementations in Ruby
5. A blog entry by Dev411 on limitations of Active Record
6. Mapping Objects to Tables, Proceedings EuroPLoP, 1997 (2004 update)