Normalización de bases de datos – Una mirada práctica IV
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
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:
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
Y hacemos la siguiente selección:
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
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
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
- Normalización de bases de datos – Una mirada práctica I
- Normalización de bases de datos – Una mirada práctica II
- Normalización de bases de datos – Una mirada práctica III
Arkaitz Arteaga
Latest posts by Arkaitz Arteaga (see all)
- Access: Encriptar contraseñas con SHA-256 utilizando biblioteca de clases .NET con C# - 4 mayo, 2014
- Rendimiento de Access contra backend Access en servidor de archivos remoto. Cuarta parte. - 27 abril, 2014
- Rendimiento de Access contra backend Access en servidor de archivos remoto. Aclaración. - 21 abril, 2014
- Utilizar biblioteca de clases .NET en Access. Tercera aproximación a la Interoperabilidad COM - 14 abril, 2014
- Vincular tablas en Access con Visual Basic - 11 abril, 2014