Object–relational mapping

Object-relational mapping is a programming technique that links relational databases to object oriented language concepts.

In the object oriented programming methodology, objects represent real-world objects to some degree. To illustrate, consider the example of an address book, which contains listings of people along with zero or more phone numbers and zero or more addresses. In the OO world this would be represented by a "person object" with "slots" (fields, members, instance variables etc.) to hold the data that makes up this listing -- the persons name, a list (or array) of phone numbers, and a list of addresses.

The trick comes when it's time to save that data out to permanent storage. From a programmer's perspective, the best solution is a persistant object store, into which any object can be placed and later found. This is a perfectly usable solution in most situations in fact, and most programs use some form of object store, typically one in the form of a binary file.

However for larger applications the store has to be considerably more powerful. Even minor damage to a simple file can render the entire file unusable, which makes it less than useful for real-world applications. In addition it becomes progressively more expensive to find information in such a store as the total number of objects -- or more generally, the total amount of data -- grows.

The solution to these sorts of data storage problems already exist, they are databases. However almost all database systems pre-date the object revolution that occured in the 1990's, and they tend to "map" poorly into the OO world because they are based on a completely different set of concepts.

The best solution would be to use an object database, which, as the name implies, is a database designed specifically to look and work with object programs. However these databases have a serious credibility problem in the "big iron" world of databases, and the programmers typically don't have the power to select the tool they want to use. They are forced -- directly or indirectly -- to use relational databases instead.

Traditional relational databases use a series of tables representing simple data. Optional or related information is stored in other tables. A single record in the database often spans several of these tables, and requires a join to collect all of the related information back into a single piece of data for processing. This would be the case for the address book, which would likely include at least a user and address table, but perhaps even a phone number table as well.

In the object world there is a clear sense of "ownership" where a particular person object owns a particular phone number. This is not the case in the relational database, where the tables have no idea how they related to other tables. Instead the user must construct a "query" to gather the information back together.

Doing this is not a simple task. Due to the complexities of relational databases, it can be very expensive to ask it several questions in a row. You can't, for instance, expect good performance if you do a series of operations like "find this user, ok, now find this users addresses, ok...". Instead you have to construct a single large query that in effect says "find all the addresses and phone numbers for this user and return them in this format.

And after construction of the query, the data returned has to be copied into the fields in the objects in question. You might wonder why you can't do this in three steps, and the basic answer is that relational databases will perform very poorly if you do -- simply asking a question is often more expensive than the answer so it's best to collect up all of the data you'll need in a single complex query.

Given these two very different worlds, object code for working with databases tends to be very complex and bug-ridden.

Object-relational systems attempt to solve this problem by providing software to do this mapping for you. Given a list of tables in the database, and objects in the program, they will automatically map requests from one to the other. Ask a person object for its phone numbers will magically result in the proper query being created and sent, and the results being magically translated directly into Address objects inside your program.

The main advantage to the O-R system is that it allows you to ignore the database. From the programmer's perspective the system looks like a persistant object store. You create objects and work with them as you would normally, and they magically end up in your relational database.

Things are never that simple though. All O-R systems tend to make themselves visible in various ways, reducing your ability to ignore the database to some degree. Worse, the translation layer can be slow and ineffecient (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-R systems have been created over the years, but their effect on the market seems mixed. One of the best was NeXTs Enterprise Objects Foundation, but it failed to have a lasting impact on the market because it was tighly tied to their entirely toolkit, OpenStep.