sin título de diapositiva - kybele.etsii.urjc.esbd-2011-12... · el modelo de clases de uml...
TRANSCRIPT
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
Base de Datos @KYBELEwww.kybele.urjc.es
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
Base de Datos @KYBELEwww.kybele.urjc.es
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
Base de Datos @KYBELEwww.kybele.urjc.es
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
Base de Datos @KYBELEwww.kybele.urjc.es
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.
1. Diagrama de clases UML
Base de Datos @KYBELEwww.kybele.urjc.es
Permiten modelar:
El vocabulario de un sistema
Colaboraciones
Esquema de una BD
Se componen de:
Clases
Interfaces
Relaciones:
Dependencia
Asociación
Generalización
1. Diagrama de clases UML
Base de Datos @KYBELEwww.kybele.urjc.es
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
1. Diagrama de clases UML
Base de Datos @KYBELEwww.kybele.urjc.es
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
1. Diagrama de clases UML
Base de Datos @KYBELEwww.kybele.urjc.es
Asociación n-aria
* *
Equipo Temporada
Las asociaciones representan relaciones existentes entre más de dos clases.
Jugador
*jugador
añoequipo
1. Diagrama de clases UML
1.2. Asociaciones
Base de Datos @KYBELEwww.kybele.urjc.es
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
1. Diagrama de clases UML
Base de Datos @KYBELEwww.kybele.urjc.es
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. Diagrama de clases UML
1.2. Asociaciones
Base de Datos @KYBELEwww.kybele.urjc.es
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
1. Diagrama de clases UML
Base de Datos @KYBELEwww.kybele.urjc.es
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. Diagrama de clases UML
1.3. Generalización
Base de Datos @KYBELEwww.kybele.urjc.es
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
Base de Datos @KYBELEwww.kybele.urjc.es
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
Base de Datos @KYBELEwww.kybele.urjc.es
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
Base de Datos @KYBELEwww.kybele.urjc.es
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
Base de Datos @KYBELEwww.kybele.urjc.es
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
Base de Datos @KYBELEwww.kybele.urjc.es
Empleado
Curso
{restricción} OCL
Restricciones sobre asociaciones
ImparteRecibe {or}
Empleado
Departamento
DirigePertenece
{subconjunto}
Curso
Alumnos
{ordenado}
2.1. Restricciones
Mecanismos de Extensión
Base de Datos @KYBELEwww.kybele.urjc.es
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
Mecanismos de Extensión
2.1. Restricciones
parcial y solapada
{overlapping, incomplete}
Base de Datos @KYBELEwww.kybele.urjc.es
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
Mecanismos de Extensión
Base de Datos @KYBELEwww.kybele.urjc.es
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.
Mecanismos de Extensión
Base de Datos @KYBELEwww.kybele.urjc.es
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>>
Mecanismos de Extensión
Base de Datos @KYBELEwww.kybele.urjc.es
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
Base de Datos @KYBELEwww.kybele.urjc.es
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
Base de Datos @KYBELEwww.kybele.urjc.es
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
Mecanismos de Extensión
2.2. Estereotipos
Base de Datos @KYBELEwww.kybele.urjc.es
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
Mecanismos de Extensión
Base de Datos @KYBELEwww.kybele.urjc.es
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
Base de Datos @KYBELEwww.kybele.urjc.es
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
Base de Datos @KYBELEwww.kybele.urjc.es
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