Bases de Datos: Formas Normales (Optimizar

Tablas)
Autor: Carlos Carmona
Este artculo est bajo licencia CopyLeft. Se permite pus su libre distribucin con la nica
condicin de incluir el nombre del autor y un enlace a la web original.
La normalizacin es un proceso que pretende conseguir tablas con una estructura ptima y eficaz. El proceso de
normalizacin est basado en lograr la independencia de los datos respecto a las aplicaciones que los usan.
Antes de empezar el proceso, se han de conocer las tablas que intervendrn y las relaciones que las unen. Si no se
conocen a partir del anlisis previo, se buscan todos los nombres (sustantivos) que han sido empleados en la
definicin del problema. Algunos de esos nombres sern las entidades, otros dependern de ellas y sern los
atributos. Otros no formarn parte ni de las entidades ni de los atributos, son parte del lenguaje necesario para
describir el problema a solucionar mediante la creacin de una base de datos.
Ejemplo prctico.
<<...a cada cliente, al pasar por Caja... se marcan por la caja registradora los artculos que ha comprado.
Con los datos de los artculos se hace una factura por el importe total de las mercancas adquiridas que se
imprime y se entrega al cliente. Los datos de la factura se almacenan para su posterior tratamiento
informtico que comprende...>>.
Las tablas son sustantivos, por lo que tenemos los siguientes: cliente, Caja, caja registradora, artculos, datos de los
artculos, factura, importe total, mercancas adquiridas, datos de la factura. De estos nombres, algunos son atributos
de otros: datos de los artculos y artculos, datos de la factura, importe total y factura. De cada cliente no se piden
datos, por lo que aunque sea una tabla, si no se necesitan sus datos, no se crear esa entidad. Caja con mayscula
se refiere a un objeto con el que se realizan procesos, por lo que no se necesita almacenar informacin de ellos. De
cada una de las cajas registradoras, tal vez se necesite para las facturas, el nmero de caja, por lo que se considera
una entidad ms. Mercancas adquiridas y artculos que ha comprado son sinnimos, por lo que solo se tratar de
artculos.
Las tablas encontradas tras el anlisis son: artculos, factura y caja registradora. Caja registradora se puede
considerar un atributo de factura, por lo que tenemos dos tablas.
Las relaciones se pueden encontrar conociendo todos los verbos que aparecen en la definicin del problema. Se
eliminan aquellos verbos que son necesarios para el lenguaje y se buscan aquellos que implican dos o ms
entidades (sustantivos) que ya se han encontrado.
En el ejemplo han aparecido los verbos: pasar, se marcan, ha comprado, se hace una factura, imprime, entrega,
almacena. De estos verbos, los que asocian entidades son: marcar, comprar. Los verbos pasar, hacer factura,
imprimir, entregar, almacenar, se refieren a procesos que se van a realizar, no a asociaciones entre entidades.
Se han obtenido las siguientes entidades con sus relaciones: clientes, comprar artculos y marcar artculos en
factura. Como no se necesitan los datos de los clientes, queda la relacin marcada (en la caja registradora) que une
las tablas artculos, y factura. La operacin marcar en la caja registradora significa que los artculos se incluyen en
una factura que se entregar al cliente para su liquidacin, consiguindose obtener el modelo entidad-relacin
siguiente:

Hay cinco niveles de normalizacin, siendo cada vez ms complejo el proceso de obtencin de tablas normalizadas.
Para bases de datos relativamente sencillas se puede terminar la normalizacin en el tercer nivel o tercera forma
normal.
El proceso de normalizacin se basa en la descomposicin sin prdida de las tablas que estn en una forma normal
inferior, obtenindose una forma normal superior. El proceso de descomposicin sin prdida, significa que se ha de
dividir o descomponer la tabla en otras con menor cantidad de atributos sin que haya perdida de informacin.
Formas normales y dependencias funcionales.
Primera Forma Normal o 1FN:
La Primera Forma Normal, o 1FN, es la ms elemental de todas. Una tabla est en 1FN si el valor que contiene un
atributo de un registro, un campo, es nico y elemental. En cada uno de los atributos slo se puede incluir un dato,
aunque sea compuesto, pero no se pueden incluir una lista de datos. Por ejemplo, no se pueden incluir en el atributo
Direccin el domicilio habitual y el de vacaciones; habra que crear dos registros que se diferenciarn por el atributo
Direccin:
NIF Ape Nom Dir CPost Pobl Prov
1 Garca Francisco C/Marn 16 33698 Oviedo Asturias
2 Sanchez Luisa
C/Teneras 34
C/Ramorta 65
85458
54585
Cigales
Bueu
Valladolid
Pontevedra
Esta tabla no est en 1FN, ya que el cliente con Id 2 tiene dos direcciones. Para poder tener esta tabla en 1FN se
hace el siguiente cambio:
NIF Ape Nom Dir CPost Pobl Prov
1 Garca Francisco C/Marn 16 33698 Oviedo Asturias
2 Sanchez Luisa C/Teneras 34 85458 Cigales Valladolid
2 Sanchez Luisa C/Ramorta 65 54585 Bueu Pontevedra
Segunda Forma Normal o 2FN:
Se dice que un atributo o conjunto de atributos tiene dependencia funcional de otro u otros si a cada uno de los
primeros le corresponde slo uno de los segundos.
Por ejemplo, hay una dependencia funcional entre CIF y el atributo Razn Social, ya que a cada CIF le corresponde
una nica Razn Social.
Una tabla est en Segunda Forma Normal o 2FN cuando est en 1FN y todo atributo que no pertenece a la clave
primaria tiene una dependencia funcional de la clave completa y no de parte de ella. Luego, si la clave principal est
formada por un solo atributo y ya est en 1FN, ya estar en 2FN.
Para transformar una tabla con dependencias funcionales, cuya clave est formada por ms de un campo, en una
tabla en 2FN se necesitan crear tablas nuevas para eliminar las dependencias funcionales, las tablas nuevas
tendrn los atributos que dependen funcionalmente de la clave y los que forman la parte de la clave de la que
dependen. Una vez creadas las nuevas tablas, se eliminan de la tabla primera los atributos que tenan dependencias
funcionales.
En el ejemplo anterior, tanto el nombre como los apellidos dependen del NIF. Se crea una nueva tabla que contiene
los atributos: NIF, nombre y apellidos, eliminndose de la tabla cliente los atributos nombre y apellidos, quedando las
siguientes tablas:
NIF Dir CPost Pobl Prov
1 C/ Marn n16 33698 Oviedo Asturias
2 C/ Teneras n34 85458 Cigales Valladolid
2 C/ Ramorta n65 54585 Bueu Pontevedra

NIF Ape Nom
1 Garca Francisco
2 Sanchez Luisa
Tercera Forma Normal o 3FN:
Se dice que hay dependencia funcional transitiva entre dos atributos cuando un atributo que no pertenece a la clave
primaria permite conocer el valor de otro atributo.
Por ejemplo: dada la tabla clientes, entre los atributos provincia y prefijo telefnico hay una dependencia funcional
transitiva, ya que el primero permite conocer el valor del segundo.
Una tabla est en Tercera Forma Normal o 3FN si est en 2FN y no existen atributos que no pertenezcan a la clave
primaria que puedan ser conocidos mediante otro atributo que no forma parte de la clave primaria, es decir, no hay
dependencias funcionales transitivas.
Siguiendo con el ejemplo anterior, cuando hay dependencias funcionales transitivas, se crea una nueva tabla con los
atributos que tienen dependencia funcional transitiva, eliminndose el atributo dependiente de la tabla original.
Si nos fijamos en esta tabla:
NIF Dir CPost Pobl Prov
1 C/ Marn n16 33698 Oviedo Asturias
2 C/ Teneras n34 85458 Cigales Valladolid
2 C/ Ramorta n65 54585 Bueu Pontevedra
La direccin, la poblacin y la provincia dependen del cdigo postal, que no forma parte de la clave primaria.
Descomponiendo sin perdida una vez ms, obtenemos estas dos tablas:
NIF Dir
1 C/ Marn n16
2 C/ Teneras n34
2 C/ Ramorta n65

CPost Dir Pobl Prov
33698 C/ Marn n16 Oviedo Asturias
85458 C/ Teneras n34 Cigales Valladolid
54585 C/ Ramorta n65 Bueu Pontevedra
Para solucionar algunos problemas de dependencias funcionales, que no se podan resolver solo con la
normalizacin en 3FN, se han propuesto tres formas normales adicionales. La normalizacin ms all de 3FN queda
al juicio del diseador de la base de datos. A partir de esa forma normal, la eliminacin de dependencias funcionales
pasa por la creacin de tablas con multitud de informacin redundante, con un posible aumento de tamao, por lo
que se ha de optar entre una optimizacin del diseo y una optimizacin del tamao. Llegndose a diversas
soluciones de compromiso entre ambos parmetros. Salvo excepciones, con la 3FN o a lo sumo, la FNBC (que
veremos a continuacin) es ms que suficiente, y llevar la normalizacin ms all ser ms perjudicial que
beneficioso.
Forma Normal de Boyce-Codd o FNBC:
Una tabla est en Forma Normal de Boyce-Codd o FNBC si solo existen dependencias funcionales elementales que
dependan de la clave primaria o de cualquier clave alternativa. Si la clave primaria est formada por un solo atributo
y est en 3FN, ya est en FNBC.
Un ejemplo tpico para mostrar una tabla que, estando en 3FN, mantiene dependencias funcionales, sin relacin con
el ejemplo seguido hasta este momento, es una tabla que posee los atributos direccin, cdigo postal y poblacin,
suponiendo que a poblaciones diferentes le corresponden cdigos postales distintos.
CPost Dir Pobl
30009 C/ Pantano Camarillas n16 Murcia
48596 Av. Buenos Aires n12 Madrid
En este caso hay dependencia entre el cdigo postal y la poblacin, ya que, conocido el cdigo postal se puede
conocer la poblacin, y conocida la direccin y la poblacin, se conoce el cdigo postal. Para transformar la tabla en
una tabla en FNBC se crea una tabla de cdigos postales y poblaciones, eliminando de la tabla original la poblacin,
obtenindose dos tablas, una con los atributos direccin y cdigo postal y otra con el cdigo postal y la poblacin:
CPost Dir
30009 C/ Pantano Camarillas n16
48596 Av. Buenos Aires n12

CPost Pobl
30009 Murcia
48596 Madrid

El proceso de normalizacin de bases de datos
relacionales
La normalizacin de bases de datos relacionales toma un esquema relacional y le aplica un conjunto de
tcnicas para producir un nuevo esquema que representa la misma informacin pero contiene menos
redundancias y evita posibles anomalas en las inserciones, actualizaciones y borrados.
Breve recordatorio del modelo (formal) relacional
El modelo relacional de bases de datos se basa en un modelo formal especificado de acuerdo a la teora de
conjuntos. Una base de datos relacional puede considerarse como un conjunto de relaciones o tablas de la
forma R(A1, ..., An), donde R es el nombre de la relacin, que se define por una serie de
atributos Ai.
Sobre las tablas relacionales se pueden definir diferentes restricciones. La integridad de entidad es una
restriccin que nos indica que cada entidad representada por una tupla tiene que ser diferente de las dems
en su relacin, es decir, debe haber algunos atributos cuyos valores identifiquen unvocamente las tuplas. La
integridad referencial indica que una clave ajena solo debe contener valores que o bien sean nulos, o bien
existan en la relacin referenciada por la clave ajena.
El proceso de normalizacin
El proceso de normalizacin consiste en comprobar en secuencia si el esquema original est en 1FN, 2FN y
3FN, analizando las dependencias funcionales en cada paso.
Un ejemplo completo
Tenemos una empresa pblica donde los puestos de trabajo estn regulados por el Estado, de modo que las
condiciones salariales estn determinadas por el puesto. Se ha creado el siguiente esquema relacional
EMPLEADOS(nss, nombre, puesto, salario, emails) con nss como clave primaria.
nss nombre puesto salario emails
111 Juan Prez Jefe de rea 3000 juanp@ecn.es; jefe2@ecn.es
222 Jos Snchez Administrativo 1500 jsanchez@ecn.es
333 Ana Daz Administrativo 1500 adiaz@ecn.es; ana32@gmail.com
... ... ... ... ...
TABLE 1
Ads by OnlineBrowserAdvertisingAd Options
Primera forma normal (1FN)
Una tabla est en 1FN si sus atributos contienen valores atmicos. En el ejemplo, podemos ver que el
atributo emails puede contener ms de un valor, por lo que viola 1FN.
En general, tenemos una relacin R con clave primaria K. Si un atributo M viola la condicin de 1FN, tenemos
dos opciones.
Solucin 1: duplicar los registros con valores repetidos
En general, esta solucin pasa por sustituir R por una nueva relacin modificada R', en la cual:
El atributo M que violaba 1FN se elimina.
Se incluye un nuevo atributo M' que solo puede contener valores simples, de modo
que si R'[M'] es uno de los valores que tenamos en R[M], entonces R'[K] =
R[K]. En otras palabras, para una tupla con n valores duplicados en M, en la nueva
relacin habr n tuplas, que slo varan en que cada una de ellas guarda uno de los
valores que haba en M.
La clave primaria de R' es (K, M'), dado que podr haber valores
de K repetidos, para los valores multivaluados en M.
Siguiendo el ejemplo, tendramos el siguiente esquema para la nueva tabla EMPLEADOS'(a) con clave
primaria (nss, email):
nss nombre puesto salario email
111 Juan Prez Jefe de rea 3000 juanp@ecn.es
111 Juan Prez Jefe de rea 3000 jefe2@ecn.es
222 Jos Snchez Administrativo 1500 jsanchez@ecn.es
333 Ana Daz Administrativo 1500 adiaz@ecn.es
333 Ana Daz Administrativo 1500 ana32@gmail.com
... ... ... ... ...
TABLE 2
Solucin 2: separar el atributo que viola 1FN en una tabla
En general, esta solucin pasa por:
sustituir R por una nueva relacin modificada R' que no contiene el atributo M.
Crear una nueva relacin N(K, M'), es decir, una relacin con una clave ajena K referenciando R', junto
al atributo M', que es la variante mono-valuada del atributo M.
La nueva relacin N tiene como clave (K, M').
Siguiendo el ejemplo, tendramos el siguiente esquema para la nueva tabla EMPLEADOS'(b)
nss nombre puesto salario
111 Juan Prez Jefe de rea 3000
222 Jos Snchez Administrativo 1500
333 Ana Daz Administrativo 1500
... ... ... ...
TABLE 3
Y adems tendramos una nueva tabla EMAILS con clave primaria (nss, email):
nss email
111 juanp@ecn.es
111 jefe2@ecn.es
222 jsanchez@ecn.es
333 adiaz@ecn.es
333 ana32@gmail.com
... ...
TABLE 4
Segunda forma normal (2FN)
Un esquema est en 2FN si:
Est en 1FN.
Todos sus atributos que no son de la clave principal tienen dependencia funcional completa respecto de todas
las claves existentes en el esquema. En otras palabras, para determinar cada atributo no clave se necesita la
clave primaria completa, no vale con una subclave.
La 2FN se aplica a las relaciones que tienen claves primarias compuestas por dos o ms atributos. Si una
relacin est en 1FN y su clave primaria es simple (tiene un solo atributo), entonces tambin est en 2FN. Por
tanto, de las soluciones anteriores, la tabla EMPLEADOS'(b) est en 1FN (y la tabla EMAILS no tiene
atributos no clave), por lo que el esquema est en 2FN. Sin embargo, tenemos que examinar las dependencias
funcionales de los atributos no clave de EMPLEADOS'(a). Las dependencias funcionales que tenemos
son las siguientes:
nss->nombre, salario, email
puesto->salario
Como la clave es (nss, email), las dependencias de nombre, salario y email son incompletas, por lo
que la relacin no est en 2FN.
En general, tendremos que observar los atributos no clave que dependan de parte de la clave.
Para solucionar este problema, tenemos que hacer lo siguiente para los gupos de atributos con dependencia
incompleta M:
Eliminar de R el atributo M.
Crear una nueva relacin N con el atributo M y la parte de la clave primaria K de la que depende, que
llamaremos K'.
La clave primaria de la nueva relacin ser K'.
Siguiendo el ejemplo anterior, crearamos una nueva relacin con los atributos que tienen dependencia
incompleta:
nss nombre puesto salario
111 Juan Prez Jefe de rea 3000
222 Jos Snchez Administrativo 1500
333 Ana Daz Administrativo 1500
... ... ... ...
TABLE 5
Y al eliminar de la tabla original estos atributos nos quedara:
nss email
111 juanp@ecn.es
111 jefe2@ecn.es
222 jsanchez@ecn.es
333 adiaz@ecn.es
333 ana32@gmail.com
... ...
TABLE 6
Como vemos, la solucin a la que llegamos es la misma que en la otra opcin de solucin para el problema de
1FN.
Tercera forma normal (3FN)
Una relacin est en tercera forma normal si, y slo si:
est en 2FN
y, adems, cada atributo que no est incluido en la clave primaria no depende transitivamente de la clave
primaria.
Por lo tanto, a partir de un esquema en 2FN, tenemos que buscar dependencias funcionales entre atributos
que no estn en la clave.
En general, tenemos que buscar dependencias transitivas de la clave, es decir, secuencias de dependencias
como la siguiente: K->A y A->B, donde A y B no pertenecen a la clave. La solucin a este tipo de
dependencias est en separar en una tabla adicional N el/los atributos B, y poner como clave primaria de N el
atributo que define la transitividad A.
Siguiendo el ejemplo anterior, podemos detectar la siguiente transitividad:
nss->puesto
puesto->salario
Por lo tanto la descomposicin sera la siguiente:
nss nombre puesto
111 Juan Prez Jefe de rea
222 Jos Snchez Administrativo
333 Ana Daz Administrativo
... ... ...
TABLE 7
En la nueva tabla PUESTOS, la clave sera el puesto, que tambin queda como clave ajena referenciando la
tabla EMPLEADOS. El resto de las tablas quedan como estaban.