La normalización optimiza las tablas en los sistemas de gestión de bases de datos (DBMS) para cumplir con lo que se conoce como formas normales: conjuntos de reglas que rigen cómo se organizan los atributos dentro de una tabla. Estas reglas se basan en gran medida en las relaciones entre atributos (columnas), incluidas las claves utilizadas para identificar filas de forma única.
En esencia, la normalización de bases de datos, a veces denominada normalización de datos, ayuda a las empresas e instituciones a organizar, consultar y mantener de forma más eficaz grandes volúmenes de datos complejos, interrelacionados y dinámicos . Aunque las empresas ahora generan y almacenan datos a una escala sin precedentes, la necesidad de normalizar las bases de datos no es nueva. Es anterior al almacenamiento en la nube e incluso a la invención de los almacenes de datos.
Desde la década de 1960, las empresas tienen dificultades para gestionar grandes conjuntos de datos. En la década de 1970, Edgar F. Codd, el matemático de IBM conocido por su histórico artículo sobre la introducción de las bases de datos relacionales, propuso que la normalización de las bases de datos podría evitar las dependencias "indeseables" entre los atributos (columnas) y los problemas que pueden crear.
En otras palabras, cuando los registros de datos están relacionados entre sí en una estructura de base de datos, los cambios en valores individuales o filas en una tabla grande y complicada pueden tener consecuencias no deseadas, como la incoherencia de los datos y la pérdida de datos. La normalización de bases de datos está diseñada para minimizar dichos riesgos.
Los beneficios de la normalización de bases de datos incluyen:
Cuando las tablas más grandes y complejas se descomponen (o dividen) en tablas más pequeñas y sencillas, modificar una base de datos se convierte en un proceso más fácil y menos propenso a errores, y limita los cambios a las tablas ahora más pequeñas de datos relacionados.
Aunque la redundancia de datos intencionada puede ayudar a mejorar la calidad de los datos, la seguridad y la disponibilidad, la redundancia no intencionada es el efecto de los sistemas que crean datos duplicados de forma inadvertida, lo que da lugar a ineficiencias.
Reducir los datos duplicados mediante la normalización de las bases de datos puede reducir los costes de almacenamiento de datos. Esto es especialmente importante para los entornos de nube, donde los precios suelen basarse en el volumen de almacenamiento de datos utilizado.
Una menor redundancia de datos debido a la normalización también puede conducir a consultas de datos más rápidas, ya que una menor redundancia a menudo requiere menos proceso de datos durante las búsquedas.
La normalización de las estructuras de datos puede prevenir tres tipos clave de anomalías:
Anomalías de inserción: se produce una anomalía de inserción cuando un registro de datos no se puede insertar en una tabla porque tiene missing values requeridos por una o más columnas de la tabla.
Anomalías de eliminación: una anomalía de eliminación se produce cuando la eliminación de un registro resultados en la eliminación involuntaria de datos importantes incluidos en dicho registro.
Anomalías de actualización: se produce una anomalía de actualización cuando una instancia de datos se actualiza en una ubicación de una base de datos, pero no en otras ubicaciones donde también se almacena ese valor de datos, lo que provoca una falta de coherencia de los datos.
En las bases de datos relacionales, una clave es una columna o una colección ordenada de columnas utilizada para identificar filas de datos en una tabla. Las claves de los modelos relacionales también establecen asociaciones entre tablas relacionadas. Estas capacidades permiten consultas de base de datos SQL eficaces y exitosas. Las claves que ocupan un lugar destacado en las reglas de normalización de bases de datos incluyen:
Una clave principal es una columna o columnas en una tabla de base de datos con valores que sirven como identificadores únicos para cada fila o registro. Por ejemplo, una columna de ID de estudiante podría ser una clave principal en una tabla de información del estudiante. Las características definitorias de las claves primarias son que excluyen valores nulos, no tienen valores duplicados y pueden constar de columnas únicas o múltiples.
Las claves que constan de dos o más columnas se denominan claves compuestas. Cuando las claves primarias son claves compuestas, pueden denominarse claves primarias compuestas.
Una clave candidata es una columna o grupo de columnas que tiene las características de una clave principal pero a la que no se le ha asignado el estado de clave principal.
Una clave externa en una tabla hace referencia a una clave primaria específica en otra tabla para definir una relación entre las tablas. Cuando las tablas más grandes se dividen en tablas más pequeñas durante la normalización, las claves externas y las claves primarias establecen una asociación entre las nuevas tablas.
Las superclaves, aunque similares a las claves primarias compuestas, también constan de más columnas de las necesarias para identificar registros de forma única.
Varias restricciones de normalización de bases de datos se basan en las relaciones (también conocidas como dependencias) entre las claves primarias y las columnas que no son claves primarias ni candidatas. Estos últimos se conocen como atributos no clave o atributos no principales.
Las relaciones entre atributos en bases de datos en las que un atributo (el determinante) determina el valor de otro atributo se conocen como dependencias funcionales. Los tipos de dependencias funcionales entre atributos incluyen dependencia parcial, dependencia transitiva, dependencia multivalor y dependencia de unión. Estas relaciones se entienden mejor cuando se analizan en el contexto de conjuntos relevantes de reglas de normalización o formas normales.
Ejecutar la normalización en modelos de datos implica diseñar tablas para ajustarse a uno o más niveles de normalización, también conocidos como formas normales. Las formas comunes incluyen:
La primera forma normal, el criterio de normalización de bases de datos más básico, requiere que un esquema de tabla de base de datos incluya una clave principal y excluya la repetición entre columnas. Para ser más específicos, una tabla en primera forma normal no debe tener campos con matrices de valores, por ejemplo, una sola celda con tres nombres diferentes, ni debe incluir grupos repetidos, que son columnas diferentes que almacenan el mismo tipo de datos.
Para comprender mejor la primera forma normal, utilicemos el siguiente conjunto de columnas como ejemplo:1
rec_num | lname | fname | bdate | anniv | child1 | child2 | child3 |
Las columnas comprenden una tabla con un grupo de padres, incluyendo sus nombres, fechas de nacimiento, aniversarios de boda, correos electrónicos y nombres de los hijos.
Esta tabla viola la primera forma normal porque contiene tres columnas separadas que almacenan el mismo tipo de información: nombres de niños. En este caso en particular, la estructura de la tabla podría abrir la puerta a errores de inserción. Por ejemplo, en el mundo real, muchos padres tienen menos de tres hijos.
En nuestra tabla de ejemplo, no es posible agregar los registros de dichos padres a la tabla. Además, consultar esta tabla por el nombre de un niño sería ineficaz, ya que requeriría buscar datos en tres columnas diferentes en cada fila.
Para obtener la primera forma normal de los datos de la tabla es necesario separar la tabla original en dos. Una mesa incluiría la mayoría de los atributos de la tabla original y la otra se centraría en los niños.
TABLA 1
rec_num | lname | fname | bdate | anniv | Correo electrónico |
TABLA 2
rec_num child_name
En este ejemplo, las nuevas tablas permanecen vinculadas a través de la columna "rec_num", que es la clave principal de la tabla 1 y a la que hace referencia la columna "rec_num" de la tabla 2, que actúa como clave externa.
Aunque cumplir con la primera forma normal puede que no reduzca los datos redundantes (los valores "rec_num" aparecerán en varias filas de la tabla 2 cuando los padres tengan más de un hijo), la eliminación de grupos repetidos puede simplificar las consultas.
En la segunda forma normal, ningún atributo que no sea clave tiene una dependencia parcial de la clave principal de la tabla. En otras palabras, si una clave principal es una clave compuesta, el atributo no clave debe depender de cada columna de esa clave compuesta.
Por ejemplo, considere una tabla de inventario que tenga registros de cantidades de piezas específicas que se almacenan en almacenes particulares. La siguiente figura muestra los atributos de la entidad de inventario2.
part | warehouse | quantity | warehouse_address |
En este ejemplo, las columnas “part” y “warehouse” forman una clave principal compuesta. Sin embargo, el atributo “warehouse_address” depende únicamente del valor de “warehouse”, por lo que la tabla viola la segunda forma normal.
Esta tabla también es propensa a la redundancia de datos, ya que el valor de warehouse_address aparece cada vez que aparece en la tabla el registro de una pieza del mismo almacén. Esto aumenta el riesgo de que se produzcan errores de actualización si la dirección se actualiza en una fila y no en otras. También se puede producir un error de eliminación si algún almacén deja de almacenar piezas. Si se borra el registro de esas piezas, también se eliminaría la dirección del almacén.
Para cumplir con la segunda forma normal y reducir la probabilidad de errores, los datos se pueden distribuir en dos tablas nuevas:
TABLA 1
part | warehouse | quantity |
TABLA 2
warehouse warehouse_address
Una tabla en tercera forma normal satisface tanto la primera como la segunda forma normal y, al mismo tiempo, evita situaciones en las que los atributos no clave dependen de otros atributos no clave en lugar de claves principales. Cuando los atributos no clave dependen de otros atributos no clave, esto se conoce como dependencia transitiva, una violación de la tercera forma normal.
Considere la siguiente tabla de información sobre los empleados:3
emp_num | emp_fname | emp_lname | dept_num | dept_name |
0200 | David | Brown | D11 | Sistema de fabricación |
0320 | Ramlal | Mehta | E21 | Soporte de software |
0220 | Jennifer | Lutz | D11 | Sistema de fabricación |
En esta tabla, la clave principal es la columna "emp_num". Sin embargo, la columna "dept_name" depende de la columna «dept_num», un atributo que no es clave. Por lo tanto, la tabla no cumple con la tercera forma normal y aumenta el riesgo de errores, como anomalías en las actualizaciones: si se cambiara el nombre de un departamento, como "sistema de fabricación", habría que actualizarlo en más de una fila según el esquema actual de la tabla.
Organizar los datos en la tercera forma normal en una base de datos normalizada podría prevenir tales errores. En este caso, este proceso implicaría estructurar los datos en tres tablas separadas: EMPLOYEE, DEPARTMENT y EMPLOYEE_DEPARTMENT 4
Tabla EMPLOYEE
emp_num | emp_fname | emp_lname |
0200 | David | Brown |
0320 | Ramlal | Mehta |
0220 | Jennifer | Lutz |
Tabla DEPARTMENT
dept_num | dept_name |
D11 | Sistema de fabricación |
E21 | Soporte de software |
Tabla EMPLOYEE_DEPARTMENT
dept_num | emp_num |
D11 | 0200 |
D11 | 0220 |
E21 | 0320 |
La forma normal de Boyce-Codd, o BCNF, es una forma normal que se considera una versión más estricta o más fuerte de la tercera forma normal. BCNF requiere el uso de superclaves.
Una tabla está en cuarta forma normal si no tiene dependencias de varios valores. Las dependencias multivalor se producen cuando los valores de dos o más columnas son independientes entre sí y solo dependen de la clave principal.
Un ejemplo comúnmente citado en los tutoriales se centra en las tablas de empleados que enumeran tanto las habilidades como los idiomas. Un empleado puede tener varias habilidades y hablar varios idiomas. Existen dos relaciones: una entre empleados y habilidades y otra entre empleados e idiomas.
Una tabla no está en cuarta forma normal si representa ambas relaciones. Para convertir los datos a la cuarta forma normal, sería necesario estructurarlos en dos tablas: una para las habilidades de los empleados y otra para los idiomas.
Considerada comúnmente como el nivel más alto de normalización, la quinta forma normal es un criterio centrado en la dependencia de la unión. En la dependencia de unión, después de que una tabla se divide en tablas más pequeñas, es posible reconstruir la tabla original reuniendo nuevamente las nuevas tablas, todo ello sin perder ningún dato ni crear accidentalmente nuevas filas de datos. Es comparable a un rompecabezas completado que, cuando se desarma, puede volver a armarse en su forma original.
En la quinta forma normal, una tabla debe dividirse en tablas más pequeñas solo cuando se puede lograr la dependencia de unión. Sin embargo, si los intentos de reconstruir la tabla original a partir de tablas más pequeñas conducen involuntariamente a la creación de una tabla ligeramente diferente, entonces no debería tener lugar la descomposición de la tabla original. Volviendo a nuestra analogía del rompecabezas, sería como volver a armar un rompecabezas y luego descubrir que falta una pieza o que ha aparecido una pieza extra.
A pesar de todos sus beneficios, la normalización de bases de datos también tiene sus desventajas. Por ejemplo, antes de la normalización, un usuario que busca datos específicos podría tener que consultar solo una tabla. Sin embargo, si una base de datos tiene más tablas después de una normalización, el usuario puede encontrarse en la situación de tener que consultar varias tablas, lo que puede ser un proceso más lento y más costoso.
Además, aunque la normalización simplifica las tablas individuales, puede aumentar la complejidad general de la base de datos, lo que requiere una gran experiencia por parte de los diseñadores y administradores de bases de datos para garantizar una implementación adecuada.
Cree y gestione canalizaciones de datos de streaming inteligentes a través de una interfaz gráfica intuitiva, y facilite una integración de datos fluida en entornos híbridos y multinube.
Watsonx.data le permite escalar la analítica y la IA con todos sus datos, residan donde residan, a través de un almacén de datos abierto, híbrido y gobernado.
Desbloquee el valor de los datos empresariales con IBM Consulting, y construya una organización impulsada por conocimientos que ofrezca ventajas empresariales.
1 “First normal form.” Documentación de IBM, Informix Servers. 19 de noviembre de 2024.
2, 3, 4 “Normalization in database design.” Documentación de IBM, Db2 for z/OS. 22 de enero de 2025.