Mapatge d'objectes relacional

El mapatge d'objectes relacional (ORM, sigles en anglès de Object-relational mapping) és una tècnica de programació per convertir dades de llenguatges de programació orientats a objectes en la seva representació en bases de dades relacionals, a través de la definició de les correspondències entre els diferents sistemes.

Descripció de la necessitat

La gestió de dades en programació orientada a objectes es fa a través de la manipulació d'objectes, que quasi sempre són valors no escalables. Considerant l'exemple d'una entrada d'una llibreta d'adreces, que representa una persona amb zero o més adreces o zero o més telèfons, en orientació a objectes això es representaria com un objecte "persona", de la qual penjarien les seves dades personals, les adreces i els telèfons, aquestes dues darreres dades, també objectes. Les bases de dades relacionals, només poden emmagatzemar valors escalars, com cadenes de caràcters o enters i organitzar-los en taules. El programador ha de convertir els valors representats en forma d'objectes en valors simples o agrupats per l'emmagatzematge a la base de dades i implementar el procés invers. Alternativament podria treballar només amb valors escalars, perdent els avantatges de la Programació Orientada a Objectes. Per poder gaudir de la potència de la programació a objectes i estalviar els processos de conversió d'objecte a registre de la base de dades i el seu invers, s'ha creat l'automatització d'aquest procés, mitjançant el mapatge d'objecte relacional.

Implementacions

Les bases de dades relacionals, que van proliferar a partir de l'aparició de la programació orientada a objectes, al principi de la dècada dels 1990, són les més típiques entre les bases de dades. Les bases de dades relacionals usen una sèrie de taules per organitzar dades. Les dades de taules diferents estan associades a través de restriccions declaratives, en lloc d'apuntadors o enllaços. Les mateixes dades que, en programació, poden ser emmagatzemades en un simple valor d'objecte probablement necessiten ser emmagatzemades arreu de diferents taules.

Una implementació d'objecte relacional necessita poder triar de forma sistemàtica i predictible quines taules ha d'usar per poder generar el SQL necessari. Vist en conjunt, el xoc d'interconnexions entre la solució arquitectònica de l'aplicació orientada a l'objecte, en Java, i el com s'emmagatzemen les dades en un sistema relacional de bases de dades, com Oracle o DB2, implica un complex conjunt de reptes a resoldre amb l'objectiu de satisfer tasques com la millora del rendiment, l'escalabilitat lineal o la gestió de les operacions CRUD i fins i tot les relacions més complexes sense alentir, eliminar codificació SQL - JDBC - Java per guanyar temps i crear consistència, fer simples el manteniment i els futurs canvis, etc. Els objectius reals de fer servir una eina ORM, és el de guanyar temps, simplificar el desenvolupament (és a dir, l'eina ORM absorbeix la part complexa que tenia el desenvolupador), incrementa el rendiment i l'escalabilitat i disminuir la complexitat en l'arquitectura, fins als límits de l'eina ORM combinades amb l'experiència del programador.

Molts paquets han estat desenvolupats per reduir la feixuga tasca de desenvolupar sistemes de mapatge proveint llibreries o classes que poden fer-ho automàticament. Donada una llista de taules de la base de dades i objectes del programa, automàticament mapejaran peticions entre un i l'altre. Demanar a un objecte persona els seus telèfons, resultarà en la creació i enviament d'una query correcta i adequada i els resultats seran traduïts directament en objectes telèfon dintre del programa. Des del punt de vista del programador, el sistema hauria de semblar que treballa amb un gestor d'objectes persistents. Hauria de crear objectes i seguir el seu cicle de vida de forma quasi transparent, actualitzant-se a la base de dades.

A la pràctica, tanmateix, les coses mai són tan senzilles. Tots els sistemes ORM tendeixen a fer-se visibles de diverses maneres, reduint alguns graus la pròpia capacitat d'ignorar la base de dades. Pitjor, la capa de traducció pot ser lenta i ineficient (notablement en termes del SQL que escriu), resultant en programes més lents i usen més memòria que el codi escrit "a mà".

Un nombre de sistemes ORM han estat creats al llarg dels anys però el seu efecte al mercat sembla prou dispar. NeXT n'ha fet un dels considerats millors, l'Enterprise Objects Framework (EOF), però ha fallat a l'hora de tenir un impacte perllongat al mercat, principalment per estar massa lligat al toolkit de NeXT, OpenStep. Posteriorment va ser integrat a WebObjects, també de NeXT i primer servidor d'aplicacions orientat a objectes. A partir de la compra de NeXT per part d'Apple, el 1997, EOF aporta la tecnologia darrere del lloc web de comerç electrònic de la companyia, els serveis .Mac i l'iTunes Music Store. Apache Cayenne va aparèixer a l'estiu de 2002 i es proposa complir l'estàndard JPA.

Una utilitat alternativa està sent presa amb tecnologies com RDF, SPARQL o el concepte del "triplestore". RDF és una serialització del concepte subjecte-predicat-objecte, RDF/XML és una representació del mateix en XML, SPARQL és un llenguatge de queries tipus SQL i triplestore és una descripció general de qualsevol base de dades que treballa amb un tercer component.

Més recentment, un sistema semblant ha començat a evolucionar dintre del món Java, conegut com a Java Data Objects. A diferència d'EOF, JDO és una especificació, de manera que hi ha diferents implementacions dels diversos fabricants. L'Enterprise Java Bean 3.0 (EJB3) també cobreix la mateixa àrea. Hi ha hagut conflicte d'estàndard entre ambdues especificacions. JDO disposa de bastants implementacions comercials, mentre EJB 3.0 encara està en fase de desenvolupament. Tanmateix, JCP ha anunciat nous estàndards per unir els que hi ha en conflicte i aconseguir que l'estàndard futur funcioni arreu de les arquitectures basades en Java. L'altre exemple a esmentar és Hibernate, l'entorn ORM més usat al món Java i que ha inspirat l'especificació EJB3.

A l'entorn web, Ruby on Rails juga un rol central i és gestionat per l'eina de wrapping ActiveRecord. DBlx::Class juga un rol similar per l'entorn basat en Perl i que s'anomena Catalyst.

En Python també hi ha múltiples ORMs, com ara SQLObject, SQLAlchemy, Dejavu Arxivat 2007-07-10 a Wayback Machine., PyDAO Arxivat 2007-09-29 a Wayback Machine., Strom, etc. Molts entorns python suporten un o més ORMs.

Bases de dades No-SQL

Una altra solució podria ser usar Bases de dades orientades a objectes (OODBMS), és a dir, bases de dades dissenyades específicament per treballar amb valors d'objectes. Així eliminem la necessitat de convertir dades en i des de la seva forma SQL, ja que les dades són emmagatzemades en la seva representació original.

Les bases de dades com Caché no necessiten ORM manual. L'accés a valors no escalars ja hi és incorporat. Caché permet el desenvolupador de dissenyar qualsevol combinació orientada a objectes i emmagatzemat estructurat de taules a la base de dades, en lloc de reprocessar amb eines externes.

Les bases de dades orientades a objectes encara gaudeixen d'un ús poc ampli. Una de les seves limitacions principals és que canviar d'un entorn SQL a un de purament orientat a objectes implica perdre la capacitat de crear queries SQL, una manera provada, de recuperació ad-hoc de combinacions de dades. Per això, molts programadors es troben a si mateixos més a casa amb sistemes de mapatge objecte-SQL, tot i que la majoria de bases de dades orientades a objectes són capaces, fins i tot, de processar queries SQL, fins a un límit.

Crítica

Algunes veus han tret al descobert que la promoció de les eines ORM és símptoma d'un intent de resoldre la part equivocada de la qüestió del xoc d'interconnexions de l'objecte relacional. El principi d'apuntalar la informació en bases de dades relacionals implica que l'orientació a objectes per si mateixa ja és inadequada per les veritables necessitats en termes de manipulació de dades i és aquest paradigma al que caldria dirigir-s'hi com un tot. Si així fos, ORM esdevindria redundant. Vist així, el xoc d'interconnexions i la suposada necessitat del mapatge d'objecte-relacional, apareixen de l'equació equivocada d'objecte i relació (taula o vista, parlant en SQL). El mapatge correcte al model relacional és el que hi ha entre objecte i tipus.

Vegeu també

• Signum Framework.

Enllaços externs

• Scott W. Ambler: Mapejant objectes a Bases de dades Relacionals: mapatge O/R al detall (anglès)
• Patrons de Disseny del nucli de J2EE: Objectes d'Accés
• Patrons pel mapatge d'objecte relacional i capes d'accés (no és al dia)
• Triant una eina de mapatge Objecte Relacional Arxivat 2020-07-10 a Wayback Machine.
• Persistència Ràpida d'ORM per Java Arxivat 2016-10-10 a Wayback Machine.
• Syrius ORM a PHP5 ORM Arxivat 2020-11-26 a Wayback Machine.