[BD 2011 12]Tema2 ModeloClasesUML

Base de Datos @KYBELEwww.kybele.urjc.es

Temario

I. BD Orientadas a Objetos

Tema 1. Bases de Datos Orientadas a Objetos

Tema 2. El modelo de clases de UML

Ejercicios de modelado conceptual OO

Tema 3. El modelo objeto-relacional

Prácticas de BDOR en Oracle

Tema 4. Diseño de BDOR

Ejercicios de diseño de BD (objeto-)relacionales con UML

II. BD Activas

Tema 5. Bases de Datos Activas

Tema 6. Disparadores en OraclePrácticas de Disparadores en Oracle

III. BD Semiestructuradas

Tema 7. XML y las BD

Prácticas de XML con XML DB de Oracle


Diseño conceptual

Modelo E/R Extendido

Modelo de clases de UML

Diseño lógico

SQL-92 (BDR)

SQL:2003 (BDOR)

ODMG (BO)

Implementación

Código SQL (R o OR) para Oracle 10g

Código para POET

Modelo de Clases UML


Tecnología y Diseño de Bases de Datos. Piattini, M.G.,

Marcos, E., Calero, C., Vela, B. Ra-Ma, 2006.

Bases de Datos Objeto Relacionales. Marcos, E., Vela, B. y

Vara J.M., Dickinson, Septiembre 2005.

El Lenguaje de Modelado Unificado. G. Booch, J.

Rumbaugh, I. Jacobson. Addison Wesley, 1999.

Persistence Modeling in the UML. S.W. Ambler. Software

Development, 1999.

Bibliografía Complementaria


1. Diagrama de clases UML

1.1. Clases

1.2. Asociaciones

1.3. Generalizaciones

2. Mecanismos de extensión

2.1. Restricciones

2.2. Estereotipos para el diseño de BD

3. Ejemplo

Índice


Diagramas UML (Técnicas)

Clases: clases, relaciones, interfaces y colaboraciones. Vista de diseño estática y de procesos.

Objetos: objetos y relaciones. Vista de diseño estática y de procesos desde una perspectiva prototípica (diagramas de colaboración pero sin envío de mensajes).

Caso de uso: conjunto de casos de uso, actores y relaciones. Modelado y organización del comportamiento.

Interacción: objetos, relaciones y mensajes:

Secuencia: ordenación temporal de mensajes

Colaboración: organización estructural de los objetos que envían y reciben mensajes

Estados: estados, transiciones, eventos y actividades. Comportamiento dirigido por eventos de una clase, interfaz, o colaboración.

Actividades : modelan el funcionamiento y resaltan el flujo de control entre objetos.

Diagramas de componentes: organización y dependencias entre un conjunto de componentes.

Diagramas de despliegue: configuración de nodos de procesamiento en tiempo de ejecución y los componentes que residen en ellos.



Permiten modelar:

El vocabulario de un sistema

Colaboraciones

Esquema de una BD

Se componen de:

Clases

Interfaces

Relaciones:

Dependencia

Asociación

Generalización



Clases1.1. Clases

Personanombre

direcciónteléfonoscrear()

eliminar()

Nombre

Atributo: tipo = valor {propiedad}

Método (parámetros):tipo {propiedad}

Responsabilidades

Persona

Descripción de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semántica.

Pueden ser concretas o abstractas

Visibilidad:+ público# protegido- privado



Asociación

Nombre

rol rol

multiplicidad multiplicidad

navegavilidad

Trabaja_en

empleado patrón

1..* 1Persona Empresa

1.2. Asociaciones

Multiplicidad:0, 1 N..M* 3..*1 2..53, 4, 6..*

Las asociaciones representan relaciones existentes entre clases.Asociaciones: - Binarias

- Reflexivas- Ternarias

Dirección del nombre

Rol empleado: Relación de Persona con respecto a Empresa



Asociación n-aria

* *

Equipo Temporada

Las asociaciones representan relaciones existentes entre más de dos clases.

Jugador

*jugador

añoequipo


1.2. Asociaciones


Clases de Asociación

empleado patrón

1..* 1Persona Empresa

En una asociación entre dos clases, la propia asociación puede teneratributos.

Trabaja_EnDescripción

Fecha_Contratación

Salario

1.2. Asociaciones



Agregación:

Universidad Estudiante

Composición (agregación física):

Parte

Todo

Universidad Departamento

1..* 1..*

1 1..*

Una agregación es una asociación que permite representar objetos compuestos. Cuando los objetos de una clase (TODO) están compuestospor la unión de los objetos de otra clase (PARTE) existe una agregación.


1.2. Asociaciones


Generalización:

Padre

Hijo Hijo Persona

Hombre MujerParcialExclusiva

La generalización es una asociación entre una clase más general (super-clase o clase padre) y una clase más específica (subclase o clase hija).Lleva implícito dos principios: herencia (simple o múltiple) e inclusión.

1.3. Generalización



Herencia Múltiple:

Animal

Bípedo Cuadrúpedo

Con Pelos

Con Plumas

Con Escamas

Herbívoro

Carnívoro

cubertura

cobertura

cobertura

comida

nro patas nro patas

comida

Conejo


1.3. Generalización


Un estudio de arquitectura desea crear una base de datos para gestionar sus proyectos. Nos dan lassiguientes especificaciones:

•Cada proyecto tiene un código y un nombre. Un proyecto tiene uno y solo un jefe deproyecto y un jefe de proyecto sólo puede estar involucrado en un proyecto o en ninguno.

•De cada jefe de proyecto se desean recoger sus datos personales (código, nombre, direccióny teléfono). Un jefe de proyecto se identifica por un código. No hay dos nombres de jefe deproyecto con el mismo nombre.

•Un proyecto se compone de una serie de planos, pero éstos se quieren guardar de modo independiente al proyecto. Es decir, si en un momento dado se dejara de trabajar en un proyecto, se desea mantener la información de los planos asociados.

•De los planos se desea guardar su número de identificación, la fecha de entrega, losarquitectos que trabajan en él y un dibujo del plano general con información acerca delnúmero de figuras que contiene.

•Los planos tienen figuras. De cada figura se desea conocer, el identificador, el nombre, elcolor, el área y el perímetro. Además, de los polígonos se desea conocer el número de líneasque tienen, además de las líneas que lo forman. El perímetro se desea que sea un métododiferido; el área se desea implementarlo como genérico para cualquier tipo de figura, peroademás se desea un método específico para el cálculo del perímetro de los polígonos.

•De cada líneas que forma parte de un polígono se desea conocer el punto de origen y el defin (según sus coordenadas, X e Y), así como la longitud. Cada línea tiene un identificador quepermite diferenciarlo del resto. La longitud de la línea se puede calcular a partir de suspuntos origen y final.

3. Ejemplo


1..*

Linea

Id_Linea

Longitud

Puntos: {Coord_X, CoordY}

Poligono

Num_Lineas

Figura

<<PK>> Figura_Id

<<AK>> Nombre

Color

Plano

Cod_Plano

Fecha_Entrega

Arquitectos

Dibujo_Plano

Num_Figuras

Proyecto

Cod_Proyecto

Nombre

JefeProyecto

Cod_JefeProyecto

Nombre

Direccion: {Tipo_Via, Nombre_Via,

Poblacion, CP, Provincia}

Telefono

10..1

1..*

0..* 1..1

dirige

tiene

Figura

Cod_Figura

Nombre

Color

3. Ejemplo


La cadena de Video-Clubs Glob-Gusters ha decidido, para mejorar su servicio, emplear una base de datos para almacenar la información referente a las películas que ofrece en alquiler. Esta información es la siguiente:

• Una película se caracteriza por su título, nacionalidad, productora y fecha (p.e., “Quo Vadis”, “Estados Unidos”, “M.G.M.”, 1955).

• En una película pueden participar varios actores (nombre, nacionalidad, sexo) algunos de ellos como actores principales.

• Una película está dirigida por un director (nombre, nacionalidad).• De cada película se dispone de uno o varios ejemplares diferenciados por un

número de ejemplar y caracterizados por su estado de conservación.• Un ejemplar se puede encontrar alquilado a algún cliente (DNI, nombre,

dirección, teléfono). Se desea almacenar la fecha de comienzo del alquiler y la de devolución.

• Cada socio puede tener alquilados, en un momento dado, 4 ejemplares como máximo.

• Un socio tiene que ser avalado por otro socio que responda de él en caso de tener problemas en el alquiler.

Enunciado 1



1.1. Clases

1.2. Asociaciones

1.3. Generalizaciones

2. Mecanismos de extensión

2.1. Restricciones

2.2. Estereotipos para el diseño de BD

3. Ejemplo

Índice


Mecanismos de extensión de UML

Mecanismos de Extensión

• Estereotipos: palabras claves que alteran el significado o funcionalidad de un elemento. <<persistent>>

• Valor etiquetado: comentarios que permiten añadirinformación al elemento. {versión=3.1}

• Restricción: limitan la funcionalidad de un elemento. {edad>18}

•Permiten adecuar la semántica de los elementos de modelosparticulares

•Extienden las posibilidades de anotación


Empleado

Curso

{restricción} OCL

Restricciones sobre asociaciones

ImparteRecibe {or}

Empleado

Departamento

DirigePertenece

{subconjunto}

Curso

Alumnos

{ordenado}

2.1. Restricciones



Restricciones sobre generalizaciones

Persona

AlumnoDocente

parcial y solapada

{overlapping, incomplete}

total y solapada

{overlapping, complete}

Persona

AlumnoEmpleado

Empleado

VendedorAnalista

{disjoint, incomplete}

parcial y exclusiva

Persona

MujerHombre

{disjoint, complete}

total y exclusiva


2.1. Restricciones

parcial y solapada

{overlapping, incomplete}


Restricciones sobre generalizaciones

Icono {raíz}

origen: Punto

mostrar()

obtenerID: Integer

IconoRectangular

altura: Integer

anchura: Integer

IconoArbitrario

borde: ColecciónDeLíneas

Botón

mostrar()

BotónOK {hoja}

mostrar()

Clases abstractas

{leaf}: sin hijos

{root}:sin padres

operación abstracta

2.1. Restricciones



2.2. Estereotipos

Permiten crear nuevos tipos de bloques de construcción a partir de los existentes, pero que sean específicos a un problema:

•interface•type•actor•exception•signal•process•thread•metaclass•etc.



Estereotipos para el diseño de BD Objeto Relacionales:

Elemento BD Elemento UML Estereotipo Icono

Base de datos Componente <<Database>>

Esquema Paquete <<Schema>>

Tablespace Componente <<Tablespace>>

Tabla Clase <<Table>> Vista Clase <<View>>

Índice Clase <<Index>>

Columna Atributos <<Column>>

Clave Primaria Atributos <<PK>>

Clave Ajena Atributos <<FK>>

Atributo multivaluado Atributos <<MA>>

Atributo derivado Atributos <<DA>>

Atributo Compuesto Atributos <<CA>>

Restricción de no nulidad Atributos <<NOT NULL>>

Restricción de unicidad Atributos <<UNIQUE>>

Disparador Restricción <<Trigger>>

Restricción Restricción <<Check>>

Procedimiento Almacenado Clase <<Stored Procedure>>



Un estudio de arquitectura desea crear una base de datos para gestionar sus proyectos. Nos dan lassiguientes especificaciones:

•Cada proyecto tiene un código y un nombre. Un proyecto tiene uno y solo un jefe de proyecto y unjefe de proyecto sólo puede estar involucrado en un proyecto o en ninguno.

•De cada jefe de proyecto se desean recoger sus datos personales (código, nombre, dirección yteléfono). Un jefe de proyecto se identifica por un código. No hay dos nombres de jefe de proyectocon el mismo nombre.

•Un proyecto se compone de una serie de planos, pero éstos se quieren guardar de modo independiente al proyecto. Es decir, si en un momento dado se dejara de trabajar en un proyecto, se desea mantener la información de los planos asociados.

•De los planos se desea guardar su número de identificación, la fecha de entrega, los arquitectosque trabajan en él y un dibujo del plano general con información acerca del número de figuras quecontiene.

•Los planos tienen figuras. De cada figura se desea conocer, el identificador, el nombre, el color, elárea y el perímetro. Además, de los polígonos se desea conocer el número de líneas que tienen,además de las líneas que lo forman. El perímetro se desea que sea un método diferido; el área sedesea implementarlo como genérico para cualquier tipo de figura, pero además se desea unmétodo específico para el cálculo del perímetro de los polígonos.

•De cada líneas que forma parte de un polígono se desea conocer el punto de origen y el de fin(según sus coordenadas, X e Y), así como la longitud. Cada línea tiene un identificador que permitediferenciarlo del resto. La longitud de la línea se puede calcular a partir de sus puntos origen y final.

3. Ejemplo


1..*

Linea<<persistent>>

<<PK>> Id_Linea

<<DA>> Longitud

<<MA>><<CA>> Puntos: {Coord_X, CoordY}

Poligono<<persistent>>

Num_Lineas

Figura

<<PK>> Figura_Id<<AK>> NombreColor

Plano<<persistent>>

<<PK>> Cod_PlanoFecha_Entrega<<MA>> ArquitectosDibujo_Plano<<DA>> Num_Figuras

Proyecto <<persistent>>

<<PK>> Cod_ProyectoNombre

JefeProyecto

<<persistent>>

<<PK>> Cod_JefeProyecto

<<AK>> Nombre

<<CA>> Direccion: {Tipo_Via, Nombre_Via,

Poblacion, CP, Provincia}

Telefono

1 0..1

1..*

1..* 1..1

dirige ►

◄ tiene

Figura<<persistent>>

<<PK>> Cod_FiguraNombreColor

3. Ejemplo


Método Diferido <<deferred>>Clase del Metamodelo: MétodoIcono: Ninguno

Método Redefinido <<overriding>>Clase del Metamodelo: MétodoIcono: NingunoRestricciones: Ninguna

Tipo ROW <<row>>Clase del Metamodelo: AtributoIcono:

ARRAY <<array>>Clase del Metamodelo: AtributoIcono:

Tipo REF <<ref>>Clase del Metamodelo: AtributoIcono:

Compone <<composes>>Clase del Metamodelo: AsociaciónIcono: None

Tabla Tipada (tt)

Clase del Metamodelo: ClaseIcono: Ninguno

Tipo Estructurado <<udt>>Clase del Metamodelo: ClaseIcono: Ninguno

Estereotipos para SQL:2003

<<udt>>

<<persistent>>

Tipo de objeto <<ot>> (udt+tt)

Clase del Metamodelo: ClaseIcono:

MULTISET <<Multiset>>Clase del Metamodelo: AtributoIcono: Ninguno


2.2. Estereotipos


Nested Table <<nt>>Clase del Metamodelo: ClaseIcono:

VARRAY <<varray>>Clase del Metamodelo: Atributo/ClaseIcono:

Tipo REF <<ref>>Clase del Metamodelo: AtributoIcono:

Compone <<composes>>Clase del Metamodelo: AsociaciónIcono: None

Tipo de Objeto <<ot>> (udt+tt)

Clase del Metamodelo: ClaseIcono:

Tipo Estructurado <<udt>>Clase del Metamodelo: ClaseIcono: Ninguno

Estereotipos para Oracle10g

<<udt>>

<<persistent>>

Tabla Tipada (tt)

Clase del Metamodelo: ClaseIcono: Ninguno

2.2. Estereotipos



La cadena de Video-Clubs Glob-Gusters ha decidido, para mejorar su servicio, emplear una base de datos para almacenar la información referente a las películas que ofrece en alquiler. Esta información es la siguiente:

• Una película se caracteriza por su título, nacionalidad, productora y fecha (p.e., “Quo Vadis”, “Estados Unidos”, “M.G.M.”, 1955).

• En una película pueden participar varios actores (nombre, nacionalidad, sexo) algunos de ellos como actores principales.

• Una película está dirigida por un director (nombre, nacionalidad).• De cada película se dispone de uno o varios ejemplares diferenciados por un

número de ejemplar y caracterizados por su estado de conservación.• Un ejemplar se puede encontrar alquilado a algún cliente (DNI, nombre,

dirección, teléfono). Se desea almacenar la fecha de comienzo del alquiler y la de devolución.

• Cada socio puede tener alquilados, en un momento dado, 4 ejemplares como máximo.

• Un socio tiene que ser avalado por otro socio que responda de él en caso de tener problemas en el alquiler.

Enunciado 1


La empresa de formación X, desea llevar un control informatizado de los cursos que imparte así como de lo profesores que participan en dichos cursos. Para ello, nos han dado las siguientes especificaciones:

• Cada curso, del que se desea conocer el título, el número de horas y el tema o los temas que trata, se identifica por un código de cuso.

• Cada curso puede tener una serie de cursos cuyo realización previa es obligatoria (prerrequisito) o recomendada.

• Cada curso se puede impartir una o varias veces, en diferentes fechas y en cada edición del mismo pueden participar diferentes empleados.

• Los empleados, de los que se desea conocer su código de empleado, nombre, DNI y fecha de antiguedad en la empresa, pueden impartir y recibir cursos pero con la restricción de que en una mismo edición de un curso no pueden participar como profesores y como alumnos.

Enunciado 2


Se desea crear una BD de recetas de cocina con los siguientes requisitos:

Cada receta tiene un identificador, además de un nombre y una descripción. SE debe guardar también los ingredientes de los que consta además de la cantidad necesaria para cada uno de ellos.

Las recetas se publican en libros de cocina. Cada libro se identifica por un ISBN. No puede haber dos libros con el mismo título. Además, se desea conocer la fecha de edición del libro.

De cada cocinero se desea conocer su nombre, su código de identificación así como su nacionalidad. No puede haber dos cocineros con el mismo nombre.

Un cocinero puede escribir libros de recetas. De éstos cocineros se desea conocer, además de los datos anteriormente descritos, el número de libros escritos. Un libro puede ser escrito por un máximo de cinco autores y un autor puede escribir varios libros. Un cocinero no tiene que ser necesariamente autor de libros.

También hay cocineros que inventan recetas. Un cocinero puede o no ser creador de recetas y en caso de serlo puede haber creado varias. Cada receta corresponde a un sólo creador.

Un cocinero que sea autor también puede ser creador de recetas y viceversa.

Enunciado 10

Documents

[BD 2011 12]Tema2 ModeloClasesUML