INTRODUCCIÓN A LAS BASES DE DATOS.

INSTRUCTOR: LEE JARED ESCOBAR.

TALLER N°3

Taller de Normalización

27 de octubre de 2021

Victoria Holguín Restrepo.

Programa: Técnico en Programación de Software.

Ficha: 2419805.

FORMAS NORMALES (1FN, 2FN, 3FN)

Las formas normales son conjuntos de criterios que utilizamos para «normalizar» (es decir,
mejorar la estructura) de las bases de datos.

Vamos a repasar las tres primeras formas normales.

Una tabla está en Primera Forma Normal si:

Todos los atributos son «atómicos». Por ejemplo, en el campo teléfono no tenemos varios
teléfonos.
 INTRODUCCIÓN A LAS BASES DE DATOS.
INSTRUCTOR: LEE JARED ESCOBAR.
TALLER N°3
La tabla contiene una clave primaria única. Por ejemplo, el NIF para personas, la matrícula para
vehículos o un simple id autoincremental. Si no tiene clave, no es 1FN.

La clave primaria no contiene atributos nulos. No podemos tener filas para las que no haya clave
(por ejemplo, personas sin NIF o vehículos sin matrícula).

No debe existir variación en el número de columnas. Si algunas filas tienen 8 columnas y otras 3,
pues no estamos en 1FN.

Los campos no clave deben identificarse por la clave. Es decir, que los campos no clave dependen
funcionalmente de la clave. Esto es prácticamente lo mismo que decir que existe clave primaria.

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. Por ejemplo, si en la columna 1
tenemos el primer apellido y en la columna 2 tenemos el segundo, pues no estamos en 1FN.
Igualmente, si en la tercera fila tenemos el tercer mejor expediente y en la quinta fila el quinto, no
estamos en 1FN.

Ejemplo 1: Dominios y valores.

Suponga que un diseñador principiante desea guardar los nombres y los números telefónicos de
los clientes. Procede a definir una tabla de cliente como la que sigue:

Cliente2

ID
Nombre Apellido Teléfono
Cliente

123 Rachel Ingram 555-861-2025

456 James Wright 555-403-1659

789 Cesar Dure 555-808-9633

En este punto, el diseñador se da cuenta de que un requerimiento es guardar múltiples números

telefónicos para algunos clientes. Razona que la manera más simple de hacer esto es permitir que
el campo "Teléfono" contenga más de un valor en cualquier registro dado:

Cliente

ID
Nombre Apellido Teléfono
Cliente

123 Rachel Ingram 555-861-2025

456 James Wright 555-403-1659, 555-776-4100, 555-888-6366

 INTRODUCCIÓN A LAS BASES DE DATOS.
INSTRUCTOR: LEE JARED ESCOBAR.
TALLER N°3
789 Cesar Dure 555-808-9633

Asumiendo, sin embargo, que la columna "Teléfono" está definida en algún tipo de dominio de
número telefónico (por ejemplo, el dominio de cadenas de 12 caracteres de longitud), la
representación de arriba no está en 1FN. La 1FN (y el RDBMS) prohíbe a un campo contener más
de un valor de su dominio de columna.

Ejemplo 2: Grupos repetidos a través de columnas

El diseñador puede evitar esta restricción definiendo múltiples columnas del número telefónico:

Cliente

ID
Nombre Apellido Teléfono 1 Teléfono 2 Teléfono 3
Cliente

123 Rachel Ingram 555-861-2025

456 James Wright 555-403-1659 555-776-4100 555-888-6366

789 Cesar Dure 555-808-9633

Sin embargo, esta representación hace uso de columnas que permiten valores nulos, y por lo tanto
no se conforman con la definición de la 1FN de Date. Incluso si se contempla la posibilidad de
columnas 3 con valores nulos, el diseño no está en armonía con el espíritu de 1FN. Teléfono 1,
Teléfono 2, y Teléfono 3, comparten exactamente el mismo dominio y exactamente el mismo
significado, dividir los números de teléfono en tres encabezados es artificial y causa problemas
lógicos.

 Dificultad en hacer consultas a la tabla. Es difícil contestar preguntas tales como "¿Qué
clientes tienen el teléfono X?" y "¿Qué pares de clientes comparten un número de
teléfono?".

 La imposibilidad de hacer cumplir la unicidad los enlaces Cliente-a-Teléfono por medio del
RDBMS. Al cliente 789 se le puede dar equivocadamente un valor para el Teléfono 2 que
es exactamente igual que el valor de su Teléfono 1.

 La restricción de los números de teléfono por cliente a tres. Si viene un cliente con cuatro
números de teléfono, estamos obligados a guardar solamente tres y dejar el cuarto sin
guardar. Esto significa que el diseño de la base de datos está imponiendo restricciones al
proceso del negocio, en vez de (como idealmente debe ser el caso) al revés.

Ejemplo 3: Repetición de grupos dentro de columnas

El diseñador puede, alternativamente, conservar una sola columna de número de teléfono, pero
alterando su dominio, haciendo una cadena de suficiente longitud para acomodar múltiples
números telefónicos:

Cliente
 INTRODUCCIÓN A LAS BASES DE DATOS.
INSTRUCTOR: LEE JARED ESCOBAR.
TALLER N°3

ID
Nombre Apellido Teléfono
Cliente

123 Rachel Ingram 555-861-2025

456 James Wright 555-403-1659, 555-776-4100, 555-888-6366

789 Cesar Dure 555-808-9633

Este es defendiblemente el peor diseño de todos, y otra vez no mantiene el espíritu de la 1NF. El
encabezado "Teléfono" llega a ser semánticamente difuso, ya que ahora puede representar, o un
número de teléfono, o una lista de números de teléfono, o de hecho cualquier cosa. Una consulta
como "¿Qué pares de clientes comparten un número telefónico?" es virtualmente imposible de
formular, dada la necesidad de proveerse de listas de números telefónicos, así como números
telefónicos individuales. Con este diseño en la RDBMS, son también imposibles de definir
significativas restricciones en números telefónicos.

2FN – SEGUNDA FORMA NORMAL

Una tabla está en 2FN si además de estar en 1FN cumple que los atributos no clave depende de
TODA la4clave principal.

Por ejemplo, si tenemos una tabla con Personas, identificadas por su NIF y recogemos su empresa
y dirección de trabajo, la clave sería NIF-Empresa. Pero nos encontraremos con que una misma
persona puede trabajar en varias empresas. Y vemos que la dirección de trabajo no depende de
TODA la clave primaria, sino solo de la empresa. Por lo tanto, no estamos en 2FN.

Ejemplo:

Considera una tabla describiendo las habilidades de los empleados:

Habilidades de los empleados

Empleado Habilidad Lugar actual de trabajo

Jones Mecanografía 114 Main Street

Jones Taquigrafía 114 Main Street

 INTRODUCCIÓN A LAS BASES DE DATOS.
INSTRUCTOR: LEE JARED ESCOBAR.
TALLER N°3
Jones Tallado 114 Main Street

Bravo Limpieza ligera 73 industrial Way

Ellis Alquimia 73 industrial Way

Ellis Malabarismo 73 industrial Way

Harrison Limpieza ligera 73 industrial Way

La única clave candidata de la tabla es {Empleado, Habilidad}.

El atributo restante, Lugar actual de trabajo, es dependiente solo en parte de la clave candidata,

llamada Empleado. Por lo tanto, la tabla no está en 2NF. Observe la redundancia de la manera en
que son representadas los Lugares actuales de trabajo: nos dicen tres veces que Jones trabaja en
la 114 Main Street, y dos veces que Ellis trabaja en 73 Industrial Way. Esta redundancia hace a la
tabla vulnerable a anomalías de actualización: por ejemplo, es posible actualizar el lugar del
trabajo de Jones en sus registros "Mecanografía" y "Taquigrafía" y no actualizar su registro
"Tallado". Los datos resultantes implicarían respuestas contradictorias a la pregunta "¿Cuál es el
lugar actual de trabajo de Jones?".

Una alternativa 2NF a este diseño representaría la misma información en dos tablas:

Empleados
5
Empleado Lugar actual de trabajo

Jones 114 Main Street

Bravo 73 industrial Way

Ellis 73 industrial Way

Harrison 73 industrial Way

Habilidades de los empleados

Empleado Habilidad

Jones Mecanografía

Jones Taquigrafía

Jones Tallado

Bravo Limpieza ligera

 INTRODUCCIÓN A LAS BASES DE DATOS.
INSTRUCTOR: LEE JARED ESCOBAR.
TALLER N°3
Ellis Alquimia

Ellis Malabarismo

Harrison Limpieza ligera

Las anomalías de actualización no pueden ocurrir en estas tablas, las cuales están en 2NF.

Sin embargo, no todas las tablas 2NF están libres de anomalías de actualización. Un ejemplo de
una tabla 2NF que sufre de anomalías de actualización es:

Ganadores del torneo

Torneo Año Ganador Fecha de nacimiento del ganador

Des Moines
1998 Chip Masterson 14 de marzo de 1977
Masters

Indiana Invitational 1998 Al Fredrickson 21 de julio de 1975

Cleveland Open 1999 Bob Albertson 28 de septiembre de 1968

Des Moines
1999 Al Fredrickson 21 de julio de 1975
Masters
6
Indiana Invitational 1999 Chip Masterson 14 de marzo de 1977

Aunque el Ganador y la Fecha de nacimiento del ganador están determinadas por una clave
completa {Torneo, Año} y no son partes de ella, particularmente las
combinaciones Ganador / Fecha de nacimiento del ganador son mostradas redundantemente en
múltiples registros. Este problema es tratado por la tercera forma normal (3NF).

2NF y las claves candidatas

Una tabla para la cual no hay dependencias funcionales parciales en la clave primaria está
típicamente, pero no siempre, en 2NF. Además de la clave principal, la tabla puede contener otras
claves candidatas; es necesario establecer que ningún atributo no-principal tienen dependencias
de clave parciales en cualesquiera de estas claves candidatas.

Las múltiples claves candidatas ocurren en la siguiente tabla:

Modelos eléctricos de cepillo de dientes

Fabricante Modelo Nombre completo del modelo País del fabricante

Forte X-Prime Forte X-Prime Italia

Forte Ultrajen Forte Ultraclean Italia

 INTRODUCCIÓN A LAS BASES DE DATOS.
INSTRUCTOR: LEE JARED ESCOBAR.
TALLER N°3
Dent-o-
EZBrush Dent-o-Fresh EZBrush USA
Fresh

Kobayashi ST-60 Kobayashi ST-60 Japón

Hoch Toothmaster Hoch Toothmaster Alemania

Hoch Contender Hoch Contender Alemania

Aun si el diseñador ha especificado la clave principal como {Nombre completo del modelo}, la
tabla no está en 2NF. {Fabricante, Modelo} es también una clave candidata, y País del fabricante es
dependiente en un subconjunto apropiado de él: Fabricante.

3FN – Tercera Forma Normal

Una tabla está en 3FN si además de estar en 2FN no existe ninguna dependencia transitiva entre
los atributos que no son clave.

Vamos a explicarlo. Como dijo Bill Kent, «todo atributo no clave debe proporcionar información
sobre la7clave, sobre toda la clave y nada más que la clave… con la ayuda de Codd».

Bueno, en serio, supongamos que tenemos una tabla de ganadores de torneos de tenis. En ella
figura el nombre del torneo, el año, el nombre del ganador y su nacionalidad. La clave sería
Torneo-Año. Pues esta tabla no está en 3FN porque el atributo nacionalidad, que no es de la clave,
depende del nombre del ganador (también depende de la clave). Digamos que nacionalidad
aporta información sobre el ganador, pero no sobre la clave. Es una dependencia transitiva porque
nacionalidad depende de ganador que a su vez depende de Torneo-Año.

Ejemplo

Un ejemplo de una tabla 2NF que falla en satisfacer los requerimientos de la 3NF es:

Ganadores del torneo

Torneo Año Ganador Fecha de nacimiento del ganador

Indiana Invitacional 1998 Al Fredrickson 21 de julio de 1975

Cleveland Open 1999 Bob Albertson 28 de septiembre de 1968

 INTRODUCCIÓN A LAS BASES DE DATOS.
INSTRUCTOR: LEE JARED ESCOBAR.
TALLER N°3
Des Moines
1999 Al Fredrickson 21 de julio de 1975
Masters

Indiana Invitacional 1999 Chip Masterson 14 de marzo de 1977

Se puede observar que la tabla anterior posee datos que se pueden repetir, o sea hacer referencia
a la misma entidad por así decirlo. Así que lo correcto sería generar una tabla para ellos.

Ganadores del torneo

idTorneo Año idGanador

1 1998 2

2 1999 3

3 1999 2

1 1999 1

idTorne
Nombre
o

1 8 Indiana Invitational

2 Cleveland Open

3 Des Moines Masters

Jugadores

idJugado
Jugador Fecha de nacimiento
r

1 Chip Masterson 14 de marzo de 1977

2 Al Fredrickson 21 de julio de 1975

3 Bob Albertson 28 de septiembre de 1968

Las anomalías de actualización no pueden ocurrir en estas tablas, las cuales están en 3NF.
 INTRODUCCIÓN A LAS BASES DE DATOS.
INSTRUCTOR: LEE JARED ESCOBAR.
TALLER N°3

REFERENCIAS

9
 Barbero, M. J. (2015, 7 noviembre). Formas Normales (1FN, 2FN, 3FN y FNBC) | El Blog de
19E37. Formas Normales. Recuperado 27 de octubre de 2021, de
http://19e37.com/blog/formas-normales-1fn-2fn-3fn/
 colaboradores de Wikipedia. (2021, 7 septiembre). Primera forma normal. Wikipedia, la
enciclopedia libre. Recuperado 27 de octubre de 2021, de
https://es.wikipedia.org/wiki/Primera_forma_normal
 colaboradores de Wikipedia. (2021a, junio 11). Segunda forma normal. Wikipedia, la
enciclopedia libre. Recuperado 27 de octubre de 2021, de
https://es.wikipedia.org/wiki/Segunda_forma_normal#2NF_y_las_claves_candidatas
 colaboradores de Wikipedia. (2021b, agosto 16). Tercera forma normal. Wikipedia, la
enciclopedia libre. Recuperado 27 de octubre de 2021, de
https://es.wikipedia.org/wiki/Tercera_forma_normal#Ejemplo