CSC/ECE 517 Summer 2008/wiki3 1 ar

From Expertiza_Wiki
Jump to navigation Jump to search

WIKI Topic - RDB/OO patterns

It would be good if OO programs could interact with OO databases, but alas, relational databases have a 99% market share. This has led to many attempts to access them from OO languages. Design patterns for doing this have been developed, starting with Crossing Chasms and extending to Rails' ActiveRecord [1][2]. Here, we investigate the various approaches for marrying OO programs to relational databases, comparing them in terms of ease of programming, robustness, and efficiency.

Introduction

This article deals with merging two software development models. Most of data are already stored in relational databases that are modeled around relational models. But all new development is being done in some Object Oriented language. Software design patterns are providing a solution in terms of ORM (Object Oriented Mapping) to merge these two models.

In this article first I will set the stage by giving some background information about the relational model and object oriented models and their differences. After this I will briefly discuss the philosophical approaches to merge them together. By then user should have a good understanding of the problem and techniques to solve it, now it is time to show some design patterns that solve this problem in very elegant way. I will pick two major design patterns that are mostly used by development teams.

Relational Vs Object-Oriented Models

Relational Models

This model deals with data structure and suggests the relational theory to organize it. It was proposed by Edgar Codd in 1969. It is the foundation of every modern database. It defines a logical view of data based on two concepts.

  1. Domain/data type
  2. Relations

The domain simply represents a set of values which is equivalent to data type in programming languages. A relation over the domain D1, D2, …, Dn is simply a subset of the Cartesian product; usual notation is R “include in” D1xD2x…xDn. An element of a Cartesian set is called a tuple. So we could say "A database is a collection of relation valued variables, together with set of integrity constraints that the data must satisfy."

Object-Oriented Models

Orient-Oriented models consist of objects that have both data and behavior. They usually represent the real word better than rational models do. There are lots of general purpose object oriedned languages available to support such type of model. Now days most of development done through this approach.

Differences between Relational Vs Object-Oriented Models

The Object-oriented models are based on the best practices of the latest software engineering principles where as relational models are based on proven mathematical principles. You find more impedance when you actually try to follow one model. In Object Oriented models, objects traverse through their relationships with other objects whereas in relational model you join rows of data. That makes them two totally different approaches. Following is an example of such two cases,

Relational Model example (Customer and Customer Address)

Object Oriented Model example (Customer and Customer Address)

Mismatches

1. Encapsulation

OO models have the concept of encapsulation where object states are hidden from the outside world but there is no such thing in relational model. All data elements are available to every one in a relational model.

2. Data type differences

Data type system is another big difference. Databases don’t support pointers where OO model embrace then on a high level. String is one example, in OO Model size of String is based on available memory but in relational databases the developer has to define the maximum allowable length. Such restrictions make it difficult for an OO model to talk with backend database system.

3. Structural and integrity differences

OO Models support nesting and tree like structure where as relational models are restricted to only rows and columns. Constraints on implementation are also different between relational model and OO model.

4. Manipulative differences

Relational model has fix well define set of operation to query and manipulate the data, where OO model doesn’t have a generic operations. OO model has to define all operations at a very low level.

5. Transactional differences

This is the place where OO is weaker then relational model. In database if is much easier to dynamically bind data manipulation operations as units of work where as in OO model such a thing doesn’t exists.

Techniques for merging Relational and OO models

So now we agree that relational model and OO model are totally different approaches. So how do we built the system where these two model need to be combined? Here I will discuss high level approaches to show how to merge these two competing approaches together,

Minimize the differences

Don’t go to that direction where these approaches separate out. Just work on those parts where these approaches agree with each other. One solution is in form of Object-Oriented Database Management Systems (OODBMS). In this approach OO model are getting special database to solve their persistence problem. Due to lack of support of data models this techniques is not widely use by the development community. Other approach is to layer your application into different concern. All latest software development is based on this approach. In this technique application is divided into multiple layers of functionality.

Compensation

In this technique developers use reflection or code generation techniques to overcome the deficiencies of each approach (Relational and Object Oriented). Using a reflection object could establish the link between table and an object’s properties. Using this approach, the links will be stored into database (ActiveRecord). Other technique is based on code generation, where one could either by looking at relational mode generate OO model or through OO model to relation model. This also generates typical data manipulation methods (CRUD – Create, Read, Update, and Delete) to provide OO model generic data manipulation capabilities.

Object/Relational Mapping (ORM) Patterns

As design patterns provide number of solutions to deal with different type of challenges in software design, they also play a major role in establishing a link between database and OO model. This approach commonly refered to as ORM (Object/Relation Mapping). There are number of tools both open source and commercial available to facilitate this approach.

Active Record Pattern

Introduction

This is the simplest way of accessing database through Objects. It deals the problem of ORM with second technique of merging OO Model and Relational Model (Minimize the differences). By using a power of reflection object could find the relationship between table columns and its properties. Using code generation it adds data manipulation capabilities.

In this pattern a database table or view is wrapped into a class, thus an object actually represents a single row in the table. A new object when persistent actually creates a new row in the table. The object has accessor methods for each column in the table and methods for CRUD operations.

Example

ROR (Ruby-on-Rails) has strong support for Active Record pattern; following example shows the simplicity and power of Active Records,

Here developer has extended a class Employee from ROR ActiveRecord class. 

 class Employee < ActiveRecord::Base; end

ROR will automatically map this object to the “employee” table. 

 Create table employees(
   id:int,
   first_name varchar(100),
   last_name varchar(100),
   email varchar(100),
   PRIMARY KEY (id)
 );

Now let’s create a new employee, 

 employee = Employee.new(:first_name=> ‘Ben’, :last_name=>’Powel’, :email=> ‘ben@company.com’)
 employee.save

In backend ROR framework actually created the following SQL statement to store this new employee into database, 

 insert into employee (first_name, last_name, email) values (‘Ben’, ‘Powel’, ‘ben@company.com)

Now searching for the same object is also easy, 

 employee = Employee. find(:condition=> “first_name = ‘Ben’”)

This code generate following sql statement in the backend, 

 select * from employees where first_name = ‘Ben’

Frameworks/Library support

All major Object Oriented languages have some kind framework to support this pattern. Some of them are really sophisticated like the Ruby-On-Rails implementation that generates dynamic methods to support complex criteria for accessing the data. Here are few of them,

Pros

  • Simple to implement
  • Good for existing database with new applications
  • Less time spend on OO modeling
  • Good choice for simple problems

Cons

  • Centered around Data Modeling
  • Not use full capabilities of OO modeling
  • Too simple for complex models

Data Access Object (DAO) Pattern

Introduction

This the second most commonly used design pattern for ORM. It actually also picks the second technique from merging OO model and relational model (Compensation). It addresses the issues that are missing from OO model related to database persistence with the help of more code. This code could come from some framework (Hibernate) or by adding some utility classes. This pattern also works will the layer approach for application development, where persistence layer is based on this pattern.

This pattern suggests creating additional objects to encapsulate all the data access logic. DAO (Data Access Objects) are responsible for connecting to the data source (which could be a relational database or XML or web services or files) and for the retrieval of data. Most of the time this pattern also uses the TransferObject/ValueObject pattern to move data between business layer and DAO object. The following is UML diagram that relationship more clearly,

Example

Hibernate is a very good implementation example of DAO design pattern. It has actually gone beyond simple implementation of DAO and now supports its own query language. It is hard to up come with some simple example in it as it requires lot of configuration steps. The Hibernate website has a nice tutorial to walk you through all configuration steps. I will only demo code that uses a properly setup hibernate application.

In order to support the transparent cache and other optimizations, hibernate uses a session . One has to get a session first to perform any CRUD operations. The following is an example of object persistence, 

   private void createAndStoreEvent(String title, Date theDate) {

       Session session = HibernateUtil.getSessionFactory().getCurrentSession();
       session.beginTransaction();
       Event theEvent = new Event();
       theEvent.setTitle(title);
       theEvent.setDate(theDate);
       session.save(theEvent);
       session.getTransaction().commit();
   }

This code stores new event to backend database.

Framework/Library support

Pros

  • Supports full OO modeling approach in layered application.
  • Allows object persistence to be easily coupled with business logic
  • Hides the complexities associated with database manipulation (no SQL)
  • Through some framework support, it could be transparent.
  • It supports more persistence options in addition to a relational database (XML, files, Web service etc.).

Cons

  • Hard to implement but with support of latest frameworks it is getting quite easy
  • It requires layer approach for application design.
  • Not suitable for simple solution.
  • It doesn’t easily support working on existing database with complex model (with long tree of objects).

Conclusion

There are number of good solutions available in the form of design patterns to address the ORM issues. A developer has to be careful using one of those patterns. One solution based on Active Record might not be feasible on other application that involves a complex object model. Although frameworks based on these patterns are evolving and these are addressing new issues very effectively, still Object persistence is a major issue in application performance. Some languages are started evolving in this direction. Microsoft LINQ is such an example that is extended the language to solve this problem.

Links

Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Summer_2008/wiki3_1_ar&oldid=15873"