Normalización: evita las redundancias en las

bases de datos
Uno de los términos clave de la modelación relacional de datos es la normalización. En este modelo
la calidad del diseño de la base de datos viene determinada por una redundancia reducida al mínimo
posible, puesto que los datos repetidos producen anomalías semánticas que dificultan tanto el
procesamiento automático de los datos como el mantenimiento mismo de la base de datos. La
normalización es la estrategia con la que se eliminan las redundancias en las bases de datos
relacionales.

Qué es la normalización

La normalización es un concepto de diseño de bases de datos que se aplica a las bases de datos
relacionales para evitar las redundancias.

El modelo relacional es el concepto más extendido en la gestión informatizada de los datos. En las
bases de datos de este tipo, la información se guarda en registros en tablas interconectadas por
medio de claves. Un registro se compone de varios campos de valores que se subordinan a ciertos
atributos a lo largo de las columnas de la tabla.

La siguiente tabla muestra los datos de facturas ficticias, emitidas por una distribuidora de material de
oficina. El empleado José García ha hecho un pedido para su empresa de 10 monitores, 12 ratones y
una silla de oficina. La compra de María Pérez comprende 2 ordenadores portátiles y 2 juegos de
auriculares.
En la base de datos de esta tienda online, los datos de las facturas se ordenan en función de los
atributos número de factura (Nº factura), fecha, cliente, número de cliente (Nº cliente), dirección,
posición del ítem (Pos. ítem), artículo, número de artículo (Nº artículo), número de unidades (Uds.) y
precio. Cada línea de la tabla corresponde a un registro, denominado tupla.

Esta tabla constituye un ejemplo de tabla mal diseñada, puesto que ya de entrada saltan a la vista
sus múltiples redundancias.

A esto se añade que las celdas de las columnas Cliente y Dirección contienen datos compuestos por
más de un valor (multivalor). Se hablaría en este caso de una base de datos no normalizada, cuyo
mayor inconveniente radica en que necesita más memoria como consecuencia de la repetición de
valores. Además, los atributos que contienen datos multivalor no se pueden procesar ni relacionar
bien. Así, según esta tabla de ejemplo, los dos clientes tienen una dirección de Villarriba, pero como
esta información no se ha recogido por separado (calle, número, CP, municipio), no sería posible filtrar
la tabla por clientes del mismo municipio.

Para evitar los campos dobles o compuestos por varios valores se han desarrollado, en el marco de
los modelos relacionales, tres formas normales que se complementan entre sí. Cada forma normal
persigue que la base de datos se encuentre en un estado determinado, y para lograrlo, se han de
cumplir ciertas condiciones. Una base de datos satisface entonces la primera, la segunda o la tercera
forma normal, si se cumplen las condiciones de cada una de ellas.

Cómo se normaliza una base de datos

Para aclarar cómo se aplican las tres formas normales a una base de datos relacional, se recorrerán
en adelante las diversas fases de la normalización con ejemplos. Partiremos para ello del
fragmento mostrado arriba.

Primera forma normal (1FN)

Una tabla en una base de datos relacional está en la primera forma normal cuando se cumplen estas
condiciones:

 Todos los datos son atómicos.

 Todas las columnas contienen el mismo tipo de datos.

Un registro se considera atómico cuando a cada información (cada asunto) se le reserva una celda
propia.
En nuestra tabla los campos correspondientes a los atributos cliente, dirección y precio no son
atómicos o no contienen datos del mismo tipo:

Las celdas en negrita muestran que nuestra tabla incumple ambas condiciones y por lo tanto no está
en la primera forma normal. Para normalizarla se hace lo siguiente:

1. Subdividir todos los datos multivalor en columnas separadas.

2. Comprobar que los valores en cada columna son del mismo tipo.

Para cumplir con el estado atómico de los datos, los atributos cliente y dirección se han de subdividir
en los atributos más específicos nombre y apellidos, así como calle, número, código
postal y municipio.
En la columna Precio hay datos en euros y en céntimos: hay que decidirse por un tipo de dato (en €)
para generar campos coherentes. Quedaría así:

El resultado es una tabla que, si bien está en la primera forma normal, los valores duplicados
siguen impidiendo procesar los datos de forma eficiente. Para reducir las redundancias se
recomienda llevarla a la segunda forma normal.

Segunda forma normal (2FN)

Para estar en la segunda forma normal, a las condiciones de la primera se añade la siguiente:

 Los atributos que no forman parte de ninguna clave han de depender funcionalmente de toda
la clave primaria.

Al principio, se definió a una base de datos relacional como un sistema de tablas relacionadas por
medio de claves. Las claves sirven para identificar inequívocamente a los registros. La clave que
permite nombrar claramente a cada una de las filas de una tabla se denomina superclave. Esta puede
resultar de los valores de una única columna o de la suma de los valores de varias columnas.

En nuestro ejemplo, los atributos número de factura, número de cliente y posición de ítem podrían
componer una posible superclave:
Una clave número de factura, número de cliente y posición de ítem con los valores {124, 12,
1} permitiría entonces identificar claramente al registro de la compra que ha hecho María Pérez:

Pero para esta identificación no es necesaria toda la información aportada por la superclave. Una
combinación de número de factura y posición de ítem (es decir, un subconjunto de la superclave)
debería bastar para identificar a cada registro. Estas claves con la mínima cantidad de atributos se
conocen como claves candidatas.

Normalmente, se escoge a una clave candidata por tabla para representarla. Su valor ideal es una
numeración correlativa. Esta clave se erige en clave primaria y señala el orden de los registros.

Como cualquier candidata a clave, la clave primaria también puede componerse de un solo valor o,
como en nuestro ejemplo, de varias claves. Nuestra tabla utiliza una clave primaria compuesta;
formada por el número de factura y la posición de ítem.

Pero para llevar a una tabla a la segunda forma normal, no solo es necesario conocer la clave primaria
y todos los atributos que no son clave, sino también cómo se relacionan entre sí. Para hacerlo se
siguen estos pasos:
 1. Comprueba que todos los atributos no-clave dependen por completo de la clave primaria. Esta
dependencia se da si todos los atributos de la clave primaria son necesarios para identificar a
los atributos no-clave. Esto quiere decir también que las tablas con claves primarias simples
se ajustan automáticamente a la 2FN si se cumplen las condiciones para la 1FN.
2. Relega a los atributos no-clave que no dependen de la clave primaria a tablas diferentes.

Si volvemos a nuestra tabla y la observamos atentamente, podremos ver que las condiciones para
la segunda forma normal no se cumplen por los siguientes motivos: la columna Fecha solo
depende del número de factura, pero no de la posición del artículo en la factura. Lo mismo puede
decirse para los datos de los clientes (apellido, nombre, calle, nº, CP, municipio).

Para que una tabla esté en la 2FN enviamos a los atributos dependientes del número de factura a una
tabla separada llamada Factura:

A la tabla con el resto de datos la llamamos Posición del ítem:

Tras la normalización, el número de factura se encuentra en ambas tablas, conectándolas. Mientras

que este atributo actúa de clave primaria en la tabla Factura, en la tabla Posición del ítem se utiliza
como clave foránea y forma parte, al mismo tiempo, de la clave primaria compuesta de la tabla.
Nuestras tablas están ahora en la segunda forma normal, pero aún no se han eliminado del todo las
redundancias. Por eso‚ la meta de la normalización suele ser la tercera forma normal.

Tercera forma normal (3FN)

Para que una tabla esté en la tercera forma normal ha de cumplir las condiciones de las dos primeras
y además:

 Los atributos no-clave no pueden depender de forma transitiva de una clave candidata.

Se da una dependencia transitiva si un atributo que no es clave depende de otro atributo que no es
clave y de forma indirecta de su clave candidata.

Nuestro esquema incumple las condiciones de la tercera forma normal en varios puntos:

En la tabla Factura, los atributos nombre y apellido, así como calle, número, CP y municipio no solo
dependen de la clave primaria (número de factura) sino también del número de cliente.

En la tabla Posición del ítem los atributos artículo y precio dependen de la clave primaria compuesta
por número de factura y el número de ítem, pero también del número de artículo. También se infringe
aquí la condición específica de la tercera forma normal:
Para eliminar las dependencias entre atributos no-clave repartimos los datos en tablas separadas
que se interconectan con claves ajenas. De este modo, resultarán las cuatro tablas
normalizadas Factura, Cliente, Posición y Artículo.

La clave primaria de la tabla Factura es un número de factura correlativo. Cada número de factura se
clasifica con la fecha de la factura y el número de cliente:

En la tabla Cliente se depositan datos más aproximados sobre los clientes, y ambas
tablas, Factura y Cliente, se conectan mediante el número de cliente, que en la tabla Cliente hace de
clave primaria y en Factura de clave ajena:

Una tabla crucial en nuestra base de datos es la Posición del ítem, puesto que revela qué artículos se
incluyen en cada factura y cuántas unidades se han pedido. La clave primaria correlativa de la tabla
resulta del número de factura y la posición del ítem en la factura. Los artículos están presentes en la
tabla solo con el número de artículo y actúan de clave ajena que enlaza con la tabla Artículo.

La tabla Artículo solo contiene los detalles sobre cada artículo, como su denominación o el precio.
Como clave primaria tenemos el número de artículo correlativo:
En nuestro ejemplo puede parecer poco eficiente fragmentar dos tablas en cuatro. De hecho, las
redundancias en los datos de solo dos clientes no saltan apenas a la vista. Imaginemos, sin embargo,
que queremos procesar varios cientos de miles de registros sobre clientes o sobre la gama de
productos de la empresa de forma consistente y libre de contradicciones. Esto solo suele ser
posible con un esquema que se ajuste a la tercera forma normal.

Aun cuando la normalización de bases de datos implica un mayor esfuerzo de programación, la tercera
forma normal está considerada como el estándar para los esquemas relacionales y solo se descarta
bajo contadas excepciones. Una de ellas sería la desnormalizacion de bases de datos que están en
la tercera forma normal a la segunda forma normal. Esto se hace porque los Joins que enlazan varias
tablas en bases de datos muy grandes tardan mucho tiempo. Desnormalizando la base de datos se
espera reducir el número de tablas y con ello la duración de la consulta.