Ana Der 2002

UNIVERSIDAD TECNOLOGICA NACIONAL Facultad Regional La Plata Carrera de Ingeniera en Sistemas de Informacin Ctedra de Anlisis de Sistemas
MODELO DE INFORMACION Diagrama de Entidad-Relacin
Modelo de Informacin Diagrama de Entidad Relacin CONSIDERACIONES PREVIAS
El presente trabajo forma parte del material preparado por la Ctedra de Anlisis de Sistemas para ser utilizado como complemento bibliogrfico por los alumnos de las carreras de Informtica. Est realizado sobre la base del Manual: Data Modelling and Data Base Design, de Oracle Corporation, traducido por integrantes de esta Ctedra; los conceptos vertidos por R. Barker en su libro: CASE-METHOD El modelo de Entidad Relacin y el aporte de la propia experiencia profesional. Se ha puesto especial esmero en su preparacin en virtud de la relevancia del tema para la formacin de los futuros profesionales de sistemas. En efecto, la Modelizacin de Datos y su tcnica de aplicacin: el Diagrama de Entidad-Relacin, son uno de los aspectos fundamentales que se deben dominar para el anlisis y diseo de los sistemas que se implementarn sobre tecnologa de bases de datos; constituyen un requerimiento para la aplicacin de CASE (Computer Aided Software Engineering) y representan un espacio ciertamente comn existente entre las metodologas Estructurada y Orientada a Objetos para el anlisis de sistemas. Respecto de los alcances del contenido de este material, se han procurado incluir la mayor cantidad de aspectos de la Modelizacin de Datos, esencialmente sobre el desarrollo del Modelo de EntidadRelacin, como paso previo al Diseo de Base de Datos. Sobre este ltimo se enuncian al final slo algunos fundamentos a ttulo introductorio, pues su desarrollo ser objeto de otro trabajo en particular.
Modelo de Informacin Diagrama de Entidad Relacin
CONTENIDO 1. INTRODUCCION 2. EL DIAGRAMA DE ENTIDAD-RELACION (DER) 2.1. Entidades y sus atributos 2.1.1. Convencin de smbolos 2.1.2. Ocurrencias o instancias 2.1.3. Pasos para la identificacin y modelizacin de entidades candidatas a partir de las notas de relevamiento Ejercicio de aplicacin 2.1. 2.2. Relaciones 2.2.1. Sintaxis. Opcionalidad. Cardinalidad 2.2.2. Convencin de smbolos Ejercicio de aplicacin 2.2. Ejercicio de aplicacin 2.3. 2.2.3. Tipos de relaciones 2.2.4. Matriz de relaciones 2.2.5. Pasos para el anlisis y modelizacin de relaciones Ejercicio de aplicacin 2.4. Ejercicio de aplicacin 2.5. 2.3. Diseo del modelo Diagrama de EntidadRelacin (DER) 2.4. Atributos 2.4.1. Convenciones para el DER 2.4.2. Distincin entre atributos y entidades 2.4.3. Opcionalidad de los atributos 2.4.4. Identificacin de atributos Ejercicio de aplicacin 2.6. 2.5. Asignacin de Identificadores Unicos (IU) 2.5.1. Bsqueda de atributos y relaciones que identifiquen cada entidad Ejercicio de aplicacin 2.7. Ejercicio de aplicacin 2.8. Ejercicio de aplicacin 2.9. 3. NORMALIZACION DEL MODELO DE DATOS 3.1. Regla de la Primera Forma Normal 3.2. Regla de la Segunda Forma Normal 3.3. Regla de la Tercera Forma Normal Ejercicio de aplicacin 3.1. 4. RESOLUCION DE RELACIONES M:M Ejercicio de aplicacin 4.1. Ejercicio de aplicacin 4.2. 5. MODELIZACION JERARQUICA DE DATOS 6. MODELIZACION DE RELACIONES RECURSIVAS Ejercicio de aplicacin 6.1. 7. MODELIZACION DE ROLES MEDIANTE RELACIONES 8. MODELIZACION DE SUBTIPOS Y SUPERTIPOS 9. MODELIZACION DE RELACIONES EXCLUYENTES Ejercicio de aplicacin 9.1. 10. MODELIZACION DE DATOS HISTORICOS Ejercicio de aplicacin 10.1. 11. MODELIZACION DE RELACIONES COMPLEJAS Ejercicio de aplicacin 11.1. Ejercicio de aplicacin 11.2. 5 6 6 7 8 8 10 10 10 11 13 13 13 15 17 21 21 21 22 23 25 26 27 28 28 33 33 33 33 34 34 35 36 37 38 45 45 46 49 53 54 56 59 60 62 65 66 68 69
Modelo de Informacin Diagrama de Entidad Relacin Ejercicio de aplicacin 11.3. 12. DISEO DE LA BASE DE DATOS A PARTIR DEL MODELO DE ENTIDAD-RELACION BIBLIOGRAFIA APENDICE A - RESOLUCION DE LOS EJERCICIOS 69 71 72 73
1. INTRODUCCION La Modelizacin de Datos (MD) es el primer paso del Proceso de Desarrollo Top-Down de una Base de Datos. Se realiza durante la etapa de anlisis dentro del ciclo de desarrollo de un sistema.
REQUERIMIENTOS DE INFORMACION DE LA ORGANIZACION INVESTIGACION PRELIMINAR
ANALISIS
MODELIZACION DE DATOS
*Definicin de Entidades y atributos *Modelo de EntidadRelacin (DER) *Diccionario de Datos
DISEO
DISEO DE BASE DE DATOS
*Definicin de tablas, ndices, vistas y espacios fsicos
IMPLEMENTACION
CONSTRUCCION DE BASE DE DATOS
BASE DE DATOS EN PRODUCCION

fig. [1] El propsito de la MD es el desarrollo de un modelo llamado Diagrama de Entidad-Relacin (DER) que representa los requerimientos de informacin de la organizacin. Debe asegurarse el establecimiento total de los requerimientos de informacin de la organizacin durante el proceso de MD. Cambiar los requerimientos en posteriores etapas del ciclo de desarrollo del sistema puede ser extremadamente costoso.
La MD es independiente del software o hardware posteriormente en la implementacin del sistema.
que
se
utilice
2. EL DIAGRAMA DE ENTIDAD-RELACION (DER) Un DER es un modelo grfico que constituye una forma efectiva de reunir y documentar los requerimientos de informacin de la organizacin. Sus principales caractersticas son: Sintaxis consistente: El DER documenta los requerimientos de informacin de la organizacin en forma clara y precisa. Comunicacin con el usuario: Los usuarios pueden fcilmente entender la forma grfica del DER. Usar vistas o partes del DER ayuda a la comunicacin con el usuario. Fcil desarrollo: El DER puede ser fcilmente desarrollado y refinado. Definicin de alcances: El DER provee un claro modelo de los alcances de los requerimientos de informacin de la organizacin. Integracin con mltiples aplicaciones: El DER provee un efectivo marco de trabajo para la integracin de mltiples aplicaciones en proyectos de sistemas de desarrollo interno y/o paquetes adquiridos. Un DER puede ser implementado en una base de datos jerrquica, de redes o relacional. Los componentes del DER son las entidades con sus atributos y las relaciones.
2.1. Entidades y sus atributos. Las entidades son las cosas significativas acerca de las cuales se necesita conservar informacin. Tambin pueden definirse como: - Un objeto Organizacin. de inters para el sistema de informacin de la
- Una clase o categora de cosas en el sistema. - Una cosa con identidad para el sistema. Los siguientes ejemplos representan cosas de significancia acerca de las cuales la organizacin necesite conservar informacin: EMPLEADO, DEPARTAMENTO, PROYECTO, CLIENTE.
Los atributos describen a las entidades. Son los componentes especficos de la informacin que se necesita conocer de ellas. Posibles atributos de la entidad EMPLEADO nombre, fecha de nacimiento, salario. son: legajo, apellido,
De la entidad DEPARTAMENTO: nombre, nmero, localizacin. La informacin que representan los atributos de una entidad debe ser necesaria y significativa desde el punto de vista de los requerimientos de la organizacin. En captulos posteriores se profundizar el tema de los atributos. 2.1.1. Convencin de Smbolos. Las entidades se representan por rectngulos con vrtices redondeados. El nombre de cada entidad debe ser nico, referirse en singular a la clase de cosa que representa y escribirse en letras maysculas. Opcionalmente puede incluirse un nombre sinnimo entre parntesis, como nombre alternativo de la entidad, si la organizacin reconoce a la misma de diferentes formas. Los nombres de los atributos se escriben en letras minsculas.
EMPLEADO legajo apellido nombres fecha de nacimiento sueldo
DEPARTAMENTO numero nombre localizacin
CLIENTE (USUARIO) apellido nombres cargo telfono domicilio lmite autorizado

fig.[2]
PROYECTO cdigo nombre descripcin localizacin
2.1.2. Ocurrencias o instancias. Cada entidad tiene mltiples ocurrencias o instancias, por ejemplo, la entidad EMPLEADO tiene una ocurrencia para cada empleado y la entidad DEPARTAMENTO tiene una ocurrencia para cada departamento de la organizacin: Jos Prez, Juan Garca, Daniel ocurrencias de la entidad EMPLEADO. Ramos, Mario Gomez,..., son
Finanzas, Marketing, Centro de sistemas, Compras,..., son instancias de la entidad DEPARTAMENTO Cada instancia de la atributos de la misma. entidad tiene valores especficos para los
En tal sentido, si la entidad EMPLEADO tiene como atributos: legajo, apellido, nombre, fecha de nacimiento y salario, la instancia Daniel Ramos tiene los siguientes valores: legajo 1253, apellido Ramos, nombre Daniel, fecha de nacimiento 12/05/1955, salario $ 2.000. Cada instancia debe ser identificable unvocamente de otra instancia de la misma entidad. Un atributo o conjunto de atributos que identifique unvocamente a cada instancia de la entidad es llamado Identificador Unico (IU). De tal modo, si cada empleado tiene un nico nmero de legajo, el atributo legajo es candidato a ser el IU de la entidad EMPLEADO. Si una entidad no puede tener un IU, entonces posiblemente no sea una entidad. Los atributos que identifican unvocamente a una entidad y que forman parte del IU de la misma, se identifican con el smbolo #*. 2.1.3. Pasos para la identificacin y modelizacin candidatas a partir de las notas de relevamiento. 1. Examinar las notas. Determinar objetos o cosas significativas 2. Dar un nombre a cada entidad. 3. Determinar sobre cada entidad la informacin de inters para la organizacin, especificndola como atributos. 4. Establecer que atributo/s pueden formar parte del IU entidad a fin de identificar unvocamente a cada instancia. de cada como de entidades
entidades candidatas a los
5. Hacer una breve descripcin de cada entidad, por ejemplo: "un EMPLEADO significa un trabajador de la empresa. Por ejemplo Juan Garca y Daniel Ramos son EMPLEADOs." 6. Dibujar cada entidad y algunos de sus atributos. 7. No desechar una entidad candidata prematuramente. Atributos adicionales de inters para el sistema pueden ser descubiertos posteriormente.
Como ejemplo de aplicacin, podemos identificar entidades de las siguientes notas de relevamiento:
modelizar
las
"Mi funcin es la de Gerente de una empresa de capacitacin que provee cursos de informtica. Tenemos muchos cursos, cada uno tiene un cdigo, un nombre y un precio. Introduccin a UNIX y Programacin C son dos de nuestros ms populares cursos. Los cursos varan en su duracin entre uno y cuatro das. Un instructor puede ser profesor de varios cursos. Pedro Gomez y Mara Gonzalez son dos de nuestros mejores instructores. Registramos el apellido, nombres y nmero telefnico de cada instructor. Cada curso es dictado por un solo instructor. Creamos un curso y luego le asignamos un instructor. Los estudiantes pueden tomar varios cursos y muchos de ellos lo hacen. Bill Gates de Microsoft ha tomado varios cursos de nuestra oferta. Tambin registramos de cada estudiante su apellido, nombres y nmero telefnico. Algunos de nuestros estudiantes e instructores no nos han dado an su nmero telefnico."
Las siguientes entidades modelizan los requerimientos de informacin de la empresa de capacitacin:
CURSO cdigo nombre precio duracin
INSTRUCTOR (PROFESOR) apellido nombres telfono
ESTUDIANTE apellido nombres telfono

fig.[3]
Descripcin de entidades: - un CURSO significa un evento de capacitacin ofrecido por la empresa de capacitacin. Por ejemplo: Introduccin a UNIX y Programacin C. - Un ESTUDIANTE significa un participante de uno o ms CURSOs. Por ejemplo Bill Gates. - Un INSTRUCTOR significa un profesor de uno o ms CURSOs. Por ejemplo Pedro Gmez y Mara Gonzlez.
10
Ejercicio de aplicacin 2.1. Identificar y modelizar las entidades en las siguientes notas de relevamiento. Escribir una breve descripcin de cada entidad. Mostrar al menos dos atributos de cada entidad.
"Nuestro negocio es un video club. Tenemos alrededor de 3.000 cintas de video y necesitamos llevar un registro de ellas. Cada una de nuestras cintas de video tiene un nmero que la identifica. Por cada pelcula necesitamos conocer su ttulo y categora (por ejemplo: comedia, drama, accin, guerra, cienciaficcin, etc). Tenemos varias copias de muchas de nuestras pelculas. Damos a cada pelcula un nmero de identificacin y lo registramos en el cassette de la cinta. Una cinta puede tener formato Beta o VHS. Siempre tenemos al menos una cinta por cada pelcula registrada. Tambin tenemos algunas pelculas muy largas que requieren ms de una cinta. Somos frecuentemente consultados por pelculas protagonizadas por determinados actores. John Wayne y Katherine Hepburn son muy populares. Necesitamos registrar todos los actores que aparecen en las pelculas. No todas nuestra pelculas estn protagonizadas por actores. Los clientes quieren saber tambin el nombre "real" de los actores y su fecha de nacimiento. Registramos solamente artistas de cine en nuestro inventario. Tenemos muchos clientes. Solamente alquilamos nuestras pelculas a personas adheridas a nuestro club. Para ser socio de nuestro video club deben tener buenas referencias. Para cada socio necesitamos registrar su apellido y nombres, nmero telefnico y domicilio. Cada socio del video club tiene un nmero de socio. Necesitamos llevar un registro de las cintas que cada socio tiene actualmente. Un socio puede tener varias pelculas alquiladas en un mismo tiempo. Registramos los alquileres actuales, no los histricos de cada socio."
2.2. Relaciones. Una relacin es una asociacin bidireccional entre dos entidades o entre una entidad y si misma.
2.2.1. Sintaxis. Opcionalidad. Cardinalidad. |debe/puede| | uno o ms | Cada entidad1 | |relacin| o | entidad2 |ser/estar | |uno y slo uno|
Por ejemplo, la relacin entre INSTRUCTOR y CURSO es: Cada CURSO puede ser dictado por uno y slo uno INSTRUCTOR. Cada INSTRUCTOR puede ser asignado a uno o ms CURSOs. Cada direccin de una relacin tiene: - Un nombre, por ejemplo dictado por o asignado a.
11
- Una opcionalidad, entre debe ser/estar o puede ser/estar. - Una cardinalidad o grado, entre uno y slo uno o uno o ms. Una cardinalidad 0 (cero) es considerada como puede ser/estar. 2.2.2. Convencin de Smbolos. Las relaciones se presentan con una linea que une las dos entidades. Los nombres de escriben en letras minsculas. Para representar la opcionalidad se utiliza:
Opcional (puede ser) Mandatorio (debe ser)
Para representar la cardinalidad o grado se utiliza: uno o ms uno y slo uno
muchos
opcional uno
mandatorio fig.[4]
Primeramente se lee la relacin en una direccin y luego se lee en la otra direccin. Por ejemplo, la relacin entre EMPLEADO Y DEPARTAMENTO:
EMPLEADO
asignado a responsable de
DEPARTAMENTO
fig.[5] Leyndola primeramente de izquierda a derecha y luego de derecha a izquierda:
12
relacin de izquierda a derecha (diagrama parcial)
EMPLEADO
asignado a
DEPARTAMENTO
fig.[6]
Cada EMPLEADO debe ser asignado a uno y solo un DEPARTAMENTO. relacin de derecha a izquierda (diagrama parcial)
EMPLEADO
DEPARTAMENTO
responsable de
fig.[7] Cada DEPARTAMENTO puede ser responsable de uno o ms EMPLEADOs. Como ejemplos de aplicacin, podemos tomar los siguientes: La relacin entre ESTUDIANTE y CURSO.
ESTUDIANTE
inscripto en tomado por

fig.[8]
CURSO
Cada ESTUDIANTE puede ser inscripto en uno o ms CURSOs. Cada CURSO puede ser tomado por uno o ms ESTUDIANTEs. La relacin entre CHEQUE DE PAGO y EMPLEADO.
CHEQUE DE PAGO para fig.[9] receptor de
EMPLEADO
Cada CHEQUE DE PAGO debe ser para uno y slo uno EMPLEADO.
13
Cada EMPLEADO puede ser el receptor de uno o ms CHEQUEs DE PAGO. Ejercicios de Aplicacin Lectura de Relaciones: 2.2. Escribir las relaciones que se leen en el siguiente DER:
PEDIDO nmero tipo
salida para solicitado va
ITEM cdigo descripcin
originado por
almacenado en
origen de CLIENTE apellido nombres
repositorio para DEPOSITO cdigo domicilio
fig.[10]
Dibujo del Diagrama de Entidad-Relacin: 2.3. Dibujar el DER que represente lo siguiente: Cada EMPLEADO debe ser asignado a uno y slo uno DEPARTAMENTO. Cada DEPARTAMENTO puede ser responsable de uno o ms EMPLEADOs.
Cada EMPLEADO puede ser asignado a una o ms ACTIVIDADes. Cada ACTIVIDAD puede ser realizada por uno o ms EMPLEADOs. 2.2.3. Tipos de Relaciones. Existen tres tipos de relaciones: - relaciones muchos a uno - relaciones muchos a muchos - relaciones uno a uno
14
Todas las relaciones deben responder a los requerimientos de informacin y a las normas de la organizacin. Las relaciones muchos a uno (M a 1 M:1) tienen grado o cardinalidad uno o ms en una direccin y grado uno y slo uno en la otra direccin. Por ejemplo, hay una relacin REPRESENTANTE DE VENTAS. M:1 entre las entidades CLIENTE y
CLIENTE
visitado por asignado a visitar

fig.[11]
REPRESENTANTE DE VENTAS
Cada CLIENTE debe ser visitado por uno y slo uno REPRESENTANTE DE VENTAS. Cada REPRESENTANTE DE VENTAS puede ser asignado a visitar uno o ms CLIENTEs. Las relaciones M:1 son muy comunes. Asimismo es muy raro que sean mandatorias en ambas direcciones. Las relaciones muchos a muchos (M a M M:M) cardinalidad de uno o ms en ambas direcciones.
tienen
un
grado
Por ejemplo, hay una relacion M:M entre las entidades ESTUDIANTE y CURSO.
ESTUDIANTE

fig.[12]
CURSO
Cada ESTUDIANTE puede estar inscripto en uno o ms CURSOs. Cada CURSO puede ser tomado por uno o ms ESTUDIANTEs. Hay una relacin M:M entre las entidades EMPLEADO y TAREA.
15
EMPLEADO
asignado a realizada por
TAREA
fig.[13] Cada EMPLEADO puede ser asignado a una o ms TAREAs. Cada TAREA puede ser realizada por uno o ms EMPLEADOs. Las relaciones M:M son muy comunes. Asimismo usualmente son opcionales en ambas direcciones, aunque pueden ser opcionales slo en una direccin. Las relaciones uno a uno (1 a 1 1:1) tienen un grado o cardinalidad uno y slo uno en ambas direcciones. Por ejemplo, hay una relacin PERSONAL y PLAQUETA MADRE. 1:1 entre las entidades COMPUTADORA
COMPUTADORA PERSONAL
integradora de incorporada dentro de

fig.[14]
PLAQUETA MADRE
Cada COMPUTADORA PLAQUETA MADRE.
PERSONAL
debe
ser
integradora
de
una
slo
una
Cada PLAQUETA MADRE puede estar incorporada dentro de una y slo una COMPUTADORA PERSONAL. difcil puede
Las relaciones 1:1 son raras. Asimismo mandatorias en ambas direcciones. Si dos entidades parecen tener tratarse de la misma entidad. una
es
muy
que
sean
relacin
1:1,
realmente
2.2.4. Matriz de relaciones. El uso de una matriz de relaciones puede ayudar para la determinacin inicial de las relaciones entre un conjunto de entidades.
Modelo de Informacin Diagrama de Entidad Relacin Para su construccin convenciones:
16
deben
tenerse
en
cuenta
las
siguientes
- Una matriz de relaciones muestra si y cmo cada entidad que figura al comienzo de una fila de la matriz se relaciona con cada entidad que figura al tope de una columna. - Todas las entidades deben ser listadas al comienzo de las filas y al tope de las columnas. - Si una entidad de una fila se relaciona con una entidad de una columna, entonces el nombre de la relacin se debe colocar en la celda que forma la interseccin de ambas. - Si una entidad de una fila no se relaciona con una entidad de una columna, entonces una raya de debe colocar en la celda que forma la interseccin de ambas. - Cada relacin por arriba de la diagonal principal de la matriz es la inversa de la relacin "imagen espejo" que est debajo de la misma. - Relaciones recursivas (entre una entidad y s misma) se representan en las celdas de la diagonal principal.
Por ejemplo, la siguiente matriz de relaciones muestra el juego de relaciones existentes entre cuatro entidades:
CLIENTE CLIENTE ITEM PEDIDO DEPOSITO originado por
ITEM
PEDIDO origen de solicitado va
DEPOSITO
almacenado en
salida para repositorio para
Por tomar un caso de entidades y relacin, puede verse que: CLIENTE est relacionado con PEDIDO y el nombre de la relacin es origen de. PEDIDO est relacionado con CLIENTE y el nombre de la relacin es originado por.
Puede ahora realizarse el mapeo del contenido de la matriz de relaciones en un DER. Se dibujan las entidades adicionndoseles los atributos; se dibuja una lnea para cada relacin, escribiendo su nombre y agregando la opcionalidad y el grado o cardinalidad.
17
PEDIDO nmero tipo
salida para solicitado va
ITEM nmero descripcin
originado por
almacenado en
origen de CLIENTE apellido nombres
repositorio para DEPOSITO cdigo domicilio
fig.[15]
2.2.5. Pasos para el anlisis y modelizacin de relaciones. Mediante los relaciones: siguientes 5 pasos se analizan y modelizan las
1. Determinar la existencia de las relaciones. 2. Dar un nombre a cada direccin de las relaciones. 3. Determinar la opcionalidad para cada direccin de las relaciones. 4. Determinar relaciones. 5. Examinar existencia. el
grado
cardinalidad
de
cada
direccin par
de
las
las
relaciones
en
ambas
direcciones
validar
su
Paso 1 - Determinar la existencia de las relaciones. Examinar cada par de entidades para determinar si existe una relacin entre ellas, preguntndose: es de significancia la relacin existente entre la ENTIDAD_A y LA ENTIDAD_B? Por ejemplo, considere las entidades DEPARTAMENTO y EMPLEADO. Hay una relacin de significancia entre ambas? Si, obviamente que la hay. Ahora, sobre las entidades DEPARTAMENTO y ACTIVIDAD. Hay una relacin de significancia entre ellas? No, al menos no surge claramente en un comienzo.
18
Es conveniente utilizar una matriz de sistemticamente cada par de entidades.
relaciones
para
examinar
Por ejemplo, para determinar las relaciones entre las entidades ACTIVIDAD, DEPARTAMENTO Y EMPLEADO en una matriz de relaciones, se marcan en ella la existencia de las mismas.
ACTIVIDAD ACTIVIDAD DEPARTAMENTO EMPLEADO X
DEPARTAMENTO
EMPLEADO X X
Paso 2 - Dar un nombre a cada direccin de las relaciones. Responder las siguientes preguntas para cada relacin: Cmo es una ENTIDAD_A respecto de una ENTIDAD_B? Cada ENTIDAD_A es nombre_relacion una ENTIDAD_B. Cmo es una ENTIDAD_B respecto de una ENTIDAD_A? Cada ENTIDAD_B es nombre_relacion una ENTIDAD_A. Por ejemplo, considerar la relacin entre DEPARTAMENTO y EMPLEADO. Cmo es un DEPARTAMENTO respecto de un EMPLEADO? Cada DEPARTAMENTO es responsable de un EMPLEADO. Cmo es un EMPLEADO respecto de un DEPARTAMENTO? Cada EMPLEADO es asignado a un DEPARTAMENTO. Luego, en la matriz de relaciones se asignan los nombres de cada relacin.
ACTIVIDAD ACTIVIDAD DEPARTAMENTO EMPLEADO asignado a
DEPARTAMENTO
EMPLEADO realizada por responsable de
asignado a
19
La siguiente es bidireccionales: basado en descripcin de operada por representado por responsable por
una
lista
de
ejemplos
de
nombres
de
relaciones
base para para operador de representante de responsabilidad de
Nunca debe usarse relacionado a como nombre de relacin. Paso 3 - Determinar relaciones. la opcionalidad para cada direccin de las
Para determinar la opcionalidad de la relacin se deben responder las siguientes preguntas para cada relacin: Debe un ENTIDAD_A ser nombre_relacin al menos uno ENTIDAD_B? Debe un ENTIDAD_B ser nombre_relacin al menos uno ENTIDAD_A? Por ejemplo, considerando la relacin entre DEPARTAMENTO y EMPLEADO: Debe un EMPLEADO ser asignado a al menos un DEPARTAMENTO? Siempre? Hay alguna situacin en la cual un EMPLEADO no sea asignado a un DEPARTAMENTO? No, un EMPLEADO debe ser siempre asignado a un DEPARTAMENTO. Debe un DEPARTAMENTO ser responsable de al menos un EMPLEADO? No, un DEPARTAMENTO puede no ser responsable de un EMPLEADO. Modelando en un DER estas relaciones con su opcionalidad:
EMPLEADO
fig.[16]
DEPARTAMENTO
20
Paso 4 - Determinar el grado o cardinalidad de cada direccin de las relaciones. Para determinar el grado de la relacin siguientes preguntas para cada relacin: se deben responder la
Puede un ENTIDAD_A ser nombre_relacin ms de uno ENTIDAD_B? Puede un ENTIDAD_B ser nombre_relacin ms de uno ENTIDAD_A? Para el caso de la relacin entre DEPARTAMENTO y EMPLEADO: Puede un EMPLEADO ser asignado a ms de un DEPARTAMENTO? No, un EMPLEADO debe ser asignado a slo un DEPARTAMENTO. Puede un DEPARTAMENTO ser responsable por ms de un EMPLEADO? Si, un DEPARTAMENTO puede ser responsable por uno o ms EMPLEADOs. Agregando al modelo DER de estas relaciones su cardinalidad:
EMPLEADO
fig.[17]
DEPARTAMENTO
Paso 5 - Examinar las relaciones en ambas direcciones par validar su existencia. Las relaciones establecidas deben ser validadas examinando el DER para verificar que tienen sentido para el sistema.
EMPLEADO
fig.[18]
DEPARTAMENTO
Cada EMPLEADO debe ser asignado a uno y solo un DEPARTAMENTO. Cada DEPARTAMENTO puede ser responsable por uno o ms EMPLEADOs.
21
Ejercicios de aplicacin: Analizar y modelizar las relaciones en los siguientes casos. Utilizar una matriz de relaciones para registrar la existencia de las mismas entre las entidades. 2.4. Empresa de Capacitacin (pg. 9). 2.5. Video Club (2.1.) 2.3. Diseo del modelo Diagrama de Entidad-Relacin. Para desarrollar el DER de forma que sea fcil de interpretar y aplicar por quienes deban hacerlo, se deben seguir las siguientes pautas: Prolijidad. - Alinear las entidades horizontal y verticalmente. - Dibujar las lineas de las relaciones en forma directa entre las entidades, en lo posible horizontal o verticalmente. Si deben ser oblicuas, no utilizar ngulos muy cerrados. - Usar abundante espacio en blanco para evitar el aspecto congestivo. - Evitar el uso de muchas dificultoso el seguimiento. Texto no ambiguo. - Evitar el uso de ambigedades en el texto. - Evitar el uso de abreviaturas y jerga. - Agregar adjetivos si contribuyen a la interpretacin. - Alinear el texto horizontalmente. - Colocar el nombre de las relaciones al comienzo de las lneas y en los lados opuestos de ellas. lneas paralelas cerradas que hacen
Modelos recordables. - Hacer los DER recordables para sus usuarios. - No exagerar el tamao de las entidades. - Dibujar el DER preferentemente en hojas lisas sin reticulados. Reglas de diseo. - Dibujar el smbolo de cardinalidad uno o ms posicionndolo preferentemente arriba o a la izquierda sobre la lnea de la relacin.
22
Izquierda Arriba
fig.[19]
- Posicionar las entidades de mayor volumen y volatilidad en torre, arriba e izquierda del diagrama. - Posicionar las entidades de bajo volumen y menor volatilidad en torre, abajo y derecha del diagrama.
2.4. Atributos. Los atributos de la entidad son informacin acerca de ella que necesita ser conocida y registrada. Ellos describen de la entidad aspectos identificatorios, cualitativos, clasificatorios, cuantitativos y de estado. Por ejemplo, algunos atributos de la entidad EMPLEADO son:
nmero de legajo o nmina identifica unvocamente a un EMPLEADO. apellido y nombres identifica no unvocamente a un EMPLEADO. tipo de pago (p.ej. semanal o mensual) clasifica a un EMPLEADO edad describe un atributo cuantitativo de un EMPLEADO. estado de actividad (p.ej. activo o pasivo) expresa el estado de un EMPLEADO.
Los atributos representan un tipo de descripcin o detalle de la entidad, no una instancia. 77560 y 829/5 son valores del atributo nmero de legajo y Juan es un valor del atributo nombre de la entidad EMPLEADO. Forman parte de su dominio. Los nombres de los atributos deben ser claros para el usuario, no codificados para el desarrollo posterior.
23
El nombre de la entidad es siempre asociado en forma cualitativa al nombre del atributo, por ejemplo cdigo de CURSO. Asimismo, un nombre de atributo nunca debe incluir el nombre de su entidad. Los nombres de los atributos deben ser especficos, por ejemplo si es cantidad, el nombre debe aclarar si es cantidad pagada o cantidad cobrada. Siempre se debe clarificar los atributos fecha con una descripcin o frase verbal, por ejemplo fecha de recepcin, fecha de nacimiento. Cada atributo debe ser asignado a una sola entidad.
2.4.1. Convenciones para el DER: Los nombres de los atributos deben ser en singular y letras minsculas. Deben listarse dentro de los smbolos de sus entidades.
PERSONA cdigo nombre profesin sexo peso
CURSO cdigo nombre duracin precio

fig.[20]
EMPLEADO legajo apellido nombres categora fecha de nacimiento
Siempre se debe descomponer los atributos en sus componentes mnimos que le dan significancia. Por ejemplo, el nombre apellido y nombres. de una PERSONA puede ser descompuesto en
PERSONA nombre
PERSONA apellido nombres
fig.[21] La caracterstica descripcin.
de
un
ITEM
consiste
en
nmero de tem, tipo y
ITEM caracterstica
ITEM nmero tipo descripcin
fig.[22]
24
Los atributos que significan por ejemplo fechas, horas, nmeros de cdigos con dgitos verificadores, generalmente no deben descomponerse en otros en esta etapa. Los atributos que contienen domicilios son generalmente descompuestos en la etapa de diseo de la base de datos, no obstante, en funcin de la necesidad pueden ser aqu descompuestos en calle, nmero, departamento, localidad, provincia, nmero postal, etc. En ltima instancia, el nivel de descomposicin de atributos en esta etapa depender de los requerimientos del sistema y de la organizacin. Se debe verificar que cada atributo tiene un nico valor para cada instancia de la entidad. Un atributo multivaluado o grupo repetitivo no es vlido. Por ejemplo, para la entidad CLIENTE:
CLIENTE cdigo fecha de visita
fig.[23] Un CLIENTE puede ser visitado mltiples veces necesita registrar todas las fechas de visita. Debe aparecer la entidad VISITA. y la organizacin
VISITA fecha de visita lugar resultado
para sujeto de
fig.[24]
CLIENTE cdigo
En consecuencia, un atributo multivaluado o repetitivo generalmente significa que existe una entidad que falta en el DER. Se debe verificar que un atributo no es derivado o calculado en funcin de los valores de otros atributos. Son ejemplos comunes de datos derivados o calculados de otros: - Cantidades, p. ej. el nmero de vendedores de una regin. - Totales, p. ej. la cantidad total de ventas mensuales de cada vendedor. - Mximos, mnimos y promedios, p. ej. estadsticas de ventas de un grupo de vendedores.
25
- Otros clculos, p. ej. el porcentaje de comisin sobre las ventas como retribucin a los vendedores. No se deben incluir en el DER atributos derivados o calculados de otros, dado que son redundantes y pueden conducir a inconsistencias en el valor de los datos, ya que deben ser revisados siempre que se modifiquen los atributos sobre los cuales se basan. 2.4.2. Distincin entre atributos y entidades. Si un atributo posee atributos de si mismo, entonces es realmente una entidad. Por ejemplo, determinando si todos VEHICULO son realmente atributos: los atributos de la entidad
pintado con VEHICULO cdigo proyecto de pintura VEHICULO cdigo PROYECTO DE PINTURA cdigo color de pintura usado tipo de pintura en color de guardas
fig.[25] Inicialmente se ha identificado proyecto de pintura como un atributo de VEHICULO. Posteriormente se ha definido que debe registrarse el cdigo del proyecto, el color de pintura, el tipo de pintura y el color de las guardas para cada proyecto de color. Dado que proyecto de color posee atributos de si mismo, entonces se convierte en una entidad relacionada con VEHICULO. Otro caso puede verse con los atributos de la entidad EMPLEADO:
EMPLEADO nombre nro.de familiares
responsable de EMPLEADO FAMILIARES A CARGO nombre nombre a fecha nacimiento cargo de

fig.[26]
Nmero de familiares a cargo es un atributo de EMPLEADO, pero es necesario conocer para cada familiar a cargo su nombre y edad, entones FAMILIARES A CARGO se convierte en una entidad. Nmero de familiares a cargo puede ahora obtenerse como un dato derivado o calculado.
En consecuencia, en el DER las entidades tienen atributos, pero los atributos no pueden tener atributos de si mismos.
26
En resumen, pueden verse las caractersticas de entidades y atributos:
Caractersticas de las entidades Algo sobre lo cual se necesita registrar informacin Posee uno o mas atributos
Caractersticas de los atributos Cualifica No posee si mismo a una entidad atributos de
Si una entidad no posee atriSi un atributo posee un butos, entonces puede ser sla- atributo, entonces es mente un atributo una entidad Puede tener mltiples ocurrencias asociadas con otra entidad va una relacin. Tiene un solo valor para cada ocurrencia de la entidad
2.4.3. Opcionalidad de los atributos La opcionalidad de los atributos se indica utilizando una marca. Atributos mandatorios: El valor debe ser conocido para cada ocurrencia de la entidad. Se marcan con * Atributos opcionales: El valor puede ser conocido para cada ocurrencia de la entidad. Se marcan con o Por ejemplo, sobre los atributos identificados PERSONAL, se determina su opcionalidad: para la entidad
PERSONAL *legajo *apellido o cargo *sexo o puntaje

fig.[27]
El cargo y el puntaje son opcionales, el resto de los atributos son mandatorios. Pueden utilizarse datos ejemplo de valores de atributos para varias instancias de la entidad con el propsito de validar su opcionalidad. Esto se realiza empleando una Tabla de Instancias de Entidad. Por ejemplo, para validar si las marcas (mandatorio u opcional) de opcionalidad de los atributos de la entidad PERSONAL son correctas:
27
PERSONAL *legajo *apellido o cargo *sexo o puntaje

fig.[28]
Tabla de Instancias de la entidad: PERSONAL
Atributo Marca Datos ejemplo
legajo * 110 301 134 340 589
apellido * Rosas Gonzalez Gomez Johnson Rivas
cargo
o
sexo * F M F M M
puntaje
o
Presidente Tesorero --Secretario ---
--210 110 --195
2.4.4. Identificacin de atributos Los atributos se identifican generalmente examinando las relevamiento y por consultas que se efectan a los usuarios. En las notas de relevamiento suelen aparecer como: - palabras y frases descriptivas - nombres - frases preposicionales, p. ej. salario mensual de cada empleado - nombres posesivos y pronombres, p. ej. categora del empleado Tambin deben realizarse consultas a lo usuarios, del tipo: - Qu informacin necesita conocer y/o registrar de tal ENTIDAD? - Qu informacin ENTIDAD? necesita displayar y/o imprimir acerca de tal notas de
Tambin es necesario examinar documentacin presente tal como manuales de procedimientos administrativos y de sistemas automatizados, como asimismo diseos de archivos de computadora para descubrir atributos adicionales que se hayan omitido.
Modelo de Informacin Diagrama de Entidad Relacin Ejercicio de aplicacin.
28
2.6. Desarrollar el DER para la siguiente situacin contemplando entidades, relaciones y atributos, integrando a cada atributo su marca de opcionalidad.
"Nuestro Grupo de Usuarios de Base de Datos de la regin ha crecido hasta alcanzar ms de 200 integrantes. Necesitamos un sistema de informacin que nos ayude a llevar un registro de todos nuestros asuntos. Definitivamente necesitamos automatizar nuestro registro de miembros. Por cada miembro necesitamos tener su nombre, ttulo, domicilio para mailing, nmero de telfono de la oficina, tipo de socio (individual o corporativo) y si tiene o no actualizadas sus cuotas. Recaudamos las cuotas anualmente y todas vencen en enero. Tambin necesitamos conocer para cual compaa trabaja un miembro, pero teniendo actualizada esa informacin porque nuestros miembros siempre estn cambiando de compaa. Solamente registramos un solo empleo actual por cada miembro. Nuestros miembros vienen de muchas diferentes compaas. Pocos de nuestros miembros no tienen empleo. Para cada compaa necesitamos su nombre, domicilio y el tipo de negocio. Tenemos un conjunto de cdigos de tipos de negocio estandarizado. Solamente necesitamos la direccin principal de cada compaa. Realizamos varios eventos durante el ao y necesitamos registrar informacin acerca de cada uno de ellos. Algunos de nuestros eventos anuales son la Reunin de Septiembre, la Reunin de Noviembre, la Jornada de Entrenamiento Anual en enero y nuestra Reunin de Abril. Tambin realizamos eventos especiales cada ao. Por ejemplo, hemos realizado una jornada especial de CASE el ltimo mes de mayo. Realizamos nuestros eventos siempre en distintos lugares de nuestra regin incluyendo empresas y universidades. Necesitamos registrar de cada evento la fecha, una descripcin opcional del mismo, nmero de asistentes, dnde se realiz, cunto dinero hemos gastado en l y otros comentarios adicionales. Numeramos cada comentario y frecuentenente agregamos mltiples comentarios por cada evento. Tambin registramos cuales miembros participaron en la organizacin de cada evento. Algunos de nuestros miembros son muy activos y otros participan muy poco o nada. Tambin necesitamos registrar qu tipo de plataforma de computadoras usan nuestros miembros. Tenemos un cdigo nico de tres dgitos para la identificacin de cada tipo de plataforma. Por ejemplo, 001 es para IBM/MVS; 002 es para IBM/VM; 003 es para VAX/VMS; 020 es para OS/2; 030 es para PC/DOS; 050 es para Sun UNIX; y 080 es para otras plataformas UNIX. Tambin necesitamos registrar en cuales reas de aplicacin cada miembro tiene incursin. Por ejemplo, contabilidad, recursos humanos, combustibles, droguera o sistemas de salud."
2.5. Asignacin de Identificadores Unicos (IU). Un Identificador Unico (IU) es alguna combinacin de atributos y/o relaciones que sirve para identificar unvocamente una ocurrencia de una entidad. Cada ocurrencia de la entidad deber ser unvocamente identificable.
29
Por ejemplo, en una organizacin cada ocurrencia de DEPARTAMENTO es unvocamente identificable por su nmero de departamento:
DEPARTAMENTO #*nmero *nombre
fig.[29] El IU para la entidad DEPARTAMENTO es el atributo nmero. Otro ejemplo puede verse para un teatro, cada entrada es unvocamente identificable por la fecha de funcin y el nmero de butaca:
ENTRADA #*fecha funcin #*nmero butaca
fig.[30] El IU para la entidad ENTRADA es la combinacin de dos atributos: fecha funcin y nmero butaca. Una entidad para ser tal debe tener al menos un IU. Todos los componentes del IU deben ser mandatorios. Los atributos que conforman el IU se marcan con el signo #* Una entidad puede ser unvocamente identificada por una relacin. Por ejemplo, en el control de las cuentas bancarias de las empresas, a cada banco es asignado un nmero nico, dentro de cada banco cada cuenta tiene un nico nmero de cuenta.
CUENTA nmero
administrada por aministrador de

fig.[31]
BANCO #*nmero
CUENTA es unvocamente identificada por su atributo nmero y el del BANCO especfico relacionado a la cuenta.
30
Se utiliza una barra que cruza la linea de la relacin para indicar que la misma es parte del IU de la entidad. La barra IU indica que la relacin con BANCO es parte del IU de CUENTA:
CUENTA #*nmero
administrada por administrador de

fig.[32]
BANCO #*nmero
Una relacin incluida en un IU debe ser mandatoria y uno y solo uno en la direccin en que participa del IU. Una entidad puede ser unvocamente identificada a travs de mltiples relaciones. Por ejemplo, una empresa necesita registrar las asignaciones de trabajo a sus empleados. Los empleados reciben trabajos correspondientes a proyectos. A cada empleado le pueden ser dadas mltiples asignaciones de un mismo proyecto, cada una con diferentes fecha de asignacin.
ASIGNACION DE TRABAJO *fecha de asignacin *duracin o posicin asignada para de
asignado a EMPLEADO #*legajo *nombre
objeto de PROYECTO #*nmero *ttulo
fig.[33]
31
Determinando el IU para la entidad ASIGNACION DE TRABAJO:
ASIGNACION DE TRABAJO #*fecha de asignacin *duracin o posicin asignada para de
fig.[34]
Una ASIGNACION DE TRABAJO es unvocamente identificada por el EMPLEADO que recibe la ASIGNACION DE TRABAJO, el PROYECTO al que corresponde la ASIGNACION DE TRABAJO y la fecha de asignacin. Como se ve, ambas relaciones son mandatorias y uno y solo uno en la direccin en que participan del IU. Una entidad puede tener ms de un IU. Por ejemplo, considerando la entidad EMPLEADO:
EMPLEADO *mmero de legajo *nmero liquidacin *apellido *nombre *fecha nacimiento

fig.[35]
Son IU candidatos: 1. nmero de legajo 2. nmero de liquidacin 3. apellido / nombre
32
Se debe verificar que sean nicos para cada empleado. La combinacin de apellido y nombre probablemente no lo sea, entonces no se lo tendr en cuenta como IU en este caso. De los que restan, se selecciona un IU considerando a los otros como IU secundarios. que ser el primario,
EMPLEADO #*mmero de legajo (#)*nmero liquidacin *apellido *nombre *fecha nacimiento

fig.[36]
Los IU secundarios se marcan con el signo (#)*. Se debe considerar la creacin identificar cada entidad. nicos,
de
atributos
que
ayuden
Por ejemplo, buscando identificadores nicos para la entidad CLIENTE:
CLIENTE *apellido *nombre *domicilio

fig.[37]
Posiblemente el apellido y nombre de los CLIENTEs puedan ser IU. Sin embargo, puede haber varios clientes con el mismo apellido y nombres. Se debe crear un atributo llamado cdigo de cliente que ser nico para cada instancia de la entidad CLIENTE.
CLIENTE #*cdigo *apellido *nombre *domicilio

fig.[38]
Este tipo de atributos son frecuentemente utilizados como IU. Deben crearse si en la organizacin no existe otro atributo que identifique unvocamente a una entidad.
33
2.5.1. Bsqueda entidad.
de
atributos
relaciones
que
identifiquen
cada
Evaluar los atributos: Qu atributos mandatorios identifican la entidad? Buscar atributos externos adicionales que ayuden a identificar la entidad. Considerar la creacin de nuevos atributos para la identificacin. Un atributo identifica unvocamente a la entidad? Qu combinacin de atributos identifica unvocamente a la entidad? Considerar las relaciones: Cules de las relaciones ayudan a identificar a la entidad? Hay relaciones ausentes que ayuden a identificar a la entidad? Una relacin ayuda a identificar unvocamente a la entidad? Es la relacin mandatoria y uno y slo uno en la direccin desde la entidad? Validar el IU: Examinar datos ejemplo. Es la combinacin seleccionada de atributos y relaciones identificador nico para cada instancia de la entidad? Son mandatorios todos los atributos y relaciones que se incluyen en el IU? Ejercicios de aplicacin. Adicionar las marcas a cada atributo e identificar los IUs para cada entidad en los DER correspondientes a: 2.7. Empresa de Capacitacin (pg. 9). 2.8. Video Club (2.1.)
Identificar los IUs para cada entidad en el DER correspondientes a: 2.9. Grupo de Usuarios de Base de Datos (2.6.)
Modelo de Informacin Diagrama de Entidad Relacin 3. NORMALIZACIN DEL MODELO DE DATOS.
34
La normalizacin es un concepto concerniente a las bases de datos relacionales, pero se aplica en principio a la modelizacin de datos. La validacin de cada atributo se realiza empleando las reglas de normalizacin. Primera Forma Normal (1FN): Todos los atributos deben tener un solo valor para cada ocurrencia. Segunda Forma Normal (2FN): Un atributo identificador nico ntegro de la entidad. debe ser dependiente del
Tercera Forma Normal (3FN): Ningn atributo no perteneciente al IU puede ser dependiente de otro atributo no perteneciente al IU. Un Modelo de Entidades y Relaciones normalizado automticamente puede trasladarse al diseo de la base de datos relacional. Si bien existen otras formas normales no tan generalizadas, las tres anteriores son suficientemente aceptadas para eliminar redundancias en el diseo de base de datos. 3.1. Regla de la Primera Forma Normal. Todos los atributos deben tener un solo valor para cada ocurrencia. Se debe validar que cada atributo tiene un solo valor para cada ocurrencia de la entidad. Ningn atributo debe tener valores repetitivos. Por ejemplo, se verifica si la siguiente entidad CLIENTE est en 1FN:
CLIENTE #*cdigo *fecha de contacto
fig.[39] El atributo fecha de contacto tiene mltiples valores, por lo tanto la entidad CLIENTE no est en 1FN. Se crea adicionalmente la entidad CONTACTO con una relacin M:1 con CLIENTE.
CONTACTO con #*fecha contacto o lugar o resultado

fig.[40]
CLIENTE #*cdigo sujeto de
35
Si un atributo tiene mltiples valores, se debe crear una entidad adicional y relacionarla con la entidad original mediante una relacin M:1.
3.2. Regla de la Segunda Forma Normal. Un atributo debe ser dependiente del identificador nico ntegro de la entidad. Validar que cada atributo es dependiente del identificador nico de la entidad en forma completa. Cada instancia especfica del IU debe determinar una sola instancia para cada atributo. Validar que un atributo no dependa Solamente de parte del IU de la entidad. Por ejemplo, validando los atributos dispuestos para la entidad CURSO:
CURSO #*cdigo *nombre *duracin *precio

fig.[41] Cada instancia de un cdigo de curso determina un valor especfico para nombre, duracin y precio. Los atributos estn correctamente dispuestos. Otro caso puede verse al validar la disposicin de los atributos para las entidades CUENTA y BANCO:
CUENTA administrada #*nmero por *balance *fecha apertura aministrador *ubicacion banco de
fig.[42]
BANCO #*nmero *nombre
Cada instancia de un nmero de BANCO y nmero de cuenta determina valor especfico de balance y fecha de apertura para cada cuenta. atributo ubicacin del banco est mal dispuesto pues es dependiente un BANCO pero no de un nmero de cuenta, por lo tanto no deber ser atributo de CUENTA. Si un atributo no es dependiente del IU completo de entonces est mal dispuesto y debe ser movido de entidad. su
un El de un
entidad,
36
3.3. Regla de la Tercera Forma Normal. Ningn atributo no perteneciente al IU puede ser dependiente de otro atributo no perteneciente al IU. Validar que cada atributo no perteneciente al IU no depende de otro atributo no perteneciente al IU. Mover de entidad los atributos no pertenecientes al IU que dependen de otro atributo no perteneciente al IU. Por ejemplo, determinando si algn atributo de la entidad PEDIDO no perteneciente al IU depende de otro atributo no perteneciente al IU:
PEDIDO #*nmero *fecha *cdigo cliente *nombre cliente *ciudad

fig.[43] Los atributos nombre cliente y ciudad son dependientes del cdigo cliente. Por lo tanto se crea otra entidad llamada CLIENTE con IU cdigo de cliente y se disponen sus atributos convenientemente.
PEDIDO #*nmero *fecha
solicitante de originado por

fig.[44]
CLIENTE #*cdigo *nombre *ciudad
Si en una entidad uno o ms atributos son dependientes de otro atributo no perteneciente al IU, mover todos (los dependientes y aquel del cual dependen) a una nueva entidad relacionada con la primera.
37
Ejercicio de aplicacin. 3.1. Para el siguiente DER evaluar cada entidad respecto de las reglas de normalizacin, identificando atributos mal dispuestos y explicando cual regla de normalizacin ha violado cada atributo mal dispuesto. Finalmente, redibujar el DER en 3FN.
ALISTAMIENTO para CURSO codigo de calificacion #*nmero nmero de maestro nombre descripcion calificac. nmero nombre de curso completado cdigo con nombre para nombre
de de de de de de
curso curso maestro depto. depto. maestro
asignado a ESTUDIANTE #*nmero apellido nombre
fig.[45]
Modelo de Informacin Diagrama de Entidad Relacin 4. RESOLUCIN DE RELACIONES M:M
38
Cuando los atributos parecen estar asociados con relaciones M:M, se debe resolver esta situacin interponiendo una entidad adicional que contenga esos atributos. Por ejemplo, considerando la relacin M:M entre PRODUCTO y PROVEEDOR. Cual es el precio actual de un especfico PRODUCTO para un PROVEEDOR especfico?
PRODUCTO #*cdigo *nombre *descripcin
suministrado por el suministro de

fig.[46]
PROVEEDOR #*cdigo *nombre
precio actual parece ser un atributo de la relacin entre PRODUCTO y PROVEEDOR.

Pero, los atributos solamente describen entidades. Si un atributo describe una relacin, entonces la relacin debe ser resuelta. La relacin M:M se resuelve mediante una nueva entidad interpuesta entre las anteriores y dos relaciones M:1 La relacin M:M entre PRODUCTO y PROVEEDOR puede ser resuelta adicionando una entidad interpuesta llamada ITEM CATALOGADO. Precio actual es realmente un atributo de esta entidad.
ITEM CATALOGADO *precio actual para *cantidad paquete *unidad de medida
PROVEEDOR #*cdigo *nombre el suministro de
para
suministrado por PRODUCTO #*cdigo *nombre *descripcin
fig.[47]
39
Una vez que la entidad ITEM CATALOGADO es definida, surgen los requerimientos de atributos adicionales para ella: cantidad paquete y unidad de medida son Tambin atributos de ITEM CATALOGADO. El IU de esta nueva entidad est compuesto por sus dos relaciones. La entidad interpuesta es frecuentemente identificada por relaciones originadas. Se observa en las dos barras de IU. las dos
Las relaciones desde la entidad interpuesta son siempre mandatorias. Las entidades interpuestas frecuentemente representan entidades reales de la empresa u organizacin. Las entidades interpuestas usualmente contienen cantidades y fechas. Tienden a ser de alto volumen y volatilidad.
Las entidades interpuestas se deben posicionar para permitir dibujar smbolos de cardinalidad uno o ms izquierdos o hacia arriba: Dibujo de relaciones M:M:
fig.[48]
Dibujo de entidades interpuestas:
entidad interpuesta
entidades referenciales
fig.[49]
Modelo de Informacin Diagrama de Entidad Relacin o tambin
40
Una Entidad Referencial es una entidad mandatorias que se conectan a ella.
que
no
tiene
relaciones
Cuando las relaciones M:M estn resueltas, el DER completo necesita ser revisado y rediseado. El IU de una entidad interpuesta est frecuentemente compuesto por sus relaciones con las dos entidades que la originaron. Por ejemplo, resolviendo la siguiente relacin M:M para ajustarse a los requerimientos adicionales:
"Necesitamos registrar la fecha en que cada estudiante se ha inscripto en un curso, la fecha en que ha completado el curso y su calificacin"
ESTUDIANTE #*nmero *apellido *nombre o telfono

fig.[50]
CURSO #*cdigo *nombre o precio o duracin
Adicionando la entidad interpuesta ALISTAMIENTO y dos relaciones M:1
41
ALISTAMIENTO *fecha de inscripcin o fecha de finalizacin o calificacin
para
para
inscripto en ESTUDIANTE #*nmero *apellido *nombre o telfono
tomado por CURSO #*cdigo *nombre o precio o duracin

fig.[51]
ALISTAMIENTO tiene los atributos finalizacin y calificacin.
fecha
de
inscripcin,
fecha
de
El IU de ALISTAMIENTO est compuesto por sus relaciones con ESTUDIANTE y CURSO. Este modelo solamente registra la ltima vez que un estudiante se inscribi en un curso especfico. Si mltiples ocurrencias necesitan ser registradas, se debe incluir el atributo fecha de inscripcin como parte del IU. Las relaciones de una entidad interpuesta con las dos entidades originales pueden no ser suficientes para definir unvocamente a cada ocurrencia de la entidad interpuesta. Por ejemplo, resolviendo la siguiente relacin M:M para ajustarse a los requerimientos adicionales: "Necesitamos registrar la fecha en que cada empleado es asignado a un proyecto y la duracin de esa asignacin"
EMPLEADO #*legajo *nombre
asignado a asignado a
fig.[52]
PROYECTO #*nmero *ttulo
42
Adicionando una entidad interpuesta llamada ASIGNACION DE TRABAJO con atributos fecha de asignacin y duracin:
ASIGNACION DE TRABAJO *fecha de asignacin *duracin o posicin asignada para de
fig.[53]
ASIGNACION DE TRABAJO es parcialmente identificada por sus relaciones con EMPLEADO y PROYECTO, pero esas dos relaciones no son bastantes para identificar unvocamente a la entidad ASIGNACION DE TRABAJO. Un empleado puede tener mltiples asignaciones a un proyecto, con diferentes fechas de asignacin. En consecuencia, el IU de ASIGNACION DE TRABAJO debe incluir al EMPLEADO relacionado, al PROYECTO relacionado y al atributo fecha de asignacin. Una vez que una entidad interpuesta es identificada, se deben buscar atributos adicionales que la describan. Por ejemplo, qu informacin necesita relacin entre PRODUCTO y PROVEEDOR? ser conocida acerca de la
"Necesitamos registrar el precio actual de un PRODUCTO especfico para un PROVEEDOR especfico" Resolviendo la siguiente requerimientos adicionales: relacin M:M para ajustarla a los
PRODUCTO #*cdigo *nombre *descripcin
suministrado por el suministro de

fig.[54]
43
Adicionando la entidad interpuesta ITEM PROVISTO con un atributo precio actual. Qu otra informacin necesita ser conocida acerca de ITEM PROVISTO?
"Tambin necesitamos conocer la cantidad empaquetada y la unidad de medida de cada ITEM PROVISTO"
ITEM PROVISTO *precio actual para *cantidad paquete *unidad de medida
PROVEEDOR #*cdigo *nombre el suministro de
para
fig.[55]
Se deben buscar atributos que identifiquen o ayuden a identificar la entidad interpuesta. Por ejemplo, para identificar cada ITEM PROVISTO puede utilizarse una combinacin del cdigo del PROVEEDOR relacionado y cdigo del PRODUCTO, o tener un catlogo ordenado de todos los ITEMs PROVISTOs, donde cada ITEM PROVISTO tiene un nico numero catalogado:
44
ITEM PROVISTO #*nmero catalogado *precio actual *cantidad paquete *unidad de medida para
para el suministro de
fig.[56]
En este caso y de acuerdo con las normas de la empresa, cada ITEM PROVISTO tiene un nico nmero catalogado, por lo tanto, el atributo nmero catalogado debe es el IU de ITEM PROVISTO. Si finalizando la etapa de modelizacin de datos an restan relaciones M:M por resolver, su resolucin forzada puede resultar en la creacin de entidades interpuestas que no posean atributos. Por ejemplo, en el caso del Video Club la siguiente situacin fue definida:
PELICULA #*cdigo *ttulo o categora
protagonizada por protagonista en

fig.[57]
ACTOR #*cdigo *nombre artistico o nombre real o fecha nacimiento
Finalizando la etapa de modelizacin, el usuario no ha identificado ningn atributo asociado a la relacin M:M, puede entonces resolverse la relacin M:M creando una entidad interpuesta que no posea atributos.
45
REPARTO DE ACTORES
para
para protagonizada por protagonista en ACTOR #*cdigo *nombre artstico o nombre real o fecha nacimiento
fig.[58]
PELICULA #*cdigo *ttulo o gnero
Una entidad interpuesta que no tiene atributos es justamente una doble-va para listar referencias cruzadas entre ocurrencias de las entidades. Una entidad interpuesta que no tiene atributos es la excepcin a la regla que expresa: "una entidad debe tener atributos para ser una entidad". El IU de una entidad interpuesta vaca est siempre compuesto por las relaciones con las dos entidades de las cuales se ha originado. Ejercicios de aplicacin. 4.1. En el DER desarrollado para el ejercicio del Grupo de Usuarios de Base de Datos (2.6.), una relacin M:M fue inicialmente modelizada entre las entidades MIEMBRO y AREA DE APLICACION. Resolver dicha relacin M:M considerando los siguientes requerimientos adicionales:
"Tambin deseamos llevar una cada miembro ha realizado en ejemplo, un miembro puede aplicacin contable que ha puede estar incursionando en incursin."
breve descripcin de cada incursin que cada rea de aplicacin especfica. Por tener realmente un gran sistema de desarrollado internamente. Otro miembro un rea de aplicacin sin describir su
4.2. Resolver la siguiente relacin M:M entre las entidades CLIENTE y PRODUCTO, adicionando los atributos fecha de pedido, cantidad pedida y precio.
CLIENTE #*cdigo *apellido *nombre
solicitante de ordenado por

fig.[59]
PRODUCTO #*nmero *nombre *unidad de medida
Modelo de Informacin Diagrama de Entidad Relacin 5. MODELIZACIN JERRQUICA DE DATOS.
46
Los datos jerrquicos pueden ser representados como un conjunto de relaciones muchos a uno.
EMPRESA
EQUIPO
DIVISION
dentro de formado por DEPARTMENTO
DEPARTAMENTO
dentro de formada por DIVISION
EQUIPO dentro de formada por EMPRESA

fig.[60]
Los Identificadores Unicos del conjunto de entidades pueden ser propagados a travs de mltiples relaciones. Por ejemplo, estableciendo DEPARTAMENTO y HABITACION: los IU para las
jerrquicas
entidades
PISO,
47
HABITACION #*cdigo
ubicada dentro de conformado por DEPARTAMENTO #*nmero o propietario ubicado en conformado por PISO #*nmero
contenido en conformado por EDIFICIO #*nmero *nombre *direccin

fig.[61]
El IU de HABITACION es el cdigo de habitacin DEPARTAMENTO dentro del cual est situada.
el
nmero
de
El IU de DEPARTAMENTO es el nmero de departamento y el del PISO donde est situado. El IU de PISO es el nmero de piso y el del EDIFICIO que lo contiene. Se debe considerar la creacin de atributos ficticios para ayudar a la identificacin de entidades en una relacin jerrquica.
48
Por ejemplo, en la estructura tpica de una organizacin, qu podra identificar unvocamente a las instancias de las entidades DIVISION, DEPARTAMENTO y EQUIPO?
EQUIPO dentro de conformado por DEPARTAMENTO
dentro de conformada por DIVISION
dentro de conformada por EMPRESA
fig.[62] Cada EQUIPO podra ser identificado basndose sobre su DEPARTAMENTO, DIVISION y EMPRESA. O cada entidad podra tener un nico e independiente cdigo de identificacin ficticio. Los cdigos ficticios de identificacin nicos e independientes son generalmente de corta longitud. Si la estructura jerrquica tiene frecuentes cambios, es conveniente usar identificadores ficticios independientes.
49
6. MODELIZACIN DE RELACIONES RECURSIVAS. Una Relacin Recursiva es una relacin entre una entidad y si misma. Por ejemplo, obsrvese la relacin recursiva existente en el siguiente DER:
EMPLEADO #*legajo *apellido *nombre o tarea *fecha de alta o salario o comisin supervisor de
supervisado por
fig.[63]
Cada EMPLEADO puede ser supervisado por uno y solo un EMPLEADO. Cada EMPLEADO puede ser el supervisor de uno o ms EMPLEADOs. Puede representarse a las relaciones jerrquicas como una relacin recursiva. Por ejemplo, la jerarqua de la estructura representarse como una relacin recursiva: organizativa puede
50
EQUIPO dentro de conformado por DEPARTAMENTO
ELEMENTO DE LA ORGANIZACION #*cdigo *nombre
dentro de
conformado por
dentro de conformada por DIVISION
dentro de conformada por EMPRESA

fig.[64]
La entidad recursiva nica debe incluir todos los atributos de cada entidad individual. Idealmente, las entidades de cada nivel de la jerarqua deberan tener los mismos atributos. Un modelo de organizacin recursiva puede prontamente acomodarse a las adiciones o sustracciones de las capas o niveles de la organizacin. Un modelo de organizacin recursiva no puede manejar relaciones mandatorias. Si cada ELEMENTO DE LA ORGANIZACION debe estar dentro de otro ELEMENTO DE LA ORGANIZACION, entonces la organizacin jerrquica tiende a ser infinita. Una relacin recursiva debe ser opcional en ambas direcciones. Otro caso puede verse con los datos del montaje de piezas o materiales, que pueden ser modelizados con mltiples entidades para cada categora de "parte" y un juego de relaciones entre cada una de esas entidades. Por ejemplo, una industria automotriz necesita registrar: partes elementales, subensamblables, ensamblables y productos. El siguiente DER modela esos datos considerando cada una de esas categoras de partes como una entidad.
51
PARTE ELEMENTAL parte de parte parte de de
p.ej: tuercas, mangueras
p.ej: carburador, compuesto radiador por SUBENSAMBLABLE parte de parte de compuesto por compuesto por parte de parte de compuesto por PRODUCTO
compuesto por ENSAMBLABLE
p.ej: sist.combustible parte de
compuesto por
compuesto por p.ej: auto, tractor
compuesto por
parte de fig.[65] compuesto por
Pueden modelizarse los datos del montaje de piezas o materiales como una relacin recursiva muchos a muchos: Por ejemplo, para la industria automotriz considerar todos las partes elementales, subensamblables, ensamblables y productos como instancias de una entidad llamada COMPONENTE. De tal modo, el complejo DER previo puede ser remodelado como una simple entidad recursiva:
COMPONENTE #*cdigo
parte de
compuesto por
fig.[66]
52
Cada COMPONENTE puede ser parte de uno o ms COMPONENTEs. Cada COMPONENTE puede estar compuesto por uno o ms COMPONENTEs. Puede resolverse la relacin recursiva M:M con una entidad interpuesta y dos relaciones M:1 diferentes para las instancias de la entidad original. Por ejemplo, considerando la estructura recursiva del modelo de montaje de materiales, ste registrar informacin acerca de cuales componentes son parte de un ventilador. Pero si una tuerca es parte de un ventilador, tambin registrar cuntas tuercas son parte de un ventilador?
COMPONENTE #*cdigo
parte de
compuesto por
fig.[67] El atributo cantidad parece estar asociado con la relacin recursiva. Puede resolverse la relacin recursiva M:M adicionando la entidad interpuesta NORMA DE ENSAMBLADO y dos relaciones M:1 con la entidad COMPONENTE. NORMA DE ENSAMBLADO tendr un atributo cantidad.
NORMA DE EMSAMBLADO o cantidad
para
para
compuesto por COMPONENTE #*cdigo
parte de
fig.[68]
53
Las dos relaciones M:1 desde una instancia de NORMA DE ENSAMBLADO estarn asociadas con diferentes instancias de la entidad COMPONENTE. Por ejemplo, una instancia de NORMA DE ENSAMBLADO para tuerca de ventilador tendr una relacin M:1 con la instancia de COMPONENTE para tuerca y una segunda relacin M:1 con la instancia de COMPONENTE para ventilador. La entidad REGLA DE ENSAMBLADO registrar la cantidad de tuercas que son parte de un solo ventilador.
Ejercicio de aplicacin. 6.1. Desarrollar dos DER para representar la siguiente situacin, uno como una estructura jerrquica y otro como una estructura recursiva.
"Nuestra compaa vende productos en todo el pas. Tenemos dividido el pas en cuatro grandes regiones de venta: Regin Norte, Sur, Este y Oeste. Cada regin de venta tiene un cdigo nico de regin. Cada regin de venta est dividido en distritos de venta. Cada distrito tiene un cdigo nico de distrito. Cada distrito tiene territorios de venta. Cada territorio tiene un cdigo nico de territorio. Cada territorio de venta se divide en reas de venta. Cada rea de venta tiene un cdigo nico de rea. Cada vendedor es responsable de una o ms reas de venta y tiene una cuota de ventas especfica. Tambin tenemos gerentes de venta quienes son responsables por uno o ms distritos de venta y directores de venta quienes son responsables por una o ms regiones de venta. Cada Gerente de Venta es responsable por los territorios dentro de sus distritos. No queremos superponer las responsabilidades de nuestros empleados, por eso un rea de venta es siempre responsabilidad de un solo vendedor y de tal modo nuestros gerentes y directores tampoco superponen sus responsabilidades. Identificamos a todo nuestro personal por su nmero de legajo."
Modelo de Informacin Diagrama de Entidad Relacin 7. MODELIZACIN DE ROLES MEDIANTE RELACIONES. Debe prestarse atencin a las entidades que representan roles.
54
Por ejemplo, en el DER de la empresa de capacitacin, se han definido las entidades INSTRUCTOR y ESTUDIANTE. Este modelo trabaja bien si un INSTRUCTOR nunca es un ESTUDIANTE o un ESTUDIANTE nunca es un INSTRUCTOR. Pero qu ocurre si un INSTRUCTOR es tambin un ESTUDIANTE?
para
para
tomado por CURSO #*cdigo *nombre o precio o duracin dictado por docente en INSTRUCTOR #*cdigo *apellido *nombre o telfono
fig.[69]
Las entidades superpuestas.
que
representan
roles
pueden
compartir
instancias
Usando relaciones para modelizar roles, estas mltiples roles a una sola instancia de la entidad.
permiten
asumir
Por ejemplo, para la empresa de capacitacin, definimos una entidad PERSONA la cual puede tomar los roles de instructor y/o estudiante.
55
ALISTAMIENTO *fecha de inscripcion o fecha de finalizacin o calificacin para para estudiante de instructor de dictado por tomado por CURSO #*cdigo *nombre o duracin o precio
PERSONA #*cdigo *apellido *nombre o telfono
fig.[70]
Modelo de Informacin Diagrama de Entidad Relacin 8. MODELIZACIN DE SUBTIPOS Y SUPERTIPOS.
56
Los subtipos y supertipos se utilizan para modelizar entidades que tienen atributos y relaciones en comn. Por ejemplo: "Una empresa ha definidos dos tipos de empleados: mensualizados y jornalizados. Para todos los empleados registra cada nmero de legajo, apellido, nombre y departamento asignado. Para los empleados mensualizados tambin registra su salario. Para los jornalizados registra valor hora normal, valor hora extra y su adhesin a algn sindicato." Se crea un supertipo EMPLEADO con dos subtipos. Cada EMPLEADO es un EMPLEADO MENSUALIZADO o un EMPLEADO JORNALIZADO.
EMPLEADO
#*legajo *apellido *nombre
EMPLEADO MENSUALIZADO *salario
EMPLEADO JORNALIZADO *valor hora normal *valor hora extra miembro de
asignado a compuesto por DEPARTAMENTO compuesto por SINDICATO
fig.[71]
57
Un supertipo es una entidad que tiene subtipos. Un supertipo puede ser partido en dos o ms subtipos mutuamente excluyentes. Por ejemplo, un EMPLEADO es un EMPLEADO MENSUALIZADO o un EMPLEADO JORNALIZADO, pero no ambas cosas. Un supertipo puede tener atributos y relaciones compartidas pos sus subtipos. Por ejemplo, todos los EMPLEADOs deben tener atributos nmero de legajo, apellido y nombre. Todos los EMPLEADOs deben estar asignados a uno y solo un DEPARTAMENTO. Cada subtipo puede tener sus propios atributos y relaciones. Por ejemplo, el subtipo EMPLEADO MENSUALIZADO tiene un atributo salario. El subtipo EMPLEADO JORNALIZADO tiene atributos de valor hora normal, valor hora extra y una relacin con la entidad SINDICATO. Debe tenerse presente que un subtipo que no tiene atributos o relaciones propios puede ser un sinnimo de la entidad supertipo y no un subtipo.
Todas las instancias de la entidad supertipo deben pertenecer a una y solo una de las entidades subtipo. Los subtipos deben conformar un conjunto completo sin superposiciones. Por ejemplo, generalmente una tarea es entre una TAREA MANUAL o una TAREA MECANIZADA, pero puede haber algunas excepciones.
TAREA TAREA MANUAL TAREA MECANIZADA
OTRA TAREA
fig.[72]
Cada TAREA debe ser entre una TAREA MANUAL, una TAREA MECANIZADA u OTRA TAREA. Siempre se debe usar el subtipo OTRO cuando no se tenga seguridad de que el conjunto este completo.
58
Los subtipos pueden contener a otros necesario anidar dos o tres niveles.
subtipos.
Normalmente
es
Por ejemplo, definiendo subtipos para la entidad NAVE AEREA.
NAVE AEREA AEROPLANO PLANEADOR AEROPLANO PROPULSADO TURBOHELICE JET
HELICOPTERO
DIRIGIBLE
OTRA NAVE AEREA
fig.[73]
AEROPLANO es un subtipo de NAVE AEREA y un supertipo de AEROPLANO MOTORIZADO y de PLANEADOR. JET hereda los atributos AEROPLANO y NAVE AEREA. y relaciones de AEROPLANO PROPULSADO,
59
9. MODELIZACIN DE RELACIONES EXCLUYENTES. En la modelizacin de dos o ms relaciones mutuamente excluyentes desde la misma entidad, se utiliza un arco para denotar tal circunstancia. Por ejemplo, una CUENTA BANCARIA debe ser poseda por una PERSONA o debe ser poseda por una EMPRESA. Utilizamos un arco para modelizar esta relacin.
poseida por CUENTA BANCARIA poseedor de poseida por
PERSONA
EMPRESA poseedor de
fig.[74]
Cada CUENTA BANCARIA debe ser poseda por una y solo una PERSONA o debe ser poseda por una y solo una EMPRESA. Convenciones para la modelizacin de arcos: - Las relaciones en un arco frecuentemente tienen el mismo nombre de relacin. - Las relaciones opcionales. en un arco deben ser todas mandatorias o todas
- Un arco pertenece a una sola misma entidad y debe solamente incluir a las relaciones originadas en esa entidad. - Una entidad puede tener mltiples arcos, pero particular puede solamente participar en un arco. una relacin en
60
Convenciones para el dibujo de los arcos: Un punto sobre el cruce entre el arco y la relacin es usado para significar que la misma pertenece al arco.
fig.[75]
Ejercicio de aplicacin. 9.1. Desarrollar un DER para el siguiente informe de requerimientos:
"Nuestra empresa se dedica al alquiler de autoportantes y trailers. Tenemos varios locales de alquiler diseminados por todo el pas. Nuestro stock de alquiler incluye un gran nmero de vehculos, con varios tipos de autoportantes y trailers. Necesitamos implementar un sistema para registrar nuestros contratos de alquiler y vehculos alquilados. Cada local de alquiler renta los vehculos que tiene en stock a los clientes interesados en ese momento. No hacemos reservaciones. La casa central controla la distribucin de vehculos y directamente transfiere los vehculos desde un local de alquiler a otro. Cada local de alquiler tiene un nombre propio. Tambin tiene un nmero nico de local de tres dgitos. Tambin registramos el domicilio del local. Cada local es el deposito para algunos de nuestro vehculos y cada vehculo es depositado en un solo local. Cada vehculo tiene un cdigo, lugar de patentamiento y un nmero de patente. Tenemos cinco tipos diferentes de vehculos y un cdigo de tipo de vehculo. Para todos nuestros vehculos necesitamos registrar la fecha del ltimo mantenimiento mecnico y fecha de vencimiento de su patente. Para nuestros autoportantes, necesitamos conocer la lectura actual del odmetro, la capacidad del tanque de gas y si tiene o no radio. Anotamos el kilometraje justo antes de alquilar un remolque y luego cuando es devuelto. La mayora de nuestros contratos de alquiler son a clientes individuales, pero un contrato de alquiler puede ser para una persona o para una empresa. Como tenemos alquilado un pequeo porcentaje de nuestros remolques a empresas, asignamos a cada empresa un nmero identificador y registramos su nombre, domicilio y telfono. Para cada cliente individual registramos su nombre, telfono particular, domicilio y emisor, nmero y fecha de vencimiento de su registro de conducir. Necesitamos llevar un registro de todos nuestros clientes. Si un cliente daa un vehculo, o lo abandona o no paga
61
totalmente la factura, lo marcamos como cliente de riesgo y no le alquilamos nuevamente ningn vehculo. Solamente permitimos que un contrato de alquiler dado sea para un solo individuo o compaa y hacemos un contrato para cada vehculo. Tenemos clientes que alquilan dos o ms vehculos al mismo tiempo. Cada contrato de alquiler es identificado por el nmero de local de alquiler original y el nmero de contrato. Tambin necesitamos registrar la fecha de alquiler, la duracin del alquiler, el local de alquiler originario, la cantidad pagada como depsito, el valor diario de alquiler y el valor por kilmetro. Para los trailers no hay cargo por kilmetro."
Modelo de Informacin Diagrama de Entidad Relacin 10. MODELIZACIN DE DATOS HISTRICOS. Agregando al DER entidades contemplarse datos histricos. y relaciones adicionales
62
pueden
Es de utilidad consultar al usuario respecto de si: - Se requieren registros de auditora? - Pueden los valores de los atributos cambiar en el tiempo? - Pueden las relaciones cambiar en el tiempo? - Puede necesitarse consultar datos antiguos? - Puede necesitarse guardar datos previos? Es conveniente validar con el usuario los requerimientos de almacenamiento de datos histricos. Almacenar datos innecesarios puede ser costoso.
Creando una entidad adicional atributos en el tiempo.
pueden
registrarse
valores
de
los
Por ejemplo: Una firma consultora necesita guardar informacin acerca de sus contratos. Cada contrato tiene un nico identificador y se necesita guardar una descripcin de la contratacin, el estado (p.ej. abierto, cerrado o suspendido). Inicialmente fue modelada la siguiente entidad CONTRATO:
CONTRATO #*cdigo *descripcin *estado *fecha

fig.[76]
La entidad CONTRATO definida anteriormente soporta un solo valor actual del estado para un CONTRATO. Los usuarios quieren registrar las fechas en que cada contrato fue abierto, cerrado y eventualmente suspendido. Para modelizar los valores de estado en el tiempo, se crea una entidad ESTADO:
estado de ESTADO #*fecha *valor en

fig.[77]
CONTRATO #*cdigo *descripcin
63
El IU de la entidad ESTADO es la relacin con CONTRATO y la fecha de efectivizacin. Una misma entidad puede utilizarse para registrar mltiples valores histricos de atributos asociados con una entidad. Asimismo, adicionando una nueva entidad relacin que puede cambiar en el tiempo. se logra acondicionar una
Por ejemplo: Un propietario de departamentos desea registrar los inquilinos de cada uno de sus departamentos. Un contrato de alquiler de un departamento puede estar a nombre de una sola persona, no de varias personas. El siguiente DER solamente registrar el actual arrendatario de un DEPARTAMENTO.
DEPARTAMENTO #*cdigo *direccin
alquilado por inquilino de

fig.[78]
PERSONA #*documento *apellido *nombres
Adicionando la entidad ALQUILER HISTORICO para capturar los valores de la relacin de alquileres en el tiempo.
ALQUILER HISTORICO #*fecha desde o fecha hasta para
para inquilino de
PERSONA #*documento *apellido *nombres
alquilado por DEPARTAMENTO #*cdigo *direccin
fig.[79]
64
Una entidad interpuesta es frecuentemente usada para informacin acerca de relaciones que cambian en el tiempo.
registrar
Por ejemplo: Una asociacin profesional desea registrar las empresas en las cuales sus miembros han sido empleados, historicamente y en lo referente al perodo de cada empleo. Hay una relacin M:M entre cada miembro y cada empresa.
MIEMBRO #*nmero *apellido *nombres
empleado de empleador de
fig.[80]
EMPRESA #*cdigo *nombre
Adicionando la entidad interpuesta EMPLEO HISTORICO para registrar en el tiempo cada empleo y las fechas de los perodos de los mismos.
EMPLEO HISTORICO #*fecha desde o fecha hasta para empleado de MIEMBRO #*nmero *apellido *nombre para empleador de EMPRESA #*cdigo *nombre
fig.[81]
Dado que se incluye el atributo fecha desde en el IU de EMPLEO HISTORICO, este modelo registrar mltiples perodos de empleo en una misma empresa para un mismo empleado.
65
Ejercicio de aplicacin. Modelizacin de datos histricos. 10.1. Modificar el DER del ejercicio del Video Club adecuarlo a los siguientes requerimientos adicionales: (2.1.) para
"Necesitamos guardar un histrico de todos nuestros alquileres. Cada vez que un cliente alquila una cinta necesitamos guardar la fecha de alquiler y la fecha de devolucin. Todos nuestros alquileres vencen al da siguiente, por lo tanto no necesitamos registrar la fecha de vencimiento. Guardar este historial nos permitir analizar la modalidad de nuestros alquileres. Podremos determinar cuantas cintas alquila cada cliente y cuantas veces ha devuelto las cintas tarde. Tambin podremos conocer cuantas veces ha sido usada una cinta en particular y entonces sabremos cuando renovar cada cinta. Tambin podremos analizar las preferencias de nuestros clientes respecto de nuestras pelculas."
Modelo de Informacin Diagrama de Entidad Relacin 11. MODELIZACIN DE RELACIONES COMPLEJAS. Debe prestarse especial atencin a los anillos de relaciones M:M.
66
Por ejemplo, en el desarrollo de un DER para la historia laboral, para cada persona se registra la posicin que ocupa, la empresa para la cual trabaja y las fechas entre las cuales la posicin fue ocupada. Una persona puede ocupar una posicin especfica dentro de la misma empresa mltiples veces durante su carrera. Inicialmente se ha definido el siguiente DER:
PERSONA poseedor #*documento de *apellido poseida *nombres por empleada por empleador de EMPRESA #*cdigo *nombre incluida en
POSICION #*tarea o descripcion
empleador de
fig.[82] Las fechas de la posicin parecen ser atributos de una relacin. En consecuencia, deben resolverse las relaciones M:M.
67
PERSONA poseedor HISTORIA #*documento de POSICION *apellido *nombres para empleada por
para
POSICION #*tarea o descripcion
poseida por incluida en
para HISTORIA EMPRESA
para HISTORIA ORGANIZACION
para
para
empleador de EMPRESA #*cdigo *nombre
empleador de
fig.[83]
Cual de las entidades interpuestas debe contener los atributos de las fechas de la posicin? Todas? Ninguna? Se debe modelizar una relacin entre las tres o ms entidades como una entidad interpuesta con relaciones mandatorias con esas entidades. Por ejemplo, la historia laboral de una persona es en realidad una relacin de tres caminos entre las entidades PERSONA, EMPRESA y POSICION. Utilizamos una sola entidad interpuesta llamada HISTORIA LABORAL para modelizar estas relaciones.
68
HISTORIA LABORAL en #*fecha desde o fecha hasta con para
empleador de
EMPRESA #*cdigo *nombre
parte de PERSONA #*documento *apellido *nombres incluida en
POSICION #*cargo *descripcin
fig.[84]
Una relacin compleja es aquella que se da entre tres o mas entidades. Una entidad interpuesta para relaciones mandatorias hacia relaciona. una relacin compleja siempre tiene las entidades con las cuales se
Para una entidad interpuesta que representa una relacin compleja, se deben seguir las reglas bsicas de modelizacin de DER para nombrar la entidad y analizar y modelizar sus relaciones, sus atributos y su IU. Deben considerarse sus relaciones mandatorias como candidatas a ser incluidas en su IU. Ejercicios de aplicacin. Modelizacin de relaciones complejas. 11.1. En el DER del ejercicio del Grupo de Usuarios de Base de Datos (2.6.), una relacin M:M fue inicialmente modelizada entre las entidades MIEMBRO y PLATAFORMA DE COMPUTACION. Revisar esa relacin basndose en los siguientes requerimientos adicionales:
"Realmente computacin adems cul usando cada
no necesitamos conocer solamente qu plataforma de est usando cada miembro. En cambio, necesitamos saber producto de base de datos (RDBMS, C, SQL, CASE, etc.) est miembro sobre cul plataforma de computacin."
69
Desarrollo de un modelo DER complejo. 11.2. Desarrollar un modelo DER para la siguiente empresa:
"Soy el socio mayoritario de un importante estudio de abogados. Manejamos una amplia variedad de casos incluyendo accidentes, divorcios, litigios civiles y homicidios. Nuestro estudio est integrado por varios departamentos como ser litigios, homicidios, etc., y cada caso es asignado a un departamento en particular por cuestiones administrativas. Los abogados estn Tambin asignados a un departamento en particular, pero esto es para propsitos administrativos y salariales, ya que un abogado puede trabajar en casos de distintos departamentos. Necesitamos una lista de los eventos para un caso dado (esencialmente una historia del caso) que incluya un resumen del evento y la fecha en que ocurri. Los casos son identificados por un nmero nico, el cual aparecer en un listado con todas las descripciones de los eventos y sus fechas. Los eventos tienen cdigos especiales como ser A para Abiertos, J para Juicios, P para Perdidos. Siempre debe haber un estado para los eventos de todos los casos. Deseamos guardar un registro de la informacin importante asociada con un caso incluyendo el departamento al cual es asignado y una breve descripcin. Despus de que un caso es cerrado, puede ser reabierto posteriormente. A los casos reabiertos le asignamos nuevos nmeros de caso, pero necesitamos enlazar el nuevo caso con el anterior. Los abogados pueden ser parte de mltiples casos, al igual que ciertas personas pueden ser parte de mltiples casos. Por ejemplo, alguien puede ser juez en un caso y testigo en otro. Solamente estamos interesados en registrar las partes y los roles que ellos juegan en el contexto de un caso en particular. Las partes deben ser identificadas por sus nombres y apellidos y su fecha de nacimiento y un cdigo. Las partes que pueden estar involucradas en un caso incluyen jueces (J), testigos (T), defendidos (D) y abogados (A). Por ejemplo, tenemos un caso de asesinato en el cual trabajamos para la defensa. Un abogado es asignado al caso y hay un juez para el caso. Hay tambin testigos. As, hay varias personas quienes son parte en este caso y necesitamos tener conocimiento acerca de ellas. Para el trabajo de la variante de roles que una persona puede tener, asumimos que una persona dada puede servir como parte en distintos roles en diferentes casos, pero puede solamente servir en un rol en un caso dado."
11.3. Desarrollar un modelo DER para la siguiente empresa:
"Nuestra empresa realiza cruceros en barco. Hemos decidido que nuestro sistema manual de registracin de pasajeros de nuestros barcos no queremos tenerlo ms cuando obtengamos nuestro nuevo barco. As es, tendremos dos barcos y probablemente nos expandamos a 5 o 6 para el ao prximo. Cada barco tiene un nombre, una cantidad especfica de pasajeros y bandera. La bandera es el pas en donde est registrado. No necesitamos preocuparnos por otra cosa acerca de los barcos. Cada ao ponemos un aviso con la informacin de cada crucero que ofrecemos. Todos los cruceros tienen un nombre y una duracin en nmero de das de crucero. Cada crucero tambin tiene un barco especfico asignado, algunas personas quieren viajar solamente en barcos nuevos. Si, necesitaremos conocer tambin la edad de cada
70
barco. Tambin, para cada crucero tenemos diferentes puertos de parada. Un crucero de tres das tendr solamente una parada, siempre en el segundo da, un crucero de siete das parar en tres puertos, etc. Variamos los puertos dependiendo de donde comienza el crucero. Dependiendo de la duracin de cada crucero, cada uno har visitas a los puertos en diferentes das. Los pasajeros que navegan con nosotros pueden escoger un crucero dado, el cual tiene una cierta duracin y un nmero de puertos. Sobre el crucero que ellos escogen tenemos que decirles cuales camarotes estn disponibles. Una vez que eligen sobre los disponibles podemos darle el precio. Este depende del nmero de ocupantes y de la clase del camarote. Siempre que reservamos un camarote en nuestro sistema manual lo removemos de la tabla de disponibilidades, al menos que no este completa su capacidad y el pasajero quiera compartirlo con otras personas. Si el camarote tiene capacidad para cuatro personas y ellas estn viajando solas, entonces les cuesta mas. Una vez que los pasajeros estn registrados y tenemos un depsito de ellos, entonces podemos pagarle su comisin al agente de viajes quien hizo la reservacin."
71
12. DISEO RELACION.
DE
LA
BASE
DE
DATOS
PARTIR
DEL
MODELO
DE
ENTIDAD-
No obstante ser el Diseo de Base de Datos un tema de envergadura y que se ha de tratar en forma separada en un posterior trabajo, daremos aqu una breve idea general de sus alcances. El diseo de base de datos es realizado durante la etapa de DISEO dentro del ciclo de desarrollo de un sistema, en forma paralela con el diseo de la aplicacin (ver figura [1]) y a partir de las definiciones producidas en el Diccionario de Datos como resultado de la etapa de ANALISIS. El diseo de la base de datos es realizado en dos grandes actividades, cada una de las cuales incluye distintos pasos: ACTIVIDAD 1. Mapeo del Modelo DER a tablas relacionales para producir un diseo inicial. 1.1. Mapeo de cada entidad simple en una tabla. 1.2. Mapeo de los atributos documentacin de datos ejemplo. en las columnas de la tabla y
1.3. Mapeo de los identificadores nicos en claves primarias. 1.4. Mapeo de las relaciones en claves externas. 1.5. Normalizacin de las tablas. ACTIVIDAD 2. Refinamiento del diseo inicial para producir un completo diseo de la base de datos. 2.1. Definicin de las restricciones de integridad referencial. 2.2. Diseo de ndices. 2.3. Establecimiento de vistas. 2.4. Desnormalizacin del diseo de la base de datos. 2.5. Planificacin del uso del espacio fsico. En resumen, la etapa de diseo de base de datos a partir del modelo DER produce especificaciones de diseo para base de datos relacional incluyendo definicin de tablas relacionales, ndices, vistas y espacios fsicos.
Modelo de Informacin Diagrama de Entidad Relacin BIBLIOGRAFIA
72
- Data Modelling and Data Base Design - Oracle Corporation. - Anlisis Estructurado Moderno - Yourdon - Prentice Hall. - CASE-METHOD -El Modelo de Entidad-Relacin - Barker - Addison Wesley
73
APENDICE A - RESOLUCION DE LOS EJERCICIOS Ejercicio 2.1.
CINTA nmero formato
PELICULA cdigo ttulo categora
CLIENTE nmero de socio apellido nombres telfono domicilio
ACTOR cdigo nombre artstico nombre real fecha de nacimiento
- una CINTA significa un soporte fsico para contener copias de parte o la totalidad de una y slo una PELICULA del Video Club. - una PELICULA significa una obra cinematogrfica contenida en una o ms CINTAs. - un ACTOR significa uno de los protagonistas en una o ms PELICULAs. - un CLIENTE significa un socio del Video Club. Alquila una o ms CINTAs que contienen las PELICULAs.
Ejercicio 2.2. Cada PEDIDO debe ser salida para uno o ms ITEMs. Cada ITEM puede ser solicitado va uno o ms PEDIDOs. Cada PEDIDO debe ser originado por uno y slo un CLIENTE. cada CLIENTE puede ser origen de uno o ms PEDIDOs. Cada ITEM debe estar almacenado en uno y slo un DEPOSITO. Cada DEPOSITO puede ser repositorio para uno o ms ITEMs.
Modelo de Informacin Diagrama de Entidad Relacin Ejercicio 2.3.
74
EMPLEADO
DEPARTAMENTO
asignado a realizada por ACTIVIDAD
Ejercicio 2.4.
CURSO cdigo nombre precio duracin tomado por
dictado por docente en
INSTRUCTOR (PROFESOR) apellido nombres telfono
inscripto en ESTUDIANTE apellido nombres telfono
CURSO CURSO ESTUDIANTE INSTRUCTOR inscripto en docente en
ESTUDIANTE tomado por
INSTRUCTOR dictado por
75
Ejercicio 2.5.
CINTA nmero formato alquilada por
copia de en
PELICULA cdigo ttulo categora protagonizada por
arrendatario de CLIENTE nmero de socio apellido nombres telfono domicilio
protagonista en ACTOR cdigo nombre artstico nombre real fecha de nacimiento
CINTA CINTA PELICULA en
PELICULA copia de
CLIENTE alquilada por
ACTOR
protagonizada por
CLIENTE arrendatario de ACTOR protagonista en
76
MIEMBRO *apellido *nombres o ttulo o cuotas adeudadas *domilicio o telfono *tipo de socio
interesado en de interes para
AEREA DE APLICACION *nombre
usuario de usada por
PLATAFORMA DE COMPUTACION *cdigo *descripcin
empleado de empleadora de participante en organizado por para COMENTARIO *nmero *texto detallado por
COMPAIA *nombre *domiclio *tipo de negocio
EVENTO *nombre *fecha o descripcin o lugar o costo
77
Ejercicio 2.7.
para
para
tomado por CURSO #*cdigo *nombre o precio o duracin
dictado por docente en INSTRUCTOR #*cdigo *apellido *nombre o telfono
78
REPARTO DE ACTORES
para
para protagonizada por protagonista en ACTOR #*cdigo *nombre artstico o nombre real o fecha nacimiento
CINTA #*nmero *formato
copia de en
PELICULA #*cdigo *ttulo o categora
alquilada por arrendatario de CLIENTE #*nmero de socio *apellido *nombres o telfono o domicilio
79
Ejercicio 2.9.
MIEMBRO #*documento *apellido *nombres o ttulo o cuotas adeudadas *domilicio o telfono *tipo de socio
interesado en de interes para
AEREA DE APLICACION #*cdigo *nombre
usuario de usada por
PLATAFORMA DE COMPUTACION #*cdigo *descripcin
empleado de empleadora de participante en organizado por para COMENTARIO #*nmero *texto detallado por
COMPAIA #*cdigo *nombre *domiclio *tipo de negocio
EVENTO #*cdigo *nombre #*fecha o descripcin o lugar o costo

Ana Der 2002

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Ana Der 2002

Enviado por

Direitos autorais:

Formatos disponíveis

UNIVERSIDAD TECNOLOGICA NACIONAL Facultad Regional La Plata Carrera de Ingeniera en Sistemas de Informacin Ctedra de Anlisis de Sistemas

MODELO DE INFORMACION Diagrama de Entidad-Relacin

Modelo de Informacin Diagrama de Entidad Relacin CONSIDERACIONES PREVIAS

Modelo de Informacin Diagrama de Entidad Relacin

Modelo de Informacin Diagrama de Entidad Relacin

REQUERIMIENTOS DE INFORMACION DE LA ORGANIZACION INVESTIGACION PRELIMINAR

*Definicin de Entidades y atributos *Modelo de EntidadRelacin (DER) *Diccionario de Datos

DISEO DE BASE DE DATOS

*Definicin de tablas, ndices, vistas y espacios fsicos

CONSTRUCCION DE BASE DE DATOS

BASE DE DATOS EN PRODUCCION

Modelo de Informacin Diagrama de Entidad Relacin

La MD es independiente del software o hardware posteriormente en la implementacin del sistema.

Modelo de Informacin Diagrama de Entidad Relacin

EMPLEADO legajo apellido nombres fecha de nacimiento sueldo

DEPARTAMENTO numero nombre localizacin

CLIENTE (USUARIO) apellido nombres cargo telfono domicilio lmite autorizado

PROYECTO cdigo nombre descripcin localizacin

Modelo de Informacin Diagrama de Entidad Relacin

entidades candidatas a los

Modelo de Informacin Diagrama de Entidad Relacin

CURSO cdigo nombre precio duracin

INSTRUCTOR (PROFESOR) apellido nombres telfono

ESTUDIANTE apellido nombres telfono

Modelo de Informacin Diagrama de Entidad Relacin

Modelo de Informacin Diagrama de Entidad Relacin

Opcional (puede ser) Mandatorio (debe ser)

Para representar la cardinalidad o grado se utiliza: uno o ms uno y slo uno

fig.[5] Leyndola primeramente de izquierda a derecha y luego de derecha a izquierda:

Modelo de Informacin Diagrama de Entidad Relacin

relacin de izquierda a derecha (diagrama parcial)

inscripto en tomado por

CHEQUE DE PAGO para fig.[9] receptor de

Modelo de Informacin Diagrama de Entidad Relacin

PEDIDO nmero tipo

salida para solicitado va

ITEM cdigo descripcin

origen de CLIENTE apellido nombres

repositorio para DEPOSITO cdigo domicilio

Modelo de Informacin Diagrama de Entidad Relacin

visitado por asignado a visitar

inscripto en tomado por

Modelo de Informacin Diagrama de Entidad Relacin

asignado a realizada por

integradora de incorporada dentro de

Cada COMPUTADORA PLAQUETA MADRE.

Modelo de Informacin Diagrama de Entidad Relacin Para su construccin convenciones:

CLIENTE CLIENTE ITEM PEDIDO DEPOSITO originado por

PEDIDO origen de solicitado va

salida para repositorio para

Modelo de Informacin Diagrama de Entidad Relacin

PEDIDO nmero tipo

salida para solicitado va

ITEM nmero descripcin

origen de CLIENTE apellido nombres

repositorio para DEPOSITO cdigo domicilio

Modelo de Informacin Diagrama de Entidad Relacin

Es conveniente utilizar una matriz de sistemticamente cada par de entidades.

ACTIVIDAD ACTIVIDAD DEPARTAMENTO EMPLEADO X

ACTIVIDAD ACTIVIDAD DEPARTAMENTO EMPLEADO asignado a

EMPLEADO realizada por responsable de

Modelo de Informacin Diagrama de Entidad Relacin

base para para operador de representante de responsabilidad de

Definicin de Entidades y atributos Modelo de EntidadRelacin (DER) *Diccionario de Datos

PERSONAL legajo apellido o cargo *sexo o puntaje

PERSONAL legajo apellido o cargo *sexo o puntaje

DEPARTAMENTO #nmero nombre

ENTRADA #fecha funcin #nmero butaca

ASIGNACION DE TRABAJO fecha de asignacin duracin o posicin asignada para de

asignado a EMPLEADO #legajo nombre

objeto de PROYECTO #nmero ttulo

ASIGNACION DE TRABAJO #fecha de asignacin duracin o posicin asignada para de

asignado a EMPLEADO #legajo nombre

objeto de PROYECTO #nmero ttulo

EMPLEADO mmero de legajo nmero liquidacin apellido nombre *fecha nacimiento

EMPLEADO #mmero de legajo (#)nmero liquidacin apellido nombre *fecha nacimiento

CLIENTE apellido nombre *domicilio

CLIENTE #cdigo apellido nombre domicilio

CLIENTE #cdigo fecha de contacto

CURSO #cdigo nombre duracin precio

BANCO #nmero nombre

PEDIDO #nmero fecha cdigo cliente nombre cliente *ciudad

PEDIDO #nmero fecha

CLIENTE #cdigo nombre *ciudad

PRODUCTO #cdigo nombre *descripcin