UML DATA PROFILE - Departamento de Sistemas Informáticos y

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:
4
Laboratorio de Sistemas de Información
Facultad de Informática
Universidad Politécnica de Valencia
En un diagrama, las marcas PK representan las claves primarias, y la
operación estereotipada PK es la restricción de la clave primaria.
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.
7
Laboratorio de Sistemas de Información
Facultad de Informática
Universidad Politécnica de Valencia
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.
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
9
Laboratorio de Sistemas de Información
Facultad de Informática
Universidad Politécnica de Valencia
punto puede tener un impacto importante en el diseño del sistema. Hay tres
soluciones fundamentales para el mapeo de la herencia en 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 Una tabla por Una tabla por
jerarquía
clase concreta clase
Ad hoc
Simple
Medio
Medio/Dificil
Fácil implementación
Simple
Medio
Difícil
Fácil acceso a los datos
Simple
Simple
Medio/Simple
Dependencia entre clases
Muy alto
Alto
bajo
Velocidad de acceso a los Rápido
Rápido
Medio/Rápido
datos
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
11
Laboratorio de Sistemas de Información
Facultad de Informática
Universidad Politécnica de Valencia
totalidad de la base de datos, casi siempre conlleva a una 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