M. en ISD.

Ana Luisa Estrada Guerrero

Normalización
El uso de normalización en nuestros diseños de BD nos permite garantizar que la información
que está contenida en nuestras tablas no será duplicada y principalmente permitirá la
actualización y consulta eficiente de la información que tengamos.

A continuación, vamos a utilizar la definición de Edgar Frank "Ted" Codd, quien nos dice lo
siguiente:

Primera Forma Normal (1FN)

"Se requiere que los valores sean atómicos con respecto al DBMS (sistema manejador de base
de datos o también conocido como SGBD) en los dominios en los que cada relación es definida".
Codd define un valor atómico como uno que "no puede ser descompuesto en pedazos más
pequeños por el DBMS (excepto ciertas funciones especiales)". Tomado de:
https://es.wikipedia.org/wiki/Primera_forma_normal

En otras palabras, significa que debemos garantizar que los datos que almacenamos ya no
tengan división lógica, o que sean atómicos.

Ok, mas simple… veamos un ejemplo:

Persona
NOMBRE TELEFONOS
JUAN PEREZ LÓPEZ 4426382087
JOSE MARÍA RODRÍGUEZ 4428465129; 4428461433;
PÉREZ 5552836473

La primera forma normal (1FN) lo que busca es que no suceda casos como la tabla anterior
donde para el campo nombre y teléfono tenemos múltiples valores. Entonces NO es atómico
por lo tanto debemos ver si la atomicidad tiene lógica realizarla de tal forma que debemos
contestarnos la pregunta: ¿Es posible dividirlo en campos nuevos? Para el caso del nombre, la
tarea es muy lógica y obtenemos lo siguiente:

Persona

NOMBRE1 NOMBRE2 APELLIDO1 APELLIDO2 TELEFONOS

JUAN PEREZ LÓPEZ 4426382087
4428465129; 4428461433;
JOSÉ MARÍA RODRÍGUEZ PÉREZ 5552836473
El problema llega cuando preguntamos lo mismo al teléfono, ¿Es posible dividirlo en campos
nuevos? SI, pero ¿cuántos campos? Alguien podrá decir que en teléfono 1 y teléfono 2, pero la
realidad es que NO LO SABEMOS, entonces aquí es donde debemos recurrir a nuestro
requerimiento de software para contestar la pregunta. Supongamos que nuestro requerimiento
funcional nos dice que “Deberá permitir almacenar cualquier número de teléfonos para la
persona, incluso saber cuando NO tiene teléfono”.

Entonces cuando tenemos un caso así, la solución al diseño es construir una nueva tabla donde
se suele utilizar el nombre del campo para su definición.

Persona
NOMBRE1 NOMBRE2 APELLIDO1 APELLIDO2
JUAN PEREZ LÓPEZ
JOSÉ MARÍA RODRÍGUEZ PÉREZ

Telefono
NUMERO
4426382087
4428465129
4428461433
5552836473

Pero también por regla debemos relacionar la nueva tabla con la tabla original y es entonces
cuando debemos aplicar el concepto de clave candidata para definir cuál será nuestra primary
key. La forma de establecer nuestra clave candidata es verificar para cada uno de nuestros
campos si sus valores son capaces de establecer de manera única a la tupla que define. En
nuestro caso con solo dos valores es fácil pensar que podemos usar a Juan y a José como
claves candidatas pues sus valores no se repiten, pero si yo tengo que dar de alta otra persona
con nombre Juan nuestro diseño se viene abajo.

Entonces aquí es donde tiene sentido la segunda forma normal y dice:

Segunda Forma Normal (2FN)

“Una tabla 1FN está en 2FN si y solo si, dada una clave primaria y cualquier atributo que no
sea un constituyente de la clave primaria, el atributo no clave depende de toda la clave
primaria en vez de solo de una parte de ella”. Tomado de:
https://es.wikipedia.org/wiki/Segunda_forma_normal
Como acabas de leer nos pide clave primaria definida y en nuestro ejemplo no la tenemos
definida. En pocas palabras lo que nos dice la 2FN es que para todas nuestras tablas debe
existir una PK y los demás campos deben depender de forma directa de la PK.

Eso significa que el error que dejamos en nuestro diseño aplicando la 2FN, quedaría como
sigue:

Persona
ID (PK) NOMBRE1 NOMBRE2 APELLIDO1 APELLIDO2
1 JUAN PEREZ LÓPEZ
2 JOSÉ MARÍA RODRÍGUEZ PÉREZ

Telefono
ID (PK) NUMERO ID_PERSONA (FK)
1 4426382087 1
2 4428465129 2
3 4428461433 2
4 5552836473 2

Como puedes ver, también resolvimos lo que solicita la 1FN sobre relacionar la tabla nueva con
la original.

La manera como se interpreta la PK es que si yo tengo el ID=1 para la tabla Persona, con tan
solo ese valor seré capaz de conocer su nombre completo y toda la información que pueda
obtener mediante la relaciones que existan, en éste caso sus números de teléfono.

Tercera Forma Normal (3FN)

Debe estar en 2FN y “Ningún atributo no-primario de la tabla es dependiente transitivamente
de una clave primaria”. Tomado de: https://es.wikipedia.org/wiki/Tercera_forma_normal

Claro como el agua. Es simple, solo debemos tomar en cuenta lo siguiente:

Si en un conjunto R tenemos el campo a, b y c se debe cumplir que:

a→ b
a→c

viendo al campo a como PK, hasta aquí todo es normal. El problema sucede cuando tenemos
que: b → c. Y a esto es a lo que se le llama transitividad.
Veamos un ejemplo:

Persona
ID NOMBRE1 NOMBRE2 APELLIDO1 APELLIDO2 MUNICIPIO ESTADO
1 JUAN PEREZ LÓPEZ CORREGIDORA QUERÉTARO
SAN JUAN DEL
2 JOSÉ MARÍA RODRÍGUEZ PÉREZ RÍO QUERÉTARO

De acuerdo a lo que hemos visto anteriormente, está en 1FN y 2FN. La 3FN no la cumple
porque sucede que

ID → MUNICIPIO
ID → ESTADO

Pero,

MUNICIPIO → ESTADO

Y entonces decimos que existe transitividad entre municipio y estado, ¿la solución? Es simple,
creamos otra tabla (ya see otra más). Nuestra nueva tabla debe normalizarse desde la 1FN
hasta la 3FN. Puedo tener dos opciones de solución:

a)

Municipio
ID (PK) NOMBRE ESTADO
1 CORREGIDORA QUERETARO
2 SAN JUAN DEL RÍO QUERÉTARO

La tabla anterior está en 1FN, en 2FN pero no en 3FN ¿Por qué? Porque nuevamente existe
transitividad entre el nombre del municipio y el estado. Por tanto tenemos que hacer la nueva
tabla. (Ya lo sé)

Municipio
ID (PK) NOMBRE ID_ESTADO (FK)
1 CORREGIDORA 1
2 SAN JUAN DEL RÍO 1

Estado
ID (PK) NOMBRE
1 QUERÉTARO
b)

Estado
ID NOMBRE MUNICIPIO
CORREGIDORA, SAN
1 QUERÉTARO JUAN DEL RÍO

La tabla anterio no está en 1FN y por lo tanto no podemos revisar el resto hasta no resolver
primero el error. ¿Cuál es el problema? Recuerda que debemos tener valores atómicos y el
campo de municipio no es atómico. La solución consiste en hacer una nueva tabla con el
nombre del campo que no es atómico y relacionarla con la tabla original. ¿Ya te diste cuenta a
donde nos lleva?

Municipio
ID (PK) NOMBRE ID_ESTADO (FK)
1 CORREGIDORA 1
2 SAN JUAN DEL RÍO 1

Estado
ID (PK) NOMBRE
1 QUERÉTARO

Como seguramente ya habrás notado, no importa mucho el orden con el que empieces a
normalizar tu tabla y sus campos siempre te llevará a la misma solución si aplicas las reglas de
normalización como es debido.

Notas importantes:

1FN

Podemos tener casos como el siguiente, donde podemos decir que SI CUMPLE la primera
forma normal pues no tenemos forma de definir en qué partes se dividiría el nombre del
proveedor.

Por otro lado, las fechas también son atómicas pues el dominio de datos que se utiliza es el
DATE, y por lo tanto no tendría sentido dividirlo en día, mes y año.
Proveedor
NOMBRE FECHA_ALTA
Embotellados s.a. de c.v. 12-MAYO-2020
Plásticos y más 12-MAYO-2020
Turbinas c.v. 12-MAYO-2020

2FN

Tal vez te resulte la menos necesaria de todas las reglas, pero creeme, he visto cada cosa y
por algo fue el resultado de toda una investigación hecha por Codd.

Si analizas el registro de ventas anterior, verás lo necesario y urgente que es ésta regla.

3FN

Siempre encontrarás casos en los que parece ser que hay transitividad, la respuesta te la dará
el requerimiento. Analiza el siguiente ejemplo:

Empleado
NUMERO PUESTO SALARIO
1 SECRETARIA 3,000
2 PROFESOR 3,000
3 SECRETARIA 30,000

Estoy segura que a éstas alturas ya puedes notar una transitividad inexistente, pero si tienes
dudas, la próxima vez que nos veamos lo platicamos.

GENERAL
• Cada vez que creas una tabla nueva debes normalizar desde la 1FN hasta por lo menos
la 3FN (sí, existen más formas de normalización)
• Debes asegurarte de normalizar siempre en orden (1FN, 2FN, 3FN).
 • Cada vez que una tabla la descompongas en otra u otras tablas nuevas debes de
asegurar la relación con la tabla original. Entonces en nuestro ejemplo de 3FN quedaría
así completo:

Persona
ID (PK) NOMBRE1 NOMBRE2 APELLIDO1 APELLIDO2 ID_MUNICIPIO (FK)
1 JUAN PEREZ LÓPEZ 1
2 JOSÉ MARÍA RODRÍGUEZ PÉREZ 2

Municipio
ID (PK) NOMBRE ID_ESTADO (FK)
1 CORREGIDORA 1
2 SAN JUAN DEL RÍO 1

Estado
ID (PK) NOMBRE
1 QUERÉTARO