Object–relational mapping: Difference between revisions

Revision as of 00:57, 6 March 2025

Latest revision as of 09:43, 29 July 2025

(One intermediate revision by one other user not shown)

Line 3:

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

Line 38:

==Comparison with traditional data access techniques==

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>Douglas{{cite Barry,journal Torsten| Stanienda,date= "Solving1998 the Java Object Storage Problem," Computer,| voldoi=10.1109/2.730734 31, no.| issue=11, pp.| 33-40,journal=Computer Nov.| 1998,pages=33–40 [https://www.computer.org/csdl/magazine/co/1998/11/ry033/13rRUxC0SRY.| Excerpt at https://www.service-architecture.com/articles/object-relational-mapping/transparent-persistence-vs-jdbc-call-level-interface.html Linespublisher=Institute of codeElectrical usingand O/RElectronics areEngineers only(IEEE) a| fractiontitle=Solving ofthe thoseJava neededobject forstorage a call-level interface (1:4).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>

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