Teoría 

y Diseño de 
Base de Datos

Modelo 
Entidad Relación II
Área Ingeniería de Software 
Departamento de Ciencias de la Computación
Facultad de Economía y Administración
Universidad Nacional del Comahue
 2. “Modelo Entidad ­ Relación Extendido”  
2.a  Especialización ­ Generalización
2.b  Diseño de un Esquema E­R de BD 
2.c  Cardinalidad, Participación y Atributos descriptivos
2.d  Reducción de un Esquema E­R a Tablas – Claves
2.e Optimización de Tablas
2.f  Aplicando todos los Conceptos

Teoría y Diseño de BD 2
2.a  Especialización ­ Generalización  Modelo E ­ R Extendido

La ESPECIALIZACIÓN es el proceso de obtener subgrupos en 
un conjunto de entidades, que se diferencian de alguna forma de 
las otras entidades del conjunto.
…el refinamiento desde un conjunto de entidades inicial en 
sucesivos niveles de subgrupos de entidades representa un proceso 
de diseño descendente ( Top­Down )
p.e.  El conjunto de entidades Cuenta con los atributos NroCta y SaldoCta, 
una cuenta puede ser:
• Caja de Ahorro ­ con el atributo particular TasaInterés ­
• Cuenta Corriente ­ con el atributo particular SaldoDescubierto ­
 además la Cuenta Corriente pueden ser de tres tipos distintos:
• Normal ­ con el atributo NroMovimientos ­
• Gold ­ con los atributos PagoInterés y SaldoMínimo ­
• Senior ­ con atributo FechaNacimiento
Teoría y Diseño de BD 3
2.a  Especialización ­ Generalización  Modelo E ­ R Extendido
NroCta
SaldoCta El conjunto de entidades 
Cuenta
Especialización Cuenta
TasaInterés SaldoDescubierto

ISA
CajaDeAhorro CtaCorriente

NroMovimientos FechaNacimiento
ISA

Normal Gold Senior

PagoInterés SaldoMínimo
Teoría y Diseño de BD 4
2.a  Especialización ­ Generalización  Modelo E ­ R Extendido

La GENERALIZACIÓN es el proceso por el cual a partir de 
subgrupos de conjuntos de entidades, se puede obtener un 
conjunto de entidades más general.

…en este caso los múltiples conjuntos de entidades se agrupan 
en un conjunto de entidades de nivel más alto 
basado en características comunes. 

…representa un proceso de diseño ascendente ( Botton­Up )

Teoría y Diseño de BD 5
2.a  Especialización ­ Generalización  Modelo E ­ R Extendido
NroCta
SaldoCta El conjunto de entidades 
Cuenta
Cuenta
TasaInterés SaldoDescubierto

ISA
CajaDeAhorro CtaCorriente

NroMovimientos FechaNacimiento
ISA

Normal Gold Senior

PagoInterés SaldoMínimo
Teoría y Diseño de BD 6
Generalización
2.a  Especialización ­ Generalización  Modelo E ­ R Extendido

… se puede utilizar la GENERALIZACIÓN para definir ciertas 
Restricciones de Diseño.
 1. El primer tipo de restricción determina qué entidades pueden ser 
      miembros de un conjunto de entidades de nivel inferior: 

( 1.a ) Definidas por condiciones  la pertenencia a un conjunto de 
entidades de nivel inferior se evalúa en función de si una entidad satisface 
o no una condición explícita o predicado.
p.e. la entidad Cuenta de nivel más alto puede tener un atributo TipoCta, entonces todas 
las cuentas se evalúan según este atributo para saber si es CajaDeAhorro o CtaCorriente. 

Teoría y Diseño de BD 7
2.a  Especialización ­ Generalización  Modelo E ­ R Extendido

( 1.b ) Definidas por el usuario  la pertenencia a un conjunto de 
           entidades de nivel inferior no se define por una condición explícita o 
           predicado, sino por los usuarios de la BD.
p.e. la asignación de un vehículo de una agencia que vende autos usados a las 
subcategorías  usado y usado con garantía ( conjuntos de entidades ) después de un 
período de peritaje técnico, es una decisión del usuario responsable de dicha decisión

Teoría y Diseño de BD 8
2.a  Especialización ­ Generalización  Modelo E ­ R Extendido

 2. El segundo tipo de restricción se define según si las entidades pueden 
      pertenecer a más de un conjunto de entidades de nivel inferior: 

( 2.a ) Disjunto  requiere que una entidad no pertenezca a más de un 
        conjunto de entidades de nivel inferior. 
p.e. la entidad Cuenta puede ser CajaDeAhorro o CtaCorriente pero 
no ambas cosas a la vez. 

( 2.b ) Solapado  autoriza que una misma entidad pertenezca a más de 
un conjunto de entidades de nivel inferior. 
p.e. la asignación de abogados de un estudio a las especialidades penal, laboral, civil, 
familia, etc. ( conjuntos de entidades ) puede ser a más de un conjunto de estas entidades 
si tiene más de una especialidad.

Teoría y Diseño de BD 9
2.a  Especialización ­ Generalización  Modelo E ­ R Extendido

 3. El tercer tipo de restricción, que se denomina restricción de  
     completitud, especifica si un conjunto de entidades de nivel más alto 
     debe pertenecer o no, al menos a uno de los conjuntos de entidades de   
     nivel inferior: 

( 3.a ) Total  cada entidad de nivel más alto debe pertenecer a un 
           conjunto de entidades de nivel inferior. 
p.e. la generalización Cuenta es “total” ya que las cuentas son de Ahorro o Corriente. 

( 3.b ) Parcial  algunas entidades de nivel más alto pueden no 
           pertenecer a ningún conjunto de entidades de nivel inferior. 
p.e. La generalización Vehículos es “parcial” ya que los vehículos de la agencia que 
están en periodo de peritaje técnico, no serán asignados a ninguna de las subcategorías 
hasta que dicho periodo finalice. 

Teoría y Diseño de BD 10
2.b  Diseño de un Esquema E­R de BD Modelo E ­ R Extendido

         El diseñador de BD debe tomar ciertas decisiones   
         entre un amplio rango de alternativas:

 Si se usa un atributo o un conjunto de entidades para representar 
    un concepto del mundo real.
 Si un concepto del mundo real se expresa mejor mediante 
un conjunto de entidades o mediante un conjunto de relaciones. 
 Si se usa una relación ternaria o un par de relaciones binarias.

 Si se usa un conjunto de entidades fuerte o débil; si se decide que 
un conjunto de entidades es débil, se debe recordar que para  
identificar una entidad miembro, se requiere de la respectiva 
entidad dominante a la que está suboordinada.
Teoría y Diseño de BD 11
2.b  Diseño de un Esquema E­R de BD Modelo E ­ R Extendido

 Si el uso de una generalización ( especialización ) es apropiado; 
en un diagrama E­R una jerarquía de relaciones ISA, contribuye a 
la modularidad por permitir que los atributos comunes de conjuntos 
de entidades similares se representen en un único lugar.  

…pero además 
La restricciones de Cardinalidad y Participación de una 
relación generan importantes decisiones de diseño para 
determinar dónde se colocan 
los atributos descriptivos de dicha relación. 

Teoría y Diseño de BD 12
2.c  Cardinalidad, Participación y Atributos descriptivos  Modelo E ­ R Extendido

Relación 1­1
p.e. Suponer el atributo “FechaEmisión” de la relación Obtuvo entre la entidad Persona y 
la entidad Pasaporte ( relación Una a Una  con Participación Total del lado Pasaporte ), 
para mantener todas las personas que obtuvieron el pasaporte Argentino y la fecha en que fue 
emitido el mismo.

FechaEmisión
Dni
NroPas

Persona Obtuvo Pasaporte

¿ES CORRECTO?

Teoría y Diseño de BD 13
2.c  Cardinalidad, Participación y Atributos descriptivos  Modelo E ­ R Extendido

Relación 1­1
p.e. Suponer el atributo “FechaEmisión” de la relación Obtuvo entre la entidad Persona y 
la entidad Pasaporte ( relación Una a Una  con Participación Total del lado Pasaporte ), 
para mantener todas las personas que obtuvieron el pasaporte Argentino y la fecha en que fue 
emitido el mismo.

FechaEmisión
Dni FechaEmisión
NroPas

Persona Obtuvo Pasaporte

¿QUÉ SUCEDE CON LOS NULOS?

Teoría y Diseño de BD 14
2.c  Cardinalidad, Participación y Atributos descriptivos  Modelo E ­ R Extendido

Relación 1­1
p.e. Suponer el atributo “FechaEmisión” de la relación Obtuvo entre la entidad Persona y 
la entidad Pasaporte ( relación Una a Una  con Participación Total del lado Pasaporte ), 
para mantener todas las personas que obtuvieron el pasaporte Argentino y la fecha en que fue 
emitido el mismo.

ENTONCES....

FechaEmisión
Dni FechaEmisión
NroPas

Persona Obtuvo Pasaporte

Teoría y Diseño de BD 15
2.c  Cardinalidad, Participación y Atributos descriptivos  Modelo E ­ R Extendido

Relación 1­M
 p.e. Suponer la relación Completó entre la entidad Persona y la entidad Estudio 
( relación Muchas a Una ), para mantener el estudio con su respectiva “FechaEgreso” que 
completó una persona.

FechaEgreso
Dni CodPlan

Persona Completó Estudio

¿ES CORRECTO?

Teoría y Diseño de BD 16
2.c  Cardinalidad, Participación y Atributos descriptivos  Modelo E ­ R Extendido

Relación 1­M
 p.e. Suponer la relación Completó entre la entidad Persona y la entidad Estudio 
( relación Muchas a Una ), para mantener el estudio con su respectiva “FechaEgreso” que 
completó una persona.

FechaEgreso
Dni FechaEgreso CodPlan

Persona Completó Estudio

¿ES CORRECTO?

Teoría y Diseño de BD 17
2.c  Cardinalidad, Participación y Atributos descriptivos  Modelo E ­ R Extendido

Relación 1­M
 p.e. Suponer la relación Completó entre la entidad Persona y la entidad Estudio 
( relación Muchas a Una ), para mantener el estudio con su respectiva “FechaEgreso” que 
completó una persona.

FechaEgreso
Dni FechaEgreso CodPlan

Persona Completó Estudio

¿QUE PASA CON LOS NULOS?

Teoría y Diseño de BD 18
2.c  Cardinalidad, Participación y Atributos descriptivos  Modelo E ­ R Extendido

Relación M­M
 Los atributos de relaciones con cardinalidad Muchas a Muchas, 
se pueden colocar solamente en la relación.
p.e. Suponer la relación AccedeCta entre la entidad Cliente y la entidad Cuenta (relación 
Muchas a Muchas ), para mantener todos los accesos con su respectiva “FechaAcceso” 
que realizan los clientes a sus cuentas.

FechaAcceso
DniCli NroCta

Cliente AccedeCta Cuenta

Teoría y Diseño de BD 19
2.c  Cardinalidad, Participación y Atributos descriptivos  Modelo E ­ R Extendido
Conjunto de Entidades  Conjunto de Entidades 
“FechaAcceso”
CLIENTE CUENTA

14/07/04 C­1000/1
Scholz 12470988
22/04/04
C­2000/2
Vicario 9870123 15/06/04
C­3024/5
Zahn 34253037 21/07/04
31/07/04 C­1567/1
Martín 13904567
12/06/04 C­3000/1
Castañet 15234848
01/07/04
C­5342/4
Giró 11253037 28/07/04
C­9311/0

Conjunto de Relaciones 
AccedeCta 
Cardinalidad Muchas a Muchas

...ahora bien, nos queda pendiente como reducir los modelos E­R a tablas y 
determinar las claves, sobretodo las claves de las relaciones.
Teoría y Diseño de BD 20
2.d  Reducción de un Esquema E­R a Tablas ­ Claves  Modelo E ­ R Extendido

 Un esquema de BD E­R se puede representar por medio de
una colección de tablas. 

…para cada conjunto de entidades y para cada conjunto de 
relaciones de la BD hay una única tabla a la que se le asigna el 
nombre del conjunto de entidades o del conjunto de relaciones 
correspondiente.

…cada tabla tiene un número de columnas con nombres únicos.

   
Teoría y Diseño de BD 21
2.d  Reducción de un Esquema E­R a Tablas ­ Claves  Modelo E ­ R Extendido
 Sea E un conjunto de Entidades Fuertes con los 
atributos descriptivos  A1, A2, .. , An 
la entidad E se representa con una tabla E de n columnas, 
una columna por cada atributo de E.
A1, A2 
Clave = { NroPres }
NroPres MontoPres
NroPres
P­17 35000
MontoPres
P­23 15000
P­15 20000
Préstamo P­14 20000
P­93 5000
P­11 18000

Representación Tabular  de la entidad Préstamo 
Teoría y Diseño de BD 22
2.d  Reducción de un Esquema E­R a Tablas ­ Claves  Modelo E ­ R Extendido

D1 representa al conjunto de todos los números de préstamo y
D2 representa al conjunto de todos los montos
entonces
cualquier fila de la tabla préstamo debe consistir en una 
tupla ( v1 , v2 )
es decir  
v1 es un número de préstamo que está en el conjunto D1  y  
v2 es un monto que está en el conjunto D2

Teoría y Diseño de BD 23
2.d  Reducción de un Esquema E­R a Tablas ­ Claves  Modelo E ­ R Extendido

…ahora bien

… la tabla préstamo contendrá solo un subconjunto de todas las 
filas posibles.

…el conjunto de todas las filas posibles de préstamo es el 
producto cartesiano representado por  D1 × D2

…en general, si se tiene una tabla de n columnas, el conjunto de 
todas sus filas posibles es el producto cartesiano 
representado por  D1 × D2 × … × Dn­1 × Dn

Teoría y Diseño de BD 24
2.d  Reducción de un Esquema E­R a Tablas ­ Claves  Modelo E ­ R Extendido

 Sea E1 un conjunto de Entidades Débiles con los 
atributos descriptivos  A1, A2, .. , An 

Sea E2 un conjunto de Entidades Fuertes del que depende E1 

Sea la clave primaria de E2 el conjunto de atributos B1, B2, .. , Bm

la entidad E1 se representa con una tabla E1 de n + m columnas, 
una columna por cada atributo del conjunto
{ A1, A2, .. , An }  ∪  { B1, B2, .. , Bm }

Teoría y Diseño de BD 25
2.d  Reducción de un Esquema E­R a Tablas ­ Claves 
Modelo E ­ R Extendido
NroPres FechaPago
MontoPres
NroPago
MontoPago

Préstamo EsPagado Pago

B1 A1, A2, A3

NroPres NroPago FechaPago MontoPago

P­17 5 10/06/04 1000
Clave = { NroPres, NroPago }
P­23 11 03/07/04 500
P­15 22 05/07/04 750
P­14 69 15/07/04 750
Representación Tabular 
 de la entidad Pago P­93 103 17/07/04 250
P­17 6 18/07/04 1000
P­11 53 06/08/04 600
P­93 104 15/08/04 250
P­17 7
Teoría y Diseño de BD 18/08/04 1000
26
2.d  Reducción de un Esquema E­R a Tablas ­ Claves  Modelo E ­ R Extendido

 Sea R una Relación entre el conjunto de Entidades E1 , E2 , .. , En  
Sean pk( E1 ) , pk( E2 ) , .. , pk( En ) las claves primarias de 
E1 , E2 , .. , En respectivamente

Si el conjunto de relaciones R no tiene Atributos Descriptivos
 entonces 
Se crea una tabla con una columna por cada elemento del conjunto:
pk( E1 )  ∪  pk( E2 )  ∪  ..  ∪  pk( En )

Si el conjunto de relaciones R tiene m Atributos Descriptivos
 entonces 
Se crea una tabla con una columna por cada elemento del conjunto:
pk( E1 )  ∪  pk( E2 )  ∪  ..  ∪  pk( En ) ∪  { A1, A2, .. , Am }

Teoría y Diseño de BD 27
2.d  Reducción de un Esquema E­R a Tablas ­ Claves  Modelo E ­ R Extendido
DniCli DirCli
NroPres
NomCli MontoPres
CiudadCli

Cliente Tiene Préstamo

pk( E1 ) pk( E2 )

DniCli NroPres
Clave = { DniCli, NroPres }
9024931 P­17
14234848 P­23
Representación  27470988 P­15
Tabular   13537253 P­14
de la relación 
14234848 P­93
TienePréstamo
15219742 P­17
24602539 P­11
Teoría y Diseño de BD 28
2.d  Reducción de un Esquema E­R a Tablas ­ Claves  Modelo E ­ R Extendido
FechaAcceso
DniCli DirCli
NroCta
NomCli CiudadCli SaldoCta

Cliente AccedeCta Cuenta

pk( E1 ) pk( E2 ) a1

DniCli NroCta FechaAcceso

Clave = { DniCli, NroPres, FechaAcceso } 9024931 C­1000/1 14/07/04
14234848 C­2000/2 22/04/04

Representación  27470988 C­3024/5 15/06/04

Tabular   13537253 C­1567/1 21/07/04
de la relación  9024931 C­3000/1 31/07/04
AccedeCta 15219742 C­5342/4 12/06/04
24602539 C­9311/0 01/07/04
Teoría y Diseño de BD
14234848 C­3000/1 28/07/0429
2.d  Reducción de un Esquema E­R a Tablas ­ Claves  Modelo E ­ R Extendido

…es importante destacar que en general existe 
Redundancia de Tablas 
cuando un conjunto de Relaciones liga un 
conjunto de Entidades Débiles con el correspondiente 
conjunto de Entidades Fuertes.

p.e. el conjunto de entidades débiles Pago depende del conjunto de entidades 
fuertes Préstamo a través del conjunto de relaciones EsPagado:
 La Clave de Pago es { NroPres, NroPago } y la Clave de Préstamo 
es { NroPres }  
 La tabla para el conjunto de entidades Pago tiene cuatro columnas 
(cuatro atributos): NroPres, NroPago, FechaPago, MontoPago. 
 Como la tabla de la relación EsPagado se compone de dos columnas 
(dos atributos): NroPres, NroPago, la relación EsPagado no necesita 
tabla, es decir Es Redundante.
Teoría y Diseño de BD 30
2.d  Reducción de un Esquema E­R a Tablas ­ Claves  Modelo E ­ R Extendido
Dada una Especialización ­ Generalización existen dos métodos 
para su Representación Tabular: 

Método 1.
 Crear una tabla para el conjunto de entidades de nivel más alto.
 Crear una tabla para cada conjunto de entidades de nivel más bajo con 
una columna por cada uno de los atributos de ese conjunto de entidades 
más una columna por cada atributo de la clave primaria del conjunto de 
entidades de nivel más alto.

Método 2.  ­ únicamente en Generalizaciones Disjuntas y Completas ­ 
 No crear una tabla para el conjunto de entidades de nivel más alto.
 Crear una tabla para cada conjunto de entidades de nivel más bajo con 
una columna por cada uno de los atributos de ese conjunto de entidades 
más una columna por cada atributo del conjunto de entidades de nivel más 
alto.
Teoría y Diseño de BD 31
2.d  Reducción de un Esquema E­R a Tablas ­ Claves  Modelo E ­ R Extendido
NroCta
Método 1. SaldoCta

Cuenta
TasaInterés SaldoDescubierto

ES
CajaDeAhorro CtaCorriente

Cuenta CajaDeAhorro CtaCorriente

NroCta SaldoCta NroCta TasaInterés NroCta SaldoDescubierto

Clave = { NroCta } Clave = { NroCta } Clave = { NroCta }

Teoría y Diseño de BD 32
2.d  Reducción de un Esquema E­R a Tablas ­ Claves  Modelo E ­ R Extendido
NroCta
Método 2. SaldoCta

Cuenta
TasaInterés SaldoDescubierto

ES
CajaDeAhorro CtaCorriente

CajaDeAhorro CtaCorriente
NroCta SaldoCta TasaInterés NroCta SaldoCta SaldoDescubierto

Clave = { NroCta } Teoría y Diseño de BD Clave = { NroCta } 33

2.e  Optimización de Tablas Modelo E ­ R Extendido
…algunas cuestiones inciales sobre optimización de tablas 
considerando la restricción de Cardinalidad
  Sean los conjuntos de entidades 
E1 = ( A1, .. , Am )  y  E2 = ( B1, .. , Bn ) 
con Claves ( A1, .. , Ai )  y  ( B1, .. , Bj ) respectivamente

  Sea R una relación que vincula  E1  y  E2 

…existe una: 

     Solución Costosa General:                                       
  E1 = ( A1, .. , Ai, .. , Am )
  E2 = ( B1, .. , Bj, .. , Bn )
  R = ( A1, .. , Ai, B1, .. , Bj )
Teoría y Diseño de BD 34
2.e  Optimización de Tablas Modelo E ­ R Extendido
  Sean los conjuntos de entidades 
E1 = ( A1, .. , Am )  y  E2 = ( B1, .. , Bn ) 
con Claves ( A1, .. , Ai )  y  ( B1, .. , Bj ) respectivamente
 Sea R una relación que vincula  E1  y  E2  con Cardinalidad 

Una a Una: 
la Clave de E2 se 
…existe una: puede mover a la 
tabla de E1 y 
       Solución Económica:   entonces se debe 
eliminar la tabla de 
      E1 = ( A1, .. , Ai, .. , Am, B1, .. , Bj ) R (o viceversa)
      E2 = ( B1, .. , Bj, .. , Bn )
CUIDADO! Previamente hay que analizar las consecuencias de aplicar esta 
optimización considerando la restricción de Participación que tiene la relación 
y las necesidades del dominio modelado. 
Teoría y Diseño de BD 35
2.e  Optimización de Tablas Modelo E ­ R Extendido
  Sean los conjuntos de entidades 
E1 = ( A1, .. , Am )  y  E2 = ( B1, .. , Bn ) 
con Claves ( A1, .. , Ai )  y  ( B1, .. , Bj ) respectivamente
 Sea R una relación que vincula  E1  y  E2  con Cardinalidad 

Muchas a Una de E1  a  E2 

…existe una: la Clave de E2 se 
puede mover a la 
          Solución Económica:   tabla de E1 y 
                E1 = ( A1, .. , Ai, .. , Am, B1, .. , Bj ) entonces se debe 
eliminar la tabla 
        E2 = ( B1, .. , Bj, .. , Bn ) de R

CUIDADO! Previamente hay que analizar las consecuencias de aplicar esta 
optimización considerando la restricción de Participación que tiene la relación
y las necesidades del dominio modelado.
Teoría y Diseño de BD 36
2.e  Optimización de Tablas Modelo E ­ R Extendido

  Sean los conjuntos de entidades 
E1 = ( A1, .. , Am )  y  E2 = ( B1, .. , Bn ) 
con Claves ( A1, .. , Ai )  y  ( B1, .. , Bj ) respectivamente

 Sea R una relación que vincula E1 y E2 con Cardinalidad 

Muchas a Muchas: 

…existe una: no se pueden 
eliminar tablas,  
          Solución Única:                                       
ya que se 
        E1 = ( A1, .. , Ai, .. , Am ) requieren las 
tablas de E1 , E2 
        E2 = ( B1, .. , Bj, .. , Bn ) y R

        R = ( A1, .. , Ai, B1, .. , Bj )
Teoría y Diseño de BD 37
2.e  Optimización de Tablas Modelo E ­ R Extendido
  Sean los conjuntos de entidades 
E1 ,  E2 , .. , En  con Claves 
pk( E1 ), pk( E2 ) , .. , pk( En ) respectivamente

  Sea R una relación n­aria que vincula E1 , E2 , .. , En

…existe una: 
Solución General:                                       
E1 = ( A1, .. , Ai1, .. , Am1 )  ,  pk( E1 ) = { A1, .. , Ai1 }
E2 = ( B1, .. , Bi2, .. , Bm2 )  ,  pk( E2 ) = { B1, .. , Bi2 }
:             : 
En = ( N1, .. , Nin, .. , Nmn )  ,  pk( En ) = { N1, .. , Nin } 
R = ( A1, .. , Ai1, B1, .. , Bi2, N1, .. , Nin )
Teoría y Diseño de BD 38
2.f  Aplicando todos los Conceptos Modelo E ­ R Extendido
p.e.: Suponer nuevamente la relación Obtuvo entre la entidad Persona y 
la entidad Pasaporte ( relación Una a Una con Participación Total del lado Pasaporte ). 

¿Dónde es más apropiado colocar el atributo “FechaEmisión” 
de acuerdo con la restricciones enunciadas para el dominio a modelar? 
Nombre
FechaEmisión
Dni Dirección NroPas

Persona Obtuvo Pasaporte

¿Qué debo considerar para reducir un modelo E­R a tablas?
  Restricciones de Cardinalidad y Participación
  Valores Nulos y Redundancia
  Claves
  Optimización de Tablas 

Teoría y Diseño de BD 39
2.f  Aplicando todos los Conceptos Modelo E ­ R Extendido

...entonces

Persona
Pasaporte Dni Nombre Dirección
12470988 ... ...
NroPas FechaEmisión Dni
08775003 14/12/04 12470988 15234848 ... ...

11345611 07/08/2005 32123006 34900127 ... ...

16798800 15/04/03 10480915 11253037 ... ...

27542110 ... ...
Clave = { NroPas }
10480915 ... ...
32123006
12470988 ...
12470988 ...
12470988

Clave = { Dni }

Teoría y Diseño de BD 40
2.f  Aplicando todos los Conceptos Modelo E ­ R Extendido

p.e. Suponer otra relación Completó entre la entidad Persona y la entidad Estudio (en donde 
una persona puede realizar varios estudios

¿Dónde es más apropiado colocar el atributo “FechaEgreso” 
de acuerdo con la restricciones enunciadas para el dominio a modelar? 

FechaEgreso CodPlan
Nombre
Dni Descripción
Dirección

Persona Completó Estudio

Teoría y Diseño de BD 41
2.f  Aplicando todos los Conceptos Modelo E ­ R Extendido
...entonces
Persona Estudio
Dni Nombre Dirección CodPlan Descripción
12470988 ... ... ENET001 ...
9870123 ... ... ENET002 ...
34253037 ... ... MAG001 ...
13904567 ... ... MAG002 ...
15234848 ... ... CENS023 ...
11253037 ... ... CENS023 ...
Clave = { Dni } Clave = { CodPlan }
Completó
Dni FechaEgreso CodPlan
12470988 14/12/86 ENET001
9870123 09/12/80 ENET002
Clave = { Dni, FechaEgreso }
12470988 15/04/05 MAG001
34253037 15/12/05 CENS022
13904567 10/12/87 CENS022
Teoría y Diseño de BD 42
2.f  Aplicando todos los Conceptos Modelo E ­ R Extendido

p.e. Suponer nuevamente la relación AccedeCta entre la entidad Cliente y la entidad Cuenta 
( relación Muchas a Muchas, con Participación Parcial de ambos lados ).
 

¿Dónde es más apropiado colocar el atributo “FechaAcceso” 
de acuerdo con la restricciones enunciadas para el dominio a modelar? 

FechaAcceso
NroCta
Nombre
DniCli Saldo

Cliente AccedeCta Cuenta

...entonces
Teoría y Diseño de BD 43
2.f  Aplicando todos los Conceptos Modelo E ­ R Extendido
Cliente Clave = { Dni }
DniCli Nombre
Scholz 12470988 AccedeCta
Vicario 9870123
DniCli FechaAcceso NroCta
12470988 14/07/04 C­1000/1
Zahn 34253037
9870123 22/04/04 C­2000/2
Martín 13904567
34253037 15/06/04 C­3024/5
Castañet 15234848
13904567 21/07/04 C­1567/1
Giró 11253037
12470988 31/07/04 C­3000/1
Cuenta Clave = { NroCta } 12470988 31/07/04 C­1000/1
NroCta Saldo 15234848 12/06/04 C­5342/4
C­1000/1 800 11253037 01/07/04 C­9311/0
C­2000/2 2500 12470988 28/07/04 C­3000/1
C­3024/5 350 9870123 28/07/04 C­3000/1
C­1567/1 180 Clave = { DniCli, FechaAcceso, NroCta }
C­3000/1 5000
C­5342/4 1200
Teoría y Diseño de BD 44
C­9311/0 240
2.f  Aplicando todos los Conceptos Modelo E ­ R Extendido

p.e. Suponer la relación Pertenece entre la entidad Municipio y la entidad Provincia 
( relación Muchas a Una con Participación Total del lado Municipio ). 

¿Dónde es más apropiado colocar el atributo “FechaFundación” 
de acuerdo con la restricciones enunciadas para el dominio a modelar? 

FechaFundación

NombreMun NombreProv
CodPostal SuperficieKm2
Ubicación

Municipio Pertenece Provincia

Teoría y Diseño de BD 45
2.f  Aplicando todos los Conceptos Modelo E ­ R Extendido
...entonces
Municipio
CodPostal NombreMun Ubicación FechaFundación NombreProv
8324 Neuquén ... 12/09/1904 Neuquén
8300 Cipolletti ... 03/10/1903 Río Negro
9200 Esquel ... 25/02/1906 Chubut
8370 SMdelosAndes ... 04/02/1898 Neuquén
8400 Bariloche ... 03/05/1902 Río Negro
Clave = { CodPostal }

Provincia
NombreProv SuperficieKm2
PARTICIPACION Neuquén 94078
TOTAL Río Negro 203013
Chubut 224686
Clave = { NombreProv}
Teoría y Diseño de BD 46
2.f  Aplicando todos los Conceptos Modelo E ­ R Extendido

Puedo saber que Persona trabaja en qué Proyecto?

dni número denominación

dirección

apellido Persona Proyecto

nombre realiza
trabaja

Departamento

interno nombre

Teoría y Diseño de BD 47
2.f  Aplicando todos los Conceptos Modelo E ­ R Extendido

Puedo saber que Persona trabaja en qué Proyecto?
Puedo saber que Persona Trabaja en qué Departamento?
Puede una persona trabajar en mas de un Departamento?

dni número denominación

dirección

apellido Persona trabaja Proyecto

nombre realiza

Departamento

interno nombre
Teoría y Diseño de BD 48
2.f  Aplicando todos los Conceptos Modelo E ­ R Extendido

Y si quisiera que una persona trabaje en solo un 
Departamento? Esta sería una solución?
Ahora, puede un proyecto pertenecer a mas de un 
Departamento?

dni número denominación

dirección

apellido Persona trabaja Proyecto

nombre
se_desempeña

Departamento

interno nombre
Teoría y Diseño de BD 49
2.f  Aplicando todos los Conceptos Modelo E ­ R Extendido

Si la especificación es: Una persona trabaja en un solo 
Departamento, un Departamento puede tener a cargo 
varios Proyectos, y en un Proyecto trabajan varias 
personas del Departamento correspondiente.

dni número denominación

dirección

?
apellido Persona Proyecto

nombre

Departamento

interno nombre
Teoría y Diseño de BD 50
2.f  Aplicando todos los Conceptos Modelo E ­ R Extendido

Si tengo un Director General de cada Proyecto, Puedo 
hacer esto?

dni número denominación

dirección dni

apellido Persona Proyecto

nombre realiza
trabaja

Departamento

interno nombre

Teoría y Diseño de BD 51
2.f  Aplicando todos los Conceptos Modelo E ­ R Extendido

Si el empleado trabaja en un proyecto solo en 
determinadas fechas?

dni número denominación

dirección

apellido Persona trabaja

Proyecto

nombre fecha_inicio
fecha_fin
Es correcto?

Teoría y Diseño de BD 52
2.f  Aplicando todos los Conceptos Modelo E ­ R Extendido

Si el empleado trabaja en un proyecto solo en 
determinadas fechas?

dni número denominación

dirección

apellido Persona trabaja

Proyecto

nombre fecha_inicio
fecha_fin
Es correcto?

Teoría y Diseño de BD 53
2.f  Aplicando todos los Conceptos Modelo E ­ R Extendido

Si el empleado trabaja en un proyecto solo en 
determinadas fechas?

dni número denominación

dirección

apellido Persona trabaja

Proyecto

nombre fecha_inicio?
fecha_fin?

Cuál es la Solución Correcta?
Teoría y Diseño de BD 54
 Resumen … hasta aquí hemos tratado:

 ESPECIALIZACIÓN y GENERALIZACIÓN

Modelo   CLAVES para el DISEÑO de un ESQUEMA E­R de BD

de   CARDINALIDAD, PARTICIPACIÓN y ATRIBUTOS 
Datos DESCRIPTIVOS
E­R  REDUCCIÓN de un ESQUEMA E­R a TABLAS ­ CLAVES 
Extendido
 OPTIMIZACIÓN de TABLAS

 APLICANDO todos los CONCEPTOS

Teoría y Diseño de BD 55