El desajuste de impedancia objeto-relacional es un conjunto de dificultades que se dan entre los datos almacenados en almacenes de datos relacionales y los datos en modelos de objetos controlados por dominios. Los sistemas de gestión de bases de datos relacionales (RDBMS) son el método estándar para almacenar datos en una base de datos dedicada, mientras que la programación orientada a objetos (OO) es el método predeterminado para el diseño centrado en el negocio en lenguajes de programación. El problema no radica ni en las bases de datos relacionales ni en la programación OO, sino en la dificultad conceptual que existe entre los dos modelos lógicos. Ambos modelos lógicos se pueden implementar de forma diferente utilizando servidores de bases de datos, lenguajes de programación, patrones de diseño u otras tecnologías. Los problemas varían desde la escala de aplicación hasta la escala empresarial, siempre que los datos relacionales almacenados se utilicen en modelos de objetos controlados por dominios, y viceversa. Los almacenes de datos orientados a objetos pueden compensar este problema con otras dificultades de implementación.
El término desajuste de impedancia proviene de coincidencia de impedancia en ingeniería eléctrica .
Matemáticamente, la OO es grafos dirigidos , donde los objetos se referencian entre sí. La relacional es tuplas en tablas con álgebra relacional . Las tuplas son campos de datos agrupados en una "fila" con campos tipificados. Los enlaces son reversibles (INNER JOIN es simétrico para seguir las claves externas hacia atrás), formando grafos no dirigidos .
La encapsulación de objetos oculta los elementos internos. Las propiedades de los objetos solo se muestran a través de las interfaces implementadas. Sin embargo, muchos ORM exponen las propiedades públicamente para trabajar con columnas de bases de datos. Los ORM de metaprogramación evitan violar la encapsulación.
En el ámbito relacional, lo "privado" y lo "público" se basan en las necesidades. En el ámbito orientado a objetos, se basan absolutamente en las clases. Esta relatividad y absolutismo de las clasificaciones y características entran en conflicto.
Los objetos deben implementar interfaces para exponer sus componentes internos. El modelo relacional utiliza vistas para variar las perspectivas y las restricciones. Carece de conceptos de OO como clases , herencia y polimorfismo .
Para que un ORM funcione correctamente, las tablas que están vinculadas a través de relaciones de clave externa / clave principal deben asignarse a asociaciones en el análisis orientado a objetos .
El relacional prohíbe las referencias por referencia (por ejemplo, punteros ), mientras que el orientado a objetos las acepta. Los tipos escalares difieren entre ellos, lo que impide el mapeo.
SQL admite cadenas con longitudes máximas (más rápido que sin ellas) y colaciones . OO solo tiene colaciones con rutinas de ordenación y cadenas limitadas solo por la memoria. SQL generalmente ignora los espacios en blanco finales durante la comparación char , pero las bibliotecas OO no lo hacen. OO no realiza la conversión de tipos nuevos mediante restricciones en primitivas.
Los objetos pueden incluir otros objetos o especializarse. Los objetos relacionales no están anidados y una relación ( tuplas con el mismo encabezado) no cabe en OO.
El modelo relacional utiliza restricciones declarativas sobre tipos escalares, atributos, variables de relación y/o a nivel global. El modelo orientado a objetos utiliza excepciones que protegen los elementos internos de los objetos.
El lenguaje relacional utiliza operadores estandarizados para la manipulación de datos, mientras que el lenguaje orientado a objetos utiliza un imperativo por clase y por caso . Todo el soporte declarativo del lenguaje orientado a objetos es para listas y tablas hash , distintas de los conjuntos en el lenguaje relacional. [ cita requerida ]
La unidad de Relational es la transacción, que supera en tamaño a cualquier método de clase OO. Las transacciones incluyen combinaciones arbitrarias de manipulación de datos, mientras que OO solo tiene asignaciones individuales a campos primitivos. OO carece de aislamiento y durabilidad, por lo que la atomicidad y la consistencia solo se dan en los primitivos.
Las soluciones comienzan por reconocer las diferencias entre los sistemas lógicos. Esto minimiza o compensa la discordancia. [1]
Existen bases de datos de objetos (OODBMS) para evitar el desajuste, pero con menos éxito que las bases de datos relacionales. La OO es una base deficiente para los esquemas. [4] Las futuras investigaciones sobre bases de datos OO implican la memoria transaccional .
Otra solución es la superposición de la lógica del dominio y del marco. En este caso, OO asigna aspectos relacionales en tiempo de ejecución en lugar de hacerlo de forma estática. Los marcos tienen una clase de tupla (también llamada fila o entidad) y una clase de relación (también conocida como conjunto de datos).
Mezclar los niveles de discurso de OO es problemático. El soporte del marco compensa principalmente esto, al automatizar la manipulación de datos y los patrones de presentación en el nivel de modelado. Se utilizan la reflexión y la generación de código . La reflexión trata el código como datos para permitir el transporte, la presentación y la integridad automáticos de los datos. La generación convierte los esquemas en clases y ayudantes. Ambos tienen anomalías entre niveles, donde las clases generadas tienen propiedades de dominio (por ejemplo, Nombre, Dirección, Teléfono) y propiedades del marco (por ejemplo, IsModified).
Aunque los desajustes de impedancia objeto-relacional pueden ocurrir con la programación orientada a objetos en general, un área particular de dificultad es con los mapeadores objeto-relacionales (ORM). [5] Dado que el ORM a menudo se especifica en términos de configuración, anotaciones y lenguajes específicos de dominio restringidos , carece de la flexibilidad de un lenguaje de programación completo para resolver el desajuste de impedancia.
Christopher J. Date afirma que un DBMS verdaderamente relacional supera el problema, [6] [7] [8] ya que los dominios y las clases son equivalentes. La correlación entre relacional y orientado a objetos es un error. [9] Las tuplas relacionales relacionan, no representan, entidades. El papel de orientado a objetos pasa a ser solo el de gestionar campos.
Los objetos de dominio y las interfaces de usuario tienen impedancias no coincidentes. Las interfaces de usuario productivas deben evitar transacciones ilegales ( violaciones de restricciones de la base de datos ) para ayudar a los operadores y otros no programadores a administrar los datos. Esto requiere conocimiento sobre los atributos de la base de datos más allá del nombre y el tipo, lo que duplica la lógica en los esquemas relacionales.
Los marcos aprovechan las restricciones de integridad referencial y otra información del esquema para estandarizar el manejo del código caso por caso.
SQL , al carecer de tipos de dominio, impide el modelado OO. [ disputado – debatido ] Es un sistema con pérdidas entre el DBMS y la aplicación (OO o no). Sin embargo, muchos evitan NoSQL y otros lenguajes de consulta específicos de proveedores. Los DBMS también ignoran Business System 12 y Tutorial D.
Los sistemas de gestión de bases de datos convencionales, como Oracle y Microsoft SQL Server, resuelven este problema. El código orientado a objetos (Java y .NET respectivamente) los extiende y se pueden invocar en SQL con tanta fluidez como si estuvieran integrados en el sistema de gestión de bases de datos. La reutilización de rutinas de bibliotecas en varios esquemas es un paradigma moderno compatible.
La OO está en el backend porque SQL nunca tendrá bibliotecas y estructuras modernas para los programadores actuales, a pesar de que el comité ISO SQL-99 desea agregar procedimientos. Es razonable utilizarlos directamente en lugar de cambiar SQL. Esto difumina la división de responsabilidad entre "programación de aplicaciones" y "administración de bases de datos", porque implementar restricciones y activadores ahora requiere habilidades tanto de DBA como de OO.
Esta afirmación puede ser discutible. Los RDBMS no sirven para modelar. SQL solo genera pérdidas cuando se abusa de él para modelar. SQL sirve para consultar, ordenar, filtrar y almacenar grandes cantidades de datos. La OO en el backend fomenta una mala arquitectura, ya que la lógica empresarial no debería estar en el nivel de datos.
El modelo relacional dice que el DBMS tiene autoridad y que los objetos del programa OO son copias temporales (posiblemente obsoletas si la base de datos se modifica simultáneamente). El modelo OO dice que los objetos tienen autoridad y que el DBMS es solo para persistencia.
Las nuevas características cambian tanto el código como los esquemas. El esquema es responsabilidad del administrador de bases de datos (DBA). Los DBA son responsables de la confiabilidad, por lo que rechazan las modificaciones innecesarias de los programadores. Las bases de datos de prueba ayudan, pero simplemente trasladan la aprobación al momento de la publicación. Los DBA quieren contener los cambios en el código, donde los defectos son menos catastróficos.
Una mayor colaboración resuelve este problema. Las decisiones sobre cambios de esquema deben basarse en las necesidades del negocio. Los datos nuevos o las mejoras de rendimiento modifican el esquema.
Existen diferencias filosóficas clave:
Por lo tanto, los partidarios argumentan que la tecnología del otro debería abandonarse. [10] Algunos administradores de bases de datos RDBMS incluso abogan por la tecnología procedimental en lugar de la OO, es decir, que los objetos no deberían sobrevivir a las transacciones. La OO responde con que la tecnología OODBMS debe desarrollarse para reemplazar a la relacional. Sin embargo, la mayoría de los programadores se abstienen y ven el desajuste de impedancia objeto-relacional como un simple obstáculo.
Los ORM ofrecen ventajas en determinadas situaciones, mientras que los escépticos citan desventajas y poco valor cuando se aplican a ciegas. [11]
La clase parece ser indistinguible del tipo, tal como se entiende clásicamente ese término..
... cualquier acercamiento de este tipo debe basarse firmemente en el modelo relacional.
El primer gran error