Danev| MFinance| JFW| Mail| MobilePark| HandyFx| TopShop| Dantest     
JFrameworkWeb SearchDownloadNewslettersFirm Profile

  Menu


    What is a Framework
    Framework Objectives
    Developing a Framework

    Architecture
    J2EE App Architecture
    Physical Architecture

    App Building Approaches
    Structuring Web App
    Components Manager
    Object Relational Mapping  

    Online Documentation

    Glossary

    News
    Download
    Message Board
    Contacts

  Summary

  A framework is a set of common and prefabricated software building blocks that programmers can use, extend or customize for specific computing solutions. With frameworks developers do not have to start from scratch each time they write an application. Frameworks are built from collection of objects so both the design and code of the framework may be reused.

 



Object Relational Mapping   
 You Are Here: Home > Object Relational Mapping


The ORM problem

Relational databases and object orientation are not entirely compatible. They represent two different views of the world: in an RDBMS, all you see is data; in an Object-Oriented system, all you see is behavior. It is not that one perspective is better than the other: the Object-Oriented model tends to work well for systems with complex behavior and state-specific behavior in which data is secondary, or systems in which data is accessed navigationally in a natural hierarchy (e.g. bills of materials). The RDBMS model is well suited to reporting applications and systems in which the relationships are dynamic or ad-hoc.

A lot of data is stored in relational databases, and if Object-Oriented applications want access to that data, they need to be able to read and write to an RDBMS. In addition, Object-Oriented systems often need to share data with non-Object-Oriented systems. It is natural, therefore, to use an RDBMS as the sharing data store.



ORM Implementation

There is a great divergence between the OO and RDB models as the objective of relational database development is to normalize data whereas the goal of the OO design is to encapsulate increasingly complex behavior. The divergence of these two perspectives - data and behavior - leads to be need for mapping between related elements in the two models.



1. Every row in the tables is regarded as an object. A column in a table is equivalent to a persistent attribute of a class (keep in mind that a persistent class may have transient attributes). So, in the simple case where we have no associations to other classes, the mapping between the two worlds is simple. The data type of the attribute corresponds to one of the allowable data types for columns. For each persistent attribute, additional information is required to appropriately model the persistent object in a relational data model.

2. Rows in tables need to have unique identity; they are uniquely identified by their primary key values. The primary key should be identified in order to be used as a reference to a row in this table from other tables, and it will uniquely identify the row/object for searches.

3. Handling foreign key dependencies. For each foreign-key relationship in the table, create an association between the associated classes, removing the attribute from the class, which mapped to the foreign-key column. If the foreign-key column was represented initially as an attribute, remove it from the class.

4. Treating many-to-many relationships. RDBMS data models represent many-to-many relationships with what has been called a join table, or an association table. These tables enable many-to-many relationships to be represented using an intermediate table, which contains the primary keys of two different tables that may be joined together. The reason join tables are needed is because a foreign key reference can only contain a reference to a single foreign key value; when a single row may relate to many other rows in another table, a join table is needed to associate them.

5. The correspondence between the OO and relational model are achieved in two ways:

a. using a naming convention between the tables/field names and the class/attributes names. E.g., by means of the Java reflection API we can find the table (if any) possessing the same name as the name of the class, instantiated by given object

b. storing metadata defining the mapping between tables/field names and the class/attributes names. It is important to note, that one object can be mapped onto several field sets from different tables, as presented in the next figure. Three of the attributes of Class A are mapped into three of the fields of three DB tables, while one of the attribute (attr4) is transient has no mapping into the DB storage. The instances of Class A (Object 1 and Object 2) have their attributes containing data that map to the corresponding data in the DB tables, regarding the correct table, column and row.



2002 Frontior Technologies. All Rights Reserved.
QWave.com QBioscan.com QSART.com QANS.com QMedical.com AutonomicTest.com QHRV.com QAthlete.com Medeia.com Dantest.com 11.24.17