Bases de Datos

Modelo Entidad Relación Extendido

Dr. Carlos E. Alvez

[Link]@[Link]

Modelo Entidad-Relación Extendido (ERE)

 Especialización
 Generalización
 Diseño de restricciones en
Especialización / Generalización
 Agregación
 Decisiones de diseño E-R
 Mapeos de esquemas ERE a tablas

Peter Pin-Shan Chen: The entity Relationship Model – Toward a Unified View of Data (1976)
Carlos E. Alvez 2

1
 Especialización
 Proceso de diseño top-down – un conjunto de entidades
puede incluir subgrupos de entidades que se diferencian de
alguna forma de las otras entidades del conjunto.

 Estos subgrupos resultan en conjuntos de entidades de

menor nivel que tienen atributos o participan en relaciones
que no son aplicables al conjunto de entidades de nivel
superior.

 Se representa con un triángulo etiquetado ES. Ej. un cliente

“es” una persona (ISA en ingles).

 Herencia de atributos – los conjuntos de entidades de menor

nivel heredan a todos los atributos y participan en todas las
relaciones del conjunto de entidades de nivel superior.
Carlos E. Alvez 3

Ejemplo de
especialización

Carlos E. Alvez 4

2
 Generalización

 Proceso de diseño bottom-up – Combina un número de

conjuntos de entidades que comparten un conjunto de
características en conjunto de entidades de nivel superior.

 Especialización y generalización son simples inversiones;

estas son representadas en un diagrama E-R de la misma
forma.

 La relación ES, también se indica como una relación de

superclase – subclase.

Carlos E. Alvez 5

Diseño de restricciones en una

Especialización/Generalización

 Restricciones sobre qué entidades pueden ser miembro

de un nivel dado de un conjunto de entidades

 Definido por condición

 Ej. Todas las entidades que satisfagan la condición:
tipo-cuenta = «cuenta corriente» estarán incluidas en
el CE cuenta-corriente.

 Definidos por el usuario: las entidades se asignan a un

conjunto de entidades dado, por el usuario de la BD.
 Ej. Asignar empleados a grupos de trabajo.

Carlos E. Alvez 6

3
 Diseño de restricciones en una
Especialización/Generalización

 Restricciones que definen si las entidades pueden

pertenecer a más de un CE de nivel más bajo en una
generalización simple.

 Disjuntos
 Requiere que una entidad no pertenezca a más de
un conjunto entidad de nivel más bajo.
 En el diagrama E-R se indica disjunto luego del
triángulo ES.

 Solapados
 La misma entidad puede pertenecer a más de un
conjunto entidad de nivel más bajo.
Carlos E. Alvez 7

Diseño de restricciones en una

Especialización/Generalización (Cont.)

 Restricción de completitud en una generalización o

especialización, especifica si un conjunto de entidades de
nivel más alto debe pertenecer o no a al menos a uno de los
conjuntos de entidades de nivel más bajo en una
generalización/especialización.

 Total: Cada entidad de nivel más alto debe pertenecer a

un conjunto de entidades de nivel más bajo.

 Parcial: Algunas entidades de nivel más alto pueden no

pertenecer a algún conjunto de entidades de nivel más bajo.

Carlos E. Alvez 8

4
 Agregación
 Considérese la relación ternaria trabaja-en, entre empleado,
sucursal y trabajo.

 Supóngase ahora que se desean registrar los

directores para las tareas realizadas por un empleado
en una sucursal.

 El conjunto de relaciones
trabaja-en y dirige, representan
información solapada
Carlos E. Alvez 9

Agregación (Cont.)
 Combinar los conjuntos de
relaciones dirige y trabaja-
para en una única relación

 Cada relación dirige corresponde a una relación trabaja-en

 Sin embargo, algunas relaciones trabaja-en pueden no
corresponder a ninguna relación dirige (Por lo tanto, no
podemos descartar la relación trabaja-en).

 Eliminar esta redundancia mediante agregación

 La agregación es una abstracción a través de la cual las
relaciones se tratan como entidades de nivel más alto.

Carlos E. Alvez 10

5
 Diagrama E-R con Agregación
 Sin introducir redundancia, el siguiente diagrama
representa:

 Un empleado
trabaja en un
trabajo en
particular en una
sucursal particular

 Una combinación empleado, sucursal,

trabajo puede tener asociado un
director.

Carlos E. Alvez 11

Decisiones de diseño ER
 Si se usa un atributo o un conjunto de entidades para
representar un objeto.
 Ejemplo: Caso de teléfonos de personas.
 Más de uno (multivalorado).
 Más de un atributo. Por ejemplo: tipo y número (compuesto).
 Si el objeto por si mismo tiene relaciones con otros conjuntos
de entidades.

 Si un concepto del mundo real se expresa más exactamente

mediante un conjunto de entidades o mediante un conjunto de
relaciones.
 Recordar que, en los conjuntos de relaciones, cada relación queda
identificada unívocamente por las claves de los conjuntos de
entidades que participan en la misma.
Carlos E. Alvez 12

6
 Decisiones de diseño ER
 Si se usa una relación ternaria o un par de relaciones binaras
 Existen formas de traducir relaciones n-arias en binarias.
 Siempre buscar la forma que más se ajusta a la realidad.

 Si se usa un CED o un CEF; un CEF y sus CED dependientes

se pueden considerar como un «objeto» en la BD, debido a
que la existencia de las EDs depende de la EF.
 Si se tomo como parte de un único objeto, puede generar
redundancia. Por ejemplo en Factura-Items, los datos de la
factura se repetirían para cada ítems.
 Otra opción es generar claves para las entidades débiles. Por
ejemplo: estudios y series de exámenes. Un estudio tiene varios
exámenes. Si el n° de examen es único, seria una relación
muchos a uno entre dos CDF.
Carlos E. Alvez 13

Decisiones de diseño ER
 Si se usa un CED o un CEF: otro ejemplo

programa cod_asignatura fecha_inicio

semestre_año
duración
título fecha_fin

asignatura se_dicta asig_cursada

programa fecha_inicio
cod_asignatura cod_cursado
duración
título fecha_fin

asignatura se_dicta asig_cursada

Carlos E. Alvez 14

7
 Decisiones de diseño E-R
 Si el uso de la generalización es apropiado:
 La generalización, o una jerarquía de relaciones ES,
contribuye a la modularidad por permitir que los atributos
comunes de conjuntos de entidades similares se representen
en un único lugar en un diagrama E-R.

 Si el uso de la agregación es apropiado:

 la agregación agrupa una parte de un diagrama E-R en un
único conjunto de entidades, permitiendo tratar el
conjunto de entidades de la agregación como una unidad
única sin importar los detalles de su estructura interna.

 El diseñador de BD necesita tener un buen entendimiento

de la empresa que se modela para tomar estas decisiones.

Carlos E. Alvez 15

Fases de diseño de una BD

 Fase inicial del diseño de bases de datos: consiste en
caracterizar completamente las necesidades de datos esperadas
por los usuarios de la BD.
 El resultado de esta fase es una especificación de requisitos
del usuario.

 La fase de diseño conceptual: El diseñador elige un modelo

de datos y, aplicando los conceptos del modelo de datos
elegido (Ej. E-R), traduce los requisitos a un esquema
conceptual de la BD.
 El resultado de esta fase es un esquema conceptual.

Carlos E. Alvez 16
Pág. 40 Fundamentes de Bases de Datos

8
 Fases de diseño de una BD (Cont)

 La fase de diseño lógico, el diseñador traduce el

esquema conceptual de alto nivel al modelo de datos de
implementación del sistema de BD que se usará.

 La fase de diseño físico, en la que se especifican las

características físicas de la BD a un SGBD específico.
 Estas características incluyen la forma de
organización de los archivos, las estructuras de
almacenamiento interno, los métodos de acceso,
etc.

Carlos E. Alvez 17

Mapeos de esquemas ERE a tablas

 Una base de datos conformada por un diagrama ER se

puede representar como una colección de tablas.

 Por cada conjunto entidad y conjunto relación, existe

una única tabla a la que se le asigna el nombre de
conjunto entidad o relación.

 Cada tabla tiene n cantidad de columnas con nombres

únicos (generalmente correspondiente a los atributos).

 La conversión de un diagrama ER a formato de tablas,

es la base para la derivación de un diseño de una BD
relacional desde una diagrama ER.

Carlos E. Alvez 18

9
Mapeos de esquemas ERE a tablas

Fuertes
Entidades
Débiles

Participación Total
Conjuntos Participación
Participación Parcial

Relaciones Uno a uno

restricciones
de Uno a varios
cardinalidad
Varios a varios

Carlos E. Alvez 19

Mapear conjunto de entidades a tablas.

 Un conjunto de entidades fuertes con atributos simples,
se representa como una tabla con los mismos atributos.

Carlos E. Alvez 20

10
 Mapear conjunto de entidades a tablas.
 Un conjunto de entidades débiles se representa como una tabla con
una columna por cada atributo de la entidad, y además, los atributos
que componen la clave primaria de la entidad fuerte de identificación.

Tabla pago

Carlos E. Alvez 21

Mapear conjunto de relaciones a tablas

 Una relación entre R entre los conjuntos de entidades A, B, C.

a1 ... an

A R C

 se representa como una tabla R, con un columna por cada

atributo de R {a1, ..., an}  {KA, KB, KC},
donde KA, KB, KC, son los conjuntos de atributos que
forman las CP de las entidades A, B y C respectivamente.

Carlos E. Alvez 22

11
 Mapear conjunto de relaciones a tablas

 Ejemplo:

Tabla prestatario

Carlos E. Alvez 23

Redundancia de tablas

 Existen casos en que pueden haber redundancia de tablas

 Uno de estos casos es la relación de identificación, la

cual tiene siempre las siguientes características:
 Varios a uno
 La (KP del CEF)  (KP del CED).
 Las relaciones de identificación no tienen atributos.

 Una relación de identificación I, se representaría con una

tabla I con una columna por cada uno de los siguientes
atributos:
 I {KP del CEF}  D  incluidos en la tabla del CED.

 Por lo tanto la tabla I es redundante.

Carlos E. Alvez 24

12
 Redundancia de tablas
 Ejemplo de relación de identificación

Tabla pago_prestamo Tabla pago

Carlos E. Alvez 25

Combinación de tablas

 Varios a varios A R B

 Independiente del tipo de TA TR TB

participación

A R B
 Varios a uno
 Con participación total TA TR TB
del lado de muchos.
TA {atrib. TA  atrib. TR}

Carlos E. Alvez 26

13
 Combinación de tablas

 Uno a uno con A R B

participación
total de ambos TA TR TB
lados.
TA {atr. TA  KTB}

 Uno a uno con

A R B
participación
total de un lado. TA TR TB
TA {atr. TA  atr. TR}

 Uno a uno con A R B

participación
parcial de ambos TA TR TB
lados.
Carlos E. Alvez 27

Atributos compuestos

 Los atributos compuestos se representan de manera plana,

separando un atributo por cada componente del atributo.

TABLA Cliente

calle_cliente

ciudad_cliente

provincia_cliente

codigo_postal_cliente

Carlos E. Alvez 28

14
 Atributos multivaluados
 Un atributo multivaluado M de una entidad E se representa con
una tabla separada M con una columna por cada uno de los
atributos:
 (AM  CPE}
 Donde AM son se refiere al atributo M (o componentes de M) y
CPE corresponde al conjunto de atributos que componen la
clave primaria de E.

Clientes Teléfonos
Nro Cliente Nombre Nro Cliente NroTeléfono
c1 Juan c1 154235645
c2 Pedro c1 4228969
c3 Jorge c2 154252538
c4 Gabriel c2 156788987
c5 Carlos c2 4256666
… …
Carlos E. Alvez 29

Representación de la Generalización

 Existen dos opciones:

 MÉTODO 1

 Formar una tabla para la entidad de mayor nivel.

 Formar una tabla para cada conjunto entidad de nivel

inferior, las cuales incluyen sus conjuntos de
atributos respectivos, más los atributos de la CP de
la entidad de mayor nivel.

Carlos E. Alvez 30

15
 Representación de la Generalización

 MÉTODO 1

 Ventaja: Actualizaciones (por ejemplo de datos de personas:

dirección, teléfono, etc.).
 Desventajas: obtener la información (por ejemplo, de un empleado)
requiere acceder a dos tablas.
Carlos E. Alvez 31

Representación de la Generalización (Cont.)

 MÉTODO 2
 Formar una tabla por cada conjunto entidad con todos sus
atributos locales y heredados.

 Si la especialización es total, la tabla para la entidad

generalizada (ej. persona) no requiere almacenar información.
 Puede ser definida como una vista que contenga la unión
de las tablas especializadas.
 Una tabla explícita puede necesitarse para restricciones
de clave foránea.

Carlos E. Alvez 32

16
 Representación de la Generalización (Cont.)

 MÉTODO 2

 Ventaja: Se tienen todos los datos de personas en una sola tabla.

 Desventajas: Calles y ciudades se pueden almacenar de manera
redundante para personas que son empleados y clientes.
Carlos E. Alvez 33

Representación de la Generalización (Cont.)

 Conclusión

 Método 1: Es mas apropiado para casos de

generalización solapada, para evitar redundancias. Por
ejemplo, caso de personas (clientes, empleados, etc.).

 Método 2: Es mas apropiado para casos de

generalización disjunta (sobre todo, si es total). Por
ejemplo: el caso de cuentas (caja_ahorro, cta_cte, etc.).

Carlos E. Alvez 34

17
Relaciones correspondientes a la agregación
 Para representar una agregación, se debe crear una tabla
que contenga:
 La clave primaria de la relación agregada,
 La clave primaria del conjunto de entidades asociado
 Algunos atributos descriptivos.

• CPR1: CPA U CPB

A R1 B
• CPR2: CPR1 U CPC
a1
R2 ... • Atributos de la tabla R2:
an • {a1, .., an} U CPR2
C
Carlos E. Alvez 35

Ejemplos (1)

• Mapear a Tablas

Carlos E. Alvez 36

18
Ejemplos (2)

• Mapear a Tablas nro_calle

nom_calle ciudad

fecha_act
nombre
cod_suc direccion
id_cli
nro_cta
saldo

cuentas depositante clientes

Carlos E. Alvez 37

Ejemplos (3)
• Mapear a Tablas

Carlos E. Alvez 38

19
Ejemplos (4)
• Mapear a Tablas

id_emp Dirige id_dep

nom_emp Empleado Departamento

nom_dep
salario
Pertenece

Carlos E. Alvez 39

Bibliografía
 ABRAHAM SILBERSCHATZ, HENRY F. KORTH, S.
SUDARSHAN. “FUNDAMENTOS DE BASES DE DATOS”.
McGraw-Hill, quinta edición, 2007
 Capítulo 6

 ELMASRI, RAMES A. & NAVATHE, SHAMKANT. B.

“FUNDAMENTOS DE SISTEMAS DE BASES DE DATOS”.
Addison Wesley, quinta edición, 2010.
 Capítulos 3 y 4

 Bertone Rodolfo, Thomas Pablo. “Introducción a las Bases de

Datos - Fundamentos y Diseño”. Prentice-Hall, 1ra. edición,
2011.
 Capítulos 11 y 12
Carlos E. Alvez 40

20