Diseño Lógico

1. Convertir el esquema conceptual en el esquema lógico.2. Derivar un conjunto de relaciones (tablas) el esquema

lógico.3. Validar el esquema mediante la normalización.4. Validar el esquema lógico frente a las transacciones del

usuario.5. Redibujar el diagrama entidad-relación.6. Definir las restricciones de integridad.7. Revisar el esquema lógico con los usuarios.8. Estudiar el crecimiento futuro.

Convertir el esquema conceptual en el esquema lógico. 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.

WPEWEMP PROJ EMPWORK WORKS PROJM N 1 N N 1

Eliminar del esquema conceptual las estructuras de datos que los sistemas relacionales no modelan directamente (2)(b) Eliminar las

relaciones entre tres o más entidades, sustituyendo cada una de ellas por una nueva entidad (débil) 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 (débil) y dos relaciones binarias de esta nueva entidad con la entidad original. La cardinalidad de estas relaciones dependerá de su significado.

(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 relación 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 relación binaria de uno a muchos con la entidad original. (LOCATION)

EMPLOYEE EMPLOYEE

SUPERVISION

1 N

SUPERVISOR SUPERVISADO

SUPERVISOR

N

1SUPERVISA

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 (sinónimos). Si así fuera, ambas entidades deben integrarse en una sola.

(g) Eliminar las relaciones redundantes. Una relación es redundante cuando se puede obtener la misma información 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 relación redundante, eso dependerá del significado de cada relación.

Derivar un conjunto de relaciones (tablas) para el esquema lógico global En este paso, se obtiene un conjunto de relaciones

(tablas) para el esquema lógico 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 relación de la base de datos tendrá un nombre, y el nombre de sus atributos aparecerá, a continuación, entre paréntesis. 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 relación (tabla) a la que hacen referencia.

(a) Entidades fuertes. Crear una relación para cada entidad fuerte que incluya todos sus atributos simples. De los atributos compuestos incluir sólo 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 mínimo número de caracteres (si es de

tipo texto). Escoger la clave candidata más fácil 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 débiles

Crear una relación para cada entidad débil incluyendo todos sus atributos simples. De los atributos compuestos incluir sólo sus componentes.

Añadir una clave ajena a la entidad de la que depende. Para ello, se incluye la clave primaria de la relación que representa a la entidad padre (FK) en la nueva relación creada para la entidad débil.

La clave primaria de la nueva relación es la combinación de la FK y la llave parcial

Ejemplo: DEPENDENT (SSN DependentName,

Sex, BirthDate, Relationship)

(c) Relaciones binarias de uno a uno. Para cada relación binaria se incluyen los atributos de la clave

primaria de la entidad padre en la relación (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

relación, 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 relación,

la elección de padre e hijo es arbitraria. Además, en caso de que ambas entidades participen de forma total en la relación, se tiene la opción de integrar las dos entidades en una sola relación (tabla). Esto se suele hacer si una de las entidades no participa en ninguna otra relación.

Se añade cualquier atributo de la interrelación: MGRStartDate

RELACIÓN: 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 relación (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).

RELACIÓN: 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 conteniendoFKs para ámbas entidades participando en la

interrelaciónAtributos de las interrelaciones

Ejemplo: INTERRELACIÓN WORKS_ON M:NWORKS_ON (ESsn Pno, Hours)

f). Atributos Multievaluados

Crear una nueva tabla conteniendoPK de la entidad a ser FK de la nueva entidadAtributo multievaluado

PK contiene la FK más el atributo multievaluadoEjemploDEPT_LOCATION (DNumber, DLocation)

(e) Jerarquías de generalización. En las jerarquías, se denomina entidad padre a la entidad genérica y

entidades hijo a las subentidades. Hay tres opciones distintas para representar las jerarquías. La elección de la más adecuada se hará en función de su tipo (total/parcial, exclusiva/superpuesta).

Crear una relación 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 también una clave ajena al padre. Esta opción sirve para cualquier tipo de jerarquía, total o parcial y exclusiva o superpuesta.

Crear una relación por cada entidad hijo, heredando los atributos de la entidad padre. Esta opción sólo sirve para jerarquías totales y exclusivas.

Integrar todas las entidades en una relación, 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 consideración. Esta opción sirve para cualquier tipo de jerarquía. Si la jerarquía es superpuesta, el atributo discriminativo será multievaluado.

f). Interrelaciones terniarias

Crear una nueva tabla conteniendo una llave foránea referenciando cada una de las 3 entidades involucradas Incluir cualquier atributo de la interrelaciónPK es usualmente la combinación de las

tres FK

Reflexiones acerca del Diseño

Usted necesita usar su discreción para escoger sus PKEl esquema relacional que ud. obtiene

siguiendo el algoritmo de mapeo ER_tablas puede mostrar deficienciasSi el esquema relacional no le parece

adecuado vuelva a revisar su diagrama E_R

¿Cuántas Relaciones?

Se debe obtener una relación por cada: Entidad (regulares y débiles) Interrelaciones M:N Atributos multievaluados Interrelaciones terniarias

Análisis de Requerimientos para una BD de un Banco Un banco se identifica por un código único,

nombre y dirección y tiene sucursales. Cada sucursal se identifica por su número y su

dirección. Las sucursales pueden abrir múltiples cuentas y hacer múltiples préstamos a sus clientes.

Una cuenta tiene un número único, balance y tipo.

Un préstamo tiene un número único, una cantidad y un tipo.

Los clientes son registrados por su ID (SSN, CURP). Además debe conocerse de ellos su nombre, dirección y teléfono.

Esquema de la BD BANK

ADDRESSNAMECODE

BNOBCODETYPEBALANCEACCTNO

ADDRESSPHONENAMESSN

BNOBCODETYPEAMOUNTLOANNO

ADDRBRANCHNOBCODE

SSN LOANNO

ACCTNOSSN

FK FK

BANK

ACCOUNT

CUSTOMER

LOAN

BANK-BRANCH

A-C

L-C

FK FK

FK

FK FK

FK FK

Análisis 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 préstamo y de devolución).

Por cada biblioteca se conoce su nombre y su dirección

De los libros se registra su ISBN, título y nombre del autor(es).

De las editoriales se desea saber su nombre, dirección y teléfono.

Por cada usuario se registra también su nombre dirección y teléfono

Diagrama E_R de la BD LIBRARY

LIBRO

USUARIOBIBLIOTECA

EDITORIAL

ALMACENA-COPIAS PRESTA

ORGANIZA

Isbn

Título

Autor

TelefDirecNombreIduDirecNombre

DirecNombre

NoCopiasFDevolucion

Telef

N 1

M

N

N

MM

FPrestamo

Idl

Esquema de la BD LIBRARY

ISBN TITULO NOMEDITIDL

NOMBREIDL

TELEFONODIRECCIONNOMBRE

FDEVOLUCIONFPRESTAMOIDUNOMBREBIBIDL

NODECOPIASNOMBREBIBIDL

NOMBREIDU DIRECCION TELEFONO

DIRECCIONNOMBRE

LIBRO

AUTOR

EDITORIAL

PRESTA

ALMACENA_COPIAS

BIBLIOTECA

USUARIO

Análisis de Requerimientos para una compañía 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 camión (TRUCK) puede llevar varios cargamentos en un

solo viaje (TRIP) , el cual es identificado por Trip#, y entrega los cargamentos a múltiples tiendas .

Cada cargamento es identificado por un Shipment#, e incluye datos acerca de sus volúmenes (volume) y peso (weight) permitidos.

La compañía tiene 150 camiones, y un camión hace de 3 a 4 viajes cada semana.

WAREHOUSE

TRIP

SHIPMENT STORE

TRUCK

FROM

INCLUDES

TRUCK_USED

DESTINATION

Location

Date

Trip#

Shipment#

Volume

Weight StoreName Address

Truck#Truck#

VolCapacity

WeightCapacity

TRUCKERS_ WAREHOUSES DB

M

N

1

N

M N

N 1

Tipo

Esquema de la BD TRUCKERS - WAREHOUSES

LOCATION TIPO

TRUCKNODATETRIPNO

TRIPNOWEIGHTVOLUMESHIPMENTNO

WEIGHTCAPACITYVOLCAPACITYTRUCKNO

ADDRESSSTORENAME

SHIPMENTNO STORENAME

TRIPNOLOCATION

FK

FK

WAREHOUSE

TRIP

SHIPMENT

TRUCK

STORE

FROM

DESTINATION

FKFK

FK FK

Análisis de Requerimientos para una BD de una Línea Aérea

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.

Análisis de Requerimientos para una BD de una Línea Aérea

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-CODETYPE-NAME

NAME STATECITYAIRPORT-CODE

WEEKDAYSAIRLINENUMBER

DEP-TIMEAIRPLANEIDDATE #AV-SEATS

DEP-AIRP.-CODE ARR.-TIMEARR.-AIRP.-CODELEG#FLIGHT#

ARR.-AIRP.-CODE ARR.-TIMESCHED-DEP-TIMEDEP-AIRP.-CODELEG-NUMBERFLIGHTNUMBER

AMOUNT RESTRICTIONSFARE-CODEFLIGHT-NUMBER

DATELEG# CUSTOMERNAMESEAT# CUSTOMERPHONEFLIGHT#

MAX-SEATS COMPANYTYPE-NAME

AIRPORT

FLIGHT

LEG-INSTANCE

FLIGHT-LEG

FARES AIRPLANE-TYPE

RESERVATION

#TOTALSEATS TYPE-NAMEAIRPLANEIDCAN-LAND AIRPLANE

Análisis de Requerimientos para una BD de un Club Náutico

En un Club Náutico un socio tiene embarcaciones y compra amarres para estas debiéndose registrar la fecha de compra. Los amarres están en una zona.

Los socios se identifican por un id, nombre, dirección, teléfono y fecha en que obtuvieron la membresía.

De las embarcaciones debe registrarse matrícula, nombre, tipo y dimensiones.

Los empleados atienden zonas, especificándose el número de barcos que atiende cada empleado en cada zona. Los empleados se definen por id, nombre, dirección, teléfono y especialidad.

La zona se define por una letra única, tipo, profundidad y ancho. Cada embarcación ocupa un amarre en una fecha determinada. El amarre

se identifica por número, agua, luz y mantenimiento

Requerimientos en detalle Club Náutico Un club náutico 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, dirección, DNI, teléfono y fecha de ingreso en el club.

Las embarcaciones vienen definidas por: matricula, nombre, tipo y dimensiones. Los amarres tienen como datos de interés el número 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 embarcación pertenece a un socio

aunque un socio puede tener varias embarcaciones. Una embarcación ocupará un amarre y un amarre está ocupado por una sola embarcación. Es importante la fecha en la que una embarcación 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 relación directa entre la fecha en la que se compra un amarre y en la que una embarcación se asigna a un amarre.

El club náutico 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 código, nombre, dirección, teléfono y especialidad. Un empleado está asignado a varias zonas y en una zona puede haber más de un empleado, siendo de interés el número 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 Náutico

Esquema de la BD CLUB NAÚTICO

NOMBRE TELEFONODIRECCIONDNI FECHA

NUMAMARRETIPO DIMENSION DNISOCIONOMBREMATRICULA

LETRAZONALUZ MANTENIMIENTO FECHADNISOCIOAGUANUMERO

TIPO PROFUNDIDADANCHOLETRA

ZLETRA NBARCOSEMPNUMERO

NOMBRE DIRECCION TELEFONO ESPECIALIDADENUMERO

FK

FK

SOCIO

EMBARCACION

AMARRE

ZONA

ATIENDE

EMPLEADO

FK

FKFK

FKFECHA

Análisis de Requerimientos para una BD de un Concesionario de Automóviles En una concesionaria de automóviles los clientes

compran modelos de autos a los vendedores bajo determinadas opciones o planes de financiamiento. El cliente puede también ceder sus vehículos a cambio especificando la fecha.

Los clientes y vendedores se identifican por id, nombre, dirección y teléfono.

Un modelo de auto se especifica por marca, modelo, cilindraje y precio.

Un vehículo puede ser descrito por matrícula, precio, marca y modelo. En la compra de un modelo se debe especificar la matrícula y la fecha.

Los modelos de autos tienen diferentes opciones de financiamiento. Una opción debe especificar nombre y descuento. Un precio se aplica a cada opción para cada modelo.

Diagrama E-R para una BD de un Concesionario de Automóviles

Esquema de la BD Concesionario de Automóviles

NOMBRE DESCUENTO

MODELO CILINDRAJE PRECIOMARCANOMBREOPC

PRECIOCILINDRAJEMODELOMARCA

DNICLIE MATRICMMARCA MOD CILIND DNIVEND FECHANOMBREOPC

NOMBRE DIRECCION TELEFONODNIV

DNICLPRECIO FECHAMARCA MODELOMATRICULA

NOMBRE DIRECCION TELEFONODNIC

FK

OPCION

TIENE

MODELO

COMPRA

VENDEDOR

CLIENTE

VEHICULO

FK FK

FK

FK

FK FK FK FK FK FK

Análisis de Requerimientos para una BD de un Zoológico Las especies de animales viven en habitats que están en

diferentes continentes. Las especies se ubican en una zona que tiene un nombre y una extensión. Las especies son cuidadas por cuidadores.

Los guías llevan itinerarios para recorrer las zonas. Los itinerarios especifican duración, longitud y visitantes.

De los cuidadores y guía se especifica nombre, dirección y teléfono.

De las especies se necesita saber nombre de la especie y nombre común así como su descripción.

El habitat se describe por nombre, clima, vegetación. Un continente tiene nombre y extensión.

Diagrama E_R de un Zoológico

Esquema de la BD ZOOLÓGICO

NOMCONTINNOMHABITAT

NOMBRECONT VEGETACIONCLIMANOMBREHAB

NOMBREZDESCRIP.NOMBREENOMBREC

EXTENSIONNOMZONA

TELEFONO FECHADIRECCIONNOMBRECUID

VISITANTESLONG. DURACIONNUMITINERARIO

CONTINENTE HABITAT

ESPECIE

ZONA

CUIDADOR

ITINERARIO

LLEVATELEFONODIRECCION FECHANOMBREG

GUIA

NOMHNOMBC

ESTA_EN VIVE_EN

FK FKFK FK

FK

NOMZONUMITI

RECORRE

HORANOMGUIANUMITIN

FECHANOMCUIDNOMBREC

CUIDA FK FK

FK FK

FK FK

Análisis 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 número, nombre, apellidos, dirección y teléfono.

Los hoteles son descritos por un número, nombre, dirección, ciudad, teléfono y número de plazas..

La agencia se identifica por un número, dirección y teléfono.

Los turistas toman una clase de vuelo. Los turistas reservan hoteles indicando la fecha de

entrada y de salida y la pensión

Diagrama E_R de una BD de Agencia de Viajes

Esquema de la BD AGENCIA DE VIAJES

DIRECCION APELLIDOSNOMBRENUMEROTUR TELEFONO

HORA ORIGEN DESTINO NUMTOTAL NUMTURFECHANUMVUELO

TELEFONO PLAZASDIRECCIONNOMBRENUMHOTEL

TELEFONODIRECCIONNUMAGENCIA

CLASE NUMEROVUEMUMEROTUR

NUMETUR NUMEAGENCIA

NHOTEL FECHA_ENT FECHA_SAL PENSIONNTURISTA

FK FK

TURISTA

VUELO

HOTEL

AGENCIA

TOMA

RESERVA

CONTRATA

FKFK

FK FK

Análisis de Requerimientos para una Base de Datos de Gestión de Exámenes

Los profesores de la asignatura de Bases de Datos de una Escuela Universitaria deciden crear una base de datos que contenga la información de los resultados de las pruebas realizadas a los alumnos. Para realizar el diseño se sabe que:

Los alumnos están definidos por su n° de matrícula, nombre y el grupo al que asisten a clase.

Dichos alumnos realizan dos tipos de pruebas a lo largo del curso académico:1. Exámenes 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 realización (la misma para todos los alumnos que realizan el mismo examen). Evidentemente, es importante almacenar la nota de cada alumno por examen.

2. Prácticas: se realiza un n° indeterminado de ellas durante el curso académico, algunas serán en grupo y otras individuales. Se definen por un código de práctica, título y el grado de dificultad. En este caso los alumnos pueden examinarse de cualquier práctica cuando lo deseen, debiéndose almacenar la fecha y nota obtenida.

En cuanto a los profesores, únicamente interesa conocer (además de sus datos personales: DNI y nombre), quien es el qué ha diseñado cada práctica, sabiendo que en el diseño de una práctica puede colaborar más de uno, y que un profesor puede diseñar más de una práctica. Interesa, además, la fecha en que ha sido diseñada cada práctica por el profesor correspondiente.

Diagrama ER para una Base de Datos de Gestión de Exámenes

Esquema de la Base de Datos para una Base de Datos de Gestión de Exámenes

GRUPONOMBREMATRICULA

DIFICULTADTITULONUMERO

FECHANPREGUNTASNUMERO

NOMBREDNI

NUMEXAMEN NOTAMUMALUMNO

NUMPROFNUMPRACTICA FECHA

NUMPRACT FECHA NOTANUMALUMNO

FK FK

PRACTICA

EXAMEN

PROFESOR

HACE

REALIZA

DISEÑAFK FK

ALUMNO

FK FK

Análisis de Requerimientos para una BD de Gestión de Trabajos de Fin de Carrera

Una Escuela de Informática 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 interés:

Que los alumnos se definan por su número de matrícula, DNI y nombre. Un alumno realiza, evidentemente, sólo un T.F.C.

Que los T.F.C. se definen por su tema, por un número 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 interés 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 número de tribunal, lugar de examen y por el número de componentes.

Al margen de esto, un alumno puede haber pertenecido a algún grupo de investigación del que haya surgido la idea del T.F.C. Dichos grupos se identifican por un número de grupo, su nombre y por su número de componentes. Un alumno no puede pertenecer a más de un grupo y no es de interés saber si el grupo tiene algo que ver o no con el T.F.C. del alumno; sí siendo de interés la fecha de incorporación 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 realización de dicho T.F.C. pero siendo otro profesor el que lo dirige. En este caso, sólo 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 Gestión de Trabajos de Fin de Carrera

Esquema de la Base de Datos de Gestión de Trabajos de Fin de Carrera

NUMGRUPO DNINOMBRENUMERO DNIPROF

DOMICILIONOMBREDNI

NOMBRENUMERO

FECHATEMA NUMTRIBUNALNUMTFCNUMALUMNO

LUGARNUMERO

NUMPROF NUMTRIB

NUMPROFNUMALUMNO

FK

FK

PROFESOR

GRUPO

TFC

TRIBUNAL

COOLABORA

PERTENECE FKFK

ALUMNO FKFK

FK

FK

Análisis de Requerimientos para una Base de Datos de Información Policial

La Policía 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 código y por el domicilio de su Central. Que cada entidad bancaria tiene más de una sucursal que también se caracteriza por un

código y por el domicilio, así como por el número de empleados de dicha sucursal. Que cada sucursal contrata, según el día, algunos vigilantes jurados, que se caracterizan

por un código y su edad. Un vigilante puede ser contratado por diferentes sucursales (incluso de diferentes entidades), en distintas fechas y es un dato de interés 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 (código) y su nombre completo.

Alguna de estas personas están integradas en algunas bandas organizadas y por ello se desea saber a qué banda pertenecen, sin ser de interés si la banda ha participado en el delito o no. Dichas bandas se definen por un número de banda y por el número 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 interés saber, en cada delito, si la persona detenida ha sido condenada o no y de haberlo sido, cuánto tiempo pasará en la cárcel. Un Juez se caracteriza por una clave interna del juzgado, su nombre y los años de servicio.

NOTA: En ningún caso interesa saber si un vigilante ha participado en la detención de un atracador.

Diagrama ER para una Base de Datos de Información Policial

juzgado

Esquema de una Base de Datos de Información Policial

DOMICILIOENUMERO

DOMICILIO NUMEMPLEADO NUMENTIDADNUMSUCURSAL

ARMAFECHANUMVIGNUMSUC

EDADNUMVIGILANTE

APELLIDOSNOMBRE NUMBANDANUMATRACADOR

NUMBANDA NOMBRE

NUMJUEZNUMATRAC FECHA CONDENA TIEMPONUMSUC

FK

SUCURSAL

CONTRATA

VIGILANTE

ATRACADOR

ATRACA

BANDA

FKFK FK FK

ENTIDAD

AÑOSAPELLIDOSNOMBRENUMEROJUEZJUEZ

FK

FK FK

Análisis de Requerimientos para una Base de Datos de una Compañía de Seguros

Una compañía de seguros desea que se haga un diseño de una base de datos para gestionar toda la información referente a los seguros que ofrece, los clientes a los que atiende y los agentes de seguros que trabajan para la compañía. Esta compañía ofrece tres tipos de seguros:

Seguros de Hogar: los seguros de este tipo ofrecidos por la compañía están ofertados de forma fija (es decir se han hecho estudios previos), según el valor del continente (la casa), el contenido (muebles, electrodomésticos, 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 según la edad y profesión del cliente, y la cobertura económica del seguro. De la misma forma que en los seguros de Hogar, existe un prima fija para cada oferta.

Seguros de Automóvil: también existen ofertas fijas, según la categoría de coche (utilitario, gama media, gama alta, gran turismo, lujo, etc.), años del vehículo, 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 compañía necesita tener almacenados los datos de los agentes, considerándose de interés el nombre, DNI, dirección y teléfono. Para el pago de comisiones y carteras (se entiende por “cartera” la comisión anual del agente mientras el seguro este vigente), será necesario saber qué agente ha realizado qué seguro y en qué fecha.

La compañía considera como datos de interés referentes al cliente (sea cual sea el seguro que contrate), los siguientes: Nombre, dirección, teléfono y DNI.

Otras consideraciones sobre la contratación de seguros por parte del cliente son: Seguros Hogar: fecha del contrato del seguro y dirección del inmueble asegurado. Seguros Automóvil: fecha contratación, matrícula del vehículo, recargos y descuentos. Otras consideraciones: Un cliente puede contratar más de un seguro de Vida, más de un seguro

de Hogar y más de un seguro de Automóvil. Además estos contratos pueden realizarse a través 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 Compañía de Seguros

V

A H

MN

M

N

L

ML

N

LO

dni

Esquema de una Base de Datos de una Compañía de Seguros

DIRECCIONNOMBREDNI TELEFONO TELEFONONOMBREDNI

AUX PRIMACIDOCENTENUMHOGAR

COBERTURA EDAD PRIMACATEGORIANUMAUTO

COBERTURA PROFESION EDAD PRIMANUMVIDA

DNIAGENTE MATRICULADNICLIENTENUMAUTO FECHA

DIRECCIONDNICLIENTEDNIAGENTE FECHANUMHOGAR

FK FK FK

FK

AGENTE

HOGAR

AUTOMOVIL

VIDA

CONTRATAHOGAR

CONTRATAUTOFK FK

CLIENTE

DNIBENEF DNICLIENTEDNIAGENTE FECHANUMVIDACONTRATAVIDA

FK FK FK FK