La falta de coincidencia de impedancia relacional entre objetos es un conjunto de dificultades que existen entre los datos de los almacenes de datos relacionales y los datos de los modelos de objetos basados en 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 orientada a objetos, sino en la dificultad conceptual que existe entre los dos modelos lógicos. Ambos modelos lógicos se pueden implementar de manera diferente utilizando servidores de bases de datos, lenguajes de programación, patrones de diseño u otras tecnologías. Los problemas van desde la aplicación hasta la escala empresarial, siempre que se utilicen datos relacionales almacenados en modelos de objetos controlados por dominios, y viceversa. Los almacenes de datos orientados a objetos pueden cambiar este problema por otras dificultades de implementación.
El término desajuste de impedancia proviene del ajuste de impedancia en ingeniería eléctrica .
OO matemáticamente son gráficos dirigidos , donde los objetos hacen referencia entre sí. Relacional son tuplas en tablas con álgebra relacional . Las tuplas son campos de datos agrupados en una "fila" con campos escritos. Los enlaces son reversibles (INNER JOIN es simétrico para seguir las claves foráneas hacia atrás), formando gráficos no dirigidos .
La encapsulación de objetos oculta sus partes internas. Las propiedades de los objetos solo se muestran a través de interfaces implementadas. Sin embargo, muchos ORM exponen públicamente las propiedades para que funcionen con columnas de bases de datos. Los ORM de metaprogramación evitan violar la encapsulación.
Lo "privado" versus lo "público" se basa en la necesidad en una relación. En OO está absolutamente basado en clases. Esta relatividad versus absolutismo de clasificaciones y características choca.
Los objetos deben implementar interfaces para exponer sus componentes internos. Relacional utiliza vistas para variar perspectivas y restricciones. Carece de conceptos OO como clases , herencia y polimorfismo .
Para que un ORM funcione correctamente, las tablas que están vinculadas mediante relaciones de clave externa / clave primaria deben asignarse a asociaciones en el análisis orientado a objetos .
Relacional prohíbe la referencia (por ejemplo, punteros ), mientras que OO acepta la referencia. Los tipos escalares difieren entre ellos, lo que impide el mapeo.
SQL admite cadenas con longitudes máximas (más rápidas que sin ellas) e intercalaciones . OO solo tiene intercalación con rutinas de clasificación y cadenas limitadas únicamente por la memoria. SQL normalmente ignora los espacios en blanco finales durante la comparación, pero las bibliotecas OO no. OO no crea nuevos tipos usando restricciones sobre primitivas.
Los objetos pueden comprender otros objetos o especializarse. Relacional no está anidado y una relación ( tuplas con el mismo encabezado) no cabe en OO.
Relacional utiliza restricciones declarativas sobre tipos escalares, atributos, variables de relación y/o globalmente. OO utiliza excepciones que protegen el interior de los objetos.
Relacional utiliza operadores estandarizados para la manipulación de datos, mientras que OO utiliza imperativo por clase y por caso . Cualquier soporte declarativo OO es para listas y tablas hash , distintas de los conjuntos relacionales. [ cita necesaria ]
La unidad relacional es la transacción que supera 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 son solo con primitivas.
Las soluciones comienzan con reconocer las diferencias entre los sistemas lógicos. Esto minimiza o compensa el desajuste. [1]
Existen bases de datos de objetos (OODBMS) para evitar la falta de coincidencia, pero con menos éxito que las bases de datos relacionales. OO es una base pobre para los esquemas. [4] La investigación futura de bases de datos OO implica memoria transaccional .
Otra solución superpone la lógica del dominio y del marco. Aquí, OO mapea aspectos relacionales en tiempo de ejecución en lugar de estáticamente. Los marcos tienen una clase tupla (también llamada fila o entidad) y una clase de relación (también conocida como conjunto de datos).
Mezclar niveles de discurso OO es problemático. Principalmente, el soporte del marco compensa automatizando 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 . Reflection aborda 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 ayudas. Ambos tienen anomalías entre niveles, donde las clases generadas tienen propiedades de dominio (por ejemplo, Nombre, Dirección, Teléfono) y propiedades de marco (por ejemplo, IsModified).
Aunque pueden ocurrir discrepancias en la impedancia relacional de objetos con la programación orientada a objetos en general, un área particular de dificultad es con los mapeadores relacionales de objetos (ORM). [5] Dado que el ORM a menudo se especifica en términos de configuración, anotaciones y lenguajes restringidos de dominio específico , carece de la flexibilidad de un lenguaje de programación completo para resolver la falta de coincidencia de impedancia.
Christopher J. Date dice que un verdadero DBMS relacional supera el problema, [6] [7] [8] ya que los dominios y las clases son equivalentes. El mapeo entre relacional y OO es un error. [9] Las tuplas relacionales relacionan, no representan, entidades. El papel de OO pasa a ser únicamente gestionar campos.
Los objetos de dominio y las interfaces de usuario tienen impedancias no coincidentes. Las IU productivas deben evitar transacciones ilegales ( violaciones de restricciones de la base de datos ) para ayudar a los operadores y otras personas que no son 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 lejos del código caso por caso.
SQL , al carecer de tipos de dominio, impide el modelado OO. Hay pérdidas entre el DBMS y la aplicación (OO o no). Sin embargo, muchos evitan NoSQL y lenguajes de consulta alternativos específicos de proveedores. Los DBMS también ignoran Business System 12 y el Tutorial D.
Los DBMS convencionales como Oracle y Microsoft SQL Server resuelven esto. El código OO (Java y .NET respectivamente) los amplía y se pueden invocar en SQL con tanta fluidez como si estuvieran integrados en el DBMS. La reutilización de rutinas de biblioteca en múltiples esquemas es un paradigma moderno compatible.
OO está en el backend porque SQL nunca obtendrá bibliotecas y estructuras modernas para los programadores de hoy, a pesar de que el comité ISO SQL-99 quiere agregar procedimientos. Es razonable utilizarlos directamente en lugar de cambiar SQL. Esto desdibuja la división de responsabilidad entre "programación de aplicaciones" y "administración de bases de datos" porque la implementación de restricciones y desencadenantes ahora requiere habilidades tanto de DBA como de OO.
Esta afirmación puede ser discutible. Los RDBMS no son para modelar. SQL solo produce pérdidas cuando se abusa de él para modelar. SQL sirve para consultar, ordenar, filtrar y almacenar big data. La OO en el backend fomenta una mala arquitectura, ya que la lógica empresarial no debería estar en la capa de datos.
Relacional dice que el DBMS tiene autoridad y que los objetos del programa OO son copias temporales (posiblemente desactualizadas si la base de datos se modifica al mismo tiempo). OO dice que los objetos tienen autoridad y que el DBMS es solo para persistencia.
Las nuevas funciones cambian tanto el código como los esquemas. El esquema es responsabilidad del DBA. Los DBA son responsables de la confiabilidad, por lo que rechazan las modificaciones innecesarias de los programadores. Las bases de datos provisionales no ayudan más que a trasladar la aprobación al tiempo de publicación. Los DBA quieren contener cambios en el código, donde los defectos son menos catastróficos.
Una mayor colaboración resuelve esto. Las decisiones de cambio de esquema deben surgir de las necesidades comerciales. Los datos novedosos o las mejoras en el rendimiento modifican el esquema.
Existen diferencias filosóficas clave:
Por lo tanto, los partidarios argumentan que se debe abandonar la tecnología del otro. [10] Algunos administradores de bases de datos de RDBMS incluso abogan por procedimientos sobre OO, es decir, que los objetos no deben sobrevivir a las transacciones. OO responde que se desarrollará la tecnología OODBMS en sustitución de la relacional. Sin embargo, la mayoría de los programadores se abstienen y ven el desajuste de impedancia relacional entre el objeto y la relación como un simple obstáculo.
Los ORM ofrecen ventajas situacionales. Los escépticos citan inconvenientes 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 debería basarse firmemente en el modelo relacional.
El primer gran error