MODELO ENTIDAD-RELACIÓN

-
 DESARROLLO

Para una mejor explicación de los términos entidad, atributo y relación nos apoyaremos en el
lenguaje DDL usado por PostgreSQL para demostrar ejemplos a lo largo de esta guía. El lenguaje
DDL (Object Definition Lenguage = Lenguaje de Definición de Objetos) fue creado con el fin de
especificar la estructura de las bases de datos en términos orientados a objetos. Dicho de otra manera,
DDL es la parte del SQL que más varía de un sistema a otro ya que esa área tiene que ver con cómo
se organizan internamente los datos, es decir, toda la estructura (tablas, esquemas, relaciones). Cada
sistema lo hace de una manera u otra.

Nota: En los recursos de esta Unidad se encuentra una guía de instalación para PostgreSQL.

1. Conjuntos entidad, relación

Como el propósito a tratar en este documento es explicar la estructura de las bases de datos en un
enfoque orientado a objetos, se entiende por entidad toda colección de objetos del mundo real que
contienen propiedades en común, por ejemplo, una persona, un edificio, una cuenta bancaria, un
curso escolar. Es importante que tengan una identificación única que los distinga de cualquier otro.
Hagamos un ejemplo, una persona tiene nombre, estatura, edad, sexo y estrato entonces estas
propiedades la convierten en un objeto y éste objeto pertenece a una entidad persona. La forma de
definir la entidad o tabla persona en PostgreSQL y en un diagrama E/R es:

Figura 1 Creación de una entidad en PostgreSQL

Persona

Figura 2 Creación de una entidad en E/R

Los atributos son propiedades de las entidades, que describen algún aspecto de un objeto. Por
ejemplo, los objetos persona pueden tener los atributos nombre y estrato cuyo tipo sería una cadena
y un entero respectivamente. La declaración de los atributos de la entidad persona quedaría así:

Figura 4 Entidad y Atributos PostgreSQL

Figura 3Entidad y Atributos diagrama E/R -

Los atributos dan a entender el objetivo específico por el cual fue creado un objeto. A partir de las
entidades se genera el termino relación que nace de la necesidad de corresponder varios objetos. Por
ejemplo, la entidad persona podría estar relacionada con otra llamada factura. Ahora, las relaciones
entre entidades tienen tres variantes:
 • Relación uno a uno:

Este tipo de relaciones no son muy comunes, para explicarla mejor tomemos el siguiente
ejemplo, un profesor solo puede ser director de un curso y a la vez un curso solo puede
ser dirigido por un profesor.

• Relación uno a muchos:

Retomemos el ejemplo anterior cada persona puede tener varias facturas, pero una factura
solo puede ser de una persona. La diferencia 2.2 Atributos, claves, super-claves, claves
candidatas y claves primarias 11 entre uno a muchos y muchos a uno solo es el sentido de
la relación. Esta relación es la más usual, su manipulación es relativamente fácil.

• Relación muchos a muchos:

Esta relación es algo problemática, el implementarla en una base de datos e intentar hacer
una simple consulta todo se complica si no está bien diseñada. Veamos un ejemplo, un
profesor puede dictar clase en un cursor y a su vez un curso puede tener varios profesores.
Si queremos saber que profesores imparten clase en un curso sería un problema. Hay que
evitar estas relaciones creando tablas intermedias las cuales hacen que existan dos
relaciones de uno a muchos, ampliando así el rendimiento de las consultas y reduciendo el
trabajo para el programador. Dicho lo anterior la manera de resolver la relación es creando
otra llamada, por ejemplo, ProfesorCurso la cual se lleva los identificadores de cada objeto
para conformar la tabla.

En este orden de ideas nacen otros conceptos, claves, super-claves, claves candidatas y claves
primarias. Para hacer referencia a un objeto de alguna entidad es necesario contar con un atributo
el cual sea totalmente diferente al resto, de aquí nacen las claves, son elementos que por lo general
son valores enteros que cambian de forma exponencial acorde aumentan los datos en la base datos,
por ejemplo, si hay una tabla usuarios con mil registros, al momento de ingresar cada usuario esta
clave aumenta su valor sumando uno, así cada objeto usuario tomará una clave distinta llamada en
base de datos clave primaria. Otro caso, por ejemplo, sería que en la tabla usuarios existiera un
campo único como el documento de identidad o cedula de ciudadanía. Para esta entidad la clave
primaria podría ser un entero incrementable y la cedula de ciudadanía una clave candidata,
pudiendo ser ésta una clave primaria sin problema puesto que su valor es identificable
inequívocamente, es decir, no se repite. El termino super-clave representa al atributo o conjunto de
atributos aptos para la representación de los objetos, es decir, no es necesario que la clave contenga
más de un atributo para considerarse super-clave, por ejemplo, la cedula de ciudadanía es una super-
clave sin problemas.

3. Relaciones Multidireccionales
 Cuando se crean relaciones muchos a muchos, como se dijo anteriormente la forma de
solucionarlo es usando entidades conexión, creando así relaciones de muchos a uno.

Alumnos Matriculas Materias

Calificaciones

Figura 5 Relación de tres direcciones

En el esquema anterior se muestra una relación matriculas que incluye un alumno, una materia y
una calificación. Básicamente lo que expresa es que un alumno matriculado en tal materia tiene
cierta calificación.
La flecha que va de matrículas a calificaciones se denomina relación multidireccional en un
diagrama E/R. Indica que si cogemos cualquier entidad ya sea alumnos o materias, está
relacionada con una entidad única de calificaciones. Dicho de otra manera, para un alumno y
materia determinada hay solo una calificación.

4. Papeles en las relaciones

Es posible encontrar que una entidad este presente varias veces en una sola relación, en estos casos
se trazan tantas líneas de la relación a la entidad como veces aparezca la entidad en la relación.
Entonces bien, cada línea trazada de la entidad a la relación y viceversa tendrá un nombre y una
función representativa diferente a la cual llamaremos papel.

Figura 6 Papeles
 En la figura anterior aparece una relación versión-de entre el conjunto entidad canciones y el mismo.
Indicando entonces que una canción puede tener una o más versiones, para diferenciar las canciones
en la relación se asignan los papeles original y versión. Se supone que una canción puede tener una
o más versiones, por ejemplo, original, remix, instrumental (sin la voz del interprete), a capela, etc.
Pero una versión solo puede tener una canción original.
Se deduce entonces que existe una relación de muchos a uno entre las canciones versión y las
canciones original, por tal razón, la flecha que va de la relación versión-de a la entidad canciones
tiene esa dirección.
Nota: En un diagrama E/R las flechas indican la multiplicidad1 de las relaciones.

5. Atributos en las relaciones

En ocasiones es más apropiado asignar atributos a las relaciones que a uno de los conjuntos entidad
que conecta la relación. Consideremos la figura 5, representa la calificación de un estudiante en una
determinada materia. Supongamos que queremos registrar el profesor asociado a la matricula. No
se podría agregar al estudiante, éste puede tener diferentes profesores por cada materia. Por otro
lado, sería absurdo asociar al profesor a las calificaciones. Una opción válida es asociarlo a la entidad
materias, pero esto solo funcionaria si un solo profesor dicta esa materia, es decir, una materia puede
ser dictada a lo sumo por un profesor.

Figura 7 Relaciones y atributos

1
Si existe una relación de muchos a uno entre una entidad A y B, la flecha debe apuntar a B. Indicando que cada
entidad del conjunto A se relación a lo más con una entidad de conjunto B.
 Es algo prematuro decir que profesor puede ser atributo de matrícula, pero asumamos que ese
atributo solo es una cadena de texto con el nombre del profesor. Ocurre que profesor tiene atributos
por si solo y se consideraría entidad además no es necesario poner atributos en las relaciones, para
ello se inventa una nueva entidad con los atributos de la relación.

Figura 8 Entidad Profesor

Al incluir la entidad profesor se omiten los atributos de la relación.

Nota: Para entender mejor el ejemplo llame a la relación matriculas curso, entendiéndose como curso
el conjunto de materias impartidas por un profesor a varios estudiantes que tienen una calificación.

6. Agregación

Es un concepto abstracto que surge de la limitación en el modelo E/R al no permitir expresar las
relaciones entre relaciones. Las relaciones se tratan como entidades de nivel más alto. Dicho lo
anterior hagamos un ejemplo para que todo quede claro. Suponga que tenemos dos entidades
profesor, asignatura. Un profesor puede impartir muchas asignaturas y ésta impartida por muchos
profesores, se crea una relación muchos a muchos.
 Figura 9 Relación Profesores - Asignaturas

Bien, ahora supongamos que los profesores pueden usar implementos para dictar las clases, es
decir, un profesor que imparte una asignatura A puede usar un implemento X (tablero, por
ejemplo) un día, otro día usa un video beam con la misma asignatura. Lo más lógico es pensar
esto:

Figura 10 Agregación Incorrecta

Pero no, las relaciones entre relaciones en el modelo E/R como se dijo anteriormente no están
permitidas. Es aquí donde entra la agregación, ésta si permite dicha relación, ahora solo hay que
agrupar los conjuntos entidad profesores y asignaturas y relacionarlo con implementos así
 Figura 11 Agregación Correcta

Ahora sí, los profesores pueden hacer uso de cualquier implemento para cualquier asignatura. En
el modelo relacional que se verá en la siguiente guía se tratará este ejemplo para seguir explicando
y suplir alguna duda.

Otro ejemplo de una correcta agregación

Figura 12 Agregación Correcta 2

Asuma la explicación anterior y aplíquela en este ejemplo.

• Exprese la base de datos en el modelo E/R para un banco que contenga información
sobre los clientes y sus cuentas. La referente a un cliente incluye su nombre, dirección,
teléfono y número de Seguro Social. Las cuentas tienen números, tipos (por ejemplo,
ahorros, cuentas de cheques) y saldos. También necesitamos registrar el cliente o
clientes titulares de la cuenta.

• Exprese en el modelo E/R la base de datos que registre la información relativa a

▪ Para cada equipo: Su nombre, sus jugadores, el nombre de su capitán (uno de los
jugadores) y los colores de su uniforme.
▪ Para cada jugador: Su nombre.
▪ Para cada aficionado: su nombre, los equipos favoritos, los jugadores favoritos
y el color favorito.
 BIBLIOGRAFIA

• Jeffrey, U, Introducción a los sistemas de bases de datos, Ed. Pearson Educación, 1999.
• De Miguel, A.; Piattini, M, Concepción y Diseño de Bases de Datos. Del Modelo E/R al Modelo
Relacional. Ed. RaMa, 1993.
• Santos, E, Bases de Datos.,Ed. Servicio Publicaciones de la E.U. de Informática, 1998.
• Fernández, C, El Modelo Relacional de Datos: De los Fundamentos a los Modelos Deductivos. Ed.
Diaz de Santos, 1987.
• Date, C, Introducción a los Sistemas de Bases de Datos , Ed. AddisonWesley Iberoamericana, 1990.
• Hursch, C; Hursh, J, SQL. El Lenguaje de Consulta Estructurado, Ed. RaMa, 1998.
• Kprth, H, Fundamentos de Bases de Datos, Ed. McGrawHill, 1998.
• Hector García-Molina, Jeffrey Ullman, and Jennifer Widow, Database systems: the complete book,
Addison Wesley, 2001.
• Pang-Ning Tan, Michael Steinbach, Vipin Kumar, Introduction to datamining, Addison Wesley,
2006
• Hastie Trevor, Tibshirani Robert, Friedman Jerome, The elements of stadistical learning: data
mining, inference, and prediction, Springer, 2009