E

S
C
U
E
L
A

D
E

C
I
E

Formas Normales
N
C
I
A
S

E
M
P
R Paul Leger
E
S
R http://pleger.cl
I
A
L
E
S
 Formas Normales
• Codd creo las Formas Normales (FNs) para certificar
modelos relacionales/intermedios

• En un inicio, Codd definió tres formas normales (1

FN, 2 FN y 3 FN). Luego con Boyce, definieron 3FN de
Boyce-Codd o simplemente Boyce-Codd FN

• Hay varias otras formas normales, por ejemplo 4 y 5

FN. Estás dos últimas no serán estudiadas en este
curso
 Formas Normales
• Una forma normal establece que un conjunto de restricciones
que deben ser satisfechas por el esquema de base datos

• El objetivo de las formas normales intentan definir de una

manera formal los lineamientos del buen diseño de una base
de datos

• Si una relación no cumple con las restricciones, esta relación

se descompone para cumplir con la forma normal que se
desea alcanzar
 Formas Normales 1, 2 y 3
• Existen varias FNs, donde cada uno involucra un
conjunto de restricciones que se deben cumplir.

• Generalmente estas restricciones están expresadas

en términos de dependencias funcionales

• Hasta Boyce-Codd FN, si uno tiene su esquema en FN n,

entonces su esquema también satisfacen la FN n-1, …, 1
 Formas Normales
• Para cumplir con las restricciones de FNs, es
necesario descomponer relaciones en otras
relaciones

• Sin embargo, la descomposiciones implican nuevos

“joins” con las nuevas tablas descompuesta

• Dependiendo del problema, no siempre es necesario

llegar a la mejor forma normal, pues su
descomposición afecta al rendimiento ¿Por qué?
 Beneficios de FNs
• Aunque cada formal busca un beneficio en
particular, sin embargo, en general:

– Evitar tuplas espurias

– Conservar las DFs de la descripción

 Algunos Conceptos
• Superclave es un conjunto de atributos
que definen una relación FACEBOOK

Amigo
• Clave es una superclave, donde ningún
atributo puede ser eliminado para
seguir siendo superclave E-mail
User
Name
• Clave candidatas el conjunto de claves LastName

• Clave primaria (Primary Key) es un

clave elegida arbitariamente Identifique:
Superclaves,
Claves candidata
• Atributo primo es un atributo miembro Primary Key
de una clave candidata Atributos primos en AMIGO
 Primera Formal Normal (1 FN)
Todo atributo debe ser atómico e indivisibles. Es decir, no debe
haber atributos multi-valuados y compuestos

Dpto
NombreID Un Dpto puede estar en varias bodegas
Jefe
BodegaID

Soluciones:
1- Descomponer en dos tablas (Dpto y bodega)
2- Ampliar la primary key con BodegaID
3- Si son tres bodegas como máximo, definir tres atributos
(BodegaID1,BodegaID2, BodegaID3)
 Primera Formal Normal (1 FN)

Dpto Bodega
NombreID 1 Se ubica n
Jefe
BodegaID BodegaID

SOLUCIÓN DESEADA

Debemos repetir el proceso para otras violaciones de 1 FN,

y volver a descomponer hasta que todo el esquema cumpla 1 FN
 Segunda Formal Normal (2 FN)
• Dependencia Funcional Total es una DF (X->Y) si al restar un atributo a X, X
deja de definir a Y, es decir, (X – A) ≠> Y

• 2 FN exige que la primary key debe ser una dependencia funcional total
con respecto a todos los atributos de la relación

• Obviamente toda relación, donde la primary key tiene un solo atributo,

está en 2 FN ---- ¿Por qué?
Amigo
Trabaja_en
E-mail
Rut
User
DptoID Name
horas LastName

¿Está en 2FN? ¿Está en 2FN?

 Segunda Formal Normal (2 FN)
Dpto NombreID, BodegaID ->
NombreID {Jefe, FechaCreación, Calle, Numero, Ciudad}
Jefe
FechaCreación BodegaID -> {Calle, Numero, Ciudad}
BodegaID
Calle
Numero
Ciudad

Hay un solución mejor, cierto?

Dpto
NombreID BODEGA1 BODEGA2 BODEGA3
Jefe
FechaCreación BodegaID BodegaID BodegaID
BodegaID Calle Numero Ciudad
E
S
C
U
E
L
A

D
E

C
I
E
N
C
Si está 2 FN, significa
I
A
S
que está 1 FN
E
M
P
R
E
S
R
I
A
L
E
S
 Tercera Forma Normal (3 FN)
• La 3 FN está relacionado con las dependencias
funcionales transitiva
– X -> Y, donde, Y -> Z => X -> Z

• Un esquema está 3 FN, si está en 2 FN y no

tiene dependencia transitiva
 Tercera Forma Normal (3 FN)
Dpto NombreID->
NombreID {Jefe, FechaCreación, BodegaID}
Jefe
FechaCreación BodegaID -> {Calle, Numero, Ciudad}
BodegaID
Calle Aquí hay una DF transitiva a través de BodegaID,
Numero Por lo tanto no está en 3 FN, pero
Ciudad si está en 2 FN ¿Por qué?

Dpto BODEGA NOTA: Suponga que un

NombreID
BodegaID
Dpto ahora solo puede
Jefe
FechaCreación Calle estar en una bodega
BodegaID Numero
Ciudad
E
S
C
U
E
L
A

D
E

C
I
E
N
C
Si está 3 FN, significa
I
A
S
que está 2 FN
E
M
P
R
E
S
R
I
A
L
E
S
 Resumen (1/2)
Forma Condición
Normal
1 FN Una relación no debería tener
ningún atributo no atómico
2 FN Para las relaciones en las que la
primary key contiene múltiples
atributos,
ningún atributo no primo debería
depender funcionalmente de una
parte de la primary key
3 FN Una relación no debería tener un
atributo no primo determinado
funcionalmente por otro atributo no
primos. En otras palabras, no
debería existir DF transitiva por
parte de un atributo no primo
Solución (normalización)
Formar relaciones nuevas para cada
conjunto de atributos no atómicos
Descomponer y crear una nueva
relación por cada atributo dependiente
por una parte la primary key.
Asegurarse que puede reunir (join) con
la tabla original
Crear una nueva relación con el
conjunto de atributos no primos que
determina las otras dependencias
 Resumen (2/2)
Forma Normal Violaciones

1 FN X ≠> Y, donde X es clave

Y son atributos compuestos y multi-valuados

2 FN X -> Y ^ (X - A) -> Y, donde

X es una clave candidata,
Y es un conjunto de atributos

3 FN X -> Y ^ Y -> Z, donde

X es una clave candidata
Y es un conjunto de atributos no primos
 Ejercicio (1/2)

1. Identifique claves candidatas

2. ¿Está en 2 FN? ¿No? ¿cuál DF rompe está FN?
 Ejercicio (2/2)

1. ¿Está en 3 FN? ¿No? ¿cuál DF rompe está FN?

 Forma FN BC
Esta FN es 3 FN con la restricción que un atributo no primo defina un atributo primo.
En imágenes, lo siguiente no esta permitido:

- ¿Cuál es la solución para este problema?

- ¿Qué pasaría si la relación solamente fuera R(B,C), con las mismas dependencias?