1 Problema

Supongamos que se nos ha encargado el diseño de una biblioteca digital. Para realizar nuestra
tarea, hemos de comenzar diseñando la base de datos que dará soporte a las distintas
aplicaciones que poesteriormente se irán implementando. En principio, la única información
de la que disponemos es la siguiente: · Nuestra biblioteca digital ha de almacenar información
bibliográfica (título, autor, edición, ISBN…) de distintos títulos. · Cada título de nuestra
biblioteca digital se encuentra almacenado en una o varias URLs alternativas. · Además, cada
título se encuentra catalogado: un título puede corresponder a una o más categorías diferentes.
Dichas categorías, por su parte, se encuentran organizadas de forma jerárquica (una categoría
puede tener varias subcategorías, si bien sólo puede estar englobada por una supercategoría).
· Los usuarios del sistema han de identificarse para poder utilizar nuestra biblioteca digital,
que utilizará las técnicas más avanzadas de protección de datos. · Al estilo de algunas librerías
de Internet como Amazon, los usuarios del sistema podrán evaluar y escribir comentarios acerca
de los títulos albergados en la biblioteca. La evaluación se hará clasificando los títulos de 1 a 5
estrellas en función de las preferencias del usuario y el conjunto de las evaluaciones realizadas
por los distintos usuarios servirá para recomendar unos títulos frente a otros

2 Problema

Supongamos que se nos ha encargado el desarrollo de una aplicación que se encargue de

gestionar la reserva de billetes de avión en una agencia de viajes. Tras analizar el problema
con nuestros clientes hemos recopilado la siguiente lista de requisitos: · La agencia de viajes
desea mantener información de contacto relativa a cada cliente que ha utilizado los servicios
de reserva de billetes a través de la agencia. · Cuando un cliente hace una reserva, compra un
billete para trasladarse de una ciudad a otra. El billete ha de incluir, aparte del nombre del
viajero y las ciudades de origen y destino, su fecha de emisión y su precio total. · Los billetes
pueden ser de distintas categorías (business, turista…). · Dado que no siempre hay vuelos
directos entre dos ciudades, el trayecto realizado por el cliente puede estar formado por
distintos tramos. Cada tramo corresponde a un vuelo concreto entre dos aeropuertos y viene
definido por el código de vuelo, la fecha y la hora de salida. En algunas ocasiones, la agencia
es capaz de reservar un asiento concreto dentro del avión. · El código de cada vuelo está
formado por el código de la compañía aérea y un número. Por ejemplo, el vuelo IB-365 es el
vuelo número 365 de la compañía Iberia. · Cada vuelo oferta un número determinado de plazas
para cada categoría y cada categoría tiene asociada una tarifa diferente para un mismo vuelo.
· Los aeropuertos vienen identificados unívocamente por un código de tres letras (por ejemplo,
GRX corresponde al aeropuerto de Granada). · En el caso de los billetes de ida y vuelta, lo único
que tenemos que hacer es incluir los tramos que sean necesarios para realizar el recorrido
completo.
3 Problema

Supongamos que se nos ha encargado el desarrollo de una aplicación que se encargue de

gestionar los ensayos realizados en un laboratorio de control de calidad y emitir los informes
pertinentes. Para realizar nuestra tarea, hemos de comenzar diseñando la base de datos que
dará soporte a nuestra aplicación. REQUISITOS: · Nuestro laboratorio se encarga de hacerle
controles de calidad a distintos productos. En concreto, la función del laboratorio consiste en
realizar el control de calidad de muestras tomadas de un lote concreto del producto analizado.
· En control de calidad viene avalado por la realización de uno o varios ensayos (experimentos
de laboratorio que se realizan expresamente sobre muestras del producto para certificar la
calidad del lote analizado). · Cada ensayo se realiza sobre una muestra del lote analizado del
producto, la cual viene identificada por un código asignado por el jefe de laboratorio y, en
ocasiones, puede reutilizarse para distintos ensayos. · Cada ensayo toma una serie de medidas
de la muestra analizada. Dichas medidas serán las que aparezcan en el informe final de control
de calidad. · Cuando los ensayos demuestren que el producto cumple con las exigencias de
calidad establecidas por ley, nuestra aplicación se encargará de emitir un certificado que
garantice la calidad del producto. Dicho certificado sólo tiene validez para el lote concreto
analizado y deberá ir firmado por el director de laboratorio para que tenga validez. · Cada
ensayo de los realizados en el laboratorio es de un tipo concreto (especificado por la normativa
vigente) y su tipo determina cuáles son las condiciones mínimas exigibles a los resultados
obtenidos en el laboratorio para poder emitir el certificado de calidad.

4 Problema

Supongamos que se nos ha encargado el desarrollo de una aplicación que se encargue de

gestionar la flota de autobuses de una empresa de transporte urbano. El objetivo de la
aplicación es analizar el funcionamiento de las distintas líneas de autobús urbano para decidir
cómo se podrían modificar dichas líneas y prestar un mejor servicio al ciudadano. Para comparar
distintas alternativas, no sólo hemos de tener en cuenta los beneficios que las modificaciones
podrían suponer, sino también los costes asociados que pueden conllevar. Tras analizar el
problema, hemos obtenido la siguiente lista de requisitos: · La compañía tiene una flota de
autobuses de distintas características. Según el modelo de autobús, éste tiene mayor o menor
capacidad y su consumo de combustible es diferente. · Para cada autobús se ha de mantener
un parte de incidencias en el que queden registradas las revisiones y reparaciones a las que ha
sido sometido. En el parte han de figurar fecha, coste y descripción, tanto de las revisiones y
reparaciones. · Cada línea de autobús consta de una serie de paradas. Las paradas están
identificadas por el nombre de la calle donde están situadas y un número (p.ej. Gran Vía 3). ·
Cada día, los autobuses realizan varias veces los recorridos marcados por las distintas líneas,
para las cuales existe un horario oficial (el cual, desgraciadamente, no suele cumplirse). · En
los autobuses se instalarán los dispositivos necesarios que permitan contar el número de
viajeros que suben y bajan en cada parada, así como controlar el cumplimiento de los horarios.
5 Problema

Supongamos que se nos ha encargado el desarrollo de una aplicación que se encargue de

gestionar reservas de billetes de tren. Tras analizar el problema, hemos obtenido la siguiente
lista de requisitos: • RENFE tiene una serie de trenes que hacen rutas fijas todos los días. Los
trenes se identifican por el código asociado a su locomotora y tienen una capacidad máxima de
pasajeros que viene determinada por el número y tipo de sus vagones. • Las rutas realizadas
por los trenes están compuestas por tramos que conectan ciudades. Los tramos se identifican
por las ciudades que conectan y la hora de salida de la ciudad origen. Además, para poder
automatizar la realización de reservas, también se mantiene información acerca de la duración
del trayecto asociado a cada tramo. • Los pasajeros hacen sus reservas para ir de una ciudad a
otra a través de un sistema informatizado que les ofrece distintas rutas alternativas. Cada
reserva tiene asociado un localizador único, una fecha de emisión, una ciudad de origen y una
ciudad de destino. • El trayecto asociado a la reserva de un pasajero está compuesto por un
conjunto de tramos, que corresponden a los tramos efectuados diariamente por los ferrocarriles
de RENFE. Para cada tramo, el viajero tiene reservado un asiento que viene determinado el
número del vagón en el convoy, la fila del asiento en el vagón y una letra que identifica la
posición del asiento dentro de la fila. • Obviamente, cuando un viajero efectúa su reserva,
puede que todo el trayecto no se realice en el mismo tren. Esto es, el pasajero puede que tenga
que hacer transbordos. vg: Para viajar de Granada a Zaragoza, el viajero hace una reserva de
un billete que incluye una plaza para el TALGO Granada-Madrid y otra plaza para el tren
Intercity Madrid-Zaragoza.

6 Problema

Supongamos que se nos ha encargado el diseño de un sistema de recuperación de información

(SRI) mediante el que se pueda acceder a una base de datos documental. Tras analizar
detenidamente el problema, enumeramos los requisitos que ha de cumplir el SRI: · Hemos de
mantener un registro de documentos, cada uno de los cuales viene identificado por un número
de registro. · Todos los documentos tienen título e incluyen una URL mediante la que se puede
acceder al documento en sí. · Los documentos aparecen indexados en la base de datos en
función de los términos (palabras) que aparecen en ellos. · En la base de datos se ha de
mantener la frecuencia de cada término en cada documento. · Para facilitar la actualización
del índice, junto con los datos de cada documento, se almacena el tamaño en bytes del
documento, la fecha de última actualización del documento en el índice y el valor de una
función hash (checksum) que se utilizará para comprobar si el documento actual es el que ya
está indexado en la base de datos. · Aparte de poder realizar búsquedas por palabras clave (al
estilo de un buscador como Google o Altavista), el sistema de recuperación de información
también ha de permitir al usuario navegar por la base de datos documental. Para ello, se han
de mantener los documentos clasificados por temas (al estilo de un directorio como Yahoo! o
dmoz.org). · Los temas se organizan de la forma tradicional formando una taxonomía (un tema
puede tener varios subtemas y ha de estar situado en una posición concreta dentro de la
jerarquía de temas). · Además, también se mantienen relaciones entre temas afines para
facilitar la navegación del usuario por la base de datos documental (por ejemplo, los algoritmos
de generación de números pseudoaleatorios usados en simulación están obviamente
relacionados con la Estadística, aunque probablemente no aparezcan dentro del tema
“Estadística” en nuestra clasificación oficial por temas). Por cuestiones de eficiencia, la base
de datos del sistema de recuperación de información almacenará de forma redundante los
siguientes datos (por ejemplo, para permitir la ordenación de los resultados obtenidos para una
consulta): · Para cada término, el número de documentos distintos en los que aparece y el
número total de veces que aparece en todos los documentos de la base de datos. · Para cada
documento, su tamaño (en palabras), el número de palabras diferentes que incluye y la
frecuencia de la palabra que más se repite en el documento.
7 Problema

Supongamos que se nos ha encargado el desarrollo de un sistema de información geográfica

(SIG). El objetivo del sistema es recopilar información acerca del uso del suelo en la provincia
de Granada. Tras analizar el problema, hemos obtenido la siguiente lista de requisitos: · El SIG
almacenará datos acerca de la división administrativa del terreno en parcelas, tal como figuran
en el catastro (coordenadas, superficie, altitud…). · A parte de las parcelas en sí, nos interesa
almacenar datos geológicos acerca de la composición de los suelos de la parcela. Ya que una
parcela puede tener zonas con distintos tipos de suelos, utilizaremos una capa diferente en
nuestro GIS para almacenar la información geológica acerca del suelo. NOTA: Para ver qué
zonas de terreno pertenecen a cada parcela utilizaremos la capacidad del GIS de realizar
consultas a partir de las coordenadas de las distintas áreas. · Nuestro sistema deberá mantener
información acerca de los propietarios de las distintas parcelas, teniendo en cuenta que una
parcela puede tener varios propietarios. · Los propietarios de una parcela, identificados por su
CIF, pueden ser personas físicas (con nombre, apellidos, DNI [CIF de una persona], fecha de
nacimiento, dirección y teléfono de contacto) o entidades jurídicas (con nombre, CIF, dirección
de la sede social y responsable administrativo, que es una persona). · Las parcelas pertenecen
a términos municipales. Cada municipio tiene un nombre único dentro de su provincia, aunque
distintas provincias pueden tener municipios con el mismo nombre. · También registraremos
datos climáticos en nuestro SIG, para lo cual mediremos las temperaturas (máxima y mínima)
y precipitaciones diarias para cada municipio, ya que no disponemos de los medios necesarios
para medir diariamente dichos datos en todas las parcelas en que se divide la zona geográfica
abarcada por nuestro GIS.

8 Problema

Supongamos que se nos ha encargado el diseño de una aplicación para la gestión de un

videoclub. Tras analizar detenidamente el problema, enumeramos los datos que nuestra
aplicación debe gestionar adecuadamente: • Hemos de mantener un registro de los clientes del
videoclub (DNI, nombre, apellidos, dirección y teléfono). • Nuestro videoclub oferta un amplio
catálogo de películas (título, año, director, reparto…). • Cada película la suministra una
distribuidora (nombre, dirección, url…). • De cada película, el videoclub dispone de una o varias
copias para alquilárselas a sus clientes. Cada copia viene identificada por un número de
registro. • Nuestra aplicación gestiona los alquileres de las copias de las películas. De cada
alquiler se almacenan, al menos, su fecha, la fecha de devolución de la copia y el importe que
el cliente ha de pagar. • Cada película tiene asociada una tarifa (p.ej. los alquileres de últimas
novedades, títulos clásicos y películas infantiles tienen precios diferentes). Para calcular el
importe de un alquiler, se utiliza la siguiente fórmula: total = base + extra*penalización, donde
extra es el número de días de más que el cliente se queda la copia de la película sin devolverla.
En otras palabras, cada tarifa tiene un precio base (en euros), un período de tiempo (expresado
en días) en el que el cliente puede quedarse su copia alquilada sin coste adicional y una
penalización para quien no devuelve las copias que alquila (en euros por día extra).
9 Problema

Supongamos que se nos ha encargado el desarrollo de un sistema de información para una

galería de arte. Tras analizar el problema, hemos obtenido la siguiente lista de requisitos: • El
sistema ofrecerá información acerca de las distintas exposiciones que estén programadas
(título, descripción, fecha de inauguración y fecha de clausura). • En cada exposición se
expondrán obras de distintos artistas. Cada obra vendrá identificada por un número de registro.
El sistema informará acerca del título, artista, estilo y precio de salida de cada una de las obras
de arte expuestas en las exposiciones. • Cada obra tiene un propietario, que suele ser el artista
que la creó, aunque esto no es necesariamente así. • Las obras expuestas se pueden comprar
haciéndole ofertas a sus propietarios. Al término de la exposición, el propietario de una obra
puede vender la obra a la persona que haya realizado la mejor oferta. NOTA: Es esencial que
en la base de datos no se almacenen datos de forma redundante, para lo cual hemos de tener
en cuenta que una misma persona puede ser propietaria de una obra de arte y realizar ofertas
para comprar otras obras de arte. De hecho, incluso puede ser responsable de la creación de
alguna de las obras expuestas.

10 Problema

Supongamos que se nos ha encargado el diseño de una aplicación para facilitar la gestión de los
proyectos de una empresa. Tras analizar detenidamente el problema, averiguamos que nuestra
aplicación debe cumplir los siguientes requisitos: • Se ha de mantener un registro de los
proyectos de la empresa (nombre en clave, denominación comercial, fecha de inicio, fecha de
finalización, estado actual…) • Nuestra aplicación gestionará los recursos humanos de la
empresa y le permitirá al usuario visualizar la ficha de cada empleado (DNI, nombre, apellidos,
dirección, teléfono, correo electrónico, fecha de contratación…). • Cada proyecto tiene un
promotor, que ha de ser uno de los empleados de la empresa y que ejercerá de jefe de proyecto
durante la duración del mismo. • Cada proyecto se descompone en una serie de tareas
(descripción, tipo, fecha de inicio estimada, fecha de inicio real, duración estimada, duración
real…). • Los empleados de la empresa se adscriben a las distintas tareas en las que se
descomponen los proyectos que en cada momento estén en marcha. • Asociados a cada tarea
se genera una serie de documentos (p.ej. el documento de especificación de requisitos, el
código fuente de un componente…). Cada documento viene caracterizado por su código (único
dentro del ámbito del proyecto al que corresponde), una descripción y su tipo. • Nuestro
sistema también se encarga de mantener almacenadas las distintas versiones de los documentos
que se van generando a lo largo del proyecto. A cada versión de cada documento, que se
almacena digitalizada en nuestro sistema, se le asocia también una descripción y una fecha.
11 Problema

Supongamos que se nos ha encargado el diseño de una aplicación para gestionar la liga BCD de
baloncesto. Tras analizar detenidamente el problema, averiguamos que nuestra aplicación
debe cumplir los siguientes requisitos: • En la liga participan 18 equipos. • Cada uno de los
equipos tiene su sede en un pabellón con una capacidad que determina el número máximo de
asistentes a un encuentro. • Cada equipo tiene una plantilla con una serie de jugadores (dorsal,
nombre, estatura, posición…). Para simplificar, suponemos que un jugador, una vez que juega
con un equipo, no puede competir con otro equipo distinto durante la misma temporada. •
Todos los equipos se enfrentan entre sí en una liga a doble vuelta de 34 jornadas. Esto es, cada
equipo juega 34 partidos (17 como local y 17 como visitante). • Nuestro sistema ha de
encargarse de mantener el calendario de encuentros de cada jornada, los resultados de los
partidos y las estadísticas de los distintos jugadores para cada partido (minutos jugados, puntos,
rebotes, asistencias, faltas personales…).

12 Problema

Supongamos que se nos ha encargado el diseño de una aplicación que sirva de soporte a la
organización de una reunión científica (congreso o seminario). Tras analizar detenidamente el
problema, averiguamos que nuestra aplicación debe cumplir los siguientes requisitos: • Los
congresistas (asistentes al congreso) se registran para poder asistir a las sesiones del congreso.
Al registrarse, han de indicar su nombre y primer apellido (fuera de España no se usa el segundo
apellido), la institución a la que pertenecen, una dirección de correo electrónico válida y,
opcionalmente, un número de teléfono móvil en el que recibirá notificaciones vía SMS. • En el
congreso se presentan trabajos remitidos por los propios congresistas. Cada trabajo tiene un
título, un “abstract” (un resumen del trabajo presentado) y una lista de autores asociada.
NOTA: Al menos uno de los autores debe estar registrado como asistente al congreso. • En cada
sesión del congreso se presenta un subconjunto de los trabajos aceptados para su publicación.
Cada sesión tiene asignada una sala donde se realizan las presentaciones en el día y la hora
establecidos por los organizadores del congreso. Cada trabajo se presenta en una única sesión.
• Cada trabajo de los presentados en una sesión es defendido por un ponente, que ha de ser
uno de los coautores del trabajo y debe aparecer registrado como asistente al congreso. • Cada
sesión es moderada por el “chairman” de la sesión, que también es un asistente al congreso
(usualmente, miembro del comité de organización del mismo).
13 Problema

Supongamos que se nos ha encargado el diseño de una aplicación que sirva de soporte al
funcionamiento de una red social online (una comunidad de usuarios con intereses comunes
que deciden ponerse en contacto e intercambiar opiniones e información acerca de sus temas
de interés). Tras analizar detenidamente el problema, averiguamos que nuestra aplicación debe
cumplir los siguientes requisitos: • Los usuarios de nuestra comunidad virtual se pueden
registrar gratuitamente en nuestro sistema. Una vez registrados, para acceder al mismo han de
usar su nombre de usuario o ‘nick’ y una contraseña que ellos mismos establecen al registrarse.
El usuario también ha de indicar una dirección de correo electrónico válida y, opcionalmente,
un número de teléfono móvil en el que recibirá notificaciones vía SMS. El perfil de un usuario
puede incluir, opcionalmente, la URL de su página web personal, su lugar de residencia (ciudad
y país), su fecha de nacimiento, una fotografía (o icono) y una breve descripción en la que el
usuario podrá especificar sus aficiones o preferencias. • Los usuarios podrán subscribirse a
distintos grupos, siendo cada grupo de usuarios gestionado por uno o varios moderadores que
pueden decidir a quién aceptan y a quién rechazan en el grupo. Cualquier usuario puede crear
nuevos grupos y solicitar su acceso a grupos ya existentes. Alguno de los moderadores deberá
aceptar o rechazar las solicitudes de acceso. En cualquier momento, el moderador puede
expulsar a alguien del grupo y el usuario puede darse de baja del grupo. • Los grupos estarán
organizados jerárquicamente y se podrán dividir en subgrupos (p.ej. el grupo “reseñas” puede
estar dividido en “reseñas de libros”, “críticas de películas” y “comentarios sobre
videojuegos”). • Los usuarios del sistema pueden enviar artículos a uno o varios grupos (textos
con información de interés para los miembros del grupo, como reseñas de libros, críticas de
productos, tutoriales técnicos de diversas materias, etc.). Cada artículo tendrá un identificador
único, una fecha de creación, un usuario responsable (el creador del artículo), un resumen
(como el “subject” de un e-mail) y un texto (el artículo en sí). También tendrá, para cada grupo
al que ha sido enviado, un estado editorial asociado (“enviado”, “aprobado” o “rechazado”)
que será controlado por los moderadores de cada grupo (para que puedan actuar como tales si
fuese necesario). • Una vez publicado un artículo, los demás usuarios de los grupos en los que
se publique el artículo podrán escribir comentarios sobre él. Cada comentario tendrá un
firmante (un usuario del sistema), una fecha, un texto y un estado editorial asociado. • Los
usuarios del sistema podrán enviar mensajes privados a otros usuarios del sistema (el sistema,
automáticamente, notificará por e-mail al recipiente del mensaje). • Los usuarios también
podrán publicar noticias de interés general que aparecerán en la página de bienvenida del
sistema. Las noticias, que estarán moderadas por los administradores del sistema, llevarán una
fecha asociada y caducarán automáticamente pasada esta fecha. • El sistema incluirá un
servicio automático de notificaciones, por lo que deberá mantener información de contacto de
cada usuario registrado (p.ej. e-mail o teléfono móvil para envío de SMSs), si bien esta
información será privada y no se compartirá con los demás miembros de la comunidad salvo
que así lo desee el usuario. • Cada usuario podrá mantener una lista de contactos personales
(otros usuarios con los que nuestro usuario quiere mantenerse en contacto). El sistema enviará
notificaciones a un usuario cada vez que alguien de su lista de contactos envíe algún artículo o
escriba un comentario. • Un usuario también podrá añadir artículos concretos a su lista de
marcadores (para poder acceder en cualquier momento a los artículos que considere
especialmente relevantes).
14 Clínica veterinaria

15 Problema

Supongamos que se nos ha encargado el diseño de una aplicación que sirva de soporte a un
sistema de compraventa de artículos mediante subastas a través de Internet (tipo eBay). Tras
analizar detenidamente el problema, averiguamos que nuestra aplicación debe cumplir los
siguientes requisitos: • Para poder realizar una operación de compraventa, los usuarios deben
registrarse en el sistema rellenando un formulario en el que han de especificar sus datos
personales (nombre, apellidos, dirección, e-mail). • Cuando un usuario desea poner en venta
un artículo, ha de rellenar otro formulario en el que especifica los datos del artículo que se
pone en venta (nombre y descripción), su estado (nuevo, usado…), su precio de salida y la fecha
límite de la subasta. • Para facilitar la búsqueda de artículos en venta, los artículos se organizan
en categorías. Cada categoría de artículos puede, a su vez, englobar otras categorías. Por
ejemplo, la categoría “libros” puede incluir a categorías como “ficción” [obras literarias], “no
ficción”, “primeras ediciones” o “libros firmados” y un libro concreto puede pertenecer a varias
categorías (p.ej. un ejemplar de la primera edición de una novela firmado por el autor). • Los
usuarios pujan por los artículos que desean comprar ofreciendo un precio mayor al ya ofrecido
por otros usuarios. El sistema registra el momento en que se realiza cada puja, la identidad del
postor y el precio que éste ofrece por el artículo subastado. • Finalmente, un artículo se
adjudica al usuario que, llegada la fecha límite de la subasta, haya realizado una puja mayor.
Si la puja mayor no alcanza el precio de salida del artículo, el propietario del artículo tiene la
posibilidad de declarar nula la subasta. Si no es así, tiene la obligación de vender el artículo al
precio ofrecido por el mejor postor.
16 Problema

Supongamos que se nos ha encargado el diseño de una base de datos que sirva de soporte a un
servicio web de búsqueda de empleo (tipo infojobs.net o monster.es). Tras analizar
detenidamente el problema, averiguamos que nuestro sistema debe cumplir los siguientes
requisitos: • Los usuarios de nuestro sistema pueden ser demandantes de empleo (candidatos)
o clientes corporativos (empresas) que usarán nuestro sistema para insertar ofertas de trabajo
y realizar procesos de selección. • Una vez registrados, los candidatos introducirán sus datos
de contacto (nombre, dirección, teléfono, e-mail) y podrán detallar su curriculum. • El
curriculum de un candidato incluirá su experiencia profesional (puesto, empresa, descripción
de responsabilidades, fecha de inicio y fecha de finalización de cada una de las actividades
profesionales que haya desempeñado) y su formación académica (título, especialidad,
institución y fecha, para cada una de sus titulaciones oficiales), así como otros méritos que el
candidato desee hacer constar. • Por su parte, las empresas serán las que podrán introducir
nuevas ofertas de empleo en nuestro sistema. • Entre los datos de cada oferta de empleo se
incluirán una descripción del puesto vacante, el número de vacantes que se ha de cubrir, la
fecha de la oferta, su ubicación (población, provincia y país) y los requisitos del puesto, así
como la duración del contrato, el horario de la jornada laboral y el salario asociado al puesto.
• Los requisitos asociados a una oferta de trabajo pueden ser requisitos mínimos que han de
cumplir los candidatos (nivel de estudios, experiencia previa, idiomas, etc.) o, simplemente,
requisitos deseables para el puesto. Obviamente, pueden ser varios para una misma oferta. •
Los candidatos, al ver una oferta de empleo de su interés, se inscribirán en ella para poder
participar el proceso de selección correspondiente. • Las ofertas de empleo se clasificarán por
categorías profesionales y estas categorías se organizarán de forma jerárquica para facilitar la
búsqueda de ofertas por parte de los demandantes de empleo (p.ej. “Business Intelligence”
como subcategoría de “Sistemas de Información” o “Estadística” como especialidad de
“Matemáticas”). • Los candidatos podrán subscribirse a un servicio de notificaciones por correo
electrónico de las ofertas de empleo correspondientes a las categorías que sean de su interés.

17 Problema

Supongamos que se nos ha encargado el diseño de una base de datos que sirva de soporte al
sistema de gestión de las nóminas de una empresa. Tras analizar detenidamente el problema,
averiguamos que nuestro sistema debe cumplir los siguientes requisitos: • La empresa tiene un
conjunto de empleados trabajando con contrato (un empleado puede firmar varios contratos a
lo largo de su carrera profesional). • Para cada empleado, el sistema almacena sus datos
personales (DNI, nombre, apellidos, teléfono, dirección) y el número de su cuenta corriente
para realizar las transferencias correspondientes a las nóminas. • Cada contrato firmado por
un empleado tiene una fecha de alta, una fecha de baja (nula si el contrato es indefinido), una
categoría asociada y un puesto de destino. • El sueldo base de un empleado depende de su
categoría. • En función del puesto de destino del empleado, el empleado puede recibir uno o
varios complementos, que se sumarán al sueldo base del empleado. • Además, por su
antigüedad en la empresa, el empleado cobrará trienios (cuyo importe depende de la categoría
de su contrato actual). • Por último, el empleado también cobrará complementos por los cargos
que desempeñe (durante la duración de su ocupación del cargo, que no tiene por qué coincidir
con la de su contrato). • De las percepciones salariales indicadas en los puntos anteriores, la
nómina de cada empleado incluirá una serie de deducciones (p.ej. aportaciones a la S.S.,
desempleo, formación profesional e I.R.P.F.). • Algunas de estas deducciones se calculan
mediante un porcentaje fijo (p.ej. 4.7% de contingencias comunes), mientras que otras se
calculan por tramos (p.ej. IRPF: 24% de 45k€ a 17k€, 28% de 17k€ a 32k€, 37% de 32k€ a 52k€,
43% a partir de 52k€). • El sistema debe almacenar todas las nóminas emitidas mensualmente
e incluir automáticamente tanto los distintos conceptos correspondientes a percepciones
salariales del empleado como los distintos tipos de deducciones a los que está sujeta su nómina.
18 problema

Supongamos que se nos ha encargado el diseño de un sistema para la gestión de proyectos de

una empresa, su planificación temporal y el uso que hacen de recursos de distintos tipos. Tras
analizar detenidamente el problema, enumeramos los requisitos que ha de cumplir el sistema:
• Hemos de mantener un registro de proyectos, cada uno de los cuales tiene un nombre en
clave que lo identifica, un título, una descripción, una fecha de inicio y una fecha de
finalización estimada. • Cada proyecto se descompone en un conjunto de tareas, cada una de
las cuales tiene un nombre y una duración estimada, así como una fecha de inicio prevista. •
Cada tarea, a su vez, también puede descomponerse en un conjunto de tareas (en tal caso, su
duración estimada será la suma de las duraciones estimadas de las tareas que la componen). •
Cada tarea de un proyecto hace uso de una serie de recursos, que pueden utilizarse a tiempo
completo o a tiempo parcial. La utilización de un recurso por parte de una tarea se expresa
mediante un porcentaje (%). • Los recursos pueden compartirse entre distintas tareas siempre
y cuando no se supere la disponibilidad de un recurso en un momento determinado, que también
se especifica como un tanto por ciento (p.ej. 200% indica dos unidades disponibles del recurso).
• Los empleados de la empresa son un tipo más de los recursos que pueden ser requeridos para
la realización de una tarea (obviamente, su disponibilidad nunca puede superar el 100%). •
Cada proyecto tiene un jefe de proyecto, que ha de ser un empleado de la empresa, y cada
tarea tiene también un responsable, que puede o no coincidir con el jefe del proyecto al que
corresponde (NOTA: el responsable de una tarea siempre será alguien del personal de la
empresa). • Algunas tareas tienen dependencias (esto es, para comenzar la realización de una
tarea han de haberse completado previamente las tareas de las que depende) y estas
dependencias han de identificarse para poder elaborar la planificación temporal de un proyecto
concreto, que también tendrá en cuenta el uso de recursos requerido por cada tarea (para
evitar sobreasignaciones).

19 problema

Crear un diseño entidad relación (estando prohíbido utilizar símbolos del modelo extendido)
que permita gestionar los datos de una biblioteca de modo que

• Las personas socias de la biblioteca disponen de un código de socio y además necesitar

almacenar su dni, dirección, teléfono, nombre y apellidos
• La biblioteca almacena libros que presta a los socios y socias, de ellos se almacena su
título, su editorial, el año en el que se escribió el libro, el nombre completo del autor
(o autores), el año en que se editó y en qué editorial fue y el ISBN.
• Necesitamos poder indicar si un volumen en la biblioteca está deteriorado o no
• Queremos controlar cada préstamo que se realiza almacenando la fecha en la que se
realiza, la fecha tope para devolver (que son 15 días más que la fecha en la que se
realiza el préstamo) y la fecha real en la que se devuelve el libro
20 problema

Crear un diseño entidad relación que permita controlar el sistema de información de una
academia de cursos siguiendo estas premisas:

• Se dan clases a trabajadores y desempleados. Los datos que se almacenan de los

alumnos son el DNI, dirección, nombre, teléfono y la edad
• Además de los que trabajan necesitamos saber el CIF, nombre, teléfono y dirección de
la empresa en la que trabajan
• Los cursos que imparte la academia se identifican con un código de curso. Además se
almacena el programa del curso, las horas de duración del mismo, el título y cada vez
que se imparte se anotará las fechas de inicio y fin del curso junto con un número
concreto de curso (distinto del código) y los datos del profesor o profesora (sólo uno
por curso) que son: dni, nombre, apellidos, dirección y teléfono
• Se almacena la nota obtenida por cada alumno en cada curso teniendo en cuenta que
un mismo alumno o alumna puede realizar varios cursos y en cada cual obtendrá una
nota.

21 problema

Crear un diseño entidad relación que permita almacenar datos geográficos referidos a España:

• Se almacenará el nombre y población de cada localidad, junto con su nombre y los

datos de la provincia a la que pertenece la localidad, su nombre, población y superficie.
• Necesitamos también conocer los datos de cada comunidad autónoma, nombre,
población y superficie y por supuesto las localidades y provincias de la misma
• Para identificar a la provincia se usarán los dos primeros dígitos del código postal. Es
decir 34 será el código de Palencia y 28 el de Madrid
• Necesitamos saber qué localidad es la capital de cada provincia y cuáles lo son de cada
comunidad
22 problema

Diseñar un modelo entidad/relación que almacene los datos de todas las guerras de la historia
de modo que:

• Se almacene el año en el que empezó la guerra y el año en que terminó, así como su
nombre y el de los paises contendientes, pudiendo indicar además quienes fueron las
ganadores
• Hay que tener en cuenta que los paises se pueden unir a la guerra a uno u otro bando
(suponemos que solo hay dos bandos) después de comenzada la guerra (como EEUU en
la 2ª guerra mundial) y que incluso pueden abandonar la guerra antes de que esta
finalice (como Rusia en la 1ª guerra mundial)
• Los paises que se almacenan en la base de datos pueden no ser paises actualmente
(como Prusia, Aragón, Asiria,etc.) por lo que se ha contemplado que en la base de datos
se almacenen los años en los que el país ha sido independiente, teniendo en cuenta que
hay paises que ha habido momentos en los que ha sido independiente y otros en los que
no (por ejemplo Croacia). Bstará con almacenar los periodos en los que ha sido
independiente.

23 problema

Se trata de crear una base de datos sobre un almacén de piezas de modo que:

• Cada pieza se identifica con dos letras (tipo, por ejemplo TU=tuerca) y un número
(modelo, por ejemplo 6)
• Almacenamos un atributo que permite saber la descripción de cada tipo de pieza. Es
decir el tipo TU tendrá la descripción tuerca.
• Necesitamos conocer el precio al que vendemos cada pieza.
• Además hay piezas que se componen de otras piezas, por ejemplo una puerta se
compone de una hoja de madera, una bisagra y un picaporte. Incluso una pieza puede
estar compuesta de otras piezas que ha su vez pueden estar compuestas por otras y así
sucesivamente
• Tenemos una serie de almacenes de los que guardamos su número, descripción,
dirección y el nombre de cada estantería de almacén. Cada estantería se identifica por
tres letras.
• Necesitaremos saber la cantidad de piezas que tenemos en cada almacén y saber en
qué estanterías están las piezas buscadas
24

Se trata de crear una base de datos sobre el funcionamiento de una biblioteca

• Almacenaremos el DNI, nombre, apellidos, código de socio, dirección y teléfonos

(pueden ser varios, pero al menos uno)
• La biblioteca presta libros, CDs y películas. De todos ellos se almacena un código de
artículo distinto para cada pieza en la biblioteca. Es decir si tenemos tres libros del
Quijote, los tres tendrán un número distinto de artículo.
• Además almacenamos el nombre de cada artículo, el año en el que se hizo la obra (sea
del tipo que sea) un resumen de la obra y los datos de los autores del mismo. Se
considera autor de la película al director, de la música al intérprete y del libro al
escritor. Pero de todos ellos se guarda la misma información: nombre y país.
• De los libros además se guarda el número de páginas, de los CDs el número de canciones
y de la película la duración
• Anotamos si un artículo concreto está deteriorado y un comentario sobre el posible
deterioro
• Cuando se presta un artículo, se anota fecha en la que se presta y la fecha tope para
devolverle. Cuando el socio le devuelve, se anota la fecha de devolución.
• No hay tope sobre el número de artículos que puede prestarse a un socio e incluso el
socio podría llevarse varias veces el mismo artículo en distintos préstamos

25

Crear el esquema entidad/relación que represente el organigrama de una empresa, de modo

que:

• Aparezcan los datos de todos los empleados y empleadas: dni, nº de seguridad social,
código de trabajador, nombre, apellidos, dirección, teléfono y departamento en el que
trabajan indicado por su código y nombre.
• También hay que tener en cuenta que cada trabajador puede tener un responsable (que
en realidad es otro trabajador)
• Los departamentos poseen un único coordinador del mismo
• Necesitamos almacenar la categoría profesional de los trabajadores y trabajadoras,
teniendo en cuenta que la categoría a veces cambia al cambiar el contrato, de los
contratos se almacena la fecha de inicio del mismo y la fecha final (un contrato en
vigor tendrá como fecha final el valor nulo).
• También controlaremos las nóminas que ha recibido el trabajador de las que sabemos
la fecha, el salario y a qué trabajador van dirigidas y la categoría del mismo.
26 Vuelos

Crear el esquema entidad/relación que permita gestionar reservas de vuelos, de modo que:

• Los clientes pueden reservar vuelos. Con la reserva se pueden reservar varias plazas,
pero no poseeremos el número de asiento hasta obtener la tarjeta de embarque. En
ese instante se asignará el asiento que tiene como identificación la fila, columna y la
planta en la que está situado.
• Se pueden obtener tarjetas de embarque sin tener reserva
• Las tarjetas de embarque se refieren a un único cliente. De modo que aunque
reserváramos nueve plazas, cada cliente podrá sacar su tarjeta de embarque indicando
el número de reserva, la fecha de la misma y sus datos personales (dni, nombre,
apellidos, dirección y teléfono). Además la persona que reserva debe indicar una
tarjeta de crédito que quedará asociada a esa persona.
• El vuelo que se reserva tiene un código único, una fecha y una hora de salida y de
llegada y un aeropuerto de salida y otro de llegada
• Los aeropuertos poseen un código único, además del nombre y la localidad y el país en
el que se encuentran
• Se guarda información sobre los aviones, código y número de plazas. Los vuelos sólo les
puede realizar un avión determinado, pero el mismo avión puede realizar (como es
lógico) otros vuelos

27

Crear el esquema entidad/relación que permita gestionar los datos sobre preparación de rectas
de cocina
28

Crear el esquema entidad/relación que permita crear el diseño de una base de datos que
almacena información sobre los partidos de una liga de futbol una temporada. Hay que tener
en cuenta que en dicha liga los jugadores no pueden cambiar de equipo

29 Accidentes geográficos

Realizar un esquema entidad/relación que sirva para almacenar información geográfica. Para
ello hay que tener en cuenta

o Se almacenan los siguientes accidentes geográficos: ríos, lagos y montañas

o De cada accidente se almacenan su posición horizontal y vertical según el eje
de la tierra, además de su nombre
o De los ríos se almacena su longitud, de las montañas su altura y de los lagos su
extensión
o Se almacena también información sobre cada país, su nombre, su extensión y
su población
o Se desea almacenar información que permite saber en qué país está cada
accidente geográfico, teniendo en cuenta que cada accidente puede estar en
más de un país.
o Se almacena también los nombres de cada localidad del planeta. Y se almacena
por qué localidades pasa cada río.
30 Empresa de software

Realizar un esquema entidad/relación que permita modelar el sistema de información de una

empresa de software atendiendo las siguientes premisas

• La empresa crea proyectos para otras empresas. De dichas empresas se almacena el

CIF, nombre, dirección y teléfono así como un código interno de empresa.
• Los proyectos se inician en una determinada fecha y finalizan en otra. Además al
planificarle se almacena la fecha prevista de finalización (que puede no coincidir con
la finalización real)
• Los proyectos los realizan varios trabajadores, cada uno de ellos desempeña una
determinada profesión en el proyecto (analista, jefe de proyecto, programador,…),
dicha profesión tiene un código de profesión. En el mismo proyecto puede haber varios
analistas, programadores,…
• Todos los trabajadores tienen un código de trabajador, un dni, un nombre y apellidos.
Su profesión puede cambiar según el proyecto: en uno puede ser jefe y en otro un
programador
• Se anota las horas que ha trabajado cada trabajador en cada proyecto.
• Puede haber varios proyectos que comiencen el mismo día.
• A todas las empresas les hemos realizado al menos un proyecto
• Todos los trabajadores han participado en algún proyecto
• En la base de datos, la profesión “administrador de diseño” no la ha desempeñado
todavía ningún trabajador o trabajadora

31 Empresa de comidas

Crear un diseño entidad/relación para una empresa de comidas. En la base de datos tienen que
figurar:

• El nombre y apellidos de cada empleado, su dni y su número de SS además del teléfono

fijo y el móvil
• Algunos empleados/as son cocineros/as. De los cocineros y cocineras anotamos (además
de los datos propios de cada empleado) sus años de servicio en la empresa.
• Hay empleados/as que son pinches. De los y las pinches anotamos su fecha de
nacimiento.
• La mayoría de trabajadores no son ni pinches ni cocineros/as
• En la base de datos figura cada plato (su nombre como “pollo a la carloteña”, “bacalo
al pil-pil”,…), el precio del plato junto con los ingredientes que lleva. Anotamos
también si cada plato es un entrante, un primer plato, segundo plato o postre
• De los ingredientes necesitamos la cantidad que necesitamos de él en cada plato y en
qué almacén y estantería del mismo le tenemos.
• Cada almacén se tiene un nombre (despensa principal, cámara frigorífica A, cámara
frigorífica B…), un número de almacén y una descripción del mismo.
• Cada estante en el almacén se identifica con dos letras y un tamaño en centímetros.
Dos almacenes distintos pueden tener dos estantes con las mismas letras.
• Necesitamos también saber qué cocineros son capaces de preparar cada plato.
• Cada pinche está a cargo de un cocinero o cocinera.
• La cantidad de ingredientes en cada estantería de un almacén se actualiza en la base
de datos al instante. SI cogemos dos ajos de un estante, figurará al instante que
tenemos dos ajos menos en ese estante. Es necesario por lo tanto saber los ingredientes
(cuáles y en qué número) que tenemos en cada estante.
32. Red social

Crear un diseño entidad/relación que permita modelar un sistema que sirva para simular el
funcionamiento de una red social, teniendo en cuenta lo siguiente:

• Los usuarios de la red social se identifican con un identificador y una contraseña.

Además se almacena de ellos:
o Su nombre, apellidos, dirección, teléfono (puede tener varios teléfonos) e e-
mail (el e-mail no tiene que poder coincidir con el de otro usuario) y una foto
o Si los usuarios son celebridades, de ellos no aparecerá ni el email ni la dirección
ni el teléfono.
• Los usuarios pueden tener una serie de contactos, que en realidad son otros usuarios.
De cada contacto se puede almacenar un comentario que es personal y que sirve para
describir al contacto.
• Los usuarios pueden organizar sus contactos en grupos de los cuales se almacena un
nombre y deberemos saber los contactos que contiene. El mismo contacto puede formar
parte de varios grupos.
• Además cada usuario puede tener una lista de usuarios bloqueados a fin de que no
puedan contactar con él
• Los usuarios pueden publicar en la red comentarios, los cuales se puede hacer que los
vea todo el mundo, que los vea uno o varios de los grupos de contactos del usuario o
bien una lista concreta de usuarios. Los comentarios pueden incluir un texto y una
imagen.

33. Menú diario

Crear un esquema Entidad/relación que represente un modelo para llevar los datos que maneja
un restaurante de menús diarios. Teniendo en cuenta que:

• Sólo interesa llevar los datos de los menús diarios a la hora de la comida, nada más del
restaurante
• Cada menús se compone de una serie de posibles platos. cada plato se puede repetir
en diferentes días. Los platos pueden ser primer plato, segundo plato o postres.
• De cada plato se almacena el nombre (por ejemplo Arroz negro con setas) y una
pequeña descripción.
• De los menús almacenamos la fecha en la que se ofrece el menú, el número de personas
que han tomado menú ese día. Además almacenamos la cantidad de cada plato que se
ha tomado ese día.
• Se almacena también la temperatura que hacía el día del menú para así poder analizar
las temperaturas y los platos exitosos
34. Twitter

Crear un esquema Entidad/relación que represente un modelo para llevar los datos que maneja
la red social Twitter: usuarios, mensajes,...
35. Horario escolar

Crear un esquema Entidad/relación que represente el funcionamiento de un centro escolar de

formación profesional, teniendo en cuenta que:

• Sólo interesa llevar el control de ocupación de las aulas en el horario escolar

• El horario es de seis horas diarias y en la base de datos simplemente se anota si es la
primera, segunda,… y el día de la semana del que hablamos (por ejemplo miércoles a
tercera hora)
• Las asignaturas tienen un nombre, un código interno del centro y un código europeo.
La misma asignatura se puede impartir en dos ciclos distintos y en ese caso tendría el
mismo código europeo y nombre, pero el código interno sería distinto. Hace falta saber
en qué curso del ciclo se imparte la asignatura
• Los ciclos tienen un nombre, pueden ser de grado superior,de grado medio o de
iniciación profesional; además tienen otro código interno en el centro.
• Las asignaturas en cada momento ocupan un aula, del que tenemos que almacenar un
código de aula, un nombre (que no se repite), un número de aula (que tampoco se
repite) y los metros que tiene. A una hora concreta de la semana, el aula puede estar
vacia o bien ocuparse, pero sólo se puede ocupar por una asignatura
• Necesitamos saber y anotar en la base de datos si una asignatura requiere que antes se
hayan aprobado otras, para poder matricularse en ella. Por ejemplo, Ampliación de
Matemáticas de 2º a lo mejor requiere aprobar Matemáticas de 1º. Puede requerirse
terminar más de una asignatura previamente para poder matricularse de una concreta.
• Se entiende que la asignatura sólo la puede impartir un profesor en todo el año, siempre
será uno en todo momento el titular
• De los profesores se almacena su nombre, dirección, teléfono, email, DNI, nº de
Seguridad Social y un código interno de profesor así como los años que tiene de
antigüedad impartiendo cada asignatura. Puede ser cada profesora o profesor, tutora
de un curso y también se anota la antigüedad que tiene en esa tarea

Complicamos el esquema anterior en este sentido

• Siendo más realistas, nos damos cuenta de que en un curso escolar, puede haber varios
profesores responsables de una asignatura (por bajas, ceses, etc.); por lo que anotamos
cuándo empezó a impartir dicho profesor la asignatura y cuando terminó (si no ha
terminado, se dejaría vacío)
• Asegurar que podemos averiguar gracias al diseño, que si buscamos a un profesor un
día concreto (por ejemplo el 13 de Mayo de 2012) a una hora concreta (sexta hora),
podríamos saber en qué aula va a estar.
36. Inmuebles

Crear un diseño entidad/relación que permita modelar un sistema que sirva para gestionar una
empresa que posee inmuebles. Para ello

• Se almacenan los clientes usando su DNI, Teléfono fijo, Móvil, Nombre y Apellidos.
• Se almacenan los trabajadores y se almacenan los mismos datos. Ocurre además que
un trabajador puede ser un cliente (porque puede alquilar o comprar mediante la
inmobiliaria) a veces.
• A cada cliente y trabajador se le asigna un código personal
• Los clientes pueden comprar pisos, locales o garajes. En los tres casos se almacena un
código de inmueble (único para cada inmueble), los metros que tienen, una descripción
y su dirección.
• Los pisos tienen un código especial de piso que es distinto para cada piso.
• En los locales se indica el uso que puede tener y si tienen servicio o no.
• De los garajes se almacena el número de garaje (podría repetirse en distintos edificios)
y la planta en que se encuentra (para el caso de garajes que están en varias plantas).
Los garajes además pueden asociarse a un piso y así cuando se alquile el piso se incluirá
el garaje.
• La empresa prevé que podría haber inmuebles que podrían no ser ni locales, ni garajes,
ni pisos
• Los inmuebles se pueden comprar. Incluso varias veces. Se asigna un código de compra
cada vez que se haga, la fecha y el valor de la compra. La compra puede tener varios
titulares.
• Cada inmueble se puede alquilar y en ese caso se asigna un número de alquiler por cada
inmueble. Ese número se puede repetir en distintos inmuebles (es decir puede haber
alquiler nº 18 para el inmueble 40 y el 35). Pero no se repite para el mismo inmueble.
• Al alquilar queremos saber el nombre del agente de la empresa que gestionó el alquiler
así como a qué persona (solo una) estamos alquilando el inmueble.
• Cada pago de cada alquiler será almacenado en la base de datos, llevando el año, el
mes y el valor del mismo.