Universidad Distrital Documento No.

5
“Francisco José de Caldas” GUÍA DE NORMALIZACIÓN DE LA
Proyecto BASE DE DATOS
SIBI-UD

Histórico
Versión Descripción Fecha Elaboró
0.1 Versión inicial 17/05/10 Ricardo Carmona R.

Objetivo
Exponer cada una de las formas normales hasta la número 4 (4FN) para aplicar cada una de estas
reglas a las Base de Datos integrada para el proyecto SIBI-UD.

Normalización
La normalización de bases de datos consiste en aplicar una serie de reglas a todas las tablas por
igual y así poder reducir la complejidad de las consultas, actualización, modificación a Bases de
Datos. Una estructura normalizada es mas flexible, estable y mas fácil de mantener. Las formas
normales son pensadas para tratar problemas de diseño y vulnerabilidades de inconsistencias lógicas
que comprometen la integridad de los datos de la base de datos.

Pasos para la Normalización:

Terminología empleada:
• Atributo = atributo o campo de una tabla.
• Clave = llave o código de identificación para una tabla.
• Clave Candidata = superclave mínima, la clave candidata es una agrupación de uno o varios
atributos que identifican sin ambigüedad todos los campos de una tabla.
• Clave Primaria = clave candidata elegida y el identificador único para una tabla.
• Clave Foránea = Es una limitación referencial entre dos tablas. La clave foránea identifica
una columna o grupo de columnas en una tabla (tabla hija o referendo) que se refiere a una
columna o grupo de columnas en otra tabla (tabla maestra o referenciada).
• Clave no-primaria: Una clave no-primaria es un atributo que no pertenece a ninguna clave
candidata.
• Campo no clave = Es el campo común de la tabla que no es ningún tipo de clave, es decir
que no es clave candidata, ni clave primaria, ni clave foránea, ni clave alternativa.
• Dependencia funcional: Es una conexión entre uno o mas campos de una tabla. Ejemplo: El
campo “fecha_nacimiento” es funcionalmente dependiente del campo “edad”, ya que con la
fecha de nacimiento se puede predecir la edad.
• 1FN = Significa, Primera Forma Normal, de la misma manera se aplica para 2FN, 3FN y
4FN diferenciando el numero que le antecede.

REGLAS GENERALES:

• La clave primaria de las tablas debe llamarse “id”, todas las tablas la tendrán, a excepción de
las tablas centrales de vinculación que se producen al “romper” la relación muchos a
muchos. Las claves primarias deben posicionarse en la primer columna (primer campo) de la
tabla.

• El Id de las tablas debe ser Auto-numérico.

• El nombre de las tablas debe escribirse en singular y en caso que sean mas de dos palabras
estas deben ir unidas con guión bajo.

• El nombre de las tablas y los campos deben ir en minúscula.

• Se debe mantener una buen equilibrio de cohesión y acoplamiento entre las relaciones de las
tablas, es decir, procurar de acuerdo al contexto del problema; NO mantener pocas tablas
con muchos campos y pocas relaciones pero tampoco mantener muchas tablas con pocos
campos y muchas relaciones (Si una tabla tiene mas de 10 campos debe dividirse, si muchas
tablas tienen pocos campos debe revisarse el diseño e intentar unificar conceptos).

Ejemplo de las reglas generales:

PRIMERA FORMA NORMAL (1FN):

Esta es la regla mas básica que debe satisfacer un modelo de bases de datos mediante cierto
conjunto mínimo de criterios. Se refiere a que la tabla no posea grupos de datos repetitivos.

Una tabla esta en 1FN (primera forma normal), si y solo si cumple las siguientes reglas:

Regla No. 1:
No debe existir un orden ni de filas (arriba - abajo) ni de columnas (izquierda - derecha) en las
tablas de bases de datos.

Regla No. 2:
No deben existir filas repetidas (registros) en las tablas (no debe haber dos filas con el mismo grupo
de valores).

Ejemplo de Forma Incorrecta:

ID
Nombre Apellido Teléfono
Cliente
123 Rachel Ingram 555-861-2025
123 Rachel Ingram 555-861-2025
Fernande
789 Maria 555-808-9633
z

Regla No. 3:
Cada campo de la tabla debe tener un solo valor y no múltiples valores. Esto se refiere a la
atomicidad de los campos, es decir, los campos atómicos son indivisibles, no se puede obtener
varios datos de cualquier campo.

Ejemplo de Forma Incorrecta:

ID Cliente Nombre Apellido Teléfono
123 Rachel Ingram 555-861-2025
555-403-1659
456 James Wright
555-776-4100
789 Maria Fernandez 555-808-9633

¿Por que esta Incorrecta?: Esta tabla esta mal diseñada ya que en el campo teléfono del cliente
James Wright tiene dos números telefónicos dentro de un mismo dominio de columna y no uno solo
como debería ser.
Regla No. 4:
Los campos no deben contener atributos nulos y mucho menos las las claves primarias. Además las
tablas no deben contener columnas repetidas (campos repetidos) con un mismo significado.

Ejemplo de Forma Incorrecta:

ID Cliente Nombre Apellido Teléfono 1 Teléfono 2 Teléfono 3
123 Jose Alfredo Ingram 555-861-2025
456 Alex Wright 555-403-1659 555-776-4100
789 Martin Fernandez 555-808-9633
¿Por que esta Incorrecta?: Esta tabla esta mal diseñada porque algunos campos permiten valores
nulos. Hay que tener en cuenta que teléfono 1, teléfono 2, teléfono 3 comparten el mismo
significado y esto causa problemas en consultas y del ingreso de mas de 3 números de teléfono, por
lo tanto solo debe ser posible generar columnas con significados diferentes en una tabla.

EJEMPLO SOLUCIÓN BASADO EN LA 1FN:

Para solucionar un problema como el anterior, que existen varias columnas con el mismo
significado se debe “romper” la tabla en dos así:

Tabla Cliente
ID Cliente Nombre Apellido
123 Rachel Ingram
456 James Wright
789 Maria Fernandez

Tabla Teléfono del cliente

ID Cliente Teléfono
123 555-861-2025
456 555-403-1659
456 555-776-4100
789 555-808-9633

De esta manera el diseño es acorde a la forma normal y soluciona los problemas presentados.

SEGUNDA FORMA NORMAL (2FN):

Esta forma normal debe cumplir en primera instancia la 1FN. La 2FN se refiere a que NO existan
dependencias parciales entre los campos de una tabla, es decir, que los campos que no son
claves, dependan de toda la clave candidata en vez de solo una parte de ella, evitando así la
redundancia.

Una tabla esta en 2FN (segunda forma normal), si y solo si cumple las siguientes reglas:

Regla No. 1:
No debe haber redundancia entre los atributos de una columna no clave ( campo no clave) para la
mismos datos de la columna candidata (campo candidato).

Ejemplo de Forma Incorrecta:

empleado habilidad lugar_de_trabajo
Jones Mecanografía 114 Main Street
Jones Taquigrafía 114 Main Street
Jones Tallado 114 Main Street
Bravo Limpieza ligera 73 Industrial Way
Ellis Alquimia 73 Industrial Way
Ellis Malabarismo 73 Industrial Way
¿Por que esta Incorrecta?: El campo “Lugar de trabajo” es dependiente solo en parte de la clave
candidata llamada “empleado”, es decir, existe redundancia en la información del lugar de trabajo
para cada empleado. Por ejemplo, la tabla nos muestra 3 veces que el empleado Jones trabaja en
“114 Main Street”. De esta manera existen problemas de actualización; porque puede darse la
situación de que el empleado Jones se cambie de lugar de trabajo y este dato solo se actualice para
la habilidad de Mecanografía y NO para Taquigrafía y Tallado del empleado Jones, eso implicaría
que el empleado Jones tuviera dos lugares de trabajo diferentes.

EJEMPLO SOLUCIÓN BASADO EN LA 2FN:

Para solucionar un problema como el anterior, que existe redundancia y dependencia parcial entre
los campos de una tabla, se debe “romper” la tabla en dos así, nótese que la clave candidata pasa a
ser clave primaria para las dos nuevas tablas:

Tabla Empleados
Empleado Lugar actual de trabajo
Jones 114 Main Street
Bravo 73 Industrial Way
Ellis 73 Industrial Way
Harrison 73 Industrial Way

Tabla Habilidades de los empleados

Empleado Habilidad
Jones Mecanografía
Jones Taquigrafía
Jones Tallado
Bravo Limpieza ligera
Ellis Alquimia
Ellis Malabarismo
Harrison Limpieza ligera

TERCERA FORMA NORMAL (3FN):

Esta forma normal debe cumplir en primera instancia la 2FN y por consiguiente la 1FN. La 3FN se
refiere a que no puede existir ninguna dependencia funcional transitiva entre los campos que
no son clave, es decir que ningún campo no-primario de la tabla debe ser dependiente
transitivamente de una clave candidata.

Una tabla esta en 3FN (tercera forma normal), si y solo si cumple las siguientes reglas:
Regla No. 1:
No debe haber redundancia en la información luego de lograr la segunda forma normal (2FN). Los
valores de un campo no-primario NO pueden estar completamente ligados a los de otro campo no-
primario, es decir, NO debe haber dependencia funcional transitiva (dependencias ocultas).

Se dice que existe una dependencia funcional transitiva entre

dos atributos (campos) de una tabla, si:

• Uno de los dos atributos (campos) es funcionalmente

dependiente del otro, y (Z->B)
• Ninguno de los dos atributos (campos) es parte de la
clave de la tabla (atributos no-primarios).
• Si un atributo A->Z, tal que Z->B, por lo tanto A->B
presenta dependencia funcional transitiva.

Ejemplo de Forma Incorrecta:

Torneo Año Ganador Fecha de nacimiento del ganador
Indiana Invitational 1998 Al Fredrickson 21 de julio de 1975
Cleveland Open 1999 Bob Albertson 28 de septiembre de 1968
Des Moines Masters 1999 Al Fredrickson 21 de julio de 1975
Indiana Invitational 1999 Chip Masterson 14 de marzo de 1977

¿Por que esta Incorrecta?: La violación de la 3NF ocurre porque el atributo no primario Fecha de
nacimiento del ganador (atributo B) es dependiente transitivamente de Torneo (atributo A) vía el
atributo no primario Ganador (atributo Z). El hecho de que la Fecha de nacimiento del ganador es
funcionalmente dependiente en el Ganador hace la tabla vulnerable a inconsistencias lógicas, pues
no hay nada que impida a la misma persona ser mostrada con diferentes fechas de nacimiento en
diversos registros.

EJEMPLO SOLUCIÓN BASADO EN LA 3FN:

La dependencia transitiva y sus problemas asociados de redundancia de datos pueden ser
eliminados mediante una técnica similar a la que usamos para eliminar las dependencias parciales
en la 2FN: descomponiendo la dependencia en una tabla aparte, de la forma siguiente:

Tabla Ganadores del torneo

Torneo Año Ganador
Indiana Invitational 1998 Al Fredrickson
Cleveland Open 1999 Bob Albertson
Des Moines Masters 1999 Al Fredrickson
Indiana Invitational 1999 Chip Masterson
Tabla Fecha de nacimiento del jugador
Jugador Fecha de nacimiento
Chip Masterson 14 de marzo de 1977
Al Fredrickson 21 de julio de 1975
Bob Albertson 28 de septiembre de 1968

CUARTA FORMA NORMAL (4FN):

Esta forma normal debe cumplir en primera instancia la 3FN y por consiguiente la 2FN y la 1FN.
La 4FN se refiere a que NO puede existir ninguna dependencia múltiple entre los campos de
una tabla.

Una dependencia múltiple existe cuando se da el siguiente contexto para 3 campos llamados A,B y
C tal que, para cada valor de A existe un conjunto de valores de B y un conjunto de valores de C, sin
embargo el conjunto de B es independiente del conjunto de C y viceversa:

Una tabla esta en 4FN (cuarta forma normal), si y solo si cumple las siguientes reglas:

Regla No. 1:
Evitar la redundancia NO puede existir ninguna dependencia múltiple entre los campos de una
tabla.

Ejemplo de Forma Incorrecta:

Restaurante Variedad de Pizza Área de envío
Vincenzo's Pizza Corteza gruesa Springfield
Vincenzo's Pizza Corteza gruesa Shelbyville
Vincenzo's Pizza Corteza fina Springfield
Vincenzo's Pizza Corteza fina Shelbyville
Elite Pizza Corteza fina Capital City
Elite Pizza Corteza rellena Capital City
A1 Pizza Corteza gruesa Springfield
A1 Pizza Corteza gruesa Shelbyville
A1 Pizza Corteza gruesa Capital City
A1 Pizza Corteza rellena Springfield
A1 Pizza Corteza rellena Shelbyville
A1 Pizza Corteza rellena Capital City
¿Por que esta Incorrecta?: Note que debido a que la tabla tiene una clave única y ningún atributo
no-clave, no viola ninguna forma normal. Pero debido a que las variedades de pizza que un
restaurante ofrece son independientes de las áreas a las cuales el restaurante envía, hay redundancia
en la tabla: por ejemplo, nos dicen tres veces que A1 Pizza ofrece la Corteza rellena, y si A1 Pizza
comienza a producir pizzas de Corteza de queso entonces necesitaremos agregar múltiples registros,
uno para cada una de las Áreas de envío de A1 Pizza. En términos formales, esto se describe como
que Variedad de pizza está teniendo una dependencia multivalor en Restaurante.

EJEMPLO SOLUCIÓN BASADO EN LA 4FN:

La dependencia transitiva y sus problemas asociados de redundancia de datos pueden ser
eliminados mediante una técnica similar a la que usamos para eliminar las dependencias parciales
en la 2FN: descomponiendo la dependencia en una tabla aparte, de la forma siguiente:

Tabla Variedades por restaurante

Restaurante Variedad de pizza
Vincenzo's Pizza Corteza gruesa
Vincenzo's Pizza Corteza fina
Elite Pizza Corteza fina
Elite Pizza Corteza rellena
A1 Pizza Corteza gruesa
A1 Pizza Corteza rellena

Tabla Áreas de envío por restaurante

Restaurante Área de envío
Vincenzo's Pizza Springfield
Vincenzo's Pizza Shelbyville
Elite Pizza Capital City
A1 Pizza Springfield
A1 Pizza Shelbyville
A1 Pizza Capital City
Referencias

• WIKIPEDIA, la enciclopedia libre. “Normalización de bases de datos” [en línea] [Bogotá

D.C., Colombia]. 11 de mayo de 2010 [Ref. 13 de mayo de 2010]. Disponible en Internet:
http://es.wikipedia.org/wiki/Normalizaci%C3%B3n_de_bases_de_datos