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:
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:
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.
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:
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.
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:
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.
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.
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.
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.
|