El proceso de normalización de bases de datos consiste en designar y aplicar una serie de reglas a las

relaciones obtenidas tras el modelo entidad-relación.

Las bases de datos relacionales se normalizan para:

 Evitar la redundancia de los datos.

 Disminuir problemas de actualización de los datos en las tablas.

 Proteger la integridad de los datos.

Para que las tablas de nuestra BD estén normalizadas deben cumplir las siguientes reglas:

 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.

Existen 3 niveles de normalización que deben respetarse para poder decir que nuestra BDs, se
encuentra NORMALIZADA, es decir, que cumple con los requisitos naturales para funcionar
óptimamente y no perjudicar el rendimiento por mala arquitectura.

Estas 3 reglas de Normalización se les conocen como las 3 FORMAS NORMALES.

Teoría sobre normalización te puedes encontrar en cualquier libro de bases de datos, lo que es difícil
encontrar son ejemplos prácticos donde puedas entender los conceptos de las reglas de
normalización. A continuación te explico las formas normales con un ejemplo real.

Para los que me conocen, saben que en Ciudad de México que es donde me encuentro, doy clases
presenciales en un par de escuelas, una de ellas es el Instituto ICONOS, donde se tienen materias en
común para diferentes planes de estudios, por ejemplo en el área de web se tiene una materia para
enseñar bases de datos con MySQL y otra para enseñar programación backend con PHP, ambas
materias se imparten tanto en la Licenciatura en Diseño Digital, como en la Maestría en Medios
Virtuales, la diferencia entre los niveles de estudios, es el número de horas y la carga de contenidos.

Pensemos que tenemos dos alumnos que cursarán ambas materias: Juanito en maestría y Pepito en
licenciatura, nuestro modelo de datos podría quedar de la siguiente manera:

Sin Normalizar:

ALUMNOS

alumno estudio_nivel estudio_nombre materia_1 materia_2

Juanito Maestría Medios Virtuales MySQL PHP

Pepito Licenciatura Diseño Digital MySQL PHP

Como podemos ver en la tabla anterior, tenemos los registros de ambos estudiantes con ambas
materias asignadas, pero esto es poco funcional, imaginemos que cada estudiante tuviera más
materias en su horario, eso significaría, agregarle más columnas a cada alumno, lo que no es muy
óptimo.

Primera Forma Normal:

NO repetir campos en las tablas (atributos atómicos).

ALUMNOS

alumno_i alumno_nombr estudio_nive estudio_nombr materi

d e l e a

Medios
1 Juanito Maestría MySQL
Virtuales

Medios
1 Juanito Maestría PHP
Virtuales

2 Pepito Licenciatura Diseño Digital MySQL

2 Pepito Licenciatura Diseño Digital PHP

Al aplicar la primer forma normal hemos generado un identificado para cada alumno y un registro
por materia asignada, hemos duplicado información, sin embargo hemos conservado la integridad de
las columnas de la información lo que es más óptimo que el modelo anterior, sin embargo podemos
mejorarlo con la segunda forma normal.

Segunda Forma Normal:

Se debe aplicar la 1FN. Cada campo de la tabla debe depender de una clave única, si tuviéramos
alguna columna que se repite a lo largo de todos los registros, dichos datos deberían atomizarse en
una nueva tabla.

ALUMNOS

alumno_i
alumno_nombre estudio_nivel estudio_nombre
d

1 Juanito Maestría Medios Virtuales

 alumno_i
alumno_nombre estudio_nivel estudio_nombre
d

2 Pepito Licenciatura Diseño Digital

MATERIAS

materia_id alumno_id materia_nombre

1 1 MySQL

2 1 PHP

3 2 MySQL

4 2 PHP

Al aplicar la segunda forma normal, hemos evitado la duplicación de registros y hemos separado la
información de los alumnos de la relación que guardan con las materias generando una segunda
tabla, sin embargo dicha tabla puede mejorarse con la tercer forma normal o su versión mejorada la
forma de Boyce-Codd.

Tercera Forma Normal:

Se debe aplicar la 1FN y 2FN. Los campos que NO son clave NO deben tener dependencias.

Forma Normal Boyce-Codd (FNBC):

Se debe aplicar la 1FN, 2FN y 3FN. Es una versión mejorada de la 3FN. Los campos que NO son clave
NO deben tener dependencias. Los campos que NO dependan de la clave se deben eliminar.

ALUMNOS

alumno_id alumno_nombre estudio_id

1 Juanito 1
 alumno_id alumno_nombre estudio_id

2 Pepito 2

ESTUDIOS

estudio_id estudio_nivel estudio_nombre

1 Maestría Medios Virtuales

2 Licenciatura Diseño Digital

MATERIAS

materia_id alumno_id materia_nombre

1 1 MySQL

2 1 PHP

3 2 MySQL

4 2 PHP

Con la ayuda de la tercer forma y la Boyce-Codd hemos sacado la información de los planes de
estudio de la información principal de los alumnos, lo que asegura una mejor integridad de los datos,
permitiendo que el número de estudios crezcan y que los estudiante puedan matricularse a más de
un estudio sin tener que desordenar el modelo de datos.

Cuarta Forma Normal:

Se debe aplicar la FNBC. La 4FN aplica únicamente para relaciones M a M, y nos ayuda a eliminar la
redundancia de información generada por dicho tipo de relación.
ALUMNOS

alumno_id alumno_nombre estudio_id

1 Juanito 1

2 Pepito 2

ESTUDIOS

estudio_id estudio_nivel estudio_nombre

1 Maestría Medios Virtuales

2 Licenciatura Diseño Digital

MATERIAS

materia_id materia_nombre

1 MySQL

2 PHP

MATERIAS X ALUMNO

alumno_i
mxa_id materia_id
d

1 1 1
 alumno_i
mxa_id materia_id
d

2 1 2

3 2 1

4 2 2

Con la cuarta forma hemos logrado separar la relación que guardan los alumnos con sus respectivas
materias asignadas, separándolas en un catálogo independiente de materias, y guardando la relación
entre alumnos y materias en otra tabla pivote que sólo guarde la relación entre ambas entidades con
un registro único.

Quinta Forma Normal:

Se debe aplicar la 1FN, 2FN, 3FN y 4FN. Existe otro nivel de normalización que se aplica con poca
frecuencia y en la mayoría de los casos no es necesario, para obtener la mejor funcionalidad de
nuestra estructura de datos. Su principio sugiere:

 La tabla original debe ser reconstruida desde las tablas resultantes en las cuales ha sido
partida.

 Los beneficios de aplicar la 5FN asegura que no se haya creado ninguna columna extraña en
las tablas y que su estructura sea del tamaño justo que tiene que ser.

 Es una buena práctica aplicar la 5FN, cuando tenemos una extensa y compleja estructura de
datos, en modelos pequeños no se recomienda usar.

En síntesis la quinta forma, nos dice que en modelos muy grandes donde tenemos muchas relaciones
y entidades, nos sugiere que una vez que hayamos terminado la normalización de nuestro modelo, lo
revisemos una vez más en busca de posibles errores de lógica en la normalización, para efectos de
nuestro ejemplo que es un modelo sencillo no aplicaremos la quinta forma normal.

FORMA NORMAL DE BOYCE-CODD (FNBC)

Edgar Frank Codd a finales definió las bases del modelo relacional a finales de los 60. Trabajaba para
IBM empresa que tardó un poco en implementar sus bases. Pocos años después el modelo se
empezó a implementar cada vez más, hasta ser el modelo de bases de datos más popular. En las
bases de Codd se definían los objetivos de este modelo:

Independencia física. La forma de almacenar los datos, no debe influir en su manipulación lógica

Independencia lógica. Las aplicaciones que utilizan la base de datos no deben ser modificadas por
que se modifiquen elementos de la base de datos.
Flexibilidad. La base de datos ofrece fácilmente distintas vistas en función de los usuarios y
aplicaciones.

Uniformidad. Las estructuras lógicas siempre tienen una única forma conceptual (las tablas)

Sencillez.

La Forma Normal Boyce-Codd (Denominada por sus siglas en ingles como BCNF or FNBC) es una
forma normal utilizada en la normalización de bases de datos. Es una adaptación vagamente más
segura de lo establecido en la Tercera Forma Normal (3FN).

Es una etapa en que se deben agrupar los datos por afinidad, formando tablas las cuales se
relacionan entre si mediante campos comunes; una tabla se considera en esta forma si y sólo sí cada
determinante o atributo es una llave candidata.

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 base de datos un atributo determinante
es un atributo del que depende funcionalmente de manera completa algún otro atributo. Todo
determinante es una clave candidata.

Como una tabla está en Forma Normal de Boyce-Codd si solo existen dependencias funcionales
elementales que dependan de la clave primaria o de cualquier clave alternativa. Si la clave primaria
está formada por un solo atributo y está en 3FN, ésta a su vez está en FNBC. Cómo 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 ). 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á 3FN y los únicos
determinantes son claves candidata

La 2FN y la 3FN eliminan las dependencias parciales y las dependencias transitivas de la clave
primaria. Pero este tipo de dependencias todavía pueden existir sobre otras claves candidatas, si
éstas existen. La BCFN es más fuerte que la 3FN, por lo tanto, toda relación en BCFN está en 3FN.

La violación de la BCFN es poco frecuente ya que se da bajo ciertas condiciones que raramente se
presentan. Se debe comprobar si una relación viola la BCFN si tiene dos o más claves candidatas
compuestas que tienen al menos un atributo en común.

Gráficamente podemos representar la forma normal de Boyce Codd de la siguiente forma:

Un ejemplo típico para mostrar una tabla que, estando en 3FN, mantiene dependencias funcionales,
puede ser una tabla que posee los atributos Dirección, Código Postal y Ciudad, deduciendo que a
Ciudades diferentes le corresponden códigos postales distintos.

Tabla en tercera forma normal

 CPost Dir Ciud

3000 C/ Las Flores N°17 Merida

4858 Av. Bolívar este Nº72 Maracay

En este caso hay dependencia entre el Código Postal y la Ciudad, ya que, conocido el Código Postal se
puede conocer la Ciudad, y conocida la Dirección y la Ciudad, se conoce el Código Postal.

Para transformar la tabla en una tabla en FNBC se crea una tabla de Códigos Postales y Ciudades,
eliminando de la tabla original la Ciudad, obteniéndose dos tablas, una con los atributos Dirección y
Código Postal y otra con el Código Postal y la Ciudad

Tabla en forma normal de Boyce-Codd

CPost Dir

3000 C/ Las Flores N°17

4858 Av. Bolívar este Nº72

Tabla en forma normal de Boyce-Codd

CPost Ciud

3000 Merida

4858 Maracay

En la mayoría de los casos, las relaciones en 3FN estarán en FNBC. Para Validar esto se deben ubicar
todos los determinantes existentes en la relación así como todas las claves candidatas, se comparan
ambos conjuntos y si encuentra que hay algún determinante que no resulta ser clave candidata se
demuestra que no esta en FNBC. Se comprueba que la relación está en 1FN, todos los atributos son
atómicos. También está en 2FN ya que no hay dependencias funcionalmente completas entre
atributos que no sean clave (formen parte de la clave). Y finalmente se verifica que no hay ningún
atributo que dependa de forma transitiva de la clave Primaria, luego está en 3FN. Usualmente se
considera aceptable tener relaciones que lleguen sólo hasta la FNBC.

La definición de la 3FN no produce diseños satisfactorios cuando se dan las siguientes condiciones, o
lo que es lo mismo, cuando una relación NO ESTE EN FNBC concurrirán las siguientes circunstancias:

 Existen varias claves candidatas.

 Las claves candidatas son compuestas.

 Las claves candidatas se encubren, tienen al menos un atributo en común.

No hay un teorema sobre la división de la relación, el motivo es que no se puede asegurar que al
descomponer una relación en dos para conseguir la FNBC el significado de las relaciones obtenidas
se corresponda semánticamente a lo que representa la relación inicial. En otras palabras, se puede
tomar una decisión equivocada al descomponer ya que puede que perdamos parte de la semántica
de la relación anterior.