CSC/ECE 517 Fall 2009/wiki3 12 sn: Difference between revisions
No edit summary |
No edit summary |
||
Line 35: | Line 35: | ||
[[Image:identity.gif|center]] | [[Image:identity.gif|center]] | ||
===Lazy Initialization=== | |||
Line 48: | Line 51: | ||
[5] http://martinfowler.com/eaaCatalog/foreignKeyMapping.html <br /> | [5] http://martinfowler.com/eaaCatalog/foreignKeyMapping.html <br /> | ||
[6] http://martinfowler.com/eaaCatalog/identityField.html <br /> | [6] http://martinfowler.com/eaaCatalog/identityField.html <br /> | ||
[7] http://martinfowler.com/eaaCatalog/lazyLoad.html <br /> | |||
[] www.adobe.com/newsletters/edge/october2008/articles/article2/images/fig2.jpg <br /> | [] www.adobe.com/newsletters/edge/october2008/articles/article2/images/fig2.jpg <br /> |
Revision as of 19:38, 18 November 2009
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].
Foreign Key Mapping
In any object oriented system, objects are connected to each other via object references which provide for different interactions between these objects in the system so if these objects were to be mapped to a database then its important to map the references as well [5]. To accomplish this a Foreign Key Mapping is used which maps an object reference to a foreign key in the database and thus maintains the relationships in the relational databases [2,5]. A foreign key is a data attribute that appears in one table and may be coincidental with the key of another table [2]. Several relationships may exist between two tables: one-to-one, one-to-many, many-to-one or many-to-many. A one-to-many relationship between Artist and Album is shown in the figure below where the artistId in Albums is the foreign key from the Artists table and connects the two tables together and can be used to retrive the required data by using sql joins [5].
Identity Field
In an object oriented system, individual objects can be easily differentiated as the object system ensures the correct identity with the help of say, raw memory locations [6]. But this is not the case with relational databases and so to be able to differentiate between different rows of a table we need a key which is called a primary key. This is required in order to tie the database to the in-memory object system so that both read and writes are correctly done [6]. So to achieve this, the identity field pattern stores the primary key of the relational database table in the object's fields [6]. An example can be seen in the figure below [6].
Lazy Initialization
Comparisons of the Patterns
External Links for Further Reading
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
[5] http://martinfowler.com/eaaCatalog/foreignKeyMapping.html
[6] http://martinfowler.com/eaaCatalog/identityField.html
[7] http://martinfowler.com/eaaCatalog/lazyLoad.html
[] www.adobe.com/newsletters/edge/october2008/articles/article2/images/fig2.jpg