Introduction to the term "ORM"

In enterprise applications we have many objects that we want to be persistent, i.e. we want their existence beyond system restarts. For it to happen one should be able to store the object state to some persistent storage and reconstruct the object from the state whenever needed. One object is a simple case, Its very usual that we need to store a whole object graph that we want to recover later.

Relational databases have been used to store data, and the technology is mature, hence its the natural choice for storing object state in relational databases.

Relational databases expose SQL based API for interaction. In java, one can use JDBC to create SQL queries, bind arguments to parameters, initiate execution of the query, scroll through the query results, retrieve values from the result-set and so on. These are very low level data access tasks; and as application developer one is more interested in solving the business problem rather than data access. So came the concept of persistence layer which should abstract all the details of data access and provide an API to business layer to deal just with the objects and not with low level stuff such as result-sets.

Let us look at some of the problems that the persistence layer faces due to paradigm mismatch between the object view and relational view of the world.

The Problem of Granularity:
If one object contains another object of different type(one and only one instance, noone else contains objects of this type). Should we create two different tables for both types or just one table having columns that take care of columns from both.

The Problem of subtypes:
How do we model inheritance in relational database.

The problem of associations:
How do we model one-to-many, many-to-many relationships.

The problem of object graph navigation:
Abstracting out the details of data access so that biz layer can navigate objects graphs in natural object oriented way like aUser.getBillingDetails().getAcoountNumber() rather than using SQL join queries.

If the application is simple enough then we can model our system relationally or may handcode the persistence layer with SQL/JDBC. Other solutions are serialization, EJB entity beans or using object-oriented database systems rather than relational databases.

ORM(Object-Relational mapper) is an attempt to create a generic piece of software that can take care of all the persistence related issues mentioned above.
It is the automated(and trasparent) persistence of objects in an application to the tables in a relational database, using metadata that describes the mapping between the objects and the database tables. ORM is supposed to provide atleast following things..

• An API for performing basic CRUD operations on objects of persistent classes.
• A query language based on the persistence classes and their properties.
• Facilities for specifying mapping metadata.
• Various optimization facilities like lazy association fetching, caching, automatic syncing of object state with same in database.

For an application that has to scale, even above is not sufficient. One also needs to think about multi-tenancy and partitioning.

(Potential)Advantages of Using ORM: Productivity, Maintainability, Performance and Vendor Independence

Reference: Chapter 1, Hibernate in Action