CSC/ECE 517 Fall 2009/wiki3 12 sn

Patterns for Mapping Objects to Relational Databases

Introduction

Mapping Objects to Relational Databases is also referred to as Object-relational mapping or ORM. It is a programming technique for converting data between incompatible type systems in relational databases and object-oriented programming languages which creates a virtual object database that can be used from within the programming language [1]. The term "mapping" is used to refer to how objects and their relationships are mapped to the tables and relationships between them in a database [2]. The following figure shows a high-level depiction of ORM [XX]:

Fundamentals of Mapping

To understand mapping we must start with the class whose objects need to be mapped. An attribute of such a class will then be mapped to a single or multiple columns of a relational database table. The simplest form of mapping is the mapping of an attribute to a single column and both the entities being mapped have the same data type. For example, a date attribute is mapped to a date type column [2].

Patterns in ORM

There are several patterns or techniques used to implement ORM in different situations. Let us see some of them in detail.

Concrete Table Inheritance

In this technique, each "concrete" class is mapped to its own table such that both the attributes implemented by the class and its inherited attributes are mapped to the table. A class is called concrete when objects are instantiated from it and is not just an abstract class used for inheritance [2]. Following is an example to explain this technique. There are tables corresponding to each of the Footballer and Cricketer classes because they are concrete but not Player because it is abstract. Each table has its own primary key and to add a new Bowler class a corresponding table is created with all of the attributes required by the Bowler objects [3].

Class Table Inheritance

In this technique, one table is created for every class with one column for every business attribute and any necessary identification information [2]. The following figure illustrates this pattern. Here as opposed to the earlier pattern, we have created one table for every class including the abstract class Player [4]. This pattern is important as it solves the problem of object-relational mismatch since relational databases don't support inheritance so links across the inheritance structure are possible by creating separate tables [4].

References

[1] http://en.wikipedia.org/wiki/Object-relational_database
[2] http://www.agiledata.org/essays/mappingObjects.html
[3] http://martinfowler.com/eaaCatalog/concreteTableInheritance.html
[4] http://martinfowler.com/eaaCatalog/classTableInheritance.html

[] www.adobe.com/newsletters/edge/october2008/articles/article2/images/fig2.jpg