Gustavo Adolfo Dejean

Profesor adjunto con dedicacin exclusiva en la Facultad

de Ingeniera de la Universidad Nacional de La Matanza
Profesor asociado a cargo de la Facultad de Informtica y
Ciencias de la Comunicacin de la Universidad de Morn
Profesor adjunto de la Universidad de Belgrano

EL MODELO ENTIDAD INTERRELACION

Una herramienta de diseo conceptual

EDICIONES DEL CENTRO DE ESTUDIANTES DE COMPUTACIN

E INFORMTICA
2

Notas para el Iector

El libro se divide en tres captulos, en el
primero se comienza explicando qu es un modelo
de datos y se presenta una metodologa de diseo
lgico de bases de datos.
En el captulo 2, se detallan las
construcciones bsicas del modelo entidad
interrelacin y su equivalencia en el modelo
relacional. Si el lector desconoce la terminologa
relacional puede dejar para mas adelante las
referencias a dicho modelo. Se trat de dar
buenos ejemplos para evitar grandes
explicaciones. En el tem 3 se ve un refinamiento
del modelo al eliminar ciertas construcciones
redundantes. En el tem 4 se da otra clase de
refinamiento necesario para cuando el modelo
lgico a utilizar sea el relacional.
En el captulo 3 se dan los conceptos mas
avanzados que corresponden al modelo entidad
interrelacin extendido. En particular se trata por
completo el tema de interrelaciones ternarias,
pretendiendo ser ste el mayor aporte de la
presente obra. Por ltimo se incluye una serie de
ejercicios tericos y prcticos, utilizados por el
autor en distintas ctedras de bases de datos.
El objetivo principal de este libro es ofrecer
una informacin lo suficientemente completa sobre
el modelo entidad interrelacin, como para que el
lector pueda modelar con gran exactitud al mundo
real. Un segundo objetivo, muy ligado al anterior,
 3

es cmo aplicar el modelado semntico al diseo

lgico de las bases de datos relacionales.
El libro est dirigido a profesionales que
estn interesados en el rea de bases de datos y
anlisis de sistemas, a estudiantes de las carreras
de informtica y a docentes que necesiten material
pedaggico para sus cursos.
Reconocimientos
Quiero expresar mi reconocimiento a todas
las personas que han ayudado a la mejora del
presente libro ya sea por su paciente lectura de los
sucesivos borradores como por los comentarios o
consejos aportados. En especial quiero nombrar a
Sandra Di Plcido, Julio Csar Abramoff y Marcelo
Vinjoy. Tambin mi reconocimiento a los alumnos
de la Universidad de Morn quienes fueron los
principales motivadores de la presente obra.

G.A.D.
4

CAPTULO 1
MODELO DE DATOS
En el esfuerzo por querer representar los
datos del mundo real, los informticos han
desarrollado un conjunto de simbologas y reglas
que dieron origen a los modelos de datos. En la
actualidad se diferencian bien entre modelos de
datos conceptuales, modelos de datos lgicos y
por ltmo modelos de datos fsicos, segn el nivel
de abstraccin en el que se definen.
Los modelos de datos conceptuales son los
modelos de ms alto nivel de abstraccin. Operan
en el nivel conceptual y permiten obtener a partir
de la observacin de la realidad un esquema
conceptual del mundo real que se desea modelar.
Su objetivo es captar la semntica de los datos en
una forma cercana al lenguaje natural y el
esquema conceptual resultante debe ser una
exacta representacin del mundo real1. Por esta
razn tambin se los llama modelos semnticos y
a la tarea de modelar utilizando dicho tipo de
modelo se la llama modelado semntico. El
modelo semntico ms conocido es el modelo
entidad interrelacin cuyo desarrollo es el objetivo
del presente libro. Otro modelo semntico es el
modelo RM/T que no se tratar.

1
Con el trmino mundo real se quiere decir cualquier
tipo de Sistema, como por ejemplo, podra ser una
Organizacin Empresaria.
 5

Los modelos de datos lgicos tratan de

representar a los datos lgicamente. Su objetivo
es obtener un esquema lgico de los datos.
Ejemplo de estos modelos son: el modelo
relacional, el de red y el jerrquico. Estos dos
ltimos actualmente en desuso. En cambio, el
modelo relacional es. hoy en da, el ms extendido
y aceptado universalmente. A l se harn
referencias seguidas porque en la actualidad,
como ya se dijo, las metodologas de diseo lgico
de bases de datos combinan al modelo entidad
interrelacin para hallar un esquema conceptual y
luego, en forma algortmica se pasa al modelo de
datos relacional, este ltimo paso en la actualidad
se puede realizar con herramientas CASE. En el
tem 2 se presenta con ms detalle una
metodologa de este tipo.
No existen, al da de hoy, productos
comerciales sustentados puramente en modelos
de datos conceptuales. En cambio, los modelos
lgicos tienen mltiples versiones comerciales. La
razn de esta discrepancia es, segn el autor, la
falta de una base slida para los modelos
semnticos, a diferencia del modelo relacional que
est sustentado por modelos matemticos. No
obstante, de la misma forma en que se us el
modelo relacional para el diseo lgico de bases
de datos antes de que apareciera el primer
producto comercial sustentado por ese modelo,
hoy en da, se usa al modelo entidad interrelacin
como parte de una metodologa para el diseo
lgico de bases de datos.
Por ltimo, los modelos fsicos pretenden
representar cmo se almacenan los datos
6

fsicamente. Es el nivel ms bajo de abstraccin y

no nos ocuparemos de ellos.
 7

1. DEFINICION FORMAL DE UN
MODELO DE DATOS
Un modelo de datos es un objeto formado
por tres componentes:
Estructuras de datos lgicas
Operadores lgicos
Reglas de integridad
Las estructuras lgicas se usan para
representar los datos. Los operadores lgicos
permiten navegar lgicamente a travs de las
estructuras y manipular los datos. Por ltimo las
reglas de integridad son las que permiten
mantener la consistencia de los datos dentro del
modelo.
Es importante y tal vez prematuro a esta
altura, ver al modelo de datos en si, como a un
solo objeto, tal como se lo dio en la definicin. El
lector que est familiarizado con la terminologa de
objetos, vera que existe una similitud entre las
reglas de integridad de los modelos de datos y los
mtodos o funciones de los Objetos. En tal sentido
se puede interpretar al modelo como a un objeto; y
a los operadores y reglas de integridad como sus
mtodos. Por ltimo las consultas y distintos tipos
de operaciones sern los mensajes.
8

2. UNA METODOLOGA PARA EL.

DISEO LGICO DE BASES DE
DATOS
Como se mencion en el comienzo de esta
seccin, la aplicacin ms frecuente y extendida
del modelado semntico utilizando el modelo
entidad interrelacin, esta dado en el diseo lgico
de bases de datos. El gran poder expresivo que
tiene dicho modelo y en especial el diagrama que
lo simboliza son determinantes en su aceptacin
universal. Gracias a l, es posible expresar en un
pequeo grfico lo que demandara varias pginas
de aburrida narrativa.
En la lmina 1 en la primer columna, se
muestra los cuatro pasos de una metodologa para
el diseo de bases de datos. Cada una de ellas
produce un resultado que se muestra en la
columna central. En la tercer columna se muestra
algunos ejemplos de lo que se puede encontrar,
en los respectivos esquemas, para algn caso
particular.
La primera etapa es el relevamiento o
anlisis de requerimientos, esto incluye determinar
los lmites del problema a modelar (alcance del
sistema), las visiones que los usuarios tendrn del
modelo (visiones de usuario) y en general
cualquier idea o definicin que ayude a definir
mejor el problema. El resultado de esta primera
etapa se la llama esquema descriptivo.
El segundo paso es el modelado
semntico, para ello se utiliza alguna herramienta
 9

apropiada, como ser el modelo entidad

interrelacin. El resultado de esta segunda etapa
se la llama esquema conceptual de los datos y
debe ser una fiel representacin de la realidad que
se quiere modelar. Los ejemplos que se dan en la
lmina 1 sobre lo que se puede encontrar en este
esquema, se corresponden para el caso de utilizar
el modelo entidad interrelacin.
El tercer paso es el diseo lgico y el
objetivo es obtener un esquema lgico de los
datos, es decir, un modelo donde se puedan
definir lgicamente los significados (semntica) de
las palabras del lenguaje natural y otras
construcciones empleadas en el esquema
conceptual. Luego se debe normalizar ese modelo
lgico, es decir, darle cierta redundancia y
complejidad. Este paso de normalizacin no se lo
muestra en la lmina y no se lo tratar en el
presente libro, pero en general, con la metodologa
propuesta se puede obtener esquemas con un alto
grado de normalizacin. En la lmina 1, los
ejemplos dados sobre lo que se puede encontrar
en este esquema, se corresponden para el caso
en que se utilice el modelo relacional.
Por ltimo, y fuera del diseo lgico, se
tiene el diseo fsico y afinamiento (tuning) de la
base de datos que tampoco se tratar.
Los pasos descriptos no son
necesariamente secuenciales, como lo indican las
dobles flechas del dibujo. Se puede iterar entre
distintas acciones, por ejemplo, del modelado
conceptual puedo volver al relevamiento varias
veces hasta que obtenga una buena y completa
10

especificacin del problema. Lo mismo puede

darse entre cualquier etapa y su etapa inmediata
superior.
Por ltimo, note que el modelado empieza
en un esquema descriptivo o modelo conceptual y
no en el mundo real como generalmente se cree.
La explicacin de esto tiene ms que ver con el
aspecto psicolgico y es la fuente de mayores
errores cometidos en la etapa del anlisis. Es que
en verdad, no se modela al mundo real
directamente (del cual no podran ser errores) sino
que se modela lo que uno entendi de ella, lo que
uno pudo captar de esa realidad. Se modela soto
lo que se pudo hacer consciente.
Una condicin que debe tenerse en cuenta
al utilizar los distilitos modelos de datos es la de no
solaparse con los niveles de abstraccin inferiores
al que se definen. Por ejemplo, el modelo
relacional es un modelo de datos lgico y nada
tiene que decir sobre el nivel fsico. De la misma
manera. el modelado semntico debe ser
independiente del modelo lgico a utilizar. Aunque
al parecer, como se ver, los que prohben el uso
de los atributos multivaluados en el modelo
entidad interrelacin no opinan as.
En los captulos II y tu se ver el modelo
entidad interrelacin y su representacin grfica,
que permitir obtener el esquema conceptual de la
base de datos y en particular, en algunos casos,
se ver como pasarla al modelo relacional para
obtener un modelo lgico de la base de datos.
Nuevamente, se repite que el lector que no est
 11

familiarizado con el modelo relacional podr

saltear esas referencias.
12

Lmina 1 La primera columna muestra las

sucesivas etapas del diseo de bases de datos en
una metodologa propuesta. La segunda columna
esta correlacionada con la primera y muestra el
resultado de cada etapa. La tercer columna
muestra algunos ejemplos de lo que se puede
tener en cada etapa o nivel de abstraccin del
problema. Las flechas indican la E/S para cada
accin a realizar.
 13

CAPTULO 2
MODELO ENTIDAD INTERRELACIN

1. INTRODUCCIN
Este modelo fue propuesto por Chen en
1975 y es lo que hoy se conoce como el modelo
entidad interrelacin bsico. Posteriormente
distintos autores le fueron agregando nuevos
conceptos tratando de dotarlo de mayor poder
expresivo culminando en la actualidad en el
Modelo Entidad lnterrelacin extendido.
El Modelo Entidad-Interrelacin se usa
actualmente como una herramienta de diseo
conceptual. es decir, para modelar los datos del
mundo real y crear un Esquema Conceptual del
mismo. Este Esquema Conceptual debe ser una
fiel representacin de los datos del mundo real.
Para las personas familiarizadas con las
metodologas estructuradas del anlisis, es bueno
recalcar que con el Modelo Entidad-Interrelacin
slo se representa a : los datos , las relaciones
que existen entre ellos y algunas limitantes o
reglas de integridad que ms adelante
analizaremos. Por lo anterior queda claro que no
se representan en forma directa a los procesos,
para lo cual se puede utilizar el conocido diagrama
de flujo de datos (DFD). Sin embargo, existen
ciertas clases de procesos. que el autor llama
procesos primitivos que s se los puede incorporar
al modelo de Datos en forma implcita. Ejemplos
14

de estos procesos son las altas, bajas, y

modificaciones a cualquier informacin de nuestro
modelo; los listados y formularios tambin son otra
variante de esos procesos primitivos. Por ltimo,
cada una de las reglas de integridad, explicita
alguna clase de proceso primitivo que tambin
queda dentro del Modelo de Datos. Estas
apreciaciones sobre los procesos primitivos
tambin son apropiadas para el Modelo Relacional
Actualmente una gran variedad de
simbologas son de uso frecuente. Por razones
que sern explicadas, se utilizar una unin de la
simbologa de Chen para las construcciones
bsicas con agregados de otras para las
construcciones extendidas. En particular se usar
la simbologa, algo modificada, de Theorey-Yang
para las interrelaciones ternarias.
Al Modelo Entidad Interrelacin se lo suele
abreviar con sus siglas en ingls MER (Model
Entity Relationship) y al diagrama utilizado para
representarlo grficamente como DER (Diagram
Entity Relationship). Desafortunadamente en
muchos casos se tradujo al castellano como
modelo entidad relacin y diagrama entidad
relacin. Lo que trajo cierta confusin al mundo
informtico de habla hispana, es que el significado
de la palabra relacin en el contexto del MER no
tiene nada en comn con el significado de relacin
en la terminologa del modelo relacional MR
(Model Relation). En la terminologa del MER una
interrelacin (Relationship), segn la propia
definicin dada por Chen, es una asociacin entre
dos o ms entidades; mientras que en la
 15

terminologa del MR una relacin (relation), tiene

su nico y preciso significado matemtico. A saber
un subconjunto de un producto cartesiano de
dominios.
El modelado de los datos a travs de
entidades es un ejemplo de metodologa Top
down. Permite realizar una abstraccin de los
datos en entidades y con ello disminuir, en gran
medida, la cantidad de datos a considerar. No
obstante y como mrito adicional para el modelo
entidad interrelacin tambin se lo puede utilizar
como una metodologa hbrida; es decir, que
combine a la anterior con una bottom up, ambas
a la vez. Esto ltimo se lo puede entender bien
conociendo la teora de las dependencias
funcionales.
Seguidamente se explicar los objetos que
componen el MER bsico y paralelamente se ver
su representacin en el diagrama que lo simboliza
(DER). En el captulo siguiente se ver algunos de
los objetos que componen el MER extendido y su
paso al MR.

2. OBJETOS DEL MER BSICO

El modelo entidad interrelacin bsico de
Chen tiene tres conceptos fundamentales:
Entidades, atributos e interrelaciones. A
continuacin explicaremos a cada uno de ellos
junto a todos los dems objetos que maneja dicho
Modelo.
16

2.1 ENTIDADES
Las Entidades son objetos que existen en
el mundo real y sobre los cuales se tiene algn
inters por observar. Ejemplos de una entidad son:
el Departamento de Compras de una empresa, el
alumno cuya libreta universitaria es la nmero
1010 o la carrera de informtica dentro de una
Universidad.
Dos entidades son del mismo tipo si tienen
las mismas propiedades y la misma semntica.
Esto vuelve a verse en el tem 2.2, donde se trata
los atributos de una interrelacin, pero por ahora
slo basta con entender que tas propiedades de
una entidad son las caractersticas que posee y la
semntica de una relacin es el significado que se
le da en el mundo real.
El modelado de los datos a travs de
Entidades no es una ciencia exacta. Lejos de ello,
es una tarea donde el conocimiento emprico o el
buen sentido sigue siendo prioritario.
Es importante darse cuenta que cuando se
enfrenta a un mundo real dispuesto a modelarlo,
las entidades ya existen, solo se las tiene que
encontrar. Es por ello que al da de hoy, esta
etapa, tiene algo de arte. Como ayuda para
descubrirlas es bueno siempre reparar en todos
los sustantivos que fueron conceptualizados del
problema y entre ellos seguro que se encontrarn
a las entidades apropiadas.
Cada entidad est unvocamente
identificada; ms adelante se ver de qu manera
se consigue esto. A las entidades se las nombra
 17

siempre, por razones obvias, en singular y

mediante un sustantivo. En los ejemplos dados
sera: departamento, alumno y carrera.

2.1.1 CONJUNTO DE ENTIDADES

Las Entidades de un mismo tipo se
agrupan en conjuntos de entidades, es decir, un
conjunto de entidades est formado por entidades
del mismo tipo. El concepto de tipo es anlogo a
los tipos de datos en los lenguajes de
programacin.
En un conjunto no puede tenerse
elementos repetidos, por lo tanto en un conjunto
de entidades no podr haber entidades repetidas.
A los elementos pertenecientes a un
conjunto de entidades se lo llama Instancia de
ese conjunto.
Es frecuente, en la prctica, que los dos
trminos: conjunto de entidades y entidad se
confundan y se los trate indistintamente, sin
embargo, para un buen entendimiento del modelo
debe tenerse claro los dos conceptos.
En trminos de la programacin procedural,
una entidad sera una variable, mientras que un
conjunto de entidades es un tipo de datos. En
trminos de la programacin orientada a objetos,
una entidad es un objeto y un conjunto de
entidades es una clase.
El smbolo usado para indicar a un conjunto
de entidades es el rectngulo poniendo el nombre
18

del tipo de entidad que contiene en el centro del

mismo. Ver Lmina II a)
Al pasar el DER al Modelo Relacional cada
conjunto de entidad pasa a ser una relacin
(tabla).

Lmina II. Simbologa bsica del DER

 19

2.2 ATRIBUTOS
Se llama atributo a cada uno de los
descriptores de las entidades o interrelaciones.
Ejemplos de atributos son: el nombre de la
materia, direccin del alumno, nmero de libreta
universitaria. Los dos primeros ejemplos son
atributos de la entidad MATERIA y los dos ltimos
son ejemplos de atributos de la entidad ALUMNO.
El smbolo usado para indicar un atributo
es un valo unido por una lnea a la entidad o
interrelacin que describe. En el centro del valo
se coloca el nombre del atributo. Ver Lmina II c).
Muchas veces para dar mayor simplicidad
al diagrama se omiten los atributos pero, sin
embargo, para que no pierda una importante parte
de su semntica es imprescindible que al menos
se indique en el diagrama a los atributos
principales de cada entidad.
Un atributo se dice que es principal si
pertenece a algn identificador nico y ser
secundario en caso contrario. En el tem siguiente
se explica este concepto.

2.2.1 IDENTIFCADOR NICO

Un identificador nico es un conjunto de
atributos (formado por uno o ms atributos) que
sirven para identificar unvocamente a cada
entidad del mismo tipo (del mismo conjunto de
entidades). Por ejemplo, para las entidades
ALUMNO y CARRERA los posibles identificadores
nicos son: numero de libreta universitaria y
nombre de la carrera respectivamente. Siempre
20

dos entidades del mismo tipo estarn

diferenciadas al menos por el valor que tomen sus
identificadores nicos.
Si para una entidad existe ms de un
identificador nico, slo se indica a uno de ellos.
Por ejemplo, en la entidad ALUMNO otro
identificador posible hubiese sido tipo y nmero de
documento. En el diagrama se indica solo a uno
de los dos; se elige en lo posible al ms
significativo.
Los identificadores nicos del MER pasan a
ser las claves primarias en el modelo relacional,
mientras que los dems identificadores nicos (si
los hay) pasan a ser claves candidatas en dicho
modelo.
El smbolo usado para indicar a un
identificador nico es el mismo utilizado para los
atributos pero en este caso adems se lo subraya.
Ver Lmina II d).

2.2.2 ATRIBUTOS MULTIVALUADOS

Muchas veces en el proceso de modelado
se encuentra que algn descriptor de una entidad
puede tener varios valores posibles para la misma
entidad. A diferencia de los otros atributos, tienen
una secuencia de ocurrencias posibles para una
misma entidad. Por esa razn se los llama
atributos multivaluados o no atmicos o multivalor
o grupo repetitivo. Este ltimo trmino, es usado
tambin con frecuencia cuando los atributos
multivaluados se dan en grupo de uno o ms
atributos a la vez. Un ejemplo de atributo
 21

multivaluado puede darse en la entidad

PROVEEDOR para el caso de que tenga
direcciones (suponga un proveedor importante).
Ver figura 1 a).
Obsrvese bien la diferencia entre los
atributos multivaluados y los otros (atmicos); a
cada entidad PROVEEDOR (suponga el proveedor
10), le corresponde un solo nombre, un solo CUIT,
pero (y aqu esta la diferencia) varias direcciones.
Otro ejemplo de atributo multivaluado es para la
entidad EMPLEADO donde algunos de sus
descriptores son: nombre del empleado, direccin
y nombre de los hijos; se ve que los primeros
atributos son atmicos para cada empleado
mientras que el ltimo atributo es multivalor
Algunas simbologas permiten representar
a los grupos multivaluados en el DER, otras no. El
autor propone a stos como un paso previo a la
representacin final del modelo, es decir, como un
borrador (a veces muy til ), previo al modelado
final. Esta decisin se debe principalmente al
objetivo final del modelado con el DER que en
general es (en la actualidad) obtener un Modelo de
datos Relacional y en dicho modelo no se permiten
tales atributos. Sin embargo, esto puede reverse
cuando el objetivo del modelo no est fijo an o,
en el mejor de los casos, cuando sea un Modelo
de Listas Invertidas o un modelo post-relacional en
el cual se permiten representen a los grupos
repetitivos.
Es opinin del autor que el uso de atributos
multivaluados ayuda a la abstraccin de los datos
22

y permite en una primera instancia reducir el

nmero de conjuntos de entidades a considerar.
En la Lmina II e) se muestra cmo se
representa a los atributos multivalor y en las
figuras 1 a) y b) se dan dos ejemplos. Obsrvese
que el grupo repetitivo datos_del_hijo es en
realidad una entidad (HIJO) anidada dentro de
EMPLEADO.

Figura 1. Ejemplo de distintos tipos de atributos

para las entidades PROVEEDOR y EMPLEADO

Siempre, a todo atributo repetitivo en un

DER. se lo puede eliminar buscando otro DER
equivalente. En el tem 4 del presente capitulo se
ver este procedimiento.
 23

2.2.3 ATRIBUTOS DERIVABLES

A veces, resulta til poder representar a
determinados atributos, cuyas instancias estn en
funcin de otros atributos de la misma entidad. Es
decir, que son atributos prescindibles y cuya
inclusin en el DER puede deberse tanto a mejorar
la representacin del mundo real, que se est
modelando, como para respetar trminos
amigables y/o familiares del usuario final. Un
ejemplo es el atributo edad de la entidad
EMPLEADO. Es claro, que su valor se calcula a
partir del atributo fecha_de_nacimiento. Otro caso
distinto, es cuando el valor del atributo derivable o
recalculable, se obtiene a partir de valores de
atributos de entidades pertenecientes a otro
conjunto de entidades o interrelaciones. Ejemplo
de este ltimo caso es el atributo importe_total de
la entidad FACTURA el mismo se calcula
sumando los importes parciales de cada tem de la
factura.
En general, no es recomendable abusar de
la utilizacin de esta clase de atributos , pues le
quitan simplicidad al DER. En la lmina II f) se
muestra el smbolo utilizado para, representar a un
atributo recalculable y en la figura 1 b) se muestra
un ejemplo con distintas clases de atributos.

2.3 INTERRELACIONES
Las interrelaciones son objetos que
representan la asociacin entre dos o ms
entidades. Una interrelacin no puede existir si no
existen previamente las entidades que est
interrelacionando. Ejemplos de interrelaciones son,
24

en general, los eventos. Suponga las dos

entidades ALUMNO y CURSO, dos eventos
relacionados con estas entidades podran ser
inscribirse y aprobar un curso. Queda claro que
para que suceda cualquiera de los dos eventos es
necesario la existencia previa de por lo menos una
entidad alumno y otra entidad curso. Una
caracterstica de los eventos es que una vez que
suceden nunca ms pueden cambiar, a diferencia
de las entidades que pueden sufrir cambios. Para
ver esto ms claramente suponga otra vez el
ejemplo anterior, una entidad alumno puede
cambiar alguna de sus caractersticas, como ser,
su direccin, telfono ,estado civil, etctera. La
entidad CURSO puede sufrir cambios en el
programa analtico, duracin, etctera. En cambio
en el evento aprobar un curso, una vez sucedido,
ninguna de las caractersticas que lo describen
puede cambiar ; a cada alumno le corresponder
una fecha y nota imposible de modificar.
No todas las interrelaciones
correspondern a eventos, ni tampoco viceversa ;
por ejemplo, una empresa puede tener
organizacin departamental y a su vez estos
departamentos se dividen en oficinas. En este
contexto, se tiene que entre las entidades
departamento y oficina existe interrelacin de
pertenencia ; pertenece a.
Las interrelaciones pueden asociar
entidades del mismo o distinto tipo.
A las interrelaciones se las debe nombrar
en lo posible con un verbo seguido de una
 25

preposicin, en los ejemplos dados sera: se

inscribi en y aprob un.

2.3.1 CONJUNTO DE
INTERRELACIONES
A las interrelaciones de un mismo tipo se
las agrupa en conjuntos de interrelaciones,
anlogamente como se hizo con las entidades.
Cada conjunto de interrelaciones puede contener
solo interrelaciones del mismo tipo.
Instancia de una interrelacin se llama a
todos los elementos pertenecientes a un conjunto
de interrelacin. Por el mismo motivo que para los
conjuntos de entidades, no podr haber elementos
repetidos dentro del mismo conjunto de
interrelaciones.
El smbolo utilizado para denotar a un
conjunto de interrelaciones es un rombo con el
nombre del tipo de interrelacin que contiene en el
centro de la figura. Ver Lmina II b). En la figura 2
a) y b) se grafican los ejemplos dados.
Entre dos entidades puede existir ms de
un tipo de interrelacin, pero siempre con distinta
semntica. Ver figura 3.
26
 27

2.3.2 GRADO DE UNA

INTERRELACIN
A la cantidad de tipos de entidades que
asocia una interrelacin se lo llama grado de una
interrelacin. Si la interrelacin asocia uno, dos o
tres tipos de entidades se la llama interrelacin de
grado uno, dos y tres respectivamente. Dicho de
otro modo se tiene:
Si la interrelacin asocia
entidades de un mismo conjunto de
Entidades se llama interrelacin de grado
uno o unarias (Ver lmina III a)).
Si la interrelacin asocia
entidades de dos conjuntos de Entidades
se llama interrelacin de
grado dos o binarias. Este es el caso ms
comn (Ver lmina III b)).
Si la interrelacin asocia
entidades pertenecientes a tres, Conjuntos
de Entidades se llama interrelacin de
grado tres o ternarias. Es el caso menos
frecuente (Ver lmina III c) ).
Otros tipos de interrelaciones en la prctica
no se dan, aunque se puede generalizar para
grados mayores a tres.
Existen casos, muy poco frecuentes, en
que una interrelacin de grado dos puede
interrelacionar a tres entidades (obviamente dos
de ellas del mismo tipo). Si esto le resulta confuso
recuerde la diferencia que hay entre una entidad y
un conjunto de entidades. El grafo de este caso se
28

da en la figura 4. El autor desconoce un trmino

especfico para este caso poco frecuente.
29
30

En general, el diseador debe evitar, en lo

posible, el uso de interrelaciones de grado tres o
mayor. En su lugar debe probar de reemplazarlas
por dos o tres interrelaciones de grado dos. Solo
deben quedar cuando su reemplazo por
interrelaciones binarias no sea una exacta
representacin del mundo real.
A diferencia de las interrelaciones de grado
uno y dos, la interpretacin de una interrelacin de
grado tres no es para nada trivial, como se ver en
el tem 1 del captulo 3. Debe tenerse en cuenta
que, en general, est fuera del alcance de
comprensin de un usuario final y su inclusin o
no, merece un esfuerzo extra en el anlisis del
modelo.

2.3.3 ATRIBUTOS DE UNA

INTERRELACIN
Las interrelaciones pueden tener atributos
propios, es decir, atributos que no pertenecen a
ninguna de las entidades que esta
interrelacionando. Por ejemplo, la interrelacin
Inscripto en que asocia a las entidades alumno y
puede tener el atributo propio fecha de
inscripcin. Ver figura 5.
 31

Como por definicin una interrelacin es

una asociacin entre dos o ms entidades, resulta
evidente que la forma de lograr esto, sea tomando
solo los identificadores nicos de las entidades
que interrelaciona. A estos atributos se tos llama
externos o forneos y no se los representa en el
DER por resultar obvio su existencia.
Por lo expuesto, si se tiene a una
interrelacin I y sean El y E2 las entidades que
asocia, los atributos de I son: Id_El, Id_E2 y
atributos propios (si los tiene), donde los dos
primeros son los atributos identificadores nicos
de E1 y E2 respectivamente.

2.3.4 IDENTIFICADORES NICOS DE

UNA INTERRELACIN
Si se toma a las interrelaciones que
involucran solamente a dos entidades El y E2,
(otros casos se vern en el capitulo 3) siendo idE1
e idE2 respectivos identificadores nicos. Se
puede tipificar los casos posibles de la siguiente
manera:
32

1. Si la interrelacin no posee atributos

propios los casos posibles son:
a. El identificador nico es la unin de
los identificadores nicos de El y
E2.
b. El identificador nico es el
identificador nico de una de las
dos entidades (cualquiera de las
dos)
c. Ambos idE1 e idE2 son
Identificadores nicos.
2. Si la interrelacin tiene atributos propios los
casos posibles son:
a. dem caso 1.1
b. El identificador nico est formado
por la unin del atributo propio ms
los dos atributos externos.
c. El identificador nico es el atributo
propio.
Para ejemplificar el caso 2.a suponga el
mismo ejemplo dado en la figura 5. Si se tiene que
un alumno puede inscribirse varias veces al mismo
curso (en distintas fechas, suponga alumnos
recursantes) se nota que para identificar
unvocamente a cada ocurrencia de la interrelacin
se necesitan los tres atributos a la vez. Si al mismo
ejemplo le agregamos que en el momento de
inscripcin en cada curso, se le da al alumno un
nmero de inscripto, es decir, las inscripciones
estn numeradas secuencialmente, este atributo
propio pasa a ser un identificador nico (caso 2.b).
 33

Los otros tres casos quedan bien

determinados segn el tipo de vinculacin
existente entre las dos entidades. Esto se ver en
el tem siguiente.

2.4 CARDINALIDAD DE UNA

INTERRELACIN
Los elementos que pertenecen a un
conjunto de interrelacin pueden estar limitados
por determinadas visiones de contexto del
problema que se quiere modelar. A una de estas
limitantes se la llama cardinalidad de la
interrelacin.
Por ejemplo, suponiendo que se tiene a las
entidades ALUMNO y CARRERA; una
interrelacin posible entre estas entidades es
Inscripto en. Una visin de contexto del problema
a modelar es si se permite o no, que un alumno
curse dos carreras simultneamente. El
reglamento de la Universidad es quien en
definitiva, impone esa visin de contexto. En el
caso que el alumno pueda cursar ms de una
carrera simultneamente, el conjunto de
interrelaciones Inscripto en no tendr ninguna
limitante. En efecto, cada alumno podr cursar
cualquier carrera y a su vez cada carrera podr
tener muchos alumnos, es decir, cualquier
instancia ser legal.
En cambio, e! segundo caso que se puede
dar es que un alumno pueda cursar solo una
carrera (esto es por visin de contexto). Los
elementos que pueden estar en la interrelacin
van a estar limitados. La limitante est dada en
34

que no puede existir dos carreras distintas con el

mismo alumno. Es decir, no se permite que una
interrelacin tenga el mismo valor de libreta ya
existente en alguna otra interrelacin del mismo
conjunto. Esto ltimo significa que el identificador
nico de la interrelacin, para este caso, es el
nmero de libreta. Las interrelaciones posibles
quedaron limitadas a un subconjunto de las
instancias permitidas en el primer caso.
Se vio cmo las visiones de contexto
imponen determinadas limitantes a los conjuntos
de interrelaciones legales. A estas clases de
limitantes en el modelo Entidad-lnterrelacin se las
llama cardinalidad de una lnterrelacin.
Ahora se tipificar las cardinalidades
posibles. En primer lugar se estudiarn las
cardinalidades en las interrelaciones de grado dos,
continuando con las de grado uno y por ltimo las
de grado tres. Otros casos, como ya se dijo, son
muy raros que se den en la prctica, pero de igual
manera se puede generalizar fcilmente para
casos mayores a tres.

2.4.1 CARDINALIDAD EN
INTERRELACIONES BINARIAS
CASO n:m Para interrelaciones binarias
Considrese en forma abstracta dos
conjuntos A y C (ver figura 6). Puede verse que un
elemento del primer conjunto (A) est
interrelacionado con uno o varios elementos del
segundo (C) y viceversa, un elemento del segundo
 35

conjunto (C) est interrelacionado con uno o ms

de uno elementos de A.
Como ejemplo concreto tome nuevamente
a los dos conjuntos de entidades ALUMNO y
CURSO.

Suponga que un alumno puede cursar

cualquier cantidad de CURSOS. Se observa que
un ALUMNO puede estar inscripto en m cursos,
mientras que en un curso pueden inscribirse n
alumnos, donde n y m son nmeros enteros
mayores o iguales a uno. En la Lmina IV a) se
muestra el smbolo grfico para el caso n:m. En la
figura 5 se mostr la representacin grfica del
ejemplo dado, pero ahora est en condiciones de
leer en el que su interrelacin es del tipo n:m. El
caso en que n o m sea iguales a cero se tratar
enseguida.
En la tabla 4.1 se muestra la instancia de la
interrelacin que le corresponde al ejemplo dado
en la figura 5.
36

A este tipo de cardinalidad se la llama n:m

y se lee n a m; su significado se lo expresa de la
siguiente manera un alumno se interrelaciona con
uno o varios cursos y viceversa (un CURSO se
interrelaciona Con uno o vanos ALUMNOS).
A veces a las interrelaciones. con
cardinalidad 1 :n y n:m se las conoce con el
nombre uno a muchos y muchos a muchos
respectivamente. El autor prefiere no usar estas
denominaciones por lo inapropiado de la palabra
muchos para el caso de significar una o dos
entidades solamente.
Un error frecuente en la asignacin de las
cardinalidades n:m se da cuando un inexperto
diseador la lee de la siguiente manera (se utiliza
el mismo ejemplo): muchos alumnos se
interrelacionan con muchos cursos. Obsrvese
que tal afirmacin siempre es verdadera, an
cuando se trate de cardinalidades 1:1 o 1 :n
(vase ms adelante en esta misma seccin), por
lo tanto, tal afirmacin no puede servir para nada.
El problema semntico est marcado en negrita y
se lo resuelve si se lo reemplaza por un alumno es
 37

decir, siempre se debe analizar la cardinalidad

partiendo de una entidad.
La determinacin del identificador en este
caso es inmediata, se puede observar en la tabla
4.1 que ninguno de dos atributos alcanza por si
solo a ser identificador nico cada interrelacin. En
efecto, si toma el atributo numero_libreta se tiene
dos instancias distintas para el valor.
Anlogamente si se toma el atributo nombre_curso
tampoco sirve para identificar unvocamente a
cada ocurrencia pues C4 est en dos ocurrencias
distintas. Por lo tanto el identificador nico es la
unin de los das atributos.
Este tipo de interrelacin (n : m) pasa al
modelo relacional como una nueva tabla. El
identificador nico, como siempre, pasa como
clave primaria, y al mismo tiempo cada atributo no
propio pasa como clave fornea.

Vinculacin mandatoria u opcional

En el ejemplo anterior, puede suceder que
exista algn alumno no se inscriba en ningn
curso. En tal caso quedara por lo menos un
alumno sin relacionarse con ningn curso. Esto
seria el caso en que el n del lado de curso fuera
igual a cero. Si la opcin ninguna (o nula) puede
suceder en el mundo real que se quiere modelar,
se dice que la vinculacin es opcional. Si por el
contrario, la vinculacin entre una entidad y la otra
es completa se dice que es mandatoria. La opcin
ninguna se puede dar con todas las variantes; de
cualquiera de los dos lados o de ambos El smbolo
utilizado para representar la vinculacin opcional
38

es un circulito del lado en que n puede valer cero.

Ver lmina 1V e). La omisin del circulito en
ambos lados de la interrelacin significa que la
vinculacin entre las dos entidades es
completa.
Para el ejemplo anterior, parece ser ms
real si se pone la opcin nula de ambos lados
como se muestra en la figura 7. Esto ltimo en
razn de que pueden existir alumnos que no
cursen nada en algn momento dado y mirando
del otro lado puede darse que un curso no tenga
ningn alumno inscripto (el caso de un curso
nuevo recin abierto).
39
40

CASO 1:n Para interrelaciones binarias

Anlogamente el caso anterior se estudia
en el caso 1:n.
Considrese en forma abstracta dos
conjuntos D y O (ver figura 8). Puede verse que
un elemento del primer conjunto (D) est
interrelacionado con uno o varios elementos del
segundo (O), mientras que un elemento del
segundo conjunto (O) est interrelacionado con un
solo elemento de (D).

Como ejemplo concreto se retomar el

visto en el tem 3, con los dos conjuntos de
entidades DEPARTAMENTO y OFICINA, y la
interrelacin PERTENECE A. En este caso se
quiere modelar el hecho de que una oficina
pertenece a un solo departamento y un
departamento puede tener vanas oficinas.
El smbolo utilizado para este tipo de
cardinalidad se muestra en la lmina IV b) y c) y
 41

se da un ejemplo en la figura 2 b). Observe que a

la lnea que une la entidad con la interrelacin se
le ha agregado una flecha del lado de uno y
queda igual del lado de muchos. Por existir una
gran variedad de simbologas el autor sugiere
rotular siempre el tipo de cardinalidad como se
muestra en la figura 7.
A este tipo de cardinalidad se la llama 1 :n
y se lee uno a n. Su interpretacin es: un
elemento (una entidad) del conjunto de entidades
DEPARTAMENTO se interrelaciona con uno o
varios elementos del conjunto de entidades
OFICINA (el n significa uno o ms de uno) y visto
en el otro sentido, una oficina pertenece a
solamente un departamento.
En la tabla 4.2 se muestra la instancia de la
interrelacin para el ejemplo dado en 1a figura 8.
Siempre que se tenga un atributo propio en
la interrelacin se lo puede desplazar a la entidad
que est del lado n.
42

Nuevamente aqu se puede dar el caso

ninguno u opcional en cualquiera de sus
combinaciones: de un lado, del otro o de ambos a
la vez. Sin embargo, para ste ejemplo, parecera
que es mejor dejarlo como mandatorio en ambos
sentidos.
Un caso particular, muy frecuente en la
prctica, de interrelacin 1 :n obligatoria del lado
uno, es la conocida con el nombre es un (is a en
ingls). En la figura 9 se da un ejemplo. La misma
quiere decir que todo becario es un alumno pero
no todo alumno es becario. En el tem 2 del
segundo captulo donde se trata jerarquas se ver
con ms detalle casos ms generales.
 43

CASO 1:1 Para Interrelaciones binarias

Anlogamente se estudia el caso 1:1 donde
un elemento del conjunto D se relaciona con un
solo elemento del conjunto S y viceversa (un
elemento del conjunto S se relaciona con un solo
elemento del conjunto O) (Ver figura 10). En la
tabla 4.3 se dio una instancia de la interrelacin
para el caso de la figura 9.

Por ejemplo, suponga que una empresa

maneja varios proyectos y cada uno de ellos est
dirigido por un solo supervisor. A su vez, cada
supervisor puede supervisar a lo sumo un
proyecto.
Como siempre se tiene la opcin ninguna
que podr estar ausente, de un solo lado o de
ambos lados, segn sea el caso que se desee
modelar. En el ejemplo, podemos suponer que es
mandatoria de ambos lados (Ver figura 11).
44

Este tipo de cardinalidad es denotada 1:1 y

se lee uno a uno. Su significado es: una entidad
del conjunto de entidades SUPERVISOR se
interrelaciona solamente con una entidad del
conjunto de entidades PROYECTO y viceversa.
En este caso se observa que cualquiera de los
dos atributos puede ser identificador nico. Al
pasarlo al modelo relacional se elige a cualquiera
de los dos como clave primaria y al otro se lo deja
como clave candidata.
 45

2.4.2 CARDINALIDAD DE LAS

INTERRELACIONES UNARIAS
Este caso es similar al de las
interrelaciones de grado dos; las posibles
restricciones de cardinalidades son las mismas a
excepcin de la opcin nula que en algn caso
como se ver no pueden existir por carecer de
sentido. A continuacin solo se dan ejemplos.

CASO n:m Para interrelaciones unarias

Suponga que est diseando una base de
datos geogrfica donde le interesa llevar la
informacin de todos los pases y para cada uno
de ellos, cules son sus pases limtrofes. Un pas
puede estar limitado por uno o ms pases o
ninguno, por lo tanto se tiene una interrelacin de
grado uno entre las entidades pas con una
cardinalidad n:m con opcin nula. Ver figura 12.
46

Obsrvese que en dicha figura existe una

simetra entre las interrelaciones ( si P1 limita con
P2 y P3, entonces P2 y P3 tambin limitan con
P1). En este caso seria absurdo poner opcional de
un lado solo. Por esa simetra siempre que exista
la opcin nula en una interrelacin unaria del tipo
n:m la misma deber estar de los dos lados.
Los atributos de una interrelacin unaria
sern como siempre los atributos propios (si los
tiene) ms los identificadores de las entidades que
 47

interrelaciona. Pero como en este caso ambos

tienen el mismo nombre, a uno de los dos se lo
renombra. Esto se aplica tambin para los dos
casos siguientes.

CASO 1:n Para Interrelaciones unarias

Este caso es comn cuando existe una
jerarqua entre los miembros de un tipo de entidad.
Por ejemplo, en el conjunto de entidades
EMPLEADO, es posible que cada empleado
dependa jerrquicamente de otro empleado, a su
vez, visto en sentido contrario un empleado tendr
otros varios empleados a cargo (Ver figura 14)
observe la opcin nula; en este contexto quiere
decir que habr empleados que no tienen personal
a cargo.

CASO1:1 Para interrelaciones unarias

Por ejemplo a una Institucin bancaria le
puede resultar interesante llevar e1 control de los
empleados que son cnyuge de otro empleado,
pues, de ser as, por razones de seguridad, no
pueden trabajar juntos en la misma sucursal; en
este caso se puede modelar una interrelacin
48

unaria entre las entidades empleados. A esta

interrelacin unaria se la puede llamar
apropiadamente casado con como se muestra en
la figura 15. Obsrvese como se colocaron las
opciones nulas; es mas real representar el hecho
de empleados a los que no les corresponde
ningn otro empleado como cnyuge.
 49

3. ELIMINACIN DE
lNTERRELAClONES REDUNDANTES
En la etapa de modelado con el modelo
entidad interrelacin puede suceder que queden
interrelaciones redundantes. Un caso particular
bien definido, son las llamadas interrelaciones
transitivas. Ver el ejemplo presentado en la figura
18. El mismo representa la siguiente realidad : un
departamento tiene muchas oficinas y cada oficina
pertenece a un solo departamento, a su vez cada
oficina tiene muchos empleados y cada uno de
ellos trabaja en una sola oficina. Por otro lado en
cada departamento trabajan muchos empleados y
cada empleado trabaja en un solo departamento.
Puede observarse que la ltima interrelacin es
redundante. En efecto, si se elimina la interrelacin
es de, de igual manera se puede saber en qu
departamento trabaja cada empleado. Esto es por
la interrelacin trabaja en, que por cada
empleado se da unvocamente una oficina y a
travs de sta por la interrelacin tiene se llega al
departamento del empleado. Por lo dicho se
puede eliminar la interrelacin redundante y dejar
como se muestra en la figura 19.
Otro caso de entidades redundantes es
cuando no se tienen atributos descriptores fuera
del identificador nico. En este caso, es posible
eliminar al conjunto de entidades y pasar su
identificador como atributo descriptor a la entidad
que este vinculado.
50

En el captulo siguiente cuando se trate la

cardinalidad en interrelaciones de grado tres se
vern otros de interrelaciones redundantes.
 51

4 REDUCCIN DE ATRIBUTOS
MULTIVALUADOS
En la seccin 2.2.2 se dijo que la utilizacin
de atributos multivaluados ayuda a la abstraccin
de los datos, permitiendo de esta manera La
simplificacin y mejor entendimiento del problema.
Una desventaja de su utilizacin es que, en
general, el diseo lgico que le sigue al modelado
conceptual se sustente en el modelo relacional y
este obliga a que todas las relaciones se definan
en 1 FN. Esto significa que todos los atributos
deben ser indivisibles, es decir, que tengan
solamente una ocurrencia por cada entidad. Otra
desventaja puede darse en la herramientas CASE
que utilice pues, en general, no permiten esta
clase de atributos. Un tercer factor, un tanto
discutible, es que su utilizacin por diseadores
inexpertos puede dejar un modelo engorroso. Esto
es .debido a que en general un atributo repetitivo
esta encubriendo a otra entidad y/o otra
interrelacin y a veces puede convenir expresarlas
directamente.
En la figura 20 a) se tiene un ejemplo con
atributo multivalor dado anteriormente y en la
figura 20 b) se representa la misma realidad con
otro DER equivalente. El lector puede notar lo
complicado que se vuelve esta ltima
representacin; para entenderla se necesitan
comprender cuatro conceptos distintos (dos
entidades, una interrelacin Y un tipo de
vinculacin) mientras que en la primera
representacin solamente existe un concepto
52

nico. En este caso adems, es ms natural y

cercana al usuario final la primera representacin.
 53

CAPTULO 3
OBJETOS DEL MER EXTENDIDO
El modelo original de Chen, resulta
inadecuado para representar ciertos conceptos del
mundo real, como as tambin para seguir algunas
metodologas de diseo conceptual como la de
unificacin de vistas. Por tal motivo, muchos
autores le siguieron agregando, hasta nuestros
das, nuevos conceptos para volverlo
semnticamente ms poderoso. A continuacin se
ver la cardinalidad en relaciones ternarias y
jerarquas.
3.1. CARDINALIDAD DE LAS
INTERRELACIONES TERNARIAS
Las interrelaciones ternarias a diferencia de
las vistas anteriormente necesitan de un anlisis
ms profundo. Su interpretacin no es tan trivial y
en general, existe en el ambiente informtico cierto
desconocimiento sobre ellas. Una dificultad extra
en su comprensin, est dada por el hecho de
interpretarse de una manera distinta a las
vinculaciones de grado uno y dos, vistas
anteriormente. Es por ese motivo que el autor
prefiere cambiar drsticamente la notacin con
que se simbolizan en el DER para, de esta
manera, marcar bien la diferencia en su lectura.
Figurativamente, es como si las interrelaciones de
grado uno y dos se vieran en dos dimensiones
distintas mientras que las interrelaciones de grado
tres se necesitan ver en tres dimensiones.
54

Es fundamental para un diseador de

basas de datos el dominio de esta clase de
interrelaciones. Saber recabar la informacin
necesaria sobre el objeto a modelar, para
determinar si le corresponde o no su utilizacin,
ser parte de su responsabilidad.
Para estudiar todos los casos posibles se
tomar el siguiente ejemplo : Existen tres tipos de
entidades PROVEEDOR, INSUMO y FBRCA; y
una interrelacin VENDE que las asocia. Los
atributos identificadores nicos para cada entidad
son: nombre_del_proveedor, nmero_de_insumo y
nombre_de_la_fbrica respectivamente. Por
simplicidad se designar a cada identificador nico
de la siguiente manera: np, ni, nf
respectivamente2. Otros atributos no interesan y
no se representarn en el DER. La interpretacin
para cada instancia del tipo <p, i, f> perteneciente
a la interrelacin VENDE es: el insumo que el
proveedor p suministra a la fbrica f.
En un apartado anterior se dijo que en lo
posible se debe tratar de eliminar las
interrelaciones de grado tres y en su lugar
reemplazarlas por tres o dos interrelaciones de
grado dos n:m. El lector debe cerciorarse que en el
ejemplo dado, ese cambio no se puede realizar,

2
Una buena prctica del diseo de bases de datos
consiste en nombrar a cada atributo en un lenguaje
natural, por lo tanto, esta codificacin de los nombres
de los identificadores nicos es a solo efecto de mejorar
la presentacin del ejemplo.
 55

pues se perderla una representacin fiel del

mundo real, objeto del problema3.
A continuacin se estudiarn en orden de
complejidad los cuatro tipos de cardinalidades
posibles a saber: casos n:n:n; n:n:1 ; n:1:1 ; 1:1:1.
Para otras opciones, como ser n:1:n, 1:n:n,
etctera, el lector debe notar que estn
contemplados en las anteriores vinculaciones y
que difieren solo en la forma en que se realiz el
diagrama4. Las vinculaciones opcionales (ninguna
o cero) tampoco son triviales; en la mayor a de los
casos no tienen sentido y se deja planteado en los
ejercicios.

3
Si lo modelamos con un DER con tres interrelaciones
n:m perderamos informacin; por ejemplo, si dos o
ms proveedores vendieron el insumo i1 y una fbrica
determinada lo compr; en general, nunca podamos
saber a cual o cuales vendedores se lo compr.
4
Note que, por ejemplo, cualquier grafo del tipo n:1:1 lo
podemos redibujar rotndolo y transformarlo a sus dos
formas equivalentes.
56

Caso n:n:n
Este caso es semejante al caso n:m, no
implica ninguna limitante5 . Es decir, que para
cualquier combinacin de los valores posibles de
los identificadores nicos, de las tres entidades,
sta ser una Instancia legal de la interrelacin
VENDE. Dicho formalmente; sea R el conjunto
formado por el producto cartesiano de los
dominios de los identificadores nicos de cada
entidad:
R = { dom(np) X dom(ni) X dom(nf) }
Cualquier subconjunto de R ser una
Instancia legal de la interrelacin VENDE. Por este
motivo se dice que no hay ninguna limitante en
VENDE.
En el ejemplo dado, esto significa que
cualquier proveedor puede vender cualquier
insumo a cualquier fbrica. Existen muchas formas
de expresar el mismo hecho en castellano.
En la figura 3.1 se ve su representacin en
el DER, vase como se simboliza el caso n:n:n; se
sombrean las esquinas correspondiente del
rombo.
En la tabla 1 se muestra una instancia
posible de ejemplo. Observe en dicha tabla, que
ningn atributo por si solo o combinacin de dos

5
En realidad existe una limitante: ningn elemento
puede estar repetido en un conjunto de interrelaciones
o entidades. Sin embargo tal limitante la vimos como
parte de su definicin y se asumi su cumplimiento para
todo conjunto.
 57

atributos, puede ser identificador nico. La nica

posibilidad es que la concatenacin de los tres
atributos sea el identificador nico.

Caso 1:n:n
Puede suponerse el mismo caso anterior
con el agregado de la siguiente visin de contexto:
a) una fbrica, no puede comprar el mismo insumo
a distinto proveedores (distintos insumos, los
podr comprar a distintos proveedores).
Analizando ahora qu pasa con la misma
instancia dada anteriormente, puede verse que en
la tabla 1 existen dos filas ilegales para este nuevo
ejemplo; un caso de conflicto est dado entre las
filas primera y cuarta. En efecto, en ellas se ve que
la fbrica f1 compra el insumo i1 a distintos
proveedores (p1 y p2) lo cual, viola la visin de
58

contexto. Por lo tanto, si se quiere cumplir con esta

limitante se debe eliminar alguna de las dos filas.
En el ejemplo se elimina la cuarta fila. El segundo
caso de conflicto est dado por las filas sexta y
sptima. Anlogamente se nota que distintos
proveedores (p2 y p3) venden el mismo insumo
(i1) a la misma fbrica (f4). Otra vez la limitante
obliga a dejar solamente a una de las dos filas. En
el ejemplo se elimina la fila sexta.
Una vez eliminadas las filas se escriben las
restantes en la tabla II que muestra una instancia
legal para la interrelacin VENDE en el caso de
que su vinculacin fuera 1:n:n. Para mayor
claridad se dejaron en blanco las filas eliminadas
de la tabla 1.
 59

Mirando la instancia de la tabla II el lector

debe ser capaz de determinar su identificador
nico6.
En la figura 3.2 se muestra el DER del
caso. Obsrvese la esquina sombreada del rombo
de cada lado n.
CASO 1:1:n
Suponiendo el caso anterior pero con el
agregado de una segunda limitante ms : b) Cada
proveedor le puede vender a cada fbrica a lo
sumo un suministro. Por claridad se repite la
restriccin anterior, a) una fbrica, no puede
comprar el mismo insumo a distintos proveedores.

6
Partiendo de una instancia dada en general no se
podr determinar el identificador nico de un tipo de
entidad, pero si se puede ver cuales seguro no son
identificadores nicos. En este caso particular y en los
que siguen, por ser un ejemplo elaborado, eliminando
los que no pueden ser quedar el o los identificadores
nicos.
60

Con esta nueva restriccin el conjunto de

instancias legales de la tabla II se ver acotado; en
efecto, un conflicto se da entre la primer

fila y la tercera, donde puede leerse que el mismo

proveedor(p1) le vende distritos insumos (i1 y i2) a
la misma fbrica (f1). El otro conflicto se encuentra
en tas dos ltimas filas donde se lee otra violacin
nuestra visin de contexto (el proveedor p3 vende
distintos insumos (i1 e i2) a la misma fbrica. Para
conseguir un conjunto de instancias legales a
partir de la tabla II, se debe eliminar, las dos filas
(una de cada conflicto). Se eligen para eliminar a
la tercera y la ltima.
En la tabla III se muestra la Instancia legal
que queda para este caso. Obsrvese que este
subconjunto, como en el caso anterior. no es el
nico, ya que se pudo haber eliminado otras filas.
Mirando instancia nuevamente el lector debe ser
capaz de determinar que existen dos
identificadores nicos7. En la figura 3.3 se muestra
el DER del caso.

7
Vase referencia 6 de la pgina 59
 61

Caso 1:1:1
Partiendo nuevamente del ltimo caso y.
suponiendo que al modelo se le agrega una tercer
suposicin (visin de contexto) c) cada proveedor
vende un suministro dado solamente a una fbrica,
por claridad se repite las dos visiones de contexto
anteriores: a) una fbrica, no puede comprar el
mismo insumo a distintos proveedores y b) Cada
proveedor le puede vender a cada fbrica a lo
sumo un suministro.
Con la restriccin agregada, solo un
subconjunto de las instancias de la tabla III ser
legal. En esta tabla se ve un conflicto entre la
primera y segunda fila, ambas filas contradicen la
nueva visin de contexto. En efecto, su lectura nos
dice que el mismo proveedor (p1) vende el mismo
insumo (i1) a distintas fbricas (f1 y f2). Si se
62

quiere una instancia legal se debe eliminar alguna

de las dos filas. Se elige la segunda y se muestra
la instancia que queda para el caso en la tabla IV.
En la figura 3.4 se ve DER del caso.

En este caso se tienen tres identificadores

nicos y se corresponden (como en los casos
anteriores) con las tres restricciones enunciadas.
La unin de dos cualesquiera de los
identificadores nicos forman el identificador de la
interrelacin.
Como nota final de este tem se puede
decir a modo de resumen lo siguiente.
 63

Las interrelaciones n:n:n no tienen

restricciones y su identificador nico
es la unin de los tres
identificadores de las entidades que
asocia.
Las interrelaciones 1:n:n tienen una
sola restriccin y es la que est
implicada por su identificador nico.
Las interrelaciones 1:1:n tienen dos
restricciones (la restriccin del caso
anterior ms una nueva). Y
nuevamente son consecuencia de
sus dos identificadores nicos.
Las interrelaciones 1:1:1 tienen tres
restricciones (las dos restricciones
del caso anterior ms una nueva) y
otra vez son consecuencia de sus
tres identificadores nicos.
Los cuatro puntos se ven de manera
grfica en la figura 3.5. El valo externo representa
al universo de instancias posibles para el caso
irrestricto n:n:n. Algunas de ellas formarn parte
de las instancias legales bajo la limitante del caso
1:n:n. De stas solo un subconjunto formar parte
de las Instancias legales bajo la restriccin del tipo
1:1:n; y por ltimo, en el valo interno se
encuentra el subconjunto de todas las instancias
legales que cumplen con las limitantes del caso
1:1:1.
64

3.1.1 UNA LECTURA NO INTUITIVA

El lector se puede preguntar en este
momento por qu se hizo tanto hincapi en el nivel
de dificultad y diferencia entre relaciones de grado
tres y las otras. Una de las razones es que su
interpretacin no es para nada intuitiva como
suceda con aquellas. Enseguida se ver el por
qu de tal aseveracin.
Si se toma el caso n:n:n anterior y la tabla 1
donde se muestra una instancia posible de la
misma. Estudiando la misma se observa que entre
dos cualesquiera conjuntos de entidades existe
una vinculacin n:m. En efecto, por ejemplo, en
dicha instancia se tiene que el proveedor p1
 65

comercializa los insumos i1, i2 e i3 y el insumo i2

lo comercializan dos proveedores; por lo tanto se
trata de una vinculacin n:m entre PROVEEDOR e
INSUMO. Anlogamente puede verse que un
proveedor (p2) comercializa con varias fbricas (f1
y f4) y a su vez una fbrica (f1) compra a varios
proveedores (p1 y p2); por lo tanto se trata de una
vinculacin n:m entre PROVEEDOR y FABRICA.
El ltimo caso entre INSUMO y FBRICA se deja
para el lector.
Ya se dijo que a la interrelacin VENDE no
se la puede reemplazar por tres interrelaciones de
grado dos sin perder la interpretacin que se hizo
del modelo. En cambio, se vio cmo su existencia
est implcita en la vinculacin n:n:n. Es decir que
la vinculacin n:n:n implica necesariamente la
existencia de tres interrelaciones n:m y no
viceversa. Dicho de otra forma, una interrelacin
n:n:n no impone ninguna limitante sobre el
comportamiento de sus entidades vistas en forma
binarias. Estas interrelaciones de grado dos no se
deben poner en el DER por resultar redundantes,
como se dijo estn implcitas en la interrelacin
n:n:n.
Obviamente, se podra tener cualquier otra
interrelacin entre estas entidades, pero para que
tenga sentido debe tener distinta semntica. Por
ejemplo, entre las entidades PROVEEDOR y
FABRICA se puede agregar la interrelacin
vecino de con cardinalidad n:m pero es claro que
se refieren a otra cosa (distinta semntica). Otro
ejemplo es la interrelacin vendedor de entre
PROVEEDOR e INSUMO; note que aqu la
diferencia es ms sutil; podra guardar todos los
66

insumos que provee cada proveedor,

independientemente de si tienen registrados algn
pedido para alguna fbrica.
Toma ahora el caso 1 :n:n; la pregunta que
se hace es: pasa lo mismo que en el caso
anterior? es decir, existen tres vinculaciones de
grado dos n:m implcitas en la interrelacin de
grado tres del tipo 1:n:n. Lamentablemente la
respuesta intuitiva no es la correcta. En efecto el
alumno o el diseador inexperto podran creer que
entre PROVEEDOR y FABRICA al igual que ente
PROVEEDOR e INSUMO existen implcitas
vinculaciones del tipo 1:n. Lo anterior es falso.
Para darse cuenta de esto basta con ver la tabla II
donde se puede ver que entre dichas entidades
sigue existiendo una vinculacin n:m. En efecto,
por ejemplo, p1 vende i1, i2 e i3 ; i1 lo compran p1
y p3 por lo tanto se tiene una vinculacin n:m entre
PROVEEDOR e INSUMO. Las otras dos
deducciones se dejan al lector.
Pase ahora al caso 1:1:n y la tabla III
donde se muestra una instancia posible de la
misma. Se hace nuevamente la misma pregunta;
existen tres vinculaciones de grado dos n:m
implcitas en la interrelacin de grado tres del tipo
1:1:n ?. A pesar de lo intuitivo, viendo la tabla III se
encuentra que el hecho es invariante; siguen
existiendo las tres interrelaciones grado dos del
tipo n:m implcitas en la interrelacin 1:1 :n igual
que en los otros dos casos. La verificacin queda
el lector.
Por ltimo queda el caso 1:1:1. qu
pasar en este caso?. El autor cree que despus
 67

del desarrollo precedente lo no intuitivo pas a ser

intuitivo y el lector estar sorprendido ante el
hecho de que tambin siguen las tres
interrelaciones n:m implcitas. Se repite, an en el
caso 1:1:1 existe una interrelacin implcita n:m
entre cualesquiera de ellas. En efecto, vase la
tabla IV donde, bastan tres filas, para demostrarlo.
Como se dijo anteriormente estas
interrelaciones Implcitas no se deben agregar al
DER por resultar redundantes. Pueden existir otras
interrelaciones de cualquier cardinalidad entre
ellas pero siempre que tengan distinta semntica.

3.2 DETERMINACIN DE LA
CARDINALIDAD
Para determinar la cardinalidad en
interrelaciones que involucran a tres entidades hay
que tipificar antes las restricciones o limitantes de
integridad vistas en el tem anterior.
Dada una interrelacin que involucra a tres
entidades se deben analizar las vinculaciones que
existen entre dos cualesquiera de ellas y la tercera
restante. Por lo tanto existen exactamente tres
combinaciones posibles a estudiar.
Tomando un ejemplo abstracto: sean los
conjuntos de entidades A, B y C y la interrelacin
que los asocie. Los tres casos a estudiar son:
si un elemento de A junto a un
elemento de B le corresponde 1 o n
elementos de C.
68

si un elemento de A junto a un
elemento de C le corresponde 1 o n
elementos de B.
si un elemento de B junto a un
elemento de C le corresponde I o n
elementos de A.
Si la respuesta es que les corresponde un
elemento quiere decir que se trata de una
restriccin, en ambos casos queda determinada la
vinculacin en esa rama.
Las tres restricciones vistas en el tem 3.1
se corresponden con las anteriores.
Obsrvese que de las tres alternativas a
estudiar surgen ocho resultados posibles, pero
como se vio anteriormente habr casos
semejantes, como ser 1:1:n 1:n:1 y n:1:1,
(anlogamente es para el caso 1:n:n) dependiendo
de como se haga el grafo. Por lo que se reduce
solamente a los cuatro casos vistos.
Por ltimo, se hace hincapi en una
diferencia entre las interrelaciones de grado dos y
las ternarias; en aquellas se estudiaba la
vinculacin de una entidad de un conjunto hacia
las otras entidades del otro conjunto, en cambio en
las ternarias se analiza la vinculacin de dos
entidades cualesquiera hacia la tercera restante.

3.3 JERARQUAS
En ocasiones es muy til y natural
clasificar las entidades en distintos subtipos segn
el rol que cumplen en el sistema, o por sus
 69

distintas caractersticas, otras veces, se puede

hacer el camino inverso: es decir, a partir de
distintas entidades se puede abstraer iguales
caractersticas y realizar una generalizacin de
ellas, creando un supertipo que contenga todas las
caractersticas comunes a aquellas. Este proceso
simple, lleva a dos conceptos del modelo entidad
interrelacin extendido; la especializacin y la
generalizacin. La diferencia existente entre ella:
es algo sutil y se puede expresar en funcin de las
limitantes que nos impone cada una.
Antes de mostrar ejemplos concretos con
mayor detalle y sin perder generalidad, se vera el
caso abstracto de un supertipo A y sus dos
subtipos B y C. Existen dos restricciones; B C =
(conjuntos disjuntos) y B C = A (completitud
de la particin), que segn se combinen dejan
cuatro casos posibles:
1. Si BC=A y BC= (conjuntos disjuntos)
2. Si BC=A y BC= (conjuntos disjuntos)
3. Si BC=A y BC (conjuntos solapados)
4. Si BCA y BC (conjuntos solapados)
El lector debe generalizarlo para el caso de
tener n subtipos. En los casos uno y tres, donde
BC =A se dice que la jerarqua es total y
jerarqua parcial en los casos en que BCA.

3.3.1 GENERALIZACIN y
ESPECIALIZACIN
Se llama generalizacin cuando imperan
las limitantes del caso uno, dado anteriormente. Es
decir, que si se tiene la restriccin de que los
70

subtipos sean disjuntos (no solapados) ms la

obligacin de que en todo momento. la particin
en B y C sea completa (completitud de la
particin). Dicho de un modo ms formal, E es una
generalizacin de E1. E2,...,En si cada ocurrencia
de E es tambin es una ocurrencia de una y solo
una de las entidades subtipos A este tipo de
jerarquas se las suele llamar es un.
Un ejemplo de generalizacin es el caso de
una inmobiliaria que comercializa distintos objetos
como ser: lotes, casas, departamentos y locales.
Podra ser til generalizar dichos objetos y formar
el supertipo INMUEBLE caracterizado por los
atributos comunes a todos los subtipos. En la
figura 3.6 se muestra el caso, obsrvese la
simbologa utilizada y el rtulo que le da semntica
a la jerarqua.

En otros casos se est frente a una

especializacin. Esta podr tener las tres variantes
 71

restantes (tipo 2, 3 y 4): por lo tanto, se debe

utilizar una simbologa que nos permita reconocer
visualmente de que variante se trata.
Un ejemplo de especializacin se presenta
en el caso de modelar a una empresa de
prstamos, donde se registran a tres clases de
personas; deudores, cnyuges y garantes, si la
empresa permite que el cnyuge o el garante de
un deudor soliciten otro prstamo, habr un
solapamiento entre los subtipos (Ver figura 3.7).
Obsrvese que si la misma empresa prohbe que
un cnyuge o un garante tengan otros prstamos
se modelara con una generalizacin.

La figura 3.9 ejemplifica el ltimo caso que

queda (caso tipo 2). A la entidad Docente se la
dividi en dos cargos mutuamente excluyentes
obviamente existen otros cargos que no se
especializaron (suponga que no le interesa a la
organizacin) por lo que la especializacin es
parcial.
72

Las ventajas que se obtienen al modelar

con jerarquas son las propias de la mayor
abstraccin de datos y del uso del concepto de
herencia. El subtipo hereda todos los atributos del
supertipo como s tambin toda interrelacin y
limitantes que le llegue a travs del supertipo.
 73

EJERCICIOS PROPUESTOS
1.
Defina los siguientes trminos

DER
Entidad
Entidad dbil
Conjunto de entidades
Interrelacin (relatioriship)
Conjunto de interrelaciones
Grado de una interrelacin
Atributos
Identificador nico
Evento
Vinculacin
Agregacin
Generalizacin
Especializacin

2.
a. Para qu sirve el DER?
b. En que etapa del ciclo de vida de un
proyecto
c. Qu relacin debe existir entre un
DER y un DFD?
3.
Una agencia de viajes necesita adoptar un sistema
que le permita disponer de la siguiente
informacin:
a. Por cada cliente desea saber el
cdigo de cliente, nombre,
74

direccin, telfono, ocupacin y

datos del grupo familiar.
b. Por cada Tours organizado por la
empresa debe saber cdigo de
Tours, fecha y hora de salida fecha
y hora de llegada, cantidad de
plazas. nombre de la gua de
turismo y las escalas que va
realizando el Tours con hora y da
de llegada y tiempo de estada.
c. La Empresa tiene contratada, gente
especializada en cada escala que
acompaa a los Tours que pasan
en su zona.
d. El importe de cada Tours se puede
pagar de vanas formas.
e. Se debe registrar las cuotas pagas
de cada cliente que corresponda a
esta modalidad de pago.
f. El sueldo de los guas de turismo se
deduce de un sueldo bsico de
acuerdo al cargo, ms un importe
por antigedad, ms un adicional
por cada Tours que atendi.
Se pide:
Hacer el DER indicando para cada entidad su
identificador nico y atributos.
4.
Con los siguientes datos de una empresa de
transportes martima realice un DER apropiado:
 75

a. La empresa dispone de varios tipos

de barcos. Cada uno de ellos tiene
un nombre nico, una capacidad
determinada y una licencia para
navegar otorgada por algn pas.
b. Cada puerto pertenece a un pas y
se le asocia un costo diario por uso
y otro costo ms por tiempo de
espera para cargar o descargar.
c. El recorrido que puede realizar cada
barco es indistinto pero siempre
dentro de rutas martimas
preestablecidas. La informacin de
estas rutas se debe guardar para
programar los itinerarios de cada
barco. Tambin se guarda el
itinerario que va realizando cada
barco con da y hora de llegada y
salida de cada puerto que puede
diferir del programado. El itinerario
programado para cada barco
consiste en una lista de puertos con
cdigos de pedidos de cargas y
descargas asociados a cada uno de
ellos y puede cambiar segn las
necesidades actuales de la
empresa.
d. Se lleva la informacin del personal
de la empresa. Los capitanes de
buques son asignados a barcos
determinados pero en casos de
licencias son reemplazados
inmediatamente. Los sueldos de los
marineros y oficiales son girados a
76

la ciudad que estos elijan y se fijan

segn el cargo ocupado, la
antigedad en la empresa, y un
porcentual por las distancias
navegadas.
5.
Una Empresa de transportes desea informatizar su
rea administrativa. Un primer relevamiento
muestra lo siguiente:
a. Cada unidad de transporte se
identifica por un nmero de interno
y puede tener uno o mas
propietarios.
b. Cada viaje lo realiza un solo chofer
y tiene asignado un destino y hora
de llegada.
c. Despus de cada viaje los choferes
deben entregar las boleteras y
rendir los boletos vendidos.
d. Los supervisores realizan controles
Sorpresivos anotando el estado de
la boletera del servicio Controlado.
e. El sueldos de los choferes se
compone de un bsico mas un plus
por viaje realizado ms un 4% por
ao de antigedad.
f. Al propietario de cada unidad sea o
no chofer se le abona tambin un
bsico mensual ms un plus por
viaje que hayan realizado sus/su
unidades.
Se pide : Realizar un DER indicando para cada
entidad su identificador nico y atributos.
6.
 77

Por cada una de las siguientes entidades se desea

llevar la informacin que se detalla a continuacin,
Realice un DER que permita representar esa
informacin.
a. SISTEMAS (cod-sist, nomb-sist,
nombre-jefe-del-proyecto,
cod_analista, nombre del analista,
cod. del programador, nombre del
programador, cdigo del programa)
b. PROGRAMAS (cod. de programa,
nombre del programa, cdigo de
programador. cod. de archivo, tipo
de acceso, tipo de familia de
programa)
c. ARCHIVOS (cod. de archivo,
nombre del archivo. cod. de dato
eIemental, nombre de dato
elemental, indicador de clave, tipo
de organizacin de archivo. longitud
de registro)
d. PROCESO (cod. de- sistema, cod.
de proceso, nombre de proceso,
cod. de programa)

Se supone:
Un sistema tiene varios analistas y vahos
programadores pero un solo jefe de
proyecto.
El cod. de programa, proceso y archivo es
nico para todos los sistemas.
Un programa pertenece a una sola familia
de programas.
El tipo de organizacin y longitud del
registro es nico para un archivo.
78

Un programa esta construido por un solo

programador.
Un programa tiene vahos archivos y el tipo
de acceso al archivo depende del
programa.
Un archivo tiene vahos datos elementales.
El indicador de clave seala si ese dato
forma parte de la clave para ese archivo.
Un sistema puede tener varios procesos y
un proceso vanos programas.
7.
Un club social y deportivo desea informatizar la
gestin de sus socios. Un primer relevamiento
muestra lo siguiente:
a. Los socios pueden ser de cuatro
categoras distintas; menores,
juniors, seniors y vitalicios. La
categora depende de la edad del
socio y para el caso de vitalicio de
su antigedad como Socio.
b. Las bajas de los socios se pueden
producir por dos razones: pedido de
baja del socio o terminado el
tercer mes de mora.
c. La cuota social consta de un bsico
que depende de la categora del
socio ms un plus por deporte
inscripto. Los socios vitalicios no
pagan arancel. Tambin se desea
mantener informacin acerca de los
deportes que practica cada socio
manteniendo la siguiente
informacin: deporte, turno,
 79

profesor asignado y arancel (si lo

tiene).
d. Un socio puede practicar varios
deportes.
Se pide:
Realizar el DER, indicando para cada entidad e
interrelacin su identificador nico y atributos.
8.
Modele con un DER los conceptos tericos del
DER ( un DER del DER).
9.
En un DER, toda entidad dbil con dependencia
de identidad, puede ser transformada en entidad
dbil con dependencia existencial, con solamente
agregarle algn atributo correspondiente. Es
conveniente hacer esto ? Justifique
10.
Pase los siguientes esquemas de relaciones a un
DER que lo represente fielmente.
VUELO ( nro_vuelo, dia_hora_salida,
aeropuerto_origen, aeropuerto_destino)
ESCALA (nro_vuelo, aeropuerto_desde,
aeropuerto_hasta)
11.
Pase los siguientes esquemas de relaciones a un
DER que lo represente fielmente.
AEROPUERTO (nombre-aeropuerto, ciudad)
VUELO (nro_vuelo, dia_hora_salida,
aeropuerto origen, aeropuerto_destino)
ESCALA (nro_vuelo, aerop_desde, aerop_hasta)
12.
a. Explique qu significa la .siguiente
relacin ternaria del DER y tache lo
que no corresponda:
80

b. Una profesor puede atender

muchos proyectos? SI/NO
c. Un profesor puede atender a
muchos alumnos? SI/NO
d. Un mismo alumno puede trabajar
en ms de un proyecto? SI NO
13.
e. Explique qu significa la siguiente
relacin ternaria del DER y tache lo
que no corresponda:
f. dem al ejercicio anterior SI/NO
g. dem al ejercicio anterior SI/NO
h. dem al ejercicio anterior SI/NO

14.
Para cada una de las figuras de los ejercicios 12 y
13 especifique los atributos de cada tipo ce datos
indicando los identificadores nicos
15.
 81

En un laboratorio de anlisis clnicos los clientes

solicitan para realizarse distintas clases de
anlisis. Los clientes deben presentar
obligatoriamente la orden mdica donde figuran el
o los anlisis que se debe realizar y en algunos
casos un mtodo determinado para algn anlisis.
Cada anlisis a su vez puede tener varios
subanlisis asociados. Cada anlisis pertenece un
rea determinada. El cliente debe abonar una
factura donde figura el detalle correspondiente.
Se pide realizar el DER.
16.
Dada la problemtica del departamento de
alumnos de su facultad donde se realiza la
inscripciones de los alumnos a las materias;
Control de cuotas pagas: control de TP aprobados;
control de exmenes rendidos; asignacin de
aulas y control de docentes y ctedras.
Se pide: Realizar el DER indicando para cada
entidad e interrelacin su identificador nico y
atributos principales.
17.
Al Modelo Entidad lnterrelacin se lo puede
considerar como un Objeto (en la terminologa 00).
Cules sern las clases? Cules sern los
mtodos pblicos y privados? y cules sern los
mensajes?
18.
Dado los siguientes esquemas de relacin dibuje
un posible DER que le dio origen.
A(a1, a2,a3, a4);
B(b1, b2, b3, b4);
C(c1, c2,c3);
r1(a1, c1);
82

D(d1, d2, d3);

r2(d1, b1);
r3(a1, b1);
E(a1, e2, e3);
F(a1, f4, f5);
19.
Para cada uno de los posibles grafos del DER
exprese las relaciones asociadas.
20.
Dado el DER que se muestra en la figura a) se
pide:
a. Para cada entidad e interrelacin
escriba sus atributos
indicando en cada caso los
identificadores nicos.
b. Bajo qu visiones de contexto se
puede reemplazar por el DER de la
figura b)?
c. Bajo qu visiones de contexto se
puede reemplazar por el DER de la
figura c)
d. Bajo qu condiciones de contexto
no se puede reemplazar por b) ni c)
sin perder su semntica?
83
84

21.
Un sistema est formado por la ejecucin de un
conjunto de programas, cada uno tiene una cierta
frecuencia.
Un programa puede ejecutarse en ms de un
sistema y su frecuencia va a depender del sistema
en que corra. A su vez, un programa puede usar
vanos archivos en distintos modos (input, output,
input-output). y este mtodo de acceso depender
del programa que lo use.
Un archivo puede ser usado por varios programas.
A la gerencia le interesa registrar el modo de
acceso de cada archivo y la frecuencia para cada
programa que se ejecute. Realice el diagrama E-R
correspondiente.
Indique alguna de las consultas que se podran
realizar sobre la base de datos as definida.
22.
dem al anterior pero agregue : Cada usuario del
sistema tiene acceso. solo a determinados
sistemas y dentro de ellos solo a determinados
programas. La gerencia quiere conocer los
permisos concedidos.
23.
En una empresa de comercializacin se ha
realizado un relevamiento a efectos de disear una
base de datos. Se considera necesario poder
mantener informacin acerca de los siguientes
elementos:
a.
Nombre, direccin, sueldo y
antigedad de los empleados.
Departamentos en que se divide la
 85

empresa. C/u de los cuales vende

una determinada serie de artculos
b. Las personas a cargo de cada
departamento.
c. Los artculos a comercializar: tipo.
nombre, precio etc.
d. Datos de los fabricantes de los
artculos.
e. Los clientes de la empresa, dem
ejercicio 21.
24.
Una entidad gremial registra la informacin de sus
afiliados en una ficha.
Solo pueden afiliarse a la entidad los empleados
del banco Nacin, quienes deben adems
pertenecer al personal jerrquico del banco.
La entidad guarda informacin de todo el personal
jerrquico sea socio o no de la entidad.
El banco no acepta empleados que no sean
argentinos nativos o por opcin.
Los datos que se registran son:
Apellido, nombres, edad, nacionalidad, calle, nro,
piso, departamento, localidad, cdigo postal y
telfono son datos personales del empleado.
Adems se tiene el Nro. de Legajo (nro. del
empleado en el banco) y el nmero de socio (nro.
de socio en la gremial (si es socio)) la fecha en
que el socio se afili a la gremial (si es socio),
Fecha de ingreso al banco, cargo que ocupa,
descripcin del cargo, fecha en que el empleado
fue ascendido o cambiado de sucursal, ubicacin
(sucursal o sector en que trabaja el empleado).

Se pide : a) realice el DER correspondiente.

86

b) verifique que soporte una consulta por todas las

modificaciones de cargo (ascensos) y tas
modificaciones de ubicacin (traslados) ordenadas
por fecha para un empleado cualquiera.
25.
En una carrera de ciencias de la computacin de
una determinada facultad existen tres
especialidades. De las materias que se dictan
algunas son comunes a una, dos o las tres
especialidades. A su vez, las materias tienen otras
materias como correlativas.
Existen profesores habilitados para dar una ms
materias, algunas de las cuales han dictado
anteriormente.
Determinadas materias se estn dictando
actualmente y tienen un profesor a cargo,
estudiantes inscriptos, horarios y aulas asignadas.
Se lleva tambin un listado de las materias
rendidas por alumnos, fecha y nota sacada.
26.
Una empresa registra acerca de sus empleados
nombre, direccin, telfono nmero de legajo,
antigedad, y rea de trabajo.
Existen los jefes supervisores de trabajo que
tienen a su cargo un grupo de empleados a los
cuales les controlan sus tareas. Un empleado es
supervisado a lo sumo por un supervisor.
La misma empresa se encarga del dictado de
cursos de perfeccionamiento, registrando por cada
curso su temtica, duracin, cantidad de alumnos
y nombre del profesor que lo haya dictado, Indicar
para cada empleado qu cursos ha tomado.
27.
 87

En la biblioteca de una universidad se requiere

mantener informacin acerca de los papers
existentes en la casa. Para esto se necesita
conocer por cada autor su nombre, ttulo y
universidad que edit el paper. Cada paper se
registra con un cdigo, un abstract, la ubicacin en
biblioteca, indicador que dice si est prestado, en
cuyo caso se registra el nombre de la persona que
lo tiene.
Tambin se requiere conocer cuales son los
docentes que utilizan esos papers en el dictado de
sus materias.
28.
Traduzca los siguientes trminos:
entity relationship model
relation model
Por qu es conveniente hacer hincapi en la
diferencia que existe entre los trminos relation y
relatioriship?.
29.
Haga una pequea referencia sobre las distintas
variantes que existen del modelo de CHEN y las
diferencias en su simbologa.
30.
Explique la diferencia entre rango y dominio de un
atributo. Ejemplifique.
88

BIBLIOGRAFA
Existe una abundante bibliografa sobre el modelo
entidad interrelacin. Las referencias del [1] al [5]
son tratamientos a nivel de libros de texto. DeI [6]
en adelante son artculos de publicaciones
especializadas.

[1]
ADORACIN DE MIGUEL 1993. Concepcin y
diseo de Bases de datos. RA-MA : Addison-
WesIey.
Hace referencias a ciertas construcciones del MER
extendido que en la presente obra no se dieron, en
particular interrelaciones opcionales y algunas
clases de jerarquas. Las interrelaciones ternarias,
al igual que en todos los libros de texto conocidos
por el autor, son tratadas en forma incompleta.

[2]
C.J.DATE 1990. lntroduccin a los Sistemas de
Bases de Datos. 5ta edicin. Addison-Wesley.
Luego de hacer una breve sntesis del modelo. el
autor, hace un buen anlisis crtico del mismo
Como muestra se extrae el siguiente comentario
Pero lo importante es que no hace falta adoptar
todas las ideas del modelo para poder utilizar los
diagramas, es muy posible emplear los diagramas
como base pare cualquier metodologa

[3]
KROENKE D.M.1992. Database Processing:
fundamentals, design implementation. 4ta. Edicin.
Macmillan Publishing Company.
 89

[4]
H.F.KORTH 1991, Fundamentos de Bases de
Datos 2da edicin. McGraw Hill.

A nivel introductorio es un buen comienzo. Es muy

didctico. El tratamiento de las interrelaciones
ternarias es en el mejor de los casos incompleto.

[5]
J.D.ULLMAN 1989, Principies of Database and
Knowledge Base System. Computer Science
Press. Tomo 1.

[6]
Chen, P.P 1976, The Eritity-Relationship Model:
Toward a Unified View of Data. ACM Trans.
Database Syst. 1.1. 9-35.

Pocos artculos como este dieron tanto que hablar

Como ya se dijo aqu se present por primera vez
al modelo entidad interrelacin y el diagrama que
lo simboliza. Algunas de sus definiciones son, en
el mejor de los casos ambiguas. Es que al da de
hoy sigue siendo un modelo no del todo formal por
lo que sus definiciones bsicas tienen algo de
subjetivo.

[7]
TEOREY T.J, YANG D. And FRY J.P. A Logical
Design Metodology for Relational Databases Using
the Extended Entity-Relationship Model.
Excelente artculo. El autor propone una
metodologa de diseo lgico a partir de un diseo
90

conceptual con el MER. Es decir, hace uso del

comentario de DATE J. C. (vase nota en
referencia [2]. En la presente obra, algunas ideas
sobre las interrelaciones ternarias surgieron de
aqu).

[8]
Smith, J.M 1977, Database Abstractions:
Aggregation and generalization ACM
Trans.Database Syst 2,2 (june)105-
133.