Mapeo objeto-relacional

El mapeo objeto-relacional ( ORM , O/RM y herramienta de mapeo O/R ) en informática es una técnica de programación para convertir datos entre una base de datos relacional y la memoria (generalmente el montón ) de un lenguaje de programación orientado a objetos . Esto crea, en efecto, una base de datos de objetos virtual que se puede utilizar desde dentro del programa.

En la programación orientada a objetos , las tareas de gestión de datos actúan sobre objetos que combinan valores escalares . Por ejemplo, consideremos una entrada en una agenda que representa a una persona con uno o más números de teléfono y direcciones. Esto podría modelarse en una implementación orientada a objetos mediante un objeto "Persona " con un atributo/campo para almacenar cada elemento de datos que compone la entrada: el nombre de la persona, una lista de números de teléfono y una lista de direcciones. La lista de números de teléfono contendría a su vez objetos "Número de teléfono", y así sucesivamente. Cada entrada de la agenda se trata como un único objeto por el lenguaje de programación (se puede referenciar mediante una única variable que contiene un puntero al objeto, por ejemplo). Se pueden asociar varios métodos al objeto, como métodos para devolver el número de teléfono preferido, la dirección particular, etc.

Por el contrario, las bases de datos relacionales, como SQL , agrupan los escalares en tuplas , que luego se enumeran en tablas . Las tuplas y los objetos tienen cierta similitud general, ya que ambos son formas de recopilar valores en campos con nombre, de manera que toda la colección se puede manipular como una única entidad compuesta. Sin embargo, presentan muchas diferencias, en particular: la gestión del ciclo de vida (inserción y eliminación de filas, frente a la recolección de basura o el conteo de referencias ), las referencias a otras entidades (referencias a objetos, frente a referencias a claves foráneas) y la herencia (inexistente en las bases de datos relacionales). Además, los objetos se gestionan en el montón y están bajo el control total de un único proceso, mientras que las tuplas de la base de datos se comparten y deben incorporar bloqueo, fusión y reintento. El mapeo objeto-relacional proporciona soporte automatizado para mapear tuplas a objetos y viceversa, teniendo en cuenta todas estas diferencias. ^{[ 1 ]}

El núcleo del problema radica en traducir la representación lógica de los objetos a una forma atomizada que pueda almacenarse en la base de datos, conservando sus propiedades y relaciones para poder recargarlos cuando sea necesario. Si se implementa esta funcionalidad de almacenamiento y recuperación, se dice que los objetos son persistentes . ^{[ 1 ]}

Los detalles específicos de la implementación de los controladores de almacenamiento generalmente se encapsulan en una API en el lenguaje de programación utilizado, lo que expone métodos para interactuar con el medio de almacenamiento de una manera más sencilla y acorde con los paradigmas del código circundante.

El siguiente es un ejemplo sencillo, escrito en código C# , para ejecutar una consulta escrita en SQL utilizando un motor de base de datos.

usando System.Collections.Generic ;string sql = "SELECT id, first_name, last_name, phone, birth_date, sex, age FROM persons WHERE id = 10" ; List < Person > result = context . Persons . FromSqlRaw ( sql ). ToList (); string name = result [ 0 ][ "first_name" ];

En cambio, el siguiente ejemplo utiliza una API ORM-job que permite escribir código que aprovecha de forma natural las características del lenguaje.

Persona persona = repositorio.GetPerson ( 10 ) ; cadena firstName = persona.GetFirstName ( ) ;​

El caso anterior utiliza un objeto que representa el repositorio de almacenamiento y los métodos de dicho objeto. Otros frameworks podrían proporcionar código como métodos estáticos, como en el ejemplo siguiente, e incluso otros métodos podrían no implementar un sistema orientado a objetos en absoluto. A menudo, la elección del paradigma se realiza en función de la mejor integración del ORM con los principios de diseño del lenguaje circundante.

Persona persona = Persona.Obtener ( 10 ) ;​

En comparación con las técnicas tradicionales de intercambio entre un lenguaje orientado a objetos y una base de datos relacional, ORM a menudo reduce la cantidad de código que se necesita escribir. ^{[ 2 ]}

Las desventajas de las herramientas ORM generalmente se derivan del alto nivel de abstracción que oculta lo que realmente sucede en el código de implementación.

Otro enfoque consiste en utilizar un sistema de gestión de bases de datos orientado a objetos (OODBMS) o bases de datos orientadas a documentos, como las bases de datos XML nativas , que ofrecen mayor flexibilidad en el modelado de datos. Los OODBMS son bases de datos diseñadas específicamente para trabajar con valores orientados a objetos. El uso de un OODBMS elimina la necesidad de convertir datos a y desde su formato SQL, ya que los datos se almacenan en su representación de objeto original y las relaciones se representan directamente, sin necesidad de tablas u operaciones de unión. El equivalente de los ORM para bases de datos orientadas a documentos se denomina mapeador objeto-documento (ODM).

Las bases de datos orientadas a documentos también evitan que el usuario tenga que dividir los objetos en filas de tablas. Muchos de estos sistemas también admiten el lenguaje de consulta XQuery para recuperar conjuntos de datos.

Las bases de datos orientadas a objetos suelen utilizarse en aplicaciones complejas y especializadas. Uno de los argumentos en contra del uso de un sistema de gestión de bases de datos orientadas a objetos (OODBMS, por sus siglas en inglés) es su posible incapacidad para ejecutar consultas ad hoc independientes de la aplicación. Por este motivo, muchos programadores se sienten más cómodos con un sistema de mapeo objeto-SQL, aunque la mayoría de las bases de datos orientadas a objetos pueden procesar consultas SQL de forma limitada. Otros OODBMS ofrecen replicación a bases de datos SQL para satisfacer la necesidad de consultas ad hoc, conservando al mismo tiempo patrones de consulta conocidos.

Al considerar cómo adaptar un sistema de objetos a una base de datos relacional, surgen diversas dificultades. Estas dificultades se conocen como desajuste de impedancia objeto-relacional . ^{[ 3 ]}

Una alternativa a la implementación de ORM es el uso de los lenguajes procedimentales nativos que proporcionan las principales bases de datos. Estos pueden ser invocados desde el cliente mediante sentencias SQL. El patrón de diseño Objeto de Acceso a Datos (DAO) se utiliza para abstraer estas sentencias y ofrecer una interfaz orientada a objetos ligera para el resto de la aplicación. ^{[ 4 ]}

Los ORM se limitan a su funcionalidad predefinida, que puede no cubrir todos los casos límite o características de la base de datos. Generalmente mitigan esta limitación proporcionando a los usuarios una interfaz para escribir consultas directas, como Django ORM. ^{[ 5 ]}

• Lista de software de mapeo objeto-relacional
• Comparación de software de mapeo objeto-relacional
• AutoFetch : ajuste automático de consultas
• Arquitectura de agente de solicitudes de objetos comunes (CORBA)
• Base de datos de objetos
• persistencia de objetos
• Base de datos objeto-relacional
• Desajuste de impedancia objeto-relacional
• Modelo relacional
  • SQL (Lenguaje de Consulta Estructurada)
• Objetos de datos Java (JDO)
• API de persistencia de Java (JPA), ahora Jakarta Persistence
• Objetos de datos de servicio
• Marco de entidades
• Patrón de registro activo
• Patrón de mapeo de datos
• Herencia de tabla única

• Acerca de ORM por Anders Hejlsberg
• Mapeo de objetos a bases de datos relacionales: Mapeo O/R en detalle por Scott W. Ambler