Mapeo objeto-relacional

Este artículo necesita citas adicionales para su verificación . Por favor, ayude a mejorar este artículo añadiendo citas de fuentes fiables . El material sin fuentes puede ser cuestionado y eliminado. Buscar fuentes:  «Mapeo objeto-relacional» – noticias  · periódicos  · libros  · académico  · JSTOR ( mayo de 2009 ) ( Aprenda cómo y cuándo eliminar este mensaje )

El mapeo relacional de objetos ( 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 (normalmente el heap ) de un lenguaje de programación orientado a objetos . Esto crea, en efecto, una base de datos de objetos virtuales que se puede utilizar desde dentro del lenguaje de programación.

En la programación orientada a objetos , las tareas de gestión de datos actúan sobre objetos que combinan valores escalares en objetos. Por ejemplo, considere una entrada de la libreta de direcciones que representa a una sola persona junto con cero o más números de teléfono y cero o más 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 comprende 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 en sí misma "objetos PhoneNumber", y así sucesivamente. Cada una de estas entradas de la libreta de direcciones se trata como un solo objeto por el lenguaje de programación (se puede hacer referencia a ella mediante una sola variable que contenga un puntero al objeto, por ejemplo). Se pueden asociar varios métodos con el objeto, como métodos para devolver el número de teléfono preferido, la dirección de casa, 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 modo que toda la colección se pueda manipular como una sola entidad compuesta. Sin embargo, tienen muchas diferencias, en particular: administración del ciclo de vida (inserción y eliminación de filas, versus recolección de basura o conteo de referencias ), referencias a otras entidades (referencias a objetos, versus referencias a claves externas) y herencia (inexistente en las bases de datos relacionales). Además, los objetos se administran en el montón y están bajo el control total de un solo 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, al tiempo que tiene en cuenta todas estas diferencias. ^[1]

El núcleo del problema consiste en traducir la representación lógica de los objetos a una forma atomizada que pueda almacenarse en la base de datos, preservando al mismo tiempo las propiedades de los objetos y sus relaciones, de modo que puedan volver a cargarse como objetos 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 están envueltos en una API en el lenguaje de programación en uso, exponiendo métodos para interactuar con el medio de almacenamiento de una manera más simple y más en línea con los paradigmas del código circundante.

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

var sql = "SELECT id, nombre, apellido, teléfono, fecha de nacimiento, sexo, edad FROM personas WHERE id = 10" ; var resultado = contexto . Personas . FromSqlRaw ( sql ). ToList (); var nombre = resultado [ 0 ][ "nombre" ];         

Por el contrario, lo siguiente hace uso de una API de trabajo ORM que permite escribir código que utiliza naturalmente las características del lenguaje.

var persona = repositorio . GetPerson ( 10 ); var nombre = persona . GetFirstName ();      

El caso anterior hace uso de un objeto que representa el repositorio de almacenamiento y los métodos de ese objeto. Otros marcos pueden proporcionar código como métodos estáticos, como en el ejemplo siguiente, y sin embargo otros métodos pueden no implementar un sistema orientado a objetos en absoluto. A menudo, la elección del paradigma se realiza para que el ORM se adapte mejor a los principios de diseño del lenguaje circundante.

var 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 debe escribirse. ^[2]

Las desventajas de las herramientas ORM generalmente se deben al alto nivel de abstracción que oculta lo que realmente está sucediendo en el código de implementación. Además, la gran dependencia del software ORM se ha citado como un factor importante en la producción de bases de datos mal diseñadas. ^[3]

Otro enfoque es 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 proporcionan más 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, en lugar de requerir operaciones de unión de tablas . El equivalente de los ORM para bases de datos orientadas a documentos se denominan mapeadores de objetos y documentos (ODM).

Las bases de datos orientadas a documentos también evitan que el usuario tenga que "desmenuzar" 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 tienden a utilizarse en aplicaciones complejas y de nicho. Uno de los argumentos en contra del uso de un OODBMS es que puede no ser capaz de ejecutar consultas ad-hoc independientes de la aplicación. ^{[ cita requerida ]} Por esta razón, muchos programadores se sienten más cómodos con un sistema de mapeo de objetos a SQL, aunque la mayoría de las bases de datos orientadas a objetos pueden procesar consultas SQL en una medida limitada. Otros OODBMS proporcionan replicación a bases de datos SQL, como un medio para abordar la necesidad de consultas ad-hoc, al tiempo que preservan patrones de consulta bien conocidos. ^{[ cita requerida ]}

Al considerar cómo hacer coincidir un sistema de objetos con una base de datos relacional, surgen diversas dificultades. Estas dificultades se conocen como desajuste de impedancia objeto-relacional . ^[4]

Una alternativa a la implementación de ORM es el uso de los lenguajes procedimentales nativos que se proporcionan con cada base de datos principal. Estos pueden ser llamados desde el cliente mediante sentencias SQL. El patrón de diseño Data Access Object (DAO) se utiliza para abstraer estas sentencias y ofrecer una interfaz orientada a objetos liviana al resto de la aplicación. ^[5]

Los ORM están limitados a su funcionalidad predefinida, que puede no cubrir todos los casos extremos o las características de la base de datos. Por lo general, mitigan esta limitación al proporcionar a los usuarios una interfaz para escribir consultas sin formato, como Django ORM. ^[6]

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

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