Temario. Base de

Transcripción

1 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 Oracle Prácticas de Disparadores en Oracle III. BD Semiestructuradas Tema 7. XML y las BD Prácticas de XML con XML DB de Oracle

2 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

3 Modelo de Clases UML

4 Bibliografía Complementaria Tecnología y Diseño de Bases de Datos. Piattini, M.G., Marcos, E., Calero, C., Vela, B. Ra-Ma, Bases de Datos Objeto Relacionales. Marcos, E., Vela, B. y Vara J.M., Dickinson, Septiembre El Lenguaje de Modelado Unificado. G. Booch, J. Rumbaugh, I. Jacobson. Addison Wesley, Persistence Modeling in the UML. S.W. Ambler. Software Development, 1999.

5 Índice 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

6 1. Diagrama de clases UML 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.

7 1. Diagrama de clases UML Permiten modelar: El vocabulario de un sistema Colaboraciones Esquema de una BD Se componen de: Clases Interfaces Relaciones: Dependencia Asociación Generalización

8 1.1. Clases 1. Diagrama de clases UML Clases Descripción de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semántica. Nombre Atributo: tipo = valor {propiedad} Método (parámetros):tipo {propiedad} Responsabilidades Visibilidad: + público # protegido - privado Pueden ser concretas o abstractas Persona nombre dirección teléfonos crear() Persona eliminar()

9 1.2. Asociaciones multiplicidad rol 1. Diagrama de clases UML Asociación Las asociaciones representan relaciones existentes entre clases. Asociaciones: - Binarias Dirección del nombre - Reflexivas - Ternarias Nombre Multiplicidad: 0, 1 N..M * 3..* , 4, 6..* navegavilidad multiplicidad rol Persona 1..* Trabaja_en 1 empleado patrón Empresa Rol empleado: Relación de Persona con respecto a Empresa

10 1.2. Asociaciones 1. Diagrama de clases UML Asociación n-aria Las asociaciones representan relaciones existentes entre más de dos clases. Equipo * * equipo año Temporada jugador * Jugador

11 1.2. Asociaciones 1. Diagrama de clases UML Clases de Asociación En una asociación entre dos clases, la propia asociación puede tener atributos. Persona 1..* 1 empleado patrón Empresa Trabaja_En Descripción Fecha_Contratación Salario

12 1.2. Asociaciones 1. Diagrama de clases UML Agregación: Una agregación es una asociación que permite representar objetos compuestos. Cuando los objetos de una clase (TODO) están compuestos por la unión de los objetos de otra clase (PARTE) existe una agregación. Todo Parte Universidad 1..* 1..* Estudiante Composición (agregación física): Universidad 1 1..* Departamento

13 1. Diagrama de clases UML 1.3. Generalización Generalización: La generalización es una asociación entre una clase más general (superclase 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. Padre Hijo Hijo Persona Parcial Exclusiva Hombre Mujer

14 1. Diagrama de clases UML 1.3. Generalización Herencia Múltiple: Bípedo Cuadrúpedo nro patas nro patas Con Pelos Herbívoro cubertura comida Con Plumas cobertura cobertura Animal comida Carnívoro Con Escamas Conejo

15 3. Ejemplo Un estudio de arquitectura desea crear una base de datos para gestionar sus proyectos. Nos dan las siguientes especificaciones: Cada proyecto tiene un código y un nombre. Un proyecto tiene uno y solo un jefe de proyecto 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ón y teléfono). Un jefe de proyecto se identifica por un código. No hay dos nombres de jefe de proyecto 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, los arquitectos que trabajan en él y un dibujo del plano general con información acerca del número de figuras que contiene. 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 se desea implementarlo como genérico para cualquier tipo de figura, pero ademá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 de fin (según sus coordenadas, X e Y), así como la longitud. Cada línea tiene un identificador que permite diferenciarlo del resto. La longitud de la línea se puede calcular a partir de sus puntos origen y final.

16 3. Ejemplo JefeProyecto Proyecto Cod_JefeProyecto Nombre Direccion: {Tipo_Via, Nombre_Via, Poblacion, CP, Provincia} Telefono 1 dirige 0..1 Cod_Proyecto Nombre 1..* Figura Figura Plano <<PK>> Cod_Figura Figura_Id <<AK>> Nombre Nombre Color tiene 0..* 1..1 Cod_Plano Fecha_Entrega Arquitectos Dibujo_Plano Num_Figuras Poligono Linea Num_Lineas 1..* Id_Linea Longitud Puntos: {Coord_X, CoordY}

17 Enunciado 1 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.

18 Índice 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

19 Mecanismos de Extensión Mecanismos de extensión de UML Permiten adecuar la semántica de los elementos de modelos particulares Extienden las posibilidades de anotación Estereotipos: palabras claves que alteran el significado o funcionalidad de un elemento. <<persistent>> Valor etiquetado: comentarios que permiten añadir información al elemento. {versión=3.1} Restricción: limitan la funcionalidad de un elemento. {edad>18}

20 Mecanismos de Extensión 2.1. Restricciones {restricción} OCL Restricciones sobre asociaciones Empleado Empleado Curso Recibe {or} Imparte {subconjunto} Pertenece Dirige {ordenado} Curso Departamento Alumnos

21 Mecanismos de Extensión 2.1. Restricciones Restricciones sobre generalizaciones Persona Persona {overlapping, incomplete} {overlapping, complete} Docente Alumno parcial y solapada Empleado Alumno total y solapada Empleado Persona {disjoint, incomplete} {disjoint, complete} Analista Vendedor parcial y exclusiva Hombre total y exclusiva Mujer

22 Mecanismos de Extensión 2.1. Restricciones Restricciones sobre generalizaciones Clases abstractas Icono {raíz} origen: Punto mostrar() obtenerid: Integer {root}:sin padres operación abstracta IconoRectangular altura: Integer anchura: Integer IconoArbitrario borde: ColecciónDeLíneas mostrar() Botón BotónOK {hoja} mostrar() {leaf}: sin hijos

23 Mecanismos de Extensión 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.

24 Mecanismos de Extensión 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>>

25 3. Ejemplo Un estudio de arquitectura desea crear una base de datos para gestionar sus proyectos. Nos dan las siguientes especificaciones: Cada proyecto tiene un código y un nombre. Un proyecto tiene uno y solo un jefe de proyecto 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ón y teléfono). Un jefe de proyecto se identifica por un código. No hay dos nombres de jefe de proyecto 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, los arquitectos que trabajan en él y un dibujo del plano general con información acerca del número de figuras que contiene. 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 se desea implementarlo como genérico para cualquier tipo de figura, pero ademá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 de fin (según sus coordenadas, X e Y), así como la longitud. Cada línea tiene un identificador que permite diferenciarlo del resto. La longitud de la línea se puede calcular a partir de sus puntos origen y final.

26 3. Ejemplo JefeProyecto <<persistent>> <<PK>> Cod_JefeProyecto <<AK>> Nombre <<CA>> Direccion: {Tipo_Via, Nombre_Via, Poblacion, CP, Provincia} Telefono 1 dirige 0..1 Proyecto <<persistent>> <<PK>> Cod_Proyecto Nombre Figura <<persistent>> Figura <<PK>> Figura_Id Cod_Figura <<AK>> Nombre Nombre Color tiene 1..* * Plano <<persistent>> <<PK>> Cod_Plano Fecha_Entrega <<MA>> Arquitectos Dibujo_Plano <<DA>> Num_Figuras Poligono <<persistent>> Num_Lineas 1..* Linea <<persistent>> <<PK>> Id_Linea <<DA>> Longitud <<MA>><<CA>> Puntos: {Coord_X, CoordY}

27 Mecanismos de Extensión 2.2. Estereotipos Estereotipos para SQL:2003 Tipo Estructurado <<udt>> Clase del Metamodelo: Clase Icono: Ninguno Tipo de objeto <<ot>> (udt+tt) Clase del Metamodelo: Clase <<udt>> Icono: <<persistent>> Tipo ROW <<row>> Clase del Metamodelo: Atributo Icono: ARRAY <<array>> Clase del Metamodelo: Atributo Icono: Método Redefinido <<overriding>> Clase del Metamodelo: Método Icono: Ninguno Restricciones: Ninguna Tabla Tipada (tt) Clase del Metamodelo: Clase Icono: Ninguno Compone <<composes>> Clase del Metamodelo: Asociación Icono: None Tipo REF <<ref>> Clase del Metamodelo: Atributo Icono: MULTISET <<Multiset>> Clase del Metamodelo: Atributo Icono: Ninguno Método Diferido <<deferred>> Clase del Metamodelo: Método Icono: Ninguno

28 Mecanismos de Extensión 2.2. Estereotipos Estereotipos para Oracle10g Tipo Estructurado <<udt>> Clase del Metamodelo: Clase Icono: Ninguno Tabla Tipada (tt) Clase del Metamodelo: Clase Icono: Ninguno Tipo de Objeto <<ot>> (udt+tt) Clase del Metamodelo: Clase <<udt>> Icono: <<persistent>> Compone <<composes>> Clase del Metamodelo: Asociación Icono: None VARRAY <<varray>> Clase del Metamodelo: Atributo/Clase Icono: Tipo REF <<ref>> Clase del Metamodelo: Atributo Icono: Nested Table <<nt>> Clase del Metamodelo: Clase Icono:

29 Enunciado 1 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.

30 Enunciado 2 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.

31 Enunciado 10 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.