Diseo Lgico

1. Convertir el esquema conceptual en el esquema lgico.

2. Derivar un conjunto de relaciones (tablas) el esquema
lgico.
3. Validar el esquema mediante la normalizacin.
4. Validar el esquema lgico frente a las transacciones del
usuario.
5. Redibujar el diagrama entidad-relacin.
6. Definir las restricciones de integridad.
7. Revisar el esquema lgico con los usuarios.
8. Estudiar el crecimiento futuro.

Convertir el esquema conceptual en el

esquema lgico.
En este paso, se eliminan del esquema conceptual las
estructuras de datos que los sistemas relacionales no
modelan directamente:
(a) Eliminar las relaciones de muchos a muchos, sustituyendo
cada una de ellas por una nueva entidad y dos relaciones de uno
a muchos de esta nueva entidad con las entidades originales.

EMP

WORK
M

PROJ
N

EMP

EW
1

WORKS
N

WP
N

PROJ
1

Eliminar del esquema conceptual las estructuras

de datos que los sistemas relacionales no
modelan directamente (2)
(b)
Eliminar
las
relaciones
entre
tres
o
ms
entidades,
sustituyendo
cada
una de ellas por una
nueva entidad (dbil)
intermedia que se
relaciona con cada
una de las entidades
originales.
La
cardinalidad de estas
nuevas
relaciones
binarias depender
de su significado.

Eliminar del esquema conceptual las estructuras de

datos que los sistemas relacionales no modelan
directamente (3)
(c) Eliminar las relaciones recursivas, sustituyendo cada
una de ellas por una nueva entidad (dbil) y dos relaciones
binarias de esta nueva entidad con la entidad original. La
cardinalidad de estas relaciones depender de su significado.
EMPLOYEE

EMPLOYEE
1

N
SUPERVISION

SUPERVISOR

N
SUPERVISA

1
SUPERVISOR

SUPERVISADO

(d) Eliminar las relaciones con atributos, sustituyendo cada

una de ellas por una nueva entidad. La cardinalidad de estas
relaciones depender del tipo de la relacin original y de su
significado. (MANAGES 1:1, WORKS_ON M:N)
(e) Eliminar los atributos multievaluados, sustituyendo cada
uno de ellos por una nueva entidad y una relacin binaria de
uno a muchos con la entidad original. (LOCATION)

Eliminar del esquema conceptual las

estructuras de datos que los sistemas
relacionales no modelan directamente (4)
(f) Revisar las relaciones de uno a uno, ya que es
posible que se hayan identificado dos entidades que
representen el mismo objeto (sinnimos). Si as fuera,
ambas entidades deben integrarse en una sola.
(g) Eliminar las relaciones redundantes. Una relacin
es redundante cuando se puede obtener la misma
informacin que ella aporta mediante otras relaciones. El
hecho de que haya dos caminos diferentes entre dos
entidades no implica que uno de los caminos
corresponda a una relacin redundante, eso depender
del significado de cada relacin.

Derivar un conjunto de relaciones

(tablas) para el esquema lgico global
En este paso, se obtiene un conjunto de relaciones
(tablas) para el esquema lgico global en donde se
representen las entidades y relaciones entre entidades,
que se describen en cada una de las vistas que los
usuarios tienen de la empresa.
Cada relacin de la base de datos tendr un nombre, y
el nombre de sus atributos aparecer, a continuacin,
entre parntesis.
El atributo o atributos que forman la clave primaria se subrayan.
Las claves ajenas, mecanismo que se utiliza para representar
las relaciones entre entidades en el modelo relacional, se
especifican aparte indicando la relacin (tabla) a la que hacen
referencia.

(a) Entidades fuertes. Crear una relacin para

cada entidad fuerte que incluya todos sus atributos
simples. De los atributos compuestos incluir slo
sus componentes
Escoger la clave candidata que tenga menos atributos.
Escoger la clave candidata cuyos valores no tengan probabilidad de
cambiar en el futuro.
Escoger la clave candidata cuyos valores no tengan probabilidad de perder
la unicidad en el futuro.
Escoger la clave candidata con el mnimo nmero de caracteres (si es de
tipo texto).
Escoger la clave candidata ms fcil de utilizar desde el punto de vista de
los usuarios.
Tablas Generadas
EMPLOYEE ( SSN, FName, Mint, LName, BDate, Address, Sex, Salary)
DEPARTMENT (DNumber, DName)
PROJECT ( PNumber, Pname, PLocation)

(b) Entidades dbiles

Crear una relacin para cada entidad dbil incluyendo
todos sus atributos simples. De los atributos compuestos
incluir slo sus componentes.
Aadir una clave ajena a la entidad de la que depende.
Para ello, se incluye la clave primaria de la relacin que
representa a la entidad padre (FK) en la nueva relacin
creada para la entidad dbil.
La clave primaria de la nueva relacin es la combinacin
de la FK y la llave parcial

Ejemplo:
DEPENDENT (SSN DependentName,
Sex, BirthDate, Relationship)

(c) Relaciones binarias de uno a uno.

Para cada relacin binaria se incluyen los atributos de la clave
primaria de la entidad padre en la relacin (tabla) que representa a la
entidad hijo, para actuar como una clave ajena.
La entidad hijo es la que participa de forma total (obligatoria) en la
relacin,
mientras que la entidad padre es la que participa de forma parcial
(opcional).
Si las dos entidades participan de forma total o parcial en la relacin,
la eleccin de padre e hijo es arbitraria. Adems, en caso de que
ambas entidades participen de forma total en la relacin, se tiene la
opcin de integrar las dos entidades en una sola relacin (tabla). Esto
se suele hacer si una de las entidades no participa en ninguna otra
relacin.
Se aade cualquier atributo de la interrelacin: MGRStartDate
RELACIN: MANAGES 1:1
EMPLOYEE ( SSN, FName, Mint, LName, BDate, Address, Sex, Salary)
DEPARTMENT (DNumber, DName, MGRSsn, MGRStartDate)

(d) Relaciones binarias de uno a

muchos.
Como en las relaciones de uno a uno, se incluyen los
atributos de la clave primaria de la entidad padre en la
relacin (tabla) que representa a la entidad hijo, para
actuar como una clave ajena.
Pero ahora, la entidad padre es la de ``la parte del
muchos'' (cada padre tiene muchos hijos),
mientras que la entidad hijo es la de ``la parte del uno''
(cada hijo tiene un solo padre).
RELACIN: WORKS_FOR 1:N
EMPLOYEE ( SSN, FName, Mint, LName, BDate, Address, Sex,
Salary, Dno)
DEPARTMENT (DNumber, DName, MGRSsn, MGRStartDate)

(e) Relaciones binarias de muchos a

muchos.
Crear una nueva tabla conteniendo
FKs para mbas entidades participando en la
interrelacin
Atributos de las interrelaciones

Ejemplo:
INTERRELACIN WORKS_ON M:N
WORKS_ON (ESsn Pno, Hours)

f). Atributos Multievaluados

Crear una nueva tabla conteniendo
PK de la entidad a ser FK de la nueva entidad
Atributo multievaluado

PK contiene la FK ms el atributo
multievaluado
Ejemplo
DEPT_LOCATION (DNumber, DLocation)

(e) Jerarquas de generalizacin.

En las jerarquas, se denomina entidad padre a la entidad genrica y

entidades hijo a las subentidades. Hay tres opciones distintas para
representar las jerarquas. La eleccin de la ms adecuada se har en
funcin de su tipo (total/parcial, exclusiva/superpuesta).
Crear una relacin por cada entidad. Las relaciones de las entidades hijo
heredan como clave primaria la de la entidad padre. Por lo tanto, la clave
primaria de las entidades hijo es tambin una clave ajena al padre. Esta
opcin sirve para cualquier tipo de jerarqua, total o parcial y exclusiva o
superpuesta.
Crear una relacin por cada entidad hijo, heredando los atributos de la
entidad padre. Esta opcin slo sirve para jerarquas totales y
exclusivas.
Integrar todas las entidades en una relacin, incluyendo en ella los
atributos de la entidad padre, los atributos de todos los hijos y un atributo
discriminativo para indicar el caso al cual pertenece la entidad en
consideracin. Esta opcin sirve para cualquier tipo de jerarqua. Si la
jerarqua es superpuesta, el atributo discriminativo ser multievaluado.

f). Interrelaciones terniarias

Crear una nueva tabla conteniendo una
llave fornea referenciando cada una de
las 3 entidades involucradas
Incluir cualquier atributo de la interrelacin
PK es usualmente la combinacin de las
tres FK

Reflexiones acerca del Diseo

Usted necesita usar su discrecin para
escoger sus PK
El esquema relacional que ud. obtiene
siguiendo el algoritmo de mapeo
ER_tablas puede mostrar deficiencias
Si el esquema relacional no le parece
adecuado vuelva a revisar su diagrama
E_R

Cuntas Relaciones?

Se debe obtener una relacin por cada:

Entidad (regulares y dbiles)
Interrelaciones M:N
Atributos multievaluados
Interrelaciones terniarias

Anlisis de Requerimientos para una BD

de un Banco
Un banco se identifica por un cdigo nico,
nombre y direccin y tiene sucursales.
Cada sucursal se identifica por su nmero y su
direccin. Las sucursales pueden abrir mltiples
cuentas y hacer mltiples prstamos a sus
clientes.
Una cuenta tiene un nmero nico, balance y
tipo.
Un prstamo tiene un nmero nico, una
cantidad y un tipo.
Los clientes son registrados por su ID (SSN,
CURP). Adems debe conocerse de ellos su
nombre, direccin y telfono.

Esquema de la BD BANK
BANK
CODE

NAME

ADDRESS

ACCOUNT
ACCTNO

BALANCE

TYPE

BCODE

FK

CUSTOMER
SSN

NAME

PHONE

BNO

FK

ADDRESS

LOAN
LOANNO

AMOUNT

TYPE

BCODE

FK
BANK-BRANCH
BCODE BRANCHNO

A-C

FK

SSN ACCTNO

L-C

FK

FK

SSN LOANNO

FK

FK

ADDR

BNO

FK

Anlisis de Requerimientos de la BD LIBRARY

Las bibliotecas almacenan copias de libros, los
organiza por editoriales y lleva el control de los
usuarios a quienes les presta libros (su fecha de
prstamo y de devolucin).
Por cada biblioteca se conoce su nombre y su
direccin
De los libros se registra su ISBN, ttulo y nombre
del autor(es).
De las editoriales se desea saber su nombre,
direccin y telfono.
Por cada usuario se registra tambin su nombre
direccin y telfono

Diagrama E_R de la BD LIBRARY

Autor

Isbn
Ttulo

Idl

LIBRO
M

Direc

Nombre
1

N
ORGANIZA

Telef

EDITORIAL

N
FPrestamo

ALMACENACOPIAS

PRESTA

NoCopias
N

FDevolucion
M

USUARIO

BIBLIOTECA
Idu
Nombre

Direc

Nombre

Direc

Telef

Esquema de la BD LIBRARY
LIBRO
IDL

ISBN

TITULO

NOMEDIT

AUTOR
IDL

NOMBRE

EDITORIAL
NOMBRE

DIRECCION

TELEFONO

PRESTA
IDL

NOMBREBIB

IDU

FPRESTAMO

ALMACENA_COPIAS
IDL NOMBREBIB

NODECOPIAS

BIBLIOTECA
NOMBRE DIRECCION

USUARIO
IDU

NOMBRE

DIRECCION TELEFONO

FDEVOLUCION

Anlisis de Requerimientos para una

compaa de camiones TRUCKERS
TRUCKERS es responsable por recoger cargamentos
(SHIPMENTS) desde los almacenes (WAREHOUSES) de una
cadena de tiendas (STORES) llamada WALMART, y entregar
estos cargamentos a cada una de las tiendas. Actualmente hay
6 WAREHOUSES y 45 STORES.
Un camin (TRUCK) puede llevar varios cargamentos en un
solo viaje (TRIP) , el cual es identificado por Trip#, y entrega
los cargamentos a mltiples tiendas .
Cada cargamento es identificado por un Shipment#, e incluye
datos acerca de sus volmenes (volume) y peso (weight)
permitidos.
La compaa tiene 150 camiones, y un camin hace de 3 a 4
viajes cada semana.

TRUCKERS_ WAREHOUSES DB
Tipo

WAREHOUSE

Location

M
VolCapacity
FROM
Truck#
Date

WeightCapacity

N
1

TRIP

TRUCK

TRUCK_USED

Trip#
1
INCLUDES
N

SHIPMENT

Shipment#

Weight
Volume

DESTINATION

STORE

StoreName

Address

Esquema de la BD TRUCKERS - WAREHOUSES

WAREHOUSE
LOCATION

TIPO

TRIP

FK

TRIPNO

DATE

TRUCKNO

SHIPMENT

FK

SHIPMENTNO

VOLUME

WEIGHT

TRIPNO

TRUCK
TRUCKNO

VOLCAPACITY

STORE
STORENAME ADDRESS

FROM
LOCATION TRIPNO

FK
FK
DESTINATION
SHIPMENTNO STORENAME

FK

FK

WEIGHTCAPACITY

Anlisis de Requerimientos para una BD

de una Lnea Area
The DB represents each AIRPORT, keeping its unique
AirportCode, the Airport Name, and the City and State in
which the airport is located.
Each airline FLIGHT has a unique number, the Airlline for the
FLIGHT, and the Weekdays on which the FLIGHT is
scheduleded (for example, every day of the week except
Sunday can be coded as X7)
A FLIGHT is composed of one or more FLIGTH LEGs (for
example, flight number CO1223 from New York to Los
Angeles may have two FLIGHT LEGs: leg 1 from New York
to Houston and leg 2 from Houston to Los Angeles). Each
FLIGHT LEG has a DEPARTURE AIRPORT and Scheduled
Departure Time, and an ARRIVAL AIRPORT and an
Scheduled Arrival Time.

Anlisis de Requerimientos para una BD

de una Lnea Area
A LEG INSTANCE is an instance of a FLIGHT LEG on an
specific Date ( for exampleCO1223 leg 1 on July 30, 1989). The
actual Departure and Arrival AIRPORTs and Times are
recorded for each flight leg after the flight leg has been
concluded. The Number of available seats and the AIRPLANE
used in the LEG INSTANCE are also KEPT.
The customer RESERVATION on each LEG INSTANCE
include the Customer Name, Phone, and Seat Number(s) for
each reservation.
Information on AIRPLANE TYPEs are also kept. For each
AIRPLANE TYPE (for example CD-10), the TypeName,
manufacturing Company, and Maximum Number of Seats are
kept. The AIRPORTs in which planes of this type CAN LAND
are kept in the DB. For each AIRPLANE, The AirplaneId, Total
number of seats, and TYPE are kept.

Esquema de la BD LINEA AEREA

AIRPORT
AIRPORT-CODE

NAME

CITY

STATE

FLIGHT
NUMBER

AIRLINE

WEEKDAYS

LEG-INSTANCE
FLIGHT#

LEG#

DATE

#AVSEATS

AIRPLANEID

DEP-AIRP.-CODE

DEP-TIME

ARR.-AIRP.-CODE

ARR.-TIME

FLIGHT-LEG
FLIGHTNUMBER

LEG-NUMBER

DEP-AIRP.-CODE

SCHED-DEP-TIME

ARR.-TIME

AIRPLANE-TYPE

FARES
FLIGHT-NUMBER

ARR.-AIRP.-CODE

FARE-CODE

AMOUNT

RESTRICTIONS

MAX-SEATS

COMPANY

AIRPLANE

CAN-LAND
TYPE-NAME

TYPE-NAME

AIRPLANEID

AIRPORT-CODE

#TOTALSEATS

TYPE-NAME

RESERVATION
FLIGHT#

LEG#

DATE

SEAT#

CUSTOMERNAME

CUSTOMERPHONE

Anlisis de Requerimientos para una BD

de un Club Nutico
En un Club Nutico un socio tiene embarcaciones y compra amarres para
estas debindose registrar la fecha de compra. Los amarres estn en una
zona.
Los socios se identifican por un id, nombre, direccin, telfono y fecha en
que obtuvieron la membresa.
De las embarcaciones debe registrarse matrcula, nombre, tipo y
dimensiones.
Los empleados atienden zonas, especificndose el nmero de barcos que
atiende cada empleado en cada zona. Los empleados se definen por id,
nombre, direccin, telfono y especialidad.
La zona se define por una letra nica, tipo, profundidad y ancho.
Cada embarcacin ocupa un amarre en una fecha determinada. El amarre
se identifica por nmero, agua, luz y mantenimiento

Requerimientos en detalle Club Nutico

Un club nutico desea tener informatizados los datos correspondientes a sus instalaciones,
empleados, socios y embarcaciones que se encuentran en dicho club. El club esta
organizado de la siguiente forma:
Los socios pertenecientes al club vienen definidos por su nombre, direccin, DNI,
telfono y fecha de ingreso en el club.
Las embarcaciones vienen definidas por: matricula, nombre, tipo y dimensiones.
Los amarres tienen como datos de inters el nmero de amarre, la lectura del contador
de agua y luz, y si tienen o no servicios de mantenimiento contratados.
Por otro lado, hay que tener en cuenta que una embarcacin pertenece a un socio
aunque un socio puede tener varias embarcaciones. Una embarcacin ocupar un
amarre y un amarre est ocupado por una sola embarcacin. Es importante la fecha en
la que una embarcacin en asignada a un amarre.
Los socios pueden ser propietarios de amarres, siendo importante la fecha de compra
del amarre. Hay que tener en cuenta que un amarre pertenece a un solo socio y que NO
HAY ninguna relacin directa entre la fecha en la que se compra un amarre y en la que
una embarcacin se asigna a un amarre.
El club nutico est dividido en varias zonas definidas por una letra, el tipo de barcos que
tiene, el numero de barcos que contiene, la profundidad y el ancho de los amarres. Una
zona tendr varios amarres y un amarre pertenece a una sola zona.
En cuanto a los empleados, estos vienen definidos por su cdigo, nombre, direccin,
telfono y especialidad. Un empleado est asignado a varias zonas y en una zona puede
haber ms de un empleado, siendo de inters el nmero de barcos de los que se
encarga en cada zona. Hay que tener en cuenta que un empleado puede no encargarse
de todos los barcos de una zona.

Diagrama E_R Club Nutico

Esquema de la BD CLUB NATICO

SOCIO
DNI

NOMBRE

DIRECCION

TELEFONO FECHA

EMBARCACION
MATRICULA

NOMBRE

FK
TIPO

DIMENSION

AMARRE
NUMERO

NUMAMARRE FECHA

FK
AGUA

LUZ

MANTENIMIENTO

FK
DNISOCIO

FK

LETRAZONA

DNISOCIO

ZONA
LETRA

TIPO

ANCHO

PROFUNDIDAD

ATIENDE
EMPNUMERO ZLETRA

FK
EMPLEADO

NBARCOS

FK

ENUMERO NOMBRE

DIRECCION

TELEFONO

ESPECIALIDAD

FECHA

Anlisis de Requerimientos para una BD

de un Concesionario de Automviles
En una concesionaria de automviles los clientes
compran modelos de autos a los vendedores bajo
determinadas opciones o planes de financiamiento. El
cliente puede tambin ceder sus vehculos a cambio
especificando la fecha.
Los clientes y vendedores se identifican por id, nombre,
direccin y telfono.
Un modelo de auto se especifica por marca, modelo,
cilindraje y precio.
Un vehculo puede ser descrito por matrcula, precio,
marca y modelo. En la compra de un modelo se debe
especificar la matrcula y la fecha.
Los modelos de autos tienen diferentes opciones de
financiamiento. Una opcin debe especificar nombre y
descuento. Un precio se aplica a cada opcin para cada
modelo.

Diagrama E-R para una BD de un

Concesionario de Automviles

Esquema de la BD Concesionario de Automviles

OPCION
NOMBRE

TIENE

FK

NOMBREOPC

DESCUENTO

FK

FK

FK

MARCA

MODELO

CILINDRAJE

PRECIO

MODELO
MARCA

COMPRA FK
NOMBREOPC

MODELO

FK
MMARCA

CILINDRAJE

FK
MOD

FK
CILIND

PRECIO

FK
DNIVEND

FK
DNICLIE MATRIC

VENDEDOR
DNIV NOMBRE

DIRECCION

TELEFONO

CLIENTE
DNIC NOMBRE

DIRECCION TELEFONO

FK

VEHICULO
MATRICULA MARCA

MODELO

PRECIO

DNICL

FECHA

FECHA

Anlisis de Requerimientos para una BD

de un Zoolgico
Las especies de animales viven en habitats que estn en
diferentes continentes. Las especies se ubican en una zona
que tiene un nombre y una extensin. Las especies son
cuidadas por cuidadores.
Los guas llevan itinerarios para recorrer las zonas. Los
itinerarios especifican duracin, longitud y visitantes.
De los cuidadores y gua se especifica nombre, direccin y
telfono.
De las especies se necesita saber nombre de la especie y
nombre comn as como su descripcin.
El habitat se describe por nombre, clima, vegetacin.
Un continente tiene nombre y extensin.

Diagrama E_R de un Zoolgico

Esquema de la BD ZOOLGICO
CONTINENTE

HABITAT

NOMBRECONT

NOMBREHAB

ESTA_EN

NOMBC

NOMCONTIN

FK
ESPECIE

FK
NOMBREE

FK
DESCRIP.

ZONA
NOMZONA

EXTENSION

DIRECCION

NOMH
FK

NOMBREZ
FK
ITINERARIO

NUMITINERARIO

LONG.

VISITANTES

DURACION

RECORRE

CUIDADOR
NOMBRECUID

VEGETACION

VIVE_EN

NOMHABITAT

NOMBREC

CLIMA

TELEFONO

NUMITI

FECHA

NOMZO

FK
GUIA

FK

LLEVA

NOMBREG

DIRECCION

TELEFONO

FECHA

NUMITIN
FK

CUIDA
NOMBREC
FK

NOMCUID
FK

FECHA

NOMGUIA
FK

HORA

Anlisis de Requerimientos para una BD

de una AGENCIA DE VIAJES
Los turistas toman vuelos, contratan agencias de
viajes y reservan un hoteles.
Un turista se define por un nmero, nombre, apellidos,
direccin y telfono.
Los hoteles son descritos por un nmero, nombre,
direccin, ciudad, telfono y nmero de plazas..
La agencia se identifica por un nmero, direccin y
telfono.
Los turistas toman una clase de vuelo.
Los turistas reservan hoteles indicando la fecha de
entrada y de salida y la pensin

Diagrama E_R de una BD de Agencia de

Viajes

Esquema de la BD AGENCIA DE VIAJES

TURISTA
NUMEROTUR

NOMBRE

APELLIDOS

DIRECCION

TELEFONO

VUELO
NUMVUELO

FECHA

HORA

ORIGEN

DESTINO

NUMTOTAL

HOTEL
NUMHOTEL

NOMBRE

DIRECCION

TELEFONO

PLAZAS

AGENCIA
NUMAGENCIA

DIRECCION

TELEFONO

TOMA
MUMEROTUR CLASE

RESERVA

FK

NTURISTA NHOTEL

FK
FECHA_ENT

FK
FK
CONTRATA
NUMETUR NUMEAGENCIA

FK

NUMEROVUE

FK

FECHA_SAL

PENSION

NUMTUR

Anlisis de Requerimientos para una

Base de Datos de Gestin de Exmenes
Los profesores de la asignatura de Bases de Datos de una Escuela Universitaria
deciden crear una base de datos que contenga la informacin de los resultados
de las pruebas realizadas a los alumnos. Para realizar el diseo se sabe que:
Los alumnos estn definidos por su n de matrcula, nombre y el grupo al que
asisten a clase.
Dichos alumnos realizan dos tipos de pruebas a lo largo del curso acadmico:
1. Exmenes escritos: cada alumno realiza varios a lo largo del curso, y se definen
por el n de examen, el n de preguntas de que consta y la fecha de realizacin
(la misma para todos los alumnos que realizan el mismo examen).
Evidentemente, es importante almacenar la nota de cada alumno por examen.
2. Prcticas: se realiza un n indeterminado de ellas durante el curso acadmico,
algunas sern en grupo y otras individuales. Se definen por un cdigo de
prctica, ttulo y el grado de dificultad. En este caso los alumnos pueden
examinarse de cualquier prctica cuando lo deseen, debindose almacenar la
fecha y nota obtenida.
En cuanto a los profesores, nicamente interesa conocer (adems de sus datos
personales: DNI y nombre), quien es el qu ha diseado cada prctica,
sabiendo que en el diseo de una prctica puede colaborar ms de uno, y que
un profesor puede disear ms de una prctica. Interesa, adems, la fecha en
que ha sido diseada cada prctica por el profesor correspondiente.

Diagrama ER para una Base de Datos de

Gestin de Exmenes

Esquema de la Base de Datos para una

Base de Datos de Gestin de Exmenes
ALUMNO
MATRICULA

NOMBRE

GRUPO

PRACTICA
NUMERO

TITULO DIFICULTAD

EXAMEN
NUMERO

NPREGUNTAS

FECHA

PROFESOR
DNI

NOMBRE

HACE
MUMALUMNO NUMEXAMEN

REALIZA

FK

FK

NUMALUMNO NUMPRACT

FK
DISEA

NOTA

FECHA

NOTA

FK

NUMPRACTICA NUMPROF
FK
FK

FECHA

Anlisis de Requerimientos para una BD

de Gestin de Trabajos de Fin de Carrera

Una Escuela de Informtica quiere generar un sistema para tener controlado en una base
de datos todo lo referente a los Trabajos Fin de Carrera: alumnos que los realizan,
profesores que los dirigen, temas de los que tratan y tribunales que los corrigen. Por
tanto, es de inters:
Que los alumnos se definan por su nmero de matrcula, DNI y nombre. Un alumno
realiza, evidentemente, slo un T.F.C.
Que los T.F.C. se definen por su tema, por un nmero de orden y por la fecha de
comienzo. Un T.F.C. determinado, no puede ser realizado por varios alumnos.
Que un profesor se define por su DNI, nombre y domicilio; y puesto que los T.F.C. son
del rea en el que trabaja, NO interesa conocer el T.F.C. que dirige sino a qu alumno se
lo dirige.
Que un Tribunal est formado por varios profesores y los profesores pueden formar parte
de varios tribunales. Por otra parte, s es de inters para el tribunal conocer qu alumno
es el que se presenta, con qu T.F.C. y en qu fecha lo ha defendido. El tribunal se
define por un nmero de tribunal, lugar de examen y por el nmero de componentes.
Al margen de esto, un alumno puede haber pertenecido a algn grupo de investigacin
del que haya surgido la idea del T.F.C. Dichos grupos se identifican por un nmero de
grupo, su nombre y por su nmero de componentes. Un alumno no puede pertenecer a
ms de un grupo y no es de inters saber si el grupo tiene algo que ver o no con el T.F.
C. del alumno; s siendo de inters la fecha de incorporacin a dicho grupo.
Por otra parte, un profesor, al margen de dirigir el T.F.C. de algunos alumnos, puede
haber colaborado con otros en la realizacin de dicho T.F.C. pero siendo otro profesor el
que lo dirige. En este caso, slo es interesante conocer qu profesor ha ayudado a qu
alumno (a un alumno le pueden ayudar varios profesores).

Diagrama E_R de una BD de

Gestin de Trabajos de Fin de Carrera

Esquema de la Base de Datos de

Gestin de Trabajos de Fin de Carrera
FK

ALUMNO
NUMERO

NOMBRE

DNI

FK

NUMGRUPO

DNIPROF

PROFESOR
DNI

NOMBRE

DOMICILIO

GRUPO
NUMERO

NOMBRE

TFC
NUMALUMNO

FK

NUMTFC

TEMA

NUMTRIBUNAL

FK

TRIBUNAL
NUMERO

LUGAR

COOLABORA
NUMALUMNO

NUMPROF

FK
PERTENECE

FK

NUMPROF NUMTRIB

FK

FECHA

FK

Anlisis de Requerimientos para una

Base de Datos de Informacin Policial
La Polica quiere crear una base de datos sobre la seguridad en algunas entidades bancarias.
Para ello tiene en cuenta:
Que cada entidad bancaria se caracteriza por un cdigo y por el domicilio de su Central.
Que cada entidad bancaria tiene ms de una sucursal que tambin se caracteriza por un
cdigo y por el domicilio, as como por el nmero de empleados de dicha sucursal.
Que cada sucursal contrata, segn el da, algunos vigilantes jurados, que se caracterizan
por un cdigo y su edad. Un vigilante puede ser contratado por diferentes sucursales
(incluso de diferentes entidades), en distintas fechas y es un dato de inters dicha fecha,
as como si se ha contratado con arma o no.
Por otra parte, se quiere controlar a las personas que han sido detenidas por atracar las
sucursales de dichas entidades. Estas personas se definen por una clave (cdigo) y su
nombre completo.
Alguna de estas personas estn integradas en algunas bandas organizadas y por ello se
desea saber a qu banda pertenecen, sin ser de inters si la banda ha participado en el
delito o no. Dichas bandas se definen por un nmero de banda y por el nmero de
miembros.
As mismo, es interesante saber en qu fecha ha atracado cada persona una sucursal.
Evidentemente, una persona puede atracar varias sucursales en diferentes fechas, as
como que una sucursal puede ser atracada por varias personas.
Igualmente, se quiere saber qu Juez ha estado encargado del caso, sabiendo que un
individuo, por diferentes delitos, puede ser juzgado por diferentes jueces. Es de inters
saber, en cada delito, si la persona detenida ha sido condenada o no y de haberlo sido,
cunto tiempo pasar en la crcel. Un Juez se caracteriza por una clave interna del
juzgado, su nombre y los aos de servicio.
NOTA: En ningn caso interesa saber si un vigilante ha participado en la detencin de un
atracador.

Diagrama ER para una Base de Datos de

Informacin Policial

juzgado

Esquema de una Base de Datos de

Informacin Policial
ENTIDAD
ENUMERO

DOMICILIO

FK

SUCURSAL
NUMSUCURSAL

DOMICILIO

NUMEMPLEADO

NUMENTIDAD

CONTRATA
NUMSUC
FK

NUMVIG

FECHA

ARMA

FK

VIGILANTE
NUMVIGILANTE

ATRACADOR
NUMATRACADOR NOMBRE

APELLIDOS

EDAD

NUMBANDA

FK
ATRACA
NUMSUC NUMATRAC

FK

FK

BANDA
NUMBANDA NOMBRE

NUMJUEZ

FECHA

CONDENA

TIEMPO

FK
JUEZ
NUMEROJUEZ

NOMBRE

APELLIDOS

AOS

Anlisis de Requerimientos para una Base de

Datos de una Compaa de Seguros

Una compaa de seguros desea que se haga un diseo de una base de datos para gestionar
toda la informacin referente a los seguros que ofrece, los clientes a los que atiende y los
agentes de seguros que trabajan para la compaa. Esta compaa ofrece tres tipos de seguros:
Seguros de Hogar: los seguros de este tipo ofrecidos por la compaa estn ofertados de forma
fija (es decir se han hecho estudios previos), segn el valor del continente (la casa), el contenido
(muebles, electrodomsticos, joyas, etc.), riesgos auxiliares (responsabilidad civil, asalto y otros).
Para cada oferta hay una prima asignada.
Seguros de Vida: de la misma forma que los de hogar, existen varias ofertas fijas segn la edad y
profesin del cliente, y la cobertura econmica del seguro. De la misma forma que en los seguros
de Hogar, existe un prima fija para cada oferta.
Seguros de Automvil: tambin existen ofertas fijas, segn la categora de coche (utilitario, gama
media, gama alta, gran turismo, lujo, etc.), aos del vehculo, edad del conductor y cobertura
(todo riesgo, franquicia, terceros, etc.). A cada una de estas ofertas le corresponde una prima.
Para llevar un control de las comisiones que se llevan los agentes y de sus carteras
correspondientes, la compaa necesita tener almacenados los datos de los agentes,
considerndose de inters el nombre, DNI, direccin y telfono. Para el pago de comisiones y
carteras (se entiende por cartera la comisin anual del agente mientras el seguro este vigente),
ser necesario saber qu agente ha realizado qu seguro y en qu fecha.
La compaa considera como datos de inters referentes al cliente (sea cual sea el seguro que
contrate), los siguientes: Nombre, direccin, telfono y DNI.
Otras consideraciones sobre la contratacin de seguros por parte del cliente son:
Seguros Hogar: fecha del contrato del seguro y direccin del inmueble asegurado.
Seguros Automvil: fecha contratacin, matrcula del vehculo, recargos y descuentos.
Otras consideraciones: Un cliente puede contratar ms de un seguro de Vida, ms de un seguro
de Hogar y ms de un seguro de Automvil. Adems estos contratos pueden realizarse a travs
de distintos agentes. Los beneficiarios de seguros de vida pueden serlo de varios seguros, e
incluso de varios clientes distintos. Por supuesto un cliente puede nombrar a varios beneficiarios
de un mismo seguro de vida.

Diagrama ER para una Base de Datos de

una Compaa de Seguros
N

L
V

L
O

dni

Esquema de una Base de Datos de una

Compaa de Seguros
CLIENTE
DNI

AGENTE

NOMBRE

DIRECCION

TELEFONO

DNI

NOMBRE

HOGAR
NUMHOGAR

CENTE

CIDO

AUX

PRIMA

AUTOMOVIL
NUMAUTO

CATEGORIA

COBERTURA

EDAD

PRIMA

VIDA
NUMVIDA COBERTURA

PROFESION

EDAD

PRIMA

CONTRATAVIDA
NUMVIDA DNIAGENTE
FK

FK

DNIBENEF
FK

DNICLIENTE

FECHA

FK

CONTRATAHOGAR
NUMHOGAR DNIAGENTE DNICLIENTE

FK
CONTRATAUTO

FK

FK

FECHA

FK

NUMAUTO DNICLIENTE DNIAGENTE

FK

DIRECCION

FK

MATRICULA

FECHA

TELEFONO