CSC/ECE 517 Fall 2007/wiki2 2 aa

From Expertiza_Wiki
Jump to navigation Jump to search

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

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 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. Hibernate is originally developed for Java, but now it also support .NET from 2005.

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.

Useful links includes

introduction to SDO from IBM

wikipedia SDO

Java Data Objects

The Java Data Objects (JDO) API is a standard interface-based Java model abstraction of persistence, developed under the auspices of the Java Community Process. Benefits of Using JDO for Application Programming. Source from Sun website

Ease of use: Application programmers can focus on their domain object model and leave the details of persistence (field-by-field storage of objects) to the JDO implementation.

Portability: Applications written with the JDO API can be run on multiple implementations without recompiling or changing source code. Metadata, which describes persistence behavior external to the Java source code including most commonly used features of O/R mapping, is highly portable.

Database independence: Applications written with the JDO API are independent of the underlying database. JDO implementations support many different kinds of transactional data stores, including relational and object databases, XML, flat files, and others.

High performance: Application programmers delegate the details of persistence to the JDO implementation, which can optimize data access patterns for optimal performance.

Integration with EJB: Applications can take advantage of EJB features such as remote message processing, automatic distributed transaction coordination, and security, using the same domain object models throughout the enterprise.

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. Jeffrey M. Barnes in Object-Relational Mapping as a Persistence Mechanism for Object-Oriented Applications indicates that Hibernate is a mature traditional O/R mapping, it uses mapping metadata in the form of XML files, instead of specific interfaces or special wrapper object.

Active Record is a wrapping framework, so developer starts by creating a database table. The relational schema is the center of the 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.

Crossing Chasms is a pattern language for Object-RDBMS integration, which contains several patterns to transform object to relational database according to different situation and different object values. Like other ORM, Crossing Chasms pattern focuses on how to how to transform between data and objects, however, it also includes other issues related to the mapping procedure, such as Table Design Time Pattern, which discuss when to design the database table schema.

Service Data Object aims to provide a uniform way to access heterogeneous data, unlike the method or patterns mentioned above, it can not only map to relational database data, but also other types of data.

Application programmers using Java Data Objects can focus on their domain object model and leave the details of persistence to JDO implementations, while Crossing Chasms specifies details how to mapping between database and objects.

In one word, different OR mappings has different advantages and limitations, developers will have to choose the appropriate OR mapping tools according to the project requirement and their skill set as well.

Reference

  1. Wikipedia Definition
  2. Foundations of Object-Relational Mapping
  3. ORM Thesis
  4. Crossing borders: Exploring Active Record
  5. SDO2.0 specifications
  6. Object-to-Relational Mapping: The Crossing Chasms Pattern and Implementation Considerations
  7. Crossing Chasms: A Pattern Language for Object-RDBMS Integration
  8. Crossing Chasms: The Architectural Patterns
  9. Crossing Chasms
  10. Java Data Objects (JDO)

External Links

  1. O/R Mapping Products
Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2007/wiki2_2_aa&oldid=8148"