Modelado de una BD (DER-MR)

Vista previa del material en texto

Modelado de una 
Base de Datos
Autor: Alfonso Palomares
Corregido y revisado por: Martín Battaglia
Modelado de una base de datos by Alfonso Palomares is licensed under a Creative                           
Commons Atribución­NoComercial­SinDerivadas 3.0 Unported License.
 
Pag. 1 ­ 59
http://www.google.com/url?q=http%3A%2F%2Fcreativecommons.org%2Flicenses%2Fby-nc-nd%2F3.0%2F&sa=D&sntz=1&usg=AFQjCNGLjr_jzVJSWxf6H1UmJmx0l7ooDA
http://www.google.com/url?q=http%3A%2F%2Fcreativecommons.org%2Flicenses%2Fby-nc-nd%2F3.0%2F&sa=D&sntz=1&usg=AFQjCNGLjr_jzVJSWxf6H1UmJmx0l7ooDA
http://www.google.com/url?q=http%3A%2F%2Fcreativecommons.org%2Flicenses%2Fby-nc-nd%2F3.0%2F&sa=D&sntz=1&usg=AFQjCNGLjr_jzVJSWxf6H1UmJmx0l7ooDA
Contenidos
Modelado de una
Base de Datos
2. El Modelado
2.1. Por qué debo realizar un modelo
2.2. Cómo modelar
2.2.1 Ejemplo
2.3. Diagrama Entidad Relación (DER)
Entidades
Ejemplo
Atributos
Atributos Clave o Identificadores
Atributos Calculados
Atributos Multivaluados
Atributos Compuestos
Relaciones
Cardinalidad de las Relaciones
Opcionalidad
Grado de una Relación
Relación Unaria
Relación Binaria
Relación Ternaria
Atributos en las relaciones
Entidades débiles
Jerarquías o Herencias
2.3.1. Ejemplos simples
2.3.2. Ejemplo complejo
2.4. Modelo Relacional (MR)
Elementos del Modelo Relacional
Relaciones
Atributos
Atributos Claves
Atributos Foráneos
Atributos Clave y foráneos
Reglas de tranformación. Desde el DER al MR
De Entidades simples a Relaciones.
De Entidades y Relaciones a Relaciones.
2.4.1. Ejemplos simples
2.4.2. Ejemplo complejo
 
Pag. 2 ­ 59
2. El Modelado
Desde sus comienzos, el ser humano ha intentado hacer representaciones gráficas de su                         
universo conocido, para así poder transmitir su modo de ver las cosas a otros. Conforme el                               
ser evoluciona, también lo hacen sus esquemas gráficos, llegando a especificar y tipificar                         
cada representación. Es por esto, que la mejor manera de pensar, diseñar y mostrar una                             
base de datos sea mediante un dibujo.
Como en todos los ámbitos formales sucede, se creó por decisión del medio y luego de                               
diversas pulseadas entre diferentes corrientes, un modelo específico para el planteo de                       
bases de datos. Por lo cual, se tomaron algunas precauciones.
Primero, se debe minimizar la cantidad de plantillas usadas, es decir, se debe contar con un                               
reducido conjunto de elementos. Segundo, se debe dar un significado único a cada                         
elemento, permitiendo así una única interpretación.
2.1. Por qué debo realizar un modelo
Debemos construir un puente que nos acerque entre quien tiene una idea y aquel que la                               
realizará. Si debemos conectar el pensamiento entre más de una persona, es vital que                           
generemos un diseño que sea lo más universal posible, que sea fácil de comprender,                           
incluso hasta por aquellos que surgen de otros ámbitos académicos. Es por ello que                           
debemos utilizar un modelo estándar, probado y revisado durante años. Si en lugar de hacer                             
un modelado simplemente nos centramos en realizar un escrito, daríamos lugar a errores de                           
interpretación o problemas del lenguaje, entre otras cosas.
2.2. Cómo modelar
Para el caso de bases de datos, el modelo gráfico conceptual más utilizado es el Diagrama                               
Entidad­Relación, también conocido como DER.
Dentro de esta forma de modelar, se encuentran solamente dos tipos de elementos                         
diferentes, permitiendo transmitir un mensaje claro y preciso. Dichos elementos, son sólo                       
del tipo “Entidad” y “Relación”.
Las entidades indican las colecciones de objetos de los que necesitamos almacenar o                         
recopilar datos. Dado que son colecciones, se las denomina formalmente “Conjunto de                       
Entidades”, pero por simplicidad se opta por llamarlas simplemente “Entidades”. 
Se las nombra siempre en singular y pueden representar objetos materiales (vehículos,                       
lugares, etc.), objetos abstractos (llamadas telefónicas, movimiento bancario, etc.), objetos                   
vivos (empleados, alumnos, etc.) u objetos inanimados (accidentes geográficos, puestos de                     
trabajo, etc.), pero siempre serán tomadas y tratadas como colecciones de objetos. Si                         
percibimos que debemos tener en cuenta los boletos de transporte utilizados en el mes, nos                             
Pag. 3 ­ 59
surge una entidad llamada Boleto, donde se guarde la colección de los boletos.
Tomando esto último, vemos que de alguna manera, tenemos que definir características o                         
atributos que describan a cada elemento de la colección. De aquí en más utilizaremos el                             
término “Atributo”. Por ejemplo, para la entidad planteada Boleto, deberíamos tener en                       
cuenta los atributos correspondientes al precio, el origen y destino del viaje, etc. Otro                           
ejemplo, para la entidad Llamada, los atributos pueden ser, día y hora de la llamada, número                               
de destino, número origen, duración de la llamada, costo, etc.
Por otra parte, las relaciones estarán signadas por la acción, vínculo, asociación o                         
interacción entre entidades. 
Por ejemplo, si tenemos las entidades “Persona” y “Mascota”, una relación entre ellas podría                           
ser “es dueño de”, donde indicamos que una o más personas son dueñas de una o más                                 
mascotas. Otro ejemplo que podemos incorporar es, teniendo “Persona” y “Boleto”, posibles                       
relaciones entre estas entidades serían, “utilizó” para señalar que una persona utilizó un                         
boleto, o “es vendido por”, para indicar que uno o más boletos son vendidos por personas.                               
Por último, podemos tener “Persona” y “Auto”, donde las relaciones podrían ser, “es dueño                           
de”, o “conduce”, o “le gusta” o “es vendido por”., etc. Como vemos, normalmente las                             
relaciones están definidas con un verbo o una frase verbal.
Qué determinará las entidades a considerar y sus relaciones dependerá exclusivamente del                       
universo o dominio que estemos modelando y del contexto en que esto sea utilizado.
2.2.1 Ejemplo
Nos interesa para este ejemplo pensar en un esquema que nos permita administrar                         
nuestros DVD de música y video. De los DVD’s queremos contar con la información de: el                               
nombre, la fecha de edición y la compañía que hizo la edición. Además, queremos saber qué                               
artistas intervienen en las diferentes producciones.
Teniendo esto, podemos empezar a analizar qué elementos serán posibles entidades. Para                       
detectar colecciones, debemos ver en el párrafo anterior, qué elementos son almacenables                       
y posiblemente necesitemos persistir más de uno. Normalmente vienen denotados por un                       
sustantivo. Lo primero que salta a la vista, son los DVD. Luego podría ser la compañía que                                 
hace la edición y por último, los artistas. Estas tres colecciones podríamos definirlas como                           
entidades.
Una vez que hemos detectado las entidades, debemos proceder a reconocer los atributos                         
que las describan. Es importante recordar describir sólo lo necesario para el dominio y                           
contexto de nuestro problema. Para los DVD, los atributos a considerar, podrían ser: elnombre, la fecha de edición e incluso podemos definir un atributo que nos distinga si el DVD                                 
es una película o no. Para las compañías editoras, la definición no especifica nada, por lo                               
que podemos presuponer contar con al menos un nombre. Lo mismo para el caso de los                               
artistas.
Finalmente, queda por determinar el conjunto de relaciones, las cuales no suelen ser tan                           
Pag. 4 ­ 59
explícitas en los textos como lo son las entidades, aunque muchas veces pueden                         
reconocerse con un verbo. Debemos recordar que las relaciones sólo ocurren “entre”                       
entidades,  lo cual nos indica quiénes participan a la hora de pensar la relación.
Nota: algunos libros plantean relaciones entre otras relaciones pero queda por fuera del alcance de este texto
Si releemos el párrafo del problema, vemos que la compañía editorial “edita” los DVD, siendo                             
esta la relación buscada. Luego, entre los artistas y los DVD, se descubre la relación                             
“participa” o “forma parte de”, determinando la acción entre el artista y la obra.
2.3. Diagrama Entidad Relación (DER)
Como anteriormente mencionamos, utilizaremos para la representación gráfica de un                   
modelo conceptual de base de datos, un Diagrama Entidad­Relación (o DER)
Entidades
En este modelo las colecciones de objetos o entidades serán representadas por un                         
rectángulo, donde el nombre de dicha colección estará encerrado dentro del mismo. Este                         
nombre estará definido en singular y no podrá repetirse en todo el diagrama.
Ejemplo
Figura 1. Se pueden ver tres entidades: Trabajador, Transporte y Zapato.
Para estos casos, se debe pensar que estamos diagramando objetos que son inherentes a                           
la necesidad que estamos representando en el diagrama. Si tenemos una empresa que                         
realiza diferentes modelos de zapatos, podemos pensar en considerar como entidades a los                         
trabajadores, con sus datos que los describen. Además, decidimos incluir la entidad zapato,                         
donde almacenaremos los distintos tipos de zapatos que se fabrican en nuestra empresa.                         
Por último, hemos incluido el transporte, para pensar en el medio que utilizaremos para                           
Pag. 5 ­ 59
distribuir los productos ya elaborados a las tiendas.
Atributos
Como ya hemos dicho, cada entidad o colección de objetos tendrá atributos que las                           
describan y además, que distinga a cada uno de los objetos incluidos en dichas colecciones.
Estos atributos serán dibujados con óvalos, conectados con una línea a la entidad a la que                               
están describiendo. Cabe destacar, que una entidad no puede tener dos o más atributos con                             
el mismo nombre, ya que estaríamos almacenando dos veces el mismo dato. Por ejemplo,                           
en la entidad Persona, si tenemos el atributo Nombre y lo definimos dos veces, para cada                               
objeto de dicha entidad, tendríamos el dato repetido: 
Para el objeto 1, la persona tiene como nombre José y para el objeto 2, el nombre Ana. Si                                     
repetimos el atributo, también duplicaríamos su contenido, almacenando en este caso                     
José;José para el objeto 1 y Ana;Ana, para el objeto 2. 
Puede el lector pensar, cómo hacer en el caso de que una persona tenga dos números de                                 
teléfono a donde poder contactarla. Estos casos los resolveremos más adelante.
Algo que sí puede suceder, es que dos entidades diferentes tengan, en cada una de ellas, un                                 
atributo con el mismo nombre. Por ejemplo, las entidades Persona y Color, ambas pueden                           
tener el atributo Nombre, pero cada atributo será una característica propia de cada entidad.
Otro ejemplo para ver esto podrá ser:
Figura 2. Vemos en el ejemplo, dos entidades, Auto y Moto, cada una con su atributo color.
 
Pag. 6 ­ 59
Atributos Clave o Identificadores
Algunos de los atributos tienen la particularidad de ser aquellos que determinan                       
unívocamente a la entidad dentro del conjunto de entidades. Por ejemplo, si tenemos la                           
entidad Auto, con los atributos año de fabricación, color, puertas, marca y modelo,                         
debemos pensar cómo distinguir los siguientes objetos de la colección Auto.
Año Color Puertas Marca Modelo
2009 Negro 5 Ford Focus
2010 Negro 5 Ford Focus
2010 Azul 5 Ford Focus
2009 Negro 5 Ford Focus
Vemos que si tomamos el atributo año como atributo identificador del Auto, no logramos                           
tener un solo valor diferente para cada auto, ya que en el ejemplo, 2009 y 2010 se                                 
encuentran en dos objetos (o autos) respectivamente.
Si tomamos año y color, tampoco conseguimos distinguir a un objeto de otro, ya que por                               
ejemplo 2009 + Negro, se encuentra en más de un objeto auto. Recordemos que el objetivo                               
es distinguir unívocamente a cada objeto de otro.
Probemos ahora, utilizar el caso extremo, es decir, utilizar todos los atributos. Si tomamos                           
2010 + Negro + 5 + Ford + Focus descubrimos que tampoco podemos determinar unicidad,                             
ya que 2009 + Negro + 5 + Ford + Focus se repite para dos objetos.
Para solucionar esto, si bien tenemos determinados a aquellos atributos que describen a la                           
entidad Auto, aún tenemos la necesidad de identificarlos unívocamente. Para el caso de esta                           
entidad, pensemos qué hay en la definición de un auto que lo identifique de forma única.                               
Generalmente, estos atributos son los fundacionales del objeto a evaluar. Para el caso de                           
las personas, lo que la define únicamente podría ser el Documento de Identidad. Para los                             
autos, esta simple característica única podría ser la matricula, ya que es el atributo con el                               
cual se diferencian los automóviles, quedando:
Matricula Año Color Puertas Marca Modelo
AAI001 2009 Negro 5 Ford Focus
AAI002 2010 Negro 5 Ford Focus
BBF003 2010 Azul 5 Ford Focus
CCF004 2009 Negro 5 Ford Focus
Si tomamos para cualquier objeto o instancia de la entidad una matrícula en particular,                           
vemos que obtenemos uno y solo un auto,
A este tipo de atributo, se lo denomina Identificador o Clave. La forma de distinguirlo de los                                 
otros, a modo gráfico, es subrayando el nombre del atributo.
Pag. 7 ­ 59
Figura 3. Tenemos las entidades Auto, con su atributo común color, y su atributo clave                             
matrícula. Por otra parte, la entidad Monitor, con su atributo clave Nro. de serie y sus                               
atributos descriptivos tamaño y color.
Cabe destacar, que podemos tener más de un atributo clave en una entidad, por ejemplo                             
la entidad Persona, que puede tener como atributos clave, el tipo y en número de                             
documento.
Figura 4. Encontramos en esta figura la entidad persona y dos atributos clave, número y tipo                               
de documento y los atributos comunes fecha de nacimiento y altura.
Tipo Nro Nombre
Pasaporte 29111222 Juan Rodriguez
DNI 29111222 Juana Dolores
DNI 29111223 Juan Rodriguez
Es importante entender que los atributos forman una única clave en su conjunto y no                             
pueden considerarse en forma aislada como tales. Como vemos en este ejemplo, sitomáramos solamente el número del documento, obtendríamos más de una personal para el                         
mismo valor. Lo mismo sucede con el atributo tipo de documento. Surge que, si tomamos el                               
tipo y el número de documento (el par), podemos distinguir unívocamente a cada persona.
Gráficamente, si tenemos más de un atributo clave, debemos subrayar a todos los atributos,                           
tal como hacemos cuando existe solo uno.
Pag. 8 ­ 59
Hay casos, donde tenemos más de un atributo que distingue únicamente a los elementos de                             
la entidad. Por ejemplo, en los autos, tenemos la matrícula como dijimos antes, pero                           
también tenemos el número del motor o chasis. En estos casos debemos elegir, según lo                             
que consideremos más apropiado en el dominio de nuestro problema, qué atributos serán                         
finalmente los identificadores. En este ejemplo, es esencial entender que debe elegirse uno                         
sobre el otro y no declararlos a ambos como atributos clave. Marcando a ambos como                             
identificadores, daríamos la pauta que se necesita el par matricula;número de motor para                         
determinar un auto.
Figura 5. Vemos dos veces la misma entidad con los mismos atributos. La entidad es Auto y                                 
los atributos son color, número de motor y matrícula. Como matrícula y número de motor son                               
posibles claves, debemos elegir una u otra opción, nunca ambas.
Recordemos que solo tomamos 2 o más atributos cuando uno solo no es suficiente para                             
determinar la unicidad de la entidad.
Ejemplos
Figura 6. Podemos ver en este grupo tres entidades con sus respectivos atributos,                         
destacando los que son clave con un subrayado.
Atributos Calculados
Pag. 9 ­ 59
Los atributos calculados son aquellos que demandan un cálculo a partir de otros atributos                           
para determinar su valor. Es decir, dependen del valor de uno a más atributos y de la                                 
fórmula que se defina para el cálculo.
Por ejemplo, el atributo calculado Edad en la entidad Alumno, depende del atributo fecha de                             
nacimiento y cuyo cálculo queda determinado por la diferencia entre la fecha actual y la de                               
nacimiento (en años). Otro ejemplo puede ser el atributo calculado clase, en la entidad                           
Matafuego, dependiendo del tipo de matafuego (A: incendios que implican sólidos, B:                       
incendios que implican líquidos inflamables, etc).
Estos atributos calculados se dibujan usando líneas punteadas en el ovalo.
Figura 7. Vemos dos entidades, alumno y matafuego. Con los atributos calculados edad y                           
clase. 
Note: es importante destacar que no hace falta explicitar la fórmula en el modelo o diagrama                               
realizado, pero si hay que tenerla presente para el futuro, cuando de este diagrama                           
conceptual obtengamos el lógico (o la base de datos en sí misma).
Atributos Multivaluados
Un caso particular de los atributos, es que cuenten con más de un valor para una instancia                                 
de la entidad a la cual pertenecen. A modo de ejemplo, la entidad Persona, posee en el                                 
atributo teléfono, la posibilidad de tener uno o más valores. Uno podría optar por definir un                               
número finito de atributos similares (teléfono1, teléfono2, etc.) o bien definir un atributo                         
multivaluado. 
Pag. 10 ­ 59
Estos atributos se dibujan con dos óvalos concéntricos. El nombre del atributo debe ser en                             
singular, por más que pueda almacenar más de un valor. Este tipo de característica nos                             
permite almacenar una indefinida cantidad de valores diferentes en dicho atributo para cada                         
uno de los elementos de la entidad. Por ejemplo, podemos tener para la persona Juan, los                               
teléfonos 4444­4444 y 2222­5555, y para la persona Ana, los números 5555­2222,                       
1111­2222, 6666­4444.
Como vemos, en un atributo multivaluado, cada objeto de la entidad, puede tener una                           
cantidad diferente de valores.
Figura 8. Aquí vemos tres personas con una cantidad diferentes de números de teléfonos.
Ejemplos de atributos multivaluados.
Figura 9. Vemos cuatro ejemplos de entidades con atributos multivaluados. La primera, es la                           
entidad Alumno, con el atributo multivaluado teléfono. Luego tenemos la entidad Celular, con                         
el atributo multivaluado aplicación. También la entidad Sillón, con el atributo color de tela,                           
como multivaluado, para almacenar diferentes colores para cada objeto sillón. Por último,                       
tenemos la entidad Libro, con el atributo multivaluado escritor, para indicar que puede tener                           
cada libro, uno o más escritores. 
Atributos Compuestos
Por último, tenemos los atributos compuestos. Estos atributos se utilizan para agrupar                       
atributos únicamente, colaborando a la visualización de la entidad y a su mejor                         
Pag. 11 ­ 59
entendimiento. Así, podemos tener el atributo dirección que podrá ser el atributo agrupador                         
de los atributos calle, piso, altura, departamento, etc.
La forma de graficarlo es asociando al atributo agrupador a la entidad con una línea. Luego,                               
los agrupados, asociados con una línea al atributo agrupador y no a la entidad.
Figura 10. En esta imagen vemos dos entidades. Primero Alumno, con el atributo compuesto                           
dirección. Este atributo está formado por calle, altura, piso y departamento. Luego,                       
tenemos la entidad Libro, con el atributo compuesto formato. Este atributo está compuesto                         
por los atributos color, columnas, tamaño de letra y tipografía. 
Relaciones
Las relaciones son quienes definen las acciones entre una entidad y otra. Se dibujan con un                               
rombo, con al menos dos conectores en las puntas horizontales, que servirán para asociar                           
las entidades que intervienen en dicha relación.
Figura 11. Vemos aquí, la forma de graficar una relación, con sus dos conectores a los                               
lados con trazo firme. 
Dentro de un mismo diagrama, los nombres de las relaciones no pueden repetirse.                         
Tampoco podemos utilizar para nombrar a una relación, algo diferente a una frase verbal o                             
un verbo, ya que es la forma de definir la acción que representa dicha relación.
Para evaluar una relación, tomamos una y solo una instancia de una entidad y aplicamos la                               
acción sobre otra instancia de la otra entidad asociada. Por ejemplo, si tenemos dos                           
entidades, Perro y Gato, y pensamos en que están relacionados mediante el verbo                         
“perseguir”, podemos definir la relación persigue a, o es perseguido por, pensando en un                           
perro en particular de toda la colección Perro y un gato en particular de toda la colección                                 
Gato.
Veamos lo mismo con algunos ejemplos Gráficos.
Pag. 12 ­ 59
Figura 12. Vemos aquí seis ejemplos más de relaciones. La primera relación, “Compuesta                         
por”, esta asociada a las entidades Empresa y sucursal. Luego, la relación “Trabaja en”, se                             
conecta con las entidades Persona y Organización. De forma similarsucede con las demás.
Normalmente, la forma de leer dicha relación es de izquierda a derecha, y de arriba hacia                               
abajo.
Figura 13. Tomando algunas de las relaciones de la figura 12, se ejemplifica cómo se debe                               
leer la relación que interviene entre las entidades.
Entre dos entidades de nuestro modelo, podemos tener ninguna o más relaciones, según la                           
necesidad o el problema que estamos resolviendo.
Pag. 13 ­ 59
Figura 14. Vemos en este ejemplo, dos entidades, Lector y Libro. Entre ellos, hay tres                             
relaciones que tienen significados diferentes. Las relaciones son Recomienda, Lee y                     
Comenta.
Esto sucede ya que, entre dos instancias de objetos de las dos entidades, pueden darse                             
ciertas combinaciones y ciertas no, según lo que la relación represente.
En el ejemplo anterior, podemos pensar que:
Figura 15. Vemos aquí tres representaciones de elementos de la entidad Lector y de la                             
entidad Libro. Cada representación hace referencia a posibles conexiones entre dichos                     
elementos, para que podamos entender cómo funcionan las relaciones y por qué muchas                         
veces debemos definir más de una relación entre dos entidades.
Pag. 14 ­ 59
Cardinalidad
Una vez comprendido que para evaluar las relaciones tenemos que considerar las                       
instancias de las entidades, debemos determinar cuántas instancias de cada entidad                     
pueden participar de la relación. Es lo mismo decir, si tenemos una acción, cuántos son los                               
que pueden provocarla y cuantos reciben dicho efecto.
Siempre la cardinalidad se define para cada uno de las entidades a las que está asociada la                                 
relación. Entonces, si tenemos dos entidades que están asociadas por una relación,                       
tenemos que evaluar la cardinalidad de la relación con respecto a ambas entidades.
Si tenemos las entidades Lector y Libro, podríamos tener la relación “Lee”, para decir que un                               
lector leyó algún libro. Ahora, si evaluamos la cardinalidad de la relación, debemos tomar un                             
lector hipotético (no Juan ni Ana) y pensar cuántos libros “puede haber leído”, para comenzar                             
de esta forma a definir la cardinalidad de la relación. Encontramos rápidamente que el                           
resultado a dicha pregunta es uno o más libros. Entonces, dado que UN LECTOR puede                             
leer UNO O MÁS LIBROS, decimos que la cardinalidad en la relación “Lee” es del tipo                               
“Muchos”, con respecto de la entidad Libro.
Evaluemos la relación ahora, pensando en la entidad Lector. Debemos pensar lo mismo                         
pero observando la acción o relación desde el punto de vista ahora del Libro. Repitamos el                               
proceso entonces, yendo desde Libro a Lector, es decir, considerando la misma relación                         
“Lee” ahora como la acción “fue leído por”. Tomemos entonces un libro hipotético, y                           
tratemos de pensar por cuantos lectores pudo haber sido leido. Rápidamente nos damos                         
cuenta que un libro pudo haber sido leído por más de un lector, como sucede con los best                                   
seller, por ejemplo. Encontramos que es una cardinalidad similar al caso anterior. Entonces,                         
dado que UN LIBRO puede ser leido por UNO O MÁS LECTORES, decimos que la                             
cardinalidad en la relación “Lee” es del tipo “Muchos”, con respecto de la entidad Lector.
Esta cardinalidad, definida como “Muchos”, se representa gráficamente como una N, en el                         
extremo correspondiente de la relación (en este caso ambos).
Figura 16. Volvemos sobre el mismo ejemplo anterior entre Lector y Libro, con las relaciones                             
Recomienda, Lee y comenta. Colocamos, para cada relación la cardinalidad. 
Como en ambos extremos de la relación tenemos N (o muchos), podemos decir que la                             
cardinalidad de la relación “Lee”  es de muchos a muchos, o N:N
Pag. 15 ­ 59
Figura 17. Vemos un ejemplo con objetos de la entidad Lector y la entidad Libro, tomando                               
solo la relación “Lee”. Podemos ver, que Juan, leyó dos libros, por lo tanto la cardinalidad de                                 
lee en Libro va a ser muchos (más de uno). Luego, vemos que el libro 100 Años de soledad                                     
fue leido por dos lectores, Juan y Ana. Entonces, la cardinalidad será muchos del lado de                               
lector para la relación Lee. 
Otro caso de cardinalidad puede darse donde uno de los elementos tomados de una entidad                             
se corresponde con un único objeto de la segunda entidad. Esto es conocido como                           
cardinalidad “Uno”.
Por ejemplo, si tenemos las entidades Localidad y Provincia, con la relación entre ellas                           
“Pertenece”, podemos definir la cardinalidad de la relación siguiendo estos pasos:
● Tomamos una localidad hipotética y transitamos la relación hacia provincia.                   
Descubrimos que está relacionada con tan solo una provincia, ya que una localidad                         
está geográficamente ubicada dentro de una provincia. Decimos entonces que la                     
cardinalidad de la relación “Pertenece”, del lado de Provincia es Uno.
Figura 18. Aquí vemos una relación entre localidad y provincia, indicando que para cada                           
localidad sólo puede existir una provincia. 
Pag. 16 ­ 59
Figura 19. Aquí vemos un ejemplo de elementos de las entidades Localidad y Provincia.                           
Como es lógico, una localidad sólo puede pertenecer a una provincia, ya que está dentro de                               
ella.
● Luego, para determinar la segunda parte de la cardinalidad, evaluemos desde la                       
entidad Provincia. Dada una provincia hipotética, cuántas localidades “pertenecen” a                   
ella. Nos encontramos que hay una Localidad o más dentro de dicha Provincia, por lo                             
que la cardinalidad del lado de localidad es Muchos.
Figura 20. Aquí vemos las entidades Localidad y Provincia, con la relación pertenece y su                             
cardinalidad N del lado de localidad.
. 
Figura 21. Se observa que cada provincia contiene una o más localidades. 
Finalmente, podemos ver la relación con la cardinalidad totalmente definida.
Pag. 17 ­ 59
Figura 22. Vemos la relación Pertenece con la cardinalidad totalmente definida, es decir, en                           
todos sus extremos. 
Este tipo de cardinalidad, donde en un extremo de la relación tenemos definido como                           
muchos y el otro extremo como uno, se define la cardinalidad como uno a muchos o                               
muchos a uno, o 1:N.
Puede existir, además, el caso donde un elemento de una entidad se relacione con un solo                               
elemento de la segunda entidad y viceversa. Por ejemplo, dada a entidad Alumno y la                             
entidad Persona, se define la relación entre ellas “Es una”.
Figura 23. Graficamos la entidad Alumno y la entidad Persona, con la relación Es Una. 
Veamos la cardinalidad de esta relación. Si tomamos un alumno A, se corresponde sólo con                             
una persona P, ya que un alumno sólo puede ser una misma persona y nunca dos o más.                                   
Entonces la cardinalidad de la relación del lado de Persona, es Uno. Ahora, si tomamos una                               
persona, siempre será uno y sóloun alumno, por lo que la cardinalidad del extremo de                               
Alumno también será Uno.
Figura 24. Vemos las entidades Alumno y Persona y la relación Es Una finalizada.
Opcionalidad
Se habla de opcionalidad en una relación cuando alguno de los elementos intervinientes                         
puede estar relacionado con ninguno o más, o cero o más elementos de la segunda entidad.
Esto se gráfica haciendo un círculo sobre la línea que conecta la relación con la entidad a la                                   
cual queremos referir la opcionalidad. 
Pag. 18 ­ 59
Figura 25. Podemos observar una relación, que tiene marcada en uno de sus conectores un                             
círculo que identifica la opcionalidad en la relación.
Algunos ejemplos que se pueden encontrar, son
Figura 26. Tenemos en esta imágen 4 entidades, Oficina, Empleado, Pc y Secretaria.Entre                         
Oficina y Empleado, la relación “Ocupada por” que, al estar marcada con opcionalidad, indica                           
que la oficina puede estar vacia, sin empleados que la ocupen. Mientras que el otro extremo                               
de la misma relación, nos indica que todos los empleados están ocupando una oficina.                           
Luego, Entre Empleado y Pc, tenemos la relación “Asignado A”, que nos indica que una Pc                               
siempre esta asignada a un empleado, mientras que no todos los empleados tienen                         
asignada una pc. 
Por último, Entre Secretaria y Empleado, tenemos la relación “Trabaja Para”, que tiene                         
marcada la opcionalidad en ambos extremos. Esto nos indica que un elemento de la entidad                             
Secretaria puede estar o no asignada a un empleado y viceversa. 
La opcionalidad es complementario a la cardinalidad, por lo que deben definirse 
ambas características en una relación. En este ejemplo nos concentramos únicamente 
en la definición de la opcionalidad y no de la cardinalidad, para simplificar el concepto.
Grado de una Relación
Las relaciones también están definidas según la cantidad de entidades que intervienen en su                           
definición. Hasta ahora, todos los ejemplos que hemos visto, fueron elaborados en base al                           
caso más común, donde una relación está asociada a dos entidades. 
Dado que el grado queda determinado según la cantidad de entidades que la relación                           
Pag. 19 ­ 59
conecta, las vistas hasta el momento, donde la relación conecta dos entidades diferentes se                           
las conoce como Binarias o grado dos. 
Luego tenemos las Unarias o de grado uno, donde la relación conecta dos veces a la                               
misma entidad. Pensemos en la entidad Empleado y la relación “Es jefe de”. Esta relación,                             
necesariamente tiene que tener ambos extremos conectados a la entidad Empleado, ya que                         
un empleado puede ser jefe de otros empleados. 
Por último, tenemos las relaciones de grado tres o Ternarias, término utilizado para                         
referirse a las relaciones que conectan a tres entidades (no necesariamente diferentes).
Por motivos de simplicidad, este modelo no permite un grado mayor que tres para sus                             
relaciones. Casos donde una relación de mayor grado sea requerida, deberá plantearse la                         
posibilidad de convertir dicha relación en una entidad concreta.
Relación Unaria
Como dijimos anteriormente, las relaciones unarias son aquellas que relacionan a una                       
misma entidad, pudiendo ser de Uno a Uno, Uno a Muchos o de Muchos a Muchos. 
Para identificarlas, debemos contemplar en la definición del modelo si existe una acción que                           
se genere en una entidad y se aplique sobre la misma. Casos ejemplos de esto pueden ser:
● Dada la entidad Persona, la relación “Es padre de”, se debe partir de una instancia                             
de la entidad persona y aplicar la acción en otra instancia de la misma entidad. En                               
este caso una persona, es padre de otra persona.
Figura 27. Vemos un grupo de elementos de una entidad Persona, y las conexiones entre                             
los progenitores y sus hijos.
● Si tenemos una entidad Auto y una relación “Fabricado a la par de”, la cual indica                               
qué auto fue fabricado en el mismo momento que otros, también tenemos necesidad                         
de utilizar una relación unaria, ya que debemos conectar objetos de una entidad con                           
otros objetos de la misma entidad.
Pag. 20 ­ 59
Figura 28. Tenemos varias ocurrencias de la entidad Auto, y vemos cuales fueron realizadas                           
al mismo tiempo.
La forma de graficar estas relaciones, sigue siendo un rombo conectando sus extremos a la                             
misma entidad. 
Figura 29. Muestra de una Relación Unaria. Vemos cómo los extremos del rombo conectan                           
la misma entidad.
Relación Binaria
Para las binarias no debemos agregar más de lo antes dicho, se debe graficar con un rombo                                 
y luego conectar con dos lineas horizontales a dos entidades. 
Figura 30. Ejemplo básico de una relación binaria. 
Relación Ternaria
Las relaciones ternarias se grafican con un triángulo en lugar de un rombo, y se conecta a                                 
las tres entidades que intervienen en la relación.
Pag. 21 ­ 59
Figura 31. Podemos ver cómo la forma de la relación cambia de un rombo a un triángulo y                                   
las tres puntas se conectan con las entidades. 
Para saber si tenemos necesidad de una relación ternaria debemos plantearnos lo siguiente:                         
La acción necesita de uno o más objetos de dos entidades para realizar la acción sobre una                                 
tercera. 
Veamos esto en un ejemplo: supongamos que deseamos saber, para una persona dada,                         
qué celular posee en cada compañía. Planteando el problema con relaciones binarias                       
tendríamos algo como esto:
Figura 32. Tenemos tres entidades, Persona, Celular y Compañía. La primera, relacionada                       
con Celular a través de la Relación “Tiene” y con Compañía a través de la relación “Contrata”.                                 
Luego Celular y Compañía se conectan con la relación “Opera con”. 
Mediante este modelo, podríamos responder las siguientes preguntas: cuáles son los                     
celulares que tienen las personas, en qué compañía están asociados los celulares y                         
finalmente las compañías que las personas tienen contratadas. No podríamos responder                     
nunca de esta forma, con qué compañia tiene contratada una persona un celular                         
determinado.
Para resolver esto, tendríamos que pensar que un elemento de Persona, llamemoslo P1, un                           
elemento de Celular, llamemos C1, están asociados a un elemento de Compañía E1.                         
Pensemos que esta asociación, la llamamos “Tiene un plan en”, para determinar que, una                           
persona (P1) con un celular (C1) tiene un plan en la compañía E1.
De este análisis surge la necesidad de utilizar una relación ternaria, y no varias binarias                             
como en el caso anterior.
Pag. 22 ­ 59
Figura 33. tenemos a izquierda, ejemplos de instancias para las entidades Celular, Persona                         
y Compañía. Luego, a derecha, tres ejemplos que combinan una instancia de celular, con                           
una instancia de persona, para determinar en qué empresa se tiene el plan.
Figura 34. De esta manera quedaría determinada la ternaria, conectando al rectángulo quela identifica, con las tres entidades, persona, compañía y celular.
Veamos la cardinalidad. Para definirla correctamente tenemos que siempre tomar dos                     
elementos de dos entidades y evaluar cuántos le corresponden de la tercera. Ahí se puede                             
definir si es cero, uno o muchos en la tercer entidad. Luego debemos pararnos en otras dos                                 
de las tres entidades y evaluar la restante. Definir si es cero uno o muchos en la restante y                                     
repetir el proceso una tercera y última vez. Hagamos un ejemplo para revisar esto, tomando                             
el caso anterior.
Si tomamos una Compañía E1 y una Persona P1, podemos decir que la persona P1 en la                                 
compañía E1 puede tener cero , uno o más Celulares, por lo que la cardinalidad en Celular                                 
es  muchos (N).
Pag. 23 ­ 59
Figura 35. Vemos la cardinalidad de la relación “Contrata” para la entidad Celular.
Luego, tomamos otro par. de Persona P1, y de Celular C1, y veamos cuantas ocurrencias                             
pueden tener en Compañía. Para lo cual nos debemos preguntar, la persona P1 con el                             
celular C1, ¿puede estar asociada a ninguna, una o muchas compañías? Para este caso, la                             
respuesta es que esta asociada a ninguna o a una. 
Por ende la cardinalidad de la relación en Compañía es uno.
Figura 36. Se agregó la cardinalidad para Compañía en la relación “Contrata”.
Finalmente, nos queda definir la cardinalidad de la relación para la entidad Persona. Por lo                             
cual, tomamos las entidades opuestas y verificamos. Tomamos una instancia de Compañía                       
E1 más una instancia de Celular C1 y nos preguntamos, para la compañía E1 y el Celular                                 
C1, ¿cuantas personas tienen asociadas? la respuesta para este caso es una, ya que dos                             
personas no pueden compartir la propiedad de un celular.
Entonces la cardinalidad es uno, ya que para cada par de celular y compañía, tengo una                               
sola persona. 
Finalmente vemos que la cardinalidad es de Muchos a Uno y Uno, o N:1:1
Pag. 24 ­ 59
Figura 37. Tenemos la cardinalidad completamente definida. N:1:1
Rápidamente evaluemos la opcionalidad en esta relación. 
Como en todos los casos es cero o uno, o cero o muchos, es opcional en todos los casos. 
Por lo que nos queda marcado en todos las líneas de la relación el círculo que nos indica la                                     
opcionalidad. 
Figura 38. Tenemos marcado además, la opcionalidad en la relación.
Atributos en las relaciones
Muchas veces, sucede que de la acción entre dos objetos se desprenden datos que para                             
nuestro diseño pueden ser pertinentes. Por tal motivo, deberíamos poder tenerlos en cuenta                         
de forma visible, es decir, graficarlos. Si estos datos son inherentes a la relación, deberían                             
asociarse a ella, ya que describen a la misma. 
Por ejemplo, si estamos considerando las entidades Perro y Gato y la relación “Mordió a”
Figura 39. Entidad Perro relacionada con la entidad Gato, mediante la relación “Mordió a”.
La información que nos da, nos indica cuáles perros mordieron a qué gatos. pero nos                             
gustaría ahora poder saber cuándo. Esa fecha, no podría estar en la entidad Perro, dado que                               
no podríamos distinguir en qué fecha la instancia de perro mordió a qué gato. 
Pag. 25 ­ 59
Tampoco podría estar en la entidad Gato el atributo fecha, ya que no podríamos distinguir                             
qué perro mordió a ese gato en esa fecha.
Figura 40. Si asignamos la fecha en que el perro muerde al gato en la entidad Perro, no                                   
sabríamos en que fecha mordió a cada gato. 
Figura 41. Se la fecha estuviera en la entidad Gato, y dos perros, por ejemplo el 1 y el 2                                       
mordieran al mismo gato, no sabríamos si la fecha corresponde a la mordida del perro 1 o                                 
del 2.
Entonces, debemos agregar un atributo en la Relación “Mordió a”, así sabemos que el perro                             
P mordió al gato G en la fecha indicada en ese atributo.
Pag. 26 ­ 59
Figura 42. En este caso, si asignamos fechas a la acción, “mordió a” podemos determinar                             
cuando un perro mordió a un determinado gato y cuando mordió a otro. 
Para graficar esto, debemos dibujar un atributo con un óvalo de la misma manera que                             
dibujamos los atributos de las entidades, pero en lugar de conectarlo con una línea recta                             
firme a una entidad, vamos a conectarlo a la relación a la que pertenece.
Figura 43. Vemos como el ovalo se asocia al rombo de la relación con una linea firme. 
Para el ejemplo anterior, en gráfico quedaría de la siguiente manera.
Figura 44. Tenemos la entidad Perro y la entidad Gato. La relación “Mordió a” con un atributo                                 
fecha. La relación es N:N
Atributos Clave en las relaciones
Existe un caso particular para las relaciones con atributos, y es cuando queremos que el par                               
de objetos de las dos entidades participantes de la relación se diferencien por cada vez que                               
se genera la acción que implica dicha relación. Esto se debe a que la instancia de relación                                 
carece de identidad propia, a diferencia de las entidades. Una instancia de relación se                           
identifica utilizando los atributos clave de las entidades que relaciona. 
Pag. 27 ­ 59
Por ejemplo, pensemos el caso que un alumno rinda un examen. Deberíamos modelar la                           
entidad Alumno y la entidad Materia, con los atributos claves DNI y COD_MAT                         
respectivamente. Unidas las entidades a través de la relación “Rinde”. Podemos, a esta                         
relación, agregarle el atributo Nota. Pero qué sucede si el alumno rindió más de una vez el                                 
exámen. Bien, agregamos un atributo Fecha. Una instancia de la relación, en este caso un                             
exámen rendido, queda identificado por un alumno y por la materia únicamente. Dado que                           
los alumnos pueden rendir varias veces la misma materia, queremos distinguir                     
unívocamente cada exámen.
Para solucionar esto, deberíamos tomar un atributo de la relación “Rinde” y definirlo como                           
clave de la relación. Esto es útil para estos casos, donde queremos extender las claves                             
propuestas por las entidades intervinientes haciendo uso de esta nueva clave parcial. 
Si decidiéramos tomar el atributo Nota como para agregar a la clave, no sería correcto, ya                               
que una misma persona, para una misma materia, puede tener la misma nota dos o más                               
veces. 
Veamos con el atributo Fecha. Si identificamos a la relación con el alumno, la persona y                               
ahora además la fecha, podemos decir que la persona con DNI 12345678 rindió la materia                             
M1 los días 05/01/2011 y los días 06/03/2011. Ahora si podemos distinguir los momentos en                             
que ocurrieron los dos exámenes, guiándonos en la persona, la materia y la fecha.
Figura 45. Tenemos las Entidades Alumno y Materia. Cada una con sus atributos. Luego, la                             
relación Rindió, con sus atributos Fecha y Nota. Para distinguir cuál es clave, se lo subraya                               
al igual que en una entidad.
Este concepto se entenderá mejor cuando más adelante tratemos la transformaciónhacia                       
un modelo lógico o Modelo Relacional (MR).
Entidades débiles
Hay veces que al generar un modelo, nos damos cuenta que ciertas entidades dependen de                             
la existencia de alguna otra entidad para poder existir en el dominio de nuestro problema. Por                               
otra parte, no pueden identificarse por sí solas, sino que requieren de esa otra para poder                               
hacerlo. Es decir, que sin tener la otra entidad a la que está fuertemente ligada, esta entidad                                 
no tendría razón de ser.  A estas entidades, las llamaremos entidades débiles. 
Un ejemplo clásico podría ser el diagrama de una biblioteca, donde se tienen las entidades                             
Ejemplar y Libro. En este caso, la entidad fuerte es el Libro, donde se determinan los                               
Pag. 28 ­ 59
atributos pertinentes a la publicación (nombre, autor, ISBN, etc.). Por otra parte, nuestra                         
biblioteca dispone de diversos ejemplares del mismo libro. Necesitamos almacenar datos de                       
los ejemplares como ser: número de ejemplar, estado, alumno que lo tiene prestado, etc. En                             
este caso, un ejemplar no tendría razón de ser sin el libro correspondiente. Si no existe el                                 
libro, no existen los ejemplares. Queda determinado de esta manera que la entidad Ejemplar                           
es una entidad débil.
Figura 46. Vemos instancias de libro y de Ejemplar. Como vemos, ejemplar no puede tener                             
al codigo de ejemplar como identificador, por que se repite. 
Entonces tenemos para cada libro, al menos un ejemplar, por lo que el código 1 de ejemplar                                 
se repetiría para cada uno de los libros que existan en nuestro esquema. Es por ello que las                                   
instancias de las entidades débiles quedan identificadas, en parte, por el identificador de la                           
fuerte correspondiente.
Figura 47. Si agrupamos el número de ISBN y el código de ejemplar, vemos que se forma                                 
entre los dos, una clave única, pudiendo así distinguir cada uno de los ejemplares. 
Los atributos que permiten diferenciar las distintas instancias de las entidades débiles se                         
denominan discriminantes. Finalmente, una entidad débil queda identificada unívocamente                 
por los atributos identificadores de la fuerte relacionada, más los discriminantes que ella                         
defina.
Pag. 29 ­ 59
Las entidades débiles se grafican con un doble rectángulo con líneas firmes, manteniendo el                           
nombre de la entidad dentro de los rectángulos. Se debe indicar además con doble línea la                               
relación hacia la fuerte correspondiente.
Figura 48. Entidades Ejemplar y Libro. Tenemos doble rectángulo sobre Ejemplar, para                       
definirla como débil. El discriminante se marca como un atributo identificador normal.
Es importante destacar que los atributos identificadores de la entidad fuerte que la débil                           
“hereda” no deben ser indicados en el diagrama, ya que se asumen de la relación. En                               
nuestro ejemplo, vemos que no debemos agregar un atributo ISBN en la entidad Ejemplar.
Por otra parte, una entidad débil podría relacionarse con más de una fuerte, quedando                           
identificada por la totalidad de los identificadores de las fuertes más los discriminantes.
Figura 49. Ejemplos de entidades débiles.
 
Pag. 30 ­ 59
Jerarquías o Herencias
Una jerarquía o herencia aparece en nuestro modelo cuando dos o más entidades tienen                           
ciertos atributos en común, y otros tantos específicos a cada una de ellas. 
Ilustrando el concepto con un ejemplo, pensemos las entidades Auto y Ómnibus, cada una                           
con los siguientes atributos: Para Auto, nro_patente, nro_motor, cantidad de puertas,                     
espacio_en_baul y color, mientras que para el Ómnibus tenemos nro_patente, nro_motor,                     
cantidad de butacas, baño, televisor y color. 
Como se observa, muchos atributos son comunes a ambas entidades, por lo que podemos                           
idear una entidad padre, también conocida como supraentidad o superentidad, que                     
agrupe a estos atributos. Normalmente, se define un nombre para esta nueva entidad,                         
común a ambas (para nuestro ejemplo “Medio de transporte”). Luego tendremos las                       
entidades específicas, también conocidas como subentidades, quienes contendrán               
únicamente los atributos específicos.
Una característica importante de las jerarquías es que las subentidades no poseen atributos                         
identificadores, sino que los “heredan” de la supraentidad. Es por ello, que al momento de                             
jerarquizar, deberán seleccionarse en la supraentidad únicamente aquellos atributos que                   
sean clave.
Figura 50a.  Tenemos las entidades Auto y Omnibus. Ambas con sus atributos.
Figura 50b. Tenemos los atributos comunes, y los desplazamos a la nueva entidad.
Pag. 31 ­ 59
Figura 50c. Resultado de la jerarquización de medios de transporte
Solapamiento
Una vez que tenemos definidas la supraentidad y las subentidades, debemos pensar si las                           
subentidades son solapables o no. En otras palabras, si una subentidad puede ser a su vez                               
otra subentidad diferente. 
En el caso de los Medios de transporte, esto es imposible, ya que un vehículo específico, o                                 
es Auto o es Omnibus (nunca ambos). Para estos casos, decimos que la jerarquía es                             
exclusiva o sin solapamiento. Esta restricción de las jerarquías se simbolizan con un arco,                           
según puede verse en el ejemplo.
Figura 51. Ejemplo de jerarquía exclusiva o sin solapamiento
Un ejemplo de jerarquía inclusiva o con solapamiento podría ser el caso de tener una                             
supraentidad Persona y las subentidades Alumno y Docente. Dado que la misma persona                         
puede ser Alumno y Docente a la vez, consideramos que en este caso puede haber                             
Pag. 32 ­ 59
solapamiento. Estos casos no requieren adicionar nada al gráfico, ya que son el caso menos                             
restrictivo, por lo que simplemente no dibujamos el arco.
Partición
La siguiente restricción que debe plantearse en una jerarquía es la partición. Una jerarquía se 
la considera de partición total cuando toda supraentidad debe tener al menos una 
subentidad que la especifica. En cambio, en una partición parcial, una supraentidad podría 
llegar a existir sin subentidad alguna. Es importante entender que este concepto es 
independiente del solapamiento.
Para nuestro ejemplo, un medio de transporte tiene que ser auto u ómnibus. No hay                             
conceptualmente medios de transporte que no sean alguno de estos dos. Por ende,                         
hablamos de una partición total. Simbolizamos esta restricción con una doble línea hacia la                           
supraentidad, según vemos en el ejemplo.
Figura 51. Ejemplo de jerarquía con partición total
Un caso de partición parcial podría ser dado por la supraentidad Empleado y las                           
subentidades Administrativo y Programador, cada una de estas últimas con sus atributos                       
específicos. Podríamos llegar a tener en nuestra empresa otros empleados que no sean ni                           
administrativos ni programadores (ej: limpieza) por lo que existirían instancias de entidades                       
Empleado sin contenerinstancias en alguna subentidad.
Al igual que en el caso de solapamiento, dado que la partición parcial es menos restrictiva                               
que la total, simplemente no se simboliza este caso en el diagrama. Se traza una línea                               
simple en lugar de doble.
 
Pag. 33 ­ 59
Atributo de Jerarquía o Discriminante
Si nos encontramos en el caso más restrictivo posible de jerarquía (partición total, sin                           
solapamiento), podemos optar por la definición de un atributo de jerarquía o discriminante.                         
Este atributo permitirá, desde el punto de vista de la supraentidad, determinar la subentidad                           
que la especifica. Este atributo puede ser uno ya existente en la supraentidad, o bien puede                               
definirse en este momento.
Dado que nuestro ejemplo posee este tipo de restricciones, definiremos un atributo que                         
permita identificar el tipo de medio de transporte que se especifica. Este atributo se dibuja                             
con un símbolo particular (cápsula) entre la supraentidad y las subentidades, según                       
podemos apreciar en el ejemplo.
 
Figura 51. Ejemplo de atributo de jerarquía o discriminante. En este caso, el atributo “Tipo” permite reconocer                                 
la subentidad correspondiente al medio de transporte.
Cabe destacar que, como este concepto aplica unicamente para esta forma de restricción                         
(partición total, sin solapamiento), pueden omitirse los símbolos particulares de las                     
restricciones ya que queda determinado por el del atributo.
 
Pag. 34 ­ 59
2.3.1. Ejemplos simples
1.Realice un diagrama según la siguiente definición:
Los profesores de la cátedra de Computación 1 nos encargaron realizar una                       
base de datos para administrar los alumnos que cursan la materia en el año                           
en curso, para de esa manera poder llevar un control de la asistencia, de los                             
trabajos prácticos entregados (este año solo habrá trabajos prácticos                 
individuales) y de las notas de  los parciales (y recuperatorios) de cada uno.
Primero, debemos realizar un pequeño análisis, lo cual nos lleva a identificar las posibles                           
entidades. A simple vista, leyendo el enunciado, debemos buscar aquellas posibles                     
colecciones de cosas u objetos o elementos. Podemos tomar a los Profesores, la cátedra no                             
es necesaria por ser una sola, los alumnos, el control de la asistencia, los trabajos prácticos                               
y las notas. Dado que no hay definición de cómo interactúan los profesores, ni con los                               
trabajos práctico,s ni con la corrección, los podemos descartar. 
Refinando un poco este análisis, detectamos que, para almacenar la asistencia, las notas de                           
los parciales y el estado de los trabajos prácticos, debemos considerar una entidad Alumno.                           
Para validar la asistencia, deberíamos tener una entidad Clase, ya que “Asistir” es una                           
acción del alumno con respecto a la clase. Siguiendo esta línea de pensamiento, podemos                           
tener una entidad Parcial, donde almacenar el parcial en sí y luego mediante una relación                             
conectar al alumno con el parcial, para definir la presentación y la nota que tuvo en dicho                                 
parcial. Lo mismo podemos hacer para los trabajos prácticos. 
Veamos como nos quedaría el diagrama. 
 
Pag. 35 ­ 59
2.Realice un diagrama según la siguiente definición:
Se tiene un equipo de fútbol, el cual consta de Director técnico, jugadores de                           
campo, ayudante de campo, preparadores físicos, arqueros. Los jugadores,                 
pueden alternar la posición de arquero con la de jugador de campo. De todos,                           
queremos saber los nombres, apellidos, nacionalidad y fecha de nacimiento. 
Para los jugadores, queremos saber qué posición ocupa en la cancha, y qué                         
número de camiseta tiene. Para el cuerpo técnico, es decir el director técnico,                         
el ayudante de campo y los preparadores físicos, se desea almacenar, el                       
sueldo y la fecha de ingreso al club.
Primero, debemos detectar las posibles entidades. Vemos que hay diferentes roles o                       
puestos dentro del club, que se pueden agrupar en: Los “jugadores” y los “técnicos”. Ambos                             
comparten cierta cantidad de atributos y luego tienen atributos específicos. Además,                     
presuponemos que un jugador no será al mismo tiempo técnico y viceversa. Para esto,                           
debemos hacer una jerarquía. Como una persona no puede ser jugador y técnico a la vez,                               
determinamos que será sin solapamiento. Por otra parte, toda persona debe ser jugador o                           
ser parte del cuerpo técnico (partición total). Esto nos lleva al caso más restrictivo, por lo                               
que definimos un atributo discriminante para determinar el “Tipo” de persona.
 
Pag. 36 ­ 59
2.3.2. Ejemplo complejo
“Se desea confeccionar un nuevo sistema para poder almacenar las llamadas que recibe el                           
Call Center de la empresa “Compre YA S.A.”. Los llamados pueden corresponderse con                         
compras de productos o bien reclamos que se realicen de los mismos. Cada llamada será                             
registrada con una identificación que corresponderá con C ó R + Nro. Unívoco (por ejemplo,                             
C101 corresponde a una compra 101 y R102 corresponde con un reclamo 102). Además, la                             
llamada registra el número de teléfono del cual provino la llamada, la fecha y hora de llamado                                 
y número de línea interna por la que ingresó el llamado. Otro de los datos a registrar, es la                                     
persona que ha realizado el llamado, la cual llamaremos Contacto. Todo contacto debe                         
identificarse a través del tipo y número de documento y además, deberemos registrar su                           
nombre, apellido, fecha de nacimiento y datos domiciliarios para poder enviar el pedido.
Tanto las compras como los reclamos se registrarán con una codificación unívoca para                         
poder identificarlos ante un siguiente llamado.
Para el caso de los reclamos, se deberá registrar cada uno de los comentarios que realice                               
el contacto en forma explícita. Si una persona vuelve a llamar para ver el avance de su                                 
reclamo, deberá indicarnos el número de reclamo y podremos verificar su estado (R:                         
resuelto, E: en evolución, S: sin analizar). Si lo desea, el contacto podrá adjuntarnos un                             
nuevo comentario de ese reclamo en cada una de las llamadas. Toda llamada, debe indicar                             
el comentario que ha realizado sobre un determinado reclamo.
Para el caso de las compras, deberá indicar la fecha de realización de la compra, el medio                                 
de pago y si es necesario, persona autorizada para recibir el pedido. Si la compra se                               
concreta, se generará la factura indicando todos los productos que haya comprado. Se debe                           
tener en cuenta que las facturas deben poseer un número unívoco, fecha de compra y datos                               
que identifiquen a la persona que lo compró. No todas las compras pudieron haber generado                             
la factura, ya que al derivarseal sector de compras, analizarán y autorizarán la compra.
Las llamadas son atendidas por operadores, los cuales poseen una identificación, fecha de                         
ingreso a la empresa, nombre, apellido, tipo y número de documento. Existen operadores                         
Junior y Senior. Cualquier operador podrá atender una llamada, pero sólo a los operadores                           
Senior se le podrán derivar los reclamos para que luego realicen el seguimiento. De los                             
operadores Junior queremos saber la antigüedad en la empresa. Existen operadores                     
coordinadores, los cuales poseen un grupo de operadores a su cargo.”
 
Pag. 37 ­ 59
 
Pag. 38 ­ 59
2.4. Modelo Relacional (MR)
Como parte del proceso de diseño de una base de datos, una vez obtenido nuestro modelo                               
conceptual, abstracto o de alto nivel (DER), debemos proceder a transformarlo en un                         
modelo lógico llamado Modelo Relacional (MR). Este modelo derivará finalmente en aquel                       
que implementaremos en nuestra base de datos.
Existen hoy en día muchas herramientas que, además de permitirnos graficar el Diagrama                         
Entidad Relación, nos sirven para generar de forma automática el Modelo Relacional. Estas                         
herramientas se llaman “Herramientas CASE” (por Computer Aided Software Engineering,                   
o Ingeniería de Software Asistida por Computadora). 
Como podemos vislumbrar, si esta conversión la puede realizar un programa, es porque es                           
en base a un procedimiento ya establecido y pensado. Por ende, iremos descubriendo este                           
pasaje en forma detallada, indicando los pasos a realizar y observando los diferentes                         
elementos que componen éste modelo.
Elementos del Modelo Relacional
El modelo relacional consta de Relaciones, Atributos y Restricciones de estos, por ende,                         
todo elemento del DER, derivará en algunos de estos. Este modelo tiene como                         
particularidad que es un modelo escrito, no gráfico.
Relaciones
Una Relación es un conjunto de instancias del mismo tipo, definido en base a los atributos                               
que la componen. También se conocen en este modelo como tablas. Las mismas se                           
describen a través de los atributos o campos y a las diferentes instancias que las                             
componen se las denomina tuplas o filas.
No deben confundirse este tipo de relaciones del MR (del inglés Relation) con las del DER                               
(del inglés Relationship). 
Por ejemplo, son relaciones de un MR: Persona, Gato, Empleado, Oficina, etc. 
Señalaremos nuestras relaciones dentro del modelo con el nombre de la relación, con su                           
primera letra en mayúscula y el resto en minúscula. Si el nombre consta de más de una                                 
palabra, suprimiremos el o los espacios entre las palabras y los reemplazaremos por                         
guiones bajos. Luego del nombre, encerraremos a los atributos que la componen entre                         
paréntesis. 
Relación(atributos)
Persona(...)
Auto(...)
Telefono(...)
Pag. 39 ­ 59
Atributos
Al igual que en las entidades, los atributos son quienes describen y diferencia las instancias                             
entre las distintas relaciones. Se escriben a la derecha de la relación, separados por comas,                             
normalmente en minúsculas. Al igual que los nombres de las relaciones, si tienen mas de                             
una palabra, no se pueden utilizar espacios, por lo que se pueden reemplazar por guiones                             
bajos. 
La forma de distinguir un atributo de otro es por su nombre, por lo que no podemos tener dos                                     
atributos con el mismo nombre.
Persona(nombre, apellido, color_de_ojos, color_de_pelo)
Auto(color, marca, modelo, cantidad_de_puertas, nro_de_motor)
Telefono(numero, dueño, )
Pais(nombre, continente)
Clave Primaria (PK)
La primera de las restricciones a tratar, es la denominada clave primaria (PK, del inglés                             
Primary Key). La misma esta formada por atributos clave, quienes identifican y diferencian                         
las distintas instancias o tuplas de la relación. Puede existir más de un atributo clave por                               
relación, de la misma manera que sucedía en las entidades del modelo relacional. En este                             
caso, el conjunto de atributos, determinará la clave primaria. 
La forma de diferenciar un atributo clave de uno que no lo es, es subrayando con una línea                                   
firme debajo del atributo clave. 
Empleado(legajo, nombre, apellido, edad, nro_documento)
Departamento(codigo, piso, nombre, lugar)
Projecto(Proj_nro, nombre)
Persona(tipo_doc, nrodoc, nombre, apellido, edad, nacionalidad)
Vemos que en Empleado, podrían distinguirse únicamente las instancias de la relación tanto                         
por el legajo como por el número de documento. Por lo tanto debemos elegir uno sobre el                                 
otro.
Para el caso de persona, se decidió tomar el tipo y el número de documento para identificar                                 
a una persona de forma única, ya que con solo el número de documento no nos alcanza                                 
para identificarla. Ambos forman la clave primaria.
Pag. 40 ­ 59
Figura 54. Tenemos un grupo de instancias de la relación Empleado, e intentamos agregar                           
instancias nuevas. Vemos que podemos tener valores repetidos en cualquier atributo,                     
menos en la clave. 
Figura 55. Ejemplo de instancias de la entidad Persona, donde vemos una instancia que no                             
puede ser agregada y la explicación de por qué si son válidas las ya existentes. 
Pag. 41 ­ 59
Claves Foránea (FK)
Otra de las restricciones que permite garantizar la consistencia de nuestra base de datos es                             
la clave foránea (FK, del inglés Foreign Key). Esto implica transportar los atributos que                           
componen la clave primaria de una relación a otra relación, para que esta segunda sólo                             
tome valores válidos, que se encuentren en la primera. 
Si por ejemplo tenemos la relación País, con el atributo nombre, este atributo será clave o                               
identificador de la relación
País (nombre)
Luego, tendremos la relación Televisor, con los atributos número de serie (como                       
identificador), modelo y pulgadas. 
Televisor (nroSerie, modelo, pulgadas)
Si queremos señalar donde fue armado el televisor, deberíamos tener un atributo                       
“armado_en”, donde colocaríamos el país. 
Televisor (nroSerie, modelo, pulgadas, armado_en)
Figura 56. Vemos ejemplos de objetos de las relaciones Televisor y País.
Pag. 42 ­ 59
Si queremos que las únicas posibilidades para completar el campo “armado en” sean                         
aquellas instancias de la relación País, deberíamos definir una clave foránea incluyendo a                         
este atributo. Con solo indicarlo, quedará establecida la restricción.
Figura 57. Vemos elementos correctos y uno incorrecto.
La forma de discriminar estos atributos foráneos de otros, es escribiendolos en negrita o                           
haciendo un subrayado punteado debajo del atributo. 
Muchas veces, se define el nombre de dicho atributo anteponiendo el nombre de la Relación                             
a la que apunta, y luego el nombre pensado para dicho atributo, pudiendo así identificar                             
rápidamente a qué relación se esta asociando dicho atributo. 
Tomando lo anterior, nos quedaría
Pais(nombre)
Televisor (nroSerie, modelo, pulgadas, armado_en)
En caso de que armemos el nombre del atributo de la clave foránea en base a la relación                                   
que referencia, podría definirse de la siguiente manera
Pais (nombre)
Televisor (nroSerie, modelo, pulgadas, pais_armado)
Clave Primaria y Foránea
Existe la posibilidad de que tengamos un caso donde un atributo identificador también sea                           
obtenido de otra relación y que cumpla con ambas condiciones. Por ende, estamos                         
definiendo dos restricciones a un solo atributo o grupo de atributos. 
Veamos un ejemplo donde se cumple esta condición,
Pag. 43 ­ 59
Figura 58. Tenemos tres instancias en la relación Persona. Las dos primeras participan de                           
la relación Alumno y la última de la relación Docente. Vemos que DNI es clave en las tres                                   
entidades, pero en Alumno y Docente además es foráneo.
Para visualizarlos a la hora de hacer el MR, hacemos el subrayado habitual para los                             
atributos claves y podemos o colocarlos además en negrita o también agregar un subrayado                           
punteado. La figura 68 quedaría de la siguiente forma el  MR.
Persona (dni, nombre, apellido, fec_nac)
Docente (dni, cargo, fec_ingr)
Alumno (dni, promedio, sexo)
 
Pag. 44 ­ 59
Reglas de transformación. Desde el DER al MR
Las reglas de transformación nos guían para mostrarnos la conversión entre un Diagrama                         
Entidad­Relación y un Modelo Relacional. Aplicando una sucesión de pasos, obtendremos                     
un único MR a partir de un DER.
De Entidades simples a Relaciones. 
Todas las entidades que tenemos en nuestro DER se transformarán en Relaciones dentro                         
de nuestro MR. Tomaremos el nombre de la entidad como nombre de la relación, los                             
atributos claves para definir la PK, y el resto de atributos de la entidad también serán                               
incluidos dentro de la relación resultante. 
Figura 59. Transformamos la Entidad Auto del DER en la relación Auto en el MR. Tomamos                               
el nombre de la entidad, su clave y el resto de atributos.
De Entidades y Relaciones a Relaciones. 
Si tenemos un caso de dos entidades y entre ellas una relación y queremos proceder a la                                 
traducción al modelo relacional, deberemos tener en cuenta la cardinalidad y la opcionalidad                         
de la relación para saber cómo proceder. 
Veamos el caso de las relaciones Binarias de 1:1 sin opcionalidad.
Se crearán las relaciones correspondientes a cada entidad y luego, para la relación                         
propiamente dicha, debemos crear un atributo foráneo en una de las dos relaciones para                           
simbolizar la relación existente entre las entidades. Este atributo foraneo, podemos incluirlo                       
en cualquiera de las dos relaciones resultantes, pero no en ambas (una u otra)
Pag. 45 ­ 59
Figura 60. Tenemos Dos Entidades y una relación guía (1:1) en un DER. Podemos traducir                             
en caso izquierdo, donde colocamos un atributo foráneo en Aprendiz, o en caso derecho,                           
donde colocamos el atributo foráneo en Tutor.
En el caso de las relaciones Binarias de 1:1 con opcionalidad en ambos extremos, la                             
traducción es equivalente a lo antes visto. 
Figura 61. En un DER con una Relación con ambas conexiones como opcionales, tenemos                           
la misma solución que en el caso anterior.
Por último, el caso donde tenemos una relación Binaria 1:1 con opcionalidad en sólo                           
Pag. 46 ­ 59
un extremo. Aquí, tenemos una entidad mandatoria y es aquella donde no se señala la                             
opcionalidad. En este caso, debemos definir el atributo foráneo en la relación resultante del                           
MR que tiene asociada la opcionalidad. 
Figura 62. Vemos el caso de una relación unaria con opcionalidad en un solo extremo.
Siguiendo este camino, tomaremos ahora el caso de las relaciones Binarias con                       
cardinalidad 1:N.
Cuando las relaciones son 1:N, no se tiene en cuenta la opcionalidad al hacer la                             
transformación. Siempre debemos tomar el/los atributo/s clave de la entidad que se                       
encuentra del lado de la cardinalidad 1 y transportarlos a la relación resultante de la Entidad                               
que tiene la cardinalidad N. Es decir, se agregan nuevos atributos en la relación                           
correspondiente al lado de la N.
Pag. 47 ­ 59
Figura 63. Vemos un ejemplo de dos entidades y una relación N:1 y su transformación a MR
Figura 64. Tenemos una relación con opcionalidad a ambos lados. Enviamos las claves de                           
la entidad del lado de Secretaria a Jefe.
Analizamos el caso de las relaciones Binarias con cardinalidad N:N.
Cuando tenemos este tipo de relaciones Binarias, debemos crear una nueva relación en el                           
MR, con el nombre de la relación N:N. Esta nueva relación, contendrá como atributos los                             
atributos claves de las entidades que intervienen en la N:N. y estos a su vez, formarán las                                 
claves foráneas correspondientes a las relaciones que referencian..
Figura 65. Relación binaria N:N
Pag. 48 ­ 59
Figura 66. Ejemplo de instancias de la figura 65.
En el caso en que la Binaria N:N tenga un atributo, ese atributo formará parte de la nueva                                   
relación creada.
Figura 67. Tenemos una Relación de un DER con atributo y lo agregamos a la relación                               
resultante en el MR.
Si uno de los atributos de la relación fuera clave, también será clave en la nueva relación.
Pag. 49 ­ 59
Figura 68. Vemos a la Relación Examen en el DER y efectuamos la traducción a MR.
Nos enfocaremos ahora en el caso de las relaciones Unarias 1:1 y 1:N. En este caso, no                                 
debemos preocuparnos ni por la cardinalidad ni por la opcionalidad. Siempre la traducción se                           
hará de la misma manera, salvo en el caso de las unarias N:N.
La forma de realizar el traspaso de las unarias es generar un nuevo atributo en la relación                                 
resultante que represente la relación unaria, y que será marcado como foráneo, pero que en                             
realidad referirá a la clave de dicha entidad. 
Veamos un ejemplo. Si tenemos la entidad Persona con los atributos DNI como clave,                           
nombre y apellido y la relación unaria “Casado_con”. Al traducir al MR, debemos tomar los                             
atributos de la entidad Persona, dni, nombre y apellido. Luego, debemos traducir                       
“casado_con”. Si mantenemos la idea de las binarias, es decir, agregar un atributo en una                             
de las relaciones resultantes, aquí deberíamos hacer lo mismo. Dado que sólo tenemos una                           
relación resultante, es ahí donde debemos colocar el atributo foráneo, que hace referencia,                         
en lugar de a una clave de otra relación, a la clave de la misma relación.
Figura 69. Transformación de una entidad con una relación unaria.
La misma traducción haremos cuando sea una 1:N, tengan o no opcionalidad.
Pag. 50 ­ 59
En el caso de las relaciones Unarias N:N, realizaremos el mismo procedimiento que las                           
binarias de igual cardinalidad. Como solo tenemos una entidad, tomamos la clave de dicha                           
entidad, pero recordando que interviene dos veces, por lo que debemos tomar dos veces                           
la clave de dicha entidad. 
Figura 70. Generamos