AnteriorPosterior

3 - Contacto con los diagramas Entidad-Relación

Por: Nacho Cabanes
Actualizado: 17-04-2019 10:49
Tiempo de lectura estimado: 13 min.

 

SQL y MySQL

3.1. ¿Qué es modelo entidad-relación?

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.

3.2. Representación de entidades y atributos

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.

3.3. Relaciones

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.

3.4. Pero hay más...

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.

3.5. Conversión a tablas

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):

  • Por lo general, una entidad se convertirá en una tabla.
  • Una relación 1:M (uno a muchos) se reflejará añadiendo el código de la tabla del "lado del 1" en la tabla del "lado del M". Por ejemplo, en el caso de las personas y ciudades, en las que cada ciudad tiene muchas personas y cada persona vive en una ciudad, se añadirá para cada persona el código de la ciudad.
  • Una relación M:M (muchos a muchos) se convertirá en una nueva tabla que contendrá ambas claves primarias (y su clave primaria estará formada por ambas claves a la vez). Por ejemplo, si nos interesa reflejar en nuestro sistema de información que cada persona puede haber vivido en varias ciudades, la relación pasaría a ser M:M, y entonces aparecería una nueva tabla "vivir", cuyos registros contendrían la clave de la ciudad y la clave de la persona (dato que actualmente no aparece en nuestra base de datos).

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:

  • País: código, nombre
  • Equipos: código, nombre, códigoDePaís
  • Jugadores: código, nombre, códigoDePaís
  • JugarEn: códigoJugador, códigoEquipo, fechaDesde, fechaHasta

3.6. Ejercicios propuestos

  • 3.1. Deseamos informatizar una lista de empleados técnicos de nuestra empresa, que sean capaces de resolver problemas de nuestros clientes. Por eso, para cada empleado nos interesará guardar información sobre todas sus habilidades técnicas (por ejemplo, "bases de datos" o "programación") así como los idiomas que maneja con soltura (por ejemplo, "inglés" o "alemán"). Como puede haber varias personas que tengan una cierta habilidad técnica o que hablen un cierto idioma, usaremos tablas para esos datos y relaciones "muchos a muchos". Además, querremos valorar de 1 a 5 el nivel que cada empleado tiene con una habilidad técnica o con un idioma (distinguiendo en este caso entre nivel hablado y nivel escrito). Crea un diagrama Entidad-Relación que muestre cómo automatizar este sistema de información. (Pista: las preguntas 3.3 a 3.7 te ayudarán a plantear qué estructura da respuesta a todo lo que se puede necesitar, así como a saber qué tipo de datos puedes emplear)
  • 3.2. Convierte a tablas el sistema Entidad-Relación, dentro de una nueva base de datos llamada "ejercicio3".
  • 3.3. Añade a los usuarios (y habilidades e idiomas) los siguientes datos:

  • Aurora, con nivel de 5 estrellas en PHP, 4 estrellas en Javascript, 5 estrellas en diseño gráfico y 3 estrellas en idioma inglés.
  • Adrián, con nivel de 4 estrellas en PHP, 4 estrellas en Javascript, 5 estrellas en montaje de equipos y 2 estrellas en idioma inglés.
  • Enrique, con 5 estrellas en electrónica y 2 estrellas en idioma inglés.
  • Gala, con 5 estrellas en inglés, 5 estrellas en francés y 5 estrellas en atención al cliente.

  • 3.4. Muestra el nombre de todas las personas que hablen francés.
  • 3.5. Muestra los nombres de los empleados con conocimientos de diseño gráfico, ordenados del más experto (5 estrellas) al menos experto (1 estrella).
  • 3.6. Muestra las habilidades de Adrián, ordenadas de aquella en la que es más experto a aquella en la que menos. Si dos habilidades coinciden, deberás ordenarlas alfabéticamente.
  • 3.7. Nos llama un cliente que sólo habla inglés y que quiere hacer una consulta técnica . Por eso, deberás obtener los nombres de los empleados con conocimientos de PHP y de inglés, ordenados de mayor a menor nivel de inglés, y, en caso de coincidir, de mayor a menor nivel de PHP.

323 visitas desde el 17-04-2019

AnteriorPosterior