En este articulo vamos a ver qué es la normalización en bases de datos, cuál es su objetivo y las diferentes formas normales que existen.

¿Qué es la normalización?

La normalización, es un proceso que forma parte del diseño de bases de datos relaciones y cuyo objetivo o fin es organizar los datos de manera eficiente, minimizando la redundancia y mejorando la integridad de los datos. Todo esto se consigue aplicando una serie de reglas llamadas formas normales, que definen como deben estructurarse las tablas para garantizar un buen diseño y una estructura óptima. Todo esto no viene de ahora, no es nada nuevo, ya que el origen de todo este proceso y normas fue creado en 1970 por Edgar F. Codd.

¿Cómo funciona?

Todo esto se logra dividiendo la información en múltiples tablas relacionadas mediante claves primarias y foráneas.

A continuación, exploraremos las principales formas normales, desde la Primera Forma Normal (1FN) hasta la Tercera Forma Normal (3FN), con ejemplos prácticos para cada una.

Hay que tener en cuenta que estas formas normales se aplican de manera progresiva y son aplicadas a las tablas de una base de datos. Cada forma normal parte de la anterior, añadiendo condiciones cada vez más estrictas y así sucesivamente.

Empecemos…

Primera Forma Normal (1FN)

Decimos que una tabla está en primera forma si cumple lo siguiente:

• Cada columna debe contener valores atómicos, es decir, no divisibles.
• Cada fila debe ser única.
• No deben existir grupos repetitivos o listas en una celda. Pues cada columna debe tener un único tipo de dato.
• No debe existir variación en el número de columnas, es decir, todas las filas deben tener exactamente las mismas columnas. No se pueden agregar o quitar columnas dependiendo del registro.
• Debe existir una dependencia funcional, es decir, cada columna que no forma parte de la clave primaria debe depender completamente de esa clave y no de otro campo.
• Debe existir independencia del orden, o, en otras palabras, el orden de las filas o de las columnas no debe afectar al significado de los datos, pues cambiar el orden no debe cambiar la información.

Ahora veamos algunos ejemplos incorrectos y correctos.

Ejemplo incorrecto, es decir, no se aplica 1FN:

ID	Cliente	Teléfonos
1	Ana	111-222, 333-444

Es incorrecto porque hay una lista de teléfonos en un campo.

La forma correcta sería:

ID	Cliente	Teléfono
1	Ana	111-222
1	Ana	333-444

Y ahora seguro que estás diciendo ¡pero la ID se repite! Tranquil@, te explico.

La clave real de esa tabla no es solo ID, sino la combinación de ID + Teléfono.

Es decir:

• ID identifica a la persona (Ana).
• Teléfono identifica el número específico.
• Juntos (ID, Teléfono) forman una clave primaria compuesta que sí es única.

Así que, aunque a primera vista el ejemplo correcto pudiera parecer incorrecto, no lo es, ya que la tabla cumple la 1FN, porque cada campo es atómico (no hay listas de teléfonos en una celda) y el hecho de que ID se repita indica que hay múltiples registros para la misma persona, pero con diferentes teléfonos.

Eso sí, el ejemplo siempre será correcto mientras la clave compuesta sea única.

Por otro lado, si necesitáramos que ID fuera único y que cada cliente tuviera un solo teléfono, entonces habría que crear otra tabla para teléfonos, con relación 1 a N (un cliente tiene varios teléfonos).

Ejemplo:

Tabla Clientes:

ID	Cliente
1	Ana
2	Pedro

Tabla Teléfonos:

ID_Cliente	Teléfono
1	111-222
1	333-444
2	555-666

De esta manera, evitamos duplicar datos del cliente y mantenemos el modelo más limpio.

Por cierto, me acabo de dar cuenta que sin quererlo (🤭) acabamos de entrar/ver la segunda forma. Mas adelante ya lo entenderás.

Segunda Forma Normal (2FN)

Para que una tabla este en 2FN debe:

• Cumplir con la 1FN.
• Todos los atributos no clave deben depender completamente de la clave primaria y no solo de una parte. Es decir, se deben evitar las dependencias parciales. Esto se aplica cuando la clave primaria está compuesta por varias columnas.

Para entenderlo mejor, veamos el siguiente ejemplo.

id_pedido	id_producto	nombre_producto	precio_producto	cantidad
1	A1	Ratón	15	2
1	B2	Teclado	25	1
2	A1	Ratón	15	3

Si nos fijamos tenemos una calve primaria que es compuesta, ya que está formada por id_pedido + id_producto.

Ahora bien, el campo cantidad, depende de toda la clave compuesta, porque depende tanto del pedido como del producto.

Peeeeeeeero nombre_producto y precio_producto dependen solo de id_producto, no de toda la clave. Entonces, ahí, ya estamos teniendo una dependencia parcial y rompiendo la 2FN.

No sé si me he explicado bien 🤔

En otras palabras, o más fácil, la 2FN nos dice que, para aplicarla correctamente, si la clave es compuesta, los campos no clave deben depender de toda la clave, no solo de una parte.

En el ejemplo anterior hemos visto que esto no era así, ya que como vimos, los campos nombre_producto y precio_producto dependía de una parte de la clave que era solo id_producto. Lo que se llama dependencia parcial.

Entonces, siguiendo con el ejemplo, pero haciéndolo bien, deberíamos de:

Primero separar las tablas: por un lado, crear una tabla llamada DetallesPedido y otra Productos.

Tabla DetallesPedido:

id_pedido	id_producto	cantidad
1	A1	2
1	B2	1
2	A1	3

Tabla Productos:

id_producto	nombre_producto	precio_producto
A1	Ratón	15
B2	Teclado	25

Ahora cantidad depende de toda la clave (id_pedido, id_producto).

Y nombre_producto y precio_producto dependen únicamente de id_producto, que ahora es clave primaria en su propia tabla.

Y como vemos, acabamos de eliminar la dependencia parcial y, por tanto, hemos aplicado correctamente la 2FN 🙂

Tercera Forma Normal (3FN)

Debe cumplir:

• Con la 2FN, que a su vez cumple con la primera forma, ¿recuerdas?
• Un campo no clave, no debe depender de otro campo no clave. Esto se conoce como dependencia transitiva.

Es decir, si tenemos:

ID_Empleado	Nombre	ID_Departamento	Nombre_Departamento
E001	Elena	5	Ventas
E005	Mario	2	IT

Aquí nos encontramos con que Nombre_Departamento depende de ID_Departamento, no de la clave primaria ID_Empleado. Entonces, hay una dependencia transitiva entre el campo no clave (Nombre_Departamento) y la clave primaria, por tanto, rompemos la 3FN, que en resumidas cuentas dice: “Todos los atributos no clave deben depender directamente de la clave primaria.”

Así pues, ¿solución?

Separar en dos tablas:

Tabla Empleados:

ID_Empleado	Nombre	ID_Departamento
E001	Elena	5
E005	Mario	2

Tabla Departamentos:

ID_Departamento	Nombre_Departamento
5	Ventas
2	IT

Y ahora, finalmente:

• En Empleados cada campo depende directamente de ID_Empleado
• En Departamentos, los datos del departamento como en este caso el nombre del mismo, dependen directamente de ID_Departamento.
• Hemos eliminado la dependencia transitiva 😎

Resumiendo un poco y concluyendo

Acabamos de ver las tres formas principales, las cuales en la mayoría de casos son suficientes. Existen otras formas que no hemos visto por ahora, pero quedan pendientes para un futuro artículo.

De momento nos quedamos con esto, qué es la normalización, su importancia en el desarrollo de bases de datos relaciones y saber que, aplicar al menos estas tres formas correctamente, no solo permiten reducir la redundancia y mejorar la integridad de los datos, sino que además sientan las bases para una base de datos eficiente, consistente y escalable.

Por cierto, «una base de datos bien normalizada es como una biblioteca bien organizada: fácil de consultar, mantener y ampliar.”

¡Ahí queda eso! Espero que te haya gustado 😉

Sobre el autor