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,

  • Ruby - Ruby-on-Rail(ActiveRecord)
  • Java - JactiveRecord, ARJ, ActiveMapper
  • .NET - Castle Project

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,

Conclusion

Links

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