Es una notación alternativa, gráfica, que se suele usar como paso inicial en la planificación de una base de datos. Permite pasar de una descripción textual de un sistema de información a una representación visual, que resulta más fácil de comprobar y de refinar.
No profundizaremos mucho, pero veremos varios ejemplos de complejidad creciente, así como la manera de obtener un esquema de base de datos a partir de un diagrama Entidad-Relación.
Una entidad representa un bloque de información. En general, como primera aproximación, se corresponderá con una tabla de la base de datos. Las entidades se representan dentro de rectángulos. Por ejemplo una primera aproximación a una entidad "Ciudad", que representara a cada ciudad de la que vamos a guardar información, podría ser:
La forma más habitual de representar los atributos (las propiedades que cada entidad, que equivalen a los "campos" de la tabla) es dentro de elipses que estarán unidas a la entidad a la que pertenecen:
Si una entidad tiene clave primaria, se indica subrayando su nombre:
Y la entidad "persona" será similar, con todos sus atributos en elipses (y ninguno estará subrayado, al no tener clave primaria):
Existe una notación alternativa, más compacta, que no sigue el estándar entidad-relación, pero que puede llegar a resultar útil en caso de sistemas de información muy grandes. Consiste en incluir en un mismo rectángulo el nombre de la tabla y la lista de sus atributos (y opcionalmente incluso sus tipos de datos):
Nosotros no usaremos esa notación, porque está más relacionada con la implementación de la base de datos que con su diseño.
El nombre del modelo entidad-relación se debe a que son tan importantes las entidades individuales como las relaciones que existen entre ellas. Las relaciones normalmente se indican dentro de rombos, y tendrán un nombre que será un verbo. Por ejemplo, una persona puede "vivir en" una cierta ciudad, lo que se reflejaría en algo como:
Un segundo detalle importante en las relaciones es la "cardinalidad": cuántas "ocurrencias" de la tabla A se relacionan con cuántas de la tabla B. Por ejemplo, si hablamos de personas que viven actualmente en ciudades, podríamos suponer que la relación es "de muchos a uno" (M:1), porque muchas personas viven en cada ciudad, mientras que cada persona sólo vive (en un momento dado, siendo optimistas) en una única ciudad.
Existen varias formas de reflejar esa cardinalidad. Una de las más sencillas es usar un "1" o una "M" en los correspondientes lados de la relación:
Otra es emplear "palitos": un palo perpendicular a la línea en la entidad que sólo aparece una vez, y tres palos (típicamente en forma de "tenedor", aunque hay quien los dibuja todos ellos perpendiculares) en el lado del "muchos", así:
Y otra es sombrear el lado del "muchos":
Personalmente, esta última notación es la que me parece más legible, porque permite saber de un vistazo rápido la cardinalidad, especialmente en los casos de relaciones más complejas, como las "ternarias", en las que intervienen tres entidades, y que veremos más adelante.
Hay muchos más detalles que se pueden representar en el modelo Entidad-Relación, como por ejemplo la "cardinalidad mínima" de una relación, es decir, el hecho de que un cierto dato debe existir siempre en una relación. Pero por ahora no vamos a afinar más.
Una de las ventajas del modelo Entidad-Relación es que la conversión de un diagrama a la correspondiente base de datos (usando el "modelo relacional", que es el más extendido y el que estamos empleando nosotros), es casi inmediata.
Igual que no vamos a ver todas las posibilidades del Entidad-Relación, tampoco vamos a ver todas las pautas de conversión, pero sí las más sencillas (que además son las más habituales):
Vamos a ver un ejemplo un poco más completo antes de pasar a la tanda de ejercicios:
Queremos informatizar un primer bloque de información de sobre equipos deportivos. Para cada equipo nos interesará saber su nombre, su país y la lista de sus jugadores. De cada jugador también querremos saber por ahora sólo el nombre y su país de nacimiento. Además, para que no sea tan trivial, querremos contemplar la posibilidad de que un jugador pueda haber formado parte de distintos equipos, en cada uno de ellos entre ciertas fechas.
De lo anterior se puede extraer que habrá dos entidades ("equipo" y "jugador"), que estarán relacionados por "jugar en" (M:M). Además, el dato del país, que sería repetitivo, debería sacarse a una nueva tabla, que estará relacionada 1:M con ambas tablas (cada jugador habrá nacido en un país, cada equipo pertenecerá a un país).
El diagrama sería así:
Y su conversión a tablas sería: