Object-relational mapping

From Wikipedia, the free encyclopedia

Object-Relational mapping (aka O/RM, ORM, and O/R mapping), is a programming technique for converting data between incompatible type systems in databases and Object-oriented programming languages. In effect, this creates 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.

Contents

[edit] The problem

In object-oriented (OO) programming, data management tasks are typically implemented by manipulating objects, which are almost always non-scalar values. To illustrate, consider the example of an address book entry, which represents a single person along with zero or more phone numbers and zero or more addresses. In an object-oriented implementation, this could be modeled 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 products, 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 in translating those objects to forms which can be stored in the database, and which can later be retrieved easily, while preserving the properties of the objects and their relationships; these objects are then said to be persistent.

[edit] Implementations

The most common type of database used is the SQL database, which predates the rise of object-oriented programming in the 1990s. SQL databases use a series of tables to organize data. Data in different tables is associated through the use of declarative constraints, rather than explicit pointers or links. The same data that can be stored in a single object value would likely need to be stored across several of these tables.

An object-relational mapping implementation would need to systematically and predictably choose which tables to use and generate the necessary SQL.

Many packages have been developed to reduce the tedium of developing object-relational mapping systems by providing libraries of classes which are able to perform mappings automatically. Given a list of tables in the database, and objects in the program, they will automatically map requests from one to the other. Asking a person object for its phone numbers will result in the proper query being created and sent, and the results being translated directly into phone number objects inside the program. [1]

From a programmer's perspective, the system should look like a persistent object store. One can create objects and work with them as one would normally, and they automatically end up in the database.

In practice, however, things are never quite that simple. All O/RM systems tend to make themselves visible in various ways, reducing to some degree one's ability to ignore the database. Worse, the translation layer can be slow and inefficient (notably in terms of the SQL it writes), resulting in programs that are slower and use more memory than code written "by hand."

A number of O/RM systems have been created over the years, but their effect on the market seems mixed. Considered one of the best was NeXT's Enterprise Objects Framework (EOF), but it failed to have a lasting impact on the market, chiefly because it was tightly tied to NeXT's entire toolkit, OpenStep. It was later integrated into NeXT's WebObjects, the first object-oriented Web Application Server. Since Apple Computer bought NeXT in 1997, EOF provides the technology behind the company's e-commerce Web site, the .Mac services and the iTunes Music Store. Apple provides EOF in two implementations: the Objective-C implementation that comes with the Apple Developers Tools and the Pure Java implementation that comes in WebObjects 5.2. Inspired by EOF is the open source Apache Cayenne. Cayenne has similar goals to EOF and aims to meet the JPA standard.

An alternative approach is being taken with technologies such as RDF and SPARQL, and the concept of the "triplestore". RDF is a serialization of the subject-predicate-object concept, RDF/XML is an XML representation of it, SPARQL is an SQL-like query language, and a triplestore is a general description of any database that deals with a triple.

More recently, a similar system has started to evolve in the Java world, known as Java Data Objects (JDO). Unlike EOF, JDO is a standard, and several implementations are available from different vendors. The Enterprise Java Beans 3.0 (EJB3) specification also covers this same area. There has been standards conflict between the two standards bodies in terms of pre-eminence. JDO has several commercial implementations, while EJB 3.0 is still under development. However, most recently another new standard has been announced by JCP to bring these two standards together and make the future standard something that works with various Java architectures. Another example to mention is Hibernate (Java), the most used framework of O/R mapping in the Java world that has inspired the EJB3 specification.[verification needed]

In the Web framework Ruby on Rails, object-relational mapping plays a central role and is handled by the ActiveRecord wrapping tool. A similar role is played by the DBIx::Class module for the Perl based Catalyst (software) framework, although many other choices are possible.

[edit] Non-SQL databases

Databases such as Caché do not require manual ORM. SQL access to non-scalar values is already built in. Caché allows the developer to design any combination of OO and table structured storage within the database instead of resorting to external tool sets.

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.

[edit] Critique

Some 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 was 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.

[edit] See also

[edit] External links