1.- ¿Por qué se debe normalizar una base de datos?

La principal ventaja de normalizar datos, aparte de la eliminación de redundancias, es el diseño de una

integridad de datos que muestra claramente cómo se relaciona información de distintas tablas entre sí. Esto
facilita la identificación de las relaciones de datos y corrige cualquier aislamiento o inconsistencia de
información que pudiese haber en la base de datos de producto.
2.- ¿Cuántas formas normales existen en base de datos y cuáles son?
Al almacenar la información en la base de datos debemos evitar las redundancias e inconsistencias de forma
que la información que obtengamos al consultarla esté libre de inconsistencias. Para evitar inconsistencias en
las bases de datos se definieron las formas normales, hay seis formas normales, aunque normalmente con
aplicar hasta la tercera es suficiente ya que por las relaciones de los datos no es necesario aplicar formas
normales superiores.
 Primera forma normal, 1FN
 Segunda forma normal, 2FN
 Tercera forma normal, 3FN
 Forma normal de Boyce-Codd, BCNF
 Cuarta forma normal, 4FN
 Quinta forma normal, 5FN

3.- ¿Cuáles son las reglas que determinan las distintas formas normales?
Para normalizar una base de datos existen principalmente 3 reglas, las cuales se deberían cumplir para evitar
redundancias e incoherencias en las dependencias. A estas reglas se les conoce como "Forma normal" que
va de la 1 a la 3 y si la base de datos cumple con cada regla se dice que está en la "primera o segunda o
tercera forma normal"
4.- ¿Cómo se normaliza una base de datos?
Para que las tablas de nuestra base de datos estén normalizadas deben cumplir las siguientes características:
 Cada tabla debe tener su nombre único.
 No puede haber dos filas iguales.
 No se permiten los duplicados.
 Todos los datos en una columna deben ser del mismo tipo.

Si tus tablas no están correctamente optimizadas o normalizadas, te pueden causar muchos problemas a largo
plazo.
Posterior a eso para poder afirmar que nuestra base de datos está normalizada deben respetarse 3 niveles de
normalización: la primera forma normal (1FN), la segunda forma normal (2FN) y la tercera forma
normal (3FN).

FORMAS NORMALES.
 Primera Forma Normal (1FN).

La primera forma normal es la primera de las reglas de normalización de bases de datos y por tanto es la más
importante, ya que si no se cumple con esta regla no se pueden cumplir con las demás.
Esta regla asegura que una tabla es una representación válida de una entidad, cumple con varias propiedades
de las tablas y no tiene grupos repetitivos. Debe cumplir con varias subreglas:

 No hay orden de arriba-a-abajo en las filas.

Es necesario que el orden en el que son dados de alta los registros no tenga ningún significado. En un registro
de empleados, no se debe asumir que el primer registro que se dio de alta en la tabla se refiere al empleado con
mayor antigüedad. Para controlar eso, será necesario colocar un campo de fecha de ingreso.

 No hay orden de izquierda-derecha en las columnas.

Haciendo el mismo razonamiento que la subregla anterior, el orden de los campos de una tabla no debe tener
ningún significado. Asumiendo una tabla con varios campos, entre ellos:
 UnApellido (de tipo texto)
 OtroApellido (de tipo texto)

No se debe, por tanto, a asumir que el campo UnApellido se trata al Apellido paterno y OtroApellido al
apellido materno. En lugar de eso se debe nombrar correctamente cada campo:
 ApellidoMaterno (o SegundoApellido)
 ApellidoPaterno (o PrimerApellido)

De esa manera no importa en qué orden se definan los campos en la tabla, el nombre del campo nos da el
significado de cada uno de ellos.
No hay filas duplicadas.
Es decir, hay unicidad de registro (cualquier registro dentro de cada tabla debe ser único, no tener dos registros
iguales), y esto se obtiene fácilmente teniendo una llave primaria en la tabla.
Cada intersección de fila-columna contiene exactamente un valor del dominio aplicable (y nada más).
Cuando se define un campo en la tabla, todos los registros tendrán valores en sus campos de los valores
esperados (por el control del tipo de datos) y dentro del dominio esperado también (por las restricciones o
CONSTRAINT configurados).
No debe haber campos que permitan nulos.
Una manera de asegurarse que la calidad de los datos es óptima es asegurándose que los campos no acepten
valores nulos. Esto se logra en la configuración de los campos, con la directiva de NOT NULL.
Esta subregla de la 1FN parecería que se contrapone con las Reglas de Codd donde especifica que la base de
datos debe poder manejar valores nulos; sin embargo, la posibilidad de que pueda manejar valores nulos no
significa que debe utilizarse.
Los campos no clave deben identificarse por la clave (Dependencia Funcional).
Cada campo dentro de la tabla debe hablar del concepto que se guarda en la tabla, y además debe depender de
todas las llaves candidatas (la llave primaria y las llaves secundarias.

En este caso, se encuentra que la tabla no

cumple con la primera forma normal ya
que el campo ClaveDePuestoDelCajero
depende del Cajero, y no de la llave
secundaria que está formada por Cajero y
FechaDeVenta. En este caso es necesario
sacar ese campo y ubicarlo en otra tabla
(probablemente en la tabla de
Empleados).

No debe contar con grupos repetitivos.

Un grupo repetitivo es un conjunto de campos que permiten guardar varios valores de un mismo tipo. Otros
ejemplos de grupos repetitivos son:
 NumeroTelefóno1, NumeroTelefono2, NumeroTeléfono3.
 Tratamiento1, Tratamiento2, Tratamiento3.
 CitaLunes, CitaMartes, CitaMiércoles, CitaDomingo.
 Medicamento1, Medicamento2, Medicamento3.

En esos casos será necesario crear una nueva tabla (con los grupos repetitivos) y crear una relación 1: n con la
tabla principal. En la tabla ejemplada en el punto anterior, existen 4 campos para los Productos vendidos. En
esta situación será necesario dividir la tabla original en dos nuevas tablas con:
TablaDeVenta
 Ticket (Número)
 Cajero (Texto)
 FechaDeVenta (Año, Mes, Día, Hora, Minuto, Segundo)
 Cliente (Texto)
 ClaveDePuestoDelCajero (Número)
TablaDeProductosVendidos
 Ticket (Número)
 Producto (Texto)
 CantidadVendidaDeProducto (Número)

Ejemplos de tablas que NO cumplen con la primera forma normal.

 Una tabla que carece de una clave primaria.
 Una vista cuya definición exige que los resultados sean retornados en un orden particular, de modo
que el orden de la fila sea un aspecto intrínseco y significativo de la vista.
 Una tabla con, por lo menos, un atributo que pueda ser nulo.
 Una tabla con un grupo repetitivo de campos.

Segunda Forma Normal (2FN).

Para que una tabla pueda cumplir con la segunda forma normal es requisito indispensable que cumpla con la
primera forma normal, y además que:
 Cualquier campo no-llave (aquellos campos que no forman parte de las llaves) dependa de toda la
clave primaria (y de las candidatas) en vez de solo de una parte de ella.
Esto significa que es necesario cualquier campo que no forme parte de una llave candidata (llámese llave
primaria o llaves secundarias). De esta manera se podrá asegurar que no hay campos que estén <fuera de
lugar> ya que cualquier campo hablara sobre todo el concepto que se quiere guardar en la tabla y no es un
campo que debe estar en otra tabla.

Ejemplo de materias cursadas en una escuela

Considerando la siguiente tabla de materias cursadas por cada alumno en una escuela se podría tener el
siguiente modelo de tabla:
 Matricula
 ClaveDeMateria
 NombreDeLaMateria
 Calificación
 NombreDelAlumno

Si asumimos que ya cumple con la 1FN y que la llave primaria es Matrícula + Clave de materia (y que no hay
otras llaves candidatas) se debe hacer un análisis de los demás campos llave para ver si dependen de toda la
llave o solo de parte de ella.
 ¿El NombreDeLaMateria depende de toda la llave primaria? Es decir, ¿es un campo que habla de la
Matrícula (del alumno) o de ClaveDeMateria (solo de la materia)? En este caso NombreDeLaMateria
depende solo de parte de la llave primaria (solo es un campo relacionado con la materia, no con la
combinación de Materia + Alumno), por tanto, este campo no cumple con la segunda forma normal.
 Calificación es un valor que está asociado al alumno (Matrícula), pero es la calificación también de
dicho alumno en una materia en particular (ClaveDeMateria), por lo que podemos concluir que este
campo si cumple con la segunda forma normal.
 NombreDelAlumno, por otro lado, solo es un campo que «habla» del alumno, no de las materias que
cursa cada alumno, ya que es un campo que depende de la Matrícula (el nombre de la persona no
cambia nunca, independientemente de la materia que curse dicho alumno), por lo que es un campo que
no cumple con la segunda forma normal. En este caso, el campo de Nombre del alumno tendrá que
estar en aquella tabla donde Matrícula sea llave primaria (es decir, en una eventual tabla de Alumnos),
lo cual tiene mucho sentido.

Encontramos por tanto que NombreDeLaMateria y NombreDelAlumno no dependen de toda la llave primaria
(y candidatas) por lo que toda la tabla no cumple con la segunda formal normal y es necesario cambiar el
modelo. En este caso el nombre de la materia tendrá que ir en la tabla del catálogo de las materias, y el nombre
del alumno iría en la tabla de los alumnos inscritos.
Tabla Alumnos:
 Matricula
 Nombre de alumno

Materias cursadas con

 Clave de Materia
 Aula

Tabla intermedia (transitiva) con

 Matricula
 Clave de Materia
 Calificación final

IMPORTANTE: Cuando una tabla de 1FN no tiene ninguna clave candidata compuesta (claves
candidatas consistiendo en más de un atributo), la tabla está automáticamente 2n 2FN.

Tercera Forma Normal (3FN).

Para que una tabla pueda cumplir con la tercera forma normal es primero necesario que la tabla cumpla con la
segunda forma normal, y además que:

“No exista ninguna dependencia funcional transitiva entre los atributos que no son clave, es decir: una
dependencia funcional X->Y en un esquema de relación R es una dependencia transitiva si hay un conjunto de
atributos Z que no es un subconjunto de alguna clave de R, donde se mantiene X->Z y Z->Y.”

Esto, en términos simples significa que hagamos una generalización de la segunda forma normal y nos
aseguremos que todo campo no-llave (cualquier campo que no forma parte de las llaves candidatas) no
dependa de otro campo que no sea de las candidatas. En la segunda forma normal se verifica todo campo no-
llave con las llaves candidatas, pero en la tercera forma normal se verifica contra todos los demás campos (los
que no forman parte de las llaves candidatas) para verificar que todo campo no-llave no esté fuera de lugar.
Si se pudiera hacer una simplificación de la 3FN, se podría decir que intenta verificar que todo campo no-llave
no dependa de otro campo no-llave (por que con la 2FN se aseguró que no depende de las llaves candidatas,
por lo que faltaba verificar contra todos los demás).

Ejemplo de materias cursadas en una escuela.

Considerando la siguiente tabla de alumnos inscritos en una escuela hagamos el análisis de la tercera forma
normal
 Matrícula
 Nombre
 Apellidos
 FechaDeNacimiento
 PaísDeNacimiento
 CiudadDeNacimiento

Si asumimos que ya cumple con la 1FN, que cumple con la 2FN y que la llave primaria es Matrícula, y solo
hay una llave secundaria que es Nombre + Apellidos (y que no hay otras llaves candidatas) se debe hacer un
análisis de campos no-llave contra los demás campos no-llave:
 La Fecha de Nacimiento depende de alumno (de las dos llaves candidatas), por lo que si cumple con
la 3FN.
 La Ciudad de nacimiento también depende del alumno y por tanto cumple con la tercera forma
normal.
 El País de nacimiento, si bien parecería que también depende del alumno (es el país donde nació el
alumno), depende realmente de la ciudad, ya que una ciudad no puede estar en dos países diferentes
(puede haber más de una ciudad con el mismo nombre, pero no es la misma) y entonces el país
depende del valor que toma la ciudad.
Encontramos por tanto País de nacimiento cumple con la 2FN (depende del alumno), pero estrictamente
hablando depende de la ciudad (o la ciudad depende del país, como se quiera ver). Por tanto, es necesario
eliminar ese campo (País) de la tabla de alumnos para evitar errores de la información (que por equivocación
un alumno tenga una combinación de País-Ciudad que no exista en el mundo real) y se eliminaría la
redundancia de la información.
FN Boyce-Codd (FNBC).

La Forma Normal de Boyce-Codd (o FNBC) es una forma normal utilizada en la normalización de bases de
datos. Es una versión ligeramente más fuerte de la Tercera forma normal (3FN). La forma normal de Boyce-
Codd requiere que no existan dependencias funcionales no triviales de los atributos que no sean un conjunto
de la clave candidata. En una tabla en 3FN, todos los atributos dependen de una clave, de la clave completa y
de ninguna otra cosa excepto de la clave (excluyendo dependencias triviales, como A → A). Se dice que una
tabla está en FNBC si y solo si está en 3FN y cada dependencia funcional no trivial tiene una clave candidata
como determinante. En términos menos formales, una tabla está en FNBC si está en 3FN y los únicos
determinantes son claves candidatas.
Ejemplo
Consideremos una empresa donde un trabajador puede trabajar en varios departamentos. En cada
departamento hay varios responsables, pero cada trabajador solo tiene asignado uno. Tendríamos una tabla con
las columnas:
 IDTrabajador, IDDepartamento, IDResponsable

La única clave candidata es IDTrabajador (que será por tanto la clave primaria).
Si añadimos la limitación de que el responsable solo puede serlo de un departamento, este detalle produce una
dependencia funcional ya que: Responsable → Departamento
Por lo tanto, hemos encontrado un determinante (IDResponsable) que sin embargo no es clave candidata. Por
ello, esta tabla no está en FNBC. En este caso la redundancia ocurre por mala selección de clave. La repetición
del par [IDDepartamento + IDResponsable] es innecesaria y evitable.
Solamente en casos raros una tabla en 3FN no satisface los requerimientos de la FNBC. Un ejemplo de tal
tabla es (teniendo en cuenta que cada estudiante puede tener más de un tutor):
El propósito de la tabla es mostrar qué tutores están asignados a qué estudiantes. Las claves candidatas de la
tabla son:
 {ID Tutor, ID Estudiante}
 {Número de seguro social del tutor, ID Estudiante}

Cuarta Forma Normal (4FN).

Regularmente los textos que hablan sobre la normalización de bases de datos se detienen en la tercera forma
porque asegura un buen nivel de calidad en el modelado. Sin embargo, existen más formas normales.
Al igual que las otras formas, la cuarta forma normal tiene como requisito el cumplir con su predecesor (la
3FN); si se cumple dicha condición, entonces se tienen que eliminar todas las relaciones muchos a muchos del
modelo de datos para cumplir con la cuarta forma.
Las relaciones muchos a muchos provocan redundancia, y esto es lo que se quiere eliminar con la 4FN.
Modelo que no cumple con la cuarta forma normal.
Consideremos una tabla de rutas de distribución de farmacias:
 ClaveFarmacia (Llave foránea de la clave de la farmacia)
 ClaveLineaProductos (Llave foránea de la clave de la línea de producto que se vende)
 ClaveZonaDistribucion (Llave foránea de la clave de la zona donde se distribuye la línea de producto
en determinada farmacia).

Existen, obviamente, la tabla correspondiente a los datos generales de Farmacias, de Línea de productos y de
Zonas de distribución, siendo la tabla mencionada solamente la tabla que «une» a todas ellas para determinar
qué líneas de productos se venden en las farmacias y a qué zonas distribuye cada una de ellas.
Si bien el modelo cumple con la tercera forma normal (y por consiguiente con la segunda y por tanto con la
primera) este modelo tiene una tabla que guarda varias relaciones muchos a muchos que podría tener algunas
situaciones indeseables:
 Si la farmacia distribuye todas sus líneas de producto a sus Zonas de distribución, cada vez que se
añada una nueva Línea se tendrán que generar varios registros (uno por cada Farmacia-Zona);
 Por otro lado, si se añade una nueva farmacia a la red, entonces hay que añadir un registro para cada
línea que se venda y cada zona donde se distribuye cada zona.

Mejora del modelo cumpliendo con la 4FN

Si tratamos de eliminar la tabla que «une» las tres tablas (Farmacias, Líneas y Zonas) se podría lograr por
medio de dos tablas:
Tabla de Zonas de distribución con los siguientes campos:
 ClaveFarmacia
 ClaveZonaDistribucion

Tabla de Líneas vendidas en cada Farmacia con:

 ClaveFarmacia
 ClaveLineaProductos

Esto facilita el que una farmacia distribuya a una nueva zona (solo se añade un registro en la primera tabla) y
si una farmacia vendiera una nueva línea entonces solo se añade un registro en la segunda tabla. No hay
redundancia y el modelo es más claro (aunque se tenga que añadir una tabla al modelo).
 Quinta Forma Normal (5FN).

Una relación se encuentra en quinta forma normal (5FN), o forma normal de Proyección-Unión, si se
encuentra en 4FN y las únicas dependencias que existen son las denominadas dependencias de Join de una
tabla con sus proyecciones, relacionándose entre sí mediante la clave primaria, o cualquier clave alternativa.
Se dice que hay dependencia de Join entre una tabla y sus proyecciones, si es posible obtener la tabla original
por medio de la unión de dichas proyecciones.
Una relación se encuentra en 5FN o forma normal de Proyección-Unión, si se encuentra en 4FN y las únicas
dependencias que existen son las denominadas dependencias de Join de una tabla con sus proyecciones,
relacionándose entre sí mediante la clave primaria, o cualquier clave alternativa.
Se dice que hay dependencia de Join entre una tabla y sus proyecciones, si es posible obtener la tabla original
por medio de la unión de dichas proyecciones.
La 5FN se emplea cuando existe mucha información redundante en una tabla, o cuando se hace inmanejable,
debido a la existencia de muchos atributos.

Ejemplo
 Persona (rut, datPers1, datPers2, datPers3, datPrev1, datPrev2, datLab1, datLab2, datLab3, datLab4)
 DatPersPer (rut, datPers1, datPers2, datPers3)
 DatPrevPer (rut, datPrev1, datPrev2)
 DatLabPer (rut, datLab1, datLab2, datLab3, datLab4)
REFERENCIAS BIBLIOGRÁFICAS.

 Date, C. J. (2021). Forma normal de Boyce-Codd - Wikipedia, la enciclopedia libre. 1999.

https://es.wikipedia.org/wiki/Forma_normal_de_Boyce-Codd
 DBA. (2021a). Cuarta forma normal o 4FN - DBA dixit. 16/04/2020. http://dbadixit.com/cuarta-
forma-normal-4fn/
 DBA. (2021b). Formas normales - DBA dixit. 01/01/2020. https://dbadixit.com/formas-normales/
 DBA. (2021c). Primera forma normal o 1FN - DBA dixit. 15/01/2020. http://dbadixit.com/primera-
forma-normal-1fn/
 DBA. (2021d). Segunda forma normal o 2FN - DBA dixit. 05/02/2020. http://dbadixit.com/segunda-
forma-normal-2fn/
 DBA. (2021e). Tercera forma normal o 3FN - DBA dixit. 12/02/2020. http://dbadixit.com/tercera-
forma-normal-3fn/
 Desconocido. (2021). Tema 2.2.5 Quinta forma normal 5FN - Base de Datos II - Instituto
Consorcio Clavijero. https://cursos.clavijero.edu.mx/cursos/070_bdII/modulo2/contenidos/
tema2.2.5.html?opc=1
 Díaz, J. (2021). Normalización de Bases de Datos | EDteam. 2018.
https://ed.team/blog/normalizacion-de-bases-de-datos
 Muñoz, A. (2021). ¿Por qué es tan importante la normalización de base de datos? 11 Noviembre
2019. https://blog.saleslayer.com/es/por-que-es-importante-la-normalizacion-de-base-de-datos
 Picodotdev. (2021). Las 6+2 formas normales de las bases de datos relacionales. 10/02/2018.
https://picodotdev.github.io/blog-bitix/2018/02/las-6-plus-2-formas-normales-de-las-bases-de-datos-
relacionales/
 Webyempresas. (2021). ¿Cómo normalizar una base de datos? - Web y Empresas. 2/Jul/2020.
https://www.webyempresas.com/como-normalizar-una-base-de-datos/#Requisitos_de_la_normalizaci
on_de_base_de_datos