Disenõ e Implementacioń de Bases Datos Relacionalesjaguila/Databases/Data_Base_Design.pdf · Disenõ e Implementacioń de Bases Datos Relacionales Recopilación y adaptaci

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


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


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


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


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


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.


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.


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.


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.


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


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


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


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


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


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


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.


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


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.


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.


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.


• 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.


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.


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:


• 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


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


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-


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.


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.


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


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


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.


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.


2. Implementar con la herramienta MySQL Workbench el diagrama EER equivalente

para la base de datos mostrada en la Figura 4.15.


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ı.


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.


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.



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.


Tabla 5.18: Relacion generica W.


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.


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.


(c) Mostrar el rut y el nombre de todos los vendedores con comision del 10%.


• EMPLEADO( rut, nombre, salario).

• PROYECTO( codigo, presupuesto, rut director).

• TRABAJA EN( rut, codigo).


(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.


• MEDICAMENTO( codigo, nombre, laboratorio).

• PRESCRIPCION( codigo, patologıa).

• CONTRAINDICACION( codigo medicamento, codigo contraindicacion).


(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”.


• PELICULA( codigo, nombre, director, protagonista, ano, genero).

• CLIENTE( rut, nombre, fono, direccion).

• ARRIENDO( codigo, rut, fecha, fecha devolucion).


(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”.


(c) Mostrar el nombre de las pelıculas que no tuvieron salida entre enero y febrero

de 2015.


• SERVICIO( numero, nombre).

• KARDEX( rut, nombre, apellido, fecha nacimiento).

• FICHA DIAGNOSTICO( rut, fecha, numero, diagnostico).


(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.


• ALUMNO( rut, apellido, nombre, direccion, fono).

• ASIGNATURA( codigo, nombre, creditos, descripcion, semestre, ano).

• INSCRIPCION( rut, codigo, semestre, ano, opcion, nota).

• REQUISITO( codigo, codigo requisito).


(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.


• LIBRO( codigo, tıtulo, autor).

• LECTOR( rut, apellido, nombre, direccion).

• PRESTAMO( rut, codigo, fecha, fecha devolucion, estado devolucion).


(a) Indicar los datos personales de todas aquellas personas que tengan alguna copia

del libro “Diseno de Bases de Datos Relacionales”.


(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.


• 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).


(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


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:


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))

{


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");

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";


{


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");


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));


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, "’");


strcat(query, ")");

printf("%s\n",query);


{


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


π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:


• 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):



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?


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.


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


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:



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.


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:



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:



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


Documents

Disenõ e Implementacioń de Bases Datos Relacionalesjaguila/Databases/Data_Base_Design.pdf · Disenõ e Implementacioń de Bases Datos Relacionales Recopilación y adaptaci