Concepto: Bases de datos relacionales y orientación de objetos
Este concepto proporciona una visión general de modelos de objeto y modelos de datos relacionales, y proporciona una descripción resumida de una infraestructura de permanencia.
Relaciones
Descripción principal

Introducción

Este documento de conceptos proporciona una visión general de modelos de objeto y modelos de datos relacionales, y proporciona una descripción resumida de una infraestructura de permanencia.

Bases de datos relacionales y orientación de objetos

Las bases de datos relacionales y la orientación de objetos no son totalmente compatibles. Representan dos vistas diferentes del mundo: en un RDBMS, sólo se ven datos; en un sistema orientado a objetos, sólo se ve el comportamiento. No se trata de que una perspectiva sea mejor que la otra: el modelo orientado a objetos tiende a funcionar bien en sistemas con comportamiento complejo y comportamiento específico del estado en el que los datos son secundarios, o sistemas en los que se accede a los datos por navegación en una jerarquía natural (por ejemplo, facturas de materiales). El modelo de RDBMS se adapta a los sistemas y aplicaciones de creación de informes que tienen relaciones dinámicas o ad-hoc.

El hecho real de la cuestión es que se almacena un montón de información en bases de datos relacionales y, si las aplicaciones orientadas a objetos desean acceder a dichos datos, deben poder leer y escribir en un RDBMS. Además, los sistemas orientados a objetos suelen tener que compartir datos con sistemas que no están orientados a objetos. Por lo tanto, es normal utilizar un RDBMS como mecanismo de compartimiento.

Mientras que los diseños relacional y orientado a objetos tienen algunas características en común (un atributo de objetos es, conceptualmente, similar a una columna de entidades), las diferencias fundamentales hacen que la integración perfecta suponga un desafío. La diferencia fundamental es que los modelos de datos muestran datos (mediante los valores de las columnas) y los modelos de objeto ocultan datos (los encapsulan tras las interfaces públicas).

El modelo de datos relacionales

El modelo relacional está formado por entidades y relaciones. Una entidad puede ser una tabla física o un proyección lógica de varias tablas, también conocida como vista. La figura de abajo ilustra las tablas LINEITEM, ORDER y PRODUCT y las diferentes relaciones entre ellas. Un modelo relacional tiene los siguientes elementos:

Diagrama detallado en el contenido.

Un modelo relacional

Una entidad tiene columnas. Cada columna se identifica mediante un nombre y un tipo. En la figura de arriba, la entidad LINEITEM tiene las columnas Id_LíneaDetalle (la clave principal), Descripción, Precio, Cantidad, Id_Producto y Id_Pedido (las dos últimas son claves externas que enlazan la entidad LINEITEM con las entidades ORDER y PRODUCT).

Una entidad tiene registros o filas. Cada fila representa un conjunto exclusivo de información que normalmente representa los datos permanentes de un objeto. 

Cada entidad tiene una o varias claves principales. Las claves principales identifican de forma exclusiva a cada registro (por ejemplo, ID es la clave principal de la tabla LINEITEM).

El soporte de las relaciones es específico del proveedor. El ejemplo ilustra el modelo lógico y la relación entre las tablas PRODUCT y LINEITEM. En el modelo físico, las relaciones suelen implementarse utilizando las referencias clave externa / clave principal. Si una entidad se relaciona con otra, contiene columnas que son claves externas. Las columnas de clave externa contienen datos que pueden relacionar registros específicos de la entidad con la entidad relacionada.

Las relaciones tienen multiplicidad (también conocida como cardinalidad). Las cardinalidades comunes son de uno a uno (1:1), de uno a muchos (1:m), de muchos a uno (m:1) y de muchos a muchos (m:n). En el ejemplo, LINEITEM tiene una relación 1:1 con PRODUCT y PRODUCT tiene una relación 0:m con LINEITEM.

El modelo de objeto

Un modelo de objeto contiene, entre otras cosas, clases (consulte [UML01] para una definición completa de un modelo de objeto). Las clases definen la estructura y el comportamiento de un conjunto de objetos, a veces llamados instancias de objetos. La estructura se representa como atributos (valores de datos) y asociaciones (relaciones entre clases). La figura siguiente ilustra un diagrama de clase simple, sólo muestra los atributos (datos) de las clases.

Diagrama detallado en el contenido.

Un modelo de objeto (diagrama de clase)

Un pedido tiene un número (el número de pedido) y una asociación de 1 o más (1..*) líneas de detalle. Cada línea de detalle tiene una cantidad (la cantidad pedida).

El modelo de objeto soporta la herencia. Una clase puede heredar datos y comportamiento de otra clase (por ejemplo, los productos ProductoSoftware y ProductoHardware heredan los atributos y los métodos de la clase Producto).

Infraestructuras de permanencia

La mayoría de las aplicaciones empresariales utilizan la tecnología relacional como un almacén de datos físicos. El reto al que se enfrentan los desarrolladores de aplicaciones orientadas a objetos es separar lo suficiente y encapsular la base de datos relacional de manera que los cambios en el modelo de datos no "rompan" el modelo de objeto, y viceversa. Hay muchas soluciones que proporcionan a las aplicaciones acceso directo a los datos relacionales; el reto consiste en conseguir una integración perfecta entre el modelo de objeto y el modelo de datos.

La interfaces de programación de aplicaciones de base de datos (API) se proporcionan en variedades estándar (por ejemplo, API de conectividad para bases de datos abiertas de Microsoft o ODBC) y son propietarias (enlaces nativos con bases de datos específicas). Las API proporcionan el paso de lenguaje de manipulación de datos (DML) a través de servicios, lo que permite a las aplicaciones acceder a datos relacionales brutos. En las aplicaciones orientadas a objetos, los datos deben someterse a la conversión relacional de objetos antes de que los utilice la aplicación. Esto requiere una cantidad considerable de código de aplicación para convertir los resultados brutos de la API de base de datos en objetos de aplicación. El objetivo de la infraestructura relacional de objetos es encapsular genéricamente el almacén de datos físicos y proporcionar servicios de conversión de objetos adecuados.

Diagrama detallado en el contenido.

El objetivo de una infraestructura de permanencia

Los desarrolladores de aplicaciones invierten más del 30% de su tiempo en la implementación del acceso a bases de datos relacionales en aplicaciones orientadas a objetos. Si la interfaz relacional de objetos no está implementada correctamente, se pierde la inversión. La implementación de una infraestructura relacional de objetos captura esta inversión. La infraestructura relacional de objetos se puede reutilizar en aplicaciones posteriores reduciendo el coste de la implementación relacional de objetos a menos de un 10% del coste total de la implementación. El coste más importante que se debe tener en cuenta cuando se implementa un sistema es el de mantenimiento. Más del 60% del coste total de un sistema durante su ciclo vital se puede atribuir al mantenimiento. Un sistema relacional de objetos mal implementado puede ser una pesadilla de mantenimiento tanto técnico como financiero.

Características esenciales de una infraestructura relacional de objetos

  • Rendimiento. Debe prestar mucha atención a la descomposición de objetos en datos y la composición de objetos a partir de datos. En sistemas donde la tasa de transferencia de datos es elevada y crítica, suele ser el talón de Aquiles de una capa de acceso mal diseñada.
  • Minimización de los compromisos de diseño. Un patrón habitual para los tecnólogos de objetos que han construido sistemas que utilizan bases de datos relacionales consiste en ajustar el modelo de objeto para facilitar el almacenamiento en sistemas relacionales y alterar el modelo relacional para un almacenamiento de objetos más sencillo. A menudo son necesarios pequeños ajustes, por eso una capa de acceso bien diseñada minimiza la degradación del diseño de modelos relacionales y objetos.
  • Capacidad de ampliación. La capa de acceso es una infraestructura de caja blanca que permite a los desarrolladores de aplicaciones ampliar la infraestructura en el caso de que necesite una función determinada. Normalmente, una capa de acceso soporta, sin una ampliación, el 65-85% de los requisitos de almacenamiento de datos de una aplicación. Si la capa de acceso no está diseñada como una infraestructura ampliable, alcanzar el último 35-15% de los requisitos de almacenamiento de datos de la aplicación puede ser muy difícil y costoso.
  • Documentación. La capa de acceso es, al mismo tiempo, un componente de caja negra y una infraestructura de caja blanca. La API del componente de caja negra debe estar definida claramente, bien documentada y entendida sin dificultad. Como se ha mencionado previamente, la capa de acceso está diseñada para ampliarse. Una infraestructura ampliable debe estar documentada minuciosamente. Deben identificarse las clases que se dividirán en subclases. Deben especificarse las características de cada protocolo relevante de la clase (por ejemplo, público, privado, protegido, final, ...). Además, debe exponerse y documentarse una parte sustancial del diseño de la infraestructura de la capa de acceso para facilitar la capacidad de ampliación.
  • Soporte para correlaciones relaciones de objetos comunes. Una capa de acceso debe proporcionar soporte para varias correlaciones relacionales de objetos básicas sin necesidad de una ampliación. Estas correlaciones relacionales de objetos se describen más detalladamente en un apartado posterior de este documento.
  • Interfaces de permanencia. En una aplicación orientada a objetos, el modelo empresarial de una aplicación de objetos captura el conocimiento semántico del dominio de problemas. Los desarrolladores deben poder manipular e interactuar con los objetos sin tener que preocuparse demasiado de los detalles de recuperación y almacenamiento de datos. Debe proporcionarse a los desarrolladores de aplicaciones un subconjunto bien definido de interfaces permanentes (guardar, suprimir, buscar).

Servicios relacionales de objetos comunes

Los patrones comunes surgen de las aplicaciones relacionales de objetos. Los profesionales de IT que han cruzado repetidas veces el abismo empiezan a comprender y reconocer determinadas estructuras y comportamientos que exponen satisfactoriamente aplicaciones relacionales de objetos. Estas estructuras y comportamientos se han formalizado mediante especificaciones de servicios CORBA de alto nivel (que también se aplican correctamente a sistemas basados en COM/DCOM).

Las especificaciones de servicios CORBA aplicables y útiles para la correlación relacional de objetos son:

Los siguientes apartados utilizarán estas categorías para estructurar un discusión de servicios relacionales de objetos comunes. Se anima al lector a que consulte las especificaciones de CORBA adecuadas para obtener más detalles.

Permanencia

Permanencia es un término utilizado para describir cómo utilizan los objetos un medio de almacenamiento secundario para mantener su estado en sesiones discretas. La permanencia proporciona a un usuario la capacidad para guardar objetos en una sesión y acceder a ellos en una sesión posterior. Cuando se accede a los objetos posteriormente, su estado (por ejemplo, los atributos) será exactamente el mismo que el de la sesión anterior. En sistemas de varios usuarios, puede que no sea así, ya otros usuarios pueden acceder a los objetos y modificarlos. La permanencia está interrelacionada con otros servicios que se tratan en este apartado. La consideración de relación, concurrencia, etc. es intencional (y coherente con la descomposición de servicios de CORBA).

Ejemplos de servicios específicos que proporciona la permanencia:

  • Gestión de la conexión del origen de datos: las aplicaciones relacionales de objetos deben iniciar la conexión con el origen de datos físico. Normalmente, los sistemas de bases de datos relacionales requieren la identificación del servidor y la base de datos. Los detalles de la gestión de la conexión suelen ser específicos del proveedor de bases de datos, por lo que la infraestructura debe diseñarse como corresponde de una manera flexible.
  • Recuperación de objetos: cuando se restauran los objetos de la base de datos, los datos se recuperan de la base de datos y se convierten en objetos. Este proceso implica la extracción de datos de estructuras específicas de la base de datos del origen de datos, la ordenación de los datos de tipos de base de datos en tipos y/o clases de objetos adecuados, la creación del objeto adecuado y el establecimiento de atributos específicos del objeto.
  • Almacenamiento de objetos: el proceso de almacenamiento de objetos duplica la recuperación de objetos. Los valores de los atributos adecuados se extraen del objeto, se crea un estructura específica de la base de datos con los valores del atributo (esto puede ser una cadena de caracteres de SQL, un procedimiento almacenado o una llamada especial a procedimiento remoto) y se envía la estructura a la base de datos.
  • Supresión de objetos: los datos asociados a los objetos que se suprimen de un sistema deben suprimirse de la base de datos relacional. La supresión de objetos requiere la extracción de la información adecuada del objeto; se puede construir una solicitud de supresión (puede tratarse de una cadena de caracteres SQL, procedimientos almacenados o una llamada especial a procedimiento remoto) y se puede enviar la solicitud a la base de datos. Recuerde que algunos idiomas (por ejemplo, Smalltalk y Java) no soportan la supresión explícita; en su lugar, dan soporte a una estrategia llamada recopilación de basura. Las infraestructuras de permanencia que dan soporte a estos lenguajes deben proporcionar una manera alternativa de eliminar los datos de la base de datos una vez que las aplicaciones dejen de hacer referencia a los datos. Una manera común es que la base de datos mantenga recuentos de referencia del número de veces que otros objetos hacen referencia a un objeto. Cuando el recuento de referencia de un objeto es cero, no hay ningún objeto que haga referencia a él, por lo que es posible que se pueda suprimir. Puede ser aceptable suprimir objetos con un recuento de referencia igual a cero, puesto que incluso cuando ya no se hace referencia a un objeto, todavía se le pueden realizar consultas. Es necesaria una política para toda la base de datos sobre cuándo se permite la supresión de objetos.

Consulta

El almacenamiento de objetos permanentes es poco útil si no existe un mecanismo de búsqueda y recuperación de objetos específicos. Los recursos de consulta permiten a las aplicaciones interrogar y recuperar objetos en función de una variedad de criterios. Las operaciones de consulta básicas que proporciona una infraestructura de correlación relacional de objetos son exclusivamente de búsqueda. La operación exclusiva de búsqueda recupera un objeto específico y la búsqueda devuelve una recopilación de objetos basados en los criterios de consulta.

Los recursos de consulta del almacén de datos varían significativamente. Los almacenes de datos simples basados en archivos puede implementar operaciones de consulta rígidas propias, mientras que los sistemas relacionales proporcionan un lenguaje de manipulación de datos flexible. Las infraestructuras de correlación relacional de objetos amplían el modelo de consulta relacional para que se centre en objetos, en vez de en datos. Los mecanismos de paso a través también se implementan para aprovechar la flexibilidad de las consultas relacionales y las ampliaciones específicas del proveedor (por ejemplo, procedimientos almacenados).

Tenga en cuenta que existe un conflicto potencial entre los mecanismos de consulta basados en bases de datos y el paradigma de objeto: los mecanismos de consulta de la base de datos se basan en los valores de atributos (columnas) de una tabla. En los objetos correspondientes, el principio de encapsulación nos impide ver los valores de los atributos; están encapsulados por las operaciones de la clase. El motivo de la encapsulación es que facilita el cambio de las aplicaciones: podemos alterar la estructura interna de una clase sin preocuparnos de las clases dependientes siempre y cuando no cambien las operaciones visibles públicamente de la clase. Un mecanismo de consulta basado en la base de datos depende de la representación interna de una clase, que rompa la encapsulación de manera eficaz. Para la infraestructura, el reto consiste en impedir que las aplicaciones sean inestables en los cambios.

Transacciones

El soporte de transacciones permite que el desarrollador de aplicaciones defina una unidad atómica de trabajo. En terminología de bases de datos, significa que el sistema debe ser capaz de aplicar un conjunto de cambios en la base de datos, o debe garantizar que no se aplica ninguno de los cambios. O se ejecutan todas las operaciones de la transacción satisfactoriamente o la transacción falla en su conjunto. Las infraestructuras relacionales de objetos deben proporcionar, como mínimo, una base de datos relacional, como recurso para confirmar/ anular transacciones. El diseño de infraestructuras relacionales de objetos en un entorno de varios usuarios puede presentar muchos retos, por lo que se le debe prestar mucha atención.

Además de los recursos que proporciona la infraestructura de permanencia, la aplicación debe saber cómo manejar los errores. Cuando una transacción falla o se cancela anormalmente, el sistema debe ser capaz de restaurar su estado a un estado anterior estable, normalmente leyendo la información del estado anterior en la base de datos. De esta manera, hay una estrecha interacción entre la infraestructura de permanencia y la infraestructura de manejo de errores.

Concurrencia

Los sistemas orientados a objetos de varios usuarios deben controlar el acceso simultáneo a los objetos. Cuando varios usuarios acceden a un objeto simultáneamente, el sistema debe proporcionar un mecanismo para asegurar que las modificaciones del objeto del almacén permanente se producen de manera controlada y previsible. Las infraestructuras relacionales de objetos pueden implementar controles de concurrencia pesimistas y/o optimistas.

  • El control de concurrencia pesimista requiere que el desarrollador de aplicaciones especifique su intención cuando recupere el objeto del almacén de datos (por ejemplo, sólo lectura, bloqueo de escritura, ...). Si se bloquean los objetos, pueden bloquearse otros usuarios cuando accedan al objeto y que tengan que esperar a que se anule el bloqueo. La concurrencia pesimista debería utilizarse e implementarse con precaución, ya que es posible que cree situaciones de punto muerto.
  • El control de concurrencia optimista presupone que es poco probable que se acceda al mismo objeto de manera simultánea. Los conflictos de concurrencia se detectan cuando se guardan las modificaciones en la base de datos. Normalmente, si otro usuario modificó el objeto desde su recuperación, se devolverá un error a la aplicación indicando la anomalía de la operación de modificación. La aplicación es responsable de detectar y manejar el error. Esta acción llama a la infraestructura para que guarde en antememoria los valores simultáneos de los objetos y los compare con la base de datos. La concurrencia optimista es menos costosa si hay pocos conflictos de concurrencia, pero más cara si hay una gran cantidad de conflictos (dada la necesidad de rehacer el trabajo cuando se producen conflictos).

Rodas las aplicaciones que utilizan datos compartidos deben utilizar la misma estrategia de concurrencia; no se pueden mezclar los controles de concurrencia pesimista y optimista en los mismos datos compartidos, ya que pueden dañarse. La necesidad de una estrategia de concurrencia coherente se maneja mejor mediante una infraestructura de permanencia.

Relaciones

Los objetos están relacionados entre sí. Un objeto Pedido tiene muchos objetos Línea de detalle. Un objeto Libro tiene muchos objetos Capítulo. Un objeto Empleado pertenece exactamente a un objeto Empresa. En sistemas relacionales, las relaciones entre entidades se implementan mediante referencias de clave externa / clave principal. En sistemas orientados a objetos, las relaciones suelen implementarse explícitamente mediante atributos. Si un objeto Pedido tiene LíneasDetalle, Pedido contendrá un atributo llamado LíneasDetalle. El atributo LíneasDetalle de Pedido contendrá muchos objetos LíneaDetalle.

Los aspectos de las relaciones de una infraestructura relacional de objetos son interdependientes con los servicios de consulta, transacción y permanencia. Cuando se almacena, se recupera, se tramita o se consulta un objeto, deben tenerse en cuenta los objetos relacionados:

  • Cuando se recupera un objeto, ¿también hay que recuperar los objetos asociados? De manera simplista, sí, aunque hacerlo cuando los objetos asociados no son necesarios resulta muy caro. Una buena infraestructura permite mezclar las estrategias.
  • Cuando se almacena un objeto, ¿también se deben almacenar los objetos asociados si se han modificado? Otra vez, la respuesta depende del contexto.

Conceptualmente, es ventajoso considerar los servicios relacionales de objetos por separado, aunque las implementaciones de infraestructuras relacionales de objeto serán codependientes. Los servicios deben implementarse coherentemente no sólo en las organizaciones que no son individuales, sino también en aplicaciones que comparten los mismos datos. Una infraestructura es la única manera económica de conseguirlo.