Normalizar una base de datos relacional significa organizar sus estructuras para reducir la redundancia de datos y mejorar la integridad. Este proceso involucra dividir grandes tablas en tablas más pequeñas y definir relaciones entre ellas para almacenar los datos de manera lógica, coherente y sin duplicación. La normalización sigue las formas normales para obtener un diseño eficiente y garantizar la ausencia de anomalías al modificar los datos. Aunque la normalización mejora el modelo de datos, también puede afectar el rendimiento, por lo

1. Normalizar una base de datos relacional
Normalizar una base de datos relacional significa organizar sus estructuras (tablas, columnas y
relaciones) para reducir la redundancia de datos y mejorar la integridad de estos. Es un proceso
que involucra dividir grandes tablas en tablas más pequeñas y definir relaciones entre ellas, para
que los datos se almacenen de manera lógica, coherente y sin duplicación innecesaria.
La normalización es una técnica que se ha desarrollado para obtener estructuras de datos
eficientes, garantizando un buen diseño lógico de la base de datos. Es decir, se utiliza para mejorar
el esquema, de modo que éste satisfaga ciertas restricciones que eviten la duplicidad de datos, y
garantiza que el esquema resultante esté más próximo al modelo de la empresa, sea consistente,
con la mínima redundancia y la máxima estabilidad.
La normalización es una ayuda muy útil en el proceso de diseño de las bases de datos, pero
conviene señalar que no es una panacea. Hay que tener en cuenta que las formas normales no
son prescripciones para la creación de un modelo de datos “correcto”. Un modelo de datos podría
llegar a estar perfectamente normalizado, pero podría proporcionar las respuestas tan despacio y
de forma tan complicada que el sistema de base de datos construido sobre él resulte inoperativo.
No hay que olvidar que al descomponer una relación penalizamos las consultas, provocando una
pérdida de eficiencia en las mismas. Aunque, en general, se aconseja llevar los esquemas
relacionales al menos a 3FN, existen ciertos casos en los que, una vez realizada la descomposición,
exigencias de eficiencia muy estrictas obligan a llevar a cabo el proceso inverso, es decir, una
desnormalización, combinando las relaciones hasta dejarlas en formas normales anteriores.
Por lo tanto, hay que poner en la balanza hasta dónde conviene normalizar para que el resultado
sea un modelo de datos eficiente y efectivo, aunque no cabe duda que con las tres primeras formas
normales las probabilidades de obtener este resultado son muy altas.

2. Formas normales
Las formas normales son reglas o estándares que guían el proceso de normalización. Existen varias
formas normales, pero en la práctica, las bases de datos suelen normalizarse hasta la tercera o
cuarta forma normal. Aquí hay un resumen sencillo de las primeras tres y una mención de las
subsiguientes:
1. Primera Forma Normal (1FN)
o Asegura que cada columna de una tabla contenga valores atómicos (indivisibles).
o Unicidad de las filas o registros.
o La 1FN prohíbe la repeticion de grupos de información. La tabla no debe contener
columnas repetidas o grupos de columnas que contengan el mismo tipo de
información. Por ejemplo, en lugar de tener columnas como Clase1, Clase2, Clase3
etc., es mejor tener una tabla separada para las clases y relacionarla con la tabla
principal.
2. Segunda Forma Normal (2FN)
o Cumple con 1FN.
o Todos los atributos (columnas) no clave deben depender completamente de la clave
primaria de la tabla. Si una tabla tiene una clave compuesta (más de un atributo como
clave primaria), todos los demás atributos deben depender de toda la clave y no solo
de una parte de ella.
3. Tercera Forma Normal (3FN)
o Cumple con 2FN.
o Los atributos no clave deben depender solamente de la clave primaria y no de otros
atributos no clave. Es decir, elimina dependencias transitivas.
4. Forma Normal de Boyce-Codd (BCNF)
o Una extensión más estricta de 3FN.
o En resumen, para cualquier dependencia funcional X→Y, X debe ser una superclave.
Si X determina Y (significa que si dos filas en la tabla tienen los mismos valores para los atributos
en X, entonces también tendrán los mismos valores para los atributos en Y-, entonces X debe ser
superclave.
En la mayoria de los casos nos bastará con llegar a la 3ª FN, puesto que cumpliendo con la 3ª FN se cumple
con la forma normal BCNF.

3. Primera Forma Normal (1FN).
La Primera Forma Normal (1FN) se centra en asegurar que todas las columnas de una tabla
contengan valores atómicos.
Ejemplo: Librería
Supongamos que tenemos una tabla para almacenar información sobre los libros que una librería
tiene en stock:
ID Titulo Autores
1 Amanecer Rojo Pierce Brown
2 Guía del Autoestopista Douglas Adams, Jane Doe
3 Dune Frank Herbert
A primera vista, esta tabla podría parecer adecuada. Sin embargo, si te fijas en el campo "Autores"
de la segunda fila, verás que hay más de un autor listado, separado por una coma. Esto significa
que la columna "Autores" no tiene valores atómicos (indivisibles), lo que va en contra de 1FN.
Normalizando a 1FN
Para llevar la tabla a 1FN, podríamos dividir la columna "Autores" en registros separados. Esto
podría significar tener múltiples registros para un solo libro si tiene más de un autor.
Podría quedar así:
ID Titulo Autor
1 Amanecer Rojo Pierce Brown
2 Guía del Autoestopista Douglas Adams
3 Guía del Autoestopista Jane Doe
4 Dune Frank Herbert
Aquí, el libro "Guía del Autoestopista" aparece dos veces en la tabla, una vez para cada autor. Esto
asegura que cada celda en la columna "Autor" tenga un valor atómico, cumpliendo con 1FN.
Esto facilita la consulta, búsqueda y actualización de autores sin tener que tratar con cadenas de
texto delimitadas por comas en la columna. Es más estructurado y evita ambigüedades y
complicaciones.

4. Segunda Forma Normal (2FN).
La Segunda Forma Normal (2FN) se centra en asegurar que todas las columnas no clave en una
tabla dependan completamente de la clave primaria. Esto es especialmente relevante para tablas
con claves primarias compuestas.
Ejemplo: Estudiantes y Cursos
Imagina que estás diseñando una base de datos para una universidad. Tienes una tabla que
registra qué estudiantes están inscritos en qué cursos durante un semestre específico:
ID_Estudiante ID_Curso Nombre_Estudiante Nombre_Curso Profesor
101 CS101 Juan Programación Sr. García
102 CS101 Marta Programación Sr. García
101 MA101 Juan Matemáticas Sra. Pérez
Aquí, la clave primaria compuesta sería (IDEstudiante,IDCurso) porque un estudiante puede estar
inscrito en múltiples cursos y un curso puede tener múltiples estudiantes.
Problema: Los atributos "Nombre_Estudiante" dependen solo de "ID_Estudiante" y los atributos
"Nombre_Curso" y "Profesor" dependen solo de "ID_Curso". No dependen de la clave compuesta
completa, lo que viola la 2FN.
Normalizando a 2FN:
Para cumplir con 2FN, descompondríamos la tabla en tres:
1. Tabla Estudiantes:
o ID_Estudiante (Clave Primaria)
o Nombre_Estudiante
2. Tabla Cursos:
o ID_Curso (Clave Primaria)
o Nombre_Curso
o Profesor
3. Tabla Inscripciones:
o ID_Estudiante
o ID_Curso
o La combinación de (ID_Estudiante, ID_Curso) sería la clave primaria.
Las tablas quedan así: (todos los atributos no clave dependen de su PK, cumpliendo con la 2FN)
Estudiantes:
ID_Estudiante Nombre_Estudiante
101 Juan
102 Marta
Cursos:
ID_Curso Nombre_Curso Profesor
CS101 Programación Sr. García
MA101 Matemáticas Sra. Pérez
Inscripciones:
ID_Estudiante ID_Curso
101 CS101
102 CS101
101 MA101

5. Tercera Forma Normal (3FN).
La Tercera Forma Normal (3FN) se asegura de que los atributos no clave de una tabla dependan
solo de la clave primaria y no de otros atributos no clave. En otras palabras, se eliminan las
dependencias transitivas.
Ejemplo: Empleados y Departamentos
Imagina que tienes una tabla que registra información sobre empleados y los departamentos en los
que trabajan:
ID_Emplead
o
Nombre_Emplead
o
ID_Departament
o
Nombre_Departament
o
Ubicación_Departament
o
1 Ana D01 Ventas Piso 3
2 Carlos D02 RRHH Piso 2
3 Beatriz D01 Ventas Piso 3
Problema: Aquí, el atributo "Ubicación_Departamento" depende del atributo
"Nombre_Departamento", que a su vez depende de la clave primaria "ID_Empleado". Esta es una
dependencia transitiva porque "Ubicación_Departamento" depende indirectamente de
"ID_Empleado" a través de "Nombre_Departamento". Esto va en contra de 3FN.
Normalizando a 3FN:
Para llevar la tabla a 3FN, debemos eliminar la dependencia transitiva. Podemos hacerlo dividiendo
la tabla original en dos tablas: una para empleados y otra para departamentos.
1. Tabla Empleados:
o ID_Empleado (Clave Primaria)
o Nombre_Empleado
o ID_Departamento (Clave Foránea)
2. Tabla Departamentos:
o ID_Departamento (Clave Primaria)
o Nombre_Departamento
o Ubicación_Departamento
Las tablas quedarían así:
Empleados:
ID_Empleado Nombre_Empleado ID_Departamento
1 Ana D01
2 Carlos D02
3 Beatriz D01
Departamentos:
ID_Departamento Nombre_Departamento Ubicación_Departamento
D01 Ventas Piso 3
D02 RRHH Piso 2
Con este diseño, la ubicación del departamento ya no depende transitivamente del ID del empleado.
Ahora, todos los atributos no clave en cada tabla dependen directamente de la clave primaria,
cumpliendo con la 3FN.

6. Forma Normal (BCNF).
La Forma Normal de Boyce-Codd (BCNF) es una extensión más rigurosa de la Tercera Forma
Normal (3FN). Una tabla está en BCNF si, para cada una de sus dependencias funcionales, la parte
izquierda es una superclave. Una superclave es un conjunto de uno o más atributos que, tomados
colectivamente, permiten identificar de manera única una entidad (registro) en la tabla.
BCNF es más estricta y requiere que para cualquier dependencia funcional X→Y, X debe ser una
superclave. Es decir, no permite ninguna excepción donde un atributo no clave determine otro
atributo no clave, incluso si es parte de la clave primaria.
Ejemplo:
Imagina una tabla Profesores:
ProfesorID Asignatura Departamento Jefe_Departamento
1 Matemáticas Ciencias Dra. López
2 Biología Ciencias Dra. López
3 Historia Humanidades Dr. Pérez
Dependencias Funcionales:
1. ProfesorID→[Asignatura,Departamento,JefeDepartamento]
(Cada profesor tiene una única asignatura, departamento y jefe de departamento).
2. Departamento→JefeDepartamento
(Cada departamento tiene un único jefe).
Analizando 3FN y BCNF:
 3FN: La tabla viola 3FN porque Jefe_Departamento depende de Departamento (una columna no
clave). Para cumplir con 3FN, deberíamos dividir la tabla para eliminar esta dependencia
transitiva.
 BCNF: La tabla también viola BCNF debido a la dependencia funcional 2
(Departamento→JefeDepartamento) ya que Departamento no es una superclave.

7. Para normalizar a BCNF (que también cumpliría con 3FN), podríamos dividir la tabla en dos:
1. Profesores:
ProfesorID Asignatura Departamento
1 Matemáticas Ciencias
2 Biología Ciencias
3 Historia Humanidades
2. Departamentos:
Departamento Jefe_Departamento
Ciencias Dra. López
Humanidades Dr. Pérez
Ambas tablas ahora cumplen con 3FN y BCNF ya que todas las dependencias funcionales
cumplen con las reglas. La descomposición en 3FN y BCNF puede ser igual en muchos casos,
pero BCNF añade una capa adicional de rigor para gestionar todas las dependencias funcionales,
no solo las que involucran claves primarias.
Diferencias entre 3FN y BCNF:
 Si una tabla en 3FN tiene una dependencia funcional donde un atributo no clave determina
otro atributo no clave, pero ese determinante es parte de la clave primaria, 3FN permite
esa dependencia.
 BCNF no permite ninguna excepción: si hay una dependencia funcional X→Y, entonces X
tiene que ser una superclave, sin importar si es parte de una clave primaria o no.