Autor:

Eberle

Bases de datos

Alexander

2014

Normalizacin

blog.std-io.com

aaaaa

Normalizacin 2

Normalizacin
blog.std-io.com

Contenido
Notas de autor............................................................................................................................ 3
Introduccin ............................................................................................................................... 3
Primera forma normal (1FN) ...................................................................................................... 4
Segunda forma normal (2FN) ..................................................................................................... 6
Tercera forma normal (3FN) ...................................................................................................... 7
Forma normal de Boyce-Codd.................................................................................................... 8
Cuarta forma normal (4FN) ........................................................................................................ 8
Quinta forma normal (5FN) ........................................................................................................ 9

Aaaaa

Autor: Eberle Alexander

Normalizacin - Autor: Eberle Alexander 3

Notas de autor
La idea de ste documento es centralizar las distintas entradas de mi blog relacionadas con
bases de datos, de igual forma puedes ver el ndice de entradas aqu ordenados por orden
de lectura.
Tambin quiero comentar que la idea de este pdf es resumir y compilar todo el proceso de
normalizacin de la forma ms clara y sencilla posible sin perder la esencia y el concepto
general.

Introduccin
Hoy en da, y desde hace muchos aos, nosotros usamos bases de datos para guardar
distintos tipos de datos que luego usaremos tiempo despus en un programa; podramos
decir que una base de datos es un conjunto de datos ordenados, pero estaramos en un
error, cualquiera que conozca un poco sobre este tema podra recaer en cosas como "datos
que tienen un tipo" y otra clase de falencias que descartan -obviamente- esta definicin. No
obstante lo antedicho, no vengo a detallar ni a inmiscuirme en lo profundo de la definicin
de bases de datos, por lo que tomaremos por el momento a la sealada antes (si, esa cutre
definicin) como el concepto de base de datos, por el momento.
En la dcada del 70', (como dije en entradas anteriores Winston Royce, creaba el ciclo de
desarrollo de software), el seor Edgar F. Codd publicaba un trabajo denominado "A
Relational Model of Data for Large Shared Data Banks", creando entonces el modelo
relacional que hoy en da aplica a todas las bases de datos (o debera hacerlo). No obstante,
uno suele encontrar software (de dudosa calidad) en internet como los conocidos sistemas
de foros Vbulletin, o SMF, que cuentan con serios problemas a la hora de cumplir los
criterios de normalizacin.
Codd, a la hora de disear el modelo relacional, construy una serie de criterios para poder
verificar que las tablas estuvieran correctas, estas normas de correccin le permiten al
programador poder corregir y realizar una tabla normalizada.
Originalmente, estas formas normales o criterios de normalizacin eran 3, creadas por el
mismo Codd; no obstante, tiempo despus se mejor la 3FN (3 criterio o forma normal 3)
junto con Boyce nombrando la nueva FN como FNBC (Forma Normal Boyce-Codd).

Normalizacin - Autor: Eberle Alexander 4

Luego, para finalizar la trayectoria de agregados a las FN, se agregaron la 4 forma normal y
la 5 forma normal (otros dos criterios que deben ser cumplidos para que una tabla est
normalizada), aunque generalmente- se cree que con tener los primeros 3 criterios
cumplidos, una tabla ya est razonablemente normalizada. Es importante en ciertos casos
para bases de datos muy grandes aplicar las nuevas FN.
Quiero aclarar que, en mi blog, solo pondr un resumen de lo que es el proceso de
normalizacin, no obstante invito a todos a profundizar leyendo cualquiera de los siguientes
libros:
Date, C. J. (1999). An Introduction to Database Systems
Kent, W. (1983). A Simple Guide to Five Normal Forms in Relational Database Theory

Primera forma normal (1FN)

A modo de introduccin, es conveniente sealar que si hablamos de normalizacin debes

comprender la importancia de normalizar tu base de datos. Cuando diseas un sistema X, y
diagramas la base de datos, es probable que cometas una cierta cantidad de errores
intolerables que te lleven a tener una base de datos inestable, inconsistente, y con varios
problemas.
Normalizar la base de datos es como comprar un seguro a largo plazo, con una base de datos
normalizada te aseguras que en un futuro no tendr problemas tpicos.
Considera la importancia de normalizar la base de datos al comienzo, esto es, antes de tener
datos cargados; debido a que si luego tenemos la base de datos rellena de registros, hacer
cambios puede conllevar la ardua tarea de alterar una cantidad significativa de los mismos,
por lo que llevar a un costo muy superior al que puede tener normalizar la base de datos al
inicio.

Normalizacin - Autor: Eberle Alexander 5

Para poder comprenderlo, observe la imagen del post y notar que hay niveles de
normalizacin, y cuanto ms superior sea el nivel de normalizacin de la base de datos mejor
ser la misma.
El primer nivel es el 1FN. Debes saber que cuando hablamos de normalizar la base de datos,
nos referimos a normalizar cada una de las tablas de la base de datos y todas estas reglas, o
formas normales, son para procesarlas en tablas particulares.
Una tabla est en 1FN si y solo si:
Una tabla est en Primera Forma Normal si:

Todos los atributos son atmicos. Un atributo es atmico si los elementos del
dominio son indivisibles, mnimos.

La tabla contiene una clave primaria nica.

La clave primaria no contiene atributos nulos.

Los Campos no clave deben identificarse por la clave (Dependencia Funcional)

Profundicemos el anlisis de los tems anteriores. El primer punto, los atributos son
atmicos, significa que un campo no posee varios valores -solo posee uno y solo un valor- y
que ese valor no puede ser dividido en dos campos; en otras palabras, con un ejemplo
sencillo podemos ilustrar la situacin, as decimos que un campo "Nombre y Apellido" no es
atmico ya que cuenta con dos valores tales como el nombre y el apellido, y puede ser
dividido en dos campos, uno llamado nombre y el otro llamado apellido.
El segundo punto, hace referencia a que la tabla tiene una clave primaria y sta es -clave
primaria- porque si un valor no se puede repetir y es nico, quiere decir que no habr dos
registros con el mismo valor para ese campo llamado clave primaria.
El tercer punto es bastante obvio, la clave primaria no puede contener un valor nulo, como
puede pasar en otros campos, tiene que haber un valor X.
El cuarto punto, tiene relacin con que cada campo debe estar basado en la clave primaria;
en otras palabras, supongamos que tengo una tabla usuarios y pongo de clave primaria color
de pelo, y el resto de los campos son dni, nombre, apellido, etc. esto sera completamente
errneo, ya que por el color de pelo no puedo deducir el nombre, el apellido y el dni de la
persona. En cambio, si pusiera de clave primaria DNI, esto sera correcto ya que el nombre,
el apellido y el color de pelo se pueden obtener basndose en el DNI, entonces todos los
dems campos estn identificados por esa clave primaria.

Normalizacin - Autor: Eberle Alexander 6

Esto es -a grandes rasgos- los requisitos que debe tener una tabla para considerarse estar en
1FN.
Cada forma normal tiene un objetivo, el objetivo de sta es eliminar los valores repetidos
dentro de una Base de Datos.

Segunda forma normal (2FN)

La segunda forma normal hace referencia a la dependencia funcional absoluta, sobre todo
cuando haya ms de una clave primaria. Habamos visto que para estar en 1FN era necesario
que todos los campos sean directamente dependientes de la clave primaria.
Primero, una tabla est en 2FN si y solo si la misma se encuentra en 1FN y cumple con el
siguiente requisito:
Los atributos que no forman parte de ninguna clave dependen de forma completa de la
clave principal. Es decir que no existen dependencias parciales. (Todos los atributos que no
son clave principal deben depender nicamente de la clave principal).
Esto quiere decir, que si tienes dos claves primarias, es necesario que cada campo de la tabla
que no sea clave primaria dependa de todas las claves primarias, si un campo solo depende
de una o algunas (pero no todas) las claves primarias, ese campo es errneo.
Imaginemos una tabla con los siguientes campos:
id_proyecto dni_empleado horas_trabajadas nombre_empleado
(donde dni_empleado e id_proyecto son claves primarias)
Como podrn apreciar, las horas trabajadas en el proyecto son dependientes del id del
proyecto y del dni del empleado. No podemos saber las horas trabajadas nicamente
teniendo el id_proyecto o el dni_empleado, ya que no podremos saber con uno solo de
stos cuantas horas trabaj en ese proyecto, por lo que ese campo es correcto; depende de
todas las claves primarias de la tabla y no tiene dependencias parciales. Pero veamos el
campo nombre_empleado, el mismo es errneo, ya que depende del dni_empleado pero no
tiene ninguna dependencia con id_proyecto (no tiene nada que ver el nombre de un
empleado con el id de un proyecto), de modo que ese campo no debe estar en esa tabla
para que esa tabla est en 2FN, ya que tiene dependencias parciales.

Normalizacin - Autor: Eberle Alexander 7

Tercera forma normal (3FN)

Recordemos que el proceso de normalizacin es un proceso sumamente importante que
prev problemas futuros con una base de datos cuando la misma adquiera gran cantidad de
registros. El proceso consta en verificar y disear las distintas tablas para que cumplan los
requisitos de cada uno de los niveles (hasta el nivel que queramos llegar), cuando todas las
tablas cumplen los requisitos de un nivel, se dice que la base de datos est en ese nivel.
La tercera forma normal es para muchos el final del camino, ya que a no ser que hablemos
de una gran base de datos de importancia mayor, y que pueda darse el caso que se
necesiten los dems niveles, la mayora de las bases de datos que se ven terminan sus tablas
en 3FN.
Una tabla est en 3FN si y solo si se encuentra en 2FN, y cumple con las siguientes
caractersticas:
No existe ninguna dependencia funcional transitiva entre los campos que no son clave.
Primero explicaremos qu es una dependencia funcional transitiva, recordemos que hay
campos que dependen de otros, y que en las FN anteriores los campos deban depender de
la clave primaria.
La dependencia funcional transitiva ocurre cuando un campo B depende un campo A, y un
campo C depende de un campo B, de modo que se asume que el campo C depende
transitoriamente del campo A.
A B C, B depende de A, C depende de B, entonces C depende de A.
Veamos la siguiente tabla con los siguientes campos:
fecha_nacimiento, edad, conducir
Fecha de nacimiento es la clave primaria en nuestra tabla, vemos que con la fecha de
nacimiento podemos conocer la edad, y con la edad podemos saber si alcanza la suficiente
para poder conducir; entonces podemos deducir solo con la fecha de nacimiento si puede
conducir o no, esto es una dependencia funcional transitiva.
De modo que una tabla que tenga dependencias de este tipo no est en 3FN, en cambio si la
tabla no tiene dependencias transitivas entonces est en 3FN.

Normalizacin - Autor: Eberle Alexander 8

Si un campo que no es clave primaria, y depende de otro campo que no es clave primaria;
entonces es muy probable que haya una dependencia transitiva (asumiendo que el segundo
campo que no es clave primaria s tenga una dependencia sobre una clave primaria.)

Forma normal de Boyce-Codd

La FNBC es una forma normal que se puede considerar como una extensin de la tercera
forma normal, establece un requisito extra.
Una tabla se encuentra en FNBC si y solo si se encuentra en 3FN (por lo que tambin se
encuentra en 2FN y 1FN), y cumple el siguiente requisito:
No deben existir dependencias funcionales no triviales.
Esto quiere decir que todos aquellos campos que tienen campos que dependan de ellos, son
claves primarias.
En otras palabras que la tabla no tenga campos de este tipo sin ser clave primaria, ya que de
lo contrario habra una dependencia transitiva. No obstante es necesario tener mucho
cuidado al modificar esto ya que puede -al hacer claves primarias a campos de este estilocrear un conflicto con la 2FN suponiendo que no todos los campos sean dependientes del
mismo o que con ese campo haya otros campos que no dependan de las dems claves
primarias.
sta entrada es bastante simple y corta ya que no hay mucho que agregar a la explicacin de
FNBC, es bastante sencilla y simplemente una extensin de la 3FN.

Cuarta forma normal (4FN)

La 4FN est relacionada con la dependencia multivalor, sta es aquella dependencia que
ocurre con los distintos valores que puede tener un campo y que depende de un valor de un
campo X.
Esto es, cuando un campo tiene un valor X, otro campo puede tener alguno de muchos
valores que dependan de ese valor de ese campo.
Una tabla est en 4FN si y solo si, la misma se encuentra en 3FN, adems cumple con el
siguiente requisito:

Normalizacin - Autor: Eberle Alexander 9

Para cada una de sus dependencias mltiples no funcionales, asumiendo X como el campo
de nico valor -cuyo dependiente campo es Y (de mltiples valores)-, ste campo X es clave
candidata o grupo de claves candidatas.
En otras palabras tomando la idea de dependencia funcional multivalor, aquel campo con el
valor que puede resultar en la dependencia de varios posibles de otro campo, es una clave
primaria, o grupo de claves primarias.
Cuando un campo tiene un valor X, otro campo puede tener alguno de muchos valores que
dependan de ese valor de ese campo, la tabla estara en 4FN si el campo del valor X es una
clave primaria o conjuntos de claves.
Por supuesto, esta forma normal solo ser til cuando existan dependencias funcionales
multivalor.

Quinta forma normal (5FN)

sta no es tan complicada como la 4FN, de hecho es bastante sencilla de explicar y se
establece de la siguiente manera, una tabla se encuentra en 5FN si y solo si, se encuentra en
4FN y cumple el siguiente requisito:

No existen relaciones de dependencias no triviales que no siguen los criterios de las claves.
Una tabla que se encuentra en la 4FN -se dice que est en la 5FN- si, y slo si, cada relacin
de dependencia se encuentra definida por claves candidatas.
En otras palabras, cualquier relacin de dependencia que haya en la tabla debe estar
compuesta por un campo o un grupo de campos que sean clave primaria, y el resto de los
campos no clave primaria dependan de los campos anteriores.
Por lo que no puede existir una relacin de dependencia en la que no haya una clave
primaria y sean simples campos, esto tambin est apoyado por la 3FN donde se prev el
problema de la dependencia transitiva.
Espero que hayan comprendido el desarrollo hasta ste punto, esto es, las 6 formas
normales (incluyendo la de B-C). Como sugerencia, quisiera agregar la lectura del artculo de
wikipedia de normalizacin y sobre todo en particular el tema de las reglas de Codd ya que
decid no hacer una entrada puesto que la explicacin de Wikipedia es simple y concreta.

Normalizacin - Autor: Eberle Alexander 10

Conclusin
Las formas normales son niveles de calidad (si se quiere) para las tablas, con ciertos
requisitos para que una tabla sea considerada como parte de ese nivel, cuando todas las
tablas de una db estn en un nivel se considera que la db est en ese nivel.
Se deben ir modificando las tablas para cumplir los requisitos de cada nivel y as avanzar al
nivel siguiente.
Cuando tu base de datos se encuentre en nivel 3 o incluso FNBC, en ese momento uno debe
cuestionarse la necesidad de seguir escalando niveles, y si es que corresponde, se seguirn
escalando los niveles hasta tener una base de datos en 5FN (nivel mximo alcanzable).
Estos niveles evitan que la base de datos a la larga sufra inconvenientes graves con los datos
que lleva almacenados.
Es conveniente disear una base de datos normalizada de entrada y no esperar a que la base
est llena de registros, porque luego los cambios estructurales llevarn un costo exagerado.

Confo en que el fatigado lector encuentre til la informacin, colabore en subsanar errores
y facilite las tareas con base de datos, Los espero en la siguiente entrada de mi blog:
http://std-io.com.

10