CSC/ECE 517 Fall 2007/wiki2 2 d4: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
No edit summary
Line 12: Line 12:
Figure 1. Position of ORM Layer in Database Architecture
Figure 1. Position of ORM Layer in Database Architecture


In addition to mapping data structures in ORM, object-oriented concepts often need to “bridge the chasm” between the object layer and the database layer. These concepts include: inheritance, aggregation, polymorphism, and class associations[[#References|<sup>6</sup>]].
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[[#References|<sup>6</sup>]]. This conceptual difference between the database structure and o-o data storage is known as the [http://en.wikipedia.org/wiki/Object-Relational_impedance_mismatch impedance mismatch,]which can create a fragile bridge across the chasm. A solution to this problem would be to create [http://en.wikipedia.org/wiki/OODBMS 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 [http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software 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[[#References|<sup>6</sup>]].
There have been [http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software 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[[#References|<sup>6</sup>]].

Revision as of 19:52, 23 October 2007

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 encapsulation6. 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 performance6.


Why these techniques are necessary?

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

Definition

Need

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.


Popular Products

These patterns in practice can be found in

Hibernate

Oslick

Data Mapper

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

Perl's DBIx::Class

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)
Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2007/wiki2_2_d4&oldid=6929"