Este documento explica el modelo de entidad-relación (ER) para el diseño de bases de datos. El modelo ER representa el mundo real mediante entidades, atributos y relaciones. Incluye definiciones de entidades, atributos, relaciones, claves y tipos de entidades. También recomienda el uso de diagramas ER extendidos que incluyen conceptos adicionales como entidades débiles y atributos en relaciones.
2. Definición
El Modelo de Entidad Relación es un modelo
de datos basado en una percepción del mundo
real que consiste en un conjunto de objetos
básicos llamados entidades y relaciones entre
estos objetos, implementándose en forma
gráfica a través del Diagrama Entidad
Relación.
1. Contenido
3. Las entidades están compuestas de atributos que son los datos
que definen el objeto (para la entidad persona serían DNI, nombre,
apellidos, dirección,...).
Claves:
Es el atributo de una entidad, al que le aplicamos una restricción
que lo distingue de los demás registros (no permitiendo que el
atributo específico se repita en la entidad)
Superclave:
Aplica una clave o restricción a varios atributos de la entidad, para
así asegurarse que en su conjunto no se repitan varias veces y
así no poder entrar en dudas al querer identificar un registro.
Tipos de Entidad
4. Clave primaria: identifica inequívocamente un solo atributo no
permitiendo que se repita en la misma entidad. Como sería la
matrícula o el número de chasis de un coche (no puede existir
dos veces el mismo).
Clave externa o clave foránea: este campo tiene que estar
estrictamente relacionado con la clave primaria de otra entidad,
para así exigir que exista previamente ese clave. ..
Anteriormente hemos hablado de ello cuando comentábamos
que un empleado indispensablemente tiene que tener un cargo
(que lo hemos representado numéricamente), por lo cual si
intentásemos darle un cargo inexistente el gestor de bases de
datos nos devolvería un error.
5. Tipos de Entidad
> Relación Uno a Uno: Cuando
un registro de una tabla sólo
puede estar relacionado con
un único registro de la otra
tabla y viceversa. En este caso
la clave foránea se ubica en
alguna de las 2 tablas.
Relación Uno a Muchos:
Cuando un registro de una
tabla (tabla secundaria) sólo
puede estar relacionado con
un único registro de la otra
tabla (tabla principal) y un
registro de la tabla principal
puede tener más de un
registro relacionado en la tabla
secundaria.
Relación Muchos a Muchos: Cuando un registro de una
tabla puede estar relacionado con más de un registro de la
otra tabla y viceversa. En este caso las dos tablas no
pueden estar relacionadas directamente, se tiene que
añadir una tabla entre las dos (Tabla débil o de
vinculación) que incluya los pares de valores relacionados
entre sí.
6. Atributos
Los atributos son las características que definen o identifican a una
entidad. Estas pueden ser muchas, y el diseñador solo utiliza o
implementa las que considere más relevantes.
Tipos de Entidad Fuerte y Débil
Cuando una entidad participa en una relación puede adquirir un papel
fuerte o débil. Una entidad débil es aquella que no puede existir sin
participar en la relación; es decir, aquella que no puede ser unívocamente
identificada solamente por sus atributos.
Hay 2 tipos de dependencias en las entidades débiles:
Dependencia por existencia
Las ocurrencias de la entidad débil pueden identificarse mediante un
atributo identificador clave sin necesidad de identificar la entidad fuerte
relacionada.
Dependencia por identidad
La entidad débil no puede ser identificada sin la entidad fuerte
relacionada.
7. Atributos en las Relaciones
Las relaciones también pueden tener
atributos asociados. Se representan igual
que los atributos de las entidades.
- Atributos simples o atómicos: son atributos no
divisibles.
- Atributos compuestos: son atributos que se
pueden dividir en sus componentes, pudiendo
formar jerarquías.
- Atributos monovaluados: son atributos que
tienen un solo valor para una entidad en
particular.
Atributos multivaluados: son atributos que
tienen límites inferior y superior en el
número de valores para una entidad.
Atributos complejos: son atributos
compuestos o multivaluados anidados de
una manera arbitraria (lista, conjuntos).
8. • Restricciones Estructurales
• Son reglas que deben mantener los datos
almacenados en la base de datos. No se deben de
quebrantar a menos que tenga otra relación de una
tabla de uno a muchos.
• Es una notación alternativa a las restricciones de llave
(cardinalidad) que incluye un par de números enteros
(mín, máx) a cada participación.
• Problemas con Modelos ER
• Los problemas que podemos tener en el modelo ER
son:
• Valores nulos y gasto de espacio de almacenamiento
• Redundancia
• Inconsistencia
9. El modelo ER es solo y
exclusivamente un método del
que disponemos para diseñar
estos esquemas que
posteriormente debemos de
implementar en un gestor de
BBDD (bases de datos).
2. Resumen
Este modelo habitualmente, además de disponer
de un diagrama que ayuda a entender los datos y
como se relacionan entre ellos, debe de ser
completado con un pequeño resumen con la lista
de los atributos y las relaciones de cada elemento.
10. 3. Recomendaciones
Los diagramas Entidad-
Relación no cumplen su
propósito con eficacia debido a
que tienen limitaciones
semánticas.
Por esto se suelen utilizar los
diagramas Entidad-Relación
extendidos (MERE) que
incorporan algunos elementos
más al lenguaje:
Entidades fuertes y débiles:
Cuando una entidad participa en
una relación puede ser fuerte
(puede ser identificada
unívocamente), o débil(que no
puede ser unívocamente
identificada por sus atributos).
Atributos en relaciones: se
representan igual que los
atributos de las entidades.
Herencia: Es un intento de
adaptación de estos diagramas
al paradigma orientado a
objetos.
11. 4. Conclusiones
El modelo entidad-relación ER es un
modelo de datos que permite
representar cualquier abstracción,
percepción y conocimiento en un
sistema de información formado por un
conjunto de objetos denominados
entidades y relaciones, incorporando
una representación visual conocida
como diagrama entidad-relación.
12. 5. Apreciación del equipo
Bajo mi punto de vista, creo que es una buena
forma de diseñar correctamente las bases de datos,
aunque algunas veces resulta más rápido
implementarlo directamente en nuestro gestor de
BBDD sin la necesidad de crear un gran diagrama,
sino usando notas más simples.