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

Formas Normales

En anteriores artículos sobre normalización de bases de datos (Normalización práctica de bases de datos I, Normalización práctica de bases de datos II y Normalización práctica de bases de datos III), explicaba la importancia de normalizar nuestra base de datos y hacíamos un repaso a las dificultades de bases de datos sin normalizar. Pues bien, nos quedan 2 tipos de relaciones por ver, las relaciones uno a varios (1:N) y las relaciones uno a uno (1:1).

Relaciones uno a varios (1:N)

Para explicar este tipo de relaciones, vamos a crear una nueva entidad DEPARTAMENTO con la siguiente estructura:

DEPARTAMENTO: (COD_DEPARTAMENTO, DEPARTAMENTO)

Departamento

Departamento

En las relaciones 1:N una entidad (por ejemplo nuestra entidad EMPLEADO) se relaciona con cero o varias ocurrencias de otra entidad (por ejemplo nuestra entidad DEPARTAMENTO) pero esa segunda entidad (DEPARTAMENTO) solo se relaciona con una ocurrencia de la primera entidad (EMPLEADO).

En este caso tenemos 2 posibles soluciones, un nuevo concepto que utilizaremos bastante, la propagación de clave y la creación de una nueva entidad:

Propagación de clave

Para llevar a cabo una propagación de clave, tenemos que propagar la clave principal de la entidad del lado N (en nuestro caso DEPARTAMENTO) hacia la entidad del lado 1, es decir, crear una clave externa en nuestra tabla EMPLEADO creando un campo DEPARTAMENTO en nuestra tabla EMPLEADO:

Clave Externa

Propagación de clave. Clave Externa

Con esto mantendríamos la integridad referencial de nuestra base de datos, tendríamos opción de actualizar y eliminar en cascada, y todas las ventajas de las bases de datos normalizadas.

El problema viene cuando la relación no es obligatoria por el lado de las N, en nuestro caso cuando puede haber empleados sin departamento. Se podría solucionar dejando que nuestra clave externa (Departamento en nuestra tabla EMPLEADOS) pueda ser NULA, pero si se dan muchos casos, tendríamos muchos valores nulos, que aunque puede no tener mayor importancia, depende de cada diseñador el dejarlo así o crear otra entidad.

Creación de una entidad nueva

La decisión de crear una nueva entidad depende del universo en el que estemos y sobre todo del diseñador. Como hemos visto en el apartado anterior, en el caso de la no obligatoriedad en la parte  de N en la relación, podría ser una buena solución. Además, nos deja abierto en un futuro la posibilidad de que se convierta en una relación N:M (nada extraño en nuestro caso, un empleado puede pertenecer a varios departamentos) ya que se transformaría como si fuese una relación N:M (ver Normalización práctica de bases de datos III).

Relaciones uno a uno (1:1)

Aunque pueda parecer que este tipo de relaciones son las más fáciles de explicar, yo creo que si las entiendes, no tendrás problemas para entender el resto. Esto es debido a que su transformación puede ser tan sencilla como añadir atributos a una entidad, o se puede transformar propagando clave o incluso creando una entidad nueva.

En las relaciones 1:1 una entidad (por ejemplo nuestra entidad EMPLEADO) se relaciona únicamente con una o ninguna ocurrencias de otra entidad y esa segunda entidad se relaciona también con una o ninguna ocurrencia de nuestra entidad.

Añadir atributos

Volvamos a nuestro segundo artículo Normalización práctica de bases de datos II y al ejemplo de los teléfonos de nuestros empleados. Ese puede ser un ejemplo válido para convertir 2 entidades (EMPLEADO y TELEFONOS) en una sola. En ese segundo artículo realizábamos la transformación contraria, pero también pudimos llegar  a la conclusión de que solo nos interesa guardar el teléfono de trabajo del empleado, lo que resultaría en una relación 1:1, que se podría resolver añadiendo el atributo «Teléfono» a la entidad EMPLEADO.

La solución anterior podría no resultarnos óptima debido a 2 motivos principales, la pérdida semántica (al eliminar la entidad, se pierde visión de nuestro sistema además de impedirnos que la entidad que desaparece tenga demasiados atributos) y en el caso de no obligatoriedad, aparecen de nuevo los valores nulos.

Propagación de clave

Para solucionar el primero de los problemas, se suele utilizar la propagación de clave en el caso de que la relación sea obligatoria. Para explicar este tipo de relaciones voy a poner un ejemplo un poco extraño, sobre todo porque la manera de implementarlo en Access.

Vamos a crear una relación 1:1 pero dentro de la misma tabla, la relación CASADO. Vamos a imaginar que tenemos una base de datos sobre personas casadas, con una entidad llamada PERSONA que tendrá un atributo CASADO. Como todas nuestras «personas» van a estar casadas por el universo en el que nos encontramos y solo van a poder tener un marido/mujer, podemos utilizar el atributo CASADA como clave externa que apunta a la clave principal de nuestra entidad PERSONAS.

Para crear este tipo de relación en Access, tenemos que pinchar sobre la tabla en «Relaciones» y cuando se nos abra el menú «Modificar relaciones» pulsar el botón «Crear Nueva»:

Crear relación a la misma tabla.

Crear relación a la misma tabla

Y hacemos la siguiente selección:

Relación 1:1 misma tabla

Relación 1:1 misma tabla

Con esto se nos creará una relación 1:1 con obligatoriedad por ambas partes, sobre la misma tabla.

Relación 1:1 misma tabla Access

Relación 1:1 misma tabla Access

Que curiosamente Access convierte en esto cuando después de guardar las relaciones volvemos a abrirlas en otro momento:

Relación 1:1 misma tabla Access modificada

Relación 1:1 misma tabla Access modificada

No os preocupéis si queda un poco raro ya que lo reconoce como una relación 1:N y encima al revés. Al final funciona correctamente a la hora de hacer las consultas.

 Creación de otra entidad

Vamos a seguir con el mismo ejemplo de una relación CASADO pero en este caso en nuestra base de datos de empleados. Imaginad que queremos saber los empleados que están casados entre ellos. Podríamos utilizar la misma solución que en el apartado anterior (propagación de clave en la misma tabla) pero nos quedarían muchos registros con el campo CASADO con el valor nulo (suponiendo que nuestros empleados no tengan la costumbre de casarse siempre entre ellos…).

Para este tipo de relaciones 1:1 sin obligatoriedad (en uno o en ambos lados la cardinalidad es 0), crearíamos otra entidad y actuaríamos como si se tratara de relaciones N:M.

Y con esto terminamos esta serie de artículos sobre Normalización de bases de datos que aunque pretendía ser breve, al final se ha convertido en 4 artículos bastante extensos pero espero que interesantes y prácticos. Si los habéis seguido desde el principio, vuestro modelo inicial transformado en tablas relacionadas normalizadas.

Como habréis observado, no he mencionado la 3ª FN en ningún momento, pero muy pocas veces después de seguir los pasos que he comentado os encontraréis con tablas que no estén en esa forma normal.

Serie de artículos

The following two tabs change content below.
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 una respuesta