Object-Relational
Mapping
CRAIG RUSSELL, SUN MICROSYSTEMS
Bridging the
Object-Relational

Modern applications are built using two very different technologies: object-oriented programming for business logic; and relational databases for data storage. Object-oriented programming is a key technology for implementing complex systems, providing benefits of reusability, robustness, and maintainability. Relational databases are repositories for persistent data. ORM (object-relational mapping) is a bridge between the two that allows applications to access relational data in an object-oriented way.

ORM is a specialization of the general concept of object persistence. In his book Object-oriented Analysis and Design with Applications, IBM Fellow Grady Booch claimed that persistence, defined as “data that outlives the program,” is a minor element of an object model. 1 In modern applications, however, the amount of effort devoted to persistence can dominate the cost of a project, and using ORM tools can significantly reduce this cost.

Other technologies can be used to access relational data from object-oriented programs, but these technologies generally do not exploit the object behavior of the programming language. To exploit object behavior fully,

database-access technology should support separation of concerns, information hiding, inheritance, change detection, uniquing, and database independence.

Separation of concerns is the process of breaking up a program into logical parts that have little or no overlap. In database programming, several parts should be separated: business methods that find domain objects and operate on them; methods in those domain objects that might cause internal state changes and call methods in associated objects; generation of database commands to implement inserts, queries, updates, and deletes of database rows and columns; and methods for database transaction demarcation.

Information hiding is an implementation strategy for separation of concerns that reduces complexity and cost by defining behavior in terms of interfaces that are implemented by specific classes. The classes implement the behavior separate from the behavior of the callers. Changing one side does not necessarily require changes in the other.

Inheritance allows for reuse of code where common behavior is defined once for a number of related classes and unique behavior is implemented only in classes where the behavior is different. Thus, the behavior of a class might be the same or different from the behavior of

References:

mailto:feedback@acmqueue.com

Archives