Saltar al contenido principal

Modelo Entidad-Relación

Modelo Entidad-Relación (ER)​

  • Entity Relationship Model (MER)

  • Permite modelar los requerimientos de una manera conceptual

    • De una forma menos técnica que usar tablas

  • Es común generar el esquema de la base de datos a partir de un modelo ER

    • Podemos evitar problemas de diseño y obtener modelos más concisos

  • Muy útil como complemento del modelo relacional paara documentar, visualizar y comunicar la estructura de datos

Componentes​

Un modelo ER consiste en un diagrama con 3 grandes componentes:

Entidades

Atributos de entidades

Relaciones entre entidades

Entidades y atributos​

  • Cada entidad debe tener una llave, la cual aparece subrayada en el diagrama
    • Comúnmente es un sólo atributo, pero pueden ser más de uno
    • Misma idea que en el modelo relacional: la llave determina la entidad

Relaciones entre entidades​

tip
  • También permitimos atributos en las relaciones como se ve en modelo entidad-relación
  • Las relaciones no tienen llaves

Multiplicidad de relaciones​

0 o muchos Productos pueden fabricar 0 o muchas Compañias

0 o muchos Productos pueden fabricar 0 o 1 Compañia

0 o 1 Producto puede fabricar 0 o muchas Compañias

0 o 1 Producto puede fabricar 1 o más Compañias

0 o muchos Productos puede fabricar solo 1 Compañia

Ejemplo modelo ER​

¿Multiplicidad de atributos?

Siempre a 1

  • 1 a 1 (e.g., rut)
  • n a 1 (e.g., categoría)

Atributos multivaluados​

  • Atributos que toman más de un valor para una entidad particular

  • Se utiliza el doble óvalo (En este caso se representa con un doble círculo)

Una persona podría tener varias profesiones

Relaciones múltiples​

Es posible relaciones entre 3 o más entidaades (aunque esto es menos común)

¿Multicidades?

Si bien en este caso se utiliza multiplicidades no es tan común

  • Tipicamente no hay restricciones

¿Qué significa esto?

  • Cada persona que alquila en un local de video puede alquilar a lo más una pelicula

¿Qué significa esto?

  • Cada persona que alquila en un solo local de video puede alquilar una pelicula
  • O no alquilar nada
Relación múltiples a binárias

Siempre se puede transformar relaciones múltiples a binárias

Más flexible (para agregar más restricciones)

Roles​

info
  • A veces una misma entidad participa más de una vez con una misma relación
  • Es útil por ejemplo en este caso para asignar roles a las distintas apariciones

Ejemplo 1

Ejemplo 2

Entidades débiles​

  • Una entidad débil es la depende de una entidad padre.
tip
  • La relación entre la entidad débil y su entidad padre siempre es a 1.
  • Una entidad débil tiene una llave parcial (Se anota con un subrayado punteado)
  • Una entidad débil queda determinada por su llave parcial y su llave entidad padre

Jerarquía entre entidades​

  • Podemos tener jerarquía entre entidades IsA (IsA = "Es una/un")
  • Los atributos se heredan

Del modelo ER al modelo relacional​

  1. Las entidades (no débiles) se pasan directamente a tablas:

Conservando sus atributos y llaves

Entidades (no débiles)
  • Producto(nombre, categoria, precio)
  • Compañia(nombre, valor_accion)
  1. Las relaciones se pasan a tablas:
  • Conservamos sus atributos
  • La llave es la únion de las llaves de las entidades relacionadas (estas últimas por separado pasan a ser foreign_keys)
Relaciones
  • Fabrica(nombre_producto, nombre_compañia, desde)

Simplificaciones según restricciones​

En el modelo ER anterior la relación Producto fabrica Compañia era 0 o muchos Productos pueden ser fabricados por 0 o muchas Compañias
  • Por lo cual era correcto:
    • Producto(nombre, categoria, precio)
    • Compañia(nombre, valor_accion)
    • Fabrica(nombre_producto, nombre_compañia, desde)

Actualmente se cambió una restricción del modelo ER (0,1)

El Producto determina la compañia
  • Producto(nombre, categoria, precio)
  • Compañia(nombre, valor_accion)
  • Fabrica(nombre_producto, nombre_compañia, desde)

Ahora si es que compañia es (1,1)

Simplificación
  • La tabla de la relación se podría simplificar en estos dos casos:
    • Si tenemos alguna multiplicidad 0 o 1 podemos simplificar la llave.
    • Si tenemos alguna multiplicidad 1 podemos eliminar la tabla!
En este ejemplo quedaría
  • Producto(nombre, precio, categoria, nombre_compania, valor_accion, desde)
  • Compañia(nombre, valor_accion)

Atributos multivaluados de modelo ER a modelo relacional​

1era opción
  • Persona(rut, nombre, direccion, profesion1, profesion2, profesion3)
    • Esto podría generar muchos valores indefinidos(nulos)
2da opción
  • Persona(rut, nombre, direccion)
  • Profesiones(rut_persona, profesion)

¿Caso de roles?​

¿Cómo sería?
  • Usuario(rut, nombre)
  • Sigue(rut_seguidor, rut_seguido, desde)

¿Caso de entidades débiles?​

Tener en consideración
  • Se elimina la relación hacia la entidad padre (ya que siempre es a 1)
  • La llave de la tabla asociada a la entidad débil es su llave parcial junto a la llave del padre.
¿Cómo se hace?
  • Curso(codigo, nombre)
  • Evaluacion(nombre, codigo_curso, fecha)

¿Caso de jerarquías?​

1era opción
  • Deportista(rut, nombre, edad)
  • Futbolista(rut, equipo, posicion)
  • Tenista(rut, grand_slam, raqueta)
2da opción
  • Futbolista(rut, nombre, edad, equipo, posicion)
  • Tenista(rut, nombre, edad, grand_slam, raqueta)

¿Cuándo conviene 1era opción?​

  • Si hay deportistas que no son ni futbolistas ni tenistas
  • Si vamos a hacer muchas consultas sobre deportistas en general
  • Si hay mucho solapamiento entre las subclases (en este caso no hay solapamiento)

¿Cuándo conviene 2da opción?​

  • Poco o no hay solapamiento
En general

Aplicar la solución "razonable" dependiendo del caso particular

CONSEJO

Revisa el glosario de esta clase Glosario Modelo Entidad-Relación