Directriz: Aplicación de ingeniería en bases de datos relacionales
En esta directriz se describen los métodos para correlacionar clases de diseño persistentes en el modelo de diseño en tablas del modelo de datos.
Relaciones
Elementos relacionados
Descripción principal

Introducción

En esta directriz se describen los métodos para correlacionar las clases de diseño persistentes en el modelo de diseño en tablas del modelo de datos

Transformación de los elementos del modelo de diseño en elementos del modelo de datos

Las clases persistentes del modelo de diseño se pueden transformar en tablas en el modelo de datos.  En la tabla siguiente se muestra un resumen de la correlación entre los elementos del modelo de diseño y los elementos del modelo de datos.

Elemento del modelo de diseño

Elemento del modelo de datos correspondiente

Clase Tabla
Atributo Columna

Asociación

Relación de no identificación

Clase de asociación

Tabla de intersección

Agregación de compuestos

Relación de identificación

Asociación varios a varios

Tabla de intersección

Multiplicidad

Cardinalidad

Asociación calificada

Tabla de intersección

Generalización (herencia) Tabla separada

Correlación de clases persistentes con tablas

Las clases persistentes del modelo de diseño representan la información que debe almacenar el sistema. Conceptualmente, dichas clases puede parecer un diseño relacional. (Por ejemplo, las clases del modelo de diseño se pueden reflejar de algún modo como entidades en el esquema relacional). Sin embargo, a medida que el proyecto pasa de la elaboración a la construcción, los objetivos del modelo de diseño y el modelo de datos relacional divergen. La causa de la divergencia se debe a que el objetivo del desarrollo de la base de datos relacional es normalizar datos, mientras que el propósito del modelo de diseño es encapsular en comportamiento cada vez más complejo. La divergencia de ambas perspectivas, datos y comportamiento, conduce a la necesidad de correlacionar entre elementos relacionados de los dos modelos.

En una base de datos relacional escrita en tercera forma normal, cada fila de las tablas, cada "tuple", se considera como un objeto. Una columna de la tabla equivale a un atributo persistente de una clase. (Recuerde que una clase persistente puede tener atributos transitorios). Por este motivo, en el caso simple en el que no existan asociaciones a otras clases, la correlación entre ambos mundos resulta sencilla. El tipo de datos del atributo corresponde a uno de los tipos permitidos para las columnas.

Ejemplo

La clase Cliente siguiente:

Clase Cliente

cuando se modela en RDBMS, convierte para una tabla llamada Cliente, con las columnas ID_Cliente, Nombre y Dirección.

Una instancia de esta tabla se puede visualizar como:

El diagrama muestra parte de la tabla Nuevo objeto de cliente

Claves y atributos persistentes

Para cada atributo persistente, se pueden plantear preguntas con el objeto de extraer información adicional, que se va a utilizar para modelar correctamente el objeto persistente en un modelo de datos relacional. Por ejemplo:

  • ¿Este atributo persistente puede servir como clave o como parte de una clave? Ejemplo: "Atributo X, junto con el atributo Z, identifica únicamente el objeto". En la tabla del cliente, ID_Cliente representa una clave principal.
  • ¿Cuáles son los valores mínimos y máximos del atributo?
  • ¿Será posible buscar utilizando este atributo como clave? Podría formar parte de un filtro en una sentencia de selección como, por ejemplo, "Es común buscar todas las instancias donde Y > 1000."
  • ¿El atributo tiene una descripción, por ejemplo, "el atributo X es el número de retransmisiones por cada 100 000 caracteres transmitidos"?
  • ¿El atributo tiene valores numéricos posibles y conversiones deseadas entre valores numéricos diferentes?
  • ¿Quién puede actualizar el atributo? Ejemplo: "Sólo pueden cambiar T las personas que tengan la clase de autorización nn."
  • ¿Quién puede leer el atributo? Ejemplo: "Pueden leer P las personas que tengan las clases de autorización yy y zz", o bien, ""P está incluido en las vistas Vi y Vj".
  • ¿Existe información adecuada sobre volúmenes y frecuencias? Ejemplos: "Existen hasta un máximo de 50 000 apariciones de A", o bien, "Cada día se cambian 2000 A de promedio".
  • ¿El atributo es exclusivo? Ejemplo: Sólo una persona puede tener el mismo número de permiso de conducir.

Correlación de asociaciones entre objetos persistentes y el modelo de datos

Las asociaciones entre dos objetos persistentes se realizan como claves externas a los objetos asociados. Una clave externa es una columna de una tabla que contiene el valor de la clave principal del objeto asociado.

Ejemplo:

Suponga que existe la asociación siguiente entre Pedido y Cliente:

El diagrama UML muestra la asociación entre Pedido y Cliente.

Cuando se correlacionan en tablas relacionales, el resultado es una tabla Pedido y una tabla Cliente. La tabla Pedido tiene columnas para los atributos listados, además de una columna adicional denominada ID_Cliente que contiene referencias de claves externas a la clave principal de la fila asociada a la tabla Cliente. Para un Pedido determinado, la columna ID_Cliente contiene el identificador del cliente al que se ha asociado el pedido. Las claves externas permiten que RDBMS una la información relacionada.

Correlación de asociaciones de agregación con el modelo de datos

La agregación también se modela utilizando relaciones de clave externa.

Ejemplo:

Suponga que existe la asociación siguiente entre Pedido y Elemento de línea:

Clases Pedido y Elemento de línea

Cuando se correlacionan en tablas relacionales, el resultado es una tabla Pedido y una tabla Elemento de línea. La tabla Elemento_Línea tiene columnas para los atributos listados, además de una columna adicional denominada ID_Pedido que contiene una referencia de clave externa a la columna asociada en la tabla Pedido. Para un elemento de línea concreto, la columna ID_Pedido contiene el ID_Pedido del pedido al que se ha asociado el elemento de línea. Las claves externas permiten que RDBMS optimice las operaciones de unión.

Además, es importante implementar una restricción de supresión en cascada que proporcione la integridad referencial al modelo de datos. Una vez que se haya llevado a cabo, siempre que se elimine el Pedido, también se suprimirán todos sus Elementos de línea.

Modelado de las relaciones de generalización en el modelo de datos

El modelo de datos relacional estándar no admite el modelado directo de la herencia. Para modelar la herencia se pueden utilizar varias estrategias, que se pueden resumir del modo siguiente:

  • Utilizar tablas separadas para representar la superclase y la subclase. La tabla de subclase debe incluir una referencia de clave externa a una tabla de superclase. Con el objeto de crear instancias de un objeto de subclase, se deben unir ambas tablas. Esta propuesta es, conceptualmente, más sencilla y simplifica los cambios en el modelo pero, con frecuencia, su ejecución no es la adecuada debido al trabajo adicional.
  • Duplicar todas las asociaciones y los atributos heredados como columnas separadas en la tabla de subclase. Es similar a la desnormalización en el modelo de datos relacional estándar.

Modelado de las asociaciones de varios a varios en el modelo de datos

Una técnica estándar del modelado relacional consiste en utilizar una entidad de intersección para representar asociaciones de varios a varios. Aquí se puede aplicar la misma propuesta: se utiliza una tabla de intersección para representar la asociación.

Ejemplo:

Si los Proveedores pueden suministrar varios Productos, y varios Proveedores pueden suministrar un Producto, la solución es crear una tabla Proveedores/Productos. Dicha tabla sólo puede contener las claves externas de las tablas de Proveedor y Producto, y sirven para enlazar las Proveedores y sus Productos relacionados. El modelo de objeto no tiene análogo para esta tabla; se utiliza, estrictamente, para representar las asociaciones del modelo de datos relacional.

Perfeccionamiento del modelo de datos

Una vez que se hayan transformado las clases de diseño en tablas y las relaciones adecuadas del modelo de datos, se perfecciona el modelo según sea necesario a fin de implementar la integridad referencial y optimizar el acceso a los datos a través de vistas y procedimientos almacenados. Para obtener más información, consulte el apartado Directriz: Modelo de datos.

Aplicación de ingeniería en el modelo de datos

La mayoría de herramientas de diseño de aplicaciones admiten la generación de scripts DDL (Lenguaje de definición de datos) de modelos de datos o la generación de las bases de datos a partir del modelo de datos.  La aplicación de la ingeniería a las bases de datos se debe planificar como parte de las tareas de desarrollo e integración global de las aplicaciones. El tiempo y la frecuencia para aplicar ingeniería a la base de datos a partir del modelo de datos depende de la situación del proyecto específico.  Para proyectos de desarrollo de aplicaciones que crean una nueva base de datos, es posible que la aplicación de ingeniería inicial se deba llevar a cabo como parte del trabajo de implementar una versión arquitectónica estable de la aplicación al final de la fase de elaboración.  En otros casos, la aplicación de ingeniería inicial se puede realizar en las primeras iteraciones de la fase de construcción. 

Los tipos de elementos de modelo del modelo de datos a los que se puede aplicar ingeniería varían en función de las herramientas de diseño específicas y del RDBMS utilizados en el proyecto.  Por lo general, se puede aplicar ingeniería a los elementos estructurales principales del modelo de datos, incluidas las tablas, las vistas, los procedimientos almacenados y los índices, de la base de datos.