Clase 2 Modelizacion de Datos

Vista previa del material en texto

Clase 2: Modelización de 
Datos – 2.019
BASE DE DATOS
FAC.DE INGENIERIA - UNJu
2.1 Modelo Entidad-Relación Extendido (MERE) (Chen, 1.976) 
Herramienta utilizada p/la construcción del modelo conceptual o MERE, los 
diseñadores de BD se encontraron con aplicaciones de complejidad 
creciente lo cual aumentaba las necesidades adicionales a conceptos del 
modelo semántico, fue modificado y enriquecido semánticamente por 
muchos otros (conceptos como subclases y superclases).
Entidades Relaciones
Representan 
los objetos a 
modelar
Atributos
Representan las 
propiedades 
de las 
entidades
Representan las 
asociaciones entre 
entidades
2.1.1. Entidades
Diccionario: "ser, existencia, una opuesta o no-existencia; la existencia como 
distinción entre cualidades o relaciones de cosas". 
P/aplicaciones de BD: alguna cosa acerca de la cual la información es 
almacenada, la cual tiene 1 existencia independiente y puede ser 
identificada, 1 entidad puede ser un objeto tal como 1casa, 1estudiante; o 1
evento o 1activ.tal como 1partido d fútbol, 1día festivo o 1carrera d autos. 
2.1.1. Atributos
Una entidad es totalmente descripta a través de sus atributos. X ej. 1 casa 
puede ser descripta x los atributos dirección, estilo y color; 1 auto puede 
ser descripto x los atributos número de patente, fabrica, modelo y año
2.1.3. Tipo de Entidad
El nombre de 1entidad junto con sus atributos define 1tipo de entidad de 
la cual puede haber muchas instancias. La distinción entre tipos de entidad 
e instancias es análogo a tipos de datos y sus instancias en un lenguaje de 
programación. X ej. los valores de atributos (San Juan 150, Victoriana, 
blanco) definen una instancia de la entidad CASA. 
2.1.4. Clave de Tipo de Entidad
“1atributo o conj.de atributos cuyos valores identifican en forma única 
c/instancia de 1tipo entidad se llama clave candidata del tipo 
entidad”. X ej., el atributo DIRECCION es 1 clave p/la entidad tipo 
CASA. 1entidad tipo puede tener 1 o + claves candidatas. 
X ej., 1estudiante puede ser identificado por 1único nro.de identific. 
(nro.de estudiante), o x la combinación de los valores del nombre y 
dirección. Se elige 1clave primaria de las claves candidatas.
2.1.5. Relaciones
Una relación es una asociación entre dos o más tipos de entidades. 
X ej. la relación: JUEGO-DE entre las entidades tipo JUGADOR y PARTIDO. 
La funcionalidad de las relaciones puede ser: 
- uno-a-uno (1: 1) 
- uno-a-muchos (1:n) 
- muchos a muchos (m:n) 
Como ej.se considera 1BD q tiene las siguientes relaciones: 
1: 1 La relación JEFE-DE entre el tipo de entidad GERENTE y 
DEPARTAMENTO es 1: 1 Esto significa que un departamento tiene un 
gerente, y un gerente, es jefe de 1 dpto. 
2.1.5. Relaciones
l:n La relación SUPERVISA entre GERENTE y EMPLEADO es l:n. 
Esto ocurre cuando un gerente supervisa a un nro diferente de empleados y 
q c/empleado es supervisado por un gerente.
n:m La relación ASIGNADA-A entre las entidades EMPLEADO y 
PROYECTO es n:m Un empleado puede estar asignado a varios proyectos y 
c/proyecto puede tener asignado varios empleados.
2.1.5. Relaciones
Ejemplos de relaciones básicas entre entidades. 
2.1.6. Relaciones complejas
Las situaciones del mundo real frecuentemente tiene 
relaciones + complejas q relaciones binarias 1:1, l:n o m:n. X ej. 
relac.entre entidades del mismo tipo o relaciones entre + tipos de entidades
2.1.6.1. Relaciones recursivas
Las relaciones recursivas son relaciones entre diferentes instancias 
del mismo tipo de entidad. Ej.: relación recursiva de 1: 1. 1instancia 
del tipo de entidad PERSONA puede estar relacionado con otro miembro a 
través de la relación CASADA-CON
2.1.6.1 Relaciones recursivas
Relación recursiva de l:n. 1instancia del tipo de entidad EMPLEADO 
puede supervisar a otras instancias. Si se asume q 1empleado puede tener un 
supervisor entonces la relación SUPERVISA es 1relación recursiva de l:n
Relación recursiva de m:n. 1instancia del tipo de entidad PARTE puede 
estar compuesta de otras partes, mientras q 1 parte puede ser 1componente 
de muchas otras partes. Esta situación podría representarse x la relación 
recursiva de m:n COMPRENDE
2.1.6.2 Relaciones ternarias
Involucran 3 tipos de entidades. Ej. 1 BD q contiene información 
sobre compañías, los productos q fabrican y los países a los cuales exportan 
estos productos. 
Los países p/los cuales un producto es exportado varían de producto en 
producto y de compañía en compañía. La relación VENDE es ternaria, 
es decir involucra 3 tipos de entidades. La funcionalidad de esta 
relación es m:n:q. 
2.1.6.2 Relaciones ternarias
Situaciones entre relaciones: 
P/1par dado(compañía, producto) hay muchos países p/los cuales el producto es vendido. 
P/1par dado(país, producto) hay muchas compañías q exportan este producto a este país. 
P/1par dado(compañía, país) hay muchos productos exportados x esa compañía a ese país.
La funcionalidad d 1relación ternaria también podría ser l:m:n, 1:1:n ó 1:1:1. 
Las relaciones ternarias deben ser definidas cuidadosamente y solo deben 
usarse cuando las relaciones no puedan representarse en forma precisa a 
través de relaciones binarías. X ej., si 1compañía fabrica muchos productos y exporta 
todos estos productos a diferentes países, entonces las 2relaciones binarias independientes 
EXPORTA y FABRICA
2.1.6.3 Subtipos y Supertipos
Un tipo de entidad El es un subtipo de un tipo de entidad E2 si toda 
instancia de El es también una instancia de E2.
Un tipo de entidad E es 1generalización de los tipos de entidad El, E2, ...,En si 
c/ocurrencia de E es también1ocurrencia y solo 1d las entidades El, E2, ...En. 
2.1.6.3 Subtipos y Supertipos
Como ej.de subtipos se considera 1BD de 1pequeña compañía la cual s 
representa en c/dpto.con 1gerente, el cual es 1categoría especial de empleado. 
También, hay otras categorías del tipo d entidad EMPLEADO tales como Secret., 
Técn.e Ing. C/u d estos tipos de entidades comparten algunas prop.en virtud d q 
estas pueden ser consideradas como diferentes categorías del tipo de entidad 
EMPLEADO. Estos tipos de entidades son subtipos del tipo de entidad EMPLEADO, la 
cual se dice q es 1Supertipo. 1 instancia de 1subtipo no 
puede existir en la BD sin q 
también sea miembro del 
supertipo. Esto es, 1instancia 
de1 subtipo 
representa1entidad del mundo 
real como alguna instancia del 
supertipo. 
Los subtipos pueden también 
tener subtipos, formando 
así1jerarquía. 
2.1.6.3 Subtipos y Supertipos
1subtipo puede tener atributos adicionales y relaciones p/el subtipo. 
X ej., en 1BD de 1compañía se podría forzar a q las instancias del tipo d 
entidad GERENTE, subtipo de EMPLEADO, pueda participar en la relación 
JEFE-DE. A continuac.se muestra la relac.q podría asistir entre el tipo d 
entidad GERENTE y DEPARTAMENTO. Un gerente comparte todos los atrib. de 
empleado pero puede tener atributos q son relevantes solo p/los gerentes. 
Es ventajoso reconocer los subtipos cuando ellos se originan ya q su 
inclusión agrega claridad y precisión para el esquema y puede mejorar la 
eficiencia en cualquier implementación subsecuente. 
2.1.6.4. Generalización y especialización
El tipo de entidad EMPLEADO puede ser considerado como 1
Generalización de los tipos de entidad SECRET., ING. y TECN.si toda instancia 
EMPLEADO en la BD, es también 1instancia de 1de estos subtipos. En este 
caso las entidades tipo SECRET., ING.y TECN.forman 1Especialización del tipo 
de entidad EMPLEADO donde cada especialización se distingue x el valor de 
sus atributos. En este caso el atributo de distinción podría ser CARGO.
2.1.7. Construcción del MERE
P/construir el MERE s usa la Narrat.del problema. De esta s determina: 
a) Especificación de Entidades (se seleccionan aquellas esenciales)
P/la determinación de las entidades se usan las siguientes técnicas: 
1- Listado de eventos
2- Diagrama de Ciclo de vida
3- Diagrama de Contexto4- DER (Individual o Elemental y Global) 
b) Especificación de Estructuras (estructuras y relaciones especiales).
Para la determinación de la estructura se utiliza:
5 - Diagrama de Martin
c) Especificación de Atributos (memoria esencial de c/entidad).
P/la determinación de los atributos el 6-Diccionario de Datos
2.1.7. Construcción de MERE – Ej. aplicado a 1Sist. de Compras
2.1.7.1 Especificación de Entidades 
1 – Listado de Eventos 
1. Un cliente solicita ingreso al sistema de compras.
2. Un cliente realiza una compra de productos.
3. Un cliente paga una factura por una compra.
4. Un cliente solicita el egreso del sistema.
5. Es hora de reclamar el pago de una factura.
6. Es hora de dar de baja a un cliente moroso.
7. Es hora de dar de baja a un cliente inmóvil
8. Depósito informa del envío del pedido a un cliente.
9. Es hora de encargar mercaderías a los proveedores.
10.Depósito informa arribo de mercaderías.
11.Un proveedor envía una factura por mercadería.
2.1.7. Construcción del MERE – Ej. aplicado a un Sist. de Compras
2.1.7.1 Especificación de Entidades 
1 – Listado de Eventos 
Las entidades esenciales son aquellos q no, dependen de la 
tecnología usada p/implementar el sist. Estas siempre forman parte del sist. 
De la narrativa se extrae un listado de eventos. 
En el listado de eventos se enuncian los sucesos (eventos) q tienen 
lugar en el entorno del sist.y a los q el sist.debe dar 1respuesta preplaneada.
Los eventos se anuncian de forma normalizada (sujeto, verbo, objeto) 
como 1sujeto q realiza 1acción sobre 1objeto (eventos de datos a materiales 
tales como “1cliente paga factura x productos pedidos”), o como 1situación 
provocada x el medio mismo sin intervención de entidades externa alguna 
(eventos temporales como “Es hora d reclamar pago de factura”).
Los sustantivos d la lista de eventos son los candid.a ser entid. esenciales.
2.1.7. Construcción de MERE – Ej. aplicado a un Sist. de Compras
2.1.7.2 Diagrama de Ciclo de Vida o Diagr.de Jackson 
P/c/1de las entidades candidatas se construye el diagrama de 
ciclo de vida utilizado la simbología del Diagrama de Jackson.
El diagr.de ciclo d vida describe el pasaje de estados del candidato, muestra 
el nacimiento (alta), la vida (transacc) y la muerte (baja) del mismo. 
2.1.7. Construcción de MERE – Ej. aplicado a un Sist. de Compras
2.1.7.2 Diagrama de Ciclo de Vida o Diagrama de Jackson 
Se lee de arriba a abajo y de derecha a izquierda. El 1er.nivel tiene 
1secuencia de 3 bloques. 1es elemental y representa el estado del cliente. 
Los otros 2 son bloques compuestos y s los describe x medio de otros bloques. 
La Baja se describe x1selección (círculos borde superior derecho). 
C/u de los rectángulos describen 1estado final al q s llega según la baja 
sea A PEDIDO del cliente, se da de baja POR MORA en pagar su deuda o por 
VEJEZ de su registro al pasar demasiado tiempo sin registrar actividad. 
La VIDA es 1interacción de transacciones (* en el ángulo superior derecho 
de TRANSACCION), c/1de los cuales es 1selección de COMPRA o PAGO. 
Se analizan los ciclos de vida buscando:
 Otros candidatos q no hayan aparecido previamente entre los eventos y
 Ciertos estados q no están asociados a eventos. 
Si aparecen otros candidatos se construirá el ciclo de vida. 
C/estado del diagrama de ciclo de vida tiene asociado un estado.
2.1.7. Construcción de MERE – Ej. aplicado a un Sist. de Compras
2.1.7.2 Diagrama de Ciclo de Vida o Diagrama de Jackson 
Todo ciclo tiene 3 bloques secuenc.(ALTA, VIDA, BAJA). Algunos sist. tienen entidades 
permanentes. La Completitud determina si están o no, pero no se crea o destruye. 
1sist.de ventas puede no dar de alta, ni de baja, a vendedores, función q cumple el 
Sist.de personal. P/el sist. de ventas los vendedores son entidades definidas. 
En gral.los estados a los q pueden arribar los objetos son varios, y la búsqueda de 1
representación ayuda a encontrar estados q no surgen de la lectura d la narrativa ni 
están asociado a eventos, x lo q los eventos q corresponden a ellos se suman a la lista. 
Si del listado de eventos el sist. 
no registra tal estado (poco 
frecuente), es posible q la 
condición de transición se 
produzca x cambios de estados 
asociados a otros candidatos y 
corresponde asociar este evento 
al estado en cuestión. 
2.1.7. Construcción de MERE – Ej. aplicado a un Sist. de Compras
2.1.7.3 Diagrama de Contexto 
Ciertos documentos q se generan ante estímulos externos aparecen aquí como 
ENVIO, RECIBO y REMITO, se comienza a construir el diccionario de datos donde s 
describe c/u de los flujos, explicando su estructura mediante 1 sintaxis particular. 
El diagr.de contexto constata la completitud del modelo. Se agregan 
respuestas y estímulos q se encuentren y se añaden a la lista de eventos los q 
correspondan. Se revisan q los nuevos eventos queden reflejados x algún cambio de 
estado entre candidatos y se completan los diagr. de ciclo de vida q hicieran falta. 
Los flujos de eventos temporales se 
representan con líneas cortadas 
anotadas con el evento, y los flujos de 
datos o materiales son flechas llenas 
anotadas desde la entidad hacia la 
burbuja del sist. El diagr.de contexto 
muestra además, las respuestas que el 
sist. envía a las entidades externas al 
ser estimuladas por los flujos. En estas 
respuestas se busca nuevamente más 
candidatos a tablas. 
2.1.7. Construcción de MERE – Ej. aplicado a un Sist. de Compras
2.1.7.4 DER Individual y Global
“Los eventos se traducen en1leng.gráfico, donde c/u se lee como 1DER elemental, 
donde 1sustantivo s representa como 1entidad con su nombre dentro del rectángulo, 
y 1relac. es 1rombo q contiene a 1conjunc.o 1propos.y q siempre vincula 2+ entid.” 
“Se analizan los DER´s p/eliminar entidades poco significativas, detectar tipos de 
entidades q reúnen características de relaciones y de entidades a la vez (los q se 
denomina tipos de entidades asociativas o TEA) y se representan como rectángulo 
con nombre de la entidad q apunten a rombo sin nombre x medio de 1 flecha.”
Del list.de eventos verificada y 
consistida se construye el DER individ.
En 1er.lugar, se revisa la redacción 
individual de c/evento, asegurándose 
q tiene toda la información q le 
corresponda (x ej.se corrige la 
redacción de un cliente paga 1
factura pero q refleje la relación entre 
factura y productos: “Un cliente paga 
1 factura por productos pedidos”). 
REMESA
2.1.7. Construcción de MERE – Ej. aplicado a un Sist. de Compras
2.1.7.4 DER Individual y Global
Los DER's elementales s conectan a través de superposiciones de entidades o TEA's
comunes a 1DER, el cual se analiza p/eliminar redundancia. El resultado es 1conj.de 
entidades y TEAs enlazados en 1gráfico. Se buscan objetos q x ser demasiado grales
soportan relac.con otras de forma parcial, o tienen atrib.diferentes según sus subtipos, 
p/definir 1jerarquía con ellos como cabeza y los subtipos de c/u como componentes. 
X ej., las entid.d la clase REMESA pertenecen a 2subt.bien diferentes. O bien se envía 
desde depósito 1PEDIDO al CLIENTE o bien el PROVEEDOR envía al depósito1ORDEN 
de mercaderías. ENVIO y ENTREGA son subtipos de REMESA y heredan atributos. 
Al eliminarse entidades, es posible q las 
TEA's no vinculen gráficamente a+de
1rectángulo, sino q haya solo 1asociado 
al rombo apuntado x la TEA, pero ese es 
el nro.mínimo y se entiende q hay otra 
entidad (x lo menos) asociada x la TEA.
En el ej.p/eliminar redundancia se han 
suprimido relac.entre PAGO y CLIENTE y 
entre FACTURA y CLIENTE, con lo q la TEA 
representado x PAGO solo apunta a 
FACTURA y este a su vez a PEDIDO. 
2.1.7. Construcción de MERE – Ej. aplicado a un Sist. de Compras
2.1.7.5 Especificación de estructura
Las entidades no son entes aislados q forman parte de 1conj.desordenado. 
Son instancias activas q s comunican entre sí p/llevar a cabo tareas. En la 
especificación de estructura se agrega a las jerarquías definidas en el DER(relación 
'es un') las relaciones "compuesto por" entre las componentes del modelo. 
“P/las jerarquías d entidades resultantes, en la especificac.d la estructura se indican 
el grado de necesidad (opcionalidad) y multiplicidad de esas y otras relaci.entre
individuos de cada tipo”. El modelo DER se transforma en diagrama de Martin.
C/entidad es representada x un 
rectángulo (también son rectángulos las 
TEAs y las relaciones puras). Solo las 
relaciones binaria dejan de existir y 
aparecen como líneas q unen 
rectángulos. Todas las otras líneas en el 
DER aparecen uniendo los respectivos 
rectángulos. Se muestra cómo se 
representa la relación compuesta x q 
vincula clases entre sí. El triángulo q 
apunta de LINEA a PEDIDO señala la 
2.1.7. Construcción de MERE – Ej. aplicado a un Sist. de Compras
2.1.7.5 Especificación de estructura
El diagr.de Martin se completa con2símbolos “multiplic. y opcional.” d las relac. 
entre entidades. La existencia d1línea entre2rectáng, no denotada con el semicírculo d 
compos.jerárquica, indica la presencia d1relac.entre instancias relacionadas en el dibujo. 
Esta relación se caracteriza x: La multiplicidad q indica con cuantos individuos de la otra 
clase –COMO MÁXIMO- puede llegar a relacionarse a través de esta relación un individuo 
de 1clase. Una barra, simbolizando un UNO indica q q a lo sumo 1individuo puede 
relacionarse con este. En el ej. p/un EMPLEADO hay a lo sumo 1CARGO. Esto se simboliza 
con la barra +cercana a la entidad del lado del 'a la sumo'. Cuando la relación no está 
acotada x1solo individuo el símbolo q se usa es el 'mayor que' (>) o 'menor que' (<), 
dependiendo del lado q se coloq, indicando q 1 de las entidades puede llegar a 
relacionarse con muchos del otro tipo
Opcionalidad: Indica la necesidad de la existencia o no de la relación. Para el ej.todo
empleado debe tener un cargo. Pero para un cargo no siempre hay un empleado.
2.1.7. Construcción de MERE – Ej. aplicado a un Sist. de Compras
Donde haya relaciones muchos a muchos, se 
analiza si existen atributos propios de la 
relación, como es el caso entre PEDIDO y 
PRODUCTO, en la que cada elemento de la 
reacción tiene como atributo la CANTIDAD 
pedida del PRODUCTO. 
Como resultado de análisis se agrega al 
modelo la entidad LINEA, PROVEEDOR tiene 
sus propios precios para su línea de 
PRODUCTO, aparece la entidad LISTA que 
mantiene la relación entre ambos. 
2.1.7.5 Especificación de estructura
P/el ej. del Sist.de Compras se debe analizar la relación entre FACT.y PAGO (puede 
haber 1FACT.q también esté impaga, pero la política de la empresa prescribe q 1FACT. 
no tenga más de 1PAGO) y de relaciones obligatorias con más de 1instancia posible. 
También s debe analizar la relación entre ENTREGA y ORDEN (p/q se realice 1entrega 
es necesario q haya 1ORDEN, pero en esa ENTREGA puede q se envíen más de 1). 
2.1.7. Construcción de MERE – Ej. aplicado a un Sist. de Compras
2.1.7.6 Especificación de atributos
La descomposición de los flujos de entrada y salida se documenta en 1diccionario d 
datos p/ ¿asegurar la completitud del relevamiento. A las narrativas recogidas en 
entrevistas semiformales s las suele completar con1relevamiento d datos utilizado en el 
sist. Tales datos son recogidos d los formul.en uso, e incorporados estructuralmente (es 
decir, respetando y anotando sus características estructurales) en 1diccion.de datos.
La sintaxis se resume en el siguiente cuadro: 
= está compuesto por 
*<frase>* comentario 
@ clave 
+ además está compuesto 
[......] opciones 
{} repetición 
Cuando 1campo es elemental, es decir q no se lo puede describir en términos de 
otros campos, se puede especificar el dominio d su contenido de 2maneras. Cuando 
se trate de un conj.grande como p/q s pueda enumerar, s recurre al campo de 
comentario (por ejemplo Nº FACTURA = * “1000..9999”*). 
2.1.7. Construcción de MERE – Ej. aplicado a un Sist. de Compras
2.1.7.6 Especificación de atributos
En el caso que la enumeración sea posible esta se realiza encerrando por el corchete 
que abre con asterisco ([*) y el corchete que cierra con asterisco (*]), separando los 
distintos valores con barras (ej. ESTADO CIVIL =[* SOLTERO ¦ CASADO ¦ SEPARADO ¦ 
DIVORCIADO ¦ VIUDO *]). 
1vez construido el diccion.de datos, los componentes son asignados al modelo . 
FACTURA = * Docum. emitido al informarse envío de los productos al cliente * 
ENCABEZAMIENTO 
+ LINEAS 
LINEAS = *Componentes de la FACTURA * 
{LINEA} 
LINEA = *Venta individual registrada * 
CODIGO DE ART. 
+ARTICULO 
+CANTIDAD 
+PRECIO UNITARIO 
+IMPORTE 
CODIGO DE ARTICULO = * tres caracteres alfabéticos seguido de cuatro dígitos*
• Alarcón Vincenc. “Desarrollo de sistemas de información: una 
metodología basada en el modelado”. 2da Edición. 2.006.
• Barranco de Areba Jesús. “Metodología del análisis estructurado de 
sistemas”. 2.001.
• CJ-Date. “Introducción a los sistemas de bases de datos”. 7ma Ed. 
2.001.
• RamezElmasri y ShamkantNavathe. “Sistemas de Bases de Datos 
(Conceptos Fundamentales)”. 2da Edición. 2.007.
• RamezElmasri y ShamkantNavathe. “Fundamentos de Sistemas de 
Bases de Datos - 5ta Ed.”
• Silverschatz&Korth&Sudarshan. “Fundamentos de Base de Datos”. 4ta 
Ed. 2.007.
Bibliografía