Object-relational mapping

Poll without page-refresh

Article on other languages:

This article does not cite any references or sources. Please help improve this article by adding citations to reliable sources. Unverifiable material may be challenged and removed. (October 2008)

For another use of "ORM", see Object role modelling.

Object-relational mapping (aka ORM, O/RM, and O/R mapping) is a programming technique for converting data between incompatible type systems in relational databases and object-oriented programming languages. This creates, in effect, a "virtual object database," which can be used from within the programming language. There are both free and commercial packages available that perform object-relational mapping, although some programmers opt to create their own ORM tools.

1 Problem description
2 Non-SQL databases
3 Criticism
4 See also
5 References
6 External links

Problem description

Data management tasks in object-oriented (OO) programming are typically implemented by manipulating objects, which are almost always non-scalar values. For example, consider an address book entry that represents a single person along with zero or more phone numbers and zero or more addresses. This could be modeled in an object-oriented implementation by a "person object" with "slots" to hold the data that comprise the entry: the person's name, a list (or array) of phone numbers, and a list of addresses. The list of phone numbers would itself contain "phone number objects" and so on. The address book entry is treated as a single value by the programming language (it can be referenced by a single variable, for instance). Various methods can be associated with the object, such as a method to return the preferred phone number, the home address, and so on.

However, many popular database products such as SQL DBMS can only store and manipulate scalar values such as integers and strings organized within tables.

The programmer must either convert the object values into groups of simpler values for storage in the database (and convert them back upon retrieval), or only use simple scalar values within the program. Object-relational mapping is used to implement the first approach.

The crux of the problem is translating those objects to forms that can be stored in the database for easy retrieval, while preserving the properties of the objects and their relationships; these objects are then said to be persistent.

Non-SQL databases

Another solution would be to use an object-oriented database management system, which, as the name implies, is a database designed specifically for working with object-oriented values. Using an OODBMS would eliminate the need for converting data to and from its SQL form, as the data would be stored in its original object representation.

Object-oriented databases have yet to come into widespread use. One of their main limitations is that switching from an SQL DBMS to a purely object-oriented DBMS means you lose the capability to create SQL queries, a tried and tested method for retrieving ad-hoc combinations of data. For this reason, many programmers find themselves more at home with an object-SQL mapping system, even though most commercial object-oriented databases are able to process SQL queries to a limited extent.

Criticism

Some^[who?] have proposed that the promotion of object-relational mapping tools is symptomatic of an intent to solve the wrong side of the object-relational impedance mismatch issue. The information principle underpinning relational databases implies that object orientation itself is inadequate for the full needs of data manipulation, and it is that 'paradigm' as a whole that should be addressed. If this were the case, ORM would be left redundant. In this view, the "impedance mismatch" and the supposed need for object-relational mapping arises from the mistaken equation of object and relation (table or view in SQL speak). The correct mapping in the relational model is between object and type. Also, ORM systems tend to perform worse than writing SQL directly for more complex tasks. However, most ORM systems allow writing raw SQL to some degree.

Because of the complexity associated with high performance physical data models, it is often impossible to build any usable interface to a normalized relational database that is easily navigable by a naïve user. This is simply a consequence of the data normalization process, which tends to increase (sometimes substantially) the number of separate tables within a database. When interfacing with the database, multiple tables must therefore be merged (or joined) together to produce the user's single table view. Alternatively, information must be abstracted into data formats such as XML, which utilize data structures that are more easily managed by object oriented methodologies.

These needs are almost ubiquitous in the enterprise environment, even when ORM tools are not being used. This suggests that many, if not all, data driven systems with high level interfaces that are not "ORM" in name must implement ORM on some level (especially since many enterprise systems are built on object oriented frameworks such as Java). For example, a join operation on two related tables may be considered a type of object relational mapping since it merges lower level data tuples into a more easily navigable, higher order structure. Thus, a join is a way of hard-coding object relational logic into SQL.

ORM tools have been criticized for their tendency to eclipse the work done by Database Administrators for optimization and performance. This issue has been solved by most tools by redundantly allowing hard-coded SQL, stored procedure calling, and by implementing dirty solutions for data acquisition and insertion, such as transaction management. In addition, the convenience involved with caching custom selected data sets in memory using ORM methodologies makes the implementation of dirty solutions at the database level unnecessary in many environments.

In this context, an ORM tool is simply any tool that joins relational data in the context of a business object required for some real world application.