Examenes Diseño ER Resueltos

EXÁMENES DE DISEÑO RESUELTOS
BD 2015/2016 Modelo E/R

Series de Televisión - Examen de Febrero de 2010
Series de Televisión
La Asociación Española de Espectadores de Series (AEES), ante el auge y la audiencia
obtenida por las series que se están emitiendo en las cadenas de televisión españolas, ha
decidido organizar una web para, entre otras cosas, poner disponible a sus socios, y a los
espectadores en general, toda la información de que disponen sobre series actuales y antiguas.
La información fundamental de las series está constituida por su título, su
nacionalidad, el género a que pertenece y los actores que participan en la misma, así como el
coste total estimado. La AEES desea asignar a cada serie un código único y además, con el fin
de facilitar las búsquedas, se desea estandarizar todo lo relativo al género a que pertenece
(aventura, drama, acción...). Hay que señalar que la misma serie podría estar clasificada en
varios géneros diferentes. Además, sólo para las series españolas desea conocerse su
productora principal (sólo una) y la audiencia media. De las productoras se tiene información
de su nombre, CIF y dirección, así como de si están asociadas a alguna cadena de televisión.
La misma productora podría haber realizado varias series.
Cada serie se organiza en temporadas, que identificaremos con el número de
temporada asociado a la serie (la 1ª temporada, 2ª, 3ª, etc., de la serie “House” o “Perdidos” o
de “Hospital Central”). De cada temporada, además, interesa almacenar el año en que se
terminó de rodar, un breve resumen y el número de episodios que incluye. Cada temporada se
compone de un cierto número de episodios, de los que se desea conocer su número de orden
dentro de la temporada y serie, un título y una pequeña sipnosis.
Lo que más interesa normalmente a los fans de las series son los actores que participan
en la misma. Hay un número de actores fijos en cada serie, de los que se desea conocer su
nombre artístico, sexo, fecha de nacimiento, nacionalidad y el nombre del papel que
interpreta en la serie. Por simplificar se considerará que un mismo actor no puede hacer a la
vez dos papeles distintos en la misma serie y que un actor de los considerados fijos no puede
abandonar la serie temporalmente. Por otra parte, el mismo actor podría haber participado en
varias series. Además, en algunos episodios, no en todos, pueden aparecer actores de fuera del
reparto (normalmente famosos). Estos actores realizan lo que se llama un cameo, es decir, una
aparición esporádica en un episodio. Hay que tener en cuenta que en un episodio sólo puede
haber tres cameos como máximo, pero el mismo actor podría realizar cameos en distintos
episodios en la misma o distinta serie y desea conocerse esta información.
Otro dato representativo para los curiosos es si una serie ha surgido a partir de otra, lo
que se conoce como ser una “spin off” de otra (por ejemplo, “Aida” surgió a partir de “Siete
vidas”); en este caso hay que guardar cuál es la serie original de la que surgió; sólo se
considerará, además, que de una serie puede surgir como máximo otra.
La AEES desea también mantener información de qué cadena de televisión ha emitido
una temporada de una determinada serie y en que periodo de fechas. Dado que estamos
considerando cadenas de televisión a nivel mundial, la misma temporada de una serie podría
haber sido emitida en las mismas fechas por varias cadenas. A su vez, dado lo frecuente de las
reposiciones en las cadenas de televisión, la misma cadena podría emitir la misma temporada
varias veces (obviamente en fechas distintas). De las cadenas de televisión se desea conocer
su nombre y nacionalidad.
Con estas especificaciones debes obtener un diagrama E/R. Representa los

atributos e identificadores de TODAS las entidades y subraya los identificadores. De la
misma forma muestra las asociaciones con sus atributos correspondientes.
Utiliza una sola hoja de examen. Dibuja el diagrama completo en una de las caras
y si necesitas hacer alguna aclaración, hazlo a la vuelta de esa hoja. (3 puntos sobre 10).
2
Series de Televisión - Examen de Febrero de 2010
ESQUEMA E/R
A continuación se muestra una solución, que no es la única posible.
cod_genero
GENERO nom_genero
pertenece a
cod_serie num_episodios
nºtemp
titulo año
nacionalidad cod_serie resumen
coste
consta de
SERIE TEMPORADA
spin-off de
interpretada por
incluye
audiencia_media
papel tiene
cod_serie
SERIE hizo cameo en
3
ESPAÑOLA ACTOR EPISODIO
rodada por cod_serie

cod_actor sexo sipnosis
fecha_nac nºepis tit_epis
nºtemp
nom_artistico nacionalidad
realiza
PRODUCTORA CADENA TV EMISION
asociada a
fecha_fin
CIF direccion cod_cadena nacionalidad cod_serie cod_cadena
nom_prod nom_cadena nºtemp fecha_inicio
Comentarios sobre la solución:

 La asociación entre PRODUCTORA y CADENA TV podría ser de cualquier
conectividad; ya que el enunciado no especificaba nada aquí se ha considerado la
opción más general posible
 Sería conveniente crear una nueva entidad PAIS o NACIONALIDAD para
estandarizar el concepto de nacionalidad, ya que el atributo nacionalidad aparece en
tres entidades (ACTOR, SERIE y CADENA TV). No se ha representado por no hacer
más difícil de entender el diseño.
 Se ha considerado que no es necesario representar una jerarquía de ACTOR, ya que
los actores por sí mismos no pueden clasificarse como fijos y de cameo, sino que
depende de la serie en que trabajen en un momento dado; es más el mismo actor
podría estar trabajando como fijo en unas series y haciendo cameos en otras. No
obstante tampoco se ha considerado como error el representarla.
3
Organización de Aviación Civil Internacional - Examen de Septiembre de 2010
Organización de Aviación Civil Internacional

La Organización de Aviación Civil Internacional (OACI) tiene entre sus objetivos
ayudar a mejorar el control de tráfico aéreo. Desastres naturales, tales como la erupción del
volcán islandés Eyjafalla, o las huelgas frecuentes de controladores, u otro personal de
aviación, repercuten enormemente en la situación del tráfico aéreo dando lugar a un montón
de incidencias de las que se desea tener constancia. Para ayudar a este fin se va a diseñar una
base de datos teniendo en cuenta las especificaciones que se indican a continuación.
Lo primero de que se dispone es la información de todos los aeropuertos del mundo,
con su denominación, la ciudad y el país donde se ubica, el número de pistas de que dispone y
su código IATA (Asociación de Transporte Aéreo Internacional). Dado que el código IATA,
aunque es el más utilizado, se repite para distintos aeropuertos, la OACI asigna a cada
aeropuerto del mundo un código alfanumérico único, que denomina código OACI. La
información de los países y ciudades debe estar perfectamente estandarizada (de hecho la
OACI también asigna códigos a los países y ciudades); debe tenerse en cuenta que una ciudad
puede tener varios aeropuertos y que un aeropuerto sólo corresponde a una ciudad.
Evidentemente, es preciso mantener información del catálogo completo de vuelos del
mundo, que están identificados por el código de la companía aérea que opera ese vuelo y un
número de vuelo. Sobre la compañía aérea de debe conocer, además de su código, su nombre
y si está aliada o no con otras companías (por ej. Iberia está asociada, entre otras, con
American Airlines y con British Airways). También es preciso saber si una companía
pertenece a otra (por ej. Air Nostrum y Vueling pertenecen a Iberia); una companía sólo
puede pertenecer a otra pero puede ser propietaria de varias. Sobre un vuelo concreto del
catálogo de vuelos es preciso saber también el aeropuerto origen, el aeropuerto destino y la
duración aproximada del vuelo.
El mismo vuelo puede operar en distintas fechas, así que se debe mantener
información de todos los vuelos programados con su fecha y hora de salida, nº de pasajeros
previstos y marca y modelo de avión. Es decir, para cada vuelo del catálogo debemos saber
todas las fechas en que se ha programado ese vuelo hasta el día de hoy. Por ejemplo, el vuelo
IB760 de Iberia, entre Madrid y Palma de Mallorca, que tiene frecuencia diaria, aparecerá
asociado a todas las posibles fechas de operación. Debe considerarse que un vuelo no puede
estar programado dos veces el mismo día.
Lo que interesa realmente a la OACI es tener información de qué vuelos se realizan
con y sin incidencias, cuáles se cancelan, si existen aeropuertos cerrados, por qué motivos, y
otros aspectos relacionados. Para satisfacer estas necesidades será preciso saber qué vuelos de
los programados se completaron, cuales sufrieron un siniestro y cuáles se cancelaron. Con el
fin de saber si hubo retrasos en los vuelos completados hay que conocer cuál fue su hora real
de salida (que puede ser diferente de la programada) y cuál la hora real de llegada al destino.
Para los vuelos cancelados es preciso saber la fecha y hora de cancelación y los motivos. Si
un vuelo tuvo un accidente hay que saber el número de victimas mortales, heridos graves y
leves, así como un resumen de las conclusiones de los técnicos sobre el accidente.
Es posible que aunque un vuelo se haya completado no haya aterrizado en el
aeropuerto previsto porque éste estaba cerrado o por otras causas; en este caso hay que saber
en qué aeropuerto aterrizó realmente. También es importante conocer, para cada vuelo
completado, cada una de las incidencias que se hayan podido producir en el vuelo, si es que
las hubo, con una descripción de la misma.
Con respecto a problemas en los aeropuertos hay que saber los períodos (fechas y
horas) en que estuvieron cerrados y por qué motivos fue (niebla, erupción volcán, terremoto,
huelga general, etc.). Con el fin de unificar los motivos existe una lista estandarizada de
4
motivos, que puede también usarse para describir las causas de las cancelaciones de vuelos.
Un aeropuerto puede estar cerrado o un vuelo puede ser cancelado por más de un motivo
diferente.
5
ESQUEMA E/R
cod_ciudad pertenece a
cod_pais nom_pais nom_ciudad asociada con
tiene
Cod_CIA num_pas
PAÍS CIUDAD nom_CIA hora
CIA AÉREA marca
Cod_CIA
cod_OACI dispone de num_vuelo modelo
Cod_IATA opera fecha
nom_aeropto origen de
num_pistas
AEROPUERTO destino de VUELO

VUELO
PROGRAMADO
ha sufrido se convierte
destino por
desvío num_vuelo Cod_CIA duración
Cod_CIA fecha num_vuelo
cod_OACI
CIERRE VUELO
fec_cierre
AEROPTO. COMPLETADO hora_salida
Cod_CIA
num_vuelo
hora_desde hora_llegada
fecha
hora_hasta tuvo
debido a Cod_CIA
VUELO
num_vuelo SINIESTRADO
num_vuelo
fecha INCIDENCIA Cod_CIA
cod_motivo num_inc VUELO fecha vict h_grav resumen
des_motivo des_inc
h_lev
VUELO
MOTIVO fecha_can
CANCELADO hora_can
es causa de
6
Rally de Acá I - Examen de Febrero de 2009
Rally De Acá I
Se desea representar parte de la información necesaria para la organización del Rally
De Acá 2010, que es la primera vez que se organiza. Este rally admitirá en el futuro la
participación de 4 tipos de vehículos (moto, coche, camión o quad), pero en esta primera
edición sólo permitirá la participación de coches.
Casi seis meses antes del comienzo se abre el periodo de inscripción. Los participantes
deben inscribirse formando parte de un equipo. La organización guarda el nombre original del
equipo y la información de los vehículos con los que participará y le asigna un código único
al equipo. De cada vehículo hay que proporcionar su marca y modelo, así como la matrícula.
A cada vehículo la organización le identifica con un número de dorsal único. Cada equipo
puede participar con varios vehículos. En el momento de la inscripción cada equipo debe
proporcionar también, asociada a cada vehículo, información de los competidores, en
concreto, su nombre y primer apellido, número de pasaporte, fecha de nacimiento,
nacionalidad, talla y peso. Hay que tener en cuenta que habrá dos competidores inscritos por
cada vehículo, el piloto y el copiloto y que desea conocerse quien hace cada función. Por otra
parte, cada equipo, debe facilitar también información del personal de apoyo que viaja con el
equipo (asistentes, mecánicos, sanitarios, etc.), en el caso de que los haya. De éstos, basta con
saber nombre y primer apellido, número de pasaporte, nacionalidad y cargo en el equipo para
el que trabaja.
Dos meses antes del comienzo de la competición la organización envía a los
participantes el itinerario del rally, que consta de un cierto número de etapas. Cada etapa se
identifica por un número único, y se conoce la localidad de inicio y de fin y la fecha en que se
realizará. Además, cada etapa se divide en tramos (un máximo de 3), que se identifican por un
número consecutivo dentro de la etapa; se necesita conocer el tipo de tramo y el número de
kilómetros que incluye. Los tramos que se denominan enlaces son tramos de unión entre dos
zonas pero que no puntúan, los tramos que se denomina especiales son tramos cronometrados
y que por lo tanto puntúan de cara a la clasificación. Para cada tramo hay que conocer,
además, la hora inicial de salida y la hora máxima de llegada.
Una vez que empieza la competición, para los tramos denominados especiales hay que
conocer la hora exacta en que debe salir cada vehículo participante (con el fin de hacer el
cronometrado), el tiempo que ha hecho en el tramo, así como si se le asignado alguna
penalización de tiempo.
Diariamente, durante la celebración del rally, hay que mantener información de la
clasificación por etapa. Es decir, hay que saber el tiempo que ha hecho cada vehículo en cada
etapa y el puesto en que ha quedado clasificado. También por cada etapa hay que mantener la
clasificación general, es decir el tiempo total de cada vehículo en la clasificación general y el
puesto en esta clasificación. Al final del rally debe poder consultarse la clasificación general,
tal y como estaba después de cada una de las etapas, por lo que esta información no debe
perderse.
La dureza del rally puede hacer que los vehículos participantes en una etapa sufran
distintas incidencias (averías, accidentes, falta de gasolina, etc). Se debe permitir mantener
información de las incidencias que ha sufrido cada vehículo en cada etapa: en concreto, una
descripción de la incidencia, en qué etapa y en qué kilómetro aproximado de la misma se
produjo y si fue auxiliado por personal de la organización del rally y por quién. A este efecto
se desea mantener información del personal de la organización que realiza estas funciones; de
éstos se desea conocer nombre completo, número de pasaporte, nacionalidad, dirección de
correo electrónico, móvil y persona de la que dependen (algunos organizadores pueden
depender jerárquicamente de otro organizador). Hay que tener en cuenta que el mismo
7
vehículo puede tener varias incidencias en la misma etapa y puede ser (o no) ayudado por una
o varias personas de la organización en cada uno de las incidencias.
Durante la celebración del rally es necesario conocer también qué vehículos han
abandonado, en qué etapa y cuál ha sido el motivo del abandono.
Nota: Puede considerarse que el número de pasaporte es un identificador válido para

cualquier persona relacionada con el rally.

8
ESQUEMA E/R
A continuación se muestran dos soluciones, que no son las únicas posibles y se
comentan algunas otras variantes.
pasaporte
nombre PERSONA
apellido
depende de
nacionalidad
pasaporte
pasaporte
e-mail ORGANIZADOR
pasaporte PERSONAL
fecha_nac COMPETIDOR
móvil APOYO
talla
peso cargo
trabaja con
auxilió en piloto de copiloto de
dorsal sufrida por pertenece a

#etapa INCIDENCIA VEHICULO EQUIPO
km
tiempo disputada por dorsal
descripción puesto marca
sufrida en modelo
tiempo_gral abandonó en #equipo
puesto_gral matrícula nom_equipo
#etapa
fecha hora_salida
motivo
inicio tiempo
ETAPA penalización
fin participó
#etapa dividida en
num_tramo
3
hora_inicial ESPECIAL
hora_llegada
kms TRAMO
num_tramo
tipo #etapa
La principal diferencia con la solución que se muestra a continuación, es que en la

siguiente, como se ha considerado que las incidencias sólo pueden darse para vehículos que
están compitiendo en una etapa, es como si tuviésemos que asociar las incidencias con la
asociación N:M “disputada por” y lo que se ha hecho es transformar esta última asociación en
una entidad dependiente PARTICIPANTE_ETAPA para poder colgar de ella las incidencias
(que luego se asocian con ORGANIZADOR). Esto permite validar por el propio esquema que
sólo pueden existir incidencias para vehículos participantes en una etapa. Lo que no sería
correcto es en la solución anterior cambiar simplemente la asociación N:M “disputada por”
por una entidad dependiente sin más, ya que un vehículo con una etapa sólo se relaciona una
vez, y, por tanto, ninguno de los atributos de tiempos o puestos son multivaluados.
También es posible representar como un subtipo de VEHICULO los ABANDONOS y

luego asociar esta entidad con ETAPA. No sería correcto, sin embargo, poner una entidad
dependiente de VEHICULO, ya que un vehículo sólo puede abandonar como máximo una vez
y no n veces.
Las asociaciones “piloto de” y “copiloto de” pueden también representarse como una
sola asociación 1:N (con cardinalidad 2) y un atributo “puesto” si bien, semánticamente
quedan mejor representadas de la manera que se indica, ya que con la otra representación se
permitiría que un vehículo tuviese 2 pilotos o 2 copilotos. Es también posible representar dos
9
subtipos de COMPETIDOR, PILOTO y COPILOTO, lo que haría desaparecer las

opcionalidades de las asociaciones. Sin embargo, esto no se ha considerado necesario, ya que
serían entidades que no tendrían atributos propios.
pasaporte
depende de nombre PERSONA A
apellido
nacionalidad
pasaporte pasaporte
e-mail ORGANIZADOR
móvil
pasaporte
COMPETIDOR PERSONAL
fecha_nac
auxilió en APOYO
dorsal talla
#etapa peso cargo
km trabaja con
INCIDENCIA piloto de copiloto de
descripción
pertenece a
dorsal sufrida por
#etapa VEHICULO EQUIPO
tiempo es un dorsal
puesto PARTICIPANTE marca
tiempo_gral modelo
ETAPA #equipo
nom_equipo
puesto_gral abandonó en matrícula
#etapa hora_salida
disputó motivo
fecha tiempo
inicio penalización
fin
ETAPA
#etapa participó
num_tramo dividida en
hora_inicial
3
ESPECIAL
hora_llegada
kms
tipo
TRAMO num_tramo
#etapa
10
El colegio de mi barrio - Examen de septiembre de 2009
El Colegio de mi barrio
Un colegio concertado que imparte todas las etapas educativas desde educación
infantil a bachillerato desea organizar toda la información de que dispone para lograr una
eficiente gestión de alumnos, cursos, profesores y asignaturas. Los supuestos que quieren
recoger inicialmente se especifican a continuación.
Cuando un alumno ingresa en el colegio se deben facilitar sus datos personales
(nombre, apellidos, sexo y fecha de nacimiento), así como la dirección completa y el teléfono
del domicilio familiar; el colegio le asigna un número de expediente único que se mantendrá a
lo largo de toda su etapa escolar. Así mismo, dado que los alumnos son habitualmente
menores de edad, se debe recoger información de al menos uno de los padres o bien de un
tutor del alumno. Para los padres (o en su caso para el tutor) debe conocerse su dni, nombre y
apellidos, fecha de nacimiento, profesión y un teléfono de contacto. También debe conocerse
el tipo de relación que le une al niño, es decir, si la persona es el tutor o el padre o la madre.
Además de la información anterior, si un alumno sufre algún tipo de enfermedad, alergia o
tiene algún grado de discapacidad debe reflejarse también, especificando una descripción de
la misma y si se requiere algún tipo de atención especial en el colegio.
La educación en el colegio se organiza en torno a las distintas etapas educativas
(infantil, primaria, secundaria y bachillerato), las cuales se identifican con un código. Cada
etapa educativa se compone de una serie de cursos identificados por un número asociado a la
etapa educativa a la que pertenece (1º de infantil, 2º de primaria...); además se guarda una
descripción general del curso. Para cada curso se desea tener almacenados una serie de
objetivos de aprendizaje que deben alcanzarse en ese curso (por ej. escribir las vocales,
conocer los números del 1 al 10 o aprender a sumar con una cifra); estos objetivos son
particulares de cada curso y aunque pueden parecerse, no pueden repetirse para distintos
cursos. Para cada objetivo, habrá de almacenarse una descripción.
El colegio sólo tiene concedida una línea, es decir, por cada curso hay un único grupo
en el que puede haber un máximo de 25 alumnos.
Con respecto al profesorado, se debe mantener información personal del mismo (dni,
nombre y apellidos, fecha de nacimiento, dirección y teléfono), así como titulación que posee,
el tipo de contrato, la cuenta corriente para el ingreso del salario, y el número máximo de
horas que puede impartir. Hay que tener en cuenta que casi todos los profesores traen a sus
hijos a estudiar a este mismo colegio en el que trabajan. Algunos profesores realizan la
función de tutor responsable de un curso (como máximo de uno) y esta información debe
conocerse; tengáse en cuenta que un curso sólo tiene un profesor tutor.
Desde el punto de vista de la docencia, los profesores en el colegio están agrupados en
departamentos (matemáticas, lengua y literatura, idiomas, etc.) y cada profesor sólo puede
pertenecer a uno de los departamentos. Cada departamento se encarga de organizar un grupo
de asignaturas, de las que se conoce un código único y el nombre. Es necesario aclarar que lo
que entiende el colegio como asignaturas son Matemáticas, Lengua, Educación Física, etc., lo
que implica que la misma asignatura pueda impartirse en varios cursos: por ejemplo, la
asignatura de nombre Matemáticas se imparte tanto en 5º de primaria como en 1º de la ESO.
Con el fin de organizar la docencia, debe mantenerse información de qué asignaturas
hay en cada curso, cuántas horas tienen asignadas y si se cursan de manera obligatoria u
optativa en ese curso. Es norma en el colegio que una asignatura en un curso sea impartida
por un único profesor aunque un profesor podría impartir varias asignaturas en el mismo o
distinto curso.
Por necesidades de la optatividad de algunas asignaturas y para poder elaborar las

actas a partir de la base de datos, el colegio quiere mantener información de los alumnos
matriculados en cada asignatura de un curso, así como de las calificaciones que ha ido
obteniendo en tres evaluaciones distintas.

12
ESQUEMA E/R
nif
exp nom_pers
des_esp apell_pers
ALUMNO atención_esp
PERSONA fecha_nac_pers
ESPECIAL tel_pers
direccion
profesion cuenta tipo_cont
nif titulo cod_dpto nom_dpto
relación nif horas
25 2 PADRE/
ALUMNO PROFESOR DEPARTAMENTO
TUTOR
es hijo/pupilo de pertenece
exp telefono organiza

sexo domicilio
nom_alum responsable de imparte
apell_alum fecha_nac
des_curso ASIGNATURA
cod_etapa cod_etapa
nom_etapa curso
nom_asig
ETAPA CURSO/ cod_asig
CURSO
EDUCATIVA ASIGNATURAS
se compone de consta de
tiene cod_etapa
curso
cod_etapa cod_asig
curso tipo_asig
nota2 OBJETIVOS cod_obj
nota1 nota3 horas_asig
APREND. des_obj
matriculado en
13
COCIChannel.com - Examen de Febrero de 2008
COCIChannel.com
Un canal de cocina que emite en televisión por cable desea organizar toda la
información relativa a las recetas que se emiten en sus programas y ponerla disponible para
cualquier usuario que acceda a su página web. Además se desea permitir que usuarios
registrados puedan dar de alta y en general gestionar también sus propias recetas
Cada receta está identificada por un número único y además se guarda su nombre, nº
de raciones, el tiempo estimado de realización, el grado de dificultad, nº de calorías y, por
supuesto, los ingredientes de la receta y las cantidades que se emplean de cada ingrediente.
Se desea que todo lo relativo a los ingredientes esté lo más estandarizado posible, así
la base de datos deberá mantener información de todos los posibles alimentos, con un código
único y con su nombre y la unidad de medida habitual (gramos, centilitros, etc). También es
importante saber a qué familia pertenece cada alimento (verduras, legumbres, lácteos, etc.).
Esta información debe estar también perfectamente estandarizada, ya que se permitirán
búsquedas por las familias. Cada alimento sólo pertenece a una familia como máximo (puede
no pertenecer a ninguna).
La información de la receta se complementa con los pasos que hay que realizar para
llevarla a cabo. Cada paso incluirá el número de paso y la descripción textual de lo que hay
que hacer en cada paso. Por ejemplo, para la receta 125, que es “Pollo en salsa de cebolla” el
paso nº1 será: salpimentar el pollo y sofreírlo en el aceite, el paso nº 2: retirar el pollo y en el
mismo aceite freír la cebolla muy picadita, etc. Hay que tener en cuenta que cada paso es
único dentro de cada receta.
Para facilitar las búsquedas de recetas se ha decidido hacer una clasificación general
de las recetas según distintos aspectos (posibles grupos serían: entrantes, ensaladas, postres,
primeros platos.. con horno, con microondas…, vegetarianas,.., cocina india, china, etc.).
Cada receta puede pertenecer a varios grupos diferentes. Nos interesa también considerar qué
recetas están relacionadas con otras porque una es una variante de otra. Puede haber recetas
que no tengan ninguna relación con otras.
En la base de datos de la web deben coexistir dos tipos de recetas, las recetas emitidas
en los programas del canal de cocina y las recetas dadas de alta por los usuarios. Con respecto
a las segundas, para que un usuario pueda dar de alta una receta tiene que registrase
previamente. Cada usuario debe facilitar su nombre completo, dirección y una contraseña de
acceso y estará identificado por un código único. El mismo usuario puede dar de alta varias
recetas, para las que se debe guardar, además de los datos generales, la fecha de alta.
Para el control de las recetas emitidas en los programas se desea organizar parte de la
información sobre los programas. De cada programa se conoce el nombre, su duración, un
código que le asigna la cadena y qué cocineros (nombre completo, categoría, en qué
restaurante trabaja, si procede) han dirigido ese programa y en que período de tiempo. Hay
que tener en cuenta que el mismo programa, a lo largo del tiempo, puede haber sido dirigido
por distintos cocineros y el mismo cocinero puede haber dirigido distintos programas (incluso
el mismo cocinero puede haber dirigido el mismo programa en varios períodos de tiempo).
De cada programa se realizan una serie de emisiones en distintas fechas. Queremos
saber qué recetas se realizaron en cada emisión de cada programa, teniendo en cuenta que en
una emisión de un programa se pueden realizar un máximo de 3 recetas y que es norma de la
cadena que no se repitan las recetas ni en el mismo programa ni en distintos (es decir, una
receta sólo puede realizarse una vez).
y si necesitas hacer alguna aclaración, hazlo a la vuelta de esa hoja. (Puntuación: 3 puntos
sobre 10)
15
ESQUEMA E/R
A continuación se muestra una posible solución. Posteriormente se comentan variantes
también válidas.
#alim
#fam
nom_alim ALIMENTO FAMILIA
unidad nom_fam
pertenece a
ingrediente de cantidad
#receta
nom_receta es variante de clasificada en #grupo
raciones
tiempo
RECETA GRUPO nom_grupo
dificultad compuesta de
calorías #receta
PASO #paso
RECETA descripción
RECETA
PROGRAMA #usuario
dada de alta por nombre
3 RECETA
USUARIO dirección
explicada en USUARIO contraseña
#prog fecha
fecha_em EMISIÓN
#cocinero fecha_desde nombre
#cocinero restaurante*
es de un #prog fecha_hasta categoría
#prog
nom_prog dirigido por dirección de
duración
HISTÓRICO
PROGRAMA COCINERO
DIRECCIÓN
La solución mostrada no es la única posible. Posibles modificaciones también válidas serían,

entre otras:
- Representar HISTÓRICO_DIRECCIÓN dependiente sólo de PROGRAMA y después
asociarla con COCINERO. La representación mostrada en la solución permite que un
programa pueda haber sido codirigido por varios cocineros y que un cocinero haya
sido director de varios programas a la vez. Según se interprete así o no, la
representación podría variar.
- Representar restaurante como entidad y asociarla con COCINERO usando
opcionalidad.
- Establecer una jerarquía entre USUARIO Y COCINERO.
- Representar la jerarquía entre RECETA_PROGRAMA y RECETA_USUARIO como
disjunta.
Errores más comunes detectados:

- No representar la entidad GRUPO o la entidad FAMILIA y simplemente añadir un
atributo a las entidades correspondientes. Un error todavía más grave es representarlas
como entidades dependientes.
16
- No representar la entidad EMISIÓN o representarla como dependiente tanto de

RECETA como de PROGRAMA. La condición de que en una emisión no pueden
realizarse más de tres recetas no estaría correctamente reflejada. Otro error es
representarla pero no asociarla con RECETA y en su lugar, asociar PROGRAMA con
RECETA por otra parte.
- No representar el HISTÓRICO DIRECCIÓN o no poner correctamente la clave
primaria, que debe incluir obligatoriamente el atributo fecha_desde.
- No poner PASO_RECETA como entidad dependiente de la RECETA.
- Establecer incorrectamente la conectividad de asociaciones como pertenece a,
clasificada en, ingrediente de…
- Representar la jerarquía RECETA_PROGRAMA y RECETA_USUARIO pero
establecer las asociaciones explicada en o dada de alta por con el supertipo RECETA
en lugar de con el subtipo correspondiente.
17
Red Hidrográfica Española - Examen de Septiembre de 2008
Red Hidrográfica Española

El cambio climático está provocando que en España se alternen períodos de sequía y períodos
de fuertes lluvias en determinadas zonas. Con el fin de realizar un estudio de la situación se
desea almacenar en una base de datos información relativa a la red hidrográfica española,
incluyendo cuencas, ríos, embalses, etc.
La red hidrográfica española se organiza en cuencas hidrográficas1 más o menos
grandes en las cuales hay un gran río colector que desemboca en el mar. España se divide en
13 cuencas hidrográficas, que se van a identificar por un código único y de las que deseamos
conocer su nombre y su superficie. A cada cuenca hidrográfica pertenecen un conjunto de
ríos, de los que interesa almacenar su nombre, longitud, lugar de nacimiento y desembocadura
y su caudal medio (cada río sólo pertenece a una cuenca). Además, se desea saber cuál es el
río principal de cada cuenca, si lo hay, y qué ríos son afluentes de otros y si lo son por la
derecha o por la izquierda. También es imprescindible conocer los municipios por los que
pasa cada río y, consecuentemente, las provincias y comunidades autónomas a las que
pertenecen estos municipios. Dado que esta información se va a usar también para los
embalses y otra parte de la base de datos, se desea que esté completamente estandarizada.
Otro recurso hidrográfico importante son los embalses. Los embalses pueden recibir
agua de uno o varios ríos (de su misma o distinta cuenca) y a su vez un río puede
proporcionar agua a varios embalses. Relacionada con los embalses existen dos tipos de
información, una información fija, que incluye su nombre, la cuenca, el municipio o
municipios donde está enclavado, el río o ríos que proporcionan agua a este embalse, etc, y
otra información de tipo histórico relacionada con el agua embalsada en un momento dado.
La siguiente tabla muestra un ejemplo de la información que debería ofrecer la aplicación
para el embalse de Borbollón cada vez que se realizase una consulta2:
EMBALSE DE BORBOLLÓN
Cuenca Tajo
Municipios (Provincias) Santibáñez el alto (Cáceres)
Ríos Arrago
Tipo embalse (opcional) Gravedad
Año construcción 1954
Superficie 888 Ha
Capacidad 88 Hm3
Agua embalsada actualmente 74 Hm3
Última medición 01/09/2008
Variación semana anterior -3 Hm3
Misma semana del año anterior 70 Hm3
Media de la misma semana para los 9 últimos años 67 Hm3
Supondremos que para todos los embalses existe, al menos, una medición diaria del
agua embalsada. Sin embargo, en algunos momentos hay algunos embalses especialmente
críticos para los que se realizan varias mediciones al día; para éstos hay que guardar una
1
Una cuenca hidrográfica se define como la superficie terrestre que recorren todos los ríos y afluentes que
desembocan en el mismo río principal.
2
Téngase en cuenta que la información de la tabla es la que se quiere presentar al usuario y no
necesariamente debe ser almacenada con esta misma estructura, pero sí será preciso disponer de información en
la base de datos para poder obtenerla.
descripción del motivo de su criticidad. Además, la información de las sucesivas mediciones

se quiere ofrecer también al usuario en tiempo real, por lo que deberá almacenarse, si bien
periódicamente se eliminará información atrasada y sólo se mantendrá, como para el resto de
embalses, una única medición diaria.
y si necesitas hacer alguna aclaración, hazlo a la vuelta de esa hoja. (Puntuación: 3 puntos
sobre 10)
19
ESQUEMA E/R
A continuación se muestra una posible solución, aunque otras soluciones pueden ser
igualmente válidas.
COMUNIDAD
MUNICIPIO PROVINCIA
#mun
está en
AUTÓNOMA
nom_mun situado en
nom_prov #prov nom_com #com

atravesado por
lado
relacionado
con #río
nom_río es afluente de pertenece a #cuenca
longitud nom_cuenca
caudal RÍO CUENCA
superf_cuenca
nacimiento
desembocadura
proporciona es el principal de
#emb agua a
nom_emb superf_emb
tipo* capacidad
año ubicado en
EMBALSE
tiene #emb
motivo #emb
#emb MEDICIÓN fecha
EMBALSE
fecha HISTÓRICO hora
CRÍTICO CRÍTICA
medida MEDICION medida
ALGUNOS ERRORES DETECTADOS:

1) Representar la Red Hidrográfica Española como una entidad.
2) Definir las entidades RÍO o EMBALSE como dependientes de CUENCA (en el
examen se dieron en alto las indicaciones oportunas para no hacerlo). O lo que es más
grave definir CUENCA como dependiente de alguna de las dos.
3) Definir una jerarquía sobre RÍO para separar Río principal y Afluente. La condición
de afluente y si es por la derecha o por la izquierda sólo tiene sentido referido a la
asociación con el río en que desemboca. Por otra parte, un río se considera principal
no por sí mismo, sino porque lo es de una cuenca. Finalmente, un río que es afluente
de otro puede, a su vez, tener afluentes.
4) Representar el lado por el que es afluente un río como dos atributos: izquierda y
derecha; se trata de dos valores posibles para un único atributo lado (o vertiente).
5) No asociar EMBALSE con CUENCA, ya que en el enunciado se dice que un embalse
puede recibir agua de ríos que están en su misma cuenca o en otra. Si no se realiza esta
asociación es imposible saber a qué cuenca pertenece un embalse.
6) Poner el atributo cuenca en EMBALSE o en RÍO o el atributo municipio en cualquiera
de las dos entidades anteriores.
7) Añadir los valores de mediciones a la entidad EMBALSE sin considerar ningún tipo
de histórico.
20
8) No representar la entidad EMBALSE CRÍTICO y poner el motivo de la criticidad en

EMBALSE o en cada una de las mediciones (en HISTÓRICO MEDICIÓN o en
MEDICIÓN CRÍTICA)
9) Representar una entidad independiente MEDICIÓN, con un único atributo #medición
o incluso con un valor de medición y hacer depender de ella y de EMBALSE el
HISTÓRICO MEDICIÓN o la MEDICIÓN CRÍTICA
10) Elegir de manera incorrecta los identificadores de las entidades HISTÓRICO
MEDICIÓN o MEDICIÓN CRÍTICA.
11) No representar las entidades PROVINCIA Y COMUNIDAD AUTÓNOMA, ya que
en el enunciado se indica que toda esta información se desea estandarizar.
21
Inmopel S.A. - Examen de Febrero de 2007
Inmopel S.A.
Inmopel S. A. (Pelotazos Inmobiliarios Sociedad Anónima) es una agencia
inmobiliaria de nueva creación que desea beneficiarse del boom inmobiliario de los últimos
años. La agencia quiere organizar la información de las viviendas que tiene a la venta para
agilizar el trabajo de sus agentes y su relación con los clientes.
La parte fundamental de la información está compuesta por los datos de las viviendas,
es decir: dirección, m2, nº de dormitorios, nº de baños, precio de venta y si tiene plaza de
garaje, calefacción y aire acondicionado. La agencia asigna a cada vivienda una referencia
única. Además les interesa saber en qué barrio se encuentra cada vivienda, ya que los clientes
generalmente buscan una zona concreta. Para estandarizar de alguna manera esta información
desean mantener la información de los municipios (código único de municipio, nombre y
provincia a la que pertenecen) y los barrios en los que se divide cada uno. Además del nombre
del barrio y el precio medio en esa zona, se debe asignar a cada barrio un código que puede
repetirse para distintos municipios, pero no dentro del mismo municipio.
Las viviendas en venta pueden ser viviendas de segunda mano o en construcción. En
este último caso es la empresa constructora (promotora) la que le facilita a la agencia los datos
de las viviendas que tienen todavía libres en las promociones que están construyendo. Es
necesario saber el cif, nombre, razón social y teléfono de la empresa constructora, así como la
promoción (nombre de la promoción y fecha de entrega) a la que pertenecen las viviendas en
venta. Ha de tenerse en cuenta que una promoción puede estar siendo construida por más de
una empresa constructora y que de la misma promoción suelen estar en venta en la agencia
inmobiliaria varias viviendas. Con respecto a estas viviendas en construcción la inmobiliaria
no necesita registrar más información que la que se ha reflejado anteriormente.
La parte más importante del negocio de Inmopel se centra en las viviendas de segunda
mano. De éstas, además de los datos generales de las viviendas, se quiere conocer su año de
construcción, estado general, si tiene hipoteca y la cuantía de la misma. Por supuesto, es
también necesario saber los datos de su propietario actual: nif, nombre y apellidos, domicilio
y teléfono y la fecha desde que la vivienda ha sido puesta en venta. En caso de que la vivienda
tuviese varios propietarios sólo se registrará la información de uno de ellos, el que sirva de
contacto para la venta de la vivienda.
Cuando un cliente que desea comprar una casa acude a la agencia indica sus
preferencias con respecto al barrio o barrios, m2, nº de dormitorios y precio aproximado de la
vivienda que está buscando. La inmobiliaria le ofrecerá las viviendas disponibles y si está
interesado en visitar alguna deberá facilitar su datos personales (nif, nombre y apellidos,
domicilio y teléfono), que quedarán registrados junto con sus preferencias en la base de datos
de la agencia, con vistas a informarle de nuevas viviendas que le puedan interesar.
Un cliente puede visitar varias viviendas de segunda mano e incluso puede visitar la
misma vivienda más de una vez pero siempre acompañado por uno de los agentes de la
inmobiliaria (no tiene que ser necesariamente por el mismo agente). La visita se realizará en
una fecha y hora concreta y puede darse el caso de que varios clientes realicen la visita a la
vez. De los agentes es preciso también tener almacenado sus datos personales (nif, nombre
completo, domicilio y teléfono), además de su fecha de ingreso en la empresa, su salario base
y su comisión por venta.
atributos de TODAS las entidades y subraya los identificadores. De la misma forma
muestra las asociaciones con sus atributos correspondientes.
y si necesitas hacer alguna aclaración, hazlo a la vuelta de esa hoja.
22
ESQUEMA E/R
A continuación se muestra una posible solución, que no tiene por qué ser única; de hecho, en
la siguiente página aparece una variante, donde se han marcado las diferencias.
nif nombre apel1 apel2 domicilio

A nom_mun
#mun
teléfono provincia
prefiere se divide en
PERSONA
BARRIO MUNICIPIO
nºdorm_pref
m2_pref precio_m2
nif precio_pref nif nom_barrio
ubicada en #barrio
#mun
#ref nom_emp
CLIENTE AGENTE PROPIETARIO
dirección razón_soc
m2 cif
teléfono
nif fecha_ing comisión nºdormitorios
salario
nºbaños EMPRESA
acompaña en pone en venta VIVIENDA plaza_garaje
realiza
VENTA CONSTR.
calefacción
fecha fecha_desde aire_acond
hora #ref precio construye

#ref
pertenece a
visita realizadas
SEGUNDA NUEVA
VISITA PROMOCIÓN
MANO CONSTRUCC.
hipot
#ref #promo nombre
año_cons estado fecha_ent
ERRORES QUE SE HAN COMETIDO FRECUENTEMENTE:

- BARRIO no se representa como entidad dependiente, o se pone mal su identificador.
- VIVIENDA se asocia con municipio, en lugar de con BARRIO
- VIVIENDA se representa como dependiente de BARRIO
- No se representa la jerarquía de CLIENTE, AGENTE y PROPIETARIO
- PROMOCIÓN no se representa como entidad y sus atributos cuelgan como
descriptores de una asociación entre NUEVA_CONSTRUCC. Y EMPRESA_
CONSTR.
- La asociación entre PROMOCIÓN y EMPRESA_CONSTR. se pone 1:N o N:1
- La asociación entre PROPIETARIO y SEGUNDA_MANO se pone N:M
- La fecha_desde (de pone en venta) aparece como atributo de PROPIETARIO
- Con respecto a la entidad VISITA hay múltiples errores. Uno de los más comunes es
representarla como una entidad dependiente de las tres entidades: CLIENTE,
AGENTE y PROPIETARIO. Esto, además de no cumplir los requisitos del enunciado,
es un error grave de concepto (una entidad nunca depende de tres). Otro error es
ponerla dependiente de AGENTE (o de AGENTE y CLIENTE), pues eso implicaría
que en una misma visita puede haber varios agentes. En la primera solución propuesta
se ha representado sólo dependiente de SEGUNDA_MANO; en la segunda solución
aparece representada como dependiente de SEGUNDA_MANO y CLIENTE. Ambas
23
pueden considerarse válidas, siempre que se indiquen correctamente los

identificadores (obsérvese que es necesario añadir la fecha y hora, además de los
identificadores de las entidades de que depende).
- Las preferencias del cliente también han dado lugar a múltiples errores, como
representarlas como una entidad dependiente, suponiendo que hay varias posibles
preferencias diferentes por cliente. En cualquier caso el error más grave ha sido el
incluir barrio como un atributo (de esta entidad o en CLIENTE) cuando BARRIO es
una entidad en sí misma, así que lo que debería hacerse es establecer una asociación.
nif nombre apel1 apel2 domicilio

A nom_mun
#mun
teléfono provincia
PERSONA
BARRIO MUNICIPIO
nºdorm_pref
m2_pref precio_m2
nif precio_pref nif nom_barrio
ubicada en #barrio
#mun
#ref nom_emp
CLIENTE AGENTE PROPIETARIO
dirección razón_soc
m2 cif
teléfono
nif fecha_ing comisión nºdormitorios
salario
nºbaños EMPRESA
realiza acompaña en pone en venta VIVIENDA plaza_garaje
VENTA CONSTR.
calefacción
fecha aire_acond
#ref nif (cliente)
hora #ref precio construye
pertenece a
visita realizadas
SEGUNDA NUEVA
VISITA PROMOCIÓN
MANO CONSTRUCC.
#ref hipot #promo nombre
año_cons estado fecha_desde fecha_ent
24
Inmopel S.A. II - Examen de Septiembre de 2007
Inmopel S.A. II
La agencia inmobiliaria Inmopel S. A. (Pelotazos Inmobiliarios Sociedad Anónima) ha
ampliado su negocio inicial, abriendo una red de sucursales en distintos puntos de
Extremadura e incluyendo también la gestión de alquileres de viviendas, de manera que
necesita reorganizar su base de datos para incluir toda esta nueva información. Una parte del
diseño de su base de datos actual (que se realizó en el examen de febrero) se muestra a
continuación. Debe tomarse este diseño como punto de partida, de manera que puede usarse la
información que aparece representada sin necesidad de repetirla en el nuevo diseño.
nif nombre apel1 apel2 domicilio nom_mun

#mun
teléfono provincia
PERSONA ZONA
MUNICIPIO
URBANA
nºdorm_pref
nºbaños_pref
2
m _pref precio_m2
nif precio_pref nif nom_zona
ubicada en #zona
#mun
PROPIETARIO #ref
CLIENTE AGENTE
dirección
ponen en m2
nif venta o alquiler nºdormitorios
fecha_ing comisión
nºbaños
VIVIENDA trastero
calefacción
piscina
Cada sucursal de la agencia Inmopel se identifica por un número único, al que

corresponden una dirección (compuesta de calle, nº, piso, puerta, código postal y municipio),
un teléfono y un número de fax. Hay que tener en cuenta que, por el momento, en cada
municipio donde se instale la agencia sólo se abrirá una única sucursal. Además, a medida
que se vayan abriendo sucursales, a cada sucursal se le asignará otra sucursal de la que
dependerá a efectos de prestarle ayuda con su gestión inicial. Es preciso señalar que una
sucursal puede tener varias que dependan de ella o ninguna.
Con la ampliación, la empresa ha tenido que contratar a nuevos agentes. Los datos que
teníamos ya incluidos de los agentes siguen siendo válidos, pero además es preciso saber a
qué sucursal ha sido asignado cada agente (sólo una). Temporalmente los agentes pueden
trabajar en otra sucursal sustituyendo a otro agente por enfermedad o vacaciones de éste. Es
preciso saber en qué sucursales ha estado trabajando un agente y en qué períodos de tiempo.
Se puede dar el caso de que el mismo agente haya estado trabajando en la misma sucursal en
varios períodos de tiempo distintos.
La información general de las viviendas se muestra en el diagrama anterior. Hay dos
tipos de viviendas: en venta y en alquiler. Debe tenerse en cuenta que la misma vivienda
puede estar puesta a la venta y en alquiler. De las viviendas en venta se guarda el precio total;
todo lo demás relativo a las mismas ya se incluyó en el diseño de febrero (aunque no se
muestra en el diagrama anterior) y no es necesario modificarlo. A partir de ahora nos
centraremos en las viviendas en alquiler.
25
De las viviendas en alquiler es necesario conocer el precio de la mensualidad, cuántos

meses de fianza se exigen, la fecha desde la que ha sido puesta en alquiler y si está
amueblada; en este último caso, hay que almacenar de qué electrodomésticos dispone y qué nº
de camas individuales y de matrimonio. Además, pueden existir una o varias condiciones que
hayan puesto los propietarios como: no se admiten animales, no alquilar a estudiantes, no
puede estar ocupado por más de un cierto nº de personas, no alquilar por menos de dos años,
etc.
Con respecto a los alquileres, la agencia quiere conocer qué viviendas están alquiladas
en la actualidad, desde qué fecha, hasta cuándo y a qué arrendatario concreto. También se
desea conocer la historia de los alquileres, es decir, todos los períodos en que una vivienda ha
sido alquilada, a qué arrendatarios y cuál fue el precio total que se pagó por ella.
La misma vivienda en alquiler puede ser gestionada por varias sucursales diferentes.
Es preciso conocer la información relativa a qué viviendas en alquiler concretas gestiona cada
sucursal de la agencia.
26
ESQUEMA E/R
nif resto atributos nif fecha_ing comisión

ref dirección m2 resto atributos
ref
CLIENTE AGENTE
desde
VIVIENDA hasta nif
precio_total desde hasta
tiene alquilada
HISTORIA
precio desde
ASIG.
ref ALQUILER
hasta TEMPORAL
asignado a
VIVIENDA
EN VENTA
VIVIENDA EN
SUCURSAL
ref ALQUILER gestionada por
mens
fecha #suc
tiene nº
meses_fianza depende de calle
piso
puerta
¿amueblada? ubicada en codpostal
teléfono
COND. fax
VIVIENDA MUNICIPIO
AMUEBLADA
camas mat
#ref provincia
#ref descripción lavavajillas camas ind nom_mun
#cond #mun
lavadora vitrocerámica
COMENTARIOS
La solución propuesta no es la única posible.
Una posible variación sería definir una entidad dependiente de AMUEBLADA para mantener
la información de los electrodomésticos (para no definir atributos fijos con valores sí o no, tal
y como está representado), o bien definir una entidad tipo ELECTRODOMÉSTICOS, con un
código y nombre de electrodoméstico que se relaciona con AMUEBLADA por medio de una
asociación “incluye” con conectividad N:M.
27
Referéndum para el Tratado de la Constitución Europea - Examen de Febrero de 2005
Referéndum para el Tratado de la Constitución Europea

Como sabéis en febrero se realizará el referéndum para el Tratado de la Constitución
Europea. Diseña una base de datos para tal evento teniendo en cuenta las siguientes
especificaciones, no del todo realistas:
Una parte fundamental de la información está compuesta por el censo electoral; en él
figuran todas las personas que pueden votar en el referéndum, en concreto su dni, nombre
completo, fecha de nacimiento y domicilio de residencia.
Previo al proceso de votación es necesario conocer cómo se organiza
administrativamente y físicamente dicho proceso. En primer lugar, administrativamente los
municipios se dividen en distritos, los distritos se organizan en secciones y en cada sección
puede haber varias mesas electorales. De los municipios almacenamos un código único a
nivel nacional, su nombre, así como la provincia a la que pertenece. Los distritos se
identifican por un número dentro de cada municipio y, además, tenemos un nombre asociado
al distrito. Para las secciones existe una letra que las identifica dentro de cada distrito. Y
finalmente, las mesas tienen asignado un número consecutivo dentro de cada sección. En
segundo lugar, debemos conocer exactamente en qué locales electorales están situadas las
mesas. Vamos a suponer que la asignación de locales electorales se realiza a nivel de sección:
un local electoral puede asignarse a varias secciones y una sección sólo puede estar asignada a
un local electoral. De los locales electorales conocemos su nombre y dirección.
Un proceso determina qué mesa electoral (sólo una) le corresponde a cada persona que
figura en el censo con residencia en España (a los españoles con residencia fuera del país no
se les asigna mesa); es preciso mantener la información de la mesa asignada a cada persona en
la base de datos. Para atender a los votantes que acudan a cada mesa electoral existen una
serie de personas que han sido elegidas por sorteo entre las personas del censo. En concreto
cada mesa tiene un único presidente y varios vocales (3 máximo), asignados sólo a esa mesa.
Por otra parte, cada mesa tiene también asignadas varias personas como suplente, cada uno
con un número de orden; en este caso una persona puede ser suplente en más de una mesa.
Para los presidentes, vocales y suplentes debemos almacenar, además de sus datos censales,
un teléfono de contacto y un número de cuenta corriente.
Para vigilar la corrección del proceso de votación se designan una serie de inspectores,
que se asignan a los locales electorales. En concreto, un inspector puede tener asignado varios
locales electorales y a un local electoral se pueden haber asignado varios inspectores. Hay que
guardar en qué intervalos de tiempo estuvo cada inspector en cada local electoral. Además,
hay que tener en cuenta que un inspector, a lo largo del día, pasa en varios momentos
diferentes por el mismo local. De los inspectores se desea almacenar su número de colegiado
y su teléfono móvil.
Al finalizar el proceso de votación debemos conocer qué personas del censo han
votado y qué medio de votación han utilizado: voto por correo, por internet o manual (¡pero
nunca el sentido de su voto!). A nivel de mesa electoral, además, debe almacenarse el
recuento de los votos, es decir el número de votos de cada tipo (sí, no, nulos, en blanco).

28
ESQUEMA E/R
#mesa nºsí
#sec nºno
nom_mun #mun #dis #dis
nom_dis #dis #mun nºblancos
#mun provincia #mun #sec
nºnulos
se divide se organiza tiene
MESA
MUNICIPIO DISTRITO SECCIÓN
ELECTORAL
nom_loc dni
#loc dir_loc
apellido1
están ubicadas apellido2
nombre
LOCAL fecha_nac
ELECTORAL dni domicilio
medio_vot
PERSONA le corresponde
visitado por VOTANTE CENSO

ELECTORAL
dni vocal de
#loc
hora_desde
#col móvil
hora_hasta dni presidente de
3
VISITA visita realizadas
PERSONA
INSPECTOR INSPECTOR MESAS ELECT
suplente
LOCAL
dni nºorden
teléfono nºcuenta
OBSERVACIONES:
- Las entidades DISTRITO, SECCIÓN y MESA son entidades dependientes y es
incorrecto representarlas como independientes según las especificaciones del
enunciado.
- Es incorrecta la representación de una entidad PERSONA NO RESIDENTE, ya que
no tiene atributos propios y tampoco participa en una relación de manera particular.
- La representación de PERSONA RESIDENTE tampoco se considera necesaria, ya
que no tiene atributos y la relación en la que participaría puede representarse
correctamente usando una opcionalidad. Además el enunciado nos dice que por sorteo
se eligen las personas de las mesas de entre los residentes, pero esto puede
perfectamente hacerlo un proceso sin tener que tener almacenado por separado las
instancias de estos residentes.
- La entidad PERSONA MESAS ELECT, puede ser sustituida por tres entidades,
VOCAL, PRESIDENTE y SUPLENTE, cada una participando en una asociación, si
bien dado que las tres entidades tienen exactamente los mismos atributos se ha
considerado mejor la opción representada. Esta opción, sin embargo, no permite
mostrar que una persona no puede ser vocal, presidente y suplente a la vez, lo que sí
puede hacerse usando una jerarquía disjunta con las 3 entidades.
- La entidad VISITA INSPECTOR LOCAL surge de una asociación N:M en la que un
inspector va a estar asociado con un local más de una vez, pues realiza varias visitas
durante el día.
- La entidad VOTANTE podría ser sustituida por nuevos atributos en PERSONA
CENSO ELECTORAL (votó? y medio de votación, o sólo medio de votación). Para el
29
atributo medio de votación habría que especificar, en este caso, que podría ser nulo. El
poner medio de votación como atributo de la asociación “le corresponde” no es muy
correcto, ya que en esta asociación no están los no residentes, que pueden votar por
correo, por ejemplo.
ERRORES MUY GRAVES:

1) Representar entidades como SISTEMA, PROCESO, etc.
2) No identificar qué entidades son dependientes y de quién dependen. Según el
enunciado, DISTRITO depende de MUNICIPIO, SECCIÓN depende de DISTRITO y
MESA depende de SECCIÓN. Pero ninguna de ellas depende de LOCAL
ELECTORAL ni ésta última es dependiente. De igual manera es gravísimo representar
como dependientes PERSONA_CENSO, INSPECTOR, o cualquier otra que forme
parte de esa jerarquía.
3) No usar el mismo identificador para todas las entidades de una jerarquía (supertipo y
todos los subtipos). En nuestro caso PERSONA_CENSO, INSPECTOR,
PERSONA_MESA_ELECT, VOTANTE, o cualquier otra que se haya utilizado en
esa jerarquía, deben tener exactamente el mismo identificador.
4) Poner en los subtipos los mismos atributos descriptores que existen en el supertipo. Es
decir, es un error grave que los atributos apellido1, apellido2, nombre, etc. de
PERSONA_CENSO aparezcan también en los subtipos de la jerarquía INSPECTOR,
PERSONA_MESA_ELECT o cualquier otra. El identificador, sin embargo, como se
indica en 3) es el mismo en todas las entidades que forman parte de la jerarquía.
5) No construir de manera correcta los identificadores de las entidades dependientes
(obsérvense DISTRITO, SECCIÓN y MESA y VISITA_INSPECTOR_LOCAL).
6) Poner atributos que pertenecen a entidades como atributos de asociaciones. Por
ejemplo, es un error grave poner teléfono y número de cuenta como atributos de las
asociaciones vocal, suplente o presidente.
7) Representar entidades dependientes colgando de asociaciones 1:1 ó N:M.
8) Representar como entidades lo que son asociaciones. Por ejemplo, la asociación
suplente es N:M y no tiene por qué representarse como una entidad.
9) Errores relacionados con la conectividad de las asociaciones: por ejemplo, poner 1:1
cuando es 1:N ó N.M. Un caso encontrado frecuentemente ha sido la asociación le
corresponde como 1:1 en lugar de N:1 como aparece representada.
30
Elección de sede para las Olimpiadas 2012 - Examen de septiembre de 2005
Elección de sede para las Olimpiadas 2012

Como algunos sabréis, Madrid era una de las ciudades candidatas a organizar las
Olimpiadas de 2012, aunque finalmente la ciudad designada fue Londres. El Comité Olímpico
Internacional (COI) en su momento organizó una base de datos con la información más
importante relativa a las distintas candidaturas. En el diseño de una parte de esta base de datos
se tenían en cuenta las siguientes especificaciones:
Las candidaturas se identifican por un nombre y se guarda la fecha de presentación de
la candidatura y la fase en la que está (inicial, preselección, presentación de documentación,
visitas, final, etc). Cada candidatura está asociada con una serie de ciudades, de las que hay
que almacenar datos generales como su nombre, el país al que pertenecen, el número de
habitantes y su extensión en km2. La lista de países está oficialmente codificada por el COI y
se guarda este código en la base de datos junto con el nombre del país y el continente. Por otra
parte, las ciudades también se han codificado con tres letras que no pueden repetirse para el
mismo o distinto país. Una candidatura tiene una sola ciudad que es su sede principal y puede
tener varias ciudades que son subsedes (o ninguna). Por ejemplo, en la candidatura de Madrid
2012, Madrid era la sede principal y Aranjuez, Palma de Mallorca, Barcelona, Alicante,
Córdoba y Málaga eran subsedes, porque en ellas podían desarrollarse algunas de las
competiciones deportivas. Hay que tener en cuenta que una ciudad no puede ser subsede en
varias candidaturas distintas y que no hay inconveniente en que ciudades de distintos países
formen parte de la misma candidatura.
Uno de los factores que más debería influir en la elección final son las instalaciones
que presenta cada candidatura. Es por ello necesario almacenar, para cada ciudad, el conjunto
de instalaciones de que dispone, con su nombre, el tipo de instalación (deportivas o de
alojamiento) y el estado de las obras. Cada instalación se identifica por un código que no
puede repetirse dentro de cada ciudad. Para las instalaciones deportivas es preciso conocer en
qué disciplina deportiva se usará. Las disciplinas están codificadas por un número asignado
por el COI y además debemos saber su nombre. Una instalación deportiva puede usarse para
distintas disciplinas y competiciones de la misma disciplina pueden tener lugar en distintas
instalaciones. Con respecto a las instalaciones de alojamiento, es preciso saber el número de
viviendas y la capacidad total.
Además, nos interesa conocer qué distancia hay de un determinado alojamiento a una
instalación deportiva concreta de su misma ciudad y cuánto tiempo puede tardarse utilizando
cada uno de los medios de transporte disponibles para recorrer ese trayecto. Para ello es
preciso mantener la información de qué medios de transporte (metro, autobús, tren,
bicicleta,…) podrían utilizarse en cada caso y el tiempo aproximado que se necesitaría para
recorrer la distancia indicada. Como ejemplo, supongamos que la distancia del alojamiento
A1 a la instalación deportiva ID3 es de 4 km; además de este dato, hay que almacenar cuánto
tiempo se tardaría en recorrer esos 4 km usando autobús, metro o a pie (u otro de los medios
de transporte disponible para ese caso concreto).

muestra cada una de las asociaciones junto con su tipo, nombre y atributos.
31
Elección de sede para las Olimpiadas 2012 - Examen de septiembre de 2005
ESQUEMA E/R
nom_cand #ciudad
fecha_cand CANDIDATURA #inst
fase_cand nom_inst
INSTALAC. estado_inst
subsedes sede principal #inst

tiene tipo_inst #ciudad num_viv
capacidad
#ciudad
nom_ciudad #ciudad
DEPORTIVA ALOJAMIENTO
habitantes CIUDAD #inst
extensión
pertenece a
asignada a
#ciudad COMUNICADA
#país CON
#inst1
nom_país PAÍS #inst2
continente
por medio de
DISCIPLINA distancia
DEPORTIVA tiempo_est
Elección de sede para las #trans MEDIO DE

Olimpiadas 2012 #disc nom_disc
nom_trans TRANSPORTE
32
BD 2015/2016 Modelo E/R y conversión al modelo Relacional
Beijing 2008 – Examen de septiembre de 2004
Acaban de celebrarse las Olimpiadas en Atenas y ya sabemos que las Olimpiadas de

2008 se celebrarán en Pekín. Los máximos responsables de estas últimas están muy
preocupados por ofrecer una buena imagen, ya que la gestión de un acontecimiento semejante
implica una cuidadosa organización y planificación. Una de las cosas que quieren abordar ya
es el diseño de una base de datos que permita la gestión de información de países
participantes, atletas, deportes, pruebas, etc. De tus primeras conversaciones con ellos (en las
que no te has entendido muy bien por problemas de idioma) y de la consulta de la web de
Atenas 2004 (www.athens2004.com), has llegado a las siguientes conclusiones iniciales:
La base de una Olimpiada son los deportistas que participarán en las pruebas. Cada
uno de ellos va representando a su país. Cada país se identifica por un código de tres letras
estandarizado definido por el Comité Olímpico Internacional (COI). Para el control de los
deportistas se precisan una serie de datos que incluyen su nombre completo, fecha de
nacimiento, sexo y número de licencia federativa. Cada deportista se identifica por el país a
que pertenece y por un número de acreditación que se les asigna durante el tiempo que duren
las Olimpiadas. Hay que guardar también información de quién es el entrenador principal de
cada deportista, aunque puede haber deportistas que no tengan entrenador. Puede darse el caso
de que una persona sea entrenador principal de más de un deportista a la vez. De los
entrenadores hay que conocer su nombre, nacionalidad (no tiene por qué ser la misma que la
del deportista al que entrena) y número de licencia federativa. Además, a los entrenadores se
les asigna un código único que les servirá para acreditarse durante el tiempo que duren las
Olimpiadas.
En las Olimpiadas se compite en un gran número de disciplinas deportivas diferentes

(atletismo, fútbol, tenis…). El COI tiene ya codificadas todas las disciplinas deportivas, junto
con su descripción y la fecha en que se incluyó por primera vez en unas Olimpiadas, y esta
información se tiene que incorporar a la base de datos. Para simplificar, vamos a considerar
como dos disciplinas diferentes si una disciplina es válida en categoría de hombres y de
mujeres. Es decir, por ejemplo, una disciplina será “atletismo hombres” y otra “atletismo
mujeres”. Cada disciplina deportiva puede o no englobar varias pruebas diferentes. Por
ejemplo, las disciplinas atletismo, natación o yudo incluyen distintas pruebas (en atletismo
hombres, las pruebas serían maratón, 20 km marcha, 50 km marcha, 100m, 200m, etc). Otras
disciplinas, sin embargo, como el baloncesto, voleibol o balonmano, no incluyen pruebas. De
momento consideraremos que las disciplinas que no incluyen pruebas son siempre deportes de
equipo y para ellas hay que almacenar el número de integrantes máximo permitido para cada
equipo, así como el número máximo de equipos que competirán. De las disciplinas que
pueden incluir pruebas, hay algunas pruebas en las que se participa individualmente y en otras
por equipos (por ejemplo, las pruebas de relevos en atletismo o en natación). Para estas
últimas hay que guardar cuál es el número máximo de integrantes del equipo titular y cuántos
reservas como máximo puede haber. La información de todas las pruebas que deben
planificarse para cada disciplina deportiva también ha sido facilitada por el COI y está
codificada. Para cada prueba, además del código y la descripción hay que guardar cuál es el
máximo número de participantes y cuáles son los records olímpicos y del mundo para esa
prueba.
33
Evidentemente hay que mantener información de qué deportistas están inscritos en

cada prueba, sean individuales o por equipos. El mismo atleta puede participar en varias
pruebas, independientemente de la disciplina deportiva a la que pertenezca la prueba. Se debe
mantener información de cuál es la mejor marca del atleta y de su mejor marca en la última
temporada, siempre para esa prueba. Para algunas pruebas hay establecidas una serie de
rondas eliminatorias (1ª, 2ª, , semifinal, final), que no son necesariamente las mismas para
todas las pruebas. Además las rondas se dividen en series. Por ejemplo, en primera ronda de
una de las pruebas podría haber 6 series, en segunda 4, etc y la final se considera una sola
serie. Hay que saber, de los deportistas inscritos en cada prueba, quienes participan en cada
una de las series de cada ronda y cuál es la marca que han hecho en esa serie. En cualquier
caso, al final siempre hay que almacenar cuál es la mejor marca que el deportista ha realizado
en la prueba sea o no una prueba que incluya rondas (si hay rondas, para calcular este valor se
tendrán en cuenta el tiempo que ha hecho en las series de todas las rondas en las que haya
participado).
También hay que conocer qué países competirán en las disciplinas deportivas que no
incluyen pruebas (baloncesto, fútbol, etc). Para cada equipo de cada país hay que conocer
cuáles son los deportistas que integran el equipo (suponemos que un deportista no puede estar
en más de un equipo) y, además, hay que saber cuál es el entrenador principal del equipo.
Hay que señalar que una persona no puede ser el entrenador principal de más de un equipo,
aunque sí podría entrenar de manera individual a otros deportistas.
Es habitual que las Olimpiadas tengan varias sedes diferentes en la misma o diferente
ciudad. De cada sede hay que conocer su nombre y la ciudad donde está ubicada. En general,
cada disciplina deportiva que incluye pruebas tiene asignada una sede principal donde se
desarrollan todas sus pruebas, y la misma sede puede alojar las pruebas de diferentes
disciplinas deportivas. Por otra parte, podemos considerar que las disciplinas deportivas que
no incluyen pruebas constan de una serie de fases, no necesariamente las mismas para todas.
Cada fase de estas disciplinas tiene en principio asignadas dos sedes principales y en la misma
sede pueden coincidir varias fases de la misma o distinta disciplina. Es preciso conocer,
además, que equipos de qué países están compitiendo en cada fase.
Otra información que se desea tener actualizada es el medallero por país. Así para
cada país hay que saber el número de medallas de oro, plata y bronce que lleva conseguidas,
así como el número de diplomas olímpicos obtenidos.
La información de que dispones hasta ahora puede incluir errores y todavía no está
completa (faltan muchos aspectos de planificación y almacenamiento de resultados), pero con
todas estas especificaciones ya puedes empezar a realizar el diseño de la base de datos en el
modelo entidad/relación poniendo especial atención en los identificadores de las entidades.
Los únicos atributos que han de aparecer en el diagrama son los identificadores de las
entidades y los atributos de las asociaciones. Después rellena la tabla adjunta donde, para cada
entidad del diagrama, debes detallar detallar sus atributos descriptores. Posteriormente has de
realizar la conversión de tu diagrama E/R a una base de datos equivalente en el modelo
relacional. La descripción para cada relación resultante de sus atributos, clave primaria y
externas, atributos únicos y no nulos, dependencias funcionales y forma normal en que se
encuentra debes incluirla en la tabla plantilla que se te proporciona.
34
ESQUEMA E/R
#entr licencia_e
BEIJING 2008
#dd
nombre_e entr.ppal. #país
de equipo
ENTRENADOR EQUIPO
nacionalidad
nombre_p
oros representado por
equipos
entrenador platas
nombre_dd participantes
principal #país bronces
diplomas #dd fechainclusion_dd
PAÍS DISCIPLINA
compiten en
pertenencia DEPORTIVA
a equipo nº integrantes
representa a
#dep #dd
nºequipos
#país #dd
D. DEP. CON D. DEP. SIN

DEPORTISTA
PRUEBAS PRUEBAS
licencia_d
nombre_d incluye #dd
se inscriben fecha_d
fases de #fase
sexo_d
#dd #pr
#país
inscritos
#dep INSCRITO FASE
#dd
PRUEBA
PRUEBA aloja
#pr es sede ppal.
descripción_p
maxpart #dd #pr
marca_per
rec_olimpico 2
marca_tem
rec_mundial
marca_pru
PRUEBA SEDE
rondas de EQUIPO
prueba
nº titulares
nº reservas #sede ciudad_s
participan en #dd
RONDA #pr nombre_s
marca #ron
ronda
series de
ronda #dd
#pr
#ron
SERIE #ser
nºserie
35
EXPLICACIÓN DE LA SOLUCIÓN PROPUESTA

1. La entidad DEPORTISTA se ha considerado dependiente de PAÍS por la restricción que
se impone en el enunciado de que un deportista se identifica por el país a que pertenece y
por un número de acreditación. Otra razón podría ser que en una Olimpiada no tiene
sentido guardar información de un deportista que no representa a ningún país.
2. EQUIPO surge de la asociación N:M entre PAÍS y DISCIPLINA_DEPORTIVA (países
que participan en disciplinas deportiva como equipo) que a su vez se tiene que asociar con
DEPORTISTA para mantener la información de los integrantes del equipo.
3. PRUEBA, RONDA y SERIE son entidades dependientes encadenadas (primer caso de
entidades dependientes: atributo multivaluado) ya que no tiene sentido por ejemplo hablar
de 1ª ronda sin saber de que prueba es (o de la ronda final) o de la 3ª serie sin saber la
ronda y la prueba de que se trata. En el caso de PRUEBA, puede considerarse también
correcto que PRUEBA se haya reflejado como independiente, pero nunca RONDA o
SERIE.
4. INSCRITOS_PRUEBA es una entidad dependiente que surge de la asociación N:M
inscrito en entre DEPORTISTA y PRUEBA que a su vez debe asociarse con SERIE, ya
que sólo los deportistas inscritos en una prueba son los que pueden participar en sus
series.
5. FASE es una entidad dependiente ya que el enunciado dice claramente que el número de
fases depende de la disciplina y puede variar de una disciplina a otra. No tiene sentido
hablar de 1ª fase, 2ª fase, etc, o fase final sin saber de que disciplina de equipo estamos
hablando.
6. La asociación es sede principal entre FASE y SEDE puede representarse también como
dos asociaciones 1:N.
7. La representación de la entidad D. DEP. CON PRUEBAS, a pesar de que no tenga
atributos propios, es necesaria, ya que debe asociarse con PRUEBA y SEDE (cada
disciplina deportiva que incluye pruebas debe tener asignada una sede principal y esto no
es así para las disciplinas deportivas sin pruebas, donde la asignación de sedes se hace por
medio de las distintas fases) .
8. No tiene sentido una entidad PRUEBA INDIVIDUAL ya que no tiene atributos propios y
además no necesita asociarse por sí misma a ninguna otra entidad.
9. Puede definirse una entidad MEDALLERO con una asociación 1:1 con PAÍS.
36
CONVERSIÓN AL MODELO RELACIONAL
NOMBRE Clave Claves externas Atributos no Atributo Dependencias funcionales Forma
RELACIÓN primaria nulos s únicos normal
PAÍS #país nombre_p nombre_p #paísPAÍS FNBC
(#país, mombre_p, oro,plata, nombre_pPAÍS
bronce, diplomas)
ENTRENADOR #ent #país referencia PAÍS(#país) nombre_e, #entENTRENADOR FNBC
(#ent, nombre_e, licencia-e, licencia_e
#país)
DEPORTISTA #país, #dep #país referencia PAÍS (#país) nombre_d, #país, #depDEPORTISTA FNBC
(#país, #dep, nombre_d, #ent referencia ENTRENADOR(#ent) fecha_d, sexo_d,
fecha_d, sexo_d, licencia_d, licencia_d
#ent)
SEDE #sede nombre_s, #sede SEDE FNBC
(#sede, nombre_s, ciudad_s) ciudad_s
DISCIPLINA_DEPORTIVA #dd nombre_dd, nombre_dd #ddDISCIPLINA_DEPORTIVA FNBC
(#dd, nombre_dd, tipo_dd nombre_dd
fechainclusión_dd, tipo_dd) DISCIPLINA_DEPORTIVA
D._DEP_SIN_PRUEBAS #dd #dd referencia DISCIPLINA_DEPORTIVA(#dd) nºequipos, #dd D._DEP_SIN_PRUEBAS FNBC
(#dd, nºequipos, nºintegrantes
nºintegrantes)
D._DEP_CON_PRUEBAS #dd #dd referencia DISCIPLINA_DEPORTIVA(#dd) #ddD._DEP_CON_PRUEBAS FNBC
(#dd, #sede) #sede referencia SEDE (#sede)
PRUEBA #dd, #pr #dd referencia D._DEP_CON_PRUEBAS(#dd) descripción_p, #dd, #prPRUEBA FNBC
(#dd, #pr, descripción_p, maxparticipantes,
maxparticipantes, record_olimp,
record_olimp, record_mundial
record_mundial, equipo?)
PRUEBA_EQUIPO #dd, #pr (#dd, #pr) referencia PRUEBA (#dd, #pr) nºtitulares, #dd, #prPRUEBA_EQUIPO FNBC
(#dd, #pr, nº titulares, nºreservas
nºreservas)
INSCRITOS_PRUEBA #dd, #pr, #país, (#dd, #pr) referencia PRUEBA (#dd, #pr) marca_personal #dd, #pr, #país, #dep FNBC
(#dd, #pr, #país, #dep, #dep (#país, #dep) referencia DEPORTISTA (#país, #dep) marca_temporada INSCRITOS_PRUEBA
marca_personal,
marca_temporada,
marca_prueba)
RONDA #dd, #pr, #ron (#dd, #pr) referencia PRUEBA (#dd, #pr) #dd, #pr, #ron RONDA FNBC
(#dd, #pr, #ron, ronda)
SERIE #dd, #pr, #ron, (#dd, #pr, #ron) referencia RONDA (#dd, #pr, #ron) #dd, #pr, #ron, #ser SERIE FNBC
(#dd, #pr, #ron, #ser, nºserie) #ser
PARTICIPANTES_SERIE #dd, #pr, #ron, (#dd, #pr, #ron, #ser) ref. SERIE (#dd, #pr, #ron, #dd, #pr, #ron, #ser, #país, #dep  FNBC
(#dd, #pr, #ron, #ser, #país, #ser, #país, #dep #ser) PARTICIPANTES_SERIE
#dep, marca) (#país, #dep) referencia DEPORTISTA (#país, #dep)
EQUIPO #país, #dd #país referencia PAÍS (#país) #ent #ent #país, #dd  EQUIPO FNBC
(#país, #dd, #ent) #dd referencia DISCIPLINA_DEPORTIVA (#dd) #ent  EQUIPO
#ent referencia ENTRENADOR (#ent)
INTEGRANTES_EQUIPO #país, #dd, #dep (#país, #dd) referencia EQUIPO (#país, #dd) #país, #dep #país, #dd, #dep  FNBC
(#país, #dd, #dep) (#país, #dep) referencia DEPORTISTA (país, #dep) INTEGRANTES_EQUIPO
#país, #dep 
INTEGRANTES_EQUIPO
FASE #dd, #fase #dd referencia DISCIPLINA_DEPORTIVA (#dd) #dd, #fase  FASE FNBC
(#dd, #fase, descripcion)
EQUIPOS_FASE #dd, #fase, #país (#dd, #fase) referencia FASE (#dd, #fase) #dd, #fase, #país FNBC
(#dd, #fase, #país) (#dd, #país) referencia EQUIPO (#dd, #país) EQUIPOS_FASE
SEDES_FASE #dd, #fase, #sede (#dd, #fase) referencia FASE (#dd, #fase) #dd, #fase, #sede  SEDES_FASE FNBC
(#dd, #fase, #sede) #sede referencia SEDE
OBSERVACIONES:
- Las relaciones PARTICIPANTES_SERIE, EQUIPOS_FASE y SEDES_FASE provienen de las asociaciones participan en, compiten en y es sede
principal.
- La relación INTEGRANTES_EQUIPO se ha generado desde la relación pertenencia a equipo que es N:1 con opcionalidad. Precisamente esta
opcionalidad es lo que hace conveniente que se transforme en una nueva relación. La solución de llevar a DEPORTISTA la clave de EQUIPO es
también válida, pero ello va a implicar que la clave externa referenciando a EQUIPO va a estar a nulos en muchas tuplas, ya que hay muchos
deportistas de un país que no compiten en sus deportes de equipo.
Encuestas para todo – Examen de febrero de 2004
Encuestas para todo

Como todos sabéis, el día 14 de marzo se celebran elecciones generales. Hasta ese
momento, y como es habitual en todas las elecciones, sean del tipo que sean, los medios de
comunicación nos van a estar bombardeando con resultados de encuestas realizadas, algunas
de ellas, por cierto, con resultado bastante dispar. Algunos critican que, con frecuencia, las
empresas que realizan las encuestas están asociadas de alguna manera con determinados
medios de comunicación algo sesgados políticamente, de manera que el resultado final de las
encuestas no parece muy fiable.
DELTA-3 es una empresa independiente de nueva creación que ha surgido con el

ánimo de ofrecer encuestas serias que aborden todo tipo de temas (sociales, económicos,
elecciones, etc). Para ello van a construir un sistema informático cuya base de datos debes
diseñar. Dada la cercanía de las próximas elecciones, no se espera poder tener el sistema
funcionando a pleno rendimiento para ese momento, pero sí se quiere utilizar estas elecciones
para realizar una prueba de una pequeña parte del sistema. Por ello te has puesto ya manos a
la obra, y éstas son las conclusiones a las que has llegado, después de hablar con los
responsables de la empresa:
La base de la empresa está formada por las personas que realizan las encuestas, es
decir, los encuestadores. De ellos hay que guardar información personal como su dni, nombre
completo, dirección, teléfono y número de la seguridad social. Los encuestadores se agrupan
en equipos de trabajo que tendrán asignadas distintas áreas geográficas donde realizar las
encuestas. Cada uno de estos equipos tiene un encuestador responsable que se encarga de
coordinar al resto de los miembros de su equipo. A veces, temporalmente, un encuestador se
reasigna de un equipo a otro por necesidades del trabajo. La empresa quiere mantener la
información de quiénes han formado parte de cada equipo en cada momento.
Para la asignación de zonas geográficas donde deben realizar su labor los

encuestadores, la empresa ha obtenido la relación de todos los municipios españoles. Para
cada uno de ellos se tiene su nombre, su extensión, número de habitantes, así como la
información de la provincia y la autonomía a que pertenecen. La asignación de los municipios
a los equipos de trabajo la realizan los responsables de la empresa en base a su número de
habitantes, pero hay que tener en cuenta que para distintos eventos para los que se realicen
encuestas esta asignación puede variar. Se considera un evento, por ejemplo, las elecciones
autonómicas de Extremadura del año 2003 o un estudio de población de la región de Murcia
en el año 2004, o las propias elecciones generales del 2004. Para cada evento para el que se
vaya a realizar un estudio hay que guardar su descripción, las fechas de comienzo y fin del
trabajo de encuestación y la información de los municipios que se tendrán en cuenta para el
estudio. Es obvio que, dada la diversidad de ámbitos geográficos que abarca cada evento, la
asignación que se realice de los equipos no puede ser la misma. Aunque, en general, cada
equipo de trabajo puede ser asignado a varios municipios y en un municipio suele trabajar un
solo equipo, en casos de municipios grandes puede haber como máximo cinco equipos
distintos asignados para un determinado evento. Se quiere guardar también en qué período de
fechas ha estado asignado un equipo a un municipio para un evento.
En cuanto a las encuestas propiamente dichas, la empresa ha diseñado inicialmente

varios modelos diferentes de encuesta y a cada uno de ellos le ha asignado un código único,
un nombre y una descripción del uso habitual de ese modelo. Eso no significa que ese modelo
39
sólo pueda usarse para un tipo de evento concreto. De hecho un mismo modelo puede servir
para varios eventos y para el estudio de un evento pueden utilizarse diferentes modelos de
encuesta. Además, para cada modelo han pensado qué preguntas (el texto) incluiría una
encuesta de ese modelo. En este punto han llegado a la conclusión de que sea cuál sea la
pregunta, para las respuestas siempre se van a facilitar varias alternativas entre las que el
encuestado debe elegir una. Esto sirve tanto para preguntas con respuestas de tipo SI, NO o
NS/NC (no sabe, no contesta), para las que se propone elegir una entre varias posibilidades
que se ofrecen (¿a cuál de estos partidos votará? ¿cuál de los siguientes cree que es el
principal problema en España?...) y para las preguntas que indican que se otorgue una
valoración en puntos sobre algo (Valore de 0 a 10 a tal partido, político o situación puede
contestarse eligiendo entre 10 casillas posibles a marcar). Por ello basta con guardar para cada
pregunta, además del texto de la pregunta en sí, cada una de las alternativas de respuesta con
su descripción correspondiente.
Además de la información de los municipios, la empresa ha obtenido un fichero con

todas las posibles direcciones de cada municipio. Esta información no se quiere almacenar en
la base de datos inicialmente debido a su volumen. Pero para cada evento para el que se va a
realizar un estudio, un proceso aleatorio elige de este fichero las direcciones de los que van a
ser encuestados. Estas direcciones seleccionadas por cada municipio y evento sí deben ser
almacenadas en la base de datos. Cada encuesta real que se realiza se corresponde con una de
estas direcciones y se identifica por un número de referencia consecutivo que se asigna para
cada evento que se estudia y cada modelo de encuesta. Además, hay que almacenar la fecha
en que fue realizada, el municipio a que corresponde y el encuestador que la realizó. Dado
que se debe preservar la identidad del encuestado, la única información del mismo que se
guarda asociada a la encuesta es su sexo y edad. En la mayoría de los casos las encuestas se
realizan en persona, pero debido a la dificultad que supone desplazarse a determinadas áreas
geográficas, algunas encuestas se realizan por teléfono. Para éstas últimas hay que saber el
número de teléfono y cuántos intentos de llamada se hicieron antes de poder entrevistar al
encuestado. Los responsables de cada equipo, periódicamente, comprueban que las encuestas
se están realizando correctamente volviendo a ponerse en contacto con el encuestado por
medio del teléfono o acudiendo a la dirección de la encuesta. Si se detecta alguna
irregularidad en la confección de determinadas encuestas, éstas se anulan automáticamente.
Para estas encuestas anuladas es preciso guardar la fecha en que se anularon y la causa de la
anulación.
Dado el trabajo que conllevaría procesar manualmente las respuestas, la empresa

dispone de un lector de documentos, que interpreta la información en papel detectando la
respuesta (la opción marcada) para cada pregunta de la encuesta. Esta información debe
almacenarse para cada encuesta con el fin de elaborar las estadísticas que se publicarán en el
estudio. No olvidemos que éste es el objetivo final de la empresa.
Con todas estas especificaciones has de realizar un diseño de la base de datos en el

entidades y los atributos de las asociaciones. Por separado, has de construir una tabla en la
que, para cada entidad del diagrama, se detallen sus atributos descriptores. Posteriormente has
de realizar la conversión de tu diagrama E/R a una base de datos equivalente en el
modelo relacional.
40
ESQUEMA E/R
#dni tel_e ENCUESTAS PARA TODO

nss nom_e
dir_e #dni #equipo fecini fecfin #equipo
adscrito a adscripción de
HISTÓRICO EQUIPO
ENCUESTADOR
PERT. EQUIPO TRABAJO
responsable 5
ini_asig
#mod #eve asignados fin_asig
#mod nom_mo ini_est
uso_mo #eve nom_e fin_est
MODELO MODELO ÁMBITO GEOG.

ENCUESTA EVENTO
EVENTO EVENTO
estudio en #eve
incluye estudio para #mun
#mod
texto
#pre encuesta de
#mun #dir se eligen
#eve
PREGUNTA
MUNICIPIO
#mod DIRECCIÓN
#pre alternativa SELEC. hab_m
#alt de #mun
ext_m
nom_m
OPCIONES dirección
pertenece a
RESPUESTAS #eve
desc #prov
ENCUESTA #mod realizada en
marcada en
#eve
nom_p PROVINCIA
#ref
#mod
#ref #pre #aut integrada
fec_enc nom_a en
ENCUESTA
sexo
realizada por edad
AUTONOMÍA
ENCUESTA ENCUESTA
TELEF. ANULADA
#eve #eve
nº tel fec_anu
#mod
intentos #mod causa
#ref #ref
41
EXPLICACIÓN DE LA SOLUCIÓN PROPUESTA

1. Los atributos subrayados son los atributos identificadores de cada entidad. El resto son
los atributos descriptores. Cualquier otro atributo que se añada (sobre todo atributos
que pertenecen a otras entidades) como atributo descriptor constituye un error.
2. La entidad dependiente HISTÓRICO PERT. EQUIPO surge de una asociación N:M
entre ENCUESTADOR y EQUIPO porque un encuestador puede estar asociado a un
equipo de trabajo más de una vez (2º caso de Entidades Dependientes), ya que según
el enunciado los encuestadores podían reasignarse temporalmente a otros equipos y no
se indica nada de que no hayan podido estar dos veces en el mismo equipo. Debido a
ello el identificador debe incluir, además de los identificadores de ENCUESTADOR y
EQUIPO, la fecha de inicio de pertenencia al equipo. Si no se incluye este último
atributo en el identificador supone un error, ya que significa que se ha considerado que
un encuestado no puede pasar por el mismo equipo dos veces; en el caso de que se
hubiese hecho esta suposición sobraría la entidad dependiente y en su lugar debería
aparecer una relación N:M con atributos descriptores fecha de inicio y fecha fin
(periodo en que el encuestador está en el equipo).
3. La entidad dependiente MODELO EVENTO ha surgido de una asociación N:M entre
MODELO y EVENTO que a su vez debe relacionarse con ENCUESTA (3er caso de
Entidades Dependientes), ya que, según el enunciado, las encuestas reales se numeran
por evento y modelo, asignando además un número de referencia único para cada
evento y modelo. De ahí que ENCUESTA sea una entidad que dependiente de éstas y
su identificador esté formado por #even, #mod y #ref.
4. La entidad dependiente denominada ÁMBITO GEOG. EVENTO surge de una
asociación N:M entre EVENTOS Y MUNICIPIOS, que a su vez tiene que
relacionarse con EQUIPOS DE TRABAJO (3er caso de Entidades Dependientes), ya
que según el enunciado las restricciones impuestas para la asignación de EQUIPOS a
municipios siempre tienen en cuenta el evento. Es decir, como máximo se podían
asignar 5 equipos a un municipio pero para un evento. Además, el enunciado también
nos dice que las direcciones se seleccionaban aleatoriamente para cada evento y
municipio con lo cual la entidad DIRECCIÓN SELEC. también se asocia con
ÁMBITO GEOG. EVENTO. Obsérvese que cualquier otra manera de establecer las
asociaciones entre EQUIPO TRABAJO, MUNICIPIO y EVENTO no permite reflejar
correctamente las restricciones del problema y no representa uno de los casos de
entidades dependientes estudiados en teoría (ver apartado de errores frecuentes
encontrados en los exámenes).
5. El formato de los distintos modelos de encuesta se representa a través de las entidades
PREGUNTA y OPCIONES (de respuesta). La entidad dependiente PREGUNTA
surge al considerar que las preguntas son un atributo multivaluado de MODELO
ENCUESTA (primer caso de Entidades Dependientes). En este caso es preciso formar
su identificador con el identificador de la entidad padre y un atributo más. Así
obtenemos #mod, #preg. Las opciones posibles de respuestas (sean 3 para preguntas
si/no/nc, 10 para preguntas de valoración y un número indeterminado para las
restantes) siempre pueden representarse como una entidad dependiente de
PREGUNTA a la que se ha denominado OPCIONES (1er caso de Entidades
Dependientes, ya que alternativas de respuesta se considera un atributo multivaluado
de PREGUNTA). La entidad OPCIONES debe formar su identificador con el de su
entidad padre (PREGUNTA) y un atributo más: así obtenemos #mod, #preg, #alt.
42
Independientemente de estas apreciaciones, también es posible considerar las

entidades PREGUNTA y OPCIONES como entidades independientes si bien en este
caso la asociación “incluye” entre MODELO ENCUESTA y PREGUNTA y la
asociación “alternativa de” entre PREGUNTA y OPCIONES deberían ser N:M y no
1:N, ya que en este caso se está considerando que no se han definido preguntas y
respuestas específicas para un determinado modelo (serían dependientes) sino
preguntas y respuestas genéricas que luego se irán asignando a los modelos de
encuesta.
6. Además de definir las preguntas y opciones de respuesta para cada modelo hay que
representar las respuestas reales que se han marcado en las encuestas que se han
realizado. La entidad dependiente RESPUESTAS ENCUESTA surge de una
asociación N:M entre ENCUESTA y PREGUNTA que a su vez debe asociarse con la
entidad OPCIONES. En primer lugar cada encuesta real de un modelo de encuesta
tendrá incluida las preguntas de ese modelo; de ahí la asociación N:M entre
ENCUESTA y PREGUNTA. Para cada una de estas preguntas, en la encuesta
concreta aparecerá marcada una opción, que debe ser una de las opciones válidas para
esa pregunta concreta de ese modelo (de ahí la asociación “marcada en” con
OPCIONES).
7. La representación de las entidades PROVINCIA y AUTONOMÍA se debe a que no se
desea repetir el nombre de la provincia y la autonomía para cada uno de los
municipios (pueden ser muchos) que pertenecen a una provincia y autonomía. Tiene
sentido al menos crear la entidad PROVINCIA donde se refleje la relación entre
provincia y autonomía. Téngase en cuenta que si estas entidades no se hubiesen
creado, al convertir al modelo relacional nos vamos a encontrar con una relación
MUNICIPIO que no estará en FNBC (por la dependencia funcional provincia->
autonomía); en concreto MUNICIPIO estaría en 2FN y al hacer la normalización para
llevarla a FNBC al menos tendríamos que crear la relación PROVINCIA (ver errores
comunes en las respuestas al examen).
8. La entidad ENCUESTA TELEF. es una especialización de ENCUESTA y que por lo
tanto debe tener su mismo identificador, #eve, #mod, #ref. No es correcto representar
una entidad ENCUESTA EN PERSONA ya que no tiene atributos propios y además
no participa en ninguna asociación diferente de las de ENCUESTA.
9. La entidad ENCUESTA ANULADA es una especialización de ENCUESTA y que por
lo tanto debe tener su mismo identificador, #eve, #mod, #ref. No es necesario
representar una entidad ENCUESTA CORRECTA ya que no tiene atributos propios y
además no participa en ninguna asociación diferente de las de ENCUESTA. Téngase
en cuenta que la anulación de una encuesta concreta es un proceso posterior en el
tiempo a la realización de la encuesta, por lo que hay que guardar las respuestas de
todas, aunque después algunas de ellas se anulen (lo que llevará también a la
anulación de sus respuestas)
10. La representación de una entidad ENCUESTADO con los atributos descriptores sexo
y edad asociada 1:1 con ENCUESTA puede también considerarse correcta aunque no
se ha creído conveniente incluirla, ya que sólo contendría estos dos atributos, y no
participaría en ninguna otra asociación. Además, y esto es fundamental, en el
enunciado se especifica que los atributos sexo y edad se guardan asociados a la
encuesta y además se insiste en que del encuestado no se posee ninguna otra
información personal; por esto la entidad ENCUESTADO pierde fuerza al sólo tener
información para cada ocurrencia del sexo y edad del encuestado.
43
NOMBRE Clave Claves externas Atributos Atributo Dependencias funcionales Forma
RELACIÓN primaria no nulos s únicos normal
ENCUESTADOR dni nombre nss nss dniENCUESTADOR FNBC
nssENCUESTADOR
EQUIPO_TRABAJO #equipo dni_responsable referencia ENCUESTADOR(#dni) #equipoEQUIPO_TRABAJO FNBC
HIST_PERT_EQUIPO dni, #equipo, dni referencia ENCUESTADOR(dni) dni, #equipo, fecini HIST_ FNBC
fecini #equipo ref. EQUIPO_TRABAJO (#equipo) PERT_.EQUIPO
AUTONOMIA #aut nom_a nom_a #autAUTONOMIA FNBC
nom_aAUTONOMIA
PROVINCIA #prov #aut referencia AUTONOMIA(#aut) nom_p nom_p #provPROVINCIA FNBC
nom_pPROVINCIA
MUNICIPIO #mun #prov referencia PROVINCIA(#prov) nom_m #munMUNICIPIO FNBC
hab_m
EVENTO #eve nom_e #eveEVENTO FNBC
ÁMB_GEOG_EVENTO #eve, #mun #eve referencia EVENTO(#eve) #eve, #mun FNBC
#mun referencia MUNICIPIO(#mun) ÁMB_GEOG_EVENTO
ASIG_EQUIPO #eve, #mun, #eve, #mun referencia AM_GEOG_EVENTO(#eve, #mun) ini_asig #eve, #mun, #equipo FNBC
#equipo #equipo referencia EQUIPO(#equipo) ASIG_EQUIPO
DIR_SELEC #eve, #mun, #dir #eve, #mun, referencia AMB_GEOG_EVENTO(#eve, direccion #eve, #mun, #dir DIR_SELEC FNBC
#mun)
MODELO_ENCUESTA #mod nom_mo #mod MODELO_ENCUESTA FNBC
MODELO_EVENTO #eve, #mod #eve referencia EVENTO(#eve) #eve, #mod FNBC
#mod referencia MODELO(#mod) MODELO_EVENTO
PREGUNTA #mod, #pre #mod referencia MODELO(#mod) texto #mod, #pre PREGUNTA FNBC
OPCIONES #mod, #pre, #alt #mod, #pre referencia PREGUNTA(#mod, #pre) desc #mod, #pre, #alt OPCIONES FNBC
ENCUESTA #eve, #mod, #ref #eve, #mod referencia MODELO_EVENTO(#eve, #mod) #eve, #mun, (#eve, #eve, #mod, #ref ENCUESTA FNBC
#eve, #mun, #dir referencia DIR_SELEC (#eve, #mun, #dir) #dir #mun, #eve, #mun, #dir ENCUESTA
dni referencia ENCUESTADOR(dni) fec_enc, #dir)
sexo, edad
telef? anula?
ENCUESTA_TELEF #eve, #mod, #ref #eve, #mod, #ref referencia ENCUESTA(#eve, #mod, #ref) nºtel #eve, #mod, #ref FNBC
ENCUESTA_TELEFONO
ENCUESTA_ANULADA #eve, #mod, #ref #eve, #mod, #ref referencia ENCUESTA(#eve, #mod, #ref) fec_anu, #eve, #mod, #ref FNBC
causa ENCUESTA_ANULADA
RESPUESTAS_ENCUESTA #eve, #mod, #ref, #eve, #mod, #ref referencia ENCUESTA(#eve, #mod, #ref) #mod, #pre, #eve, #mod, #ref, #pre FNBC
#preg #mod, #pre referencia PREGUNTA(#mod, #preg) #alt RESPUESTAS_ENCUESTA
#mod, #pre, #alt referencia OPCIONES (#mod, #pre, #alt)
44
Oleadas de Chapapote - Examen de Febrero de 2003
Oleadas de chapapote
Todos hemos sido testigos, a través de los medios de comunicación, de la catástrofe que está
afectando a toda la cornisa cantábrica causada por el hundimiento del petrolero Prestige a
finales del pasado año 2002. La zona más afectada por el momento es la costa gallega. El
dramatismo de la situación y la cobertura que está teniendo en los medios de comunicación
han provocado que miles de voluntarios hayan querido aportar su granito de arena
colaborando en las labores de limpieza de las playas. La inesperada avalancha de solicitudes
ha causado cierta desorganización en la planificación de las tareas a realizar y la asignación de
personas a las tareas. Así, aunque son muchas las personas que han mostrado el deseo de
colaborar en muchos casos hemos visto cómo, incluso encontrándose desplazadas a Galicia,
no han dispuesto de material (palas, capazos, monos, etc.) para realizar tales labores. El
objetivo de este ejercicio es diseñar una base de datos que permita dar soporte a la
planificación de las tareas de limpieza. En concreto se requiere que se tengan en cuenta las
personas que constituyen las cuadrillas de limpieza, las labores que realiza cada cuadrilla en
cada playa, las personas que localmente contribuyen a dar apoyo logístico a las cuadrillas
(comidas, alojamiento, etc.) y los depósitos y extracciones de “chapapote” que tienen lugar en
cada playa. Las especificaciones que has de considerar son las siguientes:
Las labores de limpieza las llevan a cabo una serie de cuadrillas. Cada cuadrilla está
constituida por una serie de personas que pueden ser voluntarios o miembros de alguna
agrupación del ejercito español. Cada cuadrilla viene identificada por un código único y hay
que conocer quién es su responsable (uno de los participantes). De los participantes en la
cuadrilla hay que conocer su DNI, su nombre y su dirección. Además, de los miembros del
ejercito hay que conocer a qué agrupación pertenecen y su rango militar. En concreto de las
agrupaciones es necesario almacenar su número, su nombre y el cuartel del que proviene. De
los voluntarios hay que conocer dónde estarán alojados. Para ello se dispone de una lista con
las plazas de alojamiento que (los habitantes de las localidades gallegas) ponen a disposición
de los voluntarios. Así de cada alojamiento se necesita conocer el nombre del propietario del
alojamiento, su DNI, el número de plazas que oferta y la dirección del alojamiento. Hay que
tener en cuenta que una persona puede ser reasignada de una cuadrilla a otra dependiendo de
las necesidades. De hecho, una misma persona podría pasar de una cuadrilla a otra para luego
más tarde volver a la primera. Es necesario tener constancia de todos los pasos de personas
por cuadrillas (esto resultará vital para saber más tarde qué personas han colaborado en la
realización de cada tarea de limpieza).
Cada localidad tiene una serie de playas. De cada localidad hay que conocer su
nombre y el número de habitantes que tiene. De cada playa hay que conocer su nombre, su
longitud en kilómetros y la calidad de la playa: arenosa, rocosa o mixta. Hay que conocer qué
cuadrillas han estado asignadas en cada playa cada día, y una descripción de los trabajos que
han realizado en cada asignación. Hay que tener en cuenta que a una playa puede haberse
asignado varias cuadrillas cada día e incluso que una cuadrilla, en un mismo día, puede haber
estado en varias playas.
Cada día se anota, para cada playa, la cantidad de chapapote que se ha extraído (en
toneladas). Este chapapote se almacena en contenedores que más tarde serán retirados por
camiones. Hay que tener constancia también de los camiones que colaboran en las limpiezas y
de las extracciones que cada camión hace de cada playa, en concreto, para cada extracción
que un camión hace de una playa es necesario conocer el número de toneladas extraídas y la
45
fecha y hora en la que se produjo la carga. De los camiones es necesario conocer su matrícula
y el nombre, el DNI y la dirección del propietario.
A cada cuadrilla se le asigna una localidad en la que cada día acudirán a comer durante
la jornada de trabajo. Dicha comida es aportada y preparada por una serie de colaboradores
voluntarios que en cada localidad muestran su interés en realizar esta contribución. De tales
colaboradores se conoce su nombre, un teléfono de contacto y la localidad en la que residen.
En cada localidad hay que conocer qué días se va a preparar comida (dado que no
necesariamente todos los días se prepararán) y quiénes son los colaboradores que se
encargarán de prepararla cada día. Uno de los colaboradores será el encargado de avisar al
resto y organizar la preparación de la comida (hay que conocer quién es). Este colaborador
encargado puede ser diferente cada día. Para cada uno de los colaboradores que intervienen en
la preparación de una comida hay que almacenar también una descripción de las aportaciones
materiales que realiza (aceite, arroz, gas, etc.) y la cantidad. También hay que almacenar, para
cada comida preparada, a qué cuadrillas va a dar soporte.
modelo relacional.
46
ESQUEMA E/R
#loc #playa
OLEADAS DE CHAPAPOTE
nom_l fecha
hab_l nom_p
lon_p cal_p #playa ton_chap
ubicada en diario limpieza
LOCALIDAD PLAYA PLAYA/DIA realizadas en
fecha fecha asignación
#cua #cua de
#playa #tra des_t #playa ton
comidas #playa
fecha
TRABAJO ASIGNACIÓN hora EXTRAC.
reside
#loc tareas
mat
fecha
asignada a #cua realizadas por
da soporte a mat
COMIDA CUADRILLA
CAMIÓN
fecha formada por
#loc #col #cua #his propietario
aportación dni
COLABORADOR APORT. PASO POR

COMIDAS MATERIAL CUADRILLAS PROP_CAM
organiza formó parte responsable
#loc
de dni nom_pc
#fecha cant PERSONAL dir_pc
desc
#col LIMPIEZA
COLABORADOR dni
#apo dir
nombre
#col
nom_c
dni
tel_c MIEMBRO
VOLUNTARIO
EJÉRCITO
alojado en adscrito a
dni rango
#aloj
dir_a
plazas
ALOJAMIENTO
AGRUPACIÓN
propiedad de
nº
dni nom_a cuartel
PROP_ALOJ
nom_pa
Observaciones:
- la entidad PLAYA/DIA (o DIARIO PLAYA) surge porque hay que guardar
diferentes informaciones a nivel de cada playa y cada día. En primer lugar, hay
que almacenar las toneladas de chapapote que se extraen de cada playa cada día.
Si en la entidad PLAYA figurase esta información sería un atributo
47
multivaluado, por lo que generamos la entidad dependiente PLAYA/DÍA. Hay

que tener en cuenta que también las asignaciones de cuadrillas a las playas se
realizan para cada día y la información de las toneladas de chapapote extraídas
por camión también hay que guardarla a nivel de playa y día.
- La entidad ASIGNACIÓN surge de una asociación N:M entre CUADRILLA y
PLAYA/DÍA para la que a su vez hay que guardar el atributo multivaluado
trabajos realizados. En primer lugar una cuadrilla en el mismo día puede estar
trabajando en varias playas y en una playa en el mismo día pueden estar
trabajando varias cuadrillas. Esto es una asociación N.M entre CUADRILLA y
PLAYA/DIA. Si no hubiese que guardar más, bastaría con representar esta
asociación. Sin embargo, como hay que almacenar para cada cuadrilla y cada
playa y día la relación de trabajos realizados por la cuadrilla, es necesario crear
la entidad ASIGNACIÓN dependiente de CUADRILLA y PLAYA/DIA de la
que a su vez cuelga la entidad dependiente TRABAJOS.
- La entidad dependiente EXTRACCIÓN surge de una relación N:M entre
CAMIÓN y PLAYA/DIA donde un camión puede realizar más de una
extracción en la misma playa y el mismo día. Es decir una instancia de
CAMIÓN se relaciona más de una vez con una instancia de PLAYA/DIA y por
ello se añade el atributo hora como parte de la clave.
- La entidad dependiente PASO POR CUADRLLAS surge de la relación N:M
entre CUADRILLA y PERSONAL DE LIMPIEZA donde una persona que
interviene en las labores de limpieza puede estar asociada más de una vez con la
misma cuadrilla, ya que, según el enunciado, una persona puede cambiar de
cuadrilla y volver en un momento dado a pertenecer a una en la que ya ha estado
previamente.
- La entidad dependiente comida surge como un atributo multivaluado de
LOCALIDAD.
- La entidad dependiente COLABORADOR COMIDAS surge de una asociación
N:M entre COMIDAS y COLABORADOR que necesita asociarse con una
nueva entidad APORT. MATERIAL para guardar el atributo multivaluado
aportaciones materiales que realiza un colaborador para la comida en que
participa.
48
Los torneos de tenis –Examen de Junio de 2002
Los torneos de tenis

Hace ya algunos años que los tenistas profesionales españoles están obteniendo
excelentes resultados en los torneos en los que participan, sobre todo si se desarrollan en
pistas de tierra. Después de muchos años, se logró ganar la Copa Davis. Y, sin ir más lejos, la
última final masculina del torneo sobre tierra batida más famoso del mundo, Roland Garros,
ha sido disputada por dos españoles, J. C Ferrero y A. Costa, con triunfo de éste último. Y no
es la primera vez que se produce esta situación.
A la vista de este éxito, y con el objetivo de analizar la evolución de cada uno de los
tenistas y las estadísticas que obtienen en los partidos, la Federación Española de Tenis ha
decidido realizar un seguimiento durante un año de los torneos en los que participan tenistas
españoles. Para ello va a construir una base de datos con la información necesaria cuyo diseño
debes realizar. De momento sólo se incluirán los torneos individuales masculinos y más
adelante se abordarán otras categorías y también los femeninos.
A lo largo del año se celebran una serie de torneos de tenis. De ellos nos interesa conocer
su nombre, la fecha de inicio y de fin del torneo, el máximo número de participantes en total
(no sólo españoles), el tipo de superficie sobre la que se desarrollará el torneo (tierra, hierba,
etc), a cuántos sets serán los partidos (a 3 ó a 5), y el premio que recibirá el ganador; los
torneos se identificarán por un código único de 4 letras. Por otra parte, cada torneo se
desarrolla en un club deportivo, ubicado en una ciudad. De este club interesa conocer el
nombre, la dirección, número de pistas que tiene, el tipo de superficie de cada pista, la
categoría de cada pista (central, principal, segunda, otras), el nombre de la pista si es que lo
tiene, y el aforo de espectadores. Aunque la sede del torneo puede cambiar de un año a otro
(de hecho, hay un torneo Master que el año que viene se traslada a Madrid), dado que
inicialmente sólo consideraremos la información de un año, esta posibilidad no necesita
considerarse. Además nunca ocurre que dos torneos diferentes se celebren en el mismo club.
Aunque el seguimiento se va a realizar para los tenistas españoles, la Federación ha
decidido que también incluirá en la base de datos a los tenistas no españoles que participen en
los torneos, ya que éstos se enfrentarán a los españoles en los partidos. De todos los jugadores
se necesita conocer su número de licencia federativa, pasaporte o DNI, nombre completo,
fecha de nacimiento y país de procedencia. Para cada jugador inscrito en un torneo se anotará,
además, el puesto que ocupa en el ranking de la ATP (Asociación de Tenistas Profesionales)
al comienzo del torneo. De los jugadores españoles, se quiere mantener, además, el nombre de
su entrenador y el de su club de origen, así como el historial más representativo de su carrera;
así, siempre que el jugador haya alcanzado los cuartos de final, semifinales o final en algún
torneo en años anteriores, se almacenará el torneo en que participó, y el resultado que obtuvo
(ganador, finalista, semifinalista o cuartos de final).
Para ir avanzando en el torneo, los jugadores tienen que ir superando rondas (1ª ronda, 2ª
ronda, ..., cuartos, semifinales, final); el número de rondas no es necesariamente igual para
todos los torneos, depende de la importancia del torneo y, por supuesto, del número máximo
de jugadores inscritos. Es importante conocer en cada ronda de un torneo cuál es el número de
puntos que podría sumar un jugador que llega a esa ronda, de cara al ranking de la ATP (los
que conocen el funcionamiento del ranking saben que esto no depende sólo de la ronda, sino
del resultado del jugador en el torneo el año anterior, pero para simplificar no lo tendremos en
cuenta). También interesa conocer cuál es el premio en metálico que recibe un jugador por
llegar hasta esa ronda.
En cada ronda de un torneo hay una serie de partidos que enfrentan a 2 jugadores que se
han clasificado para esa ronda. Nos interesa conocer la fecha y la hora de comienzo de un
49
partido, la pista en que se celebra, la ocupación del aforo (porcentaje de asientos vendidos) y,
por supuesto, los jugadores que intervienen, la duración del partido y el resultado. De cara al
seguimiento de los jugadores españoles es importante conocer información del rendimiento de
los mismos en cada uno de los sets disputados en cada partido. Entonces, por cada set que se
disputa en un partido y para cada jugador que participa en el mismo deben conocerse los
siguientes datos: el número de juegos ganados, el porcentaje de primeros servicios, los puntos
ganados con el primer y segundo servicio, los saques directos, los golpes ganadores de
derecha y de revés y los errores no forzados.
modelo relacional.
50
ESQUEMA E/R
nom_torn
TORNEOS DE TENIS
fec_ini
#tor #club Nom_cDirec_c
fec_fin Ciudad_c
max_par celebrado en
tipo_sup TORNEO CLUB
sets
premio #tor
#ronda num_pistas
num_ptos
organizado en
Inscripción premio
en pertenece a
RONDA
#tor
#lic #tor #club
se juegan #ronda
ranking_ATP #par #pista
primer_jug
INSCRIPCIÓN PARTIDO PISTA

jugado en
segundo_jug fec_par Tipo_sup
hora_par nom_p
ocup_pista cat_p
Inscripción de consta de
duración aforo_p
ganador
juegos_gan
SET porc_ps
ptos_ps
#tor para 1er ptos_ss
#lic saques_dir
JUGADOR #ronda y 2º jug
dchas
dni #par #set
reves
nombre errores
fecha_nac
país #lic
mérito
HISTORIAL #hist
ESPAÑOL JUGADOR
nom_tor
resultado
#lic nom_entre club_origen
Observaciones:
- la entidad dependiente INCRIPCIÓN surge de una asociación N:M entre
TORNEO y JUGADOR que a su vez debe relacionarse con PARTIDO
- la entidad PARTIDO podría haberse considerado como una entidad
independiente con identificador #par, para no tener que arrastrar identificadores
tan largos. En este caso SET, dependiente de partido, tendría como identificador
#par, #set.
51
CONVERSIÓN AL MODELO RELACIONAL

Comenzamos la conversión por algunas de las entidades que no tendrán claves externas
con respecto a ninguna otra, para continuar con las relacionadas con ellas.
Observaciones:
- cuando en la parte derecha de las dependencias aparezca el nombre de la relación,
estamos representando todos los atributos.
- aunque no se especifique para cada relación, en todas las relaciones los atributos que
forman parte de la clave primaria deben ser no nulos y la combinación de todos ellos
debe ser única
CLUB ( #club, nom_c, direc_c, ciudad_c, num_pistas3)
Clave primaria (#club)
nom_c no nulo, único
ciudad_c no nulo
#club-> CLUB
FNBC
PISTA ( #club, #pista, tipo_sup_p, nom_p, cat_p, aforo_p)
Clave primaria (#club, #pista)
nom_p puede ser nulo (según el enunciado)
#club, #pista-> PISTAS
FNBC
TORNEO ( #tor, nom_tor, fec_ini, fec_fin, max_par, tipo_sup, sets, premio, #club)
Clave primaria (#tor)
Clave externa (#club) referencia CLUB(#club)
nom_tor no nulo, único
fec_ini no nulo
#tor-> TORNEO
FNBC
RONDA ( #tor, #ronda, num_ptos, premio)
Clave primaria (#tor, #ronda)
Clave externa (#tor) referencia TORNEO(#tor)
#tor, #ronda-> RONDA
FNBC
JUGADOR ( #lic, dni/pass4, apellidos, nombre, fecha_nac, país)
Clave primaria (#lic)
Apellidos, nombre, país no nulo
#lic-> JUGADOR
FNBC
ESPAÑOL ( #lic, apellidos_entre, nombre_entre, club_origen)
Clave primaria (#lic)
Clave externa(#lic) referencia JUGADOR(#lic)
#lic-> ESPAÑOL
FNBC
3
La aplicación deberá mantener la consistencia del atributo num_pistas según lo almacenado en PISTA.
4
Al guardar jugadores extranjeros no podemos asegurar que siempre vayamos a tener información de su
pasaporte o dni, ni que el número éste no pueda repetirse.
52
HISTORIALJUGADOR( #lic, #hist, nom_tor5, resultado)

Clave primaria (#lic, #hist)
Clave externa (#lic) referencia ESPAÑOL(#lic)
nom_tor, resultado no nulo
#lic, #hist-> HISTORIALJUGADOR
FNBC
INSCRIPCIÓN( #tor, #lic, ranking_ATP)
Clave primaria (#tor, #lic)
Clave externa(#tor) referencia TORNEO(#tor)
Clave externa(#lic) referencia JUGADOR(#lic)
ranking_ATP no nulo
#tor, #lic-> INSCRIPCIÓN
FNBC
PARTIDO( #tor, #ronda, #par, fec_par, hora_par, #jug1, #jug2, duración, ganador,
#club, #pista, ocup_pista)
Clave primaria (#tor, #ronda, #par)
Clave externa(#tor, #ronda) referencia RONDA(#tor, #ronda)
Clave externa(#tor, #jug1) referencia INSCRIPCIÓN(#tor, #lic)
Clave externa(#tor, #jug2) referencia INSCRIPCIÓN(#tor, #lic)
Clave externa(#club, #pista) referencia PISTA(#club, #pista)
(fec_par, hora_par, #club, #pista) único
#tor, #ronda, #par-> PARTIDO, fec_par, hora_par, #club, #pista->PARTIDO
FNBC
SET(#tor, #ronda, #par, #set, juegos_gan1, porc_ps1, ptos_ps1, ptos_ss1,
saques_dir1, dchas1, reves1, errores1, juegos_gan2, porc_ps2, ptos_ps2, ptos_ss2,
saques_dir2, dchas2, reves2, errores2)
Clave primaria (#tor, #ronda, #par, #set)
Clave externa(#tor, #ronda, #par) referencia PARTIDO
#tor, #ronda, #par, #set-> SET
FNBC
5
Como es la información de torneos donde han participado antes no tienen por qué estar almacenados en
TORNEO.
53
Las donaciones de sangre –Examen de febrero de 2002
Las donaciones de sangre

Seguro que estás al corriente de que recientemente algunas personas en Inglaterra han sido
informadas de que habían recibido una donación de sangre de un donante al que
posteriormente se le ha diagnosticado la enfermedad de las vacas locas. Como podrás suponer
esto sólo es posible si se tiene un control riguroso de las reservas de sangre, de quiénes han
sido los donantes y de quiénes han sido los receptores. El objeto de este ejercicio es que
diseñes una base de datos adecuada a tal efecto. Para ello habrás de tener en cuenta las
siguientes especificaciones:
Existen una serie de centros de donación en los que los donantes pueden realizar sus
donaciones. De cada donante hay que guardar su DNI, su código de donante (número que se
le da a cada donante la primera vez que acude a donar sangre y que figura en su carnet de
donante), su grupo sanguíneo, su factor RH, su nombre, su dirección y su teléfono. De los
centros de donación hay que guardar su nombre, su dirección y su número (diferente para
cada centro). Hay que tener en cuenta que cada donante puede acudir a cualquier centro
cuantas veces lo desee. Las donaciones se realizan en unidades de 100ml que se almacenan en
bolsas estériles al vacío. A cada bolsa se les asigna un código que posteriormente se utilizará
para realizar el seguimiento a la donación. El código es una cadena alfanumérica que incluye
el grupo sanguíneo del donante. De cada donación hay que almacenar, además, la fecha en la
que fue realizada.
De cada donación se extrae una muestra y se envía a un laboratorio para ser analizada
en búsqueda de posibles enfermedades. Cada muestra es analizada por dos analistas diferentes
del laboratorio al que se envía la muestra. De los laboratorios hay que guardar su nombre y su
dirección. De los analistas, su nombre, su dirección, su DNI, su número de colegido (los
analistas han de ser enfermeros colegidos), el laboratorio en el que trabaja y su número de
registro (número que se le asigna a un enfermero analista cuando ocupa uno de estos puestos
especializados). Hay que tener en cuenta que un analista sólo puede trabajar en un laboratorio
y que si un analista cambia de laboratorio se le asigna un número de registro nuevo
(duplicándose todos sus datos). Además han de almacenarse los resultados de los dos análisis.
Cuando alguno de los análisis realizados a una donación indica que la muestra no está
absolutamente sana, la donación se deshecha automáticamente para ser destruida. Además se
informa al donante mediante una carta de que su donación ha sido desechada informándole
del motivo e indicándole si ha de visitar al médico o no. De cada donación desechada hay que
almacenar el número de registro de salida de la carta al donante y la fecha de destrucción de la
donación.
Cuando se constata que una donación es sana se envía a un hospital. De cada hospital
hay que conocer su nombre, su dirección y su código. Cuando una donación llega a un
hospital, se almacena la fecha en la que ha llegado. Sin embargo, esto no quiere decir que la
donación vaya a quedarse en el hospital. Por el contrario, los hospitales se transfieren sangre
unos a otros en función de sus necesidades. Hay que tener constancia de todos las
transferencias de sangre entre hospitales de forma que en todo momento se conozca por qué
hospitales a pasado cada donación y en qué hospital se encuentra actualmente. Además,
cuando una donación deja un hospital para ser transferida a otro hay que anotar la fecha en la
que se produce el envío.
La sangre es utilizada en los hospitales para realizar transfusiones a algunos de sus
pacientes. Para que un paciente pueda recibir una transfusión primero ha de ser ingresado. De
54
cada paciente se conoce el DNI, su NSS (número de la seguridad social), y su dirección. Hay
que anotar qué donaciones han sido recibidas por qué pacientes. Hay que tener en cuenta
también que un paciente puede haber recibido varias transfusiones en el mismo o diferentes
ingresos.
Por último, cuando a un donante se le detecta alguna enfermedad de riesgo
automáticamente queda anulado lo cual implica tres cosas. En primer lugar que no podrá
realizar más donaciones. Además se anotan en la base de datos las diversas causas por las que
ha quedado anulado. En segundo lugar se pone en marcha un mecanismo de inmovilización
de las donaciones que aún no han sido utilizadas y procedentes de este donante. Para ello se
envía por un mecanismo de urgencia (llamada telefónica a los servicios de urgencia y
burofax) una notificación a cada uno de los hospitales que tienen sangre de este donante para
que la inmovilicen. Además se espera confirmación (mediante burofax) de cada uno de los
avisos. Todos los burofax quedan registrados y hay que almacenar, para cada aviso el burofax
de salida (el enviado al hospital) y el de entrada (el recibido del hospital). También, para cada
donación inmovilizada se anota la fecha en la que fue inmovilizada y la fecha en la que es
destruida. En tercer lugar, se pone en marcha un mecanismo de aviso a los pacientes que han
recibo alguna donación del donante anulado. Esto es posible gracias a que se conoce a quién
se ha puesto cada una de las donaciones de sangre. Cada donación procedente de un donante
anulado que ha sido puesta a algún paciente desencadena el envío de una carta al paciente. En
la carta se le informa del hecho y se le insta a que confirme la recepción de la carta. Es
necesario anotar el registro de salida de la carta y si el paciente ha confirmado o no.
modelo relacional.
55
ESQUEMA E/R
#don tel_d LAS DONACIONES DE SANGRE

dni nom_d
dir_d #don #cen fecha_don #centro
nom_c
GS donación_de donación_en dir_c
RH
DONANTE DONACIÓN CENTRO
bolsa_donada #lab nom_l

DONANTE #bol dir_l
CAUSA enviada a
ANULADO
BOLSA LABORATORIO
#don #causa
#don
análisis asignado
resultado
2
INMOVILIZ. SANA NO SANA ANALISTA
#reg_carta
#bol #bol
fec_inmov envio #bol fecha_dest #reg num_c
fec_dest dni_a nom_a
fec_lleg dir_a
#hos_lleg
#bol
TRANSFERENCIA
hosp_part recepción
reg_bur_salr fec_part
eg_bur_ent #hosp
nom_h
HOSPITAL dir_h transfusión
aviso_anul_hospital
nss
ingreso_en
fec_ing
aviso_anul_paciente #hosp
INGRESO
reg_sal
confirmación? ingreso_de
nss
PACIENTE
dni
direc
Observaciones:
- la entidad dependiente DONACIÓN surge porque un donante y un centro se
relacionan más de una vez en la relación N:M.
- la asociación entre BOLSAS y ANALISTAS análisis, podría estar representada
por dos asociaciones N:1, para controlar la restricción de que se realizan 2
análisis solamente.
- La entidad INGRESO surge de una asociación N:M entre HOSPITALES y
PACIENTES. Por una parte un paciente puede relacionarse más de una vez con
un hospital. Por otra son los pacientes ingresados los que reciben transfusiones,
56
por lo que la asociación N:M debería relacionarse a su vez con las bolsas que
llegan a los hospitales por medio de tranferencias.
- La entidad TRANSFERENCIA surge de una asociación N:M entre SANAS y
HOSPITALES, donde la misma bolsa puede estar relacionada más de una vez
con el mismo hospital, a causa de los reenvíos. Por otra parte, se podía
establecer una asociación unaria N:M de HOSPITALES consigo mismo, en la
que un hospital podía estar relacionado con otro más de una vez, por las
transferencias de bolsas entre ellos. Al tener ya la entidad TRANSFERENCIAS
donde figura el hospital de llegada y la bolsa, basta establecer una asociación
1:N entre HOSPITALES y TRANSFERENCIAS, que refleje el hospital de
partida.
57

Examenes Diseño ER Resueltos

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Examenes Diseño ER Resueltos

Cargado por

Copyright:

Formatos disponibles

EXÁMENES DE DISEÑO RESUELTOS

BD 2015/2016 Modelo E/R

Con estas especificaciones debes obtener un diagrama E/R. Representa los

rodada por cod_serie

Comentarios sobre la solución:

Organización de Aviación Civil Internacional

AEROPUERTO destino de VUELO

Nota: Puede considerarse que el número de pasaporte es un identificador válido para

Con estas especificaciones debes obtener un diagrama E/R. Representa los

dorsal sufrida por pertenece a

La principal diferencia con la solución que se muestra a continuación, es que en la

También es posible representar como un subtipo de VEHICULO los ABANDONOS y

subtipos de COMPETIDOR, PILOTO y COPILOTO, lo que haría desaparecer las

Por necesidades de la optatividad de algunas asignaturas y para poder elaborar las

Con estas especificaciones debes obtener un diagrama E/R. Representa los

exp telefono organiza

La solución mostrada no es la única posible. Posibles modificaciones también válidas serían,

Errores más comunes detectados:

- No representar la entidad EMISIÓN o representarla como dependiente tanto de

Red Hidrográfica Española

descripción del motivo de su criticidad. Además, la información de las sucesivas mediciones

nom_prov #prov nom_com #com

ALGUNOS ERRORES DETECTADOS:

8) No representar la entidad EMBALSE CRÍTICO y poner el motivo de la criticidad en

nif nombre apel1 apel2 domicilio

hora #ref precio construye

ERRORES QUE SE HAN COMETIDO FRECUENTEMENTE:

pueden considerarse válidas, siempre que se indiquen correctamente los

nif nombre apel1 apel2 domicilio

nif nombre apel1 apel2 domicilio nom_mun

Cada sucursal de la agencia Inmopel se identifica por un número único, al que

De las viviendas en alquiler es necesario conocer el precio de la mensualidad, cuántos

nif resto atributos nif fecha_ing comisión

Referéndum para el Tratado de la Constitución Europea

Con estas especificaciones debes obtener un diagrama E/R. Representa los

visitado por VOTANTE CENSO

ERRORES MUY GRAVES:

Elección de sede para las Olimpiadas 2012

Con estas especificaciones debes obtener un diagrama E/R. Representa los

subsedes sede principal #inst

Elección de sede para las #trans MEDIO DE

Acaban de celebrarse las Olimpiadas en Atenas y ya sabemos que las Olimpiadas de

En las Olimpiadas se compite en un gran número de disciplinas deportivas diferentes

Evidentemente hay que mantener información de qué deportistas están inscritos en

D. DEP. CON D. DEP. SIN

EXPLICACIÓN DE LA SOLUCIÓN PROPUESTA

Encuestas para todo

DELTA-3 es una empresa independiente de nueva creación que ha surgido con el

Para la asignación de zonas geográficas donde deben realizar su labor los

En cuanto a las encuestas propiamente dichas, la empresa ha diseñado inicialmente

Además de la información de los municipios, la empresa ha obtenido un fichero con

Dado el trabajo que conllevaría procesar manualmente las respuestas, la empresa

Con todas estas especificaciones has de realizar un diseño de la base de datos en el

#dni tel_e ENCUESTAS PARA TODO

MODELO MODELO ÁMBITO GEOG.

EXPLICACIÓN DE LA SOLUCIÓN PROPUESTA

Independientemente de estas apreciaciones, también es posible considerar las

COLABORADOR APORT. PASO POR

multivaluado, por lo que generamos la entidad dependiente PLAYA/DÍA. Hay

Los torneos de tenis

INSCRIPCIÓN PARTIDO PISTA

CONVERSIÓN AL MODELO RELACIONAL

HISTORIALJUGADOR( #lic, #hist, nom_tor5, resultado)