NORMALIZACIÓN

Base de Datos
¿Qué es eso?
 La normalización es el proceso de organizar los
datos de una base de datos.
 Se incluye la creación de tablas y el establecimiento de
relaciones entre ellas según reglas diseñadas tanto para
proteger los datos como para hacer que la BD sea más
flexible al eliminar la redundancia y las dependencias
incoherentes. 
 También se puede entender la normalización como
una serie de reglas que sirven para desarrollar un
esquema de BD que minimice los problemas de
lógica
Datos redundantes
 Los datos redundantes desperdician el espacio de
disco y crean problemas de mantenimiento.
 Si hay que cambiar datos que existen en más de un
lugar, se deben cambiar de la misma forma
exactamente en todas sus ubicaciones.
 Un cambio en la dirección de un cliente es mucho más
fácil de implementar si los datos sólo se almacenan en
la tabla Clientes y no en algún otro lugar de la base de
datos. 
Dependencias incoherentes
 Una dependencia incoherente es cuando colocamos
un atributo a una entidad o tabla en donde no tiene
mucha coherencia que exista.
 También se da cuando relacionamos 2 entidades o
tablas que no deberían estar relacionadas según el
planteamiento del problema.
Formas normales
 Hay algunas reglas en la normalización de una base
de datos, y a cada regla se le llama una "forma
normal".
 Si se cumple la 1era regla, se dice que la BD está en la
“1era forma normal".
 Si se cumplen las 3 primeras reglas, la BD está en la
“3era forma normal".
 Son posibles otros niveles de normalización.
 Pero la 3era forma normal o hasta la 4ta se considera el
máximo nivel necesario para la mayor parte de las
aplicaciones. 
Formas normales
 Digamos que queremos crear una tabla con la
información de usuarios, y los datos a guardar son
el nombre, la empresa, la dirección de la empresa y
algún e-mail, o bien URL si las tienen.
 En principio comenzaríamos definiendo la
estructura de una tabla como esta:
Formas normales
 La tabla anterior se dice que está en forma normal
CERO, porque no se le ha aplicado ninguna regla.
 ¿Y que problema hay si se queda así?
 ¿Qué haremos cuando en nuestra aplicación necesitemos
una tercera url ?
 ¿Quieres tener que añadir otro campo/columna a tu tabla
y tener que reprogramar toda la entrada de datos de tu
código?
 Como respuestas a estas preguntas se tiene la 1era
forma normal (1FN)
1era forma normal (1FN)
 Cada renglón columna contiene valores atómicos
 Pasos.
 Eliminar los grupos repetitivos de la tablas
individuales.
 Crear una tabla separada por cada grupo de datos
relacionados.
 Identificar cada grupo de datos relacionados con una
clave primaria (Primary Key - PK).
1era forma normal (1FN)
 Volviendo a nuestro caso.
 ¿Ves que estamos rompiendo la primera regla cuando
repetimos los campos url1 y url2 ?
 ¿Y que pasa con la tercera regla, la clave primaria ?
 Aplicando los pasos anteriores, nos queda una tabla
así:
1era forma normal (1FN)
 Hemos solucionado el problema de la limitación del
campo url.
 Sin embargo vemos otros problemas...
 Cada vez que introducimos un nuevo registro en la
tabla usuarios, tenemos que duplicar el nombre de la
empresa y del usuario.
 No sólo nuestra BD crecerá muchísimo, sino que será
muy fácil que la BD se corrompa si escribimos mal
alguno de los datos redundantes
 Esto se soluciona llevando esta tabla a la 2da forma
normal (2FN)
2da forma normal (2FN)
 Pasos
 Crear tablas separadas para aquellos grupos de datos
que se aplican a varios registros.
 Relacionar estas tablas mediante una clave externa
(Foreing Key - FK).
 2da forma normal (2FN)
 Volviendo al ejemplo:
 Hemos separado el
campo url en otra tabla,
de forma que podemos
añadir más en el futuro
si tener que duplicar los
demás datos.
 También vamos a usar
nuestra clave primaria
para relacionar estos
campos:
2da forma normal (2FN)
 OK, esto ya se ve mejor, pero…
 ¿Pero que ocurre cuando queremos añadir otro
empleado a la empresa ABC ?
 ¿ o 200 empleados ?
 Ahora tenemos el nombre de la empresa y su
dirección duplicándose.
 Es otra situación que puede inducirnos a introducir
errores en nuestros datos.
 Para esto viene la 3era forma normal (3FN)
3era forma normal (3FN)
 Pasos
 Eliminar aquellos campos que no dependan de la
clave.
 En nuestro ejemplo.
 El nombre de empresa y su dirección no tienen nada
que ver con el campo userId.
 Así que debe tener su propio empresaId.
3era forma normal (3FN)
3era forma normal (3FN)
 Echemos un vistazo a nuestro campo urls ¿Hay
duplicación de datos?
 Esto es perfectamente aceptable si la entrada de datos de
este campo es solicitada al usuario en nuestra aplicación
para que teclee libremente su url.
 Por lo tanto es sólo una coincidencia que Joe y Jill teclearon
la misma url.
 ¿Pero que pasa si en lugar de entrada libre de texto
usáramos un menú desplegable con 20 o incluso más
urls predefinidas ?
 Entonces tendríamos que llevar nuestro diseño de BD a la
4ta forma normal (4FN).
4ta forma normal (4FN).
 Pasos
 En las relaciones varios-con-varios, entidades
independientes no pueden ser almacenadas en la
misma tabla.
 En nuestro ejemplo
 Vamos a cambiar la estructura para permitir que varios
usuarios estén relacionados con varias urls y así
tendremos una relación muchos a muchos.
4ta forma normal (4FN).
 Para disminuir la duplicación de los datos, hemos
creado una tabla que sólo tiene claves externas y
primarias url_relations.
 Hemos sido capaces de remover la entradas
duplicadas en la tabla urls creando la tabla
url_relations.
 Ahora podemos expresar fielmente la relación que
ambos Joe and Jill tienen entre cada uno de ellos, y
entre ambos, las urls.
4ta forma normal (4FN).
¿Qué tan lejos debe llevar la normalización

 Determinar las necesidades de simplificación

depende de nosotros.
 Si nuestra base de datos va a proveer información a un
solo usuario para un propósito simple y existen pocas
posibilidades de expansión, normalizar los datos hasta
la 3FN quizá sea algo exagerado.
 Las reglas de normalización existen como guías
para crear tablas que sean fáciles de manejar, así
como flexibles y eficientes.
 A veces puede ocurrir que normalizar los datos
hasta el nivel más alto no tenga sentido.
¿Qué tan lejos debe llevar la normalización

 ¿Se están dividiendo tablas sólo para seguir las

reglas o estas divisiones son en verdad prácticas?.
 Éstas son el tipo de cosas que nosotros como
diseñadores de la base de datos, necesitamos decidir, y
la experiencia y el sentido común nos pueden auxiliar
para tomar la decisión correcta.
 La normalización no es una ciencia exacta, más
bien subjetiva.
Mas allá de la 4ta forma normal
 Existen 5 niveles más de normalización que no se han discutido
aquí.
 Forma Normal BoyceCodd
 Quinta Forma Normal (5NF) o Forma Normal de Proyección-Unión
 Forma Normal de Proyección-Unión Fuerte.
 Forma Normal de Proyección-Unión Extra Fuerte
 Forma Normal de Clave de Dominio.
 Estas formas de normalización pueden llevar las cosas más allá
de lo que necesitamos.
 Éstas existen para hacer una base de datos realmente relacional.
 Tienen que ver principalmente con dependencias múltiples y
claves relacionales.