UCP - ISI

Base de Datos

MODELO
ENTIDAD-RELACION
Introducción
• Modelo de datos
– Colección de conceptos que sirven para describir la
estructura de una base de datos.
– Estructura de la base de datos: nos referimos a los tipos de
datos, los vínculos y las restricciones que deben
cumplirse para esos datos.
– Clasificación: dependiendo de los tipos de conceptos que
ofrecen para describir la estructura de la base de datos:
• Modelos de datos de alto nivel o conceptuales
• Modelos de bajo nivel o físicos
Introducción
Introducción
 El modelo de datos Entidad-Relación (ER):
– Permite describir los datos implicados en una empresa real
en términos de objetos y de sus relaciones.
– Se emplea mucho para desarrollar el diseño preliminar de la
base de datos.
– Aporta conceptos útiles que permiten pasar de una
descripción informal de los que los usuarios desean de su
base de datos a otra más detallada y precisa que se pueda
implementar en un SGBD
 Más allá del diseño ER
– Refinamiento de los esquemas.
– Diseño fıısico de bases de datos.
– Diseño de aplicaciones y de la seguridad.
Introducción
 Diseño Conceptual - Premisas
 ¿Qué significa entidad y vínculo en el contexto de una
Empresa/Organización?
 ¿Qué información sobre estos debería ser almacenada
en una base de datos?
 ¿Qué son las restricciones de integridad y las reglas de
negocios?
 Se puede “esquematizar” una base de datos en forma
de diagrama conceptual (DER).
 Luego se puede “mapear” este DER en un esquema
relacional.
El Modelo Entidad-Relación

 Entidad: Objetos del mundo real distinguibles

de otros objetos. Una entidad se describe (en
DB) usando un conjunto de atributos.
 Conjunto de Entidades: Una colección de
entidades similares. Ej. Todos los empleados.
 Todas la entidades en un conjunto tienen el mismo
conjunto de atributos (Hasta que consideremos las
clases jerárquicas)
 Cada conjunto de entidades posee una clave.
 Cada atributo tiene un dominio.
El Modelo Entidad-Relación

 Vínculos: Asociación entre dos o mas entidades. Ej.:

Personal que trabaja en el dpto de Farmacia.
 Conjunto de Vínculos: Colección de vínculos similares.
 Un conjunto de vínculos n-ario R relaciona n conjuntos de
entidades E1..En; y cada vínculo en R involucra las
entidades e1 E, …, en En.
 El mismo conjunto de entidades pueden participar en
diferentes conjuntos de vínculos, o en diferentes “roles”
dentro del mismo conjunto
Restricciones de Clave
 Considere el vínculo
“trabaja en”: Un
empleado puede trabajar
en mas de un
departamento; y un
departamento puede
tener más de un
empleado.
 En contraste, cada
departamento tiene como
máximo un director, de
acuerdo con la restricción
de clave en “Manages”
Restricciones Participativas
 ¿Todos los departamentos tiene un director?
 Si esto es así, existe una restricción de participación: la
participación de Departamentos en Administra es TOTAL en
contraposición a participación parcial.
 En otras palabras cada Did en Departamentos debe aparecer en
la tabla Administra (con un valor SSN NO NULO)
Entidades Débiles
 Una entidad débil puede ser identificada unívocamente
solo si consideramos la clave primaria de otra entidad
(Dueña/Padre/Maestro).
 La entidad DUEÑA y la entidad débil deben participar en una
relación uno a muchos (un maestro varios esclavos)
 La entidad débil debe tener participación total en esta relación
identificante.
Jerarquías de Clases “ES UN”
 Como en los lenguajes de programación
C++ , los atributos son heredados
 Si declaramos A “es un” B, cada entidad A
es también considerada integrante de una
entidad B.
 Restricciones solapadas: ¿Puede José ser
un empleado por horas así como un
empleado contratado al mismo tiempo?
(Permitido/Denegado)
 Restricciones complementarias: ¿Cada
entidad Empleados debe pertenecer a
Empleados por Hora o Empleados
Contratados en forma exclusiva? (SI/NO)
 Razones para usar jerarquía de clases:
 Para añadir atributos descriptivos
específicos a una subclase
 Para identificar entidades que participan en
un vínculo.
Agregaciones
 Se utilizan cuando
necesitamos modelar
vínculos que relacionan
un conjunto de otros
vínculos (y un conjunto
de entidades)

 Las agregaciones permiten tratar a un conjunto de vínculos (y

entidades) como una única entidad para poder representar, por ej.,
participaciones en (otras) relaciones.
 Agregación vs. Relación Ternaria: En el ejemplo del gráfico
“Monitors” es un vínculo distinto a “Sponsors”, cada uno con sus
propios atributos descriptivos (since, until).
 Además, podemos decir que cada “sponsoreo” puede ser
monitoreado por mas de un empeado.
Diseño Conceptual usando DER
 Decisiones de Diseño
 ¿Un concepto debería ser modelado como una entidad
o como un atributo?
 ¿Un concepto debería ser modelado como una entidad
o como un vínculo?
 Identificación de vínculos: ¿binarios/ternarios?
¿Agregación?
 Restricciones en el DER
 Debe capturarse todas las restricciones semánticas que
sean posibles en el diagrama
 Sin embargo algunas restricciones pueden no ser
capturadas
Entidad vs. Atributos
 Una dirección postal debería ser un atributo de
Empleados o una entidad separada conectada mediante
un vínculo a Empleados?
 La respuesta es: Depende del uso que se le quiera dar
al dato “dirección”, y la semántica de la misma:
 Si necesitamos registrar varias direcciones por empleado, la
dirección debería ser una entidad (ya que lo atributos no puede
ser multivaluados en un esquema relacional)
 Si la estructura (ciudad, calle, etc.) es importante, Ej.,
necesitamos filtrar los empleados de una ciudad determinada, la
dirección debería también ser modelada como una entidad (ya
que los atributos son “atomicos”).
Entidad vs. Atributos
 La relación de la derecha no
permite que un empleado
trabaje en un departamento
por mas de un periodo.
 Es similar al problema de
registrar mas de una dirección
por empleado: queremos
registrar varios valores para
un atributo descriptivo, como
lo es la duración desde-hasta,
para cada instancia de este
vínculo
Entidad vs Vínculo
 El primer diagrama es correcto si
el director tiene presupuestos
separados para cada
departamento.
 ¿Qué ocurre si un director solo
tiene un presupuesto “común”
para todos los departamentos
que dirije?
 La redundancia en el atributo
dbudget (presupuesto), la cual es
almacenada para cada
departamento que administra un
director.
 Problema: los presupuestos estan
“atados” a los departamentos
administrados por un director. No se
pueden representar con este
esquema presupuestos “sectoriales”
(con muchos directores)
Relaciones Binarias vs Ternarias
 Sicada políza es
contratada por un solo
empleado:
 Las restricciones de clave
en Polizas podrían significar
que cada poliza solo cubrirá
un beneficiario!
(Dependents)
 ¿Qué significan las
restricciones adicionales
en el segundo diagrama?
Relaciones Binarias vs Ternarias
 Los ejemplos previos ilustran el caso de cuando
un vínculo binario resulta mejor opción que un
ternario.
 Un ejemplo inverso sería: un vínculo ternario
“Contratos” relaciona el conjunto de entidades
(Partes, Departamentos, Proveedores), y tiene
un atributo descriptivo (cantidad), Ninguna
combinación de vínculos binarios es adecuado
para sustituirlo.
 S puede proveer P, D necesita P, y D negocia con S
 ¿Como registro “cantidad”? Inténtelo.
Resumen de Diseño Conceptual
 El diseño conceptual prosigue al analisis de
requerimientos.
 Contiene descripciones de alto nivel sobre datos a ser
almacenados.
 El modelo DER es el mas popular para “representar” los
diseños conceptuales.
 Las construcciones son expresivas, cercanas al lenguaje
coloquial acerca de cómo la gente piensa sobre sus
aplicaciones.
 Constructores básicos: entidades, vínculos, atributos
 Constructores adicionales: entidades débiles, agregaciones,
jerarquía de clase…
 Nota: Hay muchas versiones sobre Modelo Relacional.
Apegarse a la de la bibliografía propuesta.
Resumen de Diseño Conceptual
 Puede representar la mayoría de las clases de
restricciones de integridad: restricciones de clave, de
participación, restricciones solapadas/complementarias
en una relación de jerarquía. También puede representar
algunas restricciones de clave foranéa en forma
implícita.
 Sin embargo algunas restricciones no pueden ser
representadas (dependiencias funcionales por ej.)
 Las restricciones juegan un papel importante en
determinar el mejor modelo de diseño para una
Empresa.
Resumen de Diseño Conceptual
 El diseño ER es subjetivo. Siempre hay muchas formas
de representar lo mismo. Analizar las alternativas puede
ser tedioso y confuso, especialmente para desarrollos
complejos.
 Decisiones comunes a las que el diseñador debe
atender son:
 Entidad vs. Atributo, Entidad vs. Vínculos, vínculos binarios vs.
Ternarios, cuando y cuando no usar jerarquías de clase, cuando
usar agregaciones, etc.
 Asegurando un buen diseño conceptual de la base de
datos: El resultado de un análisis siempre debe ser
refinado varias veces antes de llegar a un resultado. Las
técnicas de normalización son especialmente útiles en
este proceso.