Data Base Design

Dise
no e Implementaci
on de Bases Datos
Relacionales
n y adaptacio
Recopilacio n de los apuntes de los cursos de bases de datos
utilizados por el recopilador
Recopilador:
Julio J. Aguila G.
Autores: Cesar Guerrero Saldivia
Mauricio Marn
Punta Arenas, julio 2014

Resumen
Este libro es una recopilaci

on 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 Marn. El primero escribi
o el curso como docente de la Universidad de Chile;
el segundo escribi
o 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 deberan
ser compatibles con las u
ltimas versiones de Ubuntu.
i
Contenidos
1 Introducci
on 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 fsica de un DBMS . . . . . . . . . . . . . . . . . . . . . 7
2 Modelo Entidad-Relaci
on 11
2.1 Tipos de atributos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2 Tipos de relaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3 Conceptos adicionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4 Metodologa para desarrollar diagramas . . . . . . . . . . . . . . . . . . . . 19
2.5 Unas notas sobre la tipografa . . . . . . . . . . . . . . . . . . . . . . . . . . 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 dise

no 41
4.1 Introduccion a MySQL Workbench . . . . . . . . . . . . . . . . . . . . . . . 42
4.2 Como crear un diagrama EER? . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2.1 Creaci
on de tablas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
iii
4.2.2 Creaci
on de relaciones . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.3 Ejemplo de aplicaci
on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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
Lista de Figuras
1.1 Modelo de datos y sus posibles implementaciones . . . . . . . . . . . . . . . 5

1.2 Visi
on 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 jerarqua con atributos compuestos . . . . . . . . . . . . . . . . 15
2.4 on TRABAJA PARA . . . . . . . . . . . . . . 16
Ejemplo de instancias de la relaci
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 lnea 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 Men
u Tabla de MySQL Workbench . . . . . . . . . . . . . . . . . . . . . . . 44
4.5 Pesta
na Columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.6 Men
u Relaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.7 Men
u Foreign Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 for
anea a tabla EMP . . . . . . . . . . . . . . . . . . . . . . . 48
4.13 Crear referencia hacia tabla DEPT . . . . . . . . . . . . . . . . . . . . . . . 49
v
4.14 Crear referencia utilizando Men
u Relaciones . . . . . . . . . . . . . . . . . . 49
Lista de Tablas
1.1 Tabla de alumnos y notas sin normalizar . . . . . . . . . . . . . . . . . . . . 3
3.1 Ejemplo de instancia para la relaci

on 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=c (W ) . . . . . . . . .
1
. . . . . . . . . . . . . . . . . . . . 55
5.14 Resultado de C=c andD=d andF 6=f (W )
1 1 1
. . . . . . . . . . . . . . . . . . . . 55
5.15 Resultado de R S . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
E6=e1 U . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.16 Resultado de T
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 relaci
on vaca . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Captulo 1
Introducci
on
El almacenamiento, manipulaci
on y recuperaci
on de informacion en forma eficiente, es
vital y estrategico para cualquier organizaci
on. Las bases de datos juegan un rol crtico en
casi todas las
areas donde las computadoras son usadas, incluyendo negocios, ingeniera,
medicina, leyes, educacion, etc.
Una base de datos es una colecci

on 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 dise
nada,
construida y llenada con datos para un proposito especfico. Tiene un grupo de usua-
rios particular, y algunas aplicaciones pre-establecidas en las cuales estos usuarios est
an
interesados.
En otras palabras, una base de datos tiene alguna fuente de la cual los datos son
derivados, alg
un grado de interaccion con eventos en el mundo real, y una audiencia que
est
a 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 colecci
on 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 teora esencial para las bases de datos. Esta teora ayuda al
dise
no 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 Captulo 1. Introduccion
maneja sus propios datos y archivos. Al usar una base de datos, todos los datos se
almacenan en forma integrada, y est
an 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 n

umero de matrcula, 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 a
un, 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.
Matrcula 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 Gonz alez 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 Gonz alez 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 c

omo almacenar informaci
on para los alumnos de una carrera utilizando un enfoque contrario al de las bases de datos normalizadas.
3
En el enfoque de bases de datos se mantiene un u

nico 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 simult

aneamente a los datos (con-
currencia).
1.1 Modelos de datos y definiciones
Una caracterstica fundamental del enfoque de bases de datos es que proporciona cierto
nivel de abstraccion de los datos, al ocultar detalles de almacenamiento que la mayora 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 adem
as 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 cu

al 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

implementaci
on. Un modelo Entidad-Relaci
on, puede ser implementado en bases de datos
arquicas, de red o relacionales, entre otras (ver Figura 1.1). As, existen diferentes
jer
niveles de abstraccion:
Nivel Fsico 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-Relaci

on implementado en diferentes sistemas de
bases de datos.
archivos, metodos de acceso, ndices, etc. En un DBMS, el nivel fsico 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 fsico.
Nivel de Vistas Es un subconjunto del nivel conceptual. A determinados usuarios de

la base de datos se les presenta s
olo un subconjunto de los datos. Para una misma
base de datos se pueden construir varias vistas seg
un el tipo de usuarios del DBMS.
Desde estos enfoques se tiene lo siguiente: una instancia es el contenido de la base de

datos en alg
un 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 fsico, 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 fsica: es posible alterar la implementaci

on sin alterar el
nivel conceptual.
Independencia de datos l
ogica: 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 Manipulaci
on 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 fsico 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 tpicas 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 modificaci

on 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 informaci

on.

En el mismo nivel tecnico, se encuentran los programadores de aplicaciones. Estos
u
ltimos interact
uan con el DBMS a traves del DML, incluyendo instrucciones del DML en
programas escritos en un lenguaje host como Pascal, C o alg
un lenguaje 4GL especialmente
dise
nado para este tipo de aplicaciones.
Desde el punto de vista funcional, existen tambien los usuarios casuales, quienes saben
de computaci
on 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 aplicaci
on. Estos usuarios no necesitan
saber de computaci
on debido a que los desarrolladores les propocionan la interfaz adecuada
para su interacci
on.
1.2.3 Estructura fsica de un DBMS
Desde el punto de vista fsico, 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 visi

on general del DBMS se muestra en la Figura 1.2. En relaci
on
a esta figura, el lector puede dimensionar cu
al es el tama
no del problema al cual est
a
enfocado el curso. Una visi
on mas informal podra 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 telef
onica 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 captulo, el objetivo del curso es conocer los fundamentos que se aplican
en el almacenamiento, manipulaci
on y recuperaci
on de informacion en forma eficiente
para cualquier organizaci
on, donde estos requerimientos son vitales para su desarrollo
estrategico.
1.2. Vista general de un DBMS 9
Figura 1.2: Visi

on general de un DBMS: usuarios, lenguajes, m
odulos, interrelaciones, etc.
Captulo 2
Modelo Entidad-Relaci
on
El modelo Entidad-Relaci
on (E-R) fue presentado por Chen en 1976. Es uno de los modelos
de datos mas populares y se basa en una representaci
on del mundo real en que los datos se
describen como entidades, relaciones y atributos. Este modelo se desarroll
o para facilitar
el dise
no 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 fsico (una persona,
un auto, una casa o un empleado) o un objeto conceptual (una compa
na, un puesto de
trabajo o un curso universitario). En el ejemplo del Captulo I, sobre las inscripciones y
notas de los alumnos de una carrera, se pueden identificar dos entidades: ALUMNO y CURSO.
Cada entidad tiene propiedades especficas que la describen llamadas atributos. Por
ejemplo, una sala de clases tiene un nombre (Sala TI I, Sala 31, Sala de Proyectos), una
ubicaci
on, 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 u
nica. Este atributo o combinacion
de atributos se denomina llave o clave primaria. Por ejemplo, el n
umero de matrcula
es una buena llave para la entidad alumno, no as el nombre, porque pueden existir dos
11
12 Captulo 2. Modelo Entidad-Relacion
personas con el mismo nombre.
Una relaci
on se puede definir como una asociaci
on entre entidades. Por ejemplo, en una
biblioteca la entidad LIBRO puede estar relacionada con la entidad PERSONA por medio de
on EST
la relaci A PEDIDO. La entidad ALUMNO puede estar relacionada con la entidad CURSO
por la relaci
on INSCRIBE. Una relaci
on tambien puede tener atributos. Por ejemplo, la
relaci
on INSCRIBE puede tener los atributos Semestre y Nota.
Considere el siguiente ejemplo sobre el supuesto que se est

an 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 est
a organizada en departamentos. Cada departamento tiene un nom-
bre u
nico. un n
umero u
nico, y un empleado particular quien lo administra. Se
quiere saber la fecha en que el empleado administrador empez
o a hacerse cargo del
departamento. Un departamento puede tener varios locales.
2. Cada departamento controla un cierto n

umero de proyectos. Cada proyecto tiene un
nombre y n
umero u
nicos, y un local.
3. Para cada empleado se desea tener su nombre, rut, direccion, salario, sexo y a
no
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 n
umero de horas semanales que un empleado trabaja
en cada proyecto. Se quiere adem
as saber cu
al 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 relaci
on con el empleado.
La Figura 2.1 muestra el modelo de esta base de datos, a traves de una notacion gr
afica
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 notaci
on gr
afica 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 u
ltimo 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 peque

nas. 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 at
omicos 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 unvoca. Para una entidad PERSONA, un atributo clave tpico 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 com

un, podra darse una jerarqua
de descomposicion como la mostrada en la Figura 2.3. Donde, una Direcci
on puede sub-
dividirse en: Dir Calle, Comuna, Ciudad y Regi
on. A su vez, Dir Calle puede dividirse
en Calle, N
umero 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 dise
nador
2.2. Tipos de relaciones 15
Figura 2.3: Ejemplo de la jerarqua de descomposici

on para atributos compuestos.
debe pensar de forma implcita en ellos cuando est

a 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 relaci
on 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 relaci
on 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 mayora de las relaciones son binarias como se muestran en los ejemplos.
Una relaci
on es un subconjunto del producto cartesiano E1 E2 . . . En . Por
ejemplo: algunas instancias de la relaci
on TRABAJA PARA del ejemplo EMPRESA podran ser
como las mostradas en la Figura 2.4
Una relaci
on podra 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). Seg
un el n
umero de
instancias en las entidades relacionadas (o grado o raz
on de cardinalidad ), se pueden definir
tres tipos de relaciones:
Relaciones Uno a Uno (1:1) Una instancia de la entidad A est

a 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 relaci
on 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 est

a asociada con una
Figura 2.4: Ejemplo de instancias de la relaci

on 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 relaci
on 1:n entre DEPARTAMENTO y PROYECTO de la Figura 2.1.
Relaciones Muchos a Muchos (n:m) Una instancia de la entidad A est

a asociada con
una o varias instancias de la entidad B, y una instancia de la entidad B est
a asociada
con una o varias instancias de la entidad A. Ejemplo: TRABAJA PARA es una relaci
on
n:m entre las entidades EMPLEADO y PROYECTO de la Figura 2.1.
La Figura 2.5 es un ejemplo de la relaci

on ADMINISTRA con un grado de cardinalidad
1:1 entre las entidades EMPLEADO y DEPARTAMENTO. Adem
as, se puede definir el grado de
on u opcionalidad de las entidades participantes: EMPLEADO tiene un grado de
participaci
on parcial en la relaci
participaci on ADMINISTRA, mientras que DEPARTAMENTO tiene un
grado de participaci
on total.
La Figura 2.6 es un ejemplo de la relaci

on TRABAJA EN con un grado de cardinalidad
n:m entre las entidades EMPLEADO y PROYECTO. Tanto EMPLEADO como PROYECTO tienen
grado de participaci
on 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 lneas que unen a las entidades
respectivas de una relaci
on. Por otra parte, la participaci
on parcial en el diagrama E-R
se representa como una lnea simple, la participaci
on total como una lnea doble, como se
2.3. Conceptos adicionales 17
Figura 2.5: Relaci

on ADMINISTRA con un grado de cardinalidad 1:1. EMPLEADO tiene grado de
participaci
on parcial, mientras que DEPARTAMENTO tiene grado de participaci
on total.
Figura 2.6: Relaci

on TRABAJA EN con un grado de cardinalidad n:m. Tanto EMPLEADO como
PROYECTO tienen grado de participaci
on total.
muestra en la Figura 2.1.
2.3 Conceptos adicionales
Los diagramas E-R representan tambien otros conceptos adicionales en el dise

no de una
base de datos. Estos conceptos son los siguientes:
Generalizaci
on y especializaci
on 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 Programaci
on Orientada a Objeto. Su representaci
on
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 lneas dobles para los rectangulos y los rombos
de las entidades dependientes, como se muestra en la Figura 2.1.
Conjuntos de entidades fuertes y d

ebiles 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 est
a 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 especializaci
on.
Llaves candidatas Aunque no es un caso muy com

un, pueden existir varios atributos
en una entidad que sirvan de llave por s mismos. Por ejemplo: para un estudiante
su n
umero de rut y su n
umero de matrcula son u
nicos. En la Figura 2.1, para las
entidades DEPARTAMENTO y PROYECTO se subrayan todos los atributos para resaltar
esta condici
on. En la opinion particular del autor de esta recopilaci
on, esta situacion
podra confundir al estudiante novato e inducirlo a pensar que se trata de una llave
compuesta por todos los atributos, lo cual no se graficara de la misma forma. . . Se
imagina como sera esta forma?
Entidades autoreferenciables Este caso tampoco es muy com

un y se trata de una
entidad que est
a relacionada consigo misma. Por ejemplo la entidad EMPLEADO en
la Figura 2.1. En este caso se recomienda etiquetar cada una de las lneas para su
on SUPERVISI
identificacion: en este caso la relaci ON 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. Metodologa para desarrollar diagramas 19
Figura 2.7: Ejemplo de generalizaci

on de entidades.
2.4 Metodologa para desarrollar diagramas
Dado un problema en particular, el autor de esta recopilaci

on recomienda utilizar la si-
guiente metodologa 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 participaci

on de las entidades.
8. Redactar los supuestos que sean necesarios para explicar la informacion faltante.
2.5 Unas notas sobre la tipografa
En esta recopilaci
on se ha mantenido la tipografa de uno de los textos originales, visto que
no toda las bibliografas respecto al tema coinciden en este punto. Para ayudar al lector
en el dise
no 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 may

usculas.
Los nombres de los atributos se escriben en min

usculas.
Cuando el nombre est

a 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 podra aplicar las convenciones conocidas para alguno de ellos,
e.g. las convenciones de Java. En la fase de implementaci
on se espera que el lector decida
cu
ales son las reglas mas convenientes para su asignacion.
2.6 Ejercicios propuestos
1. Compa
na de capacitaci
on: Soy el administrador de una compa
na de capa-
citaci
on que provee cursos en tecnicas de administracion. Ense
namos muchos cur-
sos, cada uno de los cuales tiene un codigo, un nombre y un precio. Introduccion a
Internet y Programaci
on Java son dos de nuestros cursos mas populares. Los cur-
sos se dictan entre uno a cuatro das. Un instructor puede ense
nar varios cursos.
Nosotros registramos el nombre y n
umero de telefono de los profesores. Cada curso
es ense
nado 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 n
umeros telef
onicos.
2. Vendedores con experiencia: Tenemos estos vendedores en terreno, tratando

de vender nuestros productos a la gente de su regi
on. 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 est

an 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. Compa
na de videos: Soy el propietario de una peque
na tienda de videos. Te-
nemos alrededor de 3.000 cintas de las cuales necesitamos mantener su estado. Cada
una de nuestras cintas tiene un n
umero de identificacion. Para cada pelcula, nece-
sitamos conocer su ttulo y categora (comedia, suspenso, drama, accion, guerra,
etc.). Tenemos m
ultiples copias de muchas de nuestras pelculas. A cada pelcula
le asignamos un identificador y le asociamos las copias que la contienen y su for-
mato. Una pelcula puede ser formato CD o DVD. Siempre tenemos al menos una
copia para cada pelcula que nosotros rastreamos, y cada copia contiene una u
nica
pelcula. Nuestras copias son de larga duracion y no tenemos pelculas que requieran
m
ultiples copias. Frecuentemente nos preguntan por pelculas con actores populares
especficos. As que deseamos registrar las pelculas donde est
an los actores de moda.
No todas nuestras pelculas tienen actores famosos o de moda. Los clientes desean
conocer de cada actor su nombre real y fecha de cumplea
nos. Solo registramos los
actores que aparecen en pelculas 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 n
umero 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 u

nicos sobre-
vivientes de la guerra del a
no 2084, que destruy
o los cuatro planetas de su sistema
solar, se han propuesto construir una nueva forma de organizaci
on social para prote-
ger su raza, actualmente en extinci
on. Cada miembro de la tribu desarrolla alguna
actividad, la cual debe aprender y luego perfeccionar. Por ejemplo: cazar, cultivar
la tierra, educar, etc. Cada ni
no 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 n
umero 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 guas de entrega. Adem
as,
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 est
a dividida en novecientas areas cuadradas,
cada una consistente de un n
umero 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 u
nicos. A cada chofer se le asigna un taxi y un area especfica
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 cu
antos taxis est
an en cada area, el promedio de taxis por area, el
area con mayor n
umero de taxis y el area con el menor n
umero de taxis.
Mantener un registro del n

umero 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 a

nos que mama y yo empezamos esta
peque
na tienda de alimentos naturales, y ahora vea tenemos cinco! Y en tres
estados diferentes! Bueno, como se puede imaginar, se nos est
a haciendo un gran
problema el controlar las cosas. Siempre ocurre que en una de las tiendas se acaba
alg
un 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
sera u
til. 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 n
umeros 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 n
umero total de los diferentes tems, el n
umero de tiendas en cada estado, el
n
umero de empleados en cada tienda, y el n
umero 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 lnea aerea. Extraiga, desde el diagrama
E-R, los requerimientos y restricciones que produjeron dicho esquema, i.e., aplicar
ingeniera inversa.
Figura 2.8: Diagrama E-R para un sistema de reservaciones de una lnea

aerea.
Captulo 3
Modelo Relacional
Este modelo considera la base de datos como una colecci

on de relaciones. De manera
simple, una relaci
on representa una tabla en que cada fila representa una colecci
on 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 present
o con el nombre A Relational Model of Data for Large Shared Data
Banks.
Como se ver
a en este captulo, existe una gran coherencia entre el modelo E-R y el
modelo relacional.
3.1 Dominios, tuplas, atributos, relaciones
Definici
on Un dominio D es un conjunto de valores at
omicos. At
omico quiere decir que
cada valor en el dominio es indivisible. Es u
til dar nombres a los dominios, e.g.:
N
umeros telef
onicos locales: el conjunto de n
umeros de telefonos de 9 dgitos.
Ruts: n
umeros de 8 dgitos mas un car
acter 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 dgitos, etc.
25
26 Captulo 3. Modelo Relacional
Un scheme de relaci
on R denotado por R(A1 , A2 , . . . , An ) est
a constituido por un
nombre de relaci
on 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 relaci
on R. D se llama
el dominio de Ai y se denota dom(Ai ). Un scheme relacional se usa para describir una
relaci
on. R es el nombre de esta relaci
on. El grado de una relaci
on es el n
umero n de
atributos del scheme de la relaci
on. Por ejemplo:
ESTUDIANTE(nombre, rut, fono, direccion, edad, carrera, promedio nota) tiene

grado 7.
dom(nombre) = Nombres.
umeros telef
dom(fono) = N onicos locales.
Definici
on Una relaci
on o instancia de relaci
on r del scheme de relaci
on
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 relaci
on ESTUDIANTE en la Tabla 3.1.
nombre rut fono direccion edad carrera promedio

Benjamn 13.245.622-1 6122244211 Rosas 19 Plan 4.8
Gonzalez 3241 Com un
Sergio 12.341.228-5 nulo Claudio 20 Ing. Ind. 5.1
Soto Gay 2142
... ... ... ... ... ... ...
Tabla 3.1: Ejemplo de instancia para la relaci

on ESTUDIANTE.
Cada tupla representa una entidad de estudiante en particular. La definicion de relaci

on
puede replantearse as: Una relaci
on r(R) es un subconjunto del producto cartesiano de
los dominios que definen r:
r(R) (dom(A1 ) dom(A2 ) . . . dom(An )
El n
umero total de tuplas en el producto cartesiano es:
|dom(A1 )| |dom(A2 )| . . . |dom(An )|

3.1. Dominios, tuplas, atributos, relaciones 27
Una instancia de relaci

on refleja s
olo las tuplas v
alidas que representa un estado par-
ticular del mundo real. A medida que el mundo real cambia, tambien lo hace la relaci
on,
transformandose en otro estado de relaci
on (el scheme R es relativamente est
atico y no
cambia excepto muy pocas veces).
3.1.1 Notaci
on
Un scheme de relaci
on R de grado n se denota R(A1 , A2 , . . . , An ).
Una n-tupla t en una relaci

on 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 relaci

on.
Las letras q, r, s denotan estados de relaci

on.
Las letras t, u, v denotan tuplas.
Los nombres de atributos se califican con el nombre de relaci

on a la cual pertenecen.
Por ejemplo, ESTUDIANTE.nombre, ESTUDIANTE.edad, etc.
Para la tupla t = <Benjamn Gonz

alez, 13.245.622-1, 6122244211, Rosas 3241, 19,
Plan Com
un, 4.8>, tenemos t[nombre] = <Benjamn Gonz
alez>, 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
at
omico del dominio dom(A). Una relaci
on se define como un conjunto de tuplas. Por
definicion todos los elementos de un conjunto son distintos. Luego todas las tuplas de
una relaci
on 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 relaci
on R con la propiedad de que no haya dos tuplas en
una instancia de relaci

on 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 relaci
on r de R, tenemos la restriccion:
t1 [S] 6= t2 [S]
Cualquier conjunto de atributos S es denominado super llave del scheme de relaci

on
R. Cada relaci
on tiene al menos una super llave (el conjunto de todos sus atributos).
Una llave o clave K de un scheme de relaci
on 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 relaci
on, pero no toda super llave es una clave.
El valor de un atributo clave se usa para identificar unvocamente una tupla en una
relaci
on. El hecho que un conjunto de atributos constituya una clase es una propiedad del
scheme de la relaci
on, y es invariante en el tiempo.
En general, un scheme de relaci

on 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 relaci
on. Usamos la convenci
on de que los atributos que forman la llave
primaria de un scheme de relaci
on se subrayan.
3.2 Bases de datos relacional
Un scheme de base de datos relacional es un conjunto de esquemas de relaci

on 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 relaci

on
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 restricci
on 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 relaci
on que hace referencia a otra relaci
on debe referirse a una tupla existente en esa
relaci
on. Por ejemplo, NDEPTO de EMPLEADO debe coincidir con el DNUMERO de
alguna tupla de la relaci
on DEPARTAMENTO. Para una definicion formal, se necesita el
concepto de llave for
anea o llave externa.
30
NPILA APPAT APMAT RUT FNAC DIRECCION SEXO SUELDO RUTSUPERV NDEPTO
Juan Perez Garca 12345678 9-1-55 Toesca 965 M 120 33344555 5
Alicia Zelaya Roa 99988777 19-7- Blanco 2120 F 105 98765432 4
58
Juana Besa Martnez 98765432 20-6- Mapocho F 240 88866555 4
31 2540
Francisco Cea Daza 33344555 8-12- Condell 221 M 310 88866555 5
45
Jaime Ramos Salas 88866555 10-11- Vitacura M 360 nulo 1
30 1015
Tabla 3.2: Ejemplo de instancia para la tabla EMPLEADO.
DNOMBRE DNUMERO RUTGERENTE GERFECHAINIC

Of. Central 1 88866555 19-6-71
Administracion 4 98765432 1-1-85
Investigacion 5 33344555 22-5-78
Tabla 3.3: Ejemplo de instancia para la tabla DEPARTAMENTO.
DNUMERO DUBICACION
Captulo 3. Modelo Relacional

1 Providencia
4 noa
Nu
5 La Florida
5 Pirque
Tabla 3.4: Ejemplo de instancia para la tabla UBICACIONES DEPTO.

3.2. Bases de datos relacional
PNOMBRE PNUMERO PUBICACION DNUM
Producto X 1 La Florida 5
Producto Y 2 Pirque 5
Computarizacion 10 noa
Nu 4
Reorganizacion 20 Providencia 1
Tabla 3.5: Ejemplo de instancia para la tabla PROYECTO.
ERUT PNO HORAS

12345678 1 32.5
12345678 2 7.5
33344555 2 10.0
99988777 10 10.0
98765432 10 10.0
98765432 20 15.0
88866555 20 nulo
Tabla 3.6: Ejemplo de instancia para la tabla TRABAJA EN.
ERUT NOMBRE CARGA SEXO FNAC PARENTESCO

33344555 Alicia F 5-4-86 Hija
33344555 Teodoro M 25-10-83 Hijo
33344555 Ximena F 3-5-54 Conyuge
98765432 Rodolfo M 28-2-32 Conyuge
12345678 Alicia F 5-5-57 Conyuge
Tabla 3.7: Ejemplo de instancia para la tabla CARGA.
31
Definici
on Un conjunto de atributos F en el scheme de relaci
on 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 relaci
on R2 . Los atributos F se dice que referencian la
relaci
on 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 relaci
on 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 sem

anticas 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 n
umero 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 Captulo 2 de este documento,
la pregunta es: como obtener este scheme? A saber, se podra obtener de forma analtica
en funcion de la experiencia del dise
nador. Otra alternativa es utilizar una metodologa
matematica como la que se explicar
a en otro captulo. 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 relaci

on agregando la clave primaria de
la entidad a la cual pertenece.
2. Convertir todas las entidades del diagrama en relaciones.
3. Para cada relaci

on del diagrama:
Si es de cardinalidad M:N, crear una relaci

on con las llaves primarias de las
entidades que est
an asociadas, y los atributos propios de la relaci
on si los
tuviera.
Si es de cardinalidad N:1, se debe agregar la llave primaria y los atributos

propios en la relaci
on 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 relaci
on 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 relaci

on, indicar cu
al es su llave primaria mediante la notacion
PRIMARY KEY (lista de atributos).
5. Para cada relaci

on, creada o modificada, agregar cu
ales son llaves externas mediante
la notaci
on FOREIGN KEY (lista de atributos) REFERENCES nombre tabla.
6. Para cada atributo, indicar cu

al es su dominio.
El lector podr
a comprobar que aplicando esta secuencia de pasos se obtiene el scheme
equivalente presentado mas arriba. Mas a
un, si se han seguido todos los pasos se
nalados se
debera 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)
);
N
otese que los nombres han cambiado en relaci
on al diagrama de la Figura 3.1.
Adem
as, los nombres de los atributos no siguen las convenciones dadas en el captulo
anterior. No es necesario detenerse en esto, el ejemplo ha sido transcrito literalmente
desde la fuente y se explicar
a a su debido tiempo las ventajas o desventajas de realizar
esto.
1. Notaci
on: dado el scheme de la base de datos EMPLEADO que aparece en este
captulo responda las preguntas y definiciones que se piden a continuacion:
(a) Para la relaci

on EMPLEADO, describa los dominios de los siguientes atributos:
SEXO y SUELDO.
NPILA, DIRECCION,
(b) Cu
al es el grado de cada una de las relaciones?
(c) Cu
al es el n
umero de tuplas de cada una de las relaciones?
(d) Para la tabla EMPLEADO, cu

al 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 captulo, obtenga el mode-

lo relacional de los problemas presentados en el Captulo 2:
Compa
na de capacitacion.
Vendedores con experiencia.
Compa
na 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 a
no y pas donde se han realizado los mundiales, la estaci
on (invierno, verano,
etc.), el nombre del presidente de la FIFA en ese instante y otros datos.
Los pases participantes y los jugadores de cada seleccion, indicando las carac-
tersticas 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 pas.
Los partidos efectuados, indicando entre que pases y el marcador. Si hubo

definicion a penales, estos se toman como goles del encuentro. Considere la
etapa en que se jug
o el partido (octavos de final, cuartos de final, etc.).
4. Se desea crear una base de datos relacional para la distribuci

on 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, conducci
on de vehculos, etc. Existen Empresas Con-
tratistas que contratan a dichos obreros. A su vez las Compa
nas 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 compa
na
necesita 10 estibadores, 2 conductores y personal de limpieza. Los obreros
s
olo son contratados por las empresas contratistas (solo una). Una empresa
puede estar entregando servicios a varios barcos de distintas compa
nas.
5. Se necesita crear una base de datos relacional para la Municipalidad de Punta Arenas,
que permita llevar la mantenci
on de las empresas contratistas que realizan trabajos
para ella, para lo anterior tome en cuenta lo siguiente:
Las empresas contratistas realizan obras, como ser: pavimentaci

on de calles,
mantenci
on de edificios, mantenci
on de computadores, etc. Las empresas tienen
empleados que realizan un solo tipo de labor (ingeniero, operario, soldador,
capataz, etc.), los cuales est
an 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

seg
un obra, el listado de obras que est
a ejecutando una empresa, en cu
antas
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 dise

no 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 s
olo
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 especfica. Listado de vendedores y los
pasajes que ha vendido. Otros datos interesantes son: caractersticas de los buses
(marca, peso, capacidad, etc.); y direccion de llegada de los destinos.
7. Un empresario due
no de un Pub le solicit
o a su empresa redise
nar 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 u
nica actividad como
barman, mesero, limpieza, etc. Los meseros atienden las mesas, las cuales tienen
codigo y alguna otra informacion (puede ser ubicaci
on); 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 atendi
o y el detalle de
los consumos). Los consumos tienen codigos y nombres, como por ejemplo: Ruso
Negro, Clavo Oxidado, Manhattan, etc. Un consumo est
a compuesto por varios
ingredientes; tambien es importante saber cu
ales son sus ingredientes (interesa la
proporci
on 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 clnica con la siguiente informacion:
existen servicios (traumatologa, pediatra, rayos, etc.), usuarios que tienen aten-
ciones en dichos servicios, adem
as medicos y sus especialidades (pediatra, neu-
rologa, etc.; s
olo una especialidad por medico). Cada usuario tiene un k
ardex,
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 k
ardex y sus observaciones.
9. A usted le corresponde ser parte del equipo organizador del Encuentro de Egresados
del Departamento de Ingeniera en Computaci
on. Se le ha solicitado el dise
no de
una base de datos para mantener la informacion concerniente a los egresados (datos
personales y carrera a la que perteneci
o), 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 cu
al es la carrera que estudio el egresado y en que empresa
est
a 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 Inform

atica, 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 est

an clasi-
ficadas por tipos de empresas (p
ublica, privada, ONG, etc.). Adem
as, las em-
presas tambien se categorizan por area, donde una empresa podra pertenecer
a mas de un
area (Salud, Servicios, Comercial, etc.)
10. Un grupo de alumnos del Departamento present

o 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 adem
as tiene atributos como ttulo, autor, editorial, fecha
de publicaci
on, etc. Los lectores (alumnos) tienen un codigo asignado (n
umero de
matrcula) y otros datos como nombre, direccion, a
no de ingreso, etc. Los lectores
pueden llevar libros en prestamo los que se devolver
an en una fecha determinada; es
posible tambien reservar libros. De cada libro puede haber mas de una copia. Se
debe llevar una estadstica de los libros pedidos.
11. Se desea crear una base de datos para la citaci

on de horas en un Policlnico. Tome en
cuenta lo siguiente: existen medicos que prestan un tipo de atencion, como por ejem-
plo pediatra, obstetricia, traumatologa, etc. Existen Usuarios que piden presta-
ciones al Policlnico. Las horas se dan de acuerdo a un calendario fijado, donde se
indica las horas en que atender
a cada medico. Cada cliente y medico tiene su ficha
personal con sus datos.
Captulo 4
MySQL Workbench: herramienta

de dise
no
MySQL Workbench es una herramienta visual de dise

no de bases de datos que integra
desarrollo de software, administracion de bases de datos, dise
no 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 includa 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 captulo se utiliza el material obtenido desde:
http://coba.dc.fi.udc.es/bd/bd2/MySQLWB/tutorialWB.html.
El objetivo del captulo es familiarizar al lector con la herramienta, a

un cuando la
interfaz se puede ver diferente en las versiones mas actuales. Adem
as se intentara explicar
la relaci
on que existe entre los dise
nos obtenidos con la herramienta y los dos modelos
anteriores. En particular, los diagramas de la herramienta son conocidos como diagramas
EER 2
1 Fuente: Wikipedia.
2 El recopilador no est
a seguro si la primera E es por enhanced (mejorado) o extended (extendido).
41
42 Captulo 4. MySQL Workbench: herramienta de dise
no
4.1 Introducci
on a MySQL Workbench
MySQL Workbench es una aplicaci

on para el dise
no y documentaci
on de bases de datos
(sucesora de la aplicaci
on 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 alg
un ambito,
pero la version open source es mas que suficiente para la realizaci
on 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 dise
nar el diagrama EER, implement
andolo sobre la herramienta y a partir
de el obtener el diagrama del esquema relacional. Todo esto se realiza de manera gr
afica
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 C
omo crear un diagrama EER?
En general, el trabajo con MySQL Workbench comenzar

a 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 Creaci
on 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 men
u en
4.2. C
omo crear un diagrama EER? 43
Figura 4.1: Interfaz de inicio para MySQL Workbench.
Figura 4.2: Interfaz de creaci

on 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.
no
Figura 4.3: Tabla recien creada.
Figura 4.4: Men

u Tabla de MySQL Workbench.
En la pesta
na Columns del Men
u 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 a
nade la restricci
on NOT NULL para un atributo.
AI es para campos de tipo Auto Increment.
ColumnDetails.Flags se utiliza para a

nadir la restriccion de clave primaria o Primary
Key.
Para agregar una nueva columna s

olo es necesario hacer doble click en la fila que va a
continuacion de la u
ltima a
nadida (se
nalada con un punto rojo en la Figura 4.5).
Figura 4.5: Pesta

na Columns.
4.2. C
omo crear un diagrama EER? 45
Al seleccionar la opcion PRIMARY KEY se est

a 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 Creaci
on 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 Men
u Relaciones para crear los tipos de relaci
on
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 relaci
on)
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 relaci
on N:M.
Figura 4.6: Men

u Relaciones.
Existen al menos dos formas diferentes de crear relaciones entre tablas: a traves del
Men
u Tabla o usando el Men
u Relaciones. Para el caso 1:1 y 1:N se recomienda utilizar
el Men
u Tabla, con el cual se siguen los siguientes pasos:
1. Doble click sobre la entidad del lado N de la relaci

on.
2. Crear los atributos que van a hacer la funcion de clave foranea ( si no est
an 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 men
u de tabla, desplegar la pesta
na 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.

no
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 for
anea.
Foreing Key Options es u

til 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: Men

u Foreign Key.
Para el caso de relaciones N:M se recomienda el uso del Men

u Relaciones. Los pasos a
seguir son los siguientes:
1. Las tablas deben estar creadas.
2. Se elige en el men
u de la izquierda el tipo de relaci
on que se desea.
3. Click en la tabla que representa el lado N de la relaci

on 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 aplicaci
on es su capacidad para exportar los diagramas hacia un script
de MySQL, o hacia im
agenes en formato PNG o PDF. Mas adelante se volvera
sobre esta herramienta para estudiar otras de sus caractersticas, considerando
los conceptos que son necesarios estudiar para su aplicacion.
4.3. Ejemplo de aplicaci
on 47

on
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
ver
a como en la imagen de la Figura 4.8.
Figura 4.8: Ejemplo de aplicaci

on.
Se comenzar
a primero con la tabla DEPT y luego con la tabla EMP. Los pasos a seguir
se detallan a continuacion:
1. Click en el icono se
nalado 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. A
nadir los atributos a la tabla: en la pesta
na Table se cambia table1 por el nombre
DEPT; en la pesta
na Columns se a
nade una a una las columnas de la tabla (ver
Figura 4.10). N
otese que est
a 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 restricci
on de clave foranea en la tabla EMP. Para esto se puede realizar lo
siguiente: a
nadir una columna mas a la tabla EMP con el nombre de DEPT; hacer
no
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 pesta

na Foreing keys, aqu se indica
el nombre de la restricci
on (FK DEPTNO) y la tabla a la cual hace referencia dicha
clave (DEPT) ver Figura 4.12. Luego, se indica cu
al 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 for

anea a tabla EMP.
De forma alternativa, la restricci

on de clave foranea se puede realizar utilizando el
Men
u Relaciones. En este caso se debe seleccionar en el Men
u 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 Men

u Relaciones.
1. Utilizando la herramienta MySQL Workbench obtenga los diagramas EER para los
problemas presentados en el Captulo 2:
Compa
na de capacitacion.
Vendedores con experiencia.
Compa
na de videos.
Los Arcoch.
no
2. Implementar con la herramienta MySQL Workbench el diagrama EER equivalente

para la base de datos mostrada en la Figura 4.15.

Captulo 5

Algebra Relacional
Junto con el modelo relacional del Captulo3, Codd tambien present

o un conjunto de ope-
raciones que permiten describir la forma en que se puede obtener una respuesta para una
consulta especfica sobre las relaciones definidas: este conjunto de operadores se denomina
Algebra Relacional.
Aunque en este captulo 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 captulos precedentes. As, aunque los operadores hayan sido definidos para un
modelo particular, su aplicaci
on es v
alida para los dem
as. La equivalencia entre conceptos
se puede ver en la Tabla 5.1.
Modelo E-R Modelo Relacional Modelo EER

entidad relaci
on tabla
relaci
on relaci
on tabla
atributo atributo columna
atributo multivaluado relaci
on tabla
dominio dominio tipo de dato
clave primaria clave primaria clave primaria
clave candidata clave candidata ndice
clave externa clave externa clave externa
Tabla 5.1: Equivalencia entre conceptos.
51
52
Captulo 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 relaci

on tiene un sentido mas general y
matematico. En matematicas, una relaci
on se define como un subconjunto del producto
cartesiano entre un conjunto de dominios. Cada tupla (fila) de una relaci
on 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 relaci

on se le llama esquema de la relaci
on 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 act

uan sobre relaciones completas y generan como
resultado otra relaci
on. 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.
1 De ah el nombre del modelo.

5.2. Algebra relacional 53
5.2.1 Operadores fundamentales
Uni
on Si R y S son relaciones, entonces R S denota al conjunto de tuplas que est
an
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 B
a1 b1
a2 b2
a3 b3
Tabla 5.2: Relaci

on generica R.
A B
a2 b2
a3 b3
a4 b4
Tabla 5.3: Relaci

on generica S.
A B
a1 b1
a2 b2
a3 b3
a4 b4
Tabla 5.4: Resultado de R S.
Diferencia Si R y S son relaciones, entonces R - S denota al conjunto de tuplas que

est
an en R y no est
an 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 B
a1 b1
Tabla 5.5: Resultado de R - S.
A B
a4 b4
Tabla 5.6: Resultado de S - R.
2 Una condicion menos restrictiva podra indicar que sean id

enticos s
olo en relaci
on al dominio, como
ocurre en la implementacion de MySQL.
3 En este caso es imprescindible que sea as.
54
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 relaci
on
resultante cada tupla de R aparece con todas las tuplas de S. Ver Tablas 5.7, 5.8
y 5.9.
C D
c1 d1
c2 d2
Tabla 5.7: Relaci

on generica T.
E F
e1 f1
e2 f2
Tabla 5.8: Relaci

on generica U.
C D E F
c1 d1 e1 f1
c1 d1 e2 f2
c2 d2 e1 f1
c2 d2 e2 f2
Tabla 5.9: Resultado de T U.
Proyecci
on Si W es una relaci
on con atributos v1 , v2 , . . . , vn , entonces la proyecci
on
denotada por v ,v ,v
i j k
(W ) es el conjunto de valores vi , vj , vk para cada tupla de W.
Ver Tablas 5.10, 5.11 y 5.12.
C D E F
c1 d1 e1 f1
c1 d1 e2 f2
c2 d2 e1 f1
c2 d2 e2 f2
Tabla 5.10: Relaci

on generica W.
C
c1
c2
Tabla 5.11: Resultado de C (W ).

5.2. Algebra relacional 55
D F
d1 f1
d1 f2
d2 f1
d2 f2
Tabla 5.12: Resultado de D,F (W ).
Selecci
on Si W es una relaci
on con atributos v1 , v2 , . . . , vn , entonces la seleccion denotada
por (W ) es el conjunto de tuplas de W que satisfacen la condici
on . La condici
on
se construye con operadores l
ogicos o relacionales. Ver Tablas 5.13 y 5.14.
C D E F
c1 d1 e1 f1
c1 d1 e2 f2
Tabla 5.13: Resultado de C=c1 (W ).
C D E F
c1 d1 e2 f2
Tabla 5.14: Resultado de C=c andD=d andF 6=f

1 1 1 (W ).
5.2.2 Operadores derivados
Intersecci
on Si R y S son relaciones, entonces R S denota al conjunto de tuplas que
est
an en R y tambien est
an en S. Esto es equivalente a realizar las siguientes opera-
ciones: R - (R - S). El lector puede comprobar que esta operaci
on si es conmutativa
a pesar de estar definida sobre una que no lo es. Como est
a 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 B
a2 b2
a3 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 condici
on despues de haber realizado el producto cartesiano entre ambas
relaciones, i.e, es equivalente a las siguientes operaciones: (T U ). Ver Tabla 5.16.
56
C D E F
c1 d1 e2 f2
c2 d2 e2 f2
E6=e1 U.
Tabla 5.16: Resultado de T
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 operaci
on join natural es equivalente a las siguientes
operaciones:
x ,x ,...,x ( V.y =W.y

1 2 n 1 1 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. N
otese que y1 , y2 , . . . , ym es un
subconjunto de x1 , x2 , . . . , xn . Ver Tablas 5.17, 5.18 y 5.19.
C
c1
Tabla 5.17: Relaci

on generica V.
C D E F
c1 d1 e1 f1
c1 d1 e2 f2
c2 d2 e1 f1
c2 d2 e2 f2
Tabla 5.18: Relaci

on generica W.
C D E F
c1 d1 e1 f1
c1 d1 e2 f2
Tabla 5.19: Resultado de V

W.
Cuociente Sea W una relaci

on con un esquema w[x1 , x2 , . . . , xn ] y V una relaci
on con
un esquema v[xi , xj , . . . , xm ] donde v w. La operaci
on W V es una relaci
on
con un esquema z[{xk }] tal que 1 k n k 6 {xi , xj , . . . , xm }. El resultado de
la operaci
on son aquellas subtuplas de W con esquema z tales que sus valores est
an
relacionados con todas las tuplas de V. La operaci
on cuociente es equivalente a las
siguientes operaciones:
5.3. Nota final 57
x l+1 ,...,xn
(W) - x l+1 ,...,xn
(( xl+1 ,...,xn (W) V) - W),
donde xl+1 , . . . , xn representa los atributos de W que no est

an presentes en el es-
quema de V. Esta operaci
on se puede visualizar como la operaci
on inversa al producto
cartesiano. Ver Tabla 5.20.
D E F
d1 e1 f1
d1 e2 f2
Tabla 5.20: Resultado de W V.
5.3 Nota final
Como el lector debera haber deducido, toda operaci

on del algebra relacional produce como
resultado otra relaci
on. De forma conceptual, una operaci
on que no produce tuplas es una
relaci
on con cero elementos o relaci
on vaca. Por ejemplo, en la Tabla 5.21 se muestra el
resultado de la operaci
on C=c 3
(W), la cual se representa s
olo por su encabezado.
C D E F
Tabla 5.21: Resultado de C=c 3 (W). Ejemplo de relaci

on vaca
Si no se satisfacen las condiciones para realizar una operaci

on, no existe una relaci
on
resultado. Por ejemplo, la operaci
on V W no produce ning
un 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 comisi
on
sea igual a 10%.
(b) Mostrar el rut y el nombre de todos los vendedores.

58
(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, patologa).

CONTRAINDICACION( codigo medicamento, codigo contraindicaci
on).
(a) Nombre de todos los medicamentos para el resfro com

un 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, a

no, genero).
CLIENTE( rut, nombre, fono, direccion).
ARRIENDO( codigo, rut, fecha, fecha devolucion).
(a) Cu
ales fueron las pelculas que se arrendaron en diciembre de 2014?
(b) Mostrar el rut y el nombre de los clientes que han arrendado pelculas del genero
Accion.
(c) Mostrar el nombre de las pelculas que no tuvieron salida entre enero y febrero
de 2015.
SERVICIO( n
umero, nombre).

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

FICHA DIAGNOSTICO( rut, fecha, n
umero, diagnostico).
(a) Nombre de los servicios que no han atendido usuarios en los u

ltimos 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, a

no).

INSCRIPCION( rut, codigo, semestre, a
no, 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, ttulo, 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 Dise
no de Bases de Datos Relacionales.
60
(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( n
umero, tipo, rut, fecha apertura, fecha u
ltimo movimiento, saldo).

DEPOSITO( codigo, n
umero, monto, fecha, sucursal).
GIRO( codigo, n
umero, monto, fecha, sucursal).
CLIENTE( rut, nombre, apellido, direccion, fono, ciudad, fecha nacimiento).
(a) Listado de clientes que realizaron depositos en septiembre de 2014.
(b) Cu
antos clientes est
an 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 da de hoy?

Data Base Design

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Data Base Design

Загружено:

Авторское право:

Доступные форматы

Dise

Punta Arenas, julio 2014

Este libro es una recopilaci

4 MySQL Workbench: herramienta de dise

1.1 Modelo de datos y sus posibles implementaciones . . . . . . . . . . . . . . . 5

2.1 Diagrama E-R de la base de datos EMPRESA . . . . . . . . . . . . . . . . . . 13

3.1 Diagrama E-R de la base de datos EMPRESA . . . . . . . . . . . . . . . . . . 33

4.1 Interfaz de inicio para MySQL Workbench . . . . . . . . . . . . . . . . . . . 43

1.1 Tabla de alumnos y notas sin normalizar . . . . . . . . . . . . . . . . . . . . 3

3.1 Ejemplo de instancia para la relaci

5.1 Equivalencia entre conceptos . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Una base de datos es una colecci

La importancia de almacenar, manipular y recuperar la informacion en forma eficiente

Considerese el siguiente ejemplo: Se desea almacenar la informacion de los alumnos de

Se pueden observar las siguientes desventajas:

Se repiten varios datos, como el nombre del alumno, su n

Si se desea modificar el nombre de una persona, entonces se debe buscar en toda la

Tabla 1.1: Ejemplo de c

En el enfoque de bases de datos se mantiene un u

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-

Permite que uno o mas usuarios puedan accesar simult

1.1 Modelos de datos y definiciones

Los principales objetivos del proceso de modelamiento es saber identificar cu

El modelamiento de datos es independiente de hardware o software usado para su

Figura 1.1: Ejemplo de un modelo Entidad-Relaci

archivos, metodos de acceso, ndices, etc. En un DBMS, el nivel fsico es transparente

Nivel de Vistas Es un subconjunto del nivel conceptual. A determinados usuarios de

Desde estos enfoques se tiene lo siguiente: una instancia es el contenido de la base de

Independencia de datos fsica: es posible alterar la implementaci

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-

Lenguaje de Definicion de Datos (DDL por Data Definition Language).

Recuperar informacion (consultas a la base de datos).

Modificar la informacion almacenada (actualizaciones).

1.2.2 Usuarios de una base de datos

Realiza la definicion y modificaci

Define las estructuras de almacenamiento y los metodos de acceso a los datos.

Asigna los tipos de autorizaciones de acceso a la informaci

1.2.3 Estructura fsica de un DBMS

Desde el punto de vista fsico, el DBMS proporciona las siguientes herramientas:

Administrador de Archivos Se encarga de las operaciones de almacenamiento en el

Administrador de la Base de Datos Es la interfaz entre al administrador de archivos

Preprocesador de Consultas Traduce las consultas a instrucciones que el admi-

Precompilador de DML Convierte instrucciones de DML a invocaciones a funciones

Juntando todo, una visi

Figura 1.2: Visi

personas con el mismo nombre.

Considere el siguiente ejemplo sobre el supuesto que se est

2. Cada departamento controla un cierto n

4. Se desea conocer las personas dependientes (cargas familiares) de cada empleado

Figura 2.1: Diagrama E-R de la base de datos EMPRESA.

Figura 2.2: Diagrama E-R de la base de datos de inscripciones y notas.

2.1 Tipos de atributos

instancias particulares no se representan en este modelo. Respecto a los atributos, estos

Los atributos compuestos que se pueden dividir en subpartes mas peque

Respecto a los atributos compuestos, aunque no es com

Figura 2.3: Ejemplo de la jerarqua de descomposici

debe pensar de forma implcita en ellos cuando est

2.2 Tipos de relaciones

Relaciones Uno a Uno (1:1) Una instancia de la entidad A est