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).

Introduction

Object-oriented (o-o) programming uses Object to manage data. Objects have identity, state, and behavior, which means Object is focus on identity and behavior of the things in real world. However relational database is focus on information. It is a collection of relation variables between the attributes of tables, it describes the complete state of an information model.

For instance, a "Customer Object" in on line bookstore system implemented by o-o programming constains the information of the customer such as name, address, email, and phone number. It also constains some methods operated by customer, such as "ordering_books", which defines the ordering behavior of the customer.

However, the popular relational database, such as MS SQL products, can only stores and manipulate the information of the customer within table "Customer". The ordering behavior is not included in the "Customer" table.

Therefore, programmers have to transform values between object in o-o programming and relational database. Object-ralational mapping is introduced to solve this problem.

Object-relational Mapping

Object-relational mapping (O/RM, ORM, and O/R mapping) is a programming technique or process to transform data between relational database and a set of objects in object-oriented programming. The relation is illustrated in the graph below

Implementations

ActiveRecord in Ruby

Ruby ActiveRecord provides a easy approach to map the relational database tables to objects. For example, after creating a database table

create table customers{
  customerNumber int
  name varchar(20)
  address varchar(50)
}

and declaring a module

  class Customer < ActiveRecord::Base 
  end

The table then can be manipulated directly through object.

  customer=Customer.new
  customer.customerNumber=3
  customer.name="John"
  customer.address="#202 Heaven Rd, Raleigh, NC"
  customer.save

This will fill in a new table record with customer "John" with customer number 3 and address "#202 Heaven Rd, Raleigh, NC".

The main features of ActiveRecord of Ruby on Rails includes:

Automated mapping between classes and tables, attributes and columns.
Associations between objects controlled by simple meta-programming macros.
Aggregations of value objects controlled by simple meta-programming macros.
Validation rules that can differ for new or existing objects.
Acts that can make records work as lists or trees:
Callbacks as methods or queues on the entire lifecycle (instantiation, saving, destroying, validating, etc).
Observers for the entire lifecycle
Inheritance hierarchies
Transaction support on both a database and object level. The latter is implemented by using Transaction::Simple
Reflections on columns, associations, and aggregations
Direct manipulation (instead of service invocation)
Database abstraction through simple adapters (~100 lines) with a shared connector
Logging support for Log4r and Logger

A detailed explanation including examples can be found here[1]

Crossing Chasms Pattern

Crossing Chasms Pattern is a large pattern language that describes how to connect an object system to a RelationalDatabase [9].

Crossing chasms contains architectural patterns, static patterns that define tables and object models, dynamic patterns that resolve run-time problems of object-table mapping, and client-server patterns.

K. Brown, B. Whitenack defined serveral patterns in Crossing Chasms: A Pattern Language for Object-RDBMS Integration [7], such as:

Pattern: Table Design Time
Pattern: Representing Objects as Tables
Pattern: Representing Object Relationships
Pattern: Representing Inheritance in a Relational Database
Pattern: Representing Collections in a Relational Database
Pattern: Object Identifier
Pattern: Foreign Key References
Pattern: Foreign Key versus Direct Reference

More details can be found in Crossing Chasms: A Pattern Language for Object-RDBMS Integration

There are other useful links:

Hibernate

Hibernate is a mature system following traditional view of O/R mapping, it also introduces innovations to streamline the mapping. Hibernate is originally developed for Java, but now it also support .NET from 2005.

Hibernate uses mapping metadata in the form of XML files, instead of specific interfaces or specicial wrapper object, and Hibernate API interact database through database APIs such as JDBC.

For instance, we have a class Customer[3] as follows:

public class Customer {
  private int customerNumber;
  private String name;
  private String Address;
  private String telephoneNumber;

  /* Accessors and other methods go here, such as "ordering_books". These are generally not
part of the class-to-table mapping process. Remember, the database is for storing the data of the class, not its behavior. */
}

Then, the mapping document in Hibernate is:

<hibernate-mapping>
  <class name="Customer" table="Customer" discriminator-value="P">
    <id name="id" column="CustomerId" type="long">
      <generator class="native"/>
    </id>
    <property name="name" column="Name" />
    <property name="streetAddress" column="Address" />
    <property name="telephoneNumber" column="TelephoneNumber" />
  </class>
</hibernate-mapping>

Every mapping document in Hibernate has a root bihernate-mapping, classes are specified by element class, in the class elements, children element property specifies persistent data of the class and the corresponding database columns.

An object c of class Customer can be saved to the database using code like the following [3]:

    Session session = getSessionFactory().openSession();
    Transaction tx = session.beginTransaction();
    session.save(c);
    tx.commit();
    session.close();

More details can be found in ORM Thesis

Some other useful links:

Service Data Object

Service Data Object(SDO) is a data programming architecture and an API. SDO provides a uniform way to access data from different data sources such as primitive data, XML data and relational database data. With SDO, application developers will not interact with data source. And only the persistent layer developer or mediation framework developer would deal data sources. Because of its ambitious goal, SDO can access more types of data than ordinary O/R mapping approaches.

SDO specifications provides:

Uniform access APIs to heterogeneous data sources
Support Multi-language (Java, C++, etc)
Maintains a disconnected data graph.
A dynamic APIs
Generate static APIs from the data source’s schema or UML.
Xpath based navigation through data graph
Change summary
Validations and constraints
Metadata access which is useful for tool builders.

Comparison

In Hibernate, developer usually begins development by working on the Java objects because Hibernate is a mapping framework. The object model becomes the center of your Hibernate universe. Active Record is a wrapping framework, so developer starts by creating a database table. The relational schema is the center of your Active Record universe. Active Record also includes some features that many Java frameworks don't have, such as model-based validation.Model-based validation lets developer make sure the data within the database stays consistent.

Reference

External Links

O/R Mapping Products

CSC/ECE 517 Fall 2007/wiki2 2 aa

Contents

Introduction

Object-relational Mapping

Implementations

ActiveRecord in Ruby

Crossing Chasms Pattern

Hibernate

Service Data Object

Comparison

Reference

External Links

Navigation menu

CSC/ECE 517 Fall 2007/wiki2 2 aa

Introduction

Object-relational Mapping

Implementations

ActiveRecord in Ruby

Crossing Chasms Pattern

Hibernate

Service Data Object

Comparison

Reference

External Links

Navigation menu

Search