Object–relational mapping: Difference between revisions

Revision as of 11:41, 7 August 2007

Latest revision as of 09:43, 29 July 2025

(648 intermediate revisions by more than 100 users not shown)

Line 1:

{{short description|Programming technique}}

:''Not to be confused with [[Object role modelling]].''

{{Distinguish|Object–role modeling}}

'''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. 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.

{{Use dmy dates|date=June 2019}}

{{More citations needed|date=May 2009}}

'''Object–relational mapping''' ('''ORM''', '''O/RM''', and '''O/R mapping tool''') in [[computer science]] is a [[Computer programming|programming]] technique for converting data between a [[relational database]] and the memory (usually the [[Memory management#HEAP|heap]]) of an [[Object-oriented programming|object-oriented]] programming language. This creates, in effect, a virtual [[object database]] that can be used from within the programming language.

In [[object-oriented programming]], [[data management|data-management]] tasks act on [[object (computer science)|object]]s that combine [[scalar (computing)|scalar]] values into objects. 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 (computer science)|object]]" with an [[attribute (computing)|attribute/field]] to hold each data item that the entry comprises: the person's name, a list of phone numbers, and a list of addresses. The list of phone numbers would itself contain "PhoneNumber objects" and so on. Each such address-book entry is treated as a single object by the programming language (it can be referenced by a single variable containing a pointer to the object, for instance). Various [[Method (computer programming)|methods]] can be associated with the object, such as methods to return the preferred phone number, the home address, and so on.

==Problem description==

Data management tasks in object-oriented (OO) programming are typically implemented by manipulating [[Object (computer science)|objects]], which are almost always non-scalar values. 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. This could be modeled in an object-oriented implementation by a "person [[object (computing)|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.

By contrast, relational databases, such as [[SQL]], group scalars into [[tuples]], which are then enumerated in [[Table (database)|tables]]. Tuples and objects have some general similarity, in that they are both ways to collect values into named fields such that the whole collection can be manipulated as a single compound entity. They have many differences, though, in particular: lifecycle management (row insertion and deletion, versus [[Garbage collection (computer science)|garbage collection]] or [[reference counting]]), references to other entities (object references, versus foreign key references), and inheritance (non-existent in relational databases). As well, objects are managed on-heap and are under full control of a single process, while database tuples are shared and must incorporate locking, merging, and retry. Object–relational mapping provides automated support for mapping tuples to objects and back, while accounting for all of these differences.<ref name="hibernate-orm-overview">

Many popular database products, however, such as SQL DBMS products, can only store and manipulate [[Scalar (computing)|scalar]] values such as integers and strings, organized within tables.

{{cite web |title=What is Object/Relational Mapping? |url=http://www.hibernate.org/about/orm |access-date=27 January 2022 |work=Hibernate Overview |publisher=JBOSS Hibernate |language=en-US}}

</ref>

The heart of the problem involves translating the logical representation of the objects into an atomized form that is capable of being stored in the database while preserving the properties of the objects and their relationships so that they can be reloaded as objects when needed. If this storage and retrieval functionality is implemented, the objects are said to be [[persistence (computer science)|persistent]].<ref name=hibernate-orm-overview />

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.

==Overview==

The crux of the problem is 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 [[persistence (computer science)|persistent]].

Implementation-specific details of storage drivers are generally wrapped in an API in the programming language in use, exposing methods to interact with the storage medium in a way which is simpler and more in line with the paradigms of surrounding code.

The following is a simple example, written in [[C Sharp (programming language)|C#]] code, to execute a query written in [[SQL]] using a database engine.

==Implementations==

The most common type of database used is the relational database, which predates the rise of object-oriented programming in the 1990s. Relational databases use a series of ''[[table (database)|table]]s'' to organize data. Data in different tables are 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.

<syntaxhighlight lang="csharp">

An object-relational mapping implementation would need to systematically and predictably choose which tables to use and generate the necessary SQL. In overview, the impedance mismatch between the architectural approach of the object oriented application such as built in Java and where the data is stored in a relational database management system ([[RDBMS]]) such as Oracle or IBM's DB2 creates a rather complex set of challenges to deal with in order to accomplish tasks such as performance, linear scalability, manage the [[Create,_read,_update_and_delete|CRUD]] operations for even the most complex relationships without slowing down, eliminate coding SQL - JDBC - Java to save time and create consistency in how this is handled, make maintenance and future application changes simple, requiring little or no effort, etc. The real values in using an ORM tool is to save time, simplify development (i.e. the ORM tool handles the complexity for the developer), increase performance or scalability, and minimize architectural challenges related to inability of the ORM tool or developer's experience.

var sql = "SELECT id, first_name, last_name, phone, birth_date, sex, age FROM persons WHERE id = 10";

var result = context.Persons.FromSqlRaw(sql).ToList();

var name = result[0]["first_name"];

</syntaxhighlight>

In contrast, the following makes use of an ORM-job API which makes it possible to write code that naturally makes use of the features of the language.

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. <ref>[http://www.service-architecture.com/object-relational-mapping/articles/transparent_persistence.html Animation showing how an object-relational mapping utility works]</ref>

<syntaxhighlight lang="csharp">

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.

var person = repository.GetPerson(10);

var firstName = person.GetFirstName();

</syntaxhighlight>

The case above makes use of an object representing the storage repository and methods of that object. Other frameworks might provide code as static methods, as in the example below, and yet other methods may not implement an object-oriented system at all. Often the choice of paradigm is made for the best fit of the ORM into the surrounding language's design principles.

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."

<syntaxhighlight lang="csharp">

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 [http://jcp.org/en/jsr/detail?id=220 JPA standard].

var person = Person.Get(10);

</syntaxhighlight>

==Comparison with traditional data access techniques==

An alternative approach is being taken with technologies such as [[Resource Description Framework|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.

Compared to traditional techniques of exchange between an object-oriented language and a relational database, ORM often reduces the amount of code that needs to be written.<ref>{{cite journal | date= 1998 | doi=10.1109/2.730734 | issue=11 | journal=Computer | pages=33–40 | publisher=Institute of Electrical and Electronics Engineers (IEEE) | title=Solving the Java object storage problem |quote=For this exercise, 496 lines of code were needed using the ODMG Java Binding compared to 1,923 lines of code using JDBC. | url=https://www.service-architecture.com/articles/object-relational-mapping/transparent-persistence-vs-jdbc-call-level-interface.html | vauthors=((Barry, D.)), ((Stanienda, T.)) | volume=31 }}</ref>

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.{{Verify source|date=July 2007}}

Disadvantages of ORM tools generally stem from the high level of [[Database abstraction layer|abstraction]] obscuring what is actually happening in the implementation code.

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)|Catalyst]] framework, although many other choices are possible.

==Object-oriented databases==

Python enjoys availability multiple ORMs such as [http://www.sqlobject.org/ SQLObject], [http://www.sqlalchemy.org/ SQLAlchemy], [http://projects.amor.org/dejavu Devaju], [http://aplikacja.info/PyDAO.html PyDAO], [http://storm.canonical.com/ Storm] etc. Many python frameworks support one or multiple ORMs.

Another approach is to use an [[object database|object-oriented database management system]] (OODBMS) or [[document-oriented database]]s such as native [[XML database]]s that provide more flexibility in data modeling. OODBMSs are databases designed specifically for working with object-oriented values. Using an OODBMS eliminates the need for converting data to and from its SQL form, as the data is stored in its original object representation and relationships are directly represented, rather than requiring [[junction table|join tables]]/operations. The equivalent of ORMs for [[document-oriented database]]s are called object-document mappers (ODMs).

Document-oriented databases also prevent the user from having to "shred" objects into table rows. Many of these systems also support the [[XQuery]] query language to retrieve datasets.

==Non-SQL databases==

Object-oriented databases tend to be used in complex, niche applications. One of the arguments against using an OODBMS is that it may not be able to execute ad-hoc, application-independent queries.{{Citation needed|date=September 2013}} For this reason, many programmers find themselves more at home with an object-SQL mapping system, even though most object-oriented databases are able to process SQL queries to a limited extent. Other OODBMS provide replication to SQL databases, as a means of addressing the need for ad-hoc queries, while preserving well-known query patterns.{{Citation needed|date=September 2018}}

Another solution would be to use an [[object database|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.

==Challenges==

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

A variety of difficulties arise when considering how to match an object system to a relational database. These difficulties are referred to as the [[object–relational impedance mismatch]].<ref>[https://www.semanticscholar.org/paper/Object-Relational-Mapping-Revisited-A-Quantitative-Lorenz-Rudolph/708ac5e798b7e45b949d42e2f872549a3612e1e2 Object–Relational Mapping Revisited - A Quantitative Study on the Impact of Database Technology on O/R Mapping Strategies. M Lorenz, JP Rudolph, G Hesse, M Uflacker, H Plattner. Hawaii International Conference on System Sciences (HICSS), 4877-4886] (DOI:10.24251/hicss.2017.592)</ref>

An alternative to implementing ORM is use of the native procedural languages provided with every major database. These can be called from the client using SQL statements. The [[Data access object|Data Access Object]] (DAO) design pattern is used to abstract these statements and offer a lightweight object-oriented interface to the rest of the application.<ref>{{cite web |last=Feuerstein |first=Steven |author2=Bill Pribyl |date=September 1997 |title=Oracle PL/SQL Programming |url=http://docstore.mik.ua/orelly/oracle/prog2/ch18_05.htm |access-date=23 August 2011 |language=en-US |___location=18.5 Modifying Persistent Objects}}</ref>

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.

ORMs are limited to their predefined functionality, which may not cover all edge cases or database features. They usually mitigate this limitation by providing users with an interface to write raw queries, such as Django ORM.<ref>{{Cite web |title=Performing raw SQL queries {{!}} Django documentation |url=https://docs.djangoproject.com/en/5.1/topics/db/sql/ |access-date=2024-09-08 |website=Django Project |language=en}}</ref>

==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_database|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.

== See also ==

*[[List of object-relationalobject–relational mapping software]]

*[[Comparison of object–relational mapping software]]

*[[CORBA]]

*[[AutoFetch]] – automatic query tuning

*[[Database]]

*[[Common Object Request Broker Architecture]] (CORBA)

*[[Object database]]

*[[Object-relational databasepersistence]]

*[[Object–relational database]]

*[[Object–relational impedance mismatch]]

*[[Relational model]]

**[[SQL]] (Structured Query Language)

*[[Java Data Objects]] (JDO)

*[[Object-Relational impedance mismatch]]

*[[Java Persistence API]] (JPA), now [[Jakarta Persistence]]

*[[Catalyst (software)]]

*[[Service Data Objects]]

*[[Entity Framework]]

*[[Active record pattern]]

*[[Data mapper pattern]]

*[[Single Table Inheritance]]

== References ==

{{Reflist}}

<references />

==External links==

*[http://www.artima.com/intv/abstract3.html About ORM] by [[Anders Hejlsberg]]

*[http://www.agiledata.org/essays/mappingObjects.html Scott W. Ambler: Mapping Objects to Relational Databases: O/R Mapping In Detail]

*[http://www.agiledata.org/essays/mappingObjects.html Mapping Objects to Relational Databases: O/R Mapping In Detail] by [[Scott W. Ambler]]

*[http://c2.com/cgi/wiki?ObjectRelationalToolComparisonDotNet Object Relational Tool Comparison in .NET ]

*[http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html Core J2EE Design Pattern: Data Access Objects]

*[http://www.objectarchitects.de/ObjectArchitects/orpatterns/ Patterns for Object / Relational Mapping and Access Layers (not up2date)]

*[http://madgeek.com/Articles/ORMapping/EN/mapping.htm Choosing an Object-Relational mapping tool]

*[http://www.jdbcpersistence.org JDBCPersistence Fast ORM for Java]

{{Database}}

[[Category:Databases]]

[[Category:Database management systems]]

[[de{{DEFAULTSORT:Object-Relational- Mapping]]}}

[[Category:Object–relational mapping| ]]

[[es:Mapeo objeto-relacional]]

[[frCategory:Object-relationalData mapping]]

[[Category:Articles with example C Sharp code]]

[[id:Pemetaan objek-relasional]]

[[ja:オブジェクト関係マッピング]]

[[pl:Mapowanie obiektowo-relacyjne]]

[[pt:ORM]]

[[ru:ORM]]

[[th:ตัวส่งระหว่างโมเดลเชิงวัตถุและเชิงสัมพันธ์]]

[[zh:对象关系映射]]