Módulo 2: Bases de Datos

4. Normalización

Concepto de normalización, dependencias funcionales y sus tipos

Cuando estamos diseñando una BDD debemos seguir una serie de pasos y, a la hora
de finalizar, debemos pasar del modelo entidad-relación al modelo relacional. Esto
es los que se conoce con el nombre de normalización. Cuando diseñamos una BDD o
incluso un sistema informático debemos medir su calidad y podemos hacerlo
mediante la forma normal.
El objetivo de la normalización es:
a) Eliminar la redundancia.
b) Eliminar la inconsistencia de datos.
c) Garantizar la integridad referencial.

Antes de profundizar un poco más en las formas normales, acararemos un poco el

concepto de dependencia funcional:
d) Dependencia funcional. Un atributo depende directamente de la clave.

e) Dependencia funcional completa. Un atributo depende de la totalidad de la

clave (casos clave compuestos por más de un atributo).

Página 50 de 94
 Módulo 2: Bases de Datos

f) Dependencia funcional transitiva. Un atributo depende de otro atributo no

clave que presenta una dependencia funcional con la clave.

g) Dependencia parcial. Un atributo no depende de la totalidad de la clave (casos

de claves compuestas por más de un atributo) sino que depende
funcionalmente de uno de sus atributos.

Página 51 de 94
 Módulo 2: Bases de Datos

Primera forma normal (1FN)

No se permite que en una tabla existan atributos que tomen más de un valor. Todos
sus valores deben ser atómicos, es decir, unievaluados.

El primer paso es atomizar el campo teléfono como se muestra. Esta solución genera
una fuerte redundancia de datos (los campos nombre y apellidos).
Por lo que una solución correcta sería:

La solución óptima pasa por separar los datos en dos tablas diferentes: una para los
datos que ya eran atómicos y otra para el campo multivaluado.

Página 52 de 94
 Módulo 2: Bases de Datos

Segunda forma normal (2FN)

Para que un atributo se encuentre en la 2FN debe estar en la 1FN y, además, los
atributos que no forman parte de la clave tienen una dependencia completa de la
clave principal.

Como podemos ver, el campo dirección depende de “CodTienda”, pero no de

“CodLibro”, por tanto, esta tabla no se encuentra en 2FN.

Para pasar esta tabla a 2FN:

Podemos ver que la solución que estamos buscando pasa por dividir la información
en dos tablas de forma que tengamos una dependencia completa de la clave en
ambas.

Página 53 de 94
 Módulo 2: Bases de Datos

Tercera forma normal (3FN)

Decimos que una relación está en 3FN cuando está en 2FN y cuando los atributos que
no forman parte de la clave primaria son independientes entre sí, es decir, no
presentan dependencias transitivas.

Podemos ver que el campo “Nombre Dpto” depende transitivamente de la clave a

través del campo “Cod. Dpto”, por tanto, esta tabla no está en 3FN.
Para llegar a una solución óptima podemos pasar a crear dos tablas, eliminando la
información que tenía dependencia transitiva y creando una nueva tabla para ella.

Página 54 de 94
 Módulo 2: Bases de Datos

Forma normal Boycce-Codd

La FNBC es una versión de la 3FN un poco más estricta. Decimos que una relación
está en FNBC cuando está en 3FN y cuando todos sus atributos no clave son clave
candidata.

En resumen, para que una tabla se encuentre correctamente normalizada debemos

seguir tres principios fundamentales:
1. No pueden existir atributos multivaluados.
2. Todos los atributos deben depender de forma completa y No transitiva de la
clave.
3. Si existen claves candidatas compuestas, no deben tener un atributo común.

Otras formas normales (4FN, 5FN)

Estas formas normales se van a ocupar de las dependencias entre atributos
multivaluados.

Desnormalización
Podemos definir la desnormalización como aquel proceso mediante el cual
pretendemos optimizar el desarrollo de una BDD mediante la agregación de aquellos
datos redundantes.

Página 55 de 94