Módulo 3
DISEÑ O DE B ASE DE DATOS
Introducción
5. DIAGR AMA EN TIDAD - R ELACIÓN
5.1 Introducción a los diagramas entidad-relación (DER)
5.2 Relaciones básicas
5.3 Condicionales
5.4 Vinculación entre tablas
6. CON STR UCCIÓN DE DER
6.1 Ejercicios relacionales simples
6.2 Ejercicios con condicionales
CIER R E DEL MÓDULO
Descarga del contenido
18
Introducción
Base de datos - MÓDULO 3
EaD Kennedy
02:59
En este módulo nos adentraremos en la construcción de un DER, teniendo en cuenta los conceptos de
tablas y campos, fortaleciéndolo con claves primarias y foráneas, para terminar con los distintos tipos de
relaciones según su modalidad. Por último, trabajaremos diversas problemáticas para su comprensión.
Objetivos del modulo
Diseñar una base de datos con todas sus tablas, campos y relaciones.
5.1 Introducción a los
diagramas entidad-relación
UNIDAD 5 (DER).
Diagrama entidad-relación 5.2 Relaciones básicas.
5.3 Condicionales.
5.4 Vinculación entre tablas.
6.1 Ejercicios relacionales
UNIDAD 6 simples.
Construcción de DER 6.2 Ejercicios con
condicionales.
C O NT I NU A R
28
5.1 Introducción a los diagramas entidad-relación
(DER)
Los diagramas entidad-relación nos permiten ver la estructura completa de una base de datos, es el
esqueleto que presenta todas las tablas con sus características y relaciones. Estos diagramas se analizan
profundamente para que la construcción sea eficiente, y una vez puesta en marcha, no haya redundancia de
datos y problemas de faltantes.
Para tal fin, se analizan cada una de las relaciones posibles entre las tablas, de manera individual, para que,
en el diagrama general, queden expuestas todas con su necesidad. Esto es muy importante a la hora de la
construcción, y luego en su utilización.
DER
El DER representa el diseño completo de la base de datos (Elmasri y Navathe, 2007), que incluye tanto las
tablas, como sus campos y las relaciones entre ellas. Iniciando con las tablas, tal como observamos en la
figura 1, vamos a colocar el encabezado con el nombre de la tabla y, luego, debajo todos los campos que van
a acompañar.
Figura 1. Tabla clientes. Elaboración propia.
Cada tabla va a contener diversos campos, y al menos uno de ellos va a tener la sigla PK, que significa
Primary Key o Clave Primaria. El significado de clave primaria es que ese campo o conjuntos de campos van
a permitir que cada registro sea único e irrepetible y que, por lo tanto, cada fila sea única. Por ejemplo: en la
tabla clientes colocamos el número, que seguramente se va a configurar como autonumérico (que significa
que con cada registro que se ingresa, el campo número se incrementa en 1). Por lo tanto, no van a existir dos
números 30. Lo que se coloca, puede ser también un conjunto de campos porque hay tablas que requieren
más de uno. Si tomáramos una tabla denominada detalle de factura y llevara más de un ítem, tendría que
llevar la clave primaria número de factura y también el número de producto. De esta manera cada registro es
único e irrepetible.
Existe un segundo concepto que es FK, denominada Foreign Key o Clave Foránea, esto significa que una
tabla puede tener un campo foráneo (que es una clave de otra tabla) y que permite esta vinculación. Por
ejemplo: si hay una tabla denominada clientes y otra con tipo de clientes, y se asigna un tipo de cliente a
cada cliente, el tipocliente_numero estará como foráneo en clientes.
En cuanto a la modalidad de las relaciones entre tablas, existen dos: la obligatoria (que es una relación que
siempre existe, no puede haber un registro que no presente una relación con otro registro de las tablas
relacionadas) u optativa (estas son vistas como condicionales, donde puede haber registros que no se
vinculen a registros de la otra tabla).
Por otro lado, hay un concepto que es muy importante y se denomina integridad referencial, que define que
no puede haber claves foráneas nulas. Cuando una tabla posee un campo foráneo, siempre debe tener un
valor de vinculación a la otra tabla. Si hay un inconveniente ahí, hay una mala construcción de la base de
datos con respecto a la modalidad obligatoria y optativa. Otro concepto es el de campo multivaluado, que
significa que no puede existir un campo que en un registro deba tener más de un valor. Es por ello que se
pasa a otro tipo de relación que se verá en las básicas.
La figura 2 muestra un DER tradicional que muestra una relación entre las tablas de clientes y barcos. La
misma se da con una clave foránea en clientes de barco_numero. Estas relaciones se analizarán en el
próximo punto.
Figura 2. DER tradicional. Elaboración propia.
Esquema de Procesamiento de datos
La imagen muestra la construcción de un DER en la herramienta Workbench. Las relaciones se reflejan con
líneas firmes o punteadas según la modalidad. Por otro lado, están las PK con llaves doradas, las PK/FK con
llaves rojas, las FK con rombos rojos y los campos no claves con rombos celestes.
Figura 3. DER realizado con Workbench. Elaboración propia.
Modelado de datos
En el siguiente video, se explica paso a paso como se diseña un DER con la herramienta Workbench.
Modelado de datos
JKSistemas
08:39
KJSistemas (2016). Modelado de datos [Video]. Vimeo. https://vimeo.com/179785459
C O NT I NU A R
38
5.2 Relaciones básicas
Las relaciones básicas son tres y cumplen con la clasificación de relaciones con modalidad obligatoria, por
ende, todos los registros están vinculados. A través de ejemplos, vamos a poder observar cada una de ellas.
Relación uno a uno
Para ejemplificar esta relación, utilizamos competidores y barcos, tomando en cuenta que, en una
competencia, cada competidor se presenta con un único barco. Asimismo, el barco se representa con un
único competidor. A modo gráfico, en la figura 4, vemos cómo se representa la relación, donde de cada lado
se realizan dos líneas. Por otra parte, en este tipo de relaciones, la FK puede estar en cualquiera de las dos
tablas. Se coloca en base al análisis de los tipos de consultas realizados. Esto se da porque en ninguno de
los casos se da el concepto de campo multivaluado, que no puede existir nunca.
Figura 4. Relación 1:1. Elaboración propia.
Relación uno a muchos
Para ejemplificar esta relación, utilizamos sectores y empleados, tomando en cuenta que un sector posee
muchos empleados, pero un empleado trabaja en un único sector. A modo gráfico, en la figura 5, vemos
cómo se representa dicha relación. Por otra parte, en este tipo de relaciones, la FK se coloca en empleados,
ya que cada empleado se representa con un único sector. Si se coloca en sectores es incorrecto, ya que
tiene varios empleados y la FK quedaría múltiple (no permitido).
Figura 5. Relación 1:M. Elaboración propia.
Relación muchos a muchos
En este caso, tomamos como ejemplo a proveedores y artículos. Un artículo puede ser adquirido por más de
un proveedor y un proveedor proveer más de un artículo. En la relación muchos a muchos, se debe crear una
tabla intermedia, que tendrá como clave las de ambas tablas (ver Figura 6). Asimismo, puede o no tener
campos adicionales (en este caso el precio de compra). Esto sucede debido a que, si se coloca la FK en
alguna de las dos tablas, quedaría FK múltiple y no se puede realizar.
Figura 6. Relación M:M. Elaboración propia.
C O NT I NU A R
48
5.3 Condicionales
Por otro lado, nos encontramos con relaciones de modalidades opcionales, esto indica que hay registros que
no tienen que estar necesariamente vinculados a otra tabla. Existen varias relaciones que se verán a
continuación.
Relación uno a uno condicional
El ejercicio de la figura 7 presenta que un departamento tiene un supervisor (uno solo). Sin embargo, un
supervisor puede, o no, tener asignado un departamento. En este caso, la FK se coloca en departamento,
ya que, con el concepto de integridad referencial, no pueden existir FK nulas. Por lo tanto, si se coloca en
supervisores y no tiene asignado un departamento, queda nulo.
Figura 7. Relación 1:1C. Elaboración propia.
Relación uno a muchos condicional
Para esta situación, ponemos como ejemplo lo que se observa en la figura 8 que muestra que un área
puede no tener artículos, uno o muchos. Asimismo, un artículo pertenece a una única área. La solución a
dicha relación se realiza colocando la FK en artículos, ya que, al tener una única área, nunca puede
quedar nula o ser múltiple. En el caso inverso sucede lo del ejemplo anterior, si áreas lleva la FK puede
ser nula o múltiple.
Figura 8. Relación 1:MC. Elaboración propia.
Relación de muchos a uno condicional
Para esta relación utilizamos como ejemplo, tal como se observa en la figura 9, que un ciudadano puede
o no tener una obra social (no puede tener más de una), mientras que una obra social puede brindarle
servicios a más de un ciudadano. En este caso, se necesita la tabla intermedia, ya que, si se coloca la FK
en ciudadanos, puede quedar nula. En cambio, si se coloca en obras sociales, puede quedar FK múltiple.
Figura 9. Relación M:1C. Elaboración propia.
Relación muchos a muchos condicional
Para esta relación, presentamos como ejemplo que un curso puede no tener alumnos (sin inscriptos),
como así también uno o muchos. Un alumno tiene al menos un curso asignado por política de
matriculación, también puede estar en más de uno. En este caso, se necesita de una tabla intermedia, ya
que, si colocamos la FK en cursos, puede quedar nula si no posee alumnos o múltiple si hay más de uno
(ver Figura 10). Por el contrario, si la colocamos en alumnos, si tiene más de un curso, la FK queda
múltiple.
Figura 10. Relación M:MC. Elaboración propia.
Relación muchos condicional a muchos condicional
El ejemplo de la relación bicondicional, que se observa en la figura 11, nos muestra que una persona
puede o no tener vehículo y que si posee puede ser más de uno. Lo mismo sucede con un vehículo, ya
que si aún no tiene dueño no tiene persona asignada, mientras que puede estar a nombre de una o más
personas. Al igual que la relación de M:M, se necesita de la tabla intermedia, ya que la colocación de la
clave FK en cualquiera de las dos tablas, genera FK nulas o múltiples.
Figura 11. Relación MC:MC. Elaboración propia.
C O NT I NU A R
58
5.4 Vinculación entre tablas
Luego de haber observado las diferentes relaciones que existen entre las tablas, vamos a plantear 2 casos
diferentes, que nos permitirán construir un pequeño DER, a partir de la necesidad del cliente. Para ambos
casos, vamos a establecer las relaciones y el contenido de cada tabla y, en caso de ser necesario, crear
todas las tablas intermedias para su correcta resolución.
Caso A: compañía de vuelos
Se desea construir el DER para el sistema de un pequeño aeroparque, que cuenta con las siguientes
entidades: pasajeros, vuelos y compañías aéreas. El director de la empresa nos brinda la siguiente
información:
No se abren vuelos si no hay, al menos, un pasajero.
Toda compañía cuenta con más de un vuelo.
Los pasajeros pueden tener más de un vuelo.
En la figura 12, nos encontramos con la resolución de dicho relevamiento que, seguidamente, vamos a
explicar paso a paso.
Figura 12. DER de vuelos. Elaboración propia.
Inicialmente, nos indica que van a existir 3 tablas, por eso ya las construimos. En el caso de que no indican
los campos que se necesitan, a fin de un ejercicio, colocamos lo básicos para su resolución. Una vez
colocadas las tres tablas, comenzamos a relacionarlas. La primera es relación vuelos y pasajeros. Nos
indica que no se abre un vuelo si al menos no hay una persona, entonces puede ser 1 o muchas. Por otro
lado, en el tercer punto nos dice que un pasajero puede tener muchos vuelos (viajero frecuente). Es por eso
por lo que nos encontramos con una relación de muchos a muchos, y tal como menciona la relación M:M por
las propiedades que posee, se requiere una tabla intermedia que lleva la/s clave/s de cada tabla vinculada.
Ambas claves van a ser primarias en la intermedia, como también son foráneas, porque proceden de las
principales. El campo asiento se añadió como ejemplo de que se pueden poner campos ahí, dejando
registrado que número de asiento tuvo en cada vuelo la persona.
La última relación (segundo ítem) dice que la compañía tiene más de un vuelo, pero sabemos que un vuelo
es de una única compañía (Aerolíneas Argentinas, Jet Smart, etc.). Por eso ahí hay una relación de 1 a
muchos, donde no se requiere tabla intermedia. La clave foránea de vinculación va en vuelos, porque a un
vuelo se le asigna una única compañía.
Caso B: actividades deportivas
Se debe construir el DER de un pequeño colegio que desea almacenar los datos de los alumnos y su
vinculación a las dos áreas extraprogramáticas que ofrece la institución: actividades deportivas y equipos de
investigación. Como datos fundamentales para la construcción, la directora nos ha informado lo siguiente:
los alumnos pueden integrar un solo equipo de investigación (que es obligatorio); mientras que, por otro lado,
pueden realizar más de una actividad deportiva, destacando que al menos una actividad es de carácter
obligatorio.
En la figura 13, nos encontramos con la resolución. Por lo tanto, a continuación, vamos a explicar la misma.
Figura 13. DER Actividades deportivas. Elaboración propia.
Inicialmente, ya el relevamiento nos está informando que van a existir las tablas alumnos, actividades
deportivas y equipos de investigación. Dentro de lo que comenta la directora, podemos saber que los
alumnos solo pueden estar en un equipo, y que, a su vez, no pueden no pertenecer a alguno de ellos. Por
lógica de equipos, un equipo puede tener más de un integrante, entonces nos encontramos con una relación
de 1 a muchos. Por lo tanto, para cumplir con la teoría de que no puede haber valores multivaluados, la clave
foránea va en alumnos.
Como segunda instancia, también es obligatorio que hagan una actividad deportiva, pero la diferencia está
en que pueden hacer más de una. Por ende, una actividad va a tener muchos alumnos y un alumno puede
tener más de una actividad. La relación es de muchos a muchos y requiere de una tabla intermedia. Nos
llevamos ambas claves a la tabla intermedia. En el caso de que la situación lo requiera, se puede ir
agregando campos en la intermedia.
Marque la opción correcta. ¿Cuántas son las relaciones básicas?
2
6
SUBMIT
Bibliografía de referencia
Elmasri, R. y Navathe, S. (2007). Fundamentos de Sistemas de Bases de Datos. Madrid: Pearson
Educación.
Bibliografía obligatoria
Elmasri, R. y Navathe, S. (2007). Capítulo 3: “Modelado de datos con el modelo Entidad-Relación
(ER)” (pp. 51-87), Capítulo 5: “El modelo de datos relacional y las restricciones de una base de
datos relacional” (pp. 123-144) y Capítulo 7: “Diseño de bases de datos relacionales por mapeado
ER- y EER-a-relacional” (pp. 189-202). En Fundamentos de Sistemas de Bases de Datos. Madrid:
Pearson Educación.
C O NT I NU A R
68
6.1 Ejercicios relacionales simples
El diseño de las bases de datos presenta cuestiones importantes a tener en cuenta, entre ellas se destaca
la necesidad de contar con la información que brinda la empresa, que tiene que ser clara y precisa. Ante esta
información, se requiere de la capacidad de abstracción (modelar dicha información) del personal
encargado del diseño, para transformar esa información numerosa en un diseño de base de datos. Por
último, es importante comprender los conceptos de claves foráneas nulas y valores multivaluados, con el fin
de evitar tanto inconsistencias como redundancia de datos en un diseño (Elmasri y Navathe, 2007).
A continuación, con el objetivo de recorrer los diferentes aspectos que posee un diseño de base de datos,
plantearemos diferentes ejemplos o situaciones, que abarcan las relaciones entre tablas y la importancia de
contar con información para la construcción.
Ejercicios relacionales simples
Para introducirnos más en las relaciones entre tablas, vamos a colocar dos situaciones que nos permitirán
abordar necesidades, así como resolver las mismas a través de las herramientas de diseño.
Situación A: Biblioteca
Información que se pudo recolectar y presentar en la etapa de relevamiento
La biblioteca “El Libro” se dedica al préstamo gratuito de libro y es subvencionada por el estado para cumplir
con dicho fin. Se desea diseñar una pequeña base de datos y para ello, el director nos ha brindado la
información que desean almacenar para tener en cuenta: en base a los socios, desean almacenar los datos
básicos (identificación, documento, dirección y teléfono de contacto). Por otra parte, desean tener el registro
de los libros que poseen y los volúmenes, ya que cuentan con más de un volumen por libro. Para tal fin,
quieren contar con la identificación de los libros incluyendo el número de libro, título, editorial y año de
publicación, sumado a la identificación del volumen con su número y al estado de este. Como la biblioteca
tiene contacto directo con las editoriales, desean guardar los nombres y teléfonos para poder contactarlas.
Por último, necesitan poseer la información de los préstamos (papel que se emite por cada volumen
retirado), que incluyan la fecha, el socio y el volumen.
Resolución
Vamos a comenzar con la resolución, que está reflejada en la figura 14. Contamos con las tablas de socios,
libros, volúmenes, editoriales y préstamos. Inicialmente, colocamos las 5 tablas y le añadimos los campos
que nos mencionan (sin las relaciones). De esta manera, nos van a quedar todas las tablas y campos que
nos han informado. Luego de esto, comenzamos a ver qué vinculaciones encontramos. Si observamos libros
y volúmenes, nos está diciendo que cada libro posee uno o varios volúmenes. En este punto encontramos
una relación de 1 a muchos. Por ende, volúmenes va a llevar el número de libro como FK. Asimismo, lleva su
número que es el de volumen. Acá nos encontramos con un caso particular, los volúmenes no son
autonuméricos, sino que se reinician en 1 cada vez que cambia de libro. Por ejemplo: libro A tiene volúmenes
1, 2 y 3 y libro B tiene volúmenes 1, 2, 3 y 4. Ante esto, la tabla volúmenes, por el concepto de que la/s
clave/s tienen que detectar un registro único e irrepetible, no pueden tener a número de volumen solamente,
ya que, por lo planteado, van a haber miles de números 1. Por eso, se añade a número de libro como clave
primaria, entonces nos aseguramos de que libro 1 y volumen 1 sean únicos e irrepetibles.
Pasamos a la siguiente relación, encontramos a las editoriales, que pueden tener muchos libros, pero un
libro es de una única editorial. Encontramos una relación de 1 a muchos, donde en libro colocamos el
número de editorial.
Para finalizar encontramos la tabla préstamos, donde comprobante es por un volumen, no libro. Es por ello,
que se genera una relación en la cual un préstamo posee solo un volumen, mientras que un volumen puede
estar en más de un préstamo. En la relación de uno a muchos, colocamos en préstamos las claves de
volúmenes (que cuando hay más de una se tienen que colocar todas sí o sí) porque es la vinculación al
registro único e irrepetible. Esta tabla préstamos también se vincula a un socio, y el socio puede tener más
de un préstamo. Es el mismo caso anterior, la clave de socios se coloca en préstamos, esta vez es una sola
clave.
Figura 14. Resolución de la situación A: biblioteca. Elaboración propia.
Situación B: empresa de cremas
Información que se pudo recolectar y presentar en la etapa de relevamiento
La empresa “EM1000” se dedica a la fabricación de cremas exfoliantes y necesita diagramar una base de
datos que incluya las siguientes entidades: sector, puesto, empleado y esposa. El presidente de la compañía
nos brinda la siguiente información: los sectores están compuestos por muchos puestos y, asimismo, cada
puesto puede tener más de un empleado. Si bien un puesto pertenece a un solo sector, los empleados
pueden trabajar en más de un puesto, ya que son rotativos. Por último, se desea almacenar los datos de las
esposas de cada uno de los empleados que estén casados, con el objetivo de que las mismas formen parte
de las campañas de prueba de los productos.
Resolución
Partiendo de un inicio, ya nos está indicando diferentes tablas que van a ser necesarias. Las mismas son:
sector, puesto, empleado y esposa. El relevamiento no nos está informando campos, por ende, les
colocamos algunos básicos con fines de fortalecer el ejercicio. Luego de colocar las tablas y sus campos
básicos se comienzan a detectar las relaciones. Los sectores tienen muchos puestos de trabajo, pero si
seguimos adelante con el relevamiento, nos indica que cada puesto posee un único sector. La relación en
este caso es de 1 a muchos, donde la clave FK va en puestos, dado que cada uno posee un único sector, no
hay posibilidad de que sea nula o de múltiple valor.
La segunda relación se encuentra entre empleados y puestos, en este caso, la situación es diferente a la
anterior. Los empleados pueden trabajar en más de un puesto, por lo tanto, es una relación de muchos a
muchos. En estos casos no hay otra opción que generar una tabla intermedia, que lleve ambas claves. En el
ejercicio no se presentan campos adicionales, pero dicha tabla intermedia podría tener algún campo como,
por ejemplo: fecha de inicio de actividad (dejando constancia cuando arrancó cada empleado en el puesto
mencionado). No es la fecha de ingreso a la empresa; ya que esa no va dentro del empleado, sino en el
puesto.
Lo último que nos informan que desean almacenar son los datos de las esposas de los empleados, con
fines de prueba de productos. Acá nos encontramos con una relación diferente, dado que un empleado
puede estar casado o no, aunque si sabemos que no puede estar casado en el mismo momento con más de
una mujer. Por lo tanto, si tenemos una tabla de esposas, sabemos que un empleado registrado en la
empresa puede o no estar casado, pero si tenemos en cuenta que una esposa registrada en la tabla
esposas si o si está vinculada a un marido. Por eso encontramos una relación de uno a uno condicional.
Debido a como son dichas relaciones, no se necesita tabla intermedia, porque en esposas siempre va a
haber un marido. Se coloca la clave FK de empleado en esposas y queda resuelto el ejercicio.
Figura 15. Resolución de la situación B: empresa de cremas. Elaboración ad hoc.
C O NT I NU A R
78
6.2 Ejercicios con condicionales
Para fortalecer las relaciones entre tablas con situaciones más complejas, hay que analizar relevamientos
más complejos que presentan relaciones tanto continuas como no. Ante esto, surgen los condicionales, que
son más frecuentes dependiendo la necesidad.
Relevamiento para analizar un teatro
El teatro “Alegría Asegurada” se encuentra en la zona sur del Gran Bs. As y ofrece una gran variedad de obras
teatrales, con una trayectoria de más de 40 años. Desean construir una base de datos que les permita
almacenar la información de su actividad diaria. Para tal fin, nos brindan la siguiente información:
Se desea tener un registro de cada una de las obras, representadas por su número, título, duración en
minutos, género, categoría (ATP, +12 años, etc.) y el director que la ha realizado. Además, desean llevar un
registro de los actores que trabajan en dicha obra, existiendo actores que trabajan en más de una.
Asimismo, el teatro destaca que necesita almacenar los premios que han obtenido las obras, teniendo en
cuenta que los mismos son preestablecidos (Estrella de Mar, Cannes, etc.), y existen premios almacenados
que aún no han sido obtenidos por ninguna de las obras.
Por otra parte, se desea llevar un registro de las funciones por cada obra, teniendo en cuenta que la función
es dependiente a la obra y lleva fecha, hora y estado. Diariamente, se genera un formulario de cartelera, el
cual contiene un identificador, la fecha, un título general y las obras que se ofrecen ese día. Hay que tener en
cuenta que cada obra del día es calificada (imperdible, estreno, etc.), sabiendo que una obra a lo largo de las
diferentes carteleras puede ir cambiando su calificación.
Con el objetivo de recaudar fondos para el mantenimiento del teatro, el mismo cuenta con sponsors que
colaboran para tal fin. Es por ello que una cartelera puede o no tener un sponsor adherido (en el caso de
tenerlo se le asegura que va a ser el único en la cartelera) y un mismo sponsor puede adherirse a más de
una cartelera.
Por último, nos informan que desea almacenar información adicional y se detalla a continuación:
El tiempo que cada actor aparece en las diferentes obras y el rol que cumple (protagonista,
extra, etc.)
La fecha en que una obra ha obtenido cada premio.
La cantidad de espectadores por función y total que ha conseguido cada obra.
El importe que ha abonado cada sponsor en las diferentes carteleras.
Figura 16. Resolución del relevamiento para analizar un teatro. Elaboración propia.
Resolución del caso
Vamos a comenzar dividendo el relevamiento para ir abordándolo y llegar a su resolución, tal como se
observa en la figura 16. El primer párrafo es una introducción, que para la construcción de la base de datos
solo aporta saber el rubro y de qué manera operan. El segundo párrafo dice lo siguiente:
Se desea tener un registro de cada una de las obras, representadas por su número, título, duración en
minutos, género, categoría (ATP, +12 años, etc.) y el director que la ha realizado. Además, desean llevar
un registro de los actores que trabajan en dicha obra, existiendo actores que trabajan en más de una.
Asimismo, el teatro destaca que necesita almacenar los premios que han obtenido las obras, teniendo
en cuenta que los mismos son preestablecidos (Estrella de Mar, Cannes, etc.), y existen premios
almacenados que aún no han sido obtenidos por ninguna de las obras.
Este párrafo nos indica que vamos a iniciar con una tabla de obras, que presenta campos a colocar. En este
punto vamos a considerar que hay determinados campos que se analizan, con el fin de detectar lo que en
normalización se denomina dependencia transitiva. El género, categoría y director son campos que en
realidad se van a repetir en obras, por ende, los creamos en tablas adicionales y después los relacionamos.
En todos los casos como se ve en la figura 16, quedan todas relaciones de 1 a muchos.
Si nos indica que quiere relacionar los actores, que están en una tabla. Acá el inconveniente surge debido a
que una obra tiene más de un actor, y los actores a lo largo de su carrera van a estar en más de una obra.
Ante esto se requiere una tabla intermedia. Hay dos campos que se solicitan que estén en la tabla
intermedia. Uno de ellos es roles, que, si colocamos un texto como rol, va a estar repetido continuamente.
Por eso normalizamos al igual que géneros y categorías. Generamos una tabla de roles y la vinculamos de 1
a muchos, dado que, en una obra, cada actor tendrá un único rol.
La última parte menciona premios y ahí es dónde surge un condicional. Los precios van en una tabla porque
están predefinidos. Un premio va a tener al menos una obra porque de lo contrario no estaría en la base de
datos de la empresa. Sin embargo, una obra puede no haber conseguido premios. Por lo tanto, queda una
relación de muchos a muchos condicional que se resuelve con una tabla intermedia, que añade la fecha del
premio.
El tercer párrafo no indicaba lo siguiente:
Por otra parte, se desea llevar un registro de las funciones por cada obra, teniendo en cuenta que la
función es dependiente a la obra y lleva fecha, hora y estado. Diariamente, se genera un formulario de
cartelera, el cual contiene un identificador, la fecha, un título general y las obras que se ofrecen ese día.
Hay que tener en cuenta que cada obra del día es calificada (imperdible, estreno, etc.), sabiendo que una
obra a lo largo de las diferentes carteleras puede ir cambiando su calificación.
En esta segunda parte, surge la necesidad de contar con la tabla denominada funciones, que va a contener
los datos generales que indica el relevamiento. Hay una observación vinculada a la clave, que menciona que
el número es dependiente. Esto significa que cada vez que cambia la obra, la función arranca de 1. Por el
concepto de clave única e irrepetible, se requiere de una más, y esa es obra.
La cartelera tiene un encabezado y como no puede quedar multivaluado, se abre un detalle de cartelera, ya
que una cartelera tiene muchas obras y una obra tiene muchas carteleras. En vez de llamarlas obras-
cartelera, le pusimos cartelera detalle. En el detalle va cada obra de dicha cartelera y su calificación, que se
normaliza en una tabla aparte y se vincula.
Por otra parte, el cuarto y último párrafo del relevamiento nos brinda la siguiente información.
Con el objetivo de recaudar fondos para el mantenimiento del teatro, el mismo cuenta con sponsors que
colaboran para tal fin. Es por ello que una cartelera puede o no tener un sponsor adherido (en el caso de
tenerlo se le asegura que va a ser el único en la cartelera) y un mismo sponsor puede adherirse a más de
una cartelera.
En esta parte final, surge la tabla sponsors que se vincula de manera condicional. Una cartelera puede o no
tener un sponsor, y uno puede estar en una o más de una. La relación es de uno a muchos. Por lo tanto, esta
relación requiere de una tabla intermedia.
Los puntos de los ítems A, B, C y D, nos indican diferentes campos que se requieren. Hay que interpretar los
mismos para poder colocarlos en las tablas que correspondan. Por ejemplo, cuando se refieren a los actores
y al tiempo que están en la obra, el tiempo tiene que estar vinculado a la tabla de actores-obras. Las fechas,
cantidades e importes se ubican según la necesidad, y lo pueden observar dentro del DER de la figura 16.
Ejercicio de juguetes
En este material, se explica el ejercicio desde el inicio, tomando el relevamiento y construyendo el diseño del
mismo.
EJ1. Relevamiento.pdf
29.7 KB
KJSistemas (2016). Ejercicio 1: Armado de Juguetes.
EJ1. Resolución.pdf
76.1 KB
KJSistemas (2016). Resolución del ejercicio 1.
Resolución Ejercicio DER
JKSistemas
08:42
KJSistemas (2016). Resolución Ejercicio DER [Video]. Vimeo. https://vimeo.com/165766957
Bibliografía de referencia
Elmasri, R. y Navathe, S. (2007). Fundamentos de Sistemas de Bases de Datos. Madrid: Pearson
Educación.
Bibliografía obligatoria
Elmasri, R. y Navathe, S. (2007). Capítulo 3: “Modelado de datos con el modelo Entidad-Relación
(ER)” (pp. 51-87), Capítulo 5: “El modelo de datos relacional y las restricciones de una base de
datos relacional” (pp. 123-144) y Capítulo 7: “Diseño de bases de datos relacionales por mapeado
ER- y EER-a-relacional” (pp. 189-202). En Fundamentos de Sistemas de Bases de Datos. Madrid:
Pearson Educación.
C O NT I NU A R
88
Descarga del contenido
¿Quieres imprimir el contenido del módulo?
Para descargar el contenido del módulo, e imprimirlo, haz clic en el archivo que se encuentra a continuación.
