CSC/ECE 517 Fall 2009/wiki3 12 Patterns for ORM: Difference between revisions
Line 1: | Line 1: | ||
=='''Overview'''== | =='''Overview'''== | ||
[http://en.wikipedia.org/wiki/Object-relational_mapping Object-relational mapping] is not trivial. Apart from being based on Software Engineering principles like coupling, cohesion and polymorphism, the object paradigm focuses on building applications out of objects that have both data and behavior. However, the relational paradigm is based on mathematical principles and focuses primarily on storing data. If only data objects were to be mapped to the relational database the procedure would have been fairly straightforward. With the growing complexities of object models, concepts like aggregation, inheritance, polymorphism, association between classes, and data type (smarted than SQL data types) have to be mapped to relational table structure. The table below highlights the fundamental mismatch between object oriented data model and relational data storage. | [http://en.wikipedia.org/wiki/Object-relational_mapping Object-relational mapping] is not trivial. Apart from being based on Software Engineering principles like coupling, cohesion and polymorphism, the object paradigm focuses on building applications out of objects that have both data and behavior. However, the relational paradigm is based on mathematical principles and focuses primarily on storing data. If only data objects were to be mapped to the relational database the procedure would have been fairly straightforward. With the growing complexities of object models, concepts like aggregation, inheritance, polymorphism, association between classes, and data type (smarted than SQL data types) have to be mapped to relational table structure. The table below highlights the fundamental mismatch between object oriented data model and relational data storage. | ||
{|border="2" cellspacing="0" cellpadding="4" width="50%" align="center" | |||
|- | |||
|align="center"|'''OODM''' | |||
|align="center"|'''RDBMS''' | |||
|- | |||
|align="center"|Class | |||
|align="center"|Table | |||
|- | |||
|align="center"|Object | |||
|align="center"|Row | |||
|- | |||
|align="center"|Entity | |||
|align="center"|Key | |||
|- | |||
|align="center"|State | |||
|align="center"|Data | |||
|- | |||
|align="center"|Behavior | |||
|align="center"|Transactions | |||
|- | |||
|align="center"|Inheritance | |||
|align="center"|Data Relationships | |||
|} | |||
=='''[http://docs.jboss.org/hibernate/core/3.3/reference/en/html/inheritance.html Inheritance Mapping]'''== | =='''[http://docs.jboss.org/hibernate/core/3.3/reference/en/html/inheritance.html Inheritance Mapping]'''== |
Revision as of 18:13, 17 November 2009
Overview
Object-relational mapping is not trivial. Apart from being based on Software Engineering principles like coupling, cohesion and polymorphism, the object paradigm focuses on building applications out of objects that have both data and behavior. However, the relational paradigm is based on mathematical principles and focuses primarily on storing data. If only data objects were to be mapped to the relational database the procedure would have been fairly straightforward. With the growing complexities of object models, concepts like aggregation, inheritance, polymorphism, association between classes, and data type (smarted than SQL data types) have to be mapped to relational table structure. The table below highlights the fundamental mismatch between object oriented data model and relational data storage.
OODM | RDBMS |
Class | Table |
Object | Row |
Entity | Key |
State | Data |
Behavior | Transactions |
Inheritance | Data Relationships |
Inheritance Mapping
Inheritance in Object Oriented Design makes it difficult to map between object and relation databases. In this pattern, there is mapper class for each domain class that will save and load data for the domain class [8]. Mapper class allows both abstract and concrete classes to handle their own O/R mapping[8].
For example: - To find an employee “John”:- Application calls find () method on concrete mapper object and instantiate a new Executive object. The find () will pass this executive object and database record to load () of Executive. This in turn will call the load () of Superclass. When all loads return, find returns the filled object. Mappers loading and saving the domain objects is determined by the inheritance mapping. This inheritance hierarchy is represented in the database as follows:-
- Single Table Inheritance
- Class Table Inheritance
- Concrete Table Inheritance
Choosing a mapping scheme depends on speed requirement, whether database is shared and type of RDBMS.
Single Table Inheritance
Inheritance Hierarchy of all classes is represented as single table. The columns of this table will have fields of all classes in the hierarchy. Advantage of this Inheritance is that there is one table and requires no join while retrieving data. But it could lead to large confusing table and name conflicts.
Class Table Inheritance
One table for each class is constructed. The advantage of this table inheritance is that there is clear relationship between class and table. There is high normalization. But multiple tables requires join and when fields move up and down in hierarchy, it requires changes in the tables.
Concrete Table Inheritance
In this hierarchy there is one table per concrete class. The table are independent, requires no join and there is no unused fields.