Ejercicicios SIstemas de informacion

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.

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 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. 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 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)

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 conteniendo FKs para ámbas entidades participando en la interrelación Atributos de las interrelaciones

Ejemplo:  INTERRELACIÓN 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 más el atributo multievaluado Ejemplo DEPT_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ón PK es usualmente la combinación de las tres FK

Reflexiones acerca del Diseño Usted necesita usar su discreción 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

¿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 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

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 Autor

Isbn Título

Idl

LIBRO M

Direc

Nombre 1

N ORGANIZA

Telef

EDITORIAL

N FPrestamo

ALMACENACOPIAS

PRESTA

NoCopias N

M

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

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.

TRUCKERS_ WAREHOUSES DB Tipo

WAREHOUSE

Location

M VolCapacity FROM Truck# Date

WeightCapacity

N 1

N

TRIP

TRUCK

TRUCK_USED

Trip# 1 INCLUDES N

SHIPMENT

Shipment#

Weight Volume

M

DESTINATION

N

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

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

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

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

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

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

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 ALUMNO MATRICULA

NOMBRE

GRUPO

PRACTICA NUMERO

TITULO DIFICULTAD

EXAMEN NUMERO

NPREGUNTAS

FECHA

PROFESOR DNI

NOMBRE

HACE MUMALUMNO NUMEXAMEN

REALIZA

FK

FK

NUMALUMNO NUMPRACT

FK DISEÑA

NOTA

FECHA

NOTA

FK

NUMPRACTICA NUMPROF FK FK

FECHA

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

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

AÑOS

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 N

M

N

M

L

M

A

H

L V

L O

dni

N

Esquema de una Base de Datos de una Compañía 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