disen˜o e implementacio´n de bases datos relacionalesjaguila/databases/data_base_design.pdf ·...
Post on 15-Aug-2020
7 Views
Preview:
TRANSCRIPT
Diseno e Implementacion de Bases Datos
Relacionales
Recopilacion y adaptacion de los apuntes de los cursos de bases de datos
utilizados por el recopilador
Recopilador: Julio J. Aguila G.
Autores: Cesar Guerrero Saldivia
Mauricio Marın
Punta Arenas, julio 2014
Resumen
Este libro es una recopilacion y adaptacion de los apuntes utilizados por el recopilador. Por
una parte, se toma en cuenta el curso Fundamentos de Bases de Datos de Cesar Guerrero
Saldivia. Por otra parte se reutilizan los apuntes del curso Bases de Datos Relacionales
de Mauricio Marın. El primero escribio el curso como docente de la Universidad de Chile;
el segundo escribio el apunte como docente de la Universidad de Magallanes.
Este libro es un primer borrador al cual se le deben realizar algunas modificaciones de
forma, pero el fondo de los cursos originales se mantiene intacto. Se han realizado algunas
adaptaciones visto que los sistemas operativos y las herramientas de programacion han
cambiado. En particular, los codigos de esta traduccion han sido compilados para mysql en
una terminal de Ubuntu 11.04-the Natty Narwhal —sin soporte desde 2012—, y deberıan
ser compatibles con las ultimas versiones de Ubuntu.
i
Contenidos
1 Introduccion 1
1.1 Modelos de datos y definiciones . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Vista general de un DBMS . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.1 Lenguajes de bases de datos . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.2 Usuarios de una base de datos . . . . . . . . . . . . . . . . . . . . . 7
1.2.3 Estructura fısica de un DBMS . . . . . . . . . . . . . . . . . . . . . 7
2 Modelo Entidad-Relacion 11
2.1 Tipos de atributos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2 Tipos de relaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3 Conceptos adicionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4 Metodologıa para desarrollar diagramas . . . . . . . . . . . . . . . . . . . . 19
2.5 Unas notas sobre la tipografıa . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.6 Ejercicios propuestos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3 Modelo Relacional 25
3.1 Dominios, tuplas, atributos, relaciones . . . . . . . . . . . . . . . . . . . . . 25
3.1.1 Notacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.1.2 Restricciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2 Bases de datos relacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3 Paso de modelo E-R a modelo relacional . . . . . . . . . . . . . . . . . . . . 32
3.4 Ejercicios propuestos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4 MySQL Workbench: herramienta de diseno 41
4.1 Introduccion a MySQL Workbench . . . . . . . . . . . . . . . . . . . . . . . 42
4.2 ¿Como crear un diagrama EER? . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2.1 Creacion de tablas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
iii
4.2.2 Creacion de relaciones . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.3 Ejemplo de aplicacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.4 Ejercicios propuestos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5 Algebra Relacional 51
5.1 Notas sobre el modelo relacional . . . . . . . . . . . . . . . . . . . . . . . . 52
5.2 Algebra relacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.2.1 Operadores fundamentales . . . . . . . . . . . . . . . . . . . . . . . . 53
5.2.2 Operadores derivados . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.3 Nota final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.4 Ejercicios propuestos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6 SQL 61
6.1 Consultas con SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
7 API C de MySQL 63
7.1 Base de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
7.2 Makefile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
7.3 Codigo fuente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
8 Normalizacion 73
8.1 Problemas que genera un mal diseno . . . . . . . . . . . . . . . . . . . . . . 74
8.2 Primera Forma Normal: 1FN . . . . . . . . . . . . . . . . . . . . . . . . . . 76
8.3 Segunda Forma Normal: 2FN . . . . . . . . . . . . . . . . . . . . . . . . . . 77
8.3.1 Dependecia funcional . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
8.3.2 Propiedades deseables de una descomposicion . . . . . . . . . . . . . 79
8.3.3 Conservacion de las dependencias funcionales . . . . . . . . . . . . . 81
8.3.4 2FN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
8.4 Tercera Forma Normal: 3FN . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Lista de Figuras
1.1 Modelo de datos y sus posibles implementaciones . . . . . . . . . . . . . . . 5
1.2 Vision general de un DBMS . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1 Diagrama E-R de la base de datos EMPRESA . . . . . . . . . . . . . . . . . . 13
2.2 Diagrama E-R de la base de datos de inscripciones y notas . . . . . . . . . 13
2.3 Ejemplo de jerarquıa con atributos compuestos . . . . . . . . . . . . . . . . 15
2.4 Ejemplo de instancias de la relacion TRABAJA PARA . . . . . . . . . . . . . . 16
2.5 Relacion ADMINISTRA con un grado de cardinalidad 1:1 . . . . . . . . . . . . 17
2.6 Relacion TRABAJA EN con un grado de cardinalidad n:m . . . . . . . . . . . 17
2.7 Ejemplo de generalizacion de entidades . . . . . . . . . . . . . . . . . . . . . 19
2.8 Diagrama E-R sistema de reservaciones de una lınea aerea . . . . . . . . . . 24
3.1 Diagrama E-R de la base de datos EMPRESA . . . . . . . . . . . . . . . . . . 33
4.1 Interfaz de inicio para MySQL Workbench . . . . . . . . . . . . . . . . . . . 43
4.2 Interfaz de creacion para los diagramas EER . . . . . . . . . . . . . . . . . 43
4.3 Tabla recien creada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.4 Menu Tabla de MySQL Workbench . . . . . . . . . . . . . . . . . . . . . . . 44
4.5 Pestana ‘Columns’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.6 Menu Relaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.7 Menu ‘Foreign Key’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.8 Ejemplo de aplicacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.9 Crear tabla DEPT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.10 Definir columnas de la tabla DEPT . . . . . . . . . . . . . . . . . . . . . . . 48
4.11 Definir columnas de la tabla EMP . . . . . . . . . . . . . . . . . . . . . . . 48
4.12 Agregar clave foranea a tabla EMP . . . . . . . . . . . . . . . . . . . . . . . 48
4.13 Crear referencia hacia tabla DEPT . . . . . . . . . . . . . . . . . . . . . . . 49
v
4.14 Crear referencia utilizando Menu Relaciones . . . . . . . . . . . . . . . . . . 49
4.15 Diagrama E-R de la base de datos EMPRESA . . . . . . . . . . . . . . . . . . 50
Lista de Tablas
1.1 Tabla de alumnos y notas sin normalizar . . . . . . . . . . . . . . . . . . . . 3
3.1 Ejemplo de instancia para la relacion ESTUDIANTE . . . . . . . . . . . . . 26
3.2 Instancia de la tabla EMPLEADO . . . . . . . . . . . . . . . . . . . . . . . 30
3.3 Instancia de la tabla DEPARTAMENTO . . . . . . . . . . . . . . . . . . . 30
3.4 Instancia de la tabla UBICACIONES DEPTO . . . . . . . . . . . . . . . . 30
3.5 Instancia de la tabla PROYECTO . . . . . . . . . . . . . . . . . . . . . . . 31
3.6 Instancia de la tabla TRABAJA EN . . . . . . . . . . . . . . . . . . . . . . 31
3.7 Instancia de la tabla CARGA . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.1 Equivalencia entre conceptos . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.2 Relacion generica R . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.3 Relacion generica S . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.4 Resultado de R ∪ S . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.5 Resultado de R - S . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.6 Resultado de S - R . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.7 Relacion generica T . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.8 Relacion generica U . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.9 Resultado de T × U . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.10 Relacion generica W . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.11 Resultado de πC(W ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.12 Resultado de πD,F (W ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.13 Resultado de σC=c1(W ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.14 Resultado de σC=c1andD=d1andF 6=f1(W ) . . . . . . . . . . . . . . . . . . . . 55
5.15 Resultado de R ∩ S . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.16 Resultado de T ⋊⋉E 6=e1 U . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.17 Relacion generica V . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
vii
5.18 Relacion generica W . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.19 Resultado de V ⋊⋉ W . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.20 Resultado de W ÷ V . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.21 Ejemplo de relacion vacıa . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
8.1 Muestra original de la relacion Proveedor . . . . . . . . . . . . . . . . . . . 75
8.2 Relacion P . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
8.3 Relacion I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
8.4 Resultado de P ⋊⋉ I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
8.5 Consulta sobre P ⋊⋉ I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
8.6 Relacion R no normalizada . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
8.7 Relacion R normalizada en 1FN . . . . . . . . . . . . . . . . . . . . . . . . . 76
Capıtulo 1
Introduccion
El almacenamiento, manipulacion y recuperacion de informacion en forma eficiente, es
vital y estrategico para cualquier organizacion. Las bases de datos juegan un rol crıtico en
casi todas las areas donde las computadoras son usadas, incluyendo negocios, ingenierıa,
medicina, leyes, educacion, etc.
Una base de datos es una coleccion de datos relacionados que representa un cierto
modelo o abstraccion del mundo real (algunas veces llamado el mini-mundo). Los cambios
en este mini-mundo son reflejados en la base de datos. Una base de datos es disenada,
construida y llenada con datos para un proposito especıfico. Tiene un grupo de usua-
rios particular, y algunas aplicaciones pre-establecidas en las cuales estos usuarios estan
interesados.
En otras palabras, una base de datos tiene alguna “fuente” de la cual los datos son
derivados, algun grado de interaccion con eventos en el mundo real, y una audiencia que
esta activamente interesada en el contenido de la base de datos.
Un Sistema Administrador de Base de Datos (SABD o DBMS por Data Base Manage-
ment System) es una coleccion de programas que permite a los usuarios crear y mantener
una base de datos.
La importancia de almacenar, manipular y recuperar la informacion en forma eficiente
ha llevado al desarrollo de una teorıa esencial para las bases de datos. Esta teorıa ayuda al
diseno de bases de datos y procesamiento eficiente de consultas por parte de los usuarios.
El uso de las base de datos es contrario al enfoque tradicional, en que cada sistema
1
2 Capıtulo 1. Introduccion
maneja sus propios datos y archivos. Al usar una base de datos, todos los datos se
almacenan en forma integrada, y estan sujetos a un control centralizado. Las diversas
aplicaciones operan sobre este conjunto de datos.
Considerese el siguiente ejemplo: Se desea almacenar la informacion de los alumnos de
una carrera, con los ramos que inscriben cada semestre y sus respectivas notas. Estos datos
se pueden almacenar en una matriz, fijando un maximo de cursos que pueden inscribir
cada semestre. La Tabla 1.1 muestra una forma de como realizar esto.
Se pueden observar las siguientes desventajas:
• Se repiten varios datos, como el nombre del alumno, su numero de matrıcula, etc.
• Si se desea modificar el nombre de una persona, entonces se debe buscar en toda la
matriz.
• Para obtener el promedio de una persona, o saber cuanta gente inscribe un curso
cada semestre, se debe leer secuencialmente todo el archivo.
• Etc.
Cuando se tienen pocos datos no es mucha la perdida de tiempo y espacio, pero cuando
se trata de cientos de miles de datos, o peor aun, millones de datos, el usuario se enfrenta
a un serio problema. Esta redundancia al definir y almacenar los datos implica espacio
de almacenamiento desperdiciado y esfuerzos redundantes para mantener actualizados los
datos.
3
Matrıcula Nombre Semestre Curso 1 Nota 1 Curso 2 Nota 2 Curso 3 Nota3 . . .654564 Juan Perez 97/1 FI21A 4.5 MA22A 4.2 QI21A 4.3 . . .353090 Luis Gonzalez 97/1 FI33A R MA34A 4,6 CC30A 5.5 . . .672680 Jose Tapia 97/1 FI10A * CC10A * MA11A * . . .. . . . . . . . .654564 Juan Perez 97/2 MA33A R SD20A 5.7 MA26A E . . .353090 Luis Gonzalez 97/2 CC31A 6,2 MA37A 4,5 CC31B R . . .672680 Jose Tapia 97/2 FI10A R CC10A R MA11A 4.2 . . .. . . . . . . . .
Tabla 1.1: Ejemplo de como almacenar informacion para los alumnos de una carrera utilizando un enfoque contrario al de las bases de datos normalizadas.
4 Capıtulo 1. Introduccion
En el enfoque de bases de datos se mantiene un unico almacen de datos que se define
una sola vez y al cual tienen acceso muchos usuarios. Las principales ventajas sobre el
enfoque tradicional son:
• Evita los datos repetidos (redundancia).
• Evita que distintas copias de un dato tengan valores distintos (inconsistencia).
• Evita que usuarios no autorizados accedan a los datos (seguridad).
• Protege los datos contra valores no permitidos (integridad o restricciones de consis-
tencia).
• Permite que uno o mas usuarios puedan accesar simultaneamente a los datos (con-
currencia).
1.1 Modelos de datos y definiciones
Una caracterıstica fundamental del enfoque de bases de datos es que proporciona cierto
nivel de abstraccion de los datos, al ocultar detalles de almacenamiento que la mayorıa de
los usuarios no necesitan conocer. Los modelos de datos son el principal instrumento para
ofrecer dicha abstraccion.
Un modelo de datos es un conjunto de conceptos que pueden ser usados para describir
la estructura de una bases de datos. Con el concepto de estructura de una bases de datos
se hace referencia a los tipos de datos, las relaciones y las restricciones que deben cumplirse
para esos datos. Por lo general, los modelos de datos contienen ademas un conjunto de
operaciones basicas para especificar lecturas y actualizaciones de la base de datos.
Los principales objetivos del proceso de modelamiento es saber identificar cual es el
problema y encontrar la forma de representarlo en un sistema. Esto significa saber de los
datos, saber quienes van a usarlos y como van a ser usados.
El modelamiento de datos es independiente de hardware o software usado para su
implementacion. Un modelo Entidad-Relacion, puede ser implementado en bases de datos
jerarquicas, de red o relacionales, entre otras (ver Figura 1.1). Ası, existen diferentes
niveles de abstraccion:
Nivel Fısico Son los datos tal como son almacenados en el computador. Por ejemplo:
1.1. Modelos de datos y definiciones 5
Figura 1.1: Ejemplo de un modelo Entidad-Relacion implementado en diferentes sistemas debases de datos.
archivos, metodos de acceso, ındices, etc. En un DBMS, el nivel fısico es transparente
para el usuario.
Nivel Conceptual Se describen que datos se almacenan y las relaciones que existen entre
ellos. Usualmente el usuario trabaja en este nivel y no se preocupa de los detalles
del nivel fısico.
Nivel de Vistas Es un subconjunto del nivel conceptual. A determinados usuarios de
la base de datos se les presenta solo un subconjunto de los datos. Para una misma
base de datos se pueden construir varias vistas segun el tipo de usuarios del DBMS.
6 Capıtulo 1. Introduccion
Desde estos enfoques se tiene lo siguiente: una instancia es el contenido de la base de
datos en algun momento dado en el tiempo. Un esquema es la descripcion de la estructura
de la dase de datos en un determinado nivel. Se habla de esquema fısico, esquema con-
ceptual y subesquema conceptual (vistas). En cada nivel se requiere informacion distinta
para construir los esquemas. Por lo tanto, existe independencia de datos entre niveles, es
decir, existe capacidad de modificar el esquema de un nivel sin alterar el nivel superior.
Se reconocen dos tipos de independencia:
• Independencia de datos fısica: es posible alterar la implementacion sin alterar el
nivel conceptual.
• Independencia de datos logica: es posible hacer varios cambios en el esquema con-
ceptual sin alterar los subesquemas.
1.2 Vista general de un DBMS
1.2.1 Lenguajes de bases de datos
En general un DBMS proporciona lenguajes y herramientas para diferentes tipos de usua-
rios. Los lenguajes de bases de datos que se pueden reconocer se pueden clasificar en dos
grupos principales:
• Lenguaje de Definicion de Datos (DDL por Data Definition Language).
• Lenguaje de Manipulacion de Datos (DML por Data Management Language).
El primero grupo se refiere a los lenguajes que sirven para definir los esquemas de la
base de datos en cada nivel: por definicion, cada nivel requiere un lenguaje distinto. El
resultado de la compilacion de las instrucciones DDL son las tablas con la descripcion de
la base de datos. El esquema fısico lo define principalmente el DBMS.
El segundo grupo son los lenguajes que permiten acceder a la informacion almacenada
en la base de datos. Las operaciones tıpicas de estos lenguajes son las siguientes:
• Recuperar informacion (consultas a la base de datos).
• Agregar informacion.
1.2. Vista general de un DBMS 7
• Modificar la informacion almacenada (actualizaciones).
• Borrar informacion.
1.2.2 Usuarios de una base de datos
Respecto a los usuarios, el mas importante desde el punto de vista tecnico es el admi-
nistrador de la base de datos. Este usuario tiene entre sus funciones las siguientes:
• Realiza la definicion y modificacion de los esquemas utilizando un DDL.
• Define las estructuras de almacenamiento y los metodos de acceso a los datos.
• Asigna los tipos de autorizaciones de acceso a la informacion.
En el mismo nivel tecnico, se encuentran los programadores de aplicaciones. Estos
ultimos interactuan con el DBMS a traves del DML, incluyendo instrucciones del DML en
programas escritos en un lenguaje host como Pascal, C o algun lenguaje 4GL especialmente
disenado para este tipo de aplicaciones.
Desde el punto de vista funcional, existen tambien los usuarios casuales, quienes saben
de computacion e ingresan consultas directamente en el DML.
Finalmente desde el punto de vista de su utilidad, son los usuarios finales los que
interactuan directamente con los programas de aplicacion. Estos usuarios no necesitan
saber de computacion debido a que los desarrolladores les propocionan la interfaz adecuada
para su interaccion.
1.2.3 Estructura fısica de un DBMS
Desde el punto de vista fısico, el DBMS proporciona las siguientes herramientas:
Administrador de Archivos Se encarga de las operaciones de almacenamiento en el
disco. Usualmente utiliza llamadas a funciones del sistema operativo.
Administrador de la Base de Datos Es la interfaz entre al administrador de archivos
(bajo nivel) y las consultas en DML.
Preprocesador de Consultas Traduce las consultas a instrucciones que el admi-
nistrador de la base de datos entiende. Generalmente realiza optimizaciones a las
consultas formuladas por el usuario.
8 Capıtulo 1. Introduccion
Precompilador de DML Convierte instrucciones de DML a invocaciones a funciones
DBMS.
Compilador DDL Recibe como entrada la definicion de la base de datos (en DDL) y
genera como salida tablas con la informacion de los esquemas (el diccionario de
datos).
Juntando todo, una vision general del DBMS se muestra en la Figura 1.2. En relacion
a esta figura, el lector puede dimensionar cual es el tamano del problema al cual esta
enfocado el curso. Una vision mas informal podrıa considerar un recetario de cocina
como una base de datos de recetas de cocina; o una planilla electronica con la informacion
de un inventario como una base de datos de ıtemes ; o una agenda telefonica como una
base de datos de contactos. Sin embargo, no es el concurso de informacion recopilada
o el hecho de que se use un medio computacional para almacenar informacion lo que
transforma el problema en una necesidad de estudiar bases de datos. Como se menciono
al principio del capıtulo, el objetivo del curso es conocer los fundamentos que se aplican
en el almacenamiento, manipulacion y recuperacion de informacion en forma eficiente
para cualquier organizacion, donde estos requerimientos son vitales para su desarrollo
estrategico.
1.2. Vista general de un DBMS 9
Figura 1.2: Vision general de un DBMS: usuarios, lenguajes, modulos, interrelaciones, etc.
10 Capıtulo 1. Introduccion
Capıtulo 2
Modelo Entidad-Relacion
El modelo Entidad-Relacion (E-R) fue presentado por Chen en 1976. Es uno de los modelos
de datos mas populares y se basa en una representacion del mundo real en que los datos se
describen como entidades, relaciones y atributos. Este modelo se desarrollo para facilitar
el diseno de las bases de datos.
El principal concepto del modelo E-R es la entidad, que es una “cosa” en el mundo
real con existencia independiente. Una entidad puede ser un objeto fısico (una persona,
un auto, una casa o un empleado) o un objeto conceptual (una companıa, un puesto de
trabajo o un curso universitario). En el ejemplo del Capıtulo I, sobre las inscripciones y
notas de los alumnos de una carrera, se pueden identificar dos entidades: ALUMNO y CURSO.
Cada entidad tiene propiedades especıficas que la describen llamadas atributos. Por
ejemplo, una sala de clases tiene un nombre (Sala TI I, Sala 31, Sala de Proyectos), una
ubicacion, un cupo maximo, etc. En el ejemplo sobre las inscripciones y notas, ALUMNO
posee los atributos Nombre y Matrıcula. Una entidad particular tiene un valor para cada
uno de sus atributos.
Cada uno de los atributos de una entidad posee un dominio, el que corresponde al
tipo del atributo. Por ejemplo, Matrıcula tiene como dominio al conjunto de los enteros
positivos y Nombre tiene como dominio al conjunto de caracteres.
Para todo conjunto de valores de una entidad, debe existir un atributo o combinacion
de atributos, que identifique a cada entidad en forma unica. Este atributo o combinacion
de atributos se denomina llave o clave primaria. Por ejemplo, el numero de matrıcula
es una buena llave para la entidad alumno, no ası el nombre, porque pueden existir dos
11
12 Capıtulo 2. Modelo Entidad-Relacion
personas con el mismo nombre.
Una relacion se puede definir como una asociacion entre entidades. Por ejemplo, en una
biblioteca la entidad LIBRO puede estar relacionada con la entidad PERSONA por medio de
la relacion ESTA PEDIDO. La entidad ALUMNO puede estar relacionada con la entidad CURSO
por la relacion INSCRIBE. Una relacion tambien puede tener atributos. Por ejemplo, la
relacion INSCRIBE puede tener los atributos Semestre y Nota.
Considere el siguiente ejemplo sobre el supuesto que se estan modelando los datos de
una empresa ficticia. La base de datos EMPRESA debe mantener informacion sobre los
empleados de la empresa, los departamentos y los proyectos. La descripcion del mini-
mundo (la parte de la empresa a ser representada en la base de datos) es la siguiente:
1. La empresa esta organizada en departamentos. Cada departamento tiene un nom-
bre unico. un numero unico, y un empleado particular quien lo administra. Se
quiere saber la fecha en que el empleado administrador empezo a hacerse cargo del
departamento. Un departamento puede tener varios locales.
2. Cada departamento controla un cierto numero de proyectos. Cada proyecto tiene un
nombre y numero unicos, y un local.
3. Para cada empleado se desea tener su nombre, rut, direccion, salario, sexo y ano
de nacimiento. Un empleado es asignado a un departamento, pero puede trabajar
en varios proyectos, los que no son necesariamente controlados por el mismo depar-
tamento. Se quiere saber el numero de horas semanales que un empleado trabaja
en cada proyecto. Se quiere ademas saber cual es el supervisor directo de cada
empleado.
4. Se desea conocer las personas dependientes (cargas familiares) de cada empleado
para propositos de seguros. De cada dependiente se desea conocer el nombre, sexo,
fecha de nacimiento y relacion con el empleado.
La Figura 2.1 muestra el modelo de esta base de datos, a traves de una notacion grafica
llamada diagrama E-R. En este diagrama los rectangulos representan conjuntos de enti-
dades, los elipses representan atributos y los rombos representan conjuntos de relaciones.
Usando la notacion grafica descrita, se puede hacer el diagrama E-R del ejemplo de las
inscripciones y notas de los alumnos de una carrera: ver Figura 2.2. El lector debe notar
2.1. Tipos de atributos 13
Figura 2.1: Diagrama E-R de la base de datos EMPRESA.
que este ultimo diagrama no tiene el mismo nivel de informacion que la Figura 2.1. . . ¿Ve
la diferencia?
Figura 2.2: Diagrama E-R de la base de datos de inscripciones y notas.
2.1 Tipos de atributos
Una entidad define un conjunto de instancias particulares con los mismos atributos. Por
ejemplo: una entidad EMPLEADO con atributos Nombre, Edad y Sueldo, puede represen-
tar al siguiente conjunto de instancias particulares: (Juan Perez, 55, 800.000), (Federico
Pardo, 40, 550.000) y (Rodrigo Pozo, 25, 400.000). En los diagramas E-R, una entidad
se representa como una caja rectangular y los nombres de los atributos como elipses. Las
14 Capıtulo 2. Modelo Entidad-Relacion
instancias particulares no se representan en este modelo. Respecto a los atributos, estos
se pueden clasificar de la siguiente forma:
• Los atributos compuestos que se pueden dividir en subpartes mas pequenas. Las
subdivisiones representan atributos mas basicos con significados propios. Los atri-
butos compuestos se representan con varias elipses, una por cada subdivision. En la
Figura 2.1 por ejemplo: el atributo Nombre, en la entidad EMPLEADO, se sub-divide
en NombreP, Apellido1 y Apellido2.
• Los atributos atomicos o simples que no se pueden subdividir. Si no hay necesidad
de referirse a los elementos individuales de un nombre, entonces el nombre completo
puede considerarse un atributo simple. Generalmente, los atributos de valor simple
son los que tienen un solo valor para una entidad particular, e.g., Edad y Sueldo.
• Los atributos multivaluados pueden tener un conjunto de valores para una misma
entidad. Por ejemplo: un atributo Tıtulos Profesionales, donde una persona
puede que no tenga ninguno, tenga uno, dos o mas). Los atributos multivaluados
se representan con elipses dobles, como el atributo Localizaciones de la entidad
DEPARTAMENTO en la Figura 2.1.
• Los atributos clave o llave son un tipo de atributo cuyos valores son distintos para
cada entidad individual, i.e., sus valores se usan para identificar cada entidad de
forma unıvoca. Para una entidad PERSONA, un atributo clave tıpico es el Rut. Algunas
veces, varios atributos juntos forman una clave (la combinacion debe ser distinta).
Estos atributos clave aparecen subrayados en los diagramas. En principio, todos los
conjuntos de entidades tienen una llave.
Respecto a los atributos compuestos, aunque no es comun, podrıa darse una jerarquıa
de descomposicion como la mostrada en la Figura 2.3. Donde, una Direccion puede sub-
dividirse en: Dir Calle, Comuna, Ciudad y Region. A su vez, Dir Calle puede dividirse
en Calle, Numero y Depto.
Finalmente, cada atributo tiene un conjunto de valores o dominio asociado, que especi-
fica el conjunto de valores que puede asignarse a cada instancia particular. Por ejemplo,
si las edades de los empleados pueden variar entre 16 y 70, entonces el dominio de Edad es
{x ∈ N, 16 ≤ x ≤ 70}. Los dominios, al igual que los valores de las instancias particulares
de las entidades, no se muestran en los diagramas. Sin perjuicio de lo anterior, el disenador
2.2. Tipos de relaciones 15
Figura 2.3: Ejemplo de la jerarquıa de descomposicion para atributos compuestos.
debe pensar de forma implıcita en ellos cuando esta realizando un modelo. . . ¿Se imagina
por que?
2.2 Tipos de relaciones
Como se ha mencionado, en los diagramas E-R, una entidad se representa como una caja
rectangular y las relaciones como rombos. Una relacion R entre n tipos de entidades
E1, . . . , En define un conjunto de asociaciones entre estos tipos. Puede ser visto como un
conjunto de instancias de la relacion ri, donde cada ri asocia n entidades {e1, . . . , en}, y
cada entidad ej en ri es un miembro del tipo de entidad Ej , 1 ≤ j ≤ n. En la practica,
la mayorıa de las relaciones son binarias como se muestran en los ejemplos.
Una relacion es un subconjunto del producto cartesiano E1 × E2 × . . . × En. Por
ejemplo: algunas instancias de la relacion TRABAJA PARA del ejemplo EMPRESA podrıan ser
como las mostradas en la Figura 2.4
Una relacion podrıa tambien interpretarse como un conjunto de pares ordenados, en
este caso (e1, d1), (e2, d2), (e3, d1), (e4, d2), (e5, d3), (e6, d1), (e7, d3). Segun el numero de
instancias en las entidades relacionadas (o grado o razon de cardinalidad), se pueden definir
tres tipos de relaciones:
Relaciones Uno a Uno (1:1) Una instancia de la entidad A esta asociada a lo mas
con una instancia de la entidad B, y una instancia de la entidad B a lo mas con
una instancia de la entidad A. Ejemplo: ADMINISTRA es una relacion 1:1 entre las
entidades EMPLEADO y DEPARTAMENTO de la Figura 2.1.
Relaciones Uno a Muchos (1:n) Una instancia de la entidad A esta asociada con una
16 Capıtulo 2. Modelo Entidad-Relacion
Figura 2.4: Ejemplo de instancias de la relacion TRABAJA PARA de la base de datos EMPRESA.
o varias instancias de la entidad B. Una instancia de la entidad B, sin embargo,
puede estar a lo mas asociada con una instancia de la entidad A. Ejemplo: CONTROLA
es una relacion 1:n entre DEPARTAMENTO y PROYECTO de la Figura 2.1.
Relaciones Muchos a Muchos (n:m) Una instancia de la entidad A esta asociada con
una o varias instancias de la entidad B, y una instancia de la entidad B esta asociada
con una o varias instancias de la entidad A. Ejemplo: TRABAJA PARA es una relacion
n:m entre las entidades EMPLEADO y PROYECTO de la Figura 2.1.
La Figura 2.5 es un ejemplo de la relacion ADMINISTRA con un grado de cardinalidad
1:1 entre las entidades EMPLEADO y DEPARTAMENTO. Ademas, se puede definir el grado de
participacion u opcionalidad de las entidades participantes: EMPLEADO tiene un grado de
participacion parcial en la relacion ADMINISTRA, mientras que DEPARTAMENTO tiene un
grado de participacion total.
La Figura 2.6 es un ejemplo de la relacion TRABAJA EN con un grado de cardinalidad
n:m entre las entidades EMPLEADO y PROYECTO. Tanto EMPLEADO como PROYECTO tienen
grado de participacion total.
Visto que las instancias particulares no se visualizan en un diagrama E-R, la forma
de indicar el grado de cardinalidad es etiquetando las lıneas que unen a las entidades
respectivas de una relacion. Por otra parte, la participacion parcial en el diagrama E-R
se representa como una lınea simple, la participacion total como una lınea doble, como se
2.3. Conceptos adicionales 17
Figura 2.5: Relacion ADMINISTRA con un grado de cardinalidad 1:1. EMPLEADO tiene grado departicipacion parcial, mientras que DEPARTAMENTO tiene grado de participacion total.
Figura 2.6: Relacion TRABAJA EN con un grado de cardinalidad n:m. Tanto EMPLEADO comoPROYECTO tienen grado de participacion total.
muestra en la Figura 2.1.
2.3 Conceptos adicionales
Los diagramas E-R representan tambien otros conceptos adicionales en el diseno de una
base de datos. Estos conceptos son los siguientes:
Generalizacion y especializacion En el conjunto de entidades general se agrupan los
18 Capıtulo 2. Modelo Entidad-Relacion
atributos comunes a varios conjuntos de entidades que describen aspectos particu-
lares del conjunto de entidades general. La Figura 2.7 muestra una entidad general
EMPLEADO con dos subentidades particulares VENDEDOR y OPERADOR. Este concepto se
asemeja al de herencia en la Programacion Orientada a Objeto. Su representacion
es mediante un triangulo que relaciona la entidad general con las particulares.
Dependencia de existencia La existencia de una entidad depende de la existencia de
otra. En el ejemplo de EMPRESA, para que exista un DEPENDIENTE debe existir un
EMPLEADO. Si se borra un empleado necesariamente deben borrarse sus dependientes.
Este concepto se representa utilizando lıneas dobles para los rectangulos y los rombos
de las entidades dependientes, como se muestra en la Figura 2.1.
Conjuntos de entidades fuertes y debiles Hay conjuntos de entidades que no tienen
una llave propia, como en el caso de DEPENDIENTE que toma su llave de EMPLEADO
para la base de datos EMPRESA: en este caso el concepto esta relacionado con la
dependencia de existencia. Para el caso de la Figura 2.7, las entidades generales
VENDEDOR y OPERADOR toman su llave de EMPLEADO, relacionando el concepto con el
de generalizacion y especializacion.
Llaves candidatas Aunque no es un caso muy comun, pueden existir varios atributos
en una entidad que sirvan de llave por sı mismos. Por ejemplo: para un estudiante
su numero de rut y su numero de matrıcula son unicos. En la Figura 2.1, para las
entidades DEPARTAMENTO y PROYECTO se subrayan todos los atributos para resaltar
esta condicion. En la opinion particular del autor de esta recopilacion, esta situacion
podrıa confundir al estudiante novato e inducirlo a pensar que se trata de una llave
compuesta por todos los atributos, lo cual no se graficarıa de la misma forma. . . ¿Se
imagina como serıa esta forma?
Entidades autoreferenciables Este caso tampoco es muy comun y se trata de una
entidad que esta relacionada consigo misma. Por ejemplo la entidad EMPLEADO en
la Figura 2.1. En este caso se recomienda etiquetar cada una de las lıneas para su
identificacion: en este caso la relacion SUPERVISION tiene un grado de cardinalidad
1:n, donde el lado de 1 corresponde con la etiqueta supervisor y el lado del n
corresponde con la etiqueta supervisado.
2.4. Metodologıa para desarrollar diagramas 19
Figura 2.7: Ejemplo de generalizacion de entidades.
2.4 Metodologıa para desarrollar diagramas
Dado un problema en particular, el autor de esta recopilacion recomienda utilizar la si-
guiente metodologıa para desarrollar diagramas de E-R:
1. Identificar las entidades.
2. Crear las relaciones entre entidades.
3. Identificar los atributos de las entidades.
4. Identificar los atributos de las relaciones.
5. Identificar la clave primaria de cada entidad.
6. Decidir el grado de cardinalidad de las relaciones.
7. Decidir el grado de participacion de las entidades.
8. Redactar los supuestos que sean necesarios para explicar la informacion faltante.
2.5 Unas notas sobre la tipografıa
En esta recopilacion se ha mantenido la tipografıa de uno de los textos originales, visto que
no toda las bibliografıas respecto al tema coinciden en este punto. Para ayudar al lector
20 Capıtulo 2. Modelo Entidad-Relacion
en el diseno de los ejercicios propuestos en la Seccion 2.6, se recomiendan las siguientes
convenciones:
• Los nombres de las entidades y las relaciones se escriben en mayusculas.
• Los nombres de los atributos se escriben en minusculas.
• Cuando el nombre esta compuesto de varias palabras, estas se unen con “guiones
bajos”.
• Los nombres deben ser descriptivos y no se permiten abreviaciones.
• Utilizar singular para las entidades.
• Utilizar verbos para las relaciones. Los nombres de las relaciones pueden repetirse.
• Los nombres de los atributos pueden repetirse en diferentes entidades.
Los nombres tienen la misma utilidad que los identificadores en un lenguaje de progra-
macion, de hecho el lector podrıa aplicar las convenciones conocidas para alguno de ellos,
e.g. las convenciones de Java. En la fase de implementacion se espera que el lector decida
cuales son las reglas mas convenientes para su asignacion.
2.6 Ejercicios propuestos
1. Companıa de capacitacion: “Soy el administrador de una companıa de capa-
citacion que provee cursos en tecnicas de administracion. Ensenamos muchos cur-
sos, cada uno de los cuales tiene un codigo, un nombre y un precio. Introduccion a
Internet y Programacion Java son dos de nuestros cursos mas populares. Los cur-
sos se dictan entre uno a cuatro dıas. Un instructor puede ensenar varios cursos.
Nosotros registramos el nombre y numero de telefono de los profesores. Cada curso
es ensenado por un solo instructor. Creamos un curso y luego le asignamos un profe-
sor. Los estudiantes pueden tomar varios cursos a la vez, y muchos de ellos lo hacen.
Tambien registramos el nombre y telefono de cada estudiante. Algunos de nuestros
estudiantes e instructores no nos dan sus numeros telefonicos”.
2. Vendedores con experiencia: “Tenemos estos vendedores en terreno, tratando
de vender nuestros productos a la gente de su region. El problema es que algunas
de nuestras cuentas nuevas son firmas realmente muy especializadas, y algunos de
2.6. Ejercicios propuestos 21
los vendedores que tenemos no estan capacitados para atenderlos adecuadamente.
Ası que necesitamos alguna manera de clasificar a estos clientes, y mantener un
registro de cuales empleados tienen capacitacion en esas areas, para poder mandar a
alguien donde el cliente que tenga un mayor grado de conocimiento en ese negocio,
ası evitaremos que el trasmita una mala imagen a nosotros como empresa”.
3. Companıa de videos: “Soy el propietario de una pequena tienda de videos. Te-
nemos alrededor de 3.000 cintas de las cuales necesitamos mantener su estado. Cada
una de nuestras cintas tiene un numero de identificacion. Para cada pelıcula, nece-
sitamos conocer su tıtulo y categorıa (comedia, suspenso, drama, accion, guerra,
etc.). Tenemos multiples copias de muchas de nuestras pelıculas. A cada pelıcula
le asignamos un identificador y le asociamos las copias que la contienen y su for-
mato. Una pelıcula puede ser formato CD o DVD. Siempre tenemos al menos una
copia para cada pelıcula que nosotros rastreamos, y cada copia contiene una unica
pelıcula. Nuestras copias son de larga duracion y no tenemos pelıculas que requieran
multiples copias. Frecuentemente nos preguntan por pelıculas con actores populares
especıficos. Ası que deseamos registrar las pelıculas donde estan los actores de moda.
No todas nuestras pelıculas tienen actores famosos o de moda. Los clientes desean
conocer de cada actor su nombre real y fecha de cumpleanos. Solo registramos los
actores que aparecen en pelıculas de nuestro inventario. Tenemos cientos de clientes.
Solo arrendamos videos a gente asociada a nuestro video-club. Para cada socio,
registramos su nombre, apellido, telefono y direccion. Y, por supuesto cada socio
tiene su numero de socio. Luego, necesitamos conocer que copia ha retirado cada
cliente. Un cliente puede retirar varias copias al mismo tiempo. Solo registramos los
arriendos actuales, no los historicos”.
4. Los Arcoch: La tribu de los Arcoch, habitantes del Planeta Nak y unicos sobre-
vivientes de la guerra del ano 2084, que destruyo los cuatro planetas de su sistema
solar, se han propuesto construir una nueva forma de organizacion social para prote-
ger su raza, actualmente en extincion. Cada miembro de la tribu desarrolla alguna
actividad, la cual debe aprender y luego perfeccionar. Por ejemplo: cazar, cultivar
la tierra, educar, etc. Cada nino es educado e inicia alguna actividad en la adole-
cencia, cada anciano puede dejar de trabajar si lo desea. De acuerdo a la actividad
que desarrolle cada Arcoch, se le entregan los elementos necesarios. Si se cambia de
actividad estos deben ser devueltos. Se conoce que elementos deben ser entregados
por actividad. Tal como se otorgan bienes por actividad, se otorgan bienes a las
22 Capıtulo 2. Modelo Entidad-Relacion
familias de acuerdo a la edad de la familia (tiempo que lleva constituida la familia) y
al numero de integrantes que tenga. Por ejemplo, cuando dos Arcoch deciden formar
una familia, la Tribu les da una choza y otros utensilios.
5. Farmacias: Suponga una cadena de farmacias que posee varias bodegas en distintos
puntos de la ciudad. Cada sucursal posee un stock de cada tipo de medicamento,
los que son adquiridos a distintos laboratorios (cada medicamento es proporcionado
por un solo laboratorio). Las sucursales solicitan medicamentos a cualquiera de las
bodegas. Los medicamentos entregados por los laboratorios son almacenados en las
bodegas. Los documentos utilizados son notas de pedido y guıas de entrega. Ademas,
el detalle del tipo y cantidad de medicamentos vendidos van quedando registrados
en las boletas y facturas. Construya un diagrama E-R que permita llevar el control
del flujo de entrada (Laboratorios) y salida de medicamentos (ventas).
6. Servicio de radiotaxis: “El usuario es el gerente de un servicio de taxis de gran
escala. Hay setecientos taxis que manejan alrededor de mil cuatrocientos choferes en
dos turnos. La ciudad donde operan esta dividida en novecientas areas cuadradas,
cada una consistente de un numero de calles. Todas las calles son rectas y van de
este a oeste, o de norte a sur. Una calle puede estar en mas de un area. Los nombres
de las calles son unicos. A cada chofer se le asigna un taxi y un area especıfica
cuando llega a trabajar. El chofer se reporta a la Central de Control de Taxis por
radio cuando toma un pasajero (“taxi 47, en uso”) y cuando deja un pasajero (“taxi
47, disponible”). El chofer tambien informa cambios de area de esta manera (“taxi
47, area 13”). El sistema es responsable de las siguientes operaciones:
• Ubicar el area, dados los nombre de dos calles que se interceptan.
• Ubicar un taxi disponible en un area en particular.
• Determinar cuantos taxis estan en cada area, el promedio de taxis por area, el
area con mayor numero de taxis y el area con el menor numero de taxis.
• Mantener un registro del numero total de taxis “en uso” y “disponibles”.
• Ubicar un chofer dado su nombre.
• Calcular el porcentaje actual de taxis “disponibles”.
7. Cadena de negocios: “Mire, hace cinco anos que mama y yo empezamos esta
pequena tienda de alimentos naturales, y ahora vea ¡tenemos cinco! ¡Y en tres
estados diferentes! Bueno, como se puede imaginar, se nos esta haciendo un gran
2.6. Ejercicios propuestos 23
problema el controlar las cosas. Siempre ocurre que en una de las tiendas se acaba
algun ıtem, mientras que en la otra rebalsamos del mismo ıtem ¡Y los empleados!
Antes eramos mama y yo. Ahora tenemos otros seis, y ni siquiera podemos recordar
quien trabaja donde. Una cosa que definitivamente necesitamos saber es la cantidad
disponible de cada ıtem en cada tienda. La cantidad que se ha perdido tambien
serıa util. Tambien tenemos que imprimir una lista de precios con todos los ıtems
que cada tienda vende, para saber por cuanto venderlos —nos gusta mantener los
precios iguales en todas las tiendas—. Tenemos que mantener un registro de los
nombres y numeros de telefono de los empleados, tambien, y necesitamos saber
en que estado viven para poder calcular sus impuestos correctamente (ejemplo de
USA, con impuestos diferentes por estado). Y tenemos que mantener un registro
del numero total de los diferentes ıtems, el numero de tiendas en cada estado, el
numero de empleados en cada tienda, y el numero total de empleados, para ası
poder imprimir todo esto en el informe anual”.
8. Del diagrama E-R que se muestra en la Figura 2.8, sobre un esquema “simplificado”
para el sistema de reservaciones de una lınea aerea. Extraiga, desde el diagrama
E-R, los requerimientos y restricciones que produjeron dicho esquema, i.e., aplicar
ingenierıa inversa.
24 Capıtulo 2. Modelo Entidad-Relacion
Figura 2.8: Diagrama E-R para un sistema de reservaciones de una lınea aerea.
Capıtulo 3
Modelo Relacional
Este modelo considera la base de datos como una coleccion de relaciones. De manera
simple, una relacion representa una tabla en que cada fila representa una coleccion de
valores que describen una entidad del mundo real. Cada fila se denomina tupla.
El modelo en sı fue propuesto por primera vez en 1970 por Edgar Frank Codd (Ted
Codd), quien trabajo en su desarrollo durante las decadas de los sesenta y los setenta.
Su trabajo se presento con el nombre A Relational Model of Data for Large Shared Data
Banks.
Como se vera en este capıtulo, existe una gran coherencia entre el modelo E-R y el
modelo relacional.
3.1 Dominios, tuplas, atributos, relaciones
Definicion Un dominio D es un conjunto de valores atomicos. Atomico quiere decir que
cada valor en el dominio es indivisible. Es util dar nombres a los dominios, e.g.:
• Numeros telefonicos locales: el conjunto de numeros de telefonos de 9 dıgitos.
• Ruts: numeros de 8 dıgitos mas un caracter que puede ser del 0 al 9 o K.
• Nombres: el conjunto de nombres de personas.
• Notas: valores entre 1.0 y 7.0.
Tambien se puede especificar un tipo de datos o formato para cada dominio, e.g.
enteros, reales, cadenas de 4 dıgitos, etc.
25
26 Capıtulo 3. Modelo Relacional
Un scheme de relacion R denotado por R(A1, A2, . . . , An) esta constituido por un
nombre de relacion R y una lista de atributos A1, A2, . . . , An. Cada atributo Ai es el
nombre de un rol jugado por el dominio D en el scheme de la relacion R. D se llama
el dominio de Ai y se denota dom(Ai). Un scheme relacional se usa para describir una
relacion. R es el nombre de esta relacion. El grado de una relacion es el numero n de
atributos del scheme de la relacion. Por ejemplo:
• ESTUDIANTE(nombre, rut, fono, direccion, edad, carrera, promedio nota) tiene
grado 7.
• dom(nombre) = Nombres.
• dom(fono) = Numeros telefonicos locales.
Definicion Una relacion o instancia de relacion r del scheme de relacion
R(A1, A2, . . . , An), denotado tambien como r(R) es un conjunto de n-tuplas r =
t1, t2, . . . , tm. Cada n-tupla t es una lista ordenada de n valores t =< v1, . . . , vn >,
donde cada valor vi, 1 ≤ i ≤ n, es un elemento de dom(Ai) o es un valor nulo. Vea
por ejemplo la instancia de la relacion ESTUDIANTE en la Tabla 3.1.
nombre rut fono direccion edad carrera promedioBenjamınGonzalez
13.245.622-1 6122244211 Rosas3241
19 PlanComun
4.8
SergioSoto
12.341.228-5 nulo ClaudioGay 2142
20 Ing. Ind. 5.1
. . . . . . . . . . . . . . . . . . . . .
Tabla 3.1: Ejemplo de instancia para la relacion ESTUDIANTE.
Cada tupla representa una entidad de estudiante en particular. La definicion de relacion
puede replantearse ası: Una relacion r(R) es un subconjunto del producto cartesiano de
los dominios que definen r:
r(R) ⊆ (dom(A1)× dom(A2)× . . .× dom(An)
El numero total de tuplas en el producto cartesiano es:
|dom(A1)| ∗ |dom(A2)| ∗ . . . ∗ |dom(An)|
3.1. Dominios, tuplas, atributos, relaciones 27
Una instancia de relacion refleja solo las tuplas validas que representa un estado par-
ticular del mundo real. A medida que el mundo real cambia, tambien lo hace la relacion,
transformandose en otro estado de relacion (el scheme R es relativamente estatico y no
cambia excepto muy pocas veces).
3.1.1 Notacion
• Un scheme de relacion R de grado n se denota R(A1, A2, . . . , An).
• Una n-tupla t en una relacion r(R) se denota t =< v1, . . . , vn >, donde vi es el valor
correspondiente del atributo Ai.
• t[Ai] se refiere al valor vi en t para el atributo Ai.
• t[Ai, . . . , Am] donde Ai, . . . , Am es una lista de atributos de R, se refiere a las sub-
tuplas de valores < vi, . . . , vm > de t correspondientes a los atributos especificados
en la lista.
• Las letras Q,R, S denotan nombres de relacion.
• Las letras q, r, s denotan estados de relacion.
• Las letras t, u, v denotan tuplas.
• Los nombres de atributos se califican con el nombre de relacion a la cual pertenecen.
Por ejemplo, ESTUDIANTE.nombre, ESTUDIANTE.edad, etc.
• Para la tupla t = <Benjamın Gonzalez, 13.245.622-1, 6122244211, Rosas 3241, 19,
Plan Comun, 4.8>, tenemos t[nombre] = <Benjamın Gonzalez>, t[rut, promedio,
edad] = <13.245.622-1, 4.8, 19>.
3.1.2 Restricciones
Las restricciones de dominios especifican que el valor de cada atributo A debe ser un valor
atomico del dominio dom(A). Una relacion se define como un conjunto de tuplas. Por
definicion todos los elementos de un conjunto son distintos. Luego todas las tuplas de
una relacion deben ser distintas. Esto implica que dos tuplas no pueden tener la misma
combinacion de valores para todos sus atributos. Pero puede haber otros subconjuntos
de atributos de un scheme de relacion R con la propiedad de que no haya dos tuplas en
28 Capıtulo 3. Modelo Relacional
una instancia de relacion r de R que tengan la misma combinacion de valores para esos
atributos. Supongamos que denotamos tal subconjunto de atributos por S. Entonces para
cada dos tuplas distintas t1 y t2 en una instancia de relacion r de R, tenemos la restriccion:
t1[S] 6= t2[S]
Cualquier conjunto de atributos S es denominado super llave del scheme de relacion
R. Cada relacion tiene al menos una super llave (el conjunto de todos sus atributos).
Una llave o clave K de un scheme de relacion R es una super llave de R con la propiedad
adicional de que al sacar cualquier atributo A de K deja un conjunto de atributos K ′ que
no es super llave de R (una clave es una super llave minimal), i.e. toda clave es una super
llave de una relacion, pero no toda super llave es una clave.
El valor de un atributo clave se usa para identificar unıvocamente una tupla en una
relacion. El hecho que un conjunto de atributos constituya una clase es una propiedad del
scheme de la relacion, y es invariante en el tiempo.
En general, un scheme de relacion puede tener mas de una clave, y en ese caso, cada
una de las llaves es una llave candidata. Una de las llaves candidatas se designa como llave
primaria de la relacion. Usamos la convencion de que los atributos que forman la llave
primaria de un scheme de relacion se subrayan.
3.2 Bases de datos relacional
Un scheme de base de datos relacional es un conjunto de esquemas de relacion S =
(R1, R2, . . . , Rn) y un conjunto I de restricciones de integridad.
Una instancia de base de datos relacional s de S es un conjunto de instancias de relacion
d = r1, . . . rn tal que cada ri es una instancia de Ri y tal que las relaciones ri satisfacen
las restricciones de integridad especificadas en I. Por ejemplo:
• EMPLEADO (NPILA, APPAT, APMAT, RUT, FNAC, DIRECCION, SEXO,
SUELDO, RUTSUPERV, NDEPTO).
• DEPARTAMENTO (DNOMBRE, DNUMERO, RUTGERENTE,
GERFECHAINIC).
• UBICACIONES DEPTO( DNUMERO, DUBICACION).
3.2. Bases de datos relacional 29
• PROYECTO (PNOMBRE, PNUMERO, PUBICACION, DNUM).
• TRABAJA EN (ERUT, PNO, HORAS).
• CARGA (ERUT, NOMBRE CARGA, SEXO, FNAC, PARENTESCO).
Las Tablas 3.2, 3.3, 3.4, 3.5, 3.6 y 3.7, muestran los datos que corresponden a una
instancia de la base de datos.
Se puede observar que DNUMERO es el mismo para DEPARTAMENTO y UBICA-
CIONES DEPTO. Pero el mismo concepto se llama NDEPTO en EMPLEADO y DNUM
en PROYECTO. No hay problema.
La restriccion de integridad referencial se especifica entre dos relaciones y se usa para
mantener la consistencia entre tuplas de las dos relaciones. Informalmente, una tupla en
una relacion que hace referencia a otra relacion debe referirse a una tupla existente en esa
relacion. Por ejemplo, NDEPTO de EMPLEADO debe coincidir con el DNUMERO de
alguna tupla de la relacion DEPARTAMENTO. Para una definicion formal, se necesita el
concepto de llave foranea o llave externa.
30
Capıtu
lo3.Modelo
Rela
cional
NPILA APPAT APMAT RUT FNAC DIRECCION SEXO SUELDO RUTSUPERV NDEPTOJuan Perez Garcıa 12345678 9-1-55 Toesca 965 M 120 33344555 5Alicia Zelaya Roa 99988777 19-7-
58Blanco 2120 F 105 98765432 4
Juana Besa Martınez 98765432 20-6-31
Mapocho2540
F 240 88866555 4
Francisco Cea Daza 33344555 8-12-45
Condell 221 M 310 88866555 5
Jaime Ramos Salas 88866555 10-11-30
Vitacura1015
M 360 nulo 1
Tabla 3.2: Ejemplo de instancia para la tabla EMPLEADO.
DNOMBRE DNUMERO RUTGERENTE GERFECHAINICOf. Central 1 88866555 19-6-71Administracion 4 98765432 1-1-85Investigacion 5 33344555 22-5-78
Tabla 3.3: Ejemplo de instancia para la tabla DEPARTAMENTO.
DNUMERO DUBICACION1 Providencia
4 Nunoa5 La Florida5 Pirque
Tabla 3.4: Ejemplo de instancia para la tabla UBICACIONES DEPTO.
3.2.Bases
dedatosrela
cional
31
PNOMBRE PNUMERO PUBICACION DNUMProducto X 1 La Florida 5Producto Y 2 Pirque 5
Computarizacion 10 Nunoa 4Reorganizacion 20 Providencia 1
Tabla 3.5: Ejemplo de instancia para la tabla PROYECTO.
ERUT PNO HORAS12345678 1 32.512345678 2 7.533344555 2 10.099988777 10 10.098765432 10 10.098765432 20 15.088866555 20 nulo
Tabla 3.6: Ejemplo de instancia para la tabla TRABAJA EN.
ERUT NOMBRE CARGA SEXO FNAC PARENTESCO33344555 Alicia F 5-4-86 Hija33344555 Teodoro M 25-10-83 Hijo33344555 Ximena F 3-5-54 Conyuge98765432 Rodolfo M 28-2-32 Conyuge12345678 Alicia F 5-5-57 Conyuge
Tabla 3.7: Ejemplo de instancia para la tabla CARGA.
32 Capıtulo 3. Modelo Relacional
Definicion Un conjunto de atributos F en el scheme de relacion R1 es una llave foranea
de R1 si satisface las siguientes reglas:
1. Los atributos en F tienen el mismo dominio que los atributos de la llave primaria
P de otro scheme de relacion R2. Los atributos F se dice que referencian la
relacion R2.
2. Un valor de F en una tupla t1 de R1 ya sea es nulo o tiene un valor de P para
alguna tupla t2 de R2.
Por Ejemplo: NDEPTO en una tupla t1 de EMPLEADO debe coincidir con el valor
de una llave primaria DNUMERO en alguna tupla t2 de la relacion DEPARTA-
MENTO, o el valor de NDEPTO puede ser nulo si el empleado no pertenece a un
departamento.
Las restricciones anteriores no consideran las restricciones semanticas que quizas
puedan especificarse y sostenerse en una base de datos relacional. Por ejemplo, “el
sueldo de un empleado no puede exceder el de su supervisor”, “el numero maximo
de horas que puede trabajar un empleado en todos los proyectos es 56”.
3.3 Paso de modelo E-R a modelo relacional
Las Tablas 3.2, 3.3, 3.4, 3.5, 3.6 y 3.7, muestran los datos que corresponden a una instancia
del scheme de la base de datos EMPRESA. Como se ha mostrado en la seccion anterior, este
scheme cumple con las definiciones propuestas por el modelo relacional.
• EMPLEADO (NPILA, APPAT, APMAT, RUT, FNAC, DIRECCION, SEXO,
SUELDO, RUTSUPERV, NDEPTO).
• DEPARTAMENTO (DNOMBRE, DNUMERO, RUTGERENTE,
GERFECHAINIC).
• UBICACIONES DEPTO( DNUMERO, DUBICACION).
• PROYECTO (PNOMBRE, PNUMERO, PUBICACION, DNUM).
• TRABAJA EN (ERUT, PNO, HORAS).
• CARGA (ERUT, NOMBRE CARGA, SEXO, FNAC, PARENTESCO).
3.3. Paso de modelo E-R a modelo relacional 33
A partir de una descripcion como la dada al inicio del Capıtulo 2 de este documento,
la pregunta es: ¿como obtener este scheme? A saber, se podrıa obtener de forma analıtica
en funcion de la experiencia del disenador. Otra alternativa es utilizar una metodologıa
matematica como la que se explicara en otro capıtulo. Finalmente, una combinacion de
ambas alternativas sugiere obtener el scheme a partir del diagrama E-R de la Figura 3.1,
aplicando un metodo de transformacion.
Figura 3.1: Diagrama E-R de la base de datos EMPRESA.
Dado el modelo E-R de la Figura 3.1, para obtener el scheme relacional equivalente,
se deben aplicar los siguientes pasos:
1. Para cada atributo multivaluado, crear una relacion agregando la clave primaria de
la entidad a la cual pertenece.
2. Convertir todas las entidades del diagrama en relaciones.
3. Para cada relacion del diagrama:
• Si es de cardinalidad M:N, crear una relacion con las llaves primarias de las
entidades que estan asociadas, y los atributos propios de la relacion —si los
tuviera—.
• Si es de cardinalidad N:1, se debe agregar la llave primaria y los atributos
propios en la relacion que representa a la entidad marcada con N.
34 Capıtulo 3. Modelo Relacional
• Si es de cardinalidad 1:1, se debe agregar la llave primaria y los atributos propios
en la relacion que tenga un grado de opcionalidad completa. Si ninguna tiene
grado de opcionalidad completa, es indistinto donde se agregue la llave de una
o de otra —pero no en ambas—.
4. Para cada nueva relacion, indicar cual es su llave primaria mediante la notacion
PRIMARY KEY (lista de atributos).
5. Para cada relacion, creada o modificada, agregar cuales son llaves externas mediante
la notacion FOREIGN KEY (lista de atributos) REFERENCES nombre tabla.
6. Para cada atributo, indicar cual es su dominio.
El lector podra comprobar que aplicando esta secuencia de pasos se obtiene el scheme
equivalente presentado mas arriba. Mas aun, si se han seguido todos los pasos senalados se
deberıa obtener un scheme con la estructura preliminar al que se utilizara en la practica.
Por ejemplo: el siguiente codigo corresponde a una definicion basica para crear la base de
datos EMPLEADO en el administrador de bases de datos mysql:
CREATE TABLE ‘EMPLEADO‘ (
‘NPILA‘ varchar(15) DEFAULT NULL,
‘APPAT‘ varchar(15) DEFAULT NULL,
‘APMAT‘ varchar(15) DEFAULT NULL,
‘RUT‘ varchar(10) NOT NULL DEFAULT ’’,
‘FNAC‘ date DEFAULT NULL,
‘DIRECCION‘ varchar(30) DEFAULT NULL,
‘SEXO‘ char(1) DEFAULT NULL,
‘SUELDO‘ decimal(5,0) DEFAULT NULL,
‘RUTSUPERV‘ varchar(10) DEFAULT NULL,
‘NDPETO‘ int(11) DEFAULT NULL,
PRIMARY KEY (‘RUT‘)
);
CREATE TABLE ‘DEPARTAMENTO‘ (
‘DNOMBRE‘ varchar(15) DEFAULT NULL,
‘DNUMERO‘ int(11) NOT NULL DEFAULT ’0’,
‘RUTGERENTE‘ varchar(10) DEFAULT NULL,
3.3. Paso de modelo E-R a modelo relacional 35
‘GERFECHAINIC‘ date DEFAULT NULL,
PRIMARY KEY (‘DNUMERO‘)
);
CREATE TABLE ‘UBICACIONES_DEPTO‘ (
‘DNUMERO‘ int(11) NOT NULL DEFAULT ’0’,
‘DUBICACION‘ varchar(15) NOT NULL DEFAULT ’’,
PRIMARY KEY (‘DNUMERO‘,‘DUBICACION‘)
);
CREATE TABLE ‘PROYECTO‘ (
‘PNOMBRE‘ varchar(15) DEFAULT NULL,
‘PNUMERO‘ int(11) NOT NULL DEFAULT ’0’,
‘PUBICACION‘ varchar(15) DEFAULT NULL,
‘DNUM‘ int(11) DEFAULT NULL,
PRIMARY KEY (‘PNUMERO‘)
);
CREATE TABLE ‘TRABAJA_EN‘ (
‘ERUT‘ varchar(10) NOT NULL DEFAULT ’’,
‘PNO‘ int(11) NOT NULL DEFAULT ’0’,
‘HORAS‘ decimal(3,1) DEFAULT NULL,
PRIMARY KEY (‘ERUT‘,‘PNO‘)
);
CREATE TABLE ‘CARGA‘ (
‘ERUT‘ varchar(10) NOT NULL DEFAULT ’’,
‘NOMBRE_CARGA‘ varchar(15) NOT NULL DEFAULT ’’,
‘SEXO‘ char(1) DEFAULT NULL,
‘FNAC‘ date DEFAULT NULL,
‘PARENTESCO‘ varchar(8) DEFAULT NULL,
PRIMARY KEY (‘ERUT‘,‘NOMBRE_CARGA‘)
);
Notese que los nombres han cambiado en relacion al diagrama de la Figura 3.1.
36 Capıtulo 3. Modelo Relacional
Ademas, los nombres de los atributos no siguen las convenciones dadas en el capıtulo
anterior. No es necesario detenerse en esto, el ejemplo ha sido transcrito literalmente
desde la fuente y se explicara a su debido tiempo las ventajas o desventajas de realizar
esto.
3.4 Ejercicios propuestos
1. Notacion: dado el scheme de la base de datos EMPLEADO —que aparece en este
capıtulo— responda las preguntas y definiciones que se piden a continuacion:
(a) Para la relacion EMPLEADO, describa los dominios de los siguientes atributos:
NPILA, DIRECCION, SEXO y SUELDO.
(b) ¿Cual es el grado de cada una de las relaciones?
(c) ¿Cual es el numero de tuplas de cada una de las relaciones?
(d) Para la tabla EMPLEADO, ¿cual es el valor de las siguientes notaciones?:
i. r = {t|t = t2 ∨ t = t5}.
ii. t3 = {v8 = 360, v10 = 1}.
iii. dom(A10).
iv. dom(A7)× dom(A7).
v. |dom(A8)| ∗ |dom(A8)|.
vi. t2[A4, A1, A2, A3].
vii. t[A1, A2].
2. Utilizando el metodo de transformacion, propuesto en este capıtulo, obtenga el mode-
lo relacional de los problemas presentados en el Capıtulo 2:
• Companıa de capacitacion.
• Vendedores con experiencia.
• Companıa de videos.
• Los Arcoch.
3. Los organizadores del Mundial 2018 han encargado a su empresa hacer una primera
aproximacion de una base de datos usando el modelo relacional. Para ello a usted
se le ha entregado la siguiente informacion que debe representar en la base de datos:
3.4. Ejercicios propuestos 37
• El ano y paıs donde se han realizado los mundiales, la estacion (invierno, verano,
etc.), el nombre del presidente de la FIFA en ese instante y otros datos.
• Los paıses participantes y los jugadores de cada seleccion, indicando las carac-
terısticas personales de importancia (nombre, edad, en que equipo juega, etc.),
y posicion dentro del esquema del equipo. Es importante saber que un mismo
jugador puede estar en varios mundiales y jugar en posiciones diferentes (en un
mismo mundial juega en una misma posicion) pero siempre por el mismo paıs.
• Los partidos efectuados, indicando entre que paıses y el marcador. Si hubo
definicion a penales, estos se toman como goles del encuentro. Considere la
etapa en que se jugo el partido (octavos de final, cuartos de final, etc.).
4. Se desea crear una base de datos relacional para la distribucion de trabajos en un
Terminal Portuario. Para esto se debe tomar en cuenta lo siguiente:
Existen obreros que realizan un solo tipo de trabajo, como por ejemplo
descarga, limpieza, conduccion de vehıculos, etc. Existen Empresas Con-
tratistas que contratan a dichos obreros. A su vez las Companıas Navieras
contratan los servicios de una o mas empresas contratistas a la llegada de
un barco, de acuerdo al servicio que necesitan, por ejemplo, una companıa
necesita 10 estibadores, 2 conductores y personal de limpieza. Los obreros
solo son contratados por las empresas contratistas (solo una). Una empresa
puede estar entregando servicios a varios barcos de distintas companıas.
5. Se necesita crear una base de datos relacional para la Municipalidad de Punta Arenas,
que permita llevar la mantencion de las empresas contratistas que realizan trabajos
para ella, para lo anterior tome en cuenta lo siguiente:
• Las empresas contratistas realizan obras, como ser: pavimentacion de calles,
mantencion de edificios, mantencion de computadores, etc. Las empresas tienen
empleados que realizan un solo tipo de labor (ingeniero, operario, soldador,
capataz, etc.), los cuales estan asignados a una sola obra.
• Las empresas tienen maquinarias, las cuales pueden ser usadas en las distintas
obras. Tambien es importante saber que las empresas pueden subcontratar a
otras.
• De la base de datos se puede obtener informacion tal como: el listado de obreros
segun obra, el listado de obras que esta ejecutando una empresa, en cuantas
38 Capıtulo 3. Modelo Relacional
obras participa una maquina determinada, datos personales de los obreros o
instituciones, etc.
• Otros datos como: presupuesto asignado a las obras, representante de la em-
presa, datos de las maquinas como peso, marca, modelo, etc.
6. Una empresa de transporte de pasajeros le solicita a usted y sus asociados el diseno de
una base de datos relacional para mantener la informacion relevante de la empresa.
La informacion para almacenar es: choferes y buses que conducen, un chofer solo
maneja un bus, pero un bus puede ser manejado por mas de un conductor. Los
buses van a ciudades (o destinos), y partiendo de un destino se puede llegar a otro.
Existen pasajeros que van a distintos destinos y en el pasaje es importante saber
quien fue el vendedor de ese boleto y el costo del pasaje (no interesa en que bus).
De la base de datos se puede obtener informacion tal como: el listado de pasajeros
para un destino determinado en una fecha especıfica. Listado de vendedores y los
pasajes que ha vendido. Otros datos interesantes son: caracterısticas de los buses
(marca, peso, capacidad, etc.); y direccion de llegada de los destinos.
7. Un empresario dueno de un Pub le solicito a su empresa redisenar una base de
datos, la cual representa la informacion de su local comercial. Para esto tome en
cuenta lo siguiente: el Pub tiene personal que desarrolla una unica actividad como
barman, mesero, limpieza, etc. Los meseros atienden las mesas, las cuales tienen
codigo y alguna otra informacion (puede ser ubicacion); a las mesas se le asignan
distintos consumos (realizados por los clientes), los cuales se reflejan en la boleta
final (con la identificacion de la mesa, el empleado que la atendio y el detalle de
los consumos). Los consumos tienen codigos y nombres, como por ejemplo: Ruso
Negro, Clavo Oxidado, Manhattan, etc. Un consumo esta compuesto por varios
ingredientes; tambien es importante saber cuales son sus ingredientes (interesa la
proporcion o cantidad). Un consumo se puede repetir en varias mesas, y a su vez
una mesa puede tener varios consumos.
8. Se necesita crear una base de datos para una clınica con la siguiente informacion:
existen servicios (traumatologıa, pediatrıa, rayos, etc.), usuarios que tienen aten-
ciones en dichos servicios, ademas medicos y sus especialidades (pediatrıa, neu-
rologıa, etc.; solo una especialidad por medico). Cada usuario tiene un kardex,
donde van las observaciones puestas por los medicos y los servicios en que ha es-
tado, puede haber sido mas de un medico o servicio. Las observaciones son puestas
3.4. Ejercicios propuestos 39
por cada medico, indicando fecha y hora de la atencion. No se debe olvidar los
datos personales de medicos y usuarios. La base de datos debe permitir mantener
eficientemente el kardex y sus observaciones.
9. A usted le corresponde ser parte del equipo organizador del Encuentro de Egresados
del Departamento de Ingenierıa en Computacion. Se le ha solicitado el diseno de
una base de datos para mantener la informacion concerniente a los egresados (datos
personales y carrera a la que pertenecio), almacenando tambien el historial de los
empleos (o actividades) que ha realizado, ası como las empresas donde ha estado.
Tome en cuenta lo siguiente:
• Es importante saber cual es la carrera que estudio el egresado y en que empresa
esta trabajando actualmente.
• Puede haber trabajado en distintas empresas realizando distintas actividades.
Puede haber trabajado dos veces en la misma empresa (incluso en la misma
actividad, pero en distintas fechas).
• Los tipos de actividades son por ejemplo: Jefe Unidad de Informatica, miembro
de la Unidad de Servicios, Encargado de Redes, etc. La actividad se relaciona
con alguna empresa.
• Es importante mantener la informacion de las empresas, las cuales estan clasi-
ficadas por tipos de empresas (publica, privada, ONG, etc.). Ademas, las em-
presas tambien se categorizan por area, donde una empresa podrıa pertenecer
a mas de un area (Salud, Servicios, Comercial, etc.)
10. Un grupo de alumnos del Departamento presento una propuesta al Centro de Alum-
nos para crear una biblioteca. En la biblioteca puede haber diferentes tipos de
lectura, por ejemplo: libros, revistas, publicaciones (papers). Todos estos se iden-
tifican por un codigo y ademas tiene atributos como tıtulo, autor, editorial, fecha
de publicacion, etc. Los lectores (alumnos) tienen un codigo asignado (numero de
matrıcula) y otros datos como nombre, direccion, ano de ingreso, etc. Los lectores
pueden llevar libros en prestamo los que se devolveran en una fecha determinada; es
posible tambien reservar libros. De cada libro puede haber mas de una copia. Se
debe llevar una estadıstica de los libros pedidos.
11. Se desea crear una base de datos para la citacion de horas en un Policlınico. Tome en
cuenta lo siguiente: existen medicos que prestan un tipo de atencion, como por ejem-
40 Capıtulo 3. Modelo Relacional
plo pediatrıa, obstetricia, traumatologıa, etc. Existen Usuarios que piden presta-
ciones al Policlınico. Las horas se dan de acuerdo a un calendario fijado, donde se
indica las horas en que atendera cada medico. Cada cliente y medico tiene su ficha
personal con sus datos.
Capıtulo 4
MySQL Workbench: herramienta
de diseno
MySQL Workbench es una herramienta visual de diseno de bases de datos que integra
desarrollo de software, administracion de bases de datos, diseno de bases de datos, creacion
y mantenimiento para el sistema de base de datos MySQL. Es el sucesor de DBDesigner
4 de fabFORCE.net, y reemplaza el anterior conjunto de software, MySQL GUI Tools
Bundle. La primera version de MySQL Workbench fue liberada en septiembre de 2005, y
no fue incluıda en la MySQL GUI Tools Bundle. El desarrollo fue comenzado nuevamente
en 2007 y MySQL Workbench estuvo preparado para volverse el producto insignia de
MySQL GUI. El versionado comenzo con la 5.0, para remarcar el hecho que MySQL
Workbench fue desarrollado como el sucesor de DBDesigner 4.8 1.
En este capıtulo se utiliza el material obtenido desde:
http://coba.dc.fi.udc.es/˜bd/bd2/MySQLWB/tutorialWB.html.
El objetivo del capıtulo es familiarizar al lector con la herramienta, aun cuando la
interfaz se puede ver diferente en las versiones mas actuales. Ademas se intentara explicar
la relacion que existe entre los disenos obtenidos con la herramienta y los dos modelos
anteriores. En particular, los diagramas de la herramienta son conocidos como diagramas
EER2
1Fuente: Wikipedia.2El recopilador no esta seguro si la primera E es por enhanced (mejorado) o extended (extendido).
41
42 Capıtulo 4. MySQL Workbench: herramienta de diseno
4.1 Introduccion a MySQL Workbench
MySQL Workbench es una aplicacion para el diseno y documentacion de bases de datos
(sucesora de la aplicacion DBDesigner4) pensada para ser usada con el sistema de gestion
de bases de datos MySQL (adquirido por Sun Microsystems). Existen dos versiones del
producto, una es open source y la otra es una version comercial. La version comercial
proporciona algunas funciones adicionales que pueden resultar de interes en algun ambito,
pero la version open source es mas que suficiente para la realizacion de un aprendizaje
introductorio.
Existen versiones para Window, Linux y Mac. La pagina oficial de la aplicacion desde
donde se puede descargar el producto y obtener manuales, tutoriales, etc. es:
http://www.mysql.com/products/workbench/.
La herramienta se utiliza para realizar diagramas EER mediante las siguientes fun-
ciones: primero disenar el diagrama EER, implementandolo sobre la herramienta y a partir
de el obtener el diagrama del esquema relacional. Todo esto se realiza de manera grafica
en la herramienta. A partir del diagrama se puede obtener de manera automatica un
archivo con sentencias DDL para MySQL donde se tienen las definiciones para la creacion
de tablas, vistas e ındices, incluyendo las claves primarias, las claves foraneas y a quienes
referencian. Si se desea, con algunas modificaciones, estos archivos pueden adaptarse a los
requerimientos de los usuarios cuando sea necesario.
4.2 ¿Como crear un diagrama EER?
En general, el trabajo con MySQL Workbench comenzara a partir de una interfaz como
la mostrada en la Figura 4.1. Para comenzar a crear el diagrama del esquema relacional
se debe hacer doble click sobre el icono ‘Add Diagram’, lo cual conducira al usuario a la
interfaz de la Figura 4.2.
4.2.1 Creacion de tablas
Para crear una tabla se debe hacer click sobre el ıcono ‘Insertar Tabla’ y click sobre la
posicion del lienzo en la que queremos ver la tabla, donde aparecera una imagen como la
mostrada en la Figura 4.3. Con doble click sobre la tabla creada se desplegara un menu en
4.2. ¿Como crear un diagrama EER? 43
Figura 4.1: Interfaz de inicio para MySQL Workbench.
Figura 4.2: Interfaz de creacion para los diagramas EER.
la parte inferior de la interfaz, como se muestra en la Figura 4.4. Aquı podremos introducir
las propiedades de la tabla como el nombre de la tabla, las columnas, los ındices, las claves
externas, etc. En principio, no es necesario cambiar algunos de los valores que vienen por
defecto, o completar todas las propiedades.
44 Capıtulo 4. MySQL Workbench: herramienta de diseno
Figura 4.3: Tabla recien creada.
Figura 4.4: Menu Tabla de MySQL Workbench.
En la pestana ‘Columns’ del Menu Tabla se pueden agregar los atributos de la tabla,
considerando lo siguiente:
Column name para el nombre del atributo.
Datatype para el tipo de dato del atributo.
NN anade la restriccion NOT NULL para un atributo.
AI es para campos de tipo Auto Increment.
ColumnDetails.Flags se utiliza para anadir la restriccion de clave primaria o Primary
Key.
Para agregar una nueva columna solo es necesario hacer doble click en la fila que va a
continuacion de la ultima anadida (senalada con un punto rojo en la Figura 4.5).
Figura 4.5: Pestana ‘Columns’.
4.2. ¿Como crear un diagrama EER? 45
Al seleccionar la opcion PRIMARY KEY se esta definiendo la llave principal de la
tabla. Es posible marcar esta opcion para varios atributos, con lo cual se obtiene una llave
primaria compuesta.
4.2.2 Creacion de relaciones
Para declarar las vinculaciones de clave foraneas o externas se utilizan las opciones que
aparecen en la Figura 4.6. Se muestra el Menu Relaciones para crear los tipos de relacion
1:1, 1:N y N:M en un EER. El calificativo “identificadora” que aparece en las leyendas de
la figura indica si los atributos que forman parte de la clave externa (lado N de la relacion)
deben formar parte tambien de la clave primaria de dicha entidad, lo que ocurre si una
tabla proviene de un tipo de entidad debil o en el caso de atributos de tablas que provienen
de tipos de relacion N:M.
Figura 4.6: Menu Relaciones.
Existen al menos dos formas diferentes de crear relaciones entre tablas: a traves del
Menu Tabla o usando el Menu Relaciones. Para el caso 1:1 y 1:N se recomienda utilizar
el Menu Tabla, con el cual se siguen los siguientes pasos:
1. Doble click sobre la entidad del lado N de la relacion.
2. Crear los atributos que van a hacer la funcion de clave foranea ( si no estan definidos
ya).
3. Comprobar que existen los atributos en la tabla referenciada por la clave foranea.
Si no existen deben crearse antes de continuar.
4. En el menu de tabla, desplegar la pestana ‘Foreing Keys’. Se obtiene una vista como
la mostrada en la Figura 4.7 con las siguientes opciones:
Foreing Key Name es el nombre de la restriccion de clave foranea.
46 Capıtulo 4. MySQL Workbench: herramienta de diseno
Referenced Table es la tabla referenciada por la clave foranea.
Column es la columna o columnas que van a formar parte de la clave foranea.
Referenced Column es la columna o columnas que van a ser referenciadas por la
clave foranea.
Foreing Key Options es util para definir las acciones referenciales: On Update
son acciones referenciales para la actualizacion y On Delete son acciones refe-
renciales para el borrado.
Figura 4.7: Menu ‘Foreign Key’.
Para el caso de relaciones N:M se recomienda el uso del Menu Relaciones. Los pasos a
seguir son los siguientes:
1. Las tablas deben estar creadas.
2. Se elige en el menu de la izquierda el tipo de relacion que se desea.
3. Click en la tabla que representa el lado N de la relacion y luego sobre la del lado 1
(esto puede ser al reves dependiendo del sistema operativo).
4. Los retoques que se deseen hacer sobre la clave foranea se hacen siguiendo lo indicado
en el punto 4 indicado mas arriba.
Como nota final, el recopilador considera que una de las utilidades principales
de la aplicacion es su capacidad para exportar los diagramas hacia un script
de MySQL, o hacia imagenes en formato PNG o PDF. Mas adelante se volvera
sobre esta herramienta para estudiar otras de sus caracterısticas, considerando
los conceptos que son necesarios estudiar para su aplicacion.
4.3. Ejemplo de aplicacion 47
4.3 Ejemplo de aplicacion
En esta seccion se presenta un ejemplo para practicar con la herramienta. Se trata de
relacionar dos tablas que representan a empleados y departamentos. El resultado final se
vera como en la imagen de la Figura 4.8.
Figura 4.8: Ejemplo de aplicacion.
Se comenzara primero con la tabla DEPT y luego con la tabla EMP. Los pasos a seguir
se detallan a continuacion:
1. Click en el icono senalado con la flecha (insercion tabla) y luego click sobre el
lienzo. Para editar las propiedades de la tabla hacer doble click sobre la misma.
Ver Figura 4.9.
Figura 4.9: Crear tabla DEPT.
2. Anadir los atributos a la tabla: en la pestana ‘Table’ se cambia ‘table1’ por el nombre
‘DEPT’; en la pestana ‘Columns’ se anade una a una las columnas de la tabla (ver
Figura 4.10). Notese que esta indicado que la columna DEPTO es clave primaria
(al indicar que es clave primaria el checkbox de NN (Not Null) se marca de forma
automatica).
3. Realizar los pasos 1 y 2 para la tabla EMP. La definicion de columnas se debe parecer
a la mostrada en la Figura 4.11.
4. Definir la restriccion de clave foranea en la tabla EMP. Para esto se puede realizar lo
siguiente: anadir una columna mas a la tabla EMP con el nombre de DEPT; hacer
48 Capıtulo 4. MySQL Workbench: herramienta de diseno
Figura 4.10: Definir columnas de la tabla DEPT.
Figura 4.11: Definir columnas de la tabla EMP.
doble click sobre la tabla EMP y seleccionar la pestana ‘Foreing keys’, aquı se indica
el nombre de la restriccion (FK DEPTNO) y la tabla a la cual hace referencia dicha
clave (DEPT) —ver Figura 4.12—. Luego, se indica cual es la columna que forma la
clave marcando el checkbox correspondiente y seleccionando la columna respectiva
DEPTO desde la tabla DEPT a la cual se referencia —ver Figura 4.13—.
Figura 4.12: Agregar clave foranea a tabla EMP.
De forma alternativa, la restriccion de clave foranea se puede realizar utilizando el
Menu Relaciones. En este caso se debe seleccionar en el Menu lo que se indica con
4.4. Ejercicios propuestos 49
Figura 4.13: Crear referencia hacia tabla DEPT.
una flecha en la Figura 4.14 y hacer click, primero sobre la tabla EMP y luego sobre
la tabla DEPT. Luego se puede cambiar el nombre de la columna DEPT DEPTO
por DEPT y el resultado sera similar al que se obtuvo con el otro metodo.
Figura 4.14: Crear referencia utilizando Menu Relaciones.
4.4 Ejercicios propuestos
1. Utilizando la herramienta MySQL Workbench obtenga los diagramas EER para los
problemas presentados en el Capıtulo 2:
• Companıa de capacitacion.
• Vendedores con experiencia.
• Companıa de videos.
• Los Arcoch.
50 Capıtulo 4. MySQL Workbench: herramienta de diseno
2. Implementar con la herramienta MySQL Workbench el diagrama EER equivalente
para la base de datos mostrada en la Figura 4.15.
Figura 4.15: Diagrama E-R de la base de datos EMPRESA.
Capıtulo 5
Algebra Relacional
Junto con el modelo relacional del Capıtulo3, Codd tambien presento un conjunto de ope-
raciones que permiten describir la forma en que se puede obtener una respuesta para una
consulta especıfica sobre las relaciones definidas: este conjunto de operadores se denomina
Algebra Relacional.
Aunque en este capıtulo se utilizara un lenguaje matematico, el lector no debe perder
de vista la equivalencia entre los conceptos para los distintos tipos de modelos estudiados
en los capıtulos precedentes. Ası, aunque los operadores hayan sido definidos para un
modelo particular, su aplicacion es valida para los demas. La equivalencia entre conceptos
se puede ver en la Tabla 5.1.
Modelo E-R Modelo Relacional Modelo EERentidad relacion tablarelacion relacion tablaatributo atributo columnaatributo multivaluado relacion tabladominio dominio tipo de datoclave primaria clave primaria clave primariaclave candidata clave candidata ındiceclave externa clave externa clave externa
Tabla 5.1: Equivalencia entre conceptos.
51
52 Capıtulo 5. Algebra Relacional
5.1 Notas sobre el modelo relacional
Se debe recordar que el modelo de E-R diferencia entre dos elementos de importancia:
las entidades y relaciones. Estos elementos son denominados de forma indistinta como
relaciones en el caso del modelo relacional1. En la practica, las relaciones del modelo
relacional se representan como un conjunto de tablas, como se vio en los esquemas EER.
En el modelo relacional el concepto de relacion tiene un sentido mas general y
matematico. En matematicas, una relacion se define como un subconjunto del producto
cartesiano entre un conjunto de dominios. Cada tupla (fila) de una relacion es un con-
junto de atributos (columnas) cuyos valores son obtenidos desde los dominios respectivos
(tipos de datos), i.e. una tupla es un elemento del producto cartesiano entre los distintos
dominios.
Al conjunto de atributos de una relacion se le llama esquema de la relacion y se denota
como:
Rel(a1 : dom1, a2 : dom2 : . . . , an : domn)
Sobre las relaciones se definen un conjunto de operaciones que permiten hacer consultas
sobre la base de datos. Al conjunto de operaciones ası definido se le denomina Algebra
Relacional.
5.2 Algebra relacional
Incluye una serie de operaciones que actuan sobre relaciones completas y generan como
resultado otra relacion. Los operadores se pueden clasificar en dos grupos:
• Operadores fundamentales.
• Operadores derivados.
Por simplicidad, las relaciones seran representadas como tablas y por lo tanto el resul-
tado de los operadores sera mostrado como una tabla.
1De ahı el nombre del modelo.
5.2. Algebra relacional 53
5.2.1 Operadores fundamentales
Union Si R y S son relaciones, entonces R ∪ S denota al conjunto de tuplas que estan
en R o S. Los atributos de R y S deben ser identicos en nombre y dominio2. Ver
Tablas 5.2, 5.3 y 5.4.
A Ba1 b1a2 b2a3 b3
Tabla 5.2: Relacion generica R.
A Ba2 b2a3 b3a4 b4
Tabla 5.3: Relacion generica S.
A Ba1 b1a2 b2a3 b3a4 b4
Tabla 5.4: Resultado de R ∪ S.
Diferencia Si R y S son relaciones, entonces R - S denota al conjunto de tuplas que
estan en R y no estan en S. Los atributos de R y S deben ser identicos en nombre y
dominio3. Este operador no es conmutativo, i.e. el resultado de R - S no es el mismo
que S - R. Ver Tablas 5.5 y 5.6.
A Ba1 b1
Tabla 5.5: Resultado de R - S.
A Ba4 b4
Tabla 5.6: Resultado de S - R.
2Una condicion menos restrictiva podrıa indicar que sean identicos solo en relacion al dominio, comoocurre en la implementacion de MySQL.
3En este caso es imprescindible que sea ası.
54 Capıtulo 5. Algebra Relacional
Producto Cartesiano Si T y U son relaciones con atributos v1, v2, . . . , vn y
w1, w2, . . . , wm respectivamente, entonces R × S es el conjunto de tuplas
v1, v2, . . . , vn, w1, w2, . . . , wm tal que en cada tupla de R × S los primeros n atribu-
tos corresponden a R y los siguientes m atributos corresponden a S. En la relacion
resultante cada tupla de R aparece con todas las tuplas de S. Ver Tablas 5.7, 5.8
y 5.9.
C Dc1 d1c2 d2
Tabla 5.7: Relacion generica T.
E Fe1 f1e2 f2
Tabla 5.8: Relacion generica U.
C D E Fc1 d1 e1 f1c1 d1 e2 f2c2 d2 e1 f1c2 d2 e2 f2
Tabla 5.9: Resultado de T × U.
Proyeccion Si W es una relacion con atributos v1, v2, . . . , vn, entonces la proyeccion
denotada por πvi,vj ,vk(W ) es el conjunto de valores vi, vj , vk para cada tupla de W.
Ver Tablas 5.10, 5.11 y 5.12.
C D E Fc1 d1 e1 f1c1 d1 e2 f2c2 d2 e1 f1c2 d2 e2 f2
Tabla 5.10: Relacion generica W.
Cc1c2
Tabla 5.11: Resultado de πC(W ).
5.2. Algebra relacional 55
D Fd1 f1d1 f2d2 f1d2 f2
Tabla 5.12: Resultado de πD,F (W ).
Seleccion Si W es una relacion con atributos v1, v2, . . . , vn, entonces la seleccion denotada
por σθ(W ) es el conjunto de tuplas de W que satisfacen la condicion θ. La condicion
θ se construye con operadores logicos o relacionales. Ver Tablas 5.13 y 5.14.
C D E Fc1 d1 e1 f1c1 d1 e2 f2
Tabla 5.13: Resultado de σC=c1(W ).
C D E Fc1 d1 e2 f2
Tabla 5.14: Resultado de σC=c1andD=d1andF 6=f1(W ).
5.2.2 Operadores derivados
Interseccion Si R y S son relaciones, entonces R ∩ S denota al conjunto de tuplas que
estan en R y tambien estan en S. Esto es equivalente a realizar las siguientes opera-
ciones: R - (R - S). El lector puede comprobar que esta operacion si es conmutativa
a pesar de estar definida sobre una que no lo es. Como esta basada en la diferencia
de relaciones, se requiere que los atributos de R y S sean identicos en nombre y
dominio. Ver Tabla 5.15.
A Ba2 b2a3 b3
Tabla 5.15: Resultado de R ∩ S.
Join Si T y U son relaciones, entonces T ⋊⋉θ U denota al conjunto de tuplas que satis-
facen la condicion θ despues de haber realizado el producto cartesiano entre ambas
relaciones, i.e, es equivalente a las siguientes operaciones: σθ(T×U). Ver Tabla 5.16.
56 Capıtulo 5. Algebra Relacional
C D E Fc1 d1 e2 f2c2 d2 e2 f2
Tabla 5.16: Resultado de T ⋊⋉E 6=e1 U.
Join natural Si V y W son relaciones, entonces V ⋊⋉ W denota al conjunto de tuplas que
tienen el mismo valor en los atributos que son comunes para ambas relaciones. Si
no hay atributos comunes entre las relaciones, entonces el resultado es igual al pro-
ducto cartesiano entre ellas. La operacion join natural es equivalente a las siguientes
operaciones:
πx1,x2,...,xn(σV.y1=W.y1 and V.y2=W.y2 and ... and V.ym=W.ym
(V × W)),
donde y1, y2, . . . , ym son los atributos comunes entre V y W y x1, x2, . . . , xn son los
atributos de V × W eliminando las repeticiones. Notese que y1, y2, . . . , ym es un
subconjunto de x1, x2, . . . , xn. Ver Tablas 5.17, 5.18 y 5.19.
Cc1
Tabla 5.17: Relacion generica V.
C D E Fc1 d1 e1 f1c1 d1 e2 f2c2 d2 e1 f1c2 d2 e2 f2
Tabla 5.18: Relacion generica W.
C D E Fc1 d1 e1 f1c1 d1 e2 f2
Tabla 5.19: Resultado de V ⋊⋉ W.
Cuociente Sea W una relacion con un esquema w[x1, x2, . . . , xn] y V una relacion con
un esquema v[xi, xj , . . . , xm] donde v ⊆ w. La operacion W ÷ V es una relacion
con un esquema z[{xk}] tal que 1 ≤ k ≤ n ∧ k 6∈ {xi, xj , . . . , xm}. El resultado de
la operacion son aquellas subtuplas de W con esquema z tales que sus valores estan
relacionados con todas las tuplas de V. La operacion cuociente es equivalente a las
siguientes operaciones:
5.3. Nota final 57
πxl+1,...,xn(W) - πxl+1,...,xn
((πxl+1,...,xn(W) × V) - W),
donde xl+1, . . . , xn representa los atributos de W que no estan presentes en el es-
quema de V. Esta operacion se puede visualizar como la operacion inversa al producto
cartesiano. Ver Tabla 5.20.
D E Fd1 e1 f1d1 e2 f2
Tabla 5.20: Resultado de W ÷ V.
5.3 Nota final
Como el lector deberıa haber deducido, toda operacion del algebra relacional produce como
resultado otra relacion. De forma conceptual, una operacion que no produce tuplas es una
relacion con cero elementos o relacion vacıa. Por ejemplo, en la Tabla 5.21 se muestra el
resultado de la operacion πC=c3(W), la cual se representa solo por su encabezado.
C D E F
Tabla 5.21: Resultado de πC=c3(W). Ejemplo de relacion vacıa
Si no se satisfacen las condiciones para realizar una operacion, no existe una relacion
resultado. Por ejemplo, la operacion V ∪ W no produce ningun resultado porque las
relaciones tienen esquemas distintos.
5.4 Ejercicios propuestos
1. Sea el siguiente esquema de una base de datos:
• EMPLEADO( rut, nombre, direccion).
• VENDEDOR( rut, comision).
Responda las siguientes consultas:
(a) Mostrar todas las tuplas de la tabla VENDEDOR donde la columna comision
sea igual a 10%.
(b) Mostrar el rut y el nombre de todos los vendedores.
58 Capıtulo 5. Algebra Relacional
(c) Mostrar el rut y el nombre de todos los vendedores con comision del 10%.
2. Sea el siguiente esquema de una base de datos:
• EMPLEADO( rut, nombre, salario).
• PROYECTO( codigo, presupuesto, rut director).
• TRABAJA EN( rut, codigo).
Responda las siguientes consultas:
(a) Nombre y salario de todos los directores de proyectos.
(b) Nombre y salario de los empleados que trabajan en todos los proyectos.
(c) Nombre de los empleados asignados a proyectos que no tienen director.
3. Sea el siguiente esquema de una base de datos:
• MEDICAMENTO( codigo, nombre, laboratorio).
• PRESCRIPCION( codigo, patologıa).
• CONTRAINDICACION( codigo medicamento, codigo contraindicacion).
Responda las siguientes consultas:
(a) Nombre de todos los medicamentos para el resfrıo comun que se pueden tomar
junto con “Aspirina”.
(b) Mostrar todos los pares de medicamentos que sirven para una misma enfer-
medad.
(c) Mostrar todos los laboratorios que no producen “Penicilina”.
4. Sea el siguiente esquema de una base de datos:
• PELICULA( codigo, nombre, director, protagonista, ano, genero).
• CLIENTE( rut, nombre, fono, direccion).
• ARRIENDO( codigo, rut, fecha, fecha devolucion).
Responda las siguientes consultas:
(a) ¿Cuales fueron las pelıculas que se arrendaron en diciembre de 2014?
(b) Mostrar el rut y el nombre de los clientes que han arrendado pelıculas del genero
“Accion”.
5.4. Ejercicios propuestos 59
(c) Mostrar el nombre de las pelıculas que no tuvieron salida entre enero y febrero
de 2015.
5. Sea el siguiente esquema de una base de datos:
• SERVICIO( numero, nombre).
• KARDEX( rut, nombre, apellido, fecha nacimiento).
• FICHA DIAGNOSTICO( rut, fecha, numero, diagnostico).
Responda las siguientes consultas:
(a) Nombre de los servicios que no han atendido usuarios en los ultimos dos meses.
(b) ¿Que usuarios han tenido “Apendicitis” pero no fueron atendidos por el servicio
de “Urgencia”? Considerar entre el 1 y el 28 de febrero de 2015?
(c) Nombre de los usuarios que han recibido atencion en todos los servicios.
6. Sea el siguiente esquema de una base de datos:
• ALUMNO( rut, apellido, nombre, direccion, fono).
• ASIGNATURA( codigo, nombre, creditos, descripcion, semestre, ano).
• INSCRIPCION( rut, codigo, semestre, ano, opcion, nota).
• REQUISITO( codigo, codigo requisito).
Responda las siguientes consultas:
(a) Apellido y nombre de todos los alumnos que inscribieron asignaturas el segundo
semestre de 2014.
(b) Apellido y nombre de los alumnos que hayan cursado todas las asignaturas.
7. Sea el siguiente esquema de una base de datos:
• LIBRO( codigo, tıtulo, autor).
• LECTOR( rut, apellido, nombre, direccion).
• PRESTAMO( rut, codigo, fecha, fecha devolucion, estado devolucion).
Responda las siguientes consultas:
(a) Indicar los datos personales de todas aquellas personas que tengan alguna copia
del libro “Diseno de Bases de Datos Relacionales”.
60 Capıtulo 5. Algebra Relacional
(b) Indicar los datos personales de aquellos lectores que hayan pedido todos los
libros del autor “Herbert Schild”.
(c) Indicar el nombre de todos los lectores que tengan libros atrasados a la fecha
de hoy.
8. Sea el siguiente esquema de una base de datos:
• TIPO CUENTA( tipo, nombre, descripcion).
• CUENTA( numero, tipo, rut, fecha apertura, fecha ultimo movimiento, saldo).
• DEPOSITO( codigo, numero, monto, fecha, sucursal).
• GIRO( codigo, numero, monto, fecha, sucursal).
• CLIENTE( rut, nombre, apellido, direccion, fono, ciudad, fecha nacimiento).
Responda las siguientes consultas:
(a) Listado de clientes que realizaron depositos en septiembre de 2014.
(b) ¿Cuantos clientes estan sobregirados? (Saldo < 0).
(c) Giros realizados por el cliente “NN” en “Cuentade Ahorro” para la sucursal de
“Punta Arenas” en enero de 2015.
(d) ¿Que clientes tienen todos los tipos de cuenta?
(e) ¿Que clientes sobregirados no han hecho depositos el dıa de hoy?
Capıtulo 6
SQL
El Lenguaje Estructurado de Consultas (SQL por sus siglas en Ingles: Structure Query
Language) es el estandar de bases de datos relacionales. Fue desarrollado por IBM, y
despues de algunas modificaciones fue estandarizado en 1986.
Como introduccion para el aprendizaje de este lenguaje se recomienda seguir la pauta
del Manual de Referencia de MySQL; en especıfico, se debe considerar el Capıtulo 3 del
Manual: Curso (tutorial) de MySQL.
Para efectos de comparacion se pueden descargar tutoriales de otros administradores
como PostgreSQL, Oracle, DB2, Microsoft SQL Server, etc.
Visto el Curso (tutorial) del Manual, este Capıtulo presenta una serie de ejercicios
relacionados con la base de datos EMPRESA —vista en el Capıtulo 3—. Estos ejercicios
incluyen los aspectos mas relevantes del Lenguaje.
6.1 Consultas con SQL
SQL tiene una instruccin principal para recuperar informacion de una base de datos:
el comando SELECT. Esta instruccion tiene muchas opciones. La forma basica de la
instruccion SELECT es la siguiente:
SELECT <lista de atributos>
FROM <lista de tablas>
WHERE <condicion>
61
62 Capıtulo 6. SQL
donde:
• <lista de atributos> es una lista de nombres de atributos cuyos valores van a ser
recuperados por la consulta.
• <lista de tablas> es una lista de nombres de relaciones requeridos para procesar la
consulta.
• <condicion> es una expresin de busqueda condicional (logica) que identifica las
tuplas que van a ser recuperadas por la consulta.
En los siguientes ejemplos usaremos las tablas (junto con la informacion de estas)
definidas en el capıtulo 3 del Apunte.
Capıtulo 7
API C de MySQL
Como una forma de introducir al lector en la creacion de aplicaciones para bases de datos,
el presente Capıtulo muestra el ejemplo de una implementacion para una tabla llamada
Authors, a la cual se le realizan unas consultas sencillas a traves de la API C de MySQL.
En general, una API (siglas de Application Programming Interface es un conjunto
de reglas (codigo) y especificaciones que las aplicaciones pueden seguir para comunicarse
entre ellas: sirviendo de interfaz entre programas diferentes de la misma manera en que la
interfaz de usuario facilita la interaccion humano-software.
Un detalle mas amplio de la API se puede encontrar en el Capıtulo 24 del Manual de
Referencia: APIs de MySQL.
7.1 Base de datos
Para crear la base de datos de ejemplo se carga desde la lınea de comando el archivo
Books Distributor.sql
mysql -u root -p < Books_Distributor.sql
Donde Books Distributor.sql fue creado previamente con mysqldump mediante el
comando:
mysqldump --add-drop-database --databases -u root -p Books_Distributor > Books_Distributor.sql
63
64 Capıtulo 7. API C de MySQL
El contenido del archivo Books Distributor.sql es el siguiente:
-- MySQL dump 10.13 Distrib 5.1.61, for debian-linux-gnu (i686)
--
-- Host: localhost Database: Books_Distributor
-- ------------------------------------------------------
-- Server version 5.1.61-0ubuntu0.10.10.1
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE=’+00:00’ */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE=’NO_AUTO_VALUE_ON_ZERO’ */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;
--
-- Current Database: ‘Books_Distributor‘
--
/*!40000 DROP DATABASE IF EXISTS ‘Books_Distributor‘*/;
CREATE DATABASE /*!32312 IF NOT EXISTS*/ ‘Books_Distributor‘ /*!40100 DEFAULT CHARACTER SET latin1 */;
USE ‘Books_Distributor‘;
--
-- Table structure for table ‘Authors‘
--
DROP TABLE IF EXISTS ‘Authors‘;
/*!40101 SET @saved_cs_client = @@character_set_client */;
7.1. Base de datos 65
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE ‘Authors‘ (
‘id_autor‘ varchar(8) NOT NULL,
‘last_name‘ varchar(20) NOT NULL,
‘first_name‘ varchar(20) NOT NULL,
‘phone‘ varchar(20) DEFAULT NULL,
‘address‘ varchar(30) NOT NULL,
‘city‘ varchar(20) NOT NULL,
‘state‘ varchar(20) DEFAULT NULL,
‘country‘ varchar(20) NOT NULL,
‘postcode‘ varchar(20) DEFAULT NULL,
PRIMARY KEY (‘id_autor‘)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
/*!40101 SET character_set_client = @saved_cs_client */;
--
-- Dumping data for table ‘Authors‘
--
LOCK TABLES ‘Authors‘ WRITE;
/*!40000 ALTER TABLE ‘Authors‘ DISABLE KEYS */;
INSERT INTO ‘Authors‘ VALUES (’172-32-1’,’White’,’Johnson’,’408 496-7223’,’10932 Bigge Rd.’,’Menlo
/*!40000 ALTER TABLE ‘Authors‘ ENABLE KEYS */;
UNLOCK TABLES;
/*!40103 SET TIME_ZONE=@OLD_TIME_ZONE */;
/*!40101 SET SQL_MODE=@OLD_SQL_MODE */;
/*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */;
/*!40014 SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS */;
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;
/*!40111 SET SQL_NOTES=@OLD_SQL_NOTES */;
-- Dump completed on 2012-06-13 20:47:43
66 Capıtulo 7. API C de MySQL
7.2 Makefile
Para compilar la aplicacion de ejemplo es conveniente utilizar un script. En este caso se
sugiere utilizar el comando make con el siguiente archivo Makefile:
CC = gcc
OUT = authors
SRC = ${OUT}
all:
${CC} ${SRC}.c ‘mysql_config --libs --cflags‘ -o ${OUT}
7.3 Codigo fuente
El codigo fuente de la aplicacion se encuentra en el archivo authors.c:
#include <stdio.h>
#include <mysql/mysql.h>
#include <stdlib.h>
#define DESCRIBE_TABLE 1
#define SELECT_ALL_ROWS 2
#define INSERT_ROW 3
#define EXIT 4
static void describe_table();
static void select_all_rows();
static void insert_row();
int main
(
void
)
{
MYSQL* conn = NULL;
7.3. Codigo fuente 67
char* server = "localhost";
char* user = "root";
char* password = "toor";
char* database = "Books_Distributor";
int option = 0;
conn = mysql_init(NULL);
if (!mysql_real_connect(conn, server, user, password, database, 0, NULL, 0))
{
printf("%s\n", mysql_error(conn));
exit(1);
}
do
{
system("clear");
printf("Menu\n\n");
printf("1. Describe table\n");
printf("2. Select all rows from the table\n");
printf("3. Insert row\n");
printf("4. Exit\n\n");
printf("Select an option from the menu: ");
scanf("%1d",&option);
while (getchar() != ’\n’);
switch (option)
{
case DESCRIBE_TABLE:
describe_table(conn);
break;
case SELECT_ALL_ROWS:
select_all_rows(conn);
break;
case INSERT_ROW:
insert_row(conn);
break;
case EXIT:
68 Capıtulo 7. API C de MySQL
break;
}
if (option == EXIT)
continue;
printf("Press ENTER to go back at the menu: ");
while (getchar() != ’\n’);
}while (option != EXIT);
mysql_close(conn);
printf("Bye!\n");
return 0;
}
void describe_table
(
MYSQL* conn
)
{
char* query = NULL;
MYSQL_RES* result = NULL;
MYSQL_ROW row = (MYSQL_ROW)0;
int i = 0;
query = "describe Authors";
if (mysql_query(conn, query))
{
printf("%s\n", mysql_error(conn));
exit(1);
}
result = mysql_use_result(conn);
printf("\n");
while ((row = mysql_fetch_row(result)) != NULL)
{
for (i = 0; i <= mysql_num_fields(result) - 1; i++)
printf("%s, ", row[i]);
7.3. Codigo fuente 69
printf("\n");
}
mysql_free_result(result);
printf("\n");
return;
}
void select_all_rows
(
MYSQL* conn
)
{
char* query = NULL;
MYSQL_RES* result = NULL;
MYSQL_ROW row = (MYSQL_ROW)0;
int i = 0;
query = "select * from Authors";
if (mysql_query(conn, query))
{
printf("%s\n", mysql_error(conn));
exit(1);
}
result = mysql_use_result(conn);
printf("\n");
while ((row = mysql_fetch_row(result)) != NULL)
{
for (i = 0; i <= mysql_num_fields(result) - 1; i++)
printf("%s, ", row[i]);
printf("\n");
}
mysql_free_result(result);
printf("\n");
70 Capıtulo 7. API C de MySQL
return;
}
void my_fgets
(
char* field
)
{
int i = 0;
fgets(field,30,stdin);
for (i = 0; field[i] != ’\n’; i++);
field[i] = ’\0’;
}
#include <string.h>
void insert_row
(
MYSQL* conn
)
{
char* id_author = NULL;
char* last_name = NULL;
char* first_name = NULL;
char* phone = NULL;
char* address = NULL;
char* city = NULL;
char* state = NULL;
char* country = NULL;
char* postcode = NULL;
char query[1000];
id_author = (char*)malloc(sizeof(char) * (20 + 1));
last_name = (char*)malloc(sizeof(char) * (20 + 1));
first_name = (char*)malloc(sizeof(char) * (20 + 1));
7.3. Codigo fuente 71
phone = (char*)malloc(sizeof(char) * (20 + 1));
address = (char*)malloc(sizeof(char) * (30 + 1));
city = (char*)malloc(sizeof(char) * (20 + 1));
state = (char*)malloc(sizeof(char) * (20 + 1));
country = (char*)malloc(sizeof(char) * (20 + 1));
postcode = (char*)malloc(sizeof(char) * (20 + 1));
printf("\n");
printf("Identifier author: ");
my_fgets(id_author);
printf("Last name: ");
my_fgets(last_name);
printf("First name: ");
my_fgets(first_name);
printf("Phone: ");
my_fgets(phone);
printf("Address: ");
my_fgets(address);
printf("City: ");
my_fgets(city);
printf("State: ");
my_fgets(state);
printf("Country: ");
my_fgets(country);
printf("Postcode: ");
my_fgets(postcode);
strcpy(query, "insert into Authors values (");
strcat(query, "’"); strcat(query, id_author); strcat(query, "’, ");
strcat(query, "’"); strcat(query, last_name); strcat(query, "’, ");
strcat(query, "’"); strcat(query, first_name); strcat(query, "’, ");
strcat(query, "’"); strcat(query, phone); strcat(query, "’, ");
strcat(query, "’"); strcat(query, address); strcat(query, "’, ");
strcat(query, "’"); strcat(query, city); strcat(query, "’, ");
strcat(query, "’"); strcat(query, state); strcat(query, "’, ");
strcat(query, "’"); strcat(query, country); strcat(query, "’, ");
strcat(query, "’"); strcat(query, postcode); strcat(query, "’");
72 Capıtulo 7. API C de MySQL
strcat(query, ")");
printf("%s\n",query);
if (mysql_query(conn, query))
{
printf("%s\n", mysql_error(conn));
exit(1);
}
printf("\n%d row was inserted into Authors.\n", (int)mysql_affected_rows(conn));
free(id_author);
free(last_name);
free(first_name);
free(phone);
free(address);
free(city);
free(state);
free(country);
free(postcode);
printf("\n");
return;
}
Capıtulo 8
Normalizacion
La teorıa de la normalizacion proporciona una formalizacion de ideas sencillas que son
utiles para el diseno de una base de datos. Estas ideas se aplican sobre el esquema de la base
de datos y consideran aquellas propiedades que siempre son verdaderas, i.e. propiedades
de los datos que siempre se cumplen.
Se debe tener en cuenta que cuando se disena una base de datos utilizando el modelo
Entidad-Relacion, de forma implıcita se esta aplicando la teorıa de la normalizacion. El
estudiante debe recordar que cuando aplico este modelo solo tenıa en consideracion los
atributos de las entidades y relaciones, sin considerar cuales eran los valores particulares
que tendrıa cada atributo. En este capıtulo por tanto se trabaja mas con la cabecera de
una tabla que con el cuerpo.
En general, si el modelo Entidad-Relacion esta correcto, entonces al transformarlo al
modelo relacional deberıa producir como resultado una base de datos relacional norma-
lizada. Sin embargo, si el esquema de la base de datos fue creado de manera directa, i.e. sin
un modelo Entidad-Relacion previo, entonces podrıa ocurrir que alguna de las relaciones
no este completamente normalizada.
En terminos practicos, la teorıa de la normalizacion nos proporciona las herramientas
necesarias para descomponer una relacion en una o mas tablas hasta obtener un diseno
correcto desde el punto de vista de la teorıa.
73
74 Capıtulo 8. Normalizacion
8.1 Problemas que genera un mal diseno
Normalmente existen varias alternativas para el conjunto de relaciones y sus esquemas en
una base de datos. El objetivo es establecer criterios para escoger la “mejor” alternativa.
Consideremos la relacion:
• Proveedor( codigo proveedor, nombre proveedor, codigo insumo, precio insumo).
La relacion Proveedor presenta los siguientes problemas:
• Redundancia: el nombre del proveedor se repite por cada insumo que suministra.
• Inconsistencias: el proveedor puede aparecer con nombres distintos, en tuplas dis-
tintas, producto de errores en actualizaciones.
• Perdida de informacion: al eliminar las tuplas de un proveedor determinado, perde-
mos datos como su nombre.
• Falta de informacion: para insertar el nombre de un proveedor, es necesario primero
que se le cotize algo1.
Para el ejemplo, la solucion es descomponer la relacion Proveedores en:
• Proveedor( codigo proveedor, nombre proveedor);
• Insumo( codigo insumo, precio insumo, codigo proveedor).
Ahora, para responder la consulta “Nombre de cada proveedor que suministra el insumo
de codigo 103”, se debe hacer el join natural entre Proveedor e Insumo. Una descomposion
mal hecha, puede implicar perdida de informacion. Por ejemplo:
• P( codigo proveedor, nombre proveedor, precio insumo);
• I( codigo insumo, precio insumo).
De forma grafica, sea la relacion original como la que se muestra en la Tabla 8.1. La
descomposicion en P e I se muestra en las Tablas 8.2 y 8.3. La operacion P ⋊⋉ I da como
resultado la Tabla 8.4:
1Nota del Recopilador: ¿sera importante tener su nombre si no se le cotiza nada?
8.1. Problemas que genera un mal diseno 75
codigo proveedor nombre proveedor codigo insumo precio insumoP1 Silva 100 200P1 Silva 103 70P2 Morales 201 200P3 Gallardo 305 100P3 Gallardo 390 70
Tabla 8.1: Muestra original de la relacion Proveedor.
codigo proveedor nombre proveedor precio insumoP1 Silva 200P1 Silva 70P2 Morales 200P3 Gallardo 100P3 Gallardo 70
Tabla 8.2: Relacion P, obtenida al descomponer Proveedor.
codigo insumo precio insumo100 200103 70201 200305 100390 70
Tabla 8.3: Relacion I, obtenida al descomponer Proveedor.
codigo proveedor nombre proveedor codigo insumo precio insumoP1 Silva 100 200P1 Silva 201 200P1 Silva 103 70P1 Silva 390 70P2 Morales 100 200P2 Morales 201 200P3 Gallardo 305 100P3 Gallardo 103 70P3 Gallardo 390 70
Tabla 8.4: Resultado de P ⋊⋉ I.
La Tabla 8.5 muestra el resultado de la consulta “Seleccionar las tuplas con codigo
de insumo igual a 103” sobre P ⋊⋉ I. Luego, la consulta “Nombre de cada proveedor que
suministra el insumo de codigo 103” obtiene un resultado incorrecto en comparacion a la
que se obtendrıa con la descomposicion de las tablas Proveedor e Insumo que se plantean
en la primera descomposicion.
Se asume que el estudiante puede comprobar el resultado de
la operacion Proveedor ⋊⋉ Insumo y luego obtener el resultado de
76 Capıtulo 8. Normalizacion
πnombre proveedor(σcodigo insumo=103(Proveedor ⋊⋉ Insumo)).
codigo proveedor nombre proveedor codigo insumo precio insumoP1 Silva 103 70P3 Gallardo 103 70
Tabla 8.5: Resultado de σcodigo insumo=103(P ⋊⋉ I).
Como se ha comprobado de forma grafica, se ha perdido informacion ya que la res-
puesta obtenida no es correcta y no hay forma de saber cual es la respuesta correcta.
La descomposicion en P e I es una descomposicion con perdida de informacion. Una
descomposicion sin perdida de informacion es aquella en que al hacer un join natural de
las tablas resultantes de la descomposicion se obtiene la tabla original.
Existe una jerarquıa de formas normales que permiten descubrir si una descomposicion
ha sido bien hecha. Esta jerarquıa se denota desde 1FN hasta 5FN.
8.2 Primera Forma Normal: 1FN
1FN Una relacion R esta en 1FN si y solo si todos los dominios utilizados contienen solo
valores atomicos o escalares2.
Sea por ejemplo la Tabla 8.6; se puede apreciar de forma clara que el atributo
cuota cliente corresponde con un conjunto de pares de valores; luego, esta relacion no
se encuentra en 1FN. Para que cumpla las condiciones, los valores de la relacion deben ser
ordenados como se muestra en la Tabla 8.7.
rut cliente cuota cliente1111-1 (10.000, 30/4/2016), (10.000, 30/5/2016), (10.000, 30/6/2016)9999-9 (20.000, 25/5/2016), (20.000, 25/5/2016)
Tabla 8.6: Relacion R no normalizada.
rut cliente monto cuota fecha cuota1111-1 10.000 30/4/20161111-1 10.000 30/5/20161111-1 10.000 30/6/20169999-9 20.000 25/5/20169999-9 20.000 25/6/2016
Tabla 8.7: Relacion R normalizada en 1FN.
2¿Cual es la diferencia entre valor atomico y valor escalar?
8.3. Segunda Forma Normal: 2FN 77
Por definicion del Modelo Relacional, todas las relaciones estan en 1FN. En cambio,
para el Modelo Entidad-Relacion, si una entidad o relacion tiene un atributo multivaluado
entonces no esta en 1FN. Como se vio en la Seccion 3.3, al pasar de un modelo a otro se
soluciona el problema.
8.3 Segunda Forma Normal: 2FN
2FN Una relacion R esta en 2FN si y solo si esta en 1FN y cada atributo que no pertenece
a la llave depende funcionalmente de toda la llave.
En las siguientes subsecciones se explicara el concepto de dependencia funcional. Este
concepto se utilizara para poder entender la definicion de 2FN y de cada una de las
siguientes formas normales, desde 3FN hasta 5FN.
8.3.1 Dependecia funcional
Sea R una relacion con atributos (a1, a2, . . . , an), y sean X e Y dos subonjuntos de los
atributos ai. Se dice que Y depende funcionalmente de X y se denota como:
X → Y,
si para todo par de tuplas t1 y t2 se cumple:
t1[X] = t2[X] ⇒ t1[Y ] = t2[Y ].
En terminos practicos, la notacion significa que dado un conjunto de atributos X solo
existe un conjunto de atributos Y que se puede obtener a partir de X. Por ejemplo, dado
el rut de una persona, solo podemos obtener los datos personales de una sola persona, no
de varias. Notese que para un nativo del Castellano, la notacion X → Y se puede leer
de manera mas sencilla como “X determina funcionalmente a Y ”. Veamos ahora como se
puede aplicar esto al ejemplo de la relacion Proveedor original:
• Proveedor( codigo proveedor, nombre proveedor, codigo insumo, precio insumo).
Por la definicion dada se tienen las siguientes dependecias funcionales:
78 Capıtulo 8. Normalizacion
• codigo proveedor → nombre proveedor;
• (codigo proveedor, codigo insumo) → precio insumo.
Por lo tanto, la descomposicion correcta nos lleva a las relaciones planteadas en un
inicio (notese que el orden de los atributos no es relevante):
• Proveedor( codigo proveedor, nombre proveedor);
• Insumo( codigo insumo, precio insumo, codigo proveedor).
Se debe tener en cuenta que las dependencias funcionales no son una propiedad del
contenido actual de la relacion (como por ejemplo la Tabla 8.1), sino del mundo real
representado a traves del esquema de la relacion. El concepto de dependencia funcional
es similar al concepto de llave (key), pero este ultimo es mas exigente.
Llave de una relacion Un subconjunto K de atributos de una relacion R con atributos
(a1, a2, . . . , an) es llave si:
1. K → (a1, a2, . . . , an), y
2. No existe X ⊂ K tal que X → (a1, a2, . . . , an).
Superllave de una relacion Un subconjunto S de atributos de una relacion R con atri-
butos (a1, a2, . . . , an) es superllave3 si:
1. S → (a1, a2, . . . , an), y
2. Existe X ⊂ S tal que X → (a1, a2, . . . , an).
Llave candidata de una relacion Un subconjunto X de atributos de una relacion R
con atributos (a1, a2, . . . , an) es llave candidata si:
1. X → (a1, a2, . . . , an), y
2. Existe K 6= X tal que K → (a1, a2, . . . , an).
Se debe considerar que las definiciones hacen uso de la dependencia funcional trivial
A → A. A partir de un conjunto de dependencias funcionales se pueden deducir otras: por
3¿Coincide con la definicion dada en 3.1.2?
8.3. Segunda Forma Normal: 2FN 79
ejemplo, consideremos una relacion con atributos a, b y c donde a → b y b → c, entonces
se debe cumplir a → c.
En general, existen tres axiomas4 basicos: sea R el esquema de una relacion y F el
conjunto de dependencias funcionales de R, entonces:
1. Reflexibidad: si Y ⊆ X ⊆ R entonces X → Y independientemente de F . Por
ejemplo: A → A y AB → A.
2. Aumentacion: si X → Y pertenece a F , y Z ⊆ R, entonces XZ → Y Z.
3. Transitividad: si X → Y e Y → Z pertenecen a F , entonces X → Z.
A partir de estos axiomas se deducen los siguientes:
1. Union: si X → Y y X → Z entonces X → Y Z.
2. Descomposicion: si X → Y Z entonces X → Y y X → Z.
3. Seudotransitividad: si X → Y y WY → Z entonces XW → Z.
8.3.2 Propiedades deseables de una descomposicion
Sea R el esquema de una relacion, R1 y R2 descomposiciones de R tal que R1 ∪ R2 = R.
Se puede asegurar que la descomposicion es sin perdida de informacion si se cumple al
menos una de las siguientes dependencias:
1. (R1 ∩R2) → (R1 −R2) ⇔ (R1 ∩R2) → R1.
2. (R1 ∩R2) → (R2 −R1) ⇔ (R1 ∩R2) → R2.
Ahora se puede comprobar el ejemplo de la relacion Proveedor y su descomposicion en
las relaciones Proveedor e Insumo. Sea:
• R = Proveedor(codigo proveedor, nombre proveedor, codigo insumo, pre-
cio insumo);
• R1 = Proveedor( codigo proveedor, nombre proveedor);
• R2 = Insumo( codigo insumo, precio insumo, codigo proveedor).
4Axioma: proposicion o enunciado tan evidente que se considera que no requiere demostracion.
80 Capıtulo 8. Normalizacion
Entonces:
• Se cumple que R1 ∪ R2 = R, esto es ( codigo proveedor, nombre proveedor)
∪ ( codigo insumo, precio insumo, codigo proveedor) = (codigo proveedor, nom-
bre proveedor, codigo insumo, precio insumo);
• Se cumple (R1 ∩ R2) → (R1 − R2), esto es codigo proveedor → nombre proveedor,
visto que (R1 ∩R2) = codigo proveedor y (R1 −R2) = nombre proveedor;
• Se cumple (R1 ∩ R2) → R1, esto es codigo proveedor → ( codigo proveedor, nom-
bre proveedor), visto que codigo proveedor → codigo proveedor y codigo proveedor
→ nombre proveedor.
En cambio, si la descomposicion es:
• R = Proveedor(codigo proveedor, nombre proveedor, codigo insumo, pre-
cio insumo);
• R1 = P( codigo proveedor, nombre proveedor, precio insumo);
• R2 = I( codigo insumo, precio insumo).
Entonces:
• Se cumple que R1 ∪ R2 = R, esto es ( codigo proveedor, nombre proveedor,
precio insumo) ∪ ( codigo insumo, precio insumo) = (codigo proveedor, nom-
bre proveedor, codigo insumo, precio insumo)5;
• No se cumple (R1 ∩R2) → (R1 −R2), esto es precio insumo → ( codigo proveedor,
nombre proveedor), visto que codigo proveedor y nombre proveedor no dependen
funcionalmente de precio insumo;
• No se cumple (R1 ∩R2) → (R2−R1), esto es precio insumo → codigo insumo, visto
que codigo insumo no depende funcionalmente de precio insumo.
El lector deberıa notar la “ingenuidad” de los ejemplos, los cuales se realizan a modo
ilustrativo. Lo mas importante es notar que las dependencias funcionales deben ser identi-
ficadas por el disenador de los esquemas en relacion al mundo real que se esta modelando.
5Se pone enfasis en el hecho que el orden de los atributos no es relevante
8.3. Segunda Forma Normal: 2FN 81
En otras palabras, el conjunto de dependencias funcionales de la relacion Proveedor ori-
ginal —independiente de cualquier esquema de descomposicion— es siempre el mismo y
existe desde el principio, aun sin descomposicion, esto es:
• codigo proveedor → nombre proveedor;
• (codigo proveedor, codigo insumo) → precio insumo.
8.3.3 Conservacion de las dependencias funcionales
Cuando se descompone una relacion se heredan las dependencias funcionales segun los
atributos de cada descomposicion. Sea F el conjunto de dependencias funcionales de una
relacion R y Fi el conjunto de dependencias funcionales de Ri. Fi es el conjunto de
dependencias que estan en F , pero que solo mencionan atributos de Ri. Algunas de las
dependencias funcionales de F podrıan no aparecer en ningun Fi, es decir⋃
Fi 6= F .
Por ejemplo: consideremos el esquema (ciudad, calle, comuna), y supongamos6 que
dentro de una ciudad no hay calles repetidas y que dos ciudades distintas no tienen comunas
del mismo nombre. Pueden haber dos ciudades con el mismo nombre de calle. Luego las
dependencias en F son:
• comuna → ciudad;
• (ciudad, calle) → comuna.
Con llave (ciudad, calle), si descomponemos en:
• R1 = (comuna, ciudad);
• R2 = (calle, comuna).
Entonces tenemos las siguientes dependencias:
• F1 = {comuna → ciudad};
• F2 = {calle → calle, comuna → comuna}).
6Nota del Recopilador: las suposiciones juegan un papel muy importante en el estudio y diseno de lasbases de datos, en contraposicion al mundo real, al cual siempre se hace referencia.
82 Capıtulo 8. Normalizacion
La dependencia (ciudad, calle) → comuna no aparece en ningun Fi. Para este esquema
no existe ninguna descomposicion que conserve todas las dependencias funcionales, pero
la descomposicion es sin perdida de informacion, puesto que se cumple:
1. (R1 ∩ R2) → (R1 − R2) ⇔ (R1 ∩ R2) → R1, visto que (comuna, ciudad) ∩
(calle,comuna) = (comuna) y (comuna, ciudad) - (calle, comuna) = ciudad, en-
tonces comuna → ciudad; ademas, comuna → comuna, ciudad, visto que comuna →
comuna y comuna → ciudad.
Una descomposicion conserva todas las dependencias funcionales si toda
dependencia presente en F esta en⋃Fi o puede ser deducida a partir de
⋃Fi. Por ejemplo, consideremos el esquema (A, B, C) y supongamos que se
cumplen A → B y B → C, entonces tambien existe A → C. Supongamos que
descomponemos en R1(A,B) y R2(B,C), entonces existe F1 = {A → B} y
F2 = {B → C}. Como F1 ∪ F2 implican A → C, entonces la descomposicion
conserva todas las dependencias funcionales.
Si no se puede hacer una descomposicion que conserve todas las dependencias funcionales,
entonces no se hace la descomposicon.
8.3.4 2FN
Volvamos ahora a nuestro ejemplo de la relacion Proveedor y la definicion de 2FN dada
en la seccion 8.3. La primera condicon que debe cumplir la relacion es estar en 1FN, esto
es que sus atributos sean atomicos y escalares:
• Proveedor(codigo proveedor, nombre proveedor, codigo insumo, precio insumo).
Lo cual se cumple. La segunda condicion es que cada atributo que no pertenece a la
llave depende funcionalmente de toda la llave. Como se ha dicho antes, las dependencias
funcionales de la relacion Proveedor son las siguientes:
• codigo proveedor → nombre proveedor;
• (codigo proveedor, codigo insumo) → precio insumo.
La llave de la relacion es (codigo proveedor, codigo insumo); el atributo nom-
bre proveedor solo depende funcionalmente de codigo proveedor; por lo tanto, la relacion
Proveedor no esta en 2FN.
8.4. Tercera Forma Normal: 3FN 83
Toda relacion que no esta en 2FN se puede descomponer sin perdida de informacion y
conservando todas las dependencias funcionales, en un conjunto de relaciones que si estan
en 2FN. La solucion es representar como relaciones las dependencias funcionales que no
incluyen a toda la llave eliminando de la tabla los atributos que dependen funcionalmente
de la llave parcial. Para Proveedor la descomposicion es la que se ha mostrado antes:
• Proveedor( codigo proveedor, nombre proveedor);
• Insumo( codigo insumo, precio insumo, codigo proveedor).
Es importante reconocer que una relacion puede estar en 2FN y tener dependencias
funcionales entre atributos que no son parte de la llave. Por ejemplo, sea la relacion R:
• R(empleado, departamento, gerencia).
Con dependencias funcionales:
• empleado → departamento;
• departamento → gerencia;
• empleado → gerencia.
La llave es empleado. Esta relacion esta en 2FN porque todos los atributos que no
son llave dependen funcionalmente de la llave. Pero la tabla presenta problemas debido
a la duplicacion de informacion con los pares de valores (departamento, gerencia). Para
solucionar estos problemas de dependencias funcionales transitivas se recurre a la tercera
forma normal.
8.4 Tercera Forma Normal: 3FN
84 Capıtulo 8. Normalizacion
top related