ObjectRelationalMapping

Last edit November 20, 2014
A PersistenceLayer connecting objects in an object-oriented system to data stored in a relational database. Most commonly, an SQL database is used (though strictly speaking, SQL does not implement the RelationalModel -- see SqlFlaws and RelationalLanguage for more details).

Using an ObjectRelationalMapping (ORM) allows one to cleanly apply object-oriented design, analysis, and programming techniques while hiding the specifics of dealing with the relational system.

There are commercial and OpenSource ORMs that comply to the ODMG and JDO standard APIs for object persistence. Programming against such a mapping is not different from programming against an ObjectOrientedDatabase.

Using such a ORM may be a good compromise between OO designers/architects insisting on pure object orientation without any data knowledge, and DBAs/managers emphasizing the shortcomings of OODBMSs.

-- ThomasMahler

A PrevalenceLayer is another option to forget database hassle.

See also the following:

Implementations:

Lists over 50 Object-SQL Mapping Tools,
ChrisDate and HughDarwen have much to say on this in TheThirdManifesto, ISBN 0-201-70928-7 -- ChanningWalton

Any opinions on the JavaLayeredFrameworks approach outlined by ToddLauinger? Has anyone tried something like this? -- BernardFarrell

Class structures don't map properly to relations. This is due to what Date calls the FirstGreatBlunder, that is, mapping objects or classes to SQL tables, instead of to user-defined data types.

If you map classes to user defined data types, this means that a cell can contain an object in the cell. This is TheMissedGreatBlunder because a struct or class is like a multi-cell row, and putting a multi-cell row inside a single cell, is a contradiction of relational! A row or struct contains multiple cells. Putting multiple cells inside a cell, is violating relational. Date and TheThirdManifesto hasn't got the final word on this; there are many unanswered questions and potential violations in their own proposed solution. If you map an object to a table, that object is accessible relationally; you can run queries on the tables (which were previously objects) and find data. If the object is located inside a cell on the other hand, that defeats the purpose of object relational mapping: the data is not accessible relationally, it's stuck inside the cell, like how an XML file can be placed inside a cell as a string.

{Putting a multi-cell row inside a single cell is not a contradiction of the RelationalModel. Please read TheThirdManifesto or AnIntroductionToDatabaseSystems again! The only "rule" is that each attribute of a tuple or relation be of a given type aka domain. That type may be arbitrarily complex and may be any type, including tuple and relation types. Don't let your experience of SQL DBMS limits colour your understanding of the RelationalModel.}

Consider a Cee struct which is very much like a class. Say we had a database that allowed Cee structs to be defined as types. Uh oh! You've just allowed a row (a struct is like a row) to be inserted inside a cell. Relational purism doesn't allow multiple cells inside a single cell. Relational doesn't allow sub tables inside cells.. the whole point of relational is that each cell is its own cell!

Object relational mapping tries to split the object up into cells, instead of putting the entire object in a single cell. So who is violating relational? Date and Darwen, laughingly, are the ones that are violating relational, by thinking that database types can be classes too. As a compromise, one could violate relational and allow structs and classes to be stored inside cells, similar to how we can store xml files inside cells. The database doesn't stop you from storing xml files inside a cell since an XML file is just a string; but since that XML file contains multiple cells and values inside it, it's kind of a contradiction/violation of relational - you cannot access the XML file data relationally if the xml file is stored inside a cell.

{Relation and tuple attribute types can be classes or XML DTDs; relation and tuple attribute values can be class instances or XML. This is not a violation of the RelationalModel.}

Or is it relations that do not map properly to classes? ORMs enforce a ontological approach to object programming and I have the feeling that this is not a good thing. -- EmmanuelDeloget

A sequence, as might be implemented by linked list, must be represented either by precedence (as in CREATE TABLE sequence (father INTEGER, child INTEGER);) or by a specific type... unfortunately SQL doesn't support user-defined types. Also one can have a "SequenceOrder" attribute that is a real number or integer. But linked lists are not an OO concept. Often times a time-stamp or auto-generated ID's can be used if it is to capture a temporal sequence.

See also: ObjectRelationalMappingCostsTimeAndMoney

I'm inclined to think current implementations of ORMs are anti-patterns since they are little languages and errors in the little languages aren't syntactically bound to compilation so you have to constantly go back and forth in the runtime to figure out what's wrong in your JPQL syntax for example. I agree with consolidating database access and avoiding scattered sql everywhere but I really don't like dealing with the mapping syntax. Mybatis is a better alternative although there are some similar issues there as well.

CategoryDataOrientation