Normalización de bases de datos – Una mirada práctica III

Formas Normales

En los anteriores artículos sobre normalización de bases de datos (Normalización práctica de bases de datos I y Normalización práctica de bases de datos II), nos quedamos con nuestras dos tablas EMPLEADO y TITULACIÓN relacionadas directamente esperando que Access hiciera magia.

Relacionar tablas incorrectamente.

Relacionar tablas incorrectamente.

Después de esperar varios minutos (a veces incluso antes) nos daremos cuenta de que la magia no existe (por lo menos en este caso) y que tenemos que depurar nuestras relaciones entre tablas. Para ello necesitamos explicar antes los tipos de relaciones que existen en una base de datos relacional.

Relaciones varios a varios (N:M)

Empiezo por este tipo de relación por varios motivos. Para mí, es la más sencilla de entender, la más sencilla para transformar en tablas normalizadas y además la utilizaremos en el resto de relaciones. Por otro lado, es muy interesante comprender que podremos separar los atributos de las entidades de los atributos de la propia relación. Y por último, pero no menos importante, nos sirve para solucionar el ejemplo anterior

En las relaciones N:M una entidad se puede relacionar con varias ocurrencias de otra entidad y viceversa. En nuestro caso, un EMPLEADO puede tener varias TITULACIONES y una TITULACIÓN la pueden tener varios empleados.

En este tipo de relaciones, la transformación siempre se hace de la misma manera, se mantienen las 2 tablas iniciales con sus atributos y se añade una nueva que tendrá como clave principal las claves principales de las 2 anteriores pudiendo añadir atributos en la propia relación. Vamos con nuestro ejemplo:

Relacion N:M

Relación N:M

Como vemos, en nuestro caso nos quedarían 3 tablas:

  • EMPLEADO: (DNI, NOMBRE, APELLIDOS, DEPARTAMENTO, JEFE)
  • TITULACIÓN: (COD_TITULACIÓN, TITULACIÓN, TIPO, VALORACIÓN, PUESTOS)
  • EMPLEADO_TITULACIÓN: (DNI, COD_TITULACIÓN, AÑO, CENTRO)

Con esto solucionamos todos los problemas que teníamos anteriormente:

-Valores nulos: Aunque tengamos empleados sin titulación, nuestra solución hace que desaparezcan los valores nulos. Pueden existir perfectamente empleados con 50 títulos y empleados sin ninguno.

Dificultades a la hora de actualizar/eliminar atributos de titulaciones: Una vez realizada la transformación, podríamos actualizar una titulación directamente en la tabla TITULACIÓN y quedaría modificada para todos nuestros empleados. Si la dirección decidiera eliminar cualquier titulación, se eliminaría en cascada de todos los empleados (generalmente en este tipo de relaciones se utiliza el borrado en cascada, aunque podríamos quitarlo si nos interesa por ejemplo guardar las titulaciones que alguna vez han tenido nuestros empleados aunque hayamos decidido eliminarlas de sus expedientes).

Por otro lado introducimos atributos en la propia relación, que nos servirán en nuestro caso para las particularidades de cada relación. Por ejemplo varios empleados pueden tener la titulación de Ingeniero Informático, quedando la entrada de la tabla TITULACIÓN de la siguiente manera:

Entrada en la tabla TITULACIÓN

Entrada en la tabla TITULACIÓN.

Pero después cada empleado o grupo de empleados habrá realizado su carrera en varias Universidades, con sus correspondientes atributos:

Titulaciones en distintos centros.

Titulaciones en distintos centros

Incluso podríamos haber añadido particularidades de cada titulación en cada centro como número de créditos, número de horas, etc. Eso si, es importante asegurarnos de que los atributos de la relación, hagan referencia (dependan funcionalmente) de la propia relación y no de una de las 2 entidades iniciales (2ª FN). Pongo un ejemplo:

Relación mal diseñada

Relación mal diseñada

Los atributos EMPLEADO y TIPO no dependen de la relación, dependen las entidades iniciales (EMPLEADO depende de la entidad EMPLEADO y TIPO depende de la entidad TITULACIÓN)  por lo que tendremos que eliminarlos de la relación y crearlos (si no existían antes) en las tablas de partida. En cambio el AÑO y el CENTRO si que dependen de la relación, es decir, un empleado y una titulación se relacionan mediante un centro en el que se saca la titulación y el año en el que la sacó.

Como veis, normalizar no solo nos facilita la actualización y eliminación de datos, nos da la opción de añadir nuevas funcionalidades a la base de datos (atributos de relación), nos da opciones para la integridad de la base de datos (actualización y modificación en cascada o no), nos ayuda a que los datos siempre mantengan esa integridad (si intentáis crear un registro en la tabla EMPLEADO_TITULACIÓN y no existe o el empleado o la titulación, la base de datos no lo permitirá) y sobre todo y más importante, nos obliga a crear un sistema de base de datos que cumpla con la teoría de sistemas.

Esto puede parecer que tiene poco que ver con el diseño de bases de datos (una teoría de 1950, cuando no existían ni los PCs), pero si lleváis años diseñando aplicaciones y/o bases de datos, sabréis que si un cliente te pide algo que no puedes representar con un sistema (y en consecuencia no lo puedes pasar al diseño relacional), hay 2 posibilidades:

  • No eres tan buen diseñador como creías.
  • Algo falla en ese cliente.

La segunda es la opción más común y también la más difícil (tienes que convencerle de que no está haciendo las cosas bien…). Pero es mejor que se dé cuenta antes de empezar con la base de datos a luego escuchar las típicas frases:

-Es que esto no suele ser así, pero esta vez se ha juntado que la luna está en cuarto menguante y que Saturno se ve desde Sopuerta.

Y creo que con esto tenemos suficiente por hoy. En el siguiente artículo empezaremos con el resto de tipos de relaciones (uno a varios y uno a uno).

Serie de artículos

The following two tabs change content below.
Arkaitz Arteaga
Llevo más de 10 años programando, sobre todo en Visual Basic y con bases de datos Access. Para mí, VBA y Access siguen siendo herramientas muy potentes. He desarrollado varios proyectos con PHP y MySql. Si sumo las webs que he tenido, probablemente pasaría de 100. Ahora prefiero dedicar todo mi esfuerzo a este blog (aunque sigo manteniendo unas cuantas...). Trabajo en la administración pública (si, soy funcionario), pero he trabajado en pequeñas empresas e incluso en una "grande" de las telecomunicaciones. Ultimamente estoy bastante metido en abrirme nuevos horizontes con C# y .NET. Renovarse o morir!

Deja un comentario