En el pasado post, recreamos con IA una entrevista de trabajo para DBA SQL Server. Una de las preguntas de esta entrevista era sobre la normalización de bases de datos y os comenté que esto era muy importante. Es teoría básica de base de datos, pero tan básica que son las normas sobre las que se construyen las bases de datos. Como aún no hemos hablado de ello y todo el que trabaje con base de datos (DBA o usuario) debe conocerlo vamos a dedicarle el artículo de hoy.
Desde ya os aviso que es un tema puramente teórico, voy a intentar poner ejemplos prácticos para que sea lo más claro posible pero puede que se nos haga a todos un poco de bola. Es normal. Que esto no os pare, como decimos es la base de todo buen profesional de las bases de datos relacionales y debemos conocerlo al detalle, como los mandamientos de la biblia.
¿Qué es la normalización y por qué es tan importante?
La normalización es el proceso de organizar los datos en una base de datos de forma que se eviten las redundancias, las inconsistencias y las anomalías. Se basa en aplicar una serie de reglas, llamadas formas normales, que definen cómo deben estructurarse las tablas y las relaciones entre ellas.
La normalización tiene muchos beneficios, como mejorar el rendimiento, facilitar el mantenimiento, garantizar la integridad y optimizar el espacio de almacenamiento.
¿Cómo se aplica la normalización?
Como hemos comentado existen varias formas normales, desde la primera forma normal (1FN) hasta la sexta forma normal (6FN). Cada una de ellas con sus propios requisitos y objetivos. Sin embargo, no siempre vamos a necesitar aplicar todas las formas normales, depende del tipo de datos y del diseño de la base de datos.
A continuación vamos a explicar brevemente cada forma normal con algunos ejemplos.Para el ejemplo vamos a partir de este conjunto de datos que tenemos y vamos a tratar de normalizarlo:
Primera forma normal (1FN)
Esta primera forma normal trata de eliminar registros duplicados y que cada campo de la tabla contenga un único tipo de información Así cada campo de una tabla debe contener un valor único y atómico, es decir, que no se pueda descomponer en partes más pequeñas. Además, cada tabla debe tener una clave primaria que identifique de forma única a cada registro.
En nuestro ejemplo no teníamos filas duplicadas, pero sí que debemos descomponer la dirección en varios campos atómicos y unificar el tipo de datos de la columna precio. Quedaría de la siguiente manera:
Segunda forma normal (2FN)
Para poder considerar una tabla en 2FN tiene que cumplir con todos los requisitos de la 1FN y, además, que todos los campos que no formen parte de la clave primaria dependan completamente de la clave primaria. Esto significa que si la clave primaria está compuesta por más de un campo, cada campo no clave debe depender de todos los campos clave y no solo de algunos. Deberemos separar nuestra tabla en varias de manera que todos los campos cumplan con este requisito. ¿Os ha explotado la cabeza ahora mismo? No os preocupéis que con el ejemplo lo vamos a ver más claro.
Como hemos dicho el primer requisito es estar en 1FN así que vamos a empezar a trabajar sobre esa tabla ya en 1FN. Tendremos que saber cuál es su clave primaria, podría ser Num Factura + Cliente + Linea Factura. Sin embargo no es un buen candidato a clave primaria porque no con menos campos también logramos identificar inequívocamente todos los registros. La clave será Num Factura + Linea factura. Con esta nueva clave, tanto la fecha como los datos del cliente dependen del número de factura pero no de la línea de la factura así que vamos a hacer 2 tablas separadas.
Tercera forma normal (3FN)
Para cumplir esta 3FN, además de tener que cumplir con la 2FN, cada campo de una tabla debe depender funcionalmente solo de la clave primaria sin que haya dependencias transitivas. Esto significa que si un campo no clave depende de otro campo no clave, debemos eliminar esa dependencia y crear una tabla separada.
Parecido a la 2FN pero un poco más restrictiva, en este caso tenemos que ver las dependencias de los campos con la clave y ver si puede crearse la relación con una clave intermedia. En nuestro caso separaremos los clientes de las facturas y los datos del artículo de las líneas de facturas.
Otras Formas Normales, para un extra de normalización
Lo más normal es normalizar las bases de datos hasta la tercera forma normal, a partir de aquí, aunque sigue siendo recomendable, no siempre se cumple con todo y va a depender más de casos concretos. Vamos a conocerlo aunque ya sin nuestra tabla de ejemplo, pues lo que resta no aplica en nuestro caso.
Cuarta forma normal (4FN)
Esta 4FN dicta que las tablas no deben contener columnas multivalores, es decir, que no haya campos que contengan más de un valor para un mismo registro. Esto significa que si un campo puede tener varios valores posibles para un mismo registro, debemos crear una tabla aparte para almacenar esos valores y relacionarla con la tabla original mediante una clave foránea.
Por ejemplo, si tenemos una tabla de cursos con los campos código de curso, nombre y requisitos previos, debemos eliminar el campo requisitos previos, ya que puede contener más de un valor para un mismo curso. Este campo debe ir en una tabla aparte de requisitos previos y relacionarse con la tabla de cursos mediante una clave foránea.
Quinta forma normal (5FN)
Esta forma normal establece que cada tabla debe estar libre de anomalías de unión o inserción, es decir, que no haya redundancias o inconsistencias al combinar o insertar datos en varias tablas. Esto significa que si tenemos varias tablas relacionadas entre sí mediante claves foráneas compuestas, debemos asegurarnos de que esas relaciones sean necesarias y suficientes para representar los datos correctamente.
Por ejemplo, si tenemos tres tablas: profesores, asignaturas y horarios, que se relacionan entre sí mediante las claves foráneas código de profesor, código de asignatura y día de la semana, debemos verificar que no haya combinaciones de valores que no tengan sentido o que falten datos. Si un profesor imparte una asignatura en varios días de la semana, debemos tener un registro por cada día en la tabla de horarios. Igualmente, si una asignatura se imparte por varios profesores en diferentes días, debemos tener un registro por cada profesor y día en la tabla de horarios. Si un profesor no imparte ninguna asignatura o una asignatura no se imparte por ningún profesor, debemos tener registros vacíos en la tabla de horarios.
Sexta forma normal (6FN)
Esta forma normal es la más nueva de todas y en algunos sitios no encontraréis referencias a ella justo por esto. Mientras que el resto de FN datan de los años 70, esta última no se dictó hasta los 90.
Establece que cada tabla debe contener sólo un hecho atómico, es decir, que no haya campos derivados o calculados a partir de otros campos. Esto significa que si tenemos una tabla que contiene información que se puede obtener mediante una operación matemática o lógica sobre otros campos, debemos eliminar esa información y crear una tabla aparte para almacenarla.
Por ejemplo, si tenemos una tabla de facturas con los campos número de factura, fecha, código de cliente, subtotal, impuesto y total, debemos eliminar los campos impuesto y total, ya que se pueden calcular a partir del subtotal y del porcentaje de impuesto aplicable. Estos campos deben ir en una tabla aparte de impuestos y totales y relacionarse con la tabla de facturas mediante una clave foránea.
Conclusión
Enhorabuena si habéis llegado hasta aquí, os adelantaba que iba a ser un artículo denso de teoría pero a medida que lo escribía hasta a mi se me ha hecho cuesta arriba. Es lo que hay, en todos los campos hay que tratar estos artículos teóricos para tener una buena base. En este caso, la normalización es un proceso fundamental para diseñar bases de datos eficientes, consistentes y fáciles de manejar. Espero que este esfuerzo os haya servido para entender mejor la normalización de bases de datos. Practicad con vuestros propios ejemplos y, si os surgen dudas, podéis dejarlo en los comentarios, Twitter o mail y trataré de ayudaros lo mejor que sepa.
