Download Perfil de Modelado de Datos para UML

UML DATA PROFILE
Mª José Reig Tarazona
Victoria Torres Bosch
Facultad de Informática - Universidad Politécnica de Valencia
Resumen
El desarrollo de una aplicación de base de datos requiere la existencia
de una estrecha relación entre los desarrolladores de software y el equipo de
desarrollo de la base de datos. Para que un proyecto tenga éxito éste debe
estar marcado por una visión compartida y una comunicación clara de cada
uno de los detalles del proyecto. Los desarrolladores de software utilizan
herramientas de desarrollo orientada a objetos y usan el modelo lógico de
clases para representar una visión global de la aplicación, mientras que el
equipo de desarrollo de base de datos diseñan, modelan, construyen y
optimizan la base de datos. Las áreas de interfaz y superposición entre estas
dos distintas responsabilidades a menudo representan el aspecto más
desafiante en el desarrollo de una aplicación de base de datos.
Es por ello que surge la necesidad del uso de un lenguaje estándar, que
permita el mapeo de objetos a base de datos relacionales, y que ayude a
resolver todos estos obstáculos con los que el equipo de trabajo se va a ir
encontrando a lo largo de la vida del proyecto. Para realizar esta tarea se debe
entender ambos paradigmas y sus diferencias y entonces hacer un equilibrio
inteligente basado en ese conocimiento.
Introducción
¿Por qué aparece la necesidad del mapeo de objetos a base de datos
relacionales? Por una razón, la tecnología orientada a objetos, tal como Java,
es el entorno más común de desarrollo aplicado a los nuevos sistemas de
software. También, las bases de datos relacionales son todavía el modelo
preferido para almacenar información persistente y es probable que esto siga
durante bastante tiempo.
Una vez demostrada la necesidad de un lenguaje estándar que permita
la comunicación entre los distintos miembros del equipo de proyecto llega el
momento de describir con detalle el perfil de Modelado de Datos para UML
incluyendo ejemplos para cada uno de los conceptos detallados. Una vez
familiarizados con todos estos conceptos hay que establecer una relación entre
el modelo de la aplicación y el de los datos de forma que se resuelva este
desafiante aspecto que determinará el éxito o el fracaso de un proyecto.
Perfil de Modelado de Datos para UML
1
Laboratorio de Sistemas de Información
Facultad de Informática
Universidad Politécnica de Valencia
El poder de UML no está limitado al desarrollo de software orientado a
objetos. Más y más, UML está siendo aplicado a otras áreas del desarrollo de
software, tales como el modelado de datos, mejorando la habilidad de los
profesionales para comunicar sus necesidades y contribuciones a el resto del
equipo.
Los analistas de datos, primero reúnen los datos de la documentación de
los requerimientos. Las Bases de Datos tradicionalmente han sido descritas en
una notación llamada Diagramas Entidad Relación. Sin embargo, al realizar el
modelo físico de datos se debe expresar una descripción detallada de la base
de datos. Esto se hace usando el Data Modeling Profile del Rational para UML.
Las bases de datos orientadas a objetos son soportadas por UML a
través del modelado de clases persistentes.
El Data Modeling Profile para UML no está todavía aprobado por OMG.
El Data Modeling Profile de UML.
Este documento [3] describe en detalle el Data Modeling Profile para el
UML implementado por el Rational Rose Data Modeler, incluyendo descriptores
y ejemplos para cada concepto, incluyendo bases de datos, esquemas, tablas,
claves, índices, relaciones, columnas, restricciones y disparadores.
Base de Datos.
La Base de Datos es el sistema para el almacenaje de datos y el acceso
controlado a los datos almacenados. Ésto es el elemento más grande que una
base de datos soporta. La base de datos relacional es un estándar soportado
por el Data Modeling UML Profile. Una base de datos relacional objeto, una
extensión de las relacional, es también soportada por UML Profile.
El estereotipo <<Database>> usado como un componente UML, define
una base de datos. Como un componente de base de datos debe tener un
nombre.
En la vista del componente, una base de datos es un elemento tarjeta
dependiente , desde el que se hace referencia al tipo de la base de datos.
Un icono puede representar el estereotipo como se muestra a
continuación.
Las tres posibles representaciones de un componente Base de Datos
son:
2
Laboratorio de Sistemas de Información
Facultad de Informática
Universidad Politécnica de Valencia
La completa descripción del modelo de la base de datos, para ser usada
para recuperar y almacenar datos, es almacenada en un esquema dentro de la
base de datos. El esquema es la unidad más grande con la que se puede
trabajar.
El estereotipo <<Schema>> en un modelo UML representa un esquema
de base de datos.
En el navegador un esquema se muestra como un paquete
En un diagrama la representación es un paquete con el estereotipo
Schema.
Notar que puede ser más que un esquema asociado a la base de datos.
3
Laboratorio de Sistemas de Información
Facultad de Informática
Universidad Politécnica de Valencia
Tablas.
Una tabla es la estructura de modelado básica de una base da datos
relacional. Representa un conjunto de tuplas de la misma estructura, también
llamadas filas. Cada una de estas tuplas contiene datos. La información acerca
de la estructura de una tabla esta almacenada en la base de datos.
Una clase con el estereotipo <<Table>> representa una tabla relacional
en un esquema de una base de datos.
En el navegador una tabla se representa por una símbolo “tabla”.
La representación en un diagrama usa el estereotipo Table y el
estereotipo Icon.
Insertando la tabla en el paquete esquema se crea la asociación de una
tabla a un esquema.
Claves.
Las claves se usan para acceder a las tablas. Las claves primarias
identifican de manera única a una fila de una tabla, mientras que las claves
ajenas son un acceso a datos en otras tablas relacionadas.
Las claves se representan como una restricción y como un valor
marcado sobre una columna.
La clave primaria usa una marca PK delante de la columna, como se
muestra a continuación:
En un diagrama, las marcas PK representan las claves primarias, y la
operación estereotipada PK es la restricción de la clave primaria.
4
Laboratorio de Sistemas de Información
Facultad de Informática
Universidad Politécnica de Valencia
Una clave ajena representa una columna, la cual es una parte de una
relación con otra tabla.
Una marca FK representa la clave ajena. Esto genera la restricción de
clave ajena, la cual se representa por un estereotipo FK sobre una
operación.
Indices.
Un índice es una estructura de datos física que acelera el acceso a los
datos. Esto no cambia la calidad o la cantidad de datos recuperados. Un índice
puede incluir múltiples columnas o solo una.
El índice no existe en la vista lógica.
El estereotipo Index sobre una operación representa una restricción para
un índice.
La representación en diagrama usa el estereotipo Index delante de la
operación.
5
Laboratorio de Sistemas de Información
Facultad de Informática
Universidad Politécnica de Valencia
La restricción del índice especifica la columna incluida y opcionalmente
la única del índice.
Relaciones.
Una dependencia de cualquier clase entre tablas en un modelo de datos
se llama relación.
Una relación es un resumen de una asociación estereotipada y un
conjunto de claves primarias y ajenas. Cada relación es entre una tabla padre y
otra tabla hijo, donde una tabla padre debe tener una clave primaria definida.
La tabla hijo crea una columna que es la clave ajena y una restricción para
indicar la tabla padre.
Una asociación no identificada representa una relación entre dos tablas
independientes. La clave ajena de la tabla hijo no contiene todas las columnas
de claves primarias.
Una relación identificada es una relación entre dos tablas dependientes,
donde la tabla hijo no puede existir sin la tabla padre. Todas las claves
primarias de la tabla padre se transforman en columnas de claves ajenas y
primarias en la tabla hijo.
6
Laboratorio de Sistemas de Información
Facultad de Informática
Universidad Politécnica de Valencia
Una relación tiene dos multiplicidades asociadas a ella. Éstas definen la
multiplicidad de una tabla asociada a otra. Es posible asignar más de una
relación entre dos tablas usando diferentes multiplicidadesCada relación creada importa las claves de la tabla padre a la tabla hijo.
Columnas.
Una tabla contiene columnas las cuales son atributos marcados. Las
columnas pueden contener datos cuando están instanciadas como una fila.
Una columna debe tener un tipo de datos definido. Una columna puede
ser o persistente o computada. Las columnas computadas están definidas por
una expresión.
Las columnas persistente pueden ser marcadas como claves primarias,
columnas anulables y columnas únicas.
Pueden contener un valor por defecto.
Las restricciones pueden ser revisadas para cada columna.
Tipo de Datos.
Al soportar bases de datos relacionales requiere el soporte de tipos de
datos estándar. Ejemplos de tipos de datos son char, date, float, long, number,
nvarchar2, raw, varchar2.
Restricciones.
Una restricción es una regla aplicada a la estructura de la base de datos.
Esta regla extiende la estructura y puede ser aplicada a columnas y/o tablas.
Todas las restricciones están definidas como operaciones
estereotipadas. Todas las restricciones descritas abajo están implementadas
aquí en una clase.
Clave Primaria.
La restricción de clave primaria define la clave primaria como una regla
en la tabla.
Clave Ajena.
La restricción de clava ajena define la clave ajena como una regla en la
tabla.
Disparadores.
Un disparador es una actividad ejecutada por el DBMS como un efecto
de una modificación de una tabla.
7
Laboratorio de Sistemas de Información
Facultad de Informática
Universidad Politécnica de Valencia
El estereotipo Trigger sobre una operación representa el disparo sobre
una tabla.
El disparador se muestra como un estereotipo Trigger sobre la operación
Un ejemplo de un disparador es la longitud de una inserción en otra tabla
en el caso donde el balance es menor que 0 o mayor que 100.000.
Valor Valido.
La restricción de valor valido revisa el valor de los datos de acuerdo a
una expresión dada.
El estereotipo Check sobre una operación representa la restricción de la
validación.
Un ejemplo de la restricción es BALANCE>0.
8
Laboratorio de Sistemas de Información
Facultad de Informática
Universidad Politécnica de Valencia
Unicidad.
La restricción de unicidad asegura que cada fila contiene un valor
diferente en una columna.
Es estereotipo Unique representa la restricción de uncidad.
La restricción de unicidad puede ser aplicada sobre columnas
compuestas o simples.
Resumen.
Con el Data Modeling Profile para UML, soporta completamente las
necesidades del modelado de datos. Admite el soporte de desarrollo de
software y modelado de datos con un lenguaje unificado. Usando el UML Data
Modeling Profile, Rational Rose Data Moduler unifica el equipo de desarrollo de
software con una simple herramienta.
Cómo mapear objetos a una base de datos relaciona
En esta sección se describen las técnicas fundamentales requeridas
para mapear de forma exitosa los objetos a bases de datos relacionales.
 Mapeo de atributos a columnas
 Implementación de la herencia en una base de datos relacional
 Mapeo de asociaciones, agregaciones y composiciones
 Implementación de relaciones
Mapeo de atributos a columnas
Los atributos de una clase pueden mapearse en cero o en una serie de
columnas en una base de datos relacional. Es importante tener presente que
no todos los atributos son persistentes, por lo tanto no todos serán
almacenados en la base de datos.
Además, algunos atributos hacen referencia a objetos, lo que quiere
decir que se trata de una definición recursiva: un atributo puede mapearse
tanto en cero como en una serie de columnas.
También es posible que varios atributos se mapeen en una única
columna de una tabla. (Por ej. Una clase representando un código postal (C.P.)
puede tener tres atributos numéricos, representando cada uno de ellos una
sección del C.P. completo. Sin embargo, el C.P. debe ser almacenado en una
columna en la tabla de direcciones.)
Implementación de la herencia en una base de datos relacional
El concepto de herencia sigue diferentes caminos cuando se salvan
objetos en una base de datos relacional. La cuestión se reduce a entender
cómo organizar los atributos heredados en el modelo persistente. La forma en
que se resuelve este punto puede tener un impacto importante en el diseño del
sistema. Hay tres soluciones fundamentales para el mapeo de la herencia en
9
Laboratorio de Sistemas de Información
Facultad de Informática
Universidad Politécnica de Valencia
bases de datos relacionales y para entenderlas hay que discutir el equilibrio
entre el mapeo del diagrama de clases.
Mapeo de clases a tablas
Excepto en bases de datos muy simples, nunca habrá clases que se
mapeen directamente en una tabla. A continuación se describen tres
estrategias para la implementación de estructuras de herencia en una base de
datos relacional:
 Usando una entidad para una estructura completa de clases de
herencia.
 Usando una entidad para una clase concreta
 Usando una entidad por clase.
Usando una entidad por una estructura completa de clases de herencia
Con este enfoque, la estructura completa de herencia se mapea en una
tabla, donde todos los atributos de todas las clases en la jerarquía son
almacenados. La ventaja de este enfoque es que es simple, el polimorfismo
está soportado cuando una subclase cambia de rol, y es posible acceder de
forma ad hoc a toda la información que se necesita desde una misma tabla.
Las desventajas son que cada vez que se añade un nuevo atributo en
cualquier nivel de la jerarquía dicho atributo hay que añadirlo a la tabla. Esto
hace que aumente la dependencia entre las clases de la jerarquía, ya que si se
comete un error al añadir un atributo, éste podría afectar a todas las clases de
la jerarquía, además de las subclases de cualquier clase a la que pertenezca
dicho atributo. Esto, potencialmente desperdicia una gran cantidad de espacio
en la base de datos.
También, hay que añadir una columna para indicar a qué subclase
pertenece cada una de las filas de la tabla. Este enfoque funciona bien cuando
la jerarquía de subclases no es muy amplia, ya que en caso contrario esta
solución se hace inviable.
Usando una entidad por cada clase concreta
En esta solución cada entidad incluye tanto los atributos propios de la
clase como los heredados.
La gran ventaja en este caso es que todavía es bastante fácil realizar
consultas ad hoc, debido al hecho de que toda la información que se necesita
sobre una clase dada está almacenada en una única tabla.
Sin embargo, este enfoque cuenta con varias desventajas. Una de ellas
es que cuando se modifica una clase hay que modificar su tabla y la tabla de
cada una de sus subclases (mucho trabajo si tenemos en cuenta que la
estructura puede ser muy grande). Otra es que cuando un objeto cambia de rol
hay que copiar toda la información referida al objeto en la tabla apropiada y
asignarle un nuevo identificador (mucho trabajo de nuevo). Tercera, es que es
difícil mantener múltiples roles y además mantener integridad de los datos, por
ej. ¿Dónde almacenaríamos el nombre de un estudiante que a la vez es un
profesor?
10
Laboratorio de Sistemas de Información
Facultad de Informática
Universidad Politécnica de Valencia
Usando una entidad por clase
Con este enfoque se crea una tabla por cada clase, con los atributos que
hacen referencia a la identificación del objeto y los atributos específicos de
cada clase.
La principal ventaja de esta solución es que es la más cercana al
concepto de orientación a objetos. Soporta polimorfismo ya que es posible
mantener filas en las apropiadas tablas para cada uno de los roles que un
objeto puede tener. Además es muy fácil modificar superclases y añadir nuevas
subclases porque lo único que hay que hacer es añadir o modificar una tabla.
Aunque como veremos ahora, también cuenta con varias desventajas.
En primer lugar hay demasiadas tablas en la base de datos (una por cada
clase, además de aquellas que nos permitirán mantener las relaciones entre
tablas). En segundo lugar, se tarda mucho en leer y escribir información
usando esta técnica ya que se deberá acceder a múltiples tablas. Este
problema se puede rebajar si se organiza la base de datos de forma inteligente,
poniendo cada tabla dentro de una jerarquía de clases en diferentes soportes
físicos. Tercero y último es que la recuperación de datos ad hoc es difícil, a
menos que se añadan vistas que simulen las tablas requeridas.
Comparación de estrategias
Factores a considerar
Una tabla
por jerarquía
Una tabla
por clase
concreta
Medio
Medio
Simple
Alto
Rápido
Una tabla
por clase
Ad hoc
Simple
Medio/Dificil
Fácil implementación
Simple
Difícil
Fácil acceso a los datos
Simple
Medio/Simple
Dependencia entre clases Muy alto
bajo
Velocidad de acceso a los Rápido
Medio/Rápid
datos
o
Soporta polimorfismo
Medio
Bajo
Alto
Mapeo de asociaciones, agregaciones y composiciones
No solo hay que mapear los objetos en la base de datos, también hay
que mapear las relaciones el las cuales los objetos están involucrados. Existen
cuatro tipos de relaciones en las cuales un objeto puede estar involucrado:
herencia, asociación, agregación y composición. Para mapear estas relaciones
de forma correcta hay que entender las diferencias entre ellas, cómo
implementar relaciones de forma general y cómo implementar relaciones
muchos a muchos en particular.
Diferencias entre asociación, agregación y composición
Desde la perspectiva de las bases de datos, la única diferencia entre una
asociación y una agregación o composición es cómo de fuerte es dicha relación
entre los objetos. En una agregación y una composición cada cosa que se
haga a la totalidad de la base de datos, casi siempre conlleva a una
11
Laboratorio de Sistemas de Información
Facultad de Informática
Universidad Politécnica de Valencia
modificación de cada una de las partes, sin embargo no ocurre esto en la
asociación.
Desde el punto de vista de la base de datos, una agregación o
composición y una asociación son diferentes en el hecho de que con la
agregación normalmente se quiere leer en la parte cuando se lee en el total, sin
embargo, con una asociación no es siempre tan obvio lo que se necesita hacer.
Lo mismo ocurre a la hora de salvar y borrar objetos en la base de datos.
Implementación de relaciones en bases de datos relacionales
Las relaciones en bases de datos relacionales están mantenidas a
través de claves ajenas. Una clave ajena es uno o más atributos que aparecen
en una tabla en la cual deben formar parte de ella, o es coincidente con la clave
de otra tabla. Las claves ajenas permiten relacionar una tabla con una fila de
otra tabla. Para implementar relaciones uno a muchos y uno a uno hay que
incluir la clave de una de las tablas en la otra tabla.
Implementación de muchos a muchos
Para implementar relaciones muchos a muchos se necesita el concepto
de tabla asociativa, una entidad cuyo propósito es mantener la asociación entre
dos o más tablas en una base relacional.
En bases de datos relacionales los atributos contenidos en una tabla asociativa
son tradicionalmente una combinación de las claves involucradas en la
relación. El nombre de una tabla asociativa es normalmente la combinación de
los nombre de las tablas que se están asociando o el nombre de la asociación
que implementa.
Conclusiones
La potencia de UML no está limitada al desarrollo de software orientado
a objetos. Cada vez más, UML se está aplicando a otras áreas de desarrollo de
software como el modelado de datos, mejorando la habilidad de los miembros
del equipo de comunicar sus necesidades y el poder ser valoradas por el resto
del equipo.
Referencias
[1] Mapping objects to relational databases
[2] Mapping Object to Data Models with the UML
[2] Towards a UML Profile for a Relational Persistence Model
[3] White Paper: The UML Data Modeling Profile.
[4] The Unified Modeling Language. Column from Magnus Penker
President of Astrakan Strategic Training AB, Sweden
12
Laboratorio de Sistemas de Información
Facultad de Informática
Universidad Politécnica de Valencia