Este es un modelo que nos permitirá “dibujar” las entidades y las relaciones que existen entre ellas. Nosotros usaremos el modelo “Entidad-Relación Extendido” (EER, de aquí en adelante). Existen varias notaciones ligeramente distintas. Voy a utilizar la que considero más sencilla.
En esta notación se representan las entidades como un rectángulo y las relaciones binarias como un rombo partido por la mitad. Si la relación es 1:M, una de las mitades (la que corresponde al “muchos”) deberá estar sombreada, y si es M:M, todo el rombo estará sombreado.
Diagrama EER de nuestro ejemplo
Vamos a ver cómo quedaría el diagrama Entidad-Relación de nuestro ejemplo:
Así de sencillo: tenemos 3 entidades (profesores, cursos, alumnos) y dos relaciones (impartir, entre profesores y alumnos, 1:M, y asistir, entre alumnos y cursos, M:M).
Realmente, ya a este nivel se suele indicar los “apartados” que hay en cada entidad (lo que serán los “campos” de nuestras tablas). A estos “apartados” les llamaremos “atributos”, y se representan como pequeñas elipses que salen de las entidades. Vamos a pensar primero qué atributos nos podría interesar para nuestras entidades:
Alumnos:
- DNI (Documento Nacional de Identidad)
- Nombre
- Dirección
- Ciudad
- Teléfono
- Fecha de nacimiento
- Fecha de alta en el centro
- Fotografía
Profesores:
- DNI
- Nombre
- Dirección
- Ciudad
- Teléfono
- Conocimientos
- Sueldo
- Cuenta bancaria
Cursos:
- Nombre del curso
- Fecha de comienzo
- Duración (horas)
- Importe (euros)
- Número máximo de alumnos
Es sólo un ejemplo. Insisto en que de momento no estamos pensando en tablas, sino simplemente en qué información queremos almacenar. Según el sistema de bases de datos que empleemos realmente, puede ocurrir que sea incómodo (o incluso imposible) trabajar con algunos de estos datos que hemos previsto (por ejemplo, la “fotografía” del alumno). Pero eso ya nos lo plantearemos después.
Lo que sí vamos a pensar ya es cual de esos datos nos permitirá distinguir una ficha de otra. Esto se hace porque podemos tener dos alumnos con el mismo nombre, pero claramente son personas distintas, y debemos saber qué cursos ha realizado cada uno de ellos sin posibilidad de confusión, para no dar a uno el diploma que corresponda a otro, ni cobrarle un dinero de otro.
En el caso de los alumnos, no son datos únicos los siguientes: el nombre (puede repetirse, incluso con apellidos), la dirección (dos hermanos o dos amigos pueden vivir en la misma casa), el teléfono (ocurre lo mismo), la fecha de nacimiento (también podemos encontrar dos alumnos que hayan nacido el mismo día), etc. Lo que realmente distinguirá a un alumno de otro es su número de DNI (Documento Nacional de Identidad) o pasaporte, que sí es único.
Pues bien, este dato que puede distinguir una persona de otra (o en general una ficha -registro- de otra) es lo que llamaremos la “clave”.
Puede ocurrir que no exista nada que nos sirva claramente como clave, como es el caso de los cursos: no es único el nombre (podemos impartir más de un curso con el mismo contenido), ni la fecha de comienzo (varios cursos pueden comenzar el mismo día), ni la duración, ni el importe, ni el número máximo de alumnos. En estos casos se suele añadir algo arbitrario, un código, que nos permita distinguir un curso de otro (en general una ficha -registro- de otra). En nuestro caso, incluiríamos un nuevo atributo, llamado “Código de curso”.
Un último comentario antes de ver cómo quedaría nuestro diagrama EER con sus atributos. Puede ocurrir que nuestra entidad tenga varios atributos únicos, todos los cuales puedan servir como clave. Entonces escogemos una de ellas como “clave principal”, y el resto serán “claves alternativas”, que no llegaremos a usar como claves. En el diagrama, el atributo que vaya a utilizarse como clave principal aparecerá subrayado.
Ahora ya sí. Nuestro diagrama quedaría así:
