Fundamentos de Bases de Datos Andy Oppel.Descripción completa
Fundamentos de bases de datosDescripción completa
Manual de Administración de Bases de DatosDescripción completa
Control 7 AICC Fundamentos de bases de datosDescripción completa
Descripción: Implementación de Bases de datos con LabVIEW
Bases de datosDescripción completa
Un pequeño resumen sobre bases de datos, donde se describen varios motores de bases de datos.
Descripción completa
Descripción: base de datos
Descripción completa
Descripción completa
Todo Sobre Bases de DatosDescripción completa
Full description
Descripción completa
Descripción: Bases de Datos
Descripción: Informacion acerca de bases de datos Centralizadas
Descripción completa
CONTENIDOS PREFACIO ____________________________________________________ 4 INTRODUCCIÓN _______________________________________________ 5 MODELO ENTIDAD-RELACIÓN ____________________________________ 9 MODELO RELACIONAL _________________________________________ 28 SQL _______________________________________________________ 38 OTROS LENGUAJES RELACIONALES_______________________________ 51 INTEGRIDAD Y SEGURIDAD _____________________________________ 64 DISEÑO DE BASES DE DATOS RELACIONALES ______________________ 71 BASES DE DATOS ORIENTADAS A OBJETOS ________________________ 84 BASES DE DATOS RELACIONALES ORIENTADAS A OBJETOS ___________ 93 XML ______________________________________________________ 102 ALMACENAMIENTO Y ESTRUCTURA DE ARCHIVOS__________________ 112 INDEXACION Y ASOCIACION ___________________________________ 122 PROCESAMIENTO DE CONSULTAS _______________________________ 134 OPTIMIZACIÓN DE CONSULTAS_________________________________ 142 TRANSACCIONES ____________________________________________ 151 CONTROL DE CONCURRENCIA __________________________________ 157 SISTEMAS DE RECUPERACIÓN __________________________________ 168 ARQUITECTURAS DE SISTEMAS DE BASES DE DATOS _______________ 175 BASES DE DATOS DISTRIBUÍDAS _______________________________ 180 BASES DE DATOS PARALELAS __________________________________ 189
DESARROLLO DE APLICACIONES Y ADMINISTRACIÓN _______________ 195 CONSULTAS AVANZADAS Y RECUPERACIÓN DE LA INFORMACIÓN _____ 200 TIPOS DE DATOS AVANZADOS Y NUEVAS APLICACIONES ____________ 208 PROCESAMIENTO AVANZADO DE TRANSACCIONES _________________ 215
PREFACIO Este volumen es un manual del profesor para la cuarta edición de Fundamentos de Bases de Datos por Abraham Silberschatz, Henry F. Korth y S. Sudarshan. Contiene las respuestas a los ejercicios del final de cada capítulo del libro. Antes de aportar las respuestas a los ejercicios de cada capítulo, se incluyen unos comentarios sobre cada uno. La naturaleza de estos cometarios es variable. Incluyen explicaciones sobre la inclusión u omisión de ciertas materias y se hace notar la manera en que se enseña el capítulo en nuestros propios cursos. Los comentarios también incluyen sugerencias sobre las materias a omitir, si el tiempo es escaso, consejos prácticos sobre el software y el material que se puede emplear para los ejercicios de programación. El inicio de esta edición se han dispuesto en la Web las soluciones de algunos problemas. Estos problemas se han marcado con un “*” en el manual del profesor. La página web del libro, http://www.bell-labs.com/topic/books/db-book, contiene una variedad de información útil, incluyendo la actualización de erratas, apéndices en línea que describen modelos de datos en red, modelos de datos jerárquicos, diseño avanzado de bases de datos relacionales y el modelo del plan de estudios del curso. Periódicamente se actualizará esta página con material suplementario que pueda ser útil a profesores y estudiantes. Se suministra una lista de correo para que los usuarios se puedan comunicar entre sí y con nosotros. Si desea formar parte de la lista envíe un email a [email protected] indicando su nombre, afiliación, puesto y dirección de correo electrónico. Le agradeceríamos que nos hiciera llegar los errores u omisiones del libro, así como del manual del profesor. Aunque hemos intentado escribir un manual del profesor que ayude a los usuarios de nuestro libro tanto como sea posible, siempre se puede mejorar. Se podrían incluir respuestas mejoradas, preguntas adicionales, ejemplos de preguntas de test, proyectos de programación, sugerencias sobre ordenes alternativos de presentación de las materias, referencias adicionales y otros. Si desea sugerir cualquier mejora al libro o al manual del profesor, estaremos encantados de escucharle. El correo electrónico por Internet debe dirigirse a [email protected]. El correo físico debe enviarse a Avi Silberschatz, Laboratorios Bell, Room 2T-310, 600 Mountain Avenue,Murray Hill, NJ 07974, USA. Todas las aportaciones que tengan lugar serán, naturalmente, convenientemente reconocidas a sus autores. Nilesh Dalvi, Sumit Sanghai, Gaurav Bhalotia y Arvind Hulgeri hicieron la mayor parte del trabajo de preparación para la cuarta edición del manual del profesor. Este manual se ha elaborado a partir de los manuales de las ediciones anteriores. El manual de la tercera edición fue preparado por K. V. Raghavan con la ayuda de Prateek R. Kapadia, Sara Strandtman ayudó con el manual del profesor para las ediciones segunda y tercera, mientras que Greg Speegle y Dawn Bezviner ayudaron a preparar el manual del profesor para la primera edición. A.S. H.F.K. S.S. Manual de apoyo al profesor, Versión 4.0.0
CAPITULO
1
INTRODUCCIÓN El Capítulo 1 aporta una visión general sobre la naturaleza y el propósito de los sistemas de bases de datos. El concepto más importante de este capítulo es que los sistemas de bases de datos permiten tratar los datos con un alto nivel de abstracción. Así, los sistemas de bases de datos se diferencian significativamente de los sistemas de ficheros y de los entornos de programación de propósito general, con los cuales ya están familiarizados los estudiantes. Otro aspecto importante del capítulo es animar al empleo de los sistemas de bases de datos, en lugar de los programas de aplicaciones construidos sobre sistemas de ficheros. Así, el capítulo motiva lo que el estudiante estudiará el resto del curso. La idea de la abstracción en los sistemas de bases de datos merece ser enfatizada en todo el proceso, no sólo en la discusión del Apartado 1.3. La visión general de la estructura de las bases de datos que arranca en el Apartado 1.4 es, forzosamente, más bien breve y pretende solamente dar al estudiante una idea aproximada de algunos conceptos. Puede que los estudiantes no sean capaces, inicialmente, de apreciar completamente los conceptos que aquí se describen, pero deberían serlo al final del curso. Las especificaciones de los modelos E-R, relacional y orientados a objeto, se cubren en capítulos posteriores. Estos modelos se pueden emplear en el Capítulo 1 para reforzar el concepto de abstracción, mientras los detalles sintácticos se postergan para más tarde en el curso. Si los estudiantes ya han realizado un curso sobre sistemas operativos, vale la pena mostrar como se relacionan las bases de datos -DBMS- y los sistemas operativos -OS-. También es útil diferenciar entre la concurrencia, tal y como es enseñada en los cursos sobre sistemas operativos (con una orientación hacia ficheros, procesos y recursos físicos) y el control de concurrencia en las bases de datos (con una orientación hacia una granularidad más sutil que el nivel de ficheros, las transacciones de recuperación y los recursos accedidos asociativamente, más que físicamente). Si los estudiantes están familiarizados con un sistema operativo en particular, el enfoque de esos S.O. a un acceso de ficheros concurrentes pude emplearse como ejemplo.
Ejercicios 1.1 ¿Cuáles son las cuatro diferencias principales entre un sistema de procesamiento de archivos y un SGBD? Respuesta: Algunas de las diferencias más importantes entre un sistema de gestión de bases de datos y uno de procesamiento de archivos son: • Ambos sistemas contienen una colección de datos y un conjunto de programas que acceden a ellos. Un sistema de gestión de bases de datos coordina los accesos físicos y lógicos a los datos, mientras que un sistema de procesamiento de ficheros coordina sólo el acceso físico. • Un sistema de gestión de bases de datos reduce la cantidad de datos duplicados, asegurando que una sección física de datos esté disponible para todos los programas autorizados a accederla, mientras que los datos escritos por un programa sobre un sistema de procesamiento de ficheros pueden no ser accesibles por otro programa. • Un sistema de gestión de bases de datos está diseñado para permitir acceso flexible a los datos (es decir, consultas), mientras que un sistema de procesamiento de ficheros está diseñado para permitir predeterminados accesos a los datos(es decir, programas compilados). • Un sistema de gestión de bases de datos está diseñado para coordinar a múltiples usuarios accediendo a los mismos datos en el mismo momento. Un sistema de procesamiento de ficheros generalmente se diseña para permitir que uno o más programas accedan a diferentes ficheros de datos al mismo tiempo. En un sistema de procesamiento de ficheros, dos programas pueden acceder concurrentemente a un fichero sólo si ambos tienen acceso de sólo lectura sobre el fichero. 1.2 En este capítulo se han descrito las diferentes ventajas principales de un sistema gestor de bases de datos. ¿Cuáles son dos de los inconvenientes? Respuesta: A continuación se indican dos inconvenientes asociados con los sistemas de bases de datos. a. La instalación de un sistema de bases de datos requiere más conocimiento, dinero, habilidad y tiempo. b. La complejidad de una base de datos puede originar una disminución del rendimiento. 1.3
Explíquese la diferencia entre independencia física y lógica de los datos.
Respuesta: • La independencia física de los datos es la capacidad para modificar el esquema físico, sin necesidad de rescribir los programas de las aplicaciones. Tales modificaciones incluyen cambiar el almacenamiento de registros desbloqueados a bloqueados, o de ficheros de acceso secuencial a random. • La independencia lógica de los datos es la capacidad para modificar el esquema conceptual, sin necesidad de rescribir los programas de las aplicaciones. Una de estas modificaciones podría ser la adición de un campo a un registro; una vista de los programas de la aplicación oculta este cambio desde los programas.
1.4 Lístense cinco responsabilidades de un sistema de gestión de bases de datos. Para cada responsabilidad, explíquense los problemas que ocurrirían si no se realizara esta función. Respuesta: Un gestor de bases de datos de propósito general (DBM) tiene cinco responsabilidades: a. interaccionar con el gestor de ficheros. b. poner en práctica la integridad c. poner en práctica la seguridad d. copias de seguridad y recuperación e. controlar las concurrencias. Si estas responsabilidades no fueran asumidas por un determinado DBM (y los textos indican que en ocasiones se omite alguna responsabilidad en el diseño, como es el caso del control de concurrencia en un DBM mono puesto para un microordenador) podrían ocurrir, respectivamente, los siguientes problemas: a. Ningún DBM puede hacer nada sin esto; si no hay interacción con el gestor de ficheros no se puede recuperar nada que esté almacenado en los ficheros. b. Pueden no cumplirse las restricciones de integridad, los saldos de las cuentas podían estar por debajo del mínimo permitido, los empleados podrían ganar demasiadas horas extraordinarias (por ejemplo, horas > 80) o los pilotos de las compañías aéreas podrían volar más horas de las que permite la ley. c. Usuarios no autorizados podrían acceder a la base de datos, o usuarios autorizados para acceder a determinadas partes de la base de datos podrían ser capaces de acceder a otras, para las que carecen de autorización. Por ejemplo, un estudiante de escuela superior podría tener acceso a los códigos secretos de la defensa nacional, o los empleados podrían averiguar lo que ganan sus jefes. d. Los datos se podrían perder de forma permanente en vez de, al menos, estar disponibles en el estado de consistencia que existía antes del fallo. e. Se podrían violar la restricciones de integridad a pesar del cumplimiento de la propia integridad en cada transacción. Por ejemplo, se podrían reflejar saldos bancarios incorrectos debido a retiradas y depósitos simultáneos, etcétera. 1.5
¿Cuáles son las cinco funciones principales del administrador de una base de datos?
Respuesta: Las cinco funciones principales del administrador de una base de datos son: • Crear la definición del esquema • Definir la estructura de almacenamiento y los métodos de acceso • Modificar el esquema y/o la organización física cuando sea necesario • Conceder autorización para acceder a los datos • Definir las restricciones de integridad 1.6 Lístense siete lenguajes de programación que sean procedimentales y dos que no lo sean. ¿Qué grupo es más fácil de aprender y de usar? Justifíquese la respuesta. Respuesta: Clasificación de lenguajes de programación: • Procedimentales: C, C++, Java, Basic, Fortran, Cobol, Pascal • No procedimentales: Lisp y Prolog Nota: Lisp y Prolog soportan algunas construcciones procedimentales, pero el núcleo de ambos lenguajes es no procedimental. En teoría los lenguajes no procedimentales son más fáciles de aprender porque permiten al programador concentrarse en lo que necesita ser hecho, en vez de en cómo hacerlo. En la práctica esto no siempre es cierto, especialmente si los lenguajes procedimentales se aprenden primero.
1.7 Lístense los seis pasos principales que se deberían dar en la definición de una base de datos para una empresa particular. Respuesta: Los seis pasos principales en la definición de una base de datos para una determinada empresa particular son: • Definir los requerimientos de alto nivel de la empresa (este paso genera un documento conocido como las especificaciones requeridas por el sistema.) • Definir un modelo conteniendo todos los tipos apropiados de datos y las relaciones entre ellos. • Definir las restricciones de integridad en los datos. • Definir el nivel físico. • Por cada problema conocido que haya de resolverse regularmente (por ejemplo, las tareas a realizar por usuarios Web o auxiliares) definir una interface de usuario para llevar a cabo la tarea y escribir los programas de aplicación necesarios para implantar la interface del usuario. • Crear/inicializar la base de datos. 1.8 Considérese un array de enteros bidimensionales de tamaño n × m que se va a usar en su lenguaje de programación preferido. Usando el array como ejemplo, ilústrese la diferencia (a) entre los tres niveles de abstracción y (b) entre un esquema e instancias. Respuesta: Sea tgrid un array de enteros bidimensionales de tamaño n × m. a. • El nivel físico serían simplemente m × n (probablemente consecutivas) localizaciones de almacenamiento de cualquier tamaño especificado para la implantación (por ejemplo, 32 bits cada una). • El nivel conceptual es un cuadrícula de cajas, cada una conteniendo posiblemente un entero, la cuál es n cajas de alto por m de ancho. • Hay 2m x n vistas posibles. Por ejemplo, una vista podría ser el array entero o una fila particular del array o todas las n filas, pero solamente columnas de 1 a i. b.
• Considérense las siguientes declaraciones Pascal: type tgrid = array[1..n, 1..m] of integer; var vgrid1, vgrid2 : tgrid Entonces tgrid es un esquema, mientras que los valores de las variables vgrid1 y vgrid2 son instancias. • Para ilustrarlo aún más, considérese el esquema array[1..2, 1..2] of integer. Dos instancias de este esquema son: 1 7
16 89
17 90 412 89
CAPITULO
2
MODELO ENTIDAD-RELACIÓN Este capítulo introduce el modelo entidad-relación en detalle. El capítulo abarca numerosas características del modelo, varias de las cuales se pueden omitir dependiendo del alcance del curso que se ha planificado. Conjuntos de entidades débiles (Apartado 2.6), diseño de restricciones (Apartado 2.7.4) y agregación (Apartado 2.7.5), junto con los correspondientes sub apartados del Apartado 2.9 (Reducción de un Esquema E-R a Tablas) se pueden omitir si se dispone de poco tiempo. Se recomienda tratar la especialización (Apartado 2.7.1), al menos con algún detalle, dado que es un concepto importante en las bases de datos orientadas a objeto (Capítulo 8). El propio modelo E-R y los diagramas E-R se emplean a menudo en el texto. Es importante que los estudiantes se encuentren cómodos con ellos. El modelo E-R es un excelente contexto para introducir a los estudiantes en la complejidad del diseño de las bases de datos. Para una empresa dada hay, a menudo, una extensa variedad de diseños E-R. Aunque algunas elecciones son arbitrarias, frecuentemente sucede que un diseño es intrínsecamente mejor que los restantes. Varios de los ejercicios ilustran este punto. La evaluación de las bondades de un diseño E-R requiere un conocimiento de la empresa a modelar y de las aplicaciones a ejecutar. A menudo es posible dirigir a los estudiantes a un debate sobre los méritos relativos de diseños contrapuestos y así ilustrar, por ejemplo, como la comprensión de la aplicación es frecuentemente la parte más dura del diseño de la base de datos. Un énfasis considerable se ha puesto en la construcción de tablas a partir de diagramas E-R. Esto sirve para desarrollar la intuición en la discusión del modelo relacional en los capítulos siguientes. También es útil para convertir los conceptos abstractos, de las entidades y sus relaciones, en los más concretos de las relaciones. Diversos textos sitúan esta materia junto al modelo de datos relacional, en lugar de hacerlo el capítulo del modelo E-R. Nuestra intención, al situar esta materia aquí, es ayudar a los estudiantes a apreciar como se emplean, en la realidad los modelos de datos E-R, mientras se estudia el modelo E-R, en vez de hacerlo más tarde. La materia sobre la conversión de diagramas E-R en tablas es bastante breve en algunos puntos del libro, aportando las transparencias un mejor tratamiento de los detalles que el implícitamente dejado en el libro. Cambios a la tercera edición: En la cuarta edición se han actualizado varios ejemplos, incluyendo relaciones ternarias (empleados, sucursales, trabajo en lugar de cliente, préstamo, sucursal) y agregaciones (administración en lugar de responsable de préstamos), para hacerlos más realistas. También se han añadido más ejemplos, así en la especialización se emplean persona, cliente y empleado como ejemplo principal, en lugar de cuenta, cuentas control y cuentas de ahorro, que también hace el ejemplo más realista. Se ha reemplazado D.N.I. por el más global (y realista) id-cliente e id-empleado. Se han añadido notaciones para hacer restricciones sin conexión y aclarar la participación total (solapamiento y participación parcial están por defecto). Se han introducido notaciones E-R alternativas, dado que numerosas aplicaciones del mundo real las emplean. También se ha aportado una breve introducción a los diagramas de clase UML, que están empezando a emplearse cada vez más en lugar de los diagramas E-R, en herramientas tales como el diseñador de Oracle. Se ha abandonado el alcance de las dependencias de existencia, dado que las restricciones de participación total aportan una restricción muy parecida. La distinción entre participación total y dependencias de existencia es demasiado pequeña como para ser tenida en cuenta y sólo confunde a los estudiantes. Las cuestiones de diseño se discuten en mayor detalle.
Figura 2.1
Diagrama E-R para una compañía de seguros de coches.
Ejercicios 2.1
Explíquense las diferencias entre los términos clave primaria, clave candidata y superclave.
Respuesta: Una superclave es un conjunto de uno o más atributos que, tomados colectivamente, permiten identificar de forma única una entidad en el conjunto de entidades. Una superclave puede contener atributos ajenos. Si K es una superclave, entonces también lo es cualquier superconjunto de K. Una superclave para la que ningún subconjunto propio es también superclave, se denomina clave candidata. Es posible que varios conjuntos diferentes de atributos puedan servir como claves candidatas. La clave primaria es una de las claves candidatas que se elige, por el diseñador de la base de datos, como el elemento principal para identificar las entidades dentro un conjunto de entidades. 2.2 Constrúyase un diagrama E-R para una compañía de seguros de coches cuyos clientes poseen uno o más coches. Cada coche tiene asociado un número, de cero a cualquier valor, que almacena el número de accidentes. Respuesta: Véase la Figura 2.1 2.3 Constrúyase un diagrama E-R para un hospital con un conjunto de pacientes y un conjunto de médicos. Asóciese con cada paciente un registro de las diferentes pruebas y exámenes realizados. Respuesta: Véase la Figura 2.2 2.4 Una oficina de registro de una universidad mantiene datos acerca de las siguientes entidades: (a) cursos, incluyendo número, título, créditos, programa de estudios y requisitos previos; (b) ofertas de cursos, incluyendo número del curso, año, semestre, número de sección, profesor(es), horarios y aulas; (c) estudiantes, incluyendo id-estudiante, nombre y programa; y (d) profesores, incluyendo número de identificación, nombre, departamento y título. Además, se deben modelar adecuadamente la matriculación de los estudiantes en los cursos y las calificaciones otorgadas en cada uno. Constrúyase un diagrama E-R para la oficina de registro. Documéntense todas las suposiciones que se hagan acerca de las restricciones de correspondencia.
Respuesta: Véase la Figura 2.3. En la respuesta dada aquí, los principales conjuntos de entidades son estudiantes, cursos, ofertas-cursos y profesores. El conjunto de entidades ofertas-cursos es un conjunto de entidad débil dependiente de curso. Las suposiciones hechas son: a. una clase sólo se reúne en un lugar y en un momento preciso. Este diagrama E-R no puede modelar una clase que se reúna en diferentes lugares y en diferentes momentos. b. No hay garantía de que la base de datos no tenga dos clases reuniéndose en el mismo lugar y al mismo tiempo.
Figura 2.2
Figura 2.3
Diagrama E-R para un hospital.
Diagrama E-R para una universidad.
2.5 Considérese una base de datos cuyo objeto es registrar las notas que obtienen los estudiantes en los distintos exámenes de los diferentes cursos ofertados. a. Constrúyase un diagrama E-R que modele los exámenes como entidades y haga uso de una relación ternaria para la base de datos anterior. b. Constrúyase un diagrama E-R alternativo que emplee sólo una relación binaria entre estudiantes y ofertas-cursos. Asegúrese de que sólo existe una relación entre un determinado estudiante y un par ofertascursos, y que aún se pueden representar las notas que obtiene un estudiante en los diferentes exámenes de un curso ofertado. Respuesta: a. Véase la Figura 2.4 b. Véase la Figura 2.5
Figura 2.4 2.6
Diagrama E-R para la base de datos de notas.
Constrúyanse las tablas apropiadas para cada uno de los diagramas E-R de los ejercicios 2.2 al 2.4.
Respuesta: a. Tablas de seguros de coches: persona (id-conductor, nombre, dirección) coche (matrícula, año, modelo) accidente (número-informe, fecha, lugar) participado (id-conductor, matrícula, número-informe, cantidad-daños) b.
Tablas del registro de la universidad: estudiante (id-estudiante, nombre, programa) curso (número-curso, título, programa-estudios, créditos) ofertas-cursos (número-curso, número-sección, año, semestre, hora, aula) profesor (id-profesor, nombre, departamento, título) matrículas (id-estudiante, número-curso, número-sección, semestre, año, calificación) enseña (número-curso, número-sección, semestre, año, id-profesor) requerimientos (curso-principal, requisitos-previos)
Figura 2.5
Otro diagrama E-R para la base de datos de notas.
2.7 Diséñese un diagrama E-R para seguir la pista de las hazañas de su equipo de deportes favorito. Se deberían almacenar los partidos jugados, los resultados de cada partido, los jugadores y las estadísticas individuales de cada jugador, para cada partido. Las estadísticas de resumen se deberían modelar como atributos derivados. Respuesta: Véase la Figura 2.6 2.8 Extiéndase el diagrama E-R del ejercicio anterior, a fin de almacenar la misma información para todos los equipos de una liga. Respuesta: Véase la Figura 2.7. Nótese que un jugador sólo puede pertenecer a un equipo durante una temporada. 2.9
Explíquense las diferencias entre conjunto de entidades débiles y fuertes.
Respuesta: Un conjunto de entidades fuertes tiene una clave primaria. Todas las tuplas del conjunto se distinguen por medio de esa clave. Un conjunto de entidades débiles no tiene clave primaria, a menos que se incluyan los atributos del conjunto de entidades fuertes del que depende. En un conjunto de entidades débiles las tuplas están divididas según su relación con las de la entidad fuerte. Las tuplas de cada división se
distinguen mediante un discriminador, que es un conjunto de atributos.
Figura 2.6
Diagrama E-R para las estadísticas del equipo favorito.
Figura 2.7
Diagrama E-R para las estadísticas de todos los equipos.
2.10 Se puede convertir cualquier conjunto de entidades débiles en un conjunto de entidades fuertes, simplemente añadiendo los atributos apropiados. ¿Por qué, entonces, se tienen conjuntos de entidades débiles? Respuesta: Se tienen entidades débiles por varias razones: • Se desea evitar la duplicidad de datos y las consiguientes posibles inconsistencias causadas por las claves duplicadas de la entidad fuerte. • Las entidades débiles reflejan la estructura lógica de una entidad que es dependiente de otra. • Las entidades débiles se pueden borrar automáticamente cuando se borra la entidad fuerte de la que dependen. • Las entidades débiles se pueden almacenar físicamente con sus entidades fuertes.
2.11
Defínase el concepto de agregación. Propónganse dos ejemplos para los que este concepto es útil.
Figura 2.8
Ejemplo 1 de diagrama E-R de agregación.
Figura 2.9
Ejemplo 2 de diagrama E-R de agregación.
Respuesta: La agregación es una abstracción a través de la cual las relaciones se tratan como entidades de nivel más alto. Así, la relación entre las entidades A y B se trata como si fuera una entidad C. Algunos ejemplos de esto son: a. Empleados que trabajan por proyectos. Un empleado trabajando para un proyecto en particular utiliza diversa maquinaria. Véase la Figura 2.8 b. Los fabricantes tienen asociaciones con distribuidores para la distribución de productos. Cada asociación tiene especificado el conjunto de productos que se van a distribuir. Véase la Figura 2.9
Figura 2.10
Diagrama E-R para el Ejercicio 2.12.
2.12 Considérese el diagrama E-R de la Figura 2.29, que modela una librería en línea. a. Lístense los conjuntos de entidades y sus claves primarias. b. Supóngase que la librería añade casetes de música y discos compactos a su colección. El mismo elemento musical puede estar presente en formato de casete o de disco compacto con diferentes precios. Extiéndase el diagrama E-R para modelar este añadido, ignorando el efecto sobre las cestas de la compra. c. Extiéndase ahora el diagrama E-R usando generalización para modelar el caso en que una cesta de la compra pueda contener cualquier combinación de libros, casetes de música o discos compactos. Respuesta: 2.13 Considérese un diagrama E-R en el que el mismo conjunto de entidades aparece varias veces. ¿Por qué está permitida esta redundancia, una mala práctica que se debería evitar siempre que sea posible? Respuesta: Al utilizar un conjunto de entidades muchas veces se están perdiendo relaciones en el modelo. Por ejemplo, en el diagrama E-R de la Figura 2.11: los estudiantes que toman clases son los mismos que son atletas, pero este modelo no lo mostrará.
Figura 2.11
Diagrama E-R con duplicidad de entidades.
2.14 Considérese la base de datos de una universidad para la planificación de las aulas para los exámenes finales. Esta base de datos se modelaría mediante un único conjunto de entidades examen, con atributos nombre-curso, número-sección, número-aula y hora. Alternativamente, se podrían definir uno o más conjuntos de entidades, con conjuntos de relaciones para sustituir algunos de los atributos del conjunto de entidades examen, como • curso con atributos nombre, departamento y número-c • sección con atributos número-s y matriculados, que es un conjunto de entidades débiles dependiente de curso • aula con atributos número-a, capacidad y edificio a. Muéstrese en un diagrama E-R el uso de los tres conjuntos de entidades adicionales listados. b. Explíquense qué aplicaciones características influirían en la decisión de incluir o no, cada uno de los conjuntos de entidades adicionales. Respuesta: a. Véase la Figura 2.12 b. Los conjuntos de entidades adicionales son útiles si se desea almacenar sus atributos como parte de la base de datos. Para el conjunto de entidades curso se han elegido tres atributos a incluir. Si se incluyera solamente la clave primaria (número-c) y si los cursos tuvieran sólo una sección, entonces sería apropiado reemplazar los conjuntos de entidades curso (y sección) por un atributo (número-c) de examen. La razón de que no sea aconsejable tener múltiples atributos de curso como atributos de examen es que, entonces, sería difícil el mantenimiento de los datos en los cursos, en concreto si un curso tuviera varios exámenes o ninguno. Comentarios similares aplican al conjunto de entidades aula.
Figura 2.12
Diagrama E-R para el calendario de exámenes.
2.15 Cuando se diseña un diagrama E-R para un desarrollo particular se tienen varias alternativas entre las que hay que decidir. a. ¿Qué criterio se deberá considerar para hacer la elección apropiada? b. Diséñense tres diagramas E-R alternativos para representar la oficina de registro de la universidad del Ejercicio 2.4. Lístense las ventajas de cada uno. Decídase por una de las alternativas. Respuesta: a. Los criterios a emplear son diseños intuitivos, expresiones fieles del concepto de mundo real y eficiencia. Un modelo que esboza claramente los objetos y las relaciones de una forma intuitiva es mejor que uno que no lo hace, porque es más fácil de usar y de cambiar. Decidirse entre un atributo y conjunto de entidades para representar un objeto y decidirse entre un conjunto de entidades y un conjunto de relaciones, influye en la precisión con que se representan los conceptos del mundo real. Si no se hace la elección de diseño correcta, resultarán inconsistencias y /o pérdidas de información. Es preferible, por razones obvias, un modelo que se pueda implantar de una forma eficiente. b.
Considérense tres alternativas diferentes para el problema del Ejercicio 2.4.
• Véase la Figura 2.13 • Véase la Figura 2.14 • Véase la Figura 2.15 Cada alternativa tiene ventajas, dependiendo del uso previsto de la base de datos. El esquema 2.13 se ha visto anteriormente. El esquema 2.15 no requiere una entidad independiente para requisitos-previos. Sin embargo, será difícil almacenar todos los requisitos previos(siendo un atributo multivalorado). El esquema 2.14 trata los requisitos previos, así como las aulas, como entidades independientes, siendo útil para la recogida de datos sobre los requisitos previos y el uso las habitaciones. El esquema 2.13 está entre medias de los otros, trata los requisitos previos como entidades independientes, pero las aulas no. Dado que una oficina de registro probablemente ha de responder preguntas generales sobre el número de clases que tiene un estudiante, los requisitos previos de un curso o acerca de los lugares concretos en que tienen lugar las clases, el esquema 2.14 es seguramente la mejor elección.
Figura 2.13
Diagrama E-R para una universidad (a).
Figura 2.14
Diagrama E-R para una universidad (b).
Figura 2.15
Diagrama E-R para una universidad (c).
2.16 Un diagrama E-R se puede ver como un grafo. ¿Qué significan los siguientes términos de estructura en un esquema de desarrollo? a. El grafo es inconexo. b. El grafo es acíclico. Respuesta: a. Si un par de conjuntos de entidades están conectados por una línea en un diagrama E-R, los conjuntos de entidades están relacionados, aunque sea indirectamente. Un grafo desconectado implica que hay parejas de conjuntos de entidades que no están relacionadas entre sí. Si se divide el grafo en los componentes conectados se tiene, en efecto, una base de datos independiente. b. Como se ha indicado en la respuesta del apartado anterior, una conexión en el grafo entre un par de conjuntos de entidades indica una relación (posiblemente indirecta) entre ellos. Si hay un ciclo en el grafo, entonces cada par de conjuntos de entidades del ciclo están relacionadas entre sí en, al menos, dos maneras distintas. Si el diagrama E-R es acíclico hay sólo una conexión entre cada par de conjuntos de entidades y, por lo tanto, sólo una relación. 2.17 En el Apartado 2.4.3 se representó una relación ternaria (Figura 2.30a) usando relaciones binarias, como se muestra en la Figura 2.30b. Considérese la alternativa mostrada en la Figura 2.30c. Discútanse las ventajas relativas de estas dos representaciones alternativas entre una relación ternaria y relaciones binarias. Respuesta: El modelo de la Figura 2.30c no será capaz de representar todas las relaciones ternarias. Considérese el conjunto de relaciones ABC siguiente.
Figura 2.30
Diagrama E-R para el Ejercicio 2.17 (no se muestran los atributos). A 1 4 4
B 2 2 8
C 3 7 3
Si ABC está partido en tres conjuntos de relaciones AB, BC y AC, los tres implicarán que la relación (4, 2, 3) es una parte de ABC. 2.18 Considérese la representación de una relación ternaria usando relaciones binarias como se describió en el Apartado 2.4.3 (mostrado en la figura 2.30b). a. Muéstrese una instancia sencilla de E, A, B, C, RA, RBy RC que no pueda corresponderse con ninguna instancia de A, B, C y R. b. Modifíquese el diagrama E-R de la Figura 2.30b para introducir restricciones que garanticen que cualquier ejemplar de E, A, B, C, RA, RB y RC que satisfaga las restricciones, corresponda a una instancia de A, B, C y R. c. Modifíquese la traducción anterior para manejar restricciones de participación total sobre las relaciones ternarias. d. La representación anterior requiere que se cree un atributo clave primaria para E. Muéstrese la forma en que tratar E, como un conjunto de entidades débiles, de manera que no se requiera un atributo clave primaria. Respuesta: a. Sea E = {e1, e2}, A = {a1, a2}, B = {b1}, C = {c1}, RA = {(e1, a1), (e2, a2)}, RB = {(e1, b1)} y RC = {(e1, c1)}. Se ve que debido a la tupla (e2, a2), no existe ninguna instancia de R que se corresponda con E, RA, RB y RC.
Figura 2.31
Diagrama E-R del Ejercicio 2.31b.
Figura 2.32
Diagrama E-R del Ejercicio 2.31d.
b. Véase la Figura 2.31. La idea es introducir restricciones de participación total entre E y las relaciones RA, RB y RC, para que cada tupla en E tenga una relación con A, B y C. c. Supóngase que A participa totalmente en la relación R, entonces introdúzcase una restricción de participación total entre A y RA. d. Considérese a E como un conjunto de entidades débiles y a RA, RB y RC como su conjunto de relaciones identificadoras. Véase la Figura 2.32. 2.19 Un conjunto de entidades débiles siempre se puede convertir en un conjunto de entidades fuertes, añadiéndole a sus atributos los de la clave primaria de su conjunto de entidades identificadoras. Descríbase qué tipo de redundancia resultaría si se hiciese así. Respuesta: La clave primaria de un conjunto de entidades débiles se puede deducir de su relación con el conjunto de entidades fuertes. Si se añaden los atributos de la clave primaria al conjunto de entidades débiles, estarán presentes tanto en el conjunto de entidades como en el de relaciones y serán lo mismo. En consecuencia, habrá redundancia. 2.20 Diséñese una jerarquía de especialización-generalización para las ventas de una compañía de vehículos a motor. La compañía vende motocicletas, coches de pasajeros, mono volúmenes y autobuses. Justifíquese la colocación de los atributos en cada nivel de la jerarquía. Explíquese por qué se deberían colocar en un nivel más alto o más bajo. Respuesta: La Figura 2.33 presenta una posible jerarquía; podría haber muy distintas soluciones. La jerarquía de especialización-generalización para la compañía de vehículos a motor se muestra en la figura. Los atributos modelo, tasa-impuestos-ventas y volumen-ventas son necesarios para todos los tipos de vehículos. Los vehículos comerciales son objeto del impuesto de vehículos comerciales y cada tipo tiene una capacidad
de transporte de pasajeros específica de él. Algunos tipos de vehículos no comerciales están sujetos al impuesto de vehículos de lujo. Los coches solamente pueden se de varios tipos, tales como coches deportivos, sedán, familiares, etc., por tanto el atributo tipo.
Figura 2.33
Diagrama E-R de una compañía que vende vehículos a motor.
2.21 Explíquese la distinción entre las restricciones de diseño definidas por condición y las definidas por el usuario. ¿Cuáles de estas restricciones se pueden comprobar automáticamente? Explíquese la respuesta. Respuesta: En una jerarquía de especialización-generalización debe ser posible decidir qué entidades son miembros del conjunto de entidades de nivel inferior. En una restricción de diseño definidas por condición, la pertenencia al conjunto de entidades de nivel inferior se evalúa partiendo de si una entidad cumple, o no, una condición explícita o predicado. Los conjuntos de entidades de bajo nivel definidas por usuario no están restringidos por una condición de pertenencia; Más bien las entidades están asignadas, por el usuario de la base de datos, a un conjunto de entidades determinado. Las restricciones de diseño definidas por condición sólo se pueden manejar automáticamente por el sistema. Siempre que se inserta cualquier tupla en la base de datos, se puede decidir automáticamente su pertenencia a los varios conjuntos de entidades de nivel inferior, mediante la evaluación de los correspondientes predicados de pertenencia. Igualmente, cuando se actualiza una tupla, se puede volver a evaluar automáticamente su pertenencia a los varios conjuntos de entidades. 2.22
Explíquese la distinción entre las restricciones disjuntas y solapadas.
Respuesta: En una restricción de diseño disjunta, una entidad no puede pertenecer a más de un conjunto de entidades de nivel inferior. En generalizaciones solapadas la misma entidad puede pertenecer a más de un conjunto de entidades de nivel inferior. Así, en el ejemplo del libro sobre los grupos de trabajo de empleados, un jefe puede participar en más de un grupo de trabajo.
Figura 2.34
Diagrama E-R para el Ejercicio 2.24 (no se muestran los atributos).
Figura 2.35 2.23
UML equivalente de la Figura 2.9c
Explíquese la distinción entre las restricciones totales y parciales.
Respuesta: En una restricción de diseño total, cada entidad de nivel superior deber pertenecer a un conjunto de entidades de nivel inferior. Lo mismo no tiene por qué ser cierto en una restricción de diseño parcial. Por ejemplo, algunos empleados pueden no pertenecer a ningún grupo de trabajo. 2.24 En la Figura 2.31 se muestra una estructura reticular de generalización y especialización. Para los conjuntos de entidades A, B y C explíquese cómo se heredan los atributos desde los conjuntos de entidades de nivel más alto X e Y. Discútase cómo manejar el caso en que un atributo de X tiene el mismo nombre que un atributo de Y. Respuesta: A hereda todos los atributos de X y, además, puede definir los suyos propios. Análogamente C hereda, junto con sus propios atributos, todos los de Y. B hereda los atributos de X e Y. Si algunos de los atributos nombre pertenecen a X e Y, puede referirse a B mediante el nombre cualificado X.nombre o Y.nombre. 2.25
Dibújense equivalentes UML de los diagramas E-R de las Figuras 2.9c, 2.10, 2.12, 2.13 y 2.17.
Respuesta: Véanse las Figuras 2.35 a 2.39
2.26 Considérense dos bancos que deciden fusionarse. Asúmase que ambos bancos usan exactamente el mismo esquema de bases de datos E-R - el de la Figura 2.22. (Esta suposición es, naturalmente, muy irreal; se considera un caso más realista en el Apartado 19.8). Si el banco fusionado tiene sólo una base de datos, hay varios problemas potenciales: • La posibilidad de que los dos bancos originales tengan sucursales con el mismo nombre • La posibilidad de que algunos clientes lo sean de ambos bancos originales • La posibilidad de que algunos números de préstamo o de cuenta fueran usados en ambos bancos originales (para diferentes préstamos o cuentas, por supuesto). Por cada uno de estos problemas potenciales descríbase por qué existen de hecho dificultades potenciales. Propóngase una solución a este problema. En la solución, explíquese cualquier cambio que se tenga que hacer y descríbase cómo afectará al esquema y a los datos.
Figura 2.36
UML equivalente de la Figura 2.10
Figura 2.37
UML equivalente de la Figura 2.12
Figura 2.38
UML equivalente de la Figura 2.13
Figura 2.39
UML equivalente de la Figura 2.17
Respuesta: En este ejemplo se asume que ambos bancos tienen los identificadores compartidos para los clientes, como es el caso del D.N.I. La solución general se presenta en el siguiente ejercicio. Cada uno de los problemas mencionados tiene dificultades potenciales.
a. nombre-sucursal es la clave primaria del conjunto de entidades sucursal. Por lo tanto, al fusionar los conjuntos de entidades de los dos bancos, si ambos tienen una sucursal con el mismo nombre uno de ellos se perderá. b. los clientes participan en los conjuntos de relaciones banquero-consejero, prestatario e impositor. Al fusionar los conjuntos de entidades cliente de los dos bancos, las tuplas duplicadas del mismo cliente se borrarán. Por consiguiente se actualizarán las relaciones, de entre los tres conjuntos mencionados, que estén involucradas con las tuplas borradas. Nótese que si la representación tabular de un conjunto de relaciones se obtiene tomando una unión de las claves primarias de los conjuntos de entidades participantes, no será necesario modificar ninguno de estos conjuntos de relaciones. c. El problema causado por préstamos o cuentas con el mismo número en ambos bancos, es similar al causado por las sucursales de los dos bancos con igual nombre-sucursal. Para resolver los problemas originados por la fusión no es necesario modificar el esquema. Mezclar los conjuntos de entidades cliente eliminando tuplas duplicadas con el mismo campo D.N.I. Antes de fusionar los conjuntos de entidades sucursal, prefijar el nombre del banco antiguo al atributo nombre-sucursal en cada tupla. Los conjuntos de entidades empleado y pago se pueden fusionar directamente. No hay que realizar ninguna eliminación de duplicados. Antes de fusionar los conjuntos de entidades préstamos y cuentas, siempre que haya un número común en ambos bancos, el número antiguo se reemplaza por un número nuevo único, en uno de los bancos. Los conjuntos de relaciones siguientes se pueden fusionar. Cualquier relación, en un conjunto de relaciones que implica una tupla que se ha modificado previamente por la fusión, se modifica para conservar el mismo significado. Por ejemplo, sea 1611 un número de préstamo común en ambos bancos antes de la fusión y supongamos que se remplaza por un nuevo y único número 2611 en uno de los bancos, digamos en el banco 2. Ahora todas las relaciones en prestatario, préstamo-sucursal y préstamo-pago del banco 2 que estén referidas al número de préstamo 1611, habrán de modificarse para referirse a 2611. Entonces la fusión con los conjuntos de relaciones correspondientes del banco 1 podrán tener lugar. 2.27 Reconsidérese la situación descrita en el Ejercicio 2.26 bajo la suposición de que un banco está en España y el otro en Portugal. Como antes, los bancos usan el esquema de la Figura 2.22, excepto que el banco portugués usa un número de identificación asignado por el gobierno portugués, mientras que el banco español usa el D.N.I. español para la identificación de clientes. ¿Qué problemas (además de los identificados en el Ejercicio 2.24) ocurrirían en este caso multinacional? ¿Cómo se podrían resolver? Asegúrese de considerar ambos esquemas y los valores de los datos actuales en la construcción de la respuesta. Respuesta: Este es un caso en el que los esquemas de los dos bancos difieren, con lo que la fusión se hace más difícil. El atributo de identificación para las personas en España es el D.N.I. y en Portugal el segurosocial. Por lo tanto, el esquema fusionado no puede emplear ninguno de estos. En su lugar se introduce un nuevo atributo id-persona que se usa por todos en el esquema fusionado. No es necesario ningún otro cambio en el esquema. Los valores del atributo id-persona se pueden obtener de diferentes maneras. Una forma sería prefijar un código de país a los antiguos valores de D.N.I. o seguro-social (por ejemplo “E” y “P”, respectivamente), para obtener los correspondientes valores de id-persona. Otra manera sería asignar nuevos números, empezando en el 1 y hacia arriba, un número para cada valor de D.N.I. y seguro-social en las antiguas bases de datos. Una vez hecho esto, se puede proceder a la fusión de acuerdo a la respuesta de la pregunta anterior. Si un conjunto de relaciones en particular, por ejemplo prestatario, implica sólo a clientes españoles, se puede expresar en la base de datos fusionada especializando el conjunto de entidades cliente en e-cliente y p-cliente, y haciendo que sólo e-cliente participe en el prestatario fusionado. Análogamente, empleados se puede especializar si es necesario.
CAPITULO
3
MODELO RELACIONAL Este capítulo presenta el modelo relacional y tres lenguajes relacionales. El modelo relacional (Apartado 3.1) se emplea intensamente a través del texto, así como el álgebra relacional (Apartado 3.2). El capítulo también abarca el cálculo relacional de tuplas (Apartado 3.6) y el cálculo relacional de dominios (Apartado 3.7) (el cual es la base del lenguaje QBE descrito en el Capítulo 5). Las clases que enfaticen sólo el SQL pueden omitir los lenguajes de cálculo relacional. Nuestra notación para el cálculo relacional de tuplas hace que resulte fácil presentar el concepto de una consulta segura. El concepto de seguridad para el cálculo relacional de dominios, aunque idéntico al cálculo de tuplas, es mucho más engorroso desde el punto de vista de la notación y requiere una presentación cuidadosa. Esta consideración puede sugerir que se aporte un poco menos de énfasis en los cálculos de dominios, para las clases que no hayan planificado tratar QBE. El Apartado 3.3 presenta operaciones de álgebra relacional extendidas, tales como reuniones externas y agregaciones. La evolución de los lenguajes de consultas, tales como SQL, indica claramente la importancia de estas operaciones extendidas. Algunas de estas operaciones, como las reuniones externas, pueden ser expresadas por medio del cálculo relacional de tuplas / dominios, mientras las extensiones son requeridas para otras operaciones, como es el caso de la agregación. Hemos decidido no presentar tales extensiones al cálculo relacional y, en cambio, restringir nuestra atención a las extensiones del álgebra.
Figura 3.38. Diagrama E-R
Ejercicios 3.1 Diséñese una base de datos relacional para la oficina de registro de una universidad. La oficina conserva datos sobre cada curso, incluyendo el profesor, el número de estudiantes matriculados y la hora y el lugar de las clases. Por cada pareja estudiante – curso, se guarda una calificación. Respuesta: Los atributos subrayados indican la clave primaria. estudiante (id-estudiante, nombre, programa) curso (número-curso, título, programa-estudios, créditos) ofertas-cursos (número-curso, número-sección, año, semestre, hora, aula) profesor (id-profesor, nombre, departamento, título) matrículas (id-estudiante, número-curso, número-sección, semestre, año, calificación) enseña (número-curso, número-sección, semestre, año, id-profesor) requerimientos (curso-principal, requisitos-previos) 3.2 Descríbanse las diferencias de significado entre los términos relación y esquema de la relación. Ilústrese la respuesta haciendo referencia a la solución propuesta para el Ejercicio 3.1. Respuesta: Un esquema de la relación es una definición de tipos y una relación es una instancia de ese esquema. Por ejemplo, estudiante (ss#, nombre) es un esquema de la relación y ss# nombre es una relación basada en ese esquema. ss#
123-45-6789 456-78-9123
nombre Tom Jones Joe Brown
3.3
Diséñese una base de datos relacional correspondiente al diagrama E-R de la Figura 3.38.
Respuesta: El esquema de la base de datos relaciones se presenta a continuación. persona (id-conductor, nombre, dirección) coche (matrícula, año, modelo) accidente (número-informe, lugar, fecha) posee (id-conductor, matrícula) participado (número-informe, id-conductor, matrícula, importe-daños) empleado (nombre-persona, calle, ciudad) trabaja (nombre-persona, nombre-compañía, sueldo) compañía (nombre-compañía, ciudad) jefe (nombre-persona, nombre-jefe) Figura 3.39. Base de datos relacional para los Ejercicios 3.5, 3.8 y 3.10. 3.4 En el Capítulo 2 se mostró la manera de representar los conjuntos de relaciones de varios a varios, de varios a uno, de uno a varios y de uno a uno. Explicar la manera en que las claves primarias ayudan a representar estos conjuntos de relaciones en el modelo relacional. Respuesta: Supóngase que la clave primaria del esquema de la relación R es {Ai1, Ai2 , ...,Ain} y que la clave primaria del esquema de la relación S es {Bi1, Bi2 , ...,Bim}. Entonces una relación entre los dos conjuntos se puede representar como una tupla (Ai1, Ai2 , ...,Ain, Bi1, Bi2 , ...,Bim). En una relación de uno a uno, cada valor en {Ai1, Ai2 , ...,Ain} aparecerá en una tupla e igualmete para {Bi1, Bi2 , ...,Bim}. En una relación de varios a uno (por ejemplo de varios A a un B), cada valor en {Ai1, Ai2 , ...,Ain} aparecerá una vez y cada valor en {Bi1, Bi2 , ...,Bin} puede aparecer varias veces. En una relación de varios a varios, los valores en ambos {Ai1, Ai2 , ...,Ain} y {Bi1, Bi2 , ...,Bim}aparecerán varias veces. Sin embargo, en todos los casos anteriores {Ai1, Ai2 , ...,Ain ,Bi1, Bi2 , ...,Bim} es una clave primaria, por lo que ninguna tupla en (Aj1 , ...,Ajn Bk1 , ...,Bkm) aparecerá más de una vez. 3.5 Considérese la base de datos relacional de la Figura 3.39, donde las claves primarias están subrayadas. Formúlese una expresión del álgebra relacional, otra del cálculo relacional de tuplas y una tercera del cálculo relacional de dominios, para cada una de las consultas siguientes: a. Averiguar los nombres de todos los empleados que trabajan para el Banco Importante. b. Averiguar el nombre y la ciudad de residencia de todos los empleados que trabajan para el Banco Importante. c. Averiguar el nombre, la calle y ciudad de residencia, de todos los empleados que trabajan para el Banco Importante y ganan mas de 10.000€ anuales. d. Averiguar el nombre de todos los empleados de esta base de datos que viven en la misma ciudad que la compañía para la que trabajan. e. Averiguar el nombre de todos los empleados que viven en la misma ciudad y en la misma calle que sus jefes. f. Averiguar el nombre de todos los empleados de esta base de datos que no trabajan para el Banco Importante. g. Averiguar el nombre de todos los empleados que ganan más que cualquier empleado del Banco Pequeño. h. Supóngase que las compañías pueden estar ubicadas en varias ciudades. Buscar todas las empresas con sede en todas las ciudades en las que tiene sede el Banco Pequeño.
Respuesta: a. Õnombre-persona (snombre-compañía = “Banco Importante” (trabaja)) b.
f. Las soluciones siguientes asumen que todas las personas trabajan para una compañía. Si se permite que aparezcan personas en la base de datos (por ejemplo en empleado) pero que no aparezcan en trabaja, el problema se complica. Más adelante se dan soluciones para este caso más realista. Õnombre-persona (snombre-compañía ¹ “Banco Importante” (trabaja)) Si las personas no pueden trabajar para cualquier compañía: Õnombre-persona (empleado) - Õnombre-persona (s(nombre-compañía = “Banco Importante”) (trabaja)) g. 1
h.
Õnombre-persona (trabaja) - Õtrabaja.nombre-persona (trabaja |x| (trabaja.sueldo £ trabaja2.sueldo Ù trabaja2.cpnmbre-compañía =“Banco Pequeño”) r trabaja2 (trabaja))) Nota: El Banco Pequeño se incluirá en cada respuesta. Õnombre-compañïa (compañía ÷ (Õciudad (snombre-compañía = “Banco Pequeño” (compañía))))
3.6 Considérese la relación de la Figura 3.21, que muestra el resultado de la consulta “Averígüese el nombre de todos los clientes que tienen un préstamo en el banco.” Escríbase de nuevo la consulta para incluir no solamente el nombre, sino también la ciudad de residencia de cada cliente. Obsérvese que ahora el cliente Sotoca ya no aparece en el resultado, aunque en realidad tiene un préstamo del banco. a. Explíquese por qué Sotoca no aparece en el resultado. b. Supóngase que desea que Sotoca aparezca en el resultado. ¿Cómo habría que modificar la base de datos para conseguirlo? c. Nuevamente, supóngase que desea que Sotoca aparezca en el resultado. Escríbase una consulta empleando una reunión externa que cumpla esta condición sin que haya que modificar la base de datos. Respuesta: La nueva consulta es Õnombre-cliente,ciudad-cliente,importe(prestatario |x| préstamo |x| cliente) 1
1
a. Aunque Sotoca tenga un préstamo, en la relación cliente no aparece ninguna dirección para Sotoca. Dado que ninguna tupla de cliente se une con la tupla Sotoca de prestatario, Sotoca no puede aparecer en el resultado. b. La mejor solución es insertar la dirección de Sotoca en la relación cliente. Si se desconoce la dirección, se pueden emplear valores nulos. Si el sistema de base de datos no soporta nulos, se puede emplear un valor especial (tal como desconocido) para la ciudad y la calle de Sotoca. El valor especial escogido no
debe ser un nombre que se pueda corresponder con el de una calle o ciudad real. c.
3.7 Las operaciones de reunión externa amplían la operación reunión natural, de manera que las tuplas de las relaciones participantes no se pierdan en el resultado de la reunión. Descríbase la manera en que la operación reunión zeta puede ampliarse para que las tuplas de la relación de la izquierda, derecha, o ambas, no se pierdan en el resultado de una reunión zeta. Respuesta: a. La reunión zeta externa por la izquierda de r(R) y s(S) (r ]x|q s) se puede definir como (r |x|q s) È ((r - ÕR(r |x|q s)) × (nulo,nulo, . . ., nulo)) La tupla de nulos es de tamaño igual al número de atributos en S. b. La reunión zeta externa por la derecha de r(R) y s(S) (r |x[q s) se puede definir como (r |x|q s) È ((nulo,nulo, . ., nulo) × (s - Õs(r |x|q s))) La tupla de nulos es de tamaño igual al número de atributos en R. c. La reunión zeta externa completa de r(R) y s(S) (r ]x[q s) se puede definir como (r |x|q s) È ((nulo,nulo, . . ., nulo) × (s - Õs(r |x|q s))) È ((r - ÕR(r |x|q s)) × (nulo,nulo, . . ., nulo)) La primera tupla de nulos es de tamaño igual al número de atributos en R y la segunda es de tamaño igual al número de atributos en S. 3.8 Considérese la base de datos relacional de la Figura 3.39. Se da una expresión del álgebra relacional para cada petición: a. Modificar la base de datos de forma que Santos viva en Tres Cantos. b. Dar a todos los empleados del Banco Importante un aumento de sueldo del 10%. c. Dar a todos los jefes de la base de datos un aumento de sueldo del 10%. d. Dar a todos los jefes de la base de datos un aumento de sueldo del 10%, a menos que su sueldo esté por encima de 100.000 € anuales. En tal caso, darles sólo un 3%. e. Borrar todas las tuplas de la relación trabaja para los empleados del Banco Pequeño. Respuesta: a. empleado ¬ Pnombre-persona,calle,“Tres Cantos” (snombre-persona =“Santos”(empleado)) È (empleado - snombre-persona =“Santos”(empleado)) b.
c. La sintaxis de actualización permite referenciar sólo a una relación sencilla. Dado que esta actualización requiere acceder a las dos relaciones a actualizar (trabaja) y jefe, se deben seguir varios pasos. En primer lugar, identificar las tuplas de trabaja que se han se actualizar y almacenarlas en una relación temporal (t1) Después, crear una relación temporal (t2) que contenga las nuevas tuplas. Finalmente borrar las tuplas en t1, desde trabaja, e insertar las tuplas t2. t1 ¬ Ptrabaja.nombre-persona, nombre-compañía, salario (strabaja.nombre-persona = nombre-jefe (trabaja × jefe)) t2 ¬ Pnombre-persona,nombre-compañía, 1.1 * salario (t1) trabaja(trabaja - t1) È t2 d. La misma situación surge aquí. Como antes, t1, contiene las tuplas que se han de actualizar y t2 contiene estas tuplas en su forma actualizada.
t1 ¬ Ptrabaja.nombre-persona, nombre-compañía, salario (strabaja.nombre-persona = nombre-jefe (trabaja × jefe)) t2 ¬ Ptrabaja.nombre-persona, nombre-compañía, salario*1.03 (st1.salario * 1.1 > 100.000(t1)) t2 ¬ t2 È(Ptrabaja.nombre-persona, nombre-compañía, salario*1.1 (st1.salario * 1.1 £ 100.000(t1)) trabaja(trabaja - t1) È t2 e. trabaja ¬ trabaja - snombre-compañía = “Banco Pequeño” (trabaja) 3.9 Utilizando el ejemplo bancario, escríbanse consultas del álgebra relacional para averiguar las cuentas por más de dos clientes: a. Utilizando una función de agregación. b. Sin utilizar funciones de agregación. Respuesta: a. t1 ¬ número-cuenta Gcount nombre-cliente (impositor) Õnúmero-cuenta (snúmero-titulares>2 (rtitulares-cuenta (número-cuenta,número-titulares)(t1))) b.
3.10 Considérese la base de datos relacional de la Figura 3.39. Se da una expresión del álgebra relacional para cada una de las consultas siguientes: a. Averiguar la compañía con mayor número de empleados. b. Averiguar la compañía con nómina (suma de sueldos de sus empleados) más reducida. c. Averiguar las compañías cuyos empleados ganan un sueldo más alto, en media, que el sueldo medio del Banco Importante. Respuesta: a. t1 ¬ nombre-compañía G count-distinct nombre-persona (trabaja) t2 ¬ max número-empleados(r fuerza-compañía (nombre-compañía,número-empleados)(t1)) Õnombre-compañía(r t3 (nombre-compañía,número-empleados)(t1) |x| r t4 (número-empleados)(t2)) b.
t1 ¬ nombre-compañía G sum sueldo (trabaja) t2 ¬ min nómina (r nómina-compañía (nombre-compañía,nómina)(t1)) Õnombre-compañía(r t3 (nombre-compañía,nómina)(t1) |x| r t4 (nómina)(t2))
Dense dos motivos por los que se puede decidir definir una vista.
Respuesta: a. Las condiciones de seguridad pueden requerir que la base de datos lógica no sea totalmente visible para todos los usuarios. b. Puede que se desee crear un conjunto personalizado de relaciones que se adapte mejor que el modelo lógico a la intuición de un usuario concreto.
3.12 Cítense dos problemas importantes del procesamiento de la operación actualización, expresadas en términos de vistas. Respuesta: Las vistas presentan problemas significativos si se expresan con ellas actualizaciones. La dificultad radica en que las modificaciones de la base de datos, expresadas en términos de vistas, deben traducirse en modificaciones de las relaciones reales en el modelo lógico de la base de datos. a. Dado que la vista puede no tener todos los atributos de las tablas subyacentes, la inserción de una tupla en la vista insertará tuplas en las tablas subyacentes, tomando valores nulos los atributos no participan de la vista. Esto puede no ser conveniente, especialmente si el atributo en cuestión es parte de la clave primaria de la tabla. b. Si una vista es una reunión de varias tablas subyacentes y una inserción da como resultado tuplas con nulos en las columnas de la reunión, no se logrará el efecto deseado de la inserción. En otras palabras, una actualización para una vista puede no ser capaz de expresar, en absoluto, como actualiza para las relaciones de base. Para un ejemplo explicativo, consultar el de la actualización de información-crédito, en el Apartado 3.5.2. 3.13
Sean los siguientes esquemas de relación: R = (A, B, C) S = (D, E, F) Sean las relaciones r(R) y s(S). Se da una expresión del cálculo relacional de tuplas que sea equivalente a cada una de las expresiones siguientes: a.
PA(R)
b. c.
sB = 17 (r) rxs
d.
PA, F (sC = D(r x s))
Respuesta: a. {t | $ q Î r (q[A] = t[A])} b.
{t | t Î r Ù t[B] = 17}
c.
{t | $ p Î r $ q Î s (t[A] = p[A] Ù t[B] = p[B]Ù t[C] = p[C] Ù t[D] = q[D] Ù t[E] = q[E] Ù t[F] = q[F])}
d.
{t | $ p Î r $ q Î s (t[A] = p[A] Ù t[F] = q[F] Ù p[C] = q[D]}
3.14 Sea R = (A, B, C) y sean r1 y r2 relaciones del esquema R. Se da una expresión del cálculo relacional de dominios que sea equivalente a las expresiones siguientes: a. PA(r1) b. sB = 17 (r1) c. . r1 È r2 d. . r1 Ç r2 e. . r1 - r2 f. PA, B(r1) |x| PB, C(r2) Respuesta: a. {< t > | $ p, q (< t, p, q > Î r1)} b.
{< a, b, c > | < a, b, c > Î r1 Ù b = 17}
c.
{< a, b, c > | < a, b, c > Î r1 Ú < a, b, c > Î r2}
d.
{< a, b, c > | < a, b, c > Î r1 Ù < a, b, c > Î r2}
e.
{< a, b, c > | < a, b, c > Î r1 Ù < a, b, c > Ï r2}
f.
{< a, b, c > | $ p, q (< a, b, p > Î r1 Ù < q, b, c > Î r2)}
3.15
Repítase el Ejercicio 3.5 usando el cálculo relacional de tuplas y el de dominios.
Respuesta: a. Averiguar los nombres de todos los empleados que trabajan para el Banco Importante: i. {t | $ s Î trabaja (t[nombre-persona] = s[nombre-persona] Ù s[nombre-compañía] = “Banco Importante”)} ii. { < p > | $ c, s (< p, c, s >Î trabaja Ù c = “Banco Importante”)} b. Averiguar el nombre y la ciudad de residencia de todos los empleados que trabajan para el Banco Importante: i.{t |$ r Î empleado $ s Î trabaja (t[nombre-persona] = r[nombre-persona] Ù t[ciudad] = r[ciudad] Ù r[nombre-persona] = s[nombre-persona] Ù s[nombre-compañía] = “Banco Importante”)} ii. {< p,c > | $ co, sa, st (< p,co,sa >Î trabaja Ù < p,st,c >Î empleado Ù co = “Banco Importante”)} c. Averiguar los nombres, direcciones y ciudades de residencia de todos los empleados que trabajan para el Banco Importante y ganan más de 10.000 € anuales. i. {t | t Î empleado Ù ($ s Î trabaja ( s[nombre-persona] = t[nombre-persona] Ù s[nombre-compañía] = “Banco Importante” Ù s[sueldo] > 10.000))} ii. {< p, s, c > | < p, s, c > Î empleado Ù $ co, sa (< p,co,sa > Î trabaja Ù co = “Banco Importante” Ù sa > 10.000)} d. Averiguar el nombre de todos los empleados de esta base de datos que viven en la misma ciudad que la compañía para la que trabajan: i. {t | $ e Î empleado $ w Î trabaja $ c Î compañía (t[nombre-persona] = e[nombre-persona] Ù e[nombre-persona] = w[nombre-persona] Ù w[nombre-compañía] = c[nombre-compañía] Ù e[ciudad] = c[ciudad])} ii. {< p > | $ st, c, co, sa (< p,st,c > Î empleado Ù < p,co,sa > Î trabaja Ù < co,c > Î compañía)} e. Averiguar el nombre de todos los empleados que viven en la misma ciudad y en la misma calle que sus jefes: i. { t | $ l Î empleado $ m Î jefe $ r Î empleado (l[nombre-persona] = m[nombre-persona] Ù m[nombre-jefe] = r[nombre-persona] Ù l[calle] = r[calle] Ù l[ciudad] = r[ciudad] Ù t[nombre-persona] = l[nombre-persona])} ii. {< t > | $ s, c, m (< t, s, c > Î empleado Ù < t,m > Î jefe Ù < m, s, c > Î empleado)} f.
Averiguar el nombre de todos los empleados de esta base de datos que no trabajan para el Banco
Importante: Si se permite que aparezcan personas en la base de datos (por ejemplo en empleado) pero que no aparezcan en trabaja, el problema se complica. Más adelante se dan soluciones para este caso más realista. i. { t | $ w Î trabajas ( w[nombre-compañía] ¹ “Banco Importante” Ù t[nombre-persona] = w[nombre-persona])} ii. { < p > | $ c, s (< p, c, s > Î trabaja Ù c ¹ “Banco Importante”)} Si las personas no pueden trabajar para cualquier compañía: i. { t | $ e Î empleado ( t[nombre-persona] = e[nombre-persona] Ù ¬ $ w Î trabaja (w[nombre-compañía] = “Banco Importante” Ù w[nombre-persona] = t[nombre-persona]))} ii. { < p > | $ s, c (< p, s, c > Î empleado) Ù ¬ $ x, y (y = “Banco Importante”Ù < p, y, x > Î trabaja)} g. Averiguar el nombre de todos los empleados que ganan más que cualquier empleado del Banco Pequeño: i. { t | $ w Î trabaja ( t[nombre-persona] = w[nombre-persona] Ù " s Î trabaja (s[nombre-compañía] = “Banco Pequeño” Þ w[sueldo] > s[sueldo]))} ii. {< p > | $ c, s (< p, c, s > Î trabaja Ù " p2, c2, s2 (< p2, c2, s2 > Ï trabaja Ú c2 ¹ “Banco Pequeño” Ú s > s2))} h. Supóngase que las compañías pueden estar ubicadas en varias ciudades. Buscar todas las empresas con sede en todas las ciudades en las que tiene sede el Banco Pequeño. Nota: El Banco Pequeño se incluirá en cada respuesta. i. {t | " s Î compañía (s[nombre-compañía] = “Banco Pequeño” Þ $ r Î compañía (t[nombre-compañía] = r[nombre-compañía] Ù r[ciudad] = s[ciudad]))} ii. {< co > | " co2, ci2 (< co2, ci2 > Ï compañía Ú co2 ¹ “Banco Pequeño” Ú < co,ci2 > Î compañía)} 3.16 Sean R = (A,B) y S = (A,C), y sean las relaciones r(R) y s(S). Escribir expresiones del álgebra relacional equivalentes a las siguientes expresiones del cálculo relacional de dominios: a. { | $ b ( Î r Ù b = 17)} b. { | Î r Ù Î s} c. { | $ b ( Î r) Ú " c ($ d ( Î s) Þ Î s)} d. { | $ c ( Î s) Ù $ b1, b2 ( Î r Ù < c, b2> Î r Ù b1 > b2))} Respuesta: a. ÕA (sB = 17 (r)) b.
