Normalización de bases de datos – Una mirada práctica II
En el anterior artículo sobre Normalización práctica de bases de datos I, nos quedamos sentados delante de nuestra pantalla con un mapa de entidades/atributos y una pequeña descripción de nuestro modelo.
La primera comprobación que tenemos que hacer es que todos los atributos de cada una de las entidades sean atómicos, es decir, que no se puedan dividir en atributos más pequeños. Esto significa eliminar atributos como por ejemplo el atributo Teléfonos de la siguiente tabla:
Atributo multivaluado
Que tendría registros parecidos a esto:
Registro con atributo multivaluado
Cualquiera que tenga nociones de bases de datos se dará cuenta que el campo Teléfonos está mal construido, pero pocas veces nos paramos a pensar el por qué. Por eso cuando un cliente nos pregunta, a veces no sabemos qué responder. Es más, explicar a una persona sin conocimientos de bases de datos por qué está mal el ejemplo anterior, es bastante complicado ya que normalmente los teléfonos no se utilizan para realizar búsquedas, ni para filtrar informes de resultados. Y el cliente nos dirá:
Si quiero encontrar los teléfonos de un empleado, los veo ahí con una simple búsqueda.
Correcto, la información está ahí, pero no debidamente estructurada. Por ello siempre hay que tener preparado un buen ejemplo, en mi caso el ejemplo de los profesores y las asignaturas:
Asignaturas multivaluadas
En esta tabla, si quieres saber las asignaturas que imparte un profesor, lo tienes muy fácil. Pero el tema cambia cuando necesitamos saber todos los profesores que imparten la asignatura de Física, cuántas asignaturas imparte cada profesor, etc.
Para intentar encontrar una solución a este tipo de atributos (volviendo al ejemplo de los Teléfonos) podemos hacer un primer acercamiento separando el atributo multivaluado en múltiples atributos:
Empleados
En principio la solución es correcta (técnicamente se podría decir que está en 1ª FN) y funcionaría perfectamente incluso para el ejemplo de los Profesores. Pero aquí es donde la cosa se empieza a complicar (no mucho) puesto que hay ocasiones que algo que en un principio pensábamos que era un atributo, pasa a ser una entidad.
Como podéis ver, hay 3 atributos (teléfonos) que dependiendo de los requerimientos de nuestro sistema, pueden quedar tal cual (imaginad una empresa en la que todos los empleados tienen 3 teléfonos, uno personal, un móvil de empresa y el fijo de empresa) o convertirse en otra entidad (empresas en las que hay empleados que tienen solo 1 teléfono y empleados que tienen 4).
Vamos a poner otro ejemplo en el que veremos más clara la necesidad de modificar nuestro diseño inicial. En este caso tenemos nuestra entidad EMPLEADO de la siguiente manera:
Entidad empleado mal diseñada.
En este caso, si dejamos así la entidad, tendríamos muchos problemas:
–Valores nulos: Tendríamos muchos empleados con solo una titulación por lo que llenaríamos nuestra tabla con valores nulos. Además, en el caso de que uno de nuestros empleados tuviera 8 títulos (nada extraño si metemos cursos por ejemplo), tendríamos que cambiar el diseño de la tabla, añadiendo valores nulos a ésta.
–Dificultades a la hora de actualizar/ eliminar atributos de titulaciones: Imaginad que queremos que cada titulación tenga varios atributos, Tipo, Centro, Año de titulación… tendríamos que modificar los atributos para cada empleado, con el riesgo que esto supone para la integridad de los datos. O también podemos imaginar que la dirección decide suprimir un curso de las titulaciones que tiene cada empleado (por ejemplo se dan cuenta de que no es valorable debido a su escasa dificultad). Tendríamos que eliminar el curso de cada empleado que lo tiene.
La solución, crear otra entidad (de momento nos quedamos aquí, en crear la entidad):
Titulaciones
Así que hasta el momento hemos podido ver que en el diseño inicial de una base de datos tenemos que tomar decisiones que solo podremos tomar conociendo bien nuestro universo. Es mejor «perder» más tiempo del debido en esta fase, que después tener que modificar el diseño cuando el sistema lleva varios meses funcionando (a todos nos ha tocado alguna vez y sabemos la dificultad que tiene, a veces incluso es mejor seguir con la base de datos mal diseñada que parar a los usuarios y hacer el volcado de la información).
Una vez que tenemos bien identificadas nuestras entidades con sus atributos, nos falta el paso principal para la normalización, la elección de claves y las relaciones. Miremos a ver que nos dice la Wikipedia:
En el diseño de bases de datos relacionales, se llama clave primaria a un campo o a una combinación de campos que identifica de forma única a cada fila de una tabla. Una clave primaria comprende de esta manera una columna o conjunto de columnas. No puede haber dos filas en una tabla que tengan la misma clave primaria.
Relación: Describe cierta dependencia entre entidades o permite la asociación de las mismas. Una relación tiene sentido al expresar las entidades que relaciona. En el ejemplo anterior, podemos decir que un huésped (entidad), se aloja (relación) en una habitación (entidad).
Volviendo al ejemplo anterior, parece que vemos claro que nuestra tabla EMPLEADO podría tener como clave primaria el DNI, no vamos a tener nunca 2 empleados con el mismo DNI. La segunda tabla en cambio nos genera algo más de dudas, ¿ponemos como clave primaria el campo Titulación? ¿No hay 2 empleados con la misma titulación? ¿Tiramos una relación de una a otra y Access hace magia?:
Relacionar tablas incorrectamente.
Me temo que no va a ser tan sencillo, para relacionar tablas tendremos que tener en cuenta algunos factores más, los tipos de relaciones, propagaciones de clave, creación de nuevas entidades, etc.
Hasta aquí este segundo artículo sobre los aspectos prácticos de la normalización de bases de datos. En el siguiente desarrollaremos el concepto de relaciones en una base de datos y empezaremos con la normalización.
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 III
- Normalización de bases de datos – Una mirada práctica IV
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