Fundamentos de normalizacion

Material recopilado con fines didácticos por: Ing. Esp. Vincenzo Quagliano 1
Fundamentos de la normalización
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
base de datos sea más flexible al eliminar la redundancia y las dependencias
incoherentes.
La normalización es un proceso que consiste en aplicar una serie de reglas
que nos permitirán organizar nuestra base de datos evitando la redundancia,
garantizando la integridad de nuestra información. Para avanzar en el proceso de
la normalización, debemos ir dividiendo nuestras tablas en dos o más (sin perder
la relación entre ellas).
Tener nuestra base de datos correctamente relacionada y normalizada nos
evitará redundancia de datos (en términos prácticos, datos repetidos) y nos
ayudará a tener una base de datos más "ligera", más correcta y tiempos de
ejecución menores.
Las bases de datos se normalizan para:
• Evitar la redundancia de datos.
• Proteger la integridad de los datos (integridad referencial).
• Evitar problemas de actualización de los datos en las tablas.
Objetivos de la normalización de base de datos
Al proceder a la normalización de base de datos hay que plantearse 4
metas:
1. Organizar los datos en grupos lógicos, de tal manera que cada grupo
describa una pequeña parte del todo.
2. Minimizar la cantidad de datos duplicados almacenados en una base de
datos.

3. Perfeccionar la organización de los datos de tal manera que, cuando se
necesite introducir modificaciones, el cambio sólo deba aplicarse en un
lugar.
4. Construir una base de datos a la que se pueda acceder de forma rápida
y donde sea posible manipular los datos con la máxima eficiencia y sin
comprometer su integridad.
La normalización de base de datos es especialmente importante en el
entorno del procesamiento transaccional, sobre todo en el que se lleva a cabo en
línea. Esto es debido a la agilidad con que se llevan a cabo las modificaciones de
datos que, además, suelen darse de forma aleatoria. Inserciones, eliminaciones o
actualizaciones afectan a los datos almacenados pudiendo disminuir el
rendimiento de la base de datos si ésta no se ha normalizado.
No obstante, antes de poder empezar a normalizar una base de datos es
preciso realizar un análisis de requisitos, que servirá para determinar las políticas
y procedimientos a aplicar. De esta investigación resultará un compendio de reglas
de negocio.
Consecuencias de la falta de normalización de base de datos
• Inexactitud de los sistemas de bases de datos.
• Ralentización de los procesos.
• Ineficiencia en las operaciones.
La normalización de base de datos ayuda a evitar estos efectos negativos
ya desde el diseño de nuevas bases de datos y permite también comprobar si las
existentes garantizan la integridad de datos o referencial necesaria. Lo más
recomendable es proceder a normalizar los datos antes de crear las tablas de la
base de datos, aunque siempre es preferible asegurar su integridad y, aunque ya
se cuente con las bases de datos y no sean de nueva creación, utilizar estas
técnicas para ponerlas a prueba, teniendo claros los objetivos a alcanzar en el
proceso.

Formas normales
Hay algunas reglas en la normalización de una base de datos. Cada regla
se denomina una "forma normal". Si se cumple la primera regla, se dice que la
base de datos está en la "primera forma normal". Si se cumplen las tres primeras
reglas, la base de datos se considera que está en la "tercera forma normal".
Aunque son posibles otros niveles de normalización, la tercera forma normal se
considera el máximo nivel necesario para la mayor parte de las aplicaciones.
Primera Forma Normal (1NF)
En esta etapa debemos asegurarnos de que todos nuestras campos son
únicos (atómicos) e indivisibles y eliminar todos los datos que sean repetidos o
que tengan una dependencia funcional, como por ejemplo edad y fecha de
nacimiento.
La primera forma normal significa que los datos están en un formato de
entidad, lo que significa que se han cumplido las siguientes condiciones:
• Eliminar grupos repetidos en tablas individuales.
• Crear una tabla independiente para cada conjunto de datos
relacionados.
• Identificar cada conjunto de relacionados con la clave principal.

No utilice varios campos en una sola tabla para almacenar datos similares.
En el ejemplo tenemos una tabla No Normalizada que contiene Estudiantes,
Tutor, Habitación y las Clases 1,2 y 3. Al aplicarle la primera forma normal
eliminamos los grupos repetidos quedándonos con una sola columna de clases y
repitiendo los datos del estudiante tutor y habitación y ahora no tenemos grupos
repetidos porque aplicamos la primera forma normal (1FN).
Para identificar si lo hemos hecho de manera correcta debemos considerar
los siguientes aspectos:
• Todos los atributos son atómicos. Un atributo es atómico si los
elementos del dominio son indivisibles, mínimos.
• La tabla contiene una clave primaria única.
• La clave primaria no contiene atributos nulos.
• No debe existir variación en el número de columnas.
• Los campos no clave deben identificarse por la clave (dependencia
funcional).

• Debe existir una independencia del orden tanto de las filas como de las
columnas, es decir, si los datos cambian de orden no deben cambiar sus
significados.
• Una tabla no puede tener múltiples valores en cada columna.
• Los datos son atómicos (a cada valor de X le pertenece un valor de Y e
viceversa).
Segunda Forma Normal (2NF)
En la segunda forma normal debemos eliminar la redundancia que se
pueda observar, esto lo hacemos si al revisar las dependencias funcionales
existentes notamos que un subconjunto de nuestra tabla no depende de la clave
en su totalidad (dependencia parcial de la llave). Para lograr esto debemos crear
una tabla independiente para estos valores incluyendo algún campo que nos
permita relacionarlo con la tabla original.
La segunda forma normal asegura que cada atributo describe la entidad.
Crear tablas separadas para el conjunto de valores y los registros múltiples,
estas tablas se deben relacionar con una clave externa.
Los registros no deben depender de otra cosa que la clave principal de la
tabla, incluida la clave compuesta si es necesario.
Al pasar a la segunda forma normal vamos a eliminar los datos
redundantes, y para lograrlo vamos a crear dos tablas. Una tabla se llamará
Estudiantes donde eliminaremos los datos redundantes quedándonos con los
datos únicos (Estudiante, Tutor y Habitación) y en una segunda tabla que
llamaremos Registro para el número de estudiante y las clases que llevará en el
ejemplo cada estudiante; 1606 y 2602 llevará cada uno tres clases. El contenido
de la 1FN que estaba en una tabla ha sido divido en dos tablas para eliminar los
datos redundantes e introducirlo a la Segunda Forma Normal (2FN).
Sabremos si nuestra base de datos está en la 2FN si ésta previamente
cumple con las normas de la 1FN y si sus atributos no principales dependen de

forma completa de la clave principal. Es decir que no existen dependencias
parciales.
Tercera Forma Normal (3FN)
En la tercera forma normal, debemos eliminar de las tablas los datos que no
dependan directamente de la clave de la tabla.
Los valores que no dependen de la clave principal no pertenecen a la tabla.
Los campos que no pertenecen a la clave principal colóquelos en una tabla
aparte y relacionen ambas tablas por medio de una clave externa.
Para pasar a la tercera forma normal tenemos que eliminar los campos que
NO dependen de la clave y para lograrlo dividimos la tabla Estudiantes en dos
tablas y creamos la tabla Facultad, donde trasladaremos la columna habitación
que no depende de la clave que es la columna estudiante, el nombre del tutor será
el enlace con la tabla Estudiantes aunque también podría ser la columna
estudiante.

Otras formas de normalización
La cuarta forma normal también se llama la forma normal de Boyce-Codd
(BCNF) y la quinta forma normal existe, pero rara vez se consideran en el diseño
práctico.
El no tener en cuenta estas dos reglas de normalización adicionales puede
resultar en un diseño de base de datos menos perfecto pero no debería afectar a
la funcionalidad.
La normalización de base de datos es un punto muy importante que
deberíamos de tomar muy en serio para establecer cimientos sólidos sobre los
cuales podemos construir aplicaciones robustas que en el futuro no presenten
problemas de base de datos difíciles de solucionar.
Ejemplo
Supongamos que necesitamos hacer una base de datos para una biblioteca
que llevará el control de préstamos de libros. Las operaciones mínimas serían:
• "Un usuario solicita un préstamo".
• "Un préstamo incluye uno o varios libros".
Estas frases tiene dos objetivos muy claros, el primero es identificar las
entidades y relaciones. Definimos una entidad como todo aquello que tiene vida
propia (sustantivo) y relación como la forma en que una entidad interactúa como
otros (verbos).

Entidades Relaciones
Usuarios
Libros
Préstamo
El segundo objetivo es identificar la forma en que interactúan las entidades
con las relaciones, observemos las palabras "UNO" o "VARIOS". Dos entidades
pueden participar en una relación en cualquiera de las siguientes formas:
1. Uno a uno (1:1). Cada entidad A se relaciona solo con 1 entidad B
2. Uno a varios (1:N) Cada entidad A se relaciona con Muchas entidades B
3. Varios a uno (N:1) Muchas entidades A se relacionan con 1 entidad B
4. Varios a varios. (N:N) Muchas entidades A se relacionan con Muchas
entidades B
Con esto en mente podemos identificar los elementos que nos permitirán
diferenciar un dato de otro, nuestras claves primarias.
USUARIOS -> Id_usuario
LIBROS -> ISBN
PRÉSTAMOS -> Id_prestamo
Los atributos de nuestras tablas serían para el ejemplo:
USUARIOS: id_usuario, nombre, edad, fecha de nacimiento, correo
electrónico, dirección, teléfono casa, teléfono móvil.
PRESTAMOS: id_prestamo, id_usuario, fecha, ISBN, fecha de entrega.
LIBROS: ISBN, título, materia, autor, nacionalidad_autor.
Identificar las DEPENDENCIAS es clave para normalizar. Estas
dependencias son de muchos tipos pero por el momento basta con buscar de qué
manera dependen unos atributos de otros. Por ejemplo, en USUARIOS tenemos
dos campos que tienen una DEPENDENCIA FUNCIONAL que es el tipo de
dependencia más común a identificar: edad y fecha de nacimiento. Al saber la
fecha de nacimiento podemos identificar la edad de una persona; este segundo

atributo (edad) puede ser eliminado sin que eso represente una alteración
importante ni la pérdida de información.
Primera Forma Normal (1NF)
En nuestra tabla de usuarios deberíamos.
1. Eliminar el atributo edad, pues depende directamente de fecha de
nacimiento.
2. Como puedes notar tenemos dos campos para almacenar teléfonos:
teléfono de casa y teléfono móvil. ¿Qué pasaría si después tenemos la
necesidad de almacenar un tercer teléfono, por ejemplo un fax? En lugar
de tener que modificar la tabla, deberíamos agregar entonces una tabla
más denominada "Teléfonos" en donde identificaríamos el número de
teléfono, el tipo, y el id del usuario relacionado a cada caso (relación
1:N). Nuestra tabla de usuarios se dividiría como sigue:
TABLA 'USUARIOS':
id_usuario nombre fecha_de_nacimiento correo_electronico direccion
TABLA 'TELEFONOS':
id_telefono id_usuario telefono Tipo
Nota que ahora en la tabla "Teléfonos" tienes dos tipos de clave: una
principal o maestra y una foránea que te ayudará a identificar a qué usuario
pertenece cada teléfono.
Segunda Forma Normal (2FN)
En nuestro ejemplo tenemos la tabla PRÉSTAMOS. Ya aplicada la 1FN,
nuestra tabla tendría los siguientes campos con algunos registros de ejemplo.

TABLA 'PRESTAMOS' 1NF
id_prestamo id_usuario ISBN fecha fecha_entrega
1 1 00001 2019-01-01 2019-01-15
1 1 00032 2019-01-01 2019-01-15
1 1 0005 2019-01-01 2019-01-15
2 2 00001 2019-01-18 2019-01-30
Si observamos, identificamos cada préstamo con un id único, pero éste se
repite, pues si recordamos la relación, un usuario puede solicitar 1 o varios libros
en cada préstamo (los datos solo sirven para mostrar la redundancia, no debemos
olvidar que es importante validar que esto es cierto verificando las reglas del
negocio de nuestro desarrollo en general). Si almacenamos esto en una sola tabla,
tenemos redundancia. La solución es crear tablas independientes, una con los
datos del préstamo y otra con los libros de ese préstamo:
TABLA ‘PRESTAMOS’ 2FN
id_prestamo id_usuario fecha fecha_entrega
1 1 2019-01-01 2019-01-13
2 2 2019-01-18 2019-01-30
TABLA ‘REGISTROS_PRESTAMOS’ 2FN
id_registro id_prestamo ISBN
1 1 00001
2 1 00032
3 1 0005
4 2 00001
Tercera Forma Normal (3FN)

Si la tabla contiene datos sobre un libro debemos quitar de la tabla los datos
que no correspondan directamente con el libro, por ejemplo:
La tabla LIBROS contiene los campos: ISBN, titulo, materia, autor,
nacionalidad_autor.
Aplicando 1FN y 2FN tendremos tres tablas.
TABLA ‘LIBROS’ 2FN
ISBN titulo id_materia id_autor nacionalidad_autor
TABLA ‘MATERIAS’ 2FN
id_materia nombre_materia
TABLA ‘AUTORES’ 2FN
id_autor nombre_autor
Si notas, la nacionalidad del autor no es un campo que dependa
directamente de libro, sino que es una dependencia del autor por lo que en
nuestra tercera forma normal tendríamos que mover ese campo a una nueva
tabla, aunque en este caso ya tenemos la tabla a la que corresponde:
TABLA ‘LIBROS’ 3FN
ISBN titulo id_materia id_autor
TABLA ‘AUTORES’ 3FN
id_autor nombre_autor nacionalidad
TABLA ‘MATERIAS’ 3FN
id_materia nombre_materia

Si observamos nuestra base de datos vemos que de tres tablas que
teníamos originalmente terminamos con 7:
• USUARIOS
• TELÉFONOS
• PRÉSTAMOS
• REGISTROS_PRESTAMOS
• LIBROS
• AUTORES
• MATERIAS
Y podríamos ir más lejos, si por ejemplo descomponemos el campo
‘dirección’ de la tabla USUARIOS pensando que el usuario podría tener más de
una dirección y a su vez cada dirección contendría un país (de una tabla de
países), un estado (extraído de una tabla de estados), etc. Depende mucho, desde
luego, de las necesidades de cada desarrollo.
Infografía
https://platzi.com/blog/normalizar-una-base-de-datos-y-no-morir-en-el-intento/
https://support.microsoft.com/es-ve/help/283878/description-of-the-database-
normalization-basics
http://www.marcossarmiento.com/2017/06/28/normalizacion-de-base-de-datos/
https://blog.powerdata.es/el-valor-de-la-gestion-de-datos/por-que-se-necesita-la-
normalizacion-de-base-de-datos
https://www.cs.upc.edu/~bcasas/docencia/pfc/NormalitzacioBD.pdf
https://blog.bi-geek.com/modelo-relacional-formas-normales/
https://magazine.joomla.org/es/ediciones-anteriores/noviembre-2103/item/1610-
desarrollo-de-componentes-normalizacion-de-la-base-de-datos

Fundamentos de normalizacion

Más contenido relacionado

La actualidad más candente

Similar a Fundamentos de normalizacion

Más de vinceq

Último

Fundamentos de normalizacion