Normalización

Marta Zorrilla
Universidad de Cantabria
Tabla de contenidos

Introducción

Notación

Primera forma normal

Dependencias funcionales

Segunda forma normal

Tercera forma normal

Forma normal de Boyce-Codd

Dependencias multivaluadas y 4FN

Quinta forma normal

Proceso de diseño
 Criterios de diseño

Un buen diseño de base de datos relacional requiere
encontrar un “buen” conjunto de esquemas de
relación

Objetivos de diseño principales:

 Evitar la redundancia de datos
 Asegurar que están recogidas las relaciones relevantes
entre los atributos
 Preservar las restricciones de integridad (actualizaciones)

Métodos:
 Modelos ER, UML, ORM y uso de herramientas CASE
 Síntesis: Agrupar atributos en relaciones
 Descomposición: Dividir una relación en relaciones
Ejemplo

Sea el esquema:
prestamos = (nombre_sucursal, ciudad_sucursal, activos,
nombre_cliente, numero_prestamo, cantidad)

Nombre Ciudad Nombre Nº

sucursal sucursal Activos cliente Prést. cantidad

Problemas:
 Los datos nombre_sucursal, ciudad_sucursal, activos se repiten para
cada préstamo que hace una sucursal
 La información de la sucursal no existe, si no hay préstamo (o bien
requiere nulos)
 Se malgasta espacio en disco
 Se complica el proceso de actualización de datos

Solución: descomposición sin pérdida de dependencias

 Esquemas: sucursales e info_prestamos
Descomposición sin pérdida de dependencias

Descomposición del esquema

prestamos = (nombre_sucursal,nombre_ciudad,activos,
nombre_cliente, numero_prestamo, cantidad)

sucursal = (nombre_sucursal,nombre_ciudad,activos)

info_prestamos= (nombre_cliente, numero_prestamo,

nombre_sucursal, cantidad)

Todos los atributos del esquema original (R) deben aparecer en la

descomposición (R1, R2):

R = R1 ∪ R2

Descomposición sin pérdida. Para todas las posibles relaciones r en

el esquema R

r = ∏R1 (r) ∏R2 (r)

Ejemplo de descomposición con pérdida

Decomposición de R = (V, W)

R1 = (V) R2 = (W)

V W V W

α 1 α 1
α 2 β 2
β 1 ∏W(r)
∏V(r)
r

V W
∏V (r) ∏W (r)
α 1
α 2
β 1
β 2
Ejemplo de descomposición sin pérdida

Decomposición de R = (V, W, Y)

R1 = (V,Y) R2 = (W,Y)

V W Y V Y W Y

α 1 a α a 1 a
α 2 b α b 2 b
β 1 c β c 1 c
r ∏W(r)
∏V(r)

V W Y

∏V (r) ∏W (r) α 1 a
α 2 b
β 1 c
r
Normalización

Diseño formal de bases de datos relacionales basado en el
concepto de dependencia.

Dependencias:
 son propiedades inherentes al contenido semántico de los datos;
 son un tipo especial de restricción de usuario en el modelo
relacional, que afecta únicamente a los atributos dentro de una
única relación; y
 se han de cumplir para cualquier extensión de un esquema de
relación.

Tipos: funcional, multievaluada, jerárquicas y de combinación

Formas normales: condiciones exigibles a los esquemas de

relación para evitar redundancias y contradicciones en los datos

Proceso:
 Determinar si una relación R está normalizada
 Si no, descomponer la relación en {R1, R2, ..., Rn} tal que

Cada relación esté normalizada

La descomposición se produce sin pérdida de dependencias funcionales
Formas normales
combinación 5FN

multivaluadas 4FN

fu FN Boyce - Codd
n ci
on 3FN
al
es
2FN

1FN
1FN
Definiciones y notación

Esquema de relación (o esquema de tabla):
Es una lista ordenada de nombres de atributos.

Relación (o tabla):
Es una determinación de un esquema de relación mediante
valores concretos de los atributos, es decir, una tabla de
valores.

Notación utilizada:
 1.-Las letras mayúsculas del comienzo del alfabeto
representan atributos simples.
 2.-Las letras mayúsculas del final del alfabeto representan
conjuntos de atributos (atributos compuestos), siendo posibles
conjuntos simples.
 3.-La letra R se usa para denotar un esquema de relación.
 4.-Se utiliza r para indicar una relación, es decir, el contenido
de una tabla.
 5.-La concatenación significa unión, es decir: A1A2...An es el
conjunto {A1, A2, ..., An}, X ∪ Y es lo mismo que XY y
también X ∪ A es igual que X{A}.
Primera forma normal (1NF)

Un esquema de relación, R, está en 1NF, si y
sólo si, tiene un número de atributos fijo y éstos
toman valores no compuestos (atómicos)

Un atributo es atómico si sus elementos se

consideran unidades indivisibles
 Ejemplos de valores no atómicos:

Atributos que tomen varios valores, p.e., teléfonos.

Identificadores como CS101 que pueden ser divididos en
partes.

Controversia con tipos ARRAY y SET incluidos en

SQL:2003
Primera forma normal (1NF), ej.
⊆

Definiciones

Clave:
Es todo atributo, simple o compuesto, que toma valores únicos
(no repetidos). Esto equivale a decir que, para un esquema de
relación, R, K ⊆ R es una clave si, para cualquier contenido,
r(R), de la relación, para todas las parejas t1 y t2 de tuplas de
r(R), tales que t1≠t2 entonces t1[K] ≠ t2[K].

Clave principal:
Es la clave que se utiliza para identificar cada tupla de una
relación.

Atributo de clave (Key atribute):
Es un atributo que pertenece a una clave.

Atributo no de clave (Non key attribute):
Es un atributo que ni es una clave ni forma parte de una clave.

Superclave, conjunto de atributos que contengan una clave
(key). Todas las claves son superclaves pero pueden no ser
mínimas.
 Definiciones

Dependencia funcional:
Sean V ⊆ R y W ⊆ R, se dice que W depende funcionalmente de
V en R, V → W, si en cualquier relación r(R), para todas las
parejas t1 y t2 de tuplas de r(R) tales que t1[V]=t2[V] entonces
t1[W]=t2[W].

También se dice que V determina funcionalmente a W.

Mientras que una clave es un conjunto de atributos que

identifica de manera unívoca toda una tupla, una dependencia
funcional permite expresar restricciones que identifican de
manera unívoca el valor de determinados atributos.

Ejemplo: Considera r(A,B) con la siguiente instancia de r.

1 4
1 5
3 7

En esta instancia, A → B NO es cierto pero B → A si.

Dependencias funcionales (Cont.)

Las dependencias funcionales permiten expresar restricciones que
no pueden ser expresadas por las claves.

Por ejemplo:

info_prestamos= (nombre_cliente, numero_prestamo,

nombre_sucursal, cantidad)

Dependencias que se espera que se mantengan:

numero_prestamo → cantidad
numero_prestamo → nombre_sucursal

y que NO se mantengan :
numero_prestamo → nombre_cliente
(podría ser un préstamo de varias personas)
cantidad → numero_prestamo
(podría haber más préstamos con el mismo importe)
Dependencias funcionales (Cont.)

Una dependencia funcional es trivial si es satisfecha por
todas las instancias de la relación. En general, V → W es
trivial si W ⊆ V.
 E.j.

nombre_cliente, numero_prestamo → nombre_cliente

nombre_cliente → nombre_cliente

X → Y es una dependencia funcional completa o plena,

si y sólo si, Y no depende funcionalmente de ningún
subconjunto de X.
 Ej dependencia no plena:

numero_cliente, numero_prestamo → cantidad
Y numero_cliente es atributo “extraño”

X → Y es una dependencia funcional elemental si es

una dependencia funcional completa, no trivial e Y es un
atributo único.
Dependencias funcionales (Cont.)

Dado un conjunto de dependencias funcionales F que se
cumple en una relación r(R), hay otras dependencias
lógicamente implicadas.

Dado un conjunto, F, de dependencias funcionales, el

conjunto cerrado de dependencias funcionales de F,
F+, es aquel que contiene todas las dependencias
funcionales que F implica lógicamente.

Axiomas de Armstrong Tres son las reglas que permiten

encontrar el conjunto cerrado de dependencias funcionales
de una relación:

 si X ⊆ Y, entonces X → Y (reflexividad)
 si X → Y entonces Z X → ZY (amplificación)
 si X → Y e Y → Z, entonces X → Z (transitividad)
Dependencias funcionales (Cont.)

Se dice que estas reglas son válidas porque no generan
dependencias funcionales incorrectas y son completas
porque, dado un conjunto de dependencias funcionales, F,
permiten encontrar su conjunto cerrado, F+.

Su utilización práctica suele resultar incómoda, por lo que

frecuentemente, junto a ellas, se utilizan otras reglas
deducidas como:

 Si X → Y y X → Z entonces X → YZ (unión)
 Si X → YZ entonces X → Y y X → Z (descomposición)
 Si X → Y y WY → Z entonces XW → Z
(seudotransitividad)
Ejemplo

R = (A, B, C, G, H, I)
F={ A→B
A→C
CG → H
CG → I
B→H }

Algunos miembros de F+
 A→H

Por transitividad A → B y B → H
 AG → I

Por amplificación A → C con G, para conseguir AG → CG
y después transitividad con CG → I
 CG → HI

con CG → H y CG → I aplicando la regla de unión o por la
amplificación de CG → I para inferir CG → CGI, amplificación
de CG → H para inferir CGI → HI, y entonces aplicar regla de
transitividad
Procedimiento para computar F+

F+ := F
repeat
for each dependencia funcional f en F+
aplicar reglas de reflexividad y amplificación a f
añadir las dependencias funcionales resultantes a F+
for each par de depencias funcionales f1y f2 en F+
if f1 y f2 pueden ser combinadas utilizando transitividad
then añadir la dependencia funcional resultante a F+
until F+ deje de cambiar

Su cálculo es costoso en tiempo  reducir el cjto de DF 

recubrimiento canónico
Segunda forma normal (2FN)

Un esquema de relación, R, está en 2FN si y sólo
si está en 1FN y todo atributo no de clave, V ⊆ R,
depende funcionalmente de la clave (o claves) y
no de ningún subconjunto propio de ella (o ellas).
Es decir, cada atributo no principal tiene DF plena
respecto de cada una de las claves.

Se puede afirmar que cualquier relación binaria

está en 2FN, así como cualquier relación en la
que todas sus claves son simples (un solo
atributo), y cuando todos sus atributos forman
parte de la clave.
Ejemplo
PEDIDO

Cod_prov Num_ped Cod_artic Unidades_ped

Num_ped Cod_prov
A20 729 2745 110
A20 729 3752 240
B09 730 3752 250
Num_ped Cod_artic Unidades_ped
... ... ... ...

El esquema PEDIDO NO está en 2FN.

PEDIDO

Cod_prov Num_ped

A20 729
B09 730
... ... LINEA_DE_PEDIDO

Num_ped Cod_artic Unidades_ped

729 2745 110

729 3752 240
730 3752 250
... ... ...
Tercera forma normal (3FN)

Un esquema de relación, R, está en 3FN si está en 2FN y todo
atributo no de clave no depende funcionalmente de ningún
atributo no de clave (dependencias transitivas).

R está en 3FN si para toda DF X → Y en F+ se cumple una de

las siguientes condiciones:
 X → Y es trivial (i.e., Y ⊆ X)
 X es clave de R
 Cada atributo A de Y – X está contenido en alguna clave candidata
de R

Puede tener cierta redundancia pero conserva las

dependencias y la información.

Se puede afirmar que cualquier relación binaria está en 3FN,

así como cualquier relación en la que sólo hay un atributo no
de clave, y cuando todos sus atributos forman parte de alguna
clave.

La 3FN tiene ciertos problemas en relaciones que presentan

varias claves candidatas compuestas que se solapan.
Ejemplo

El esquema EMPLEADOS NO está en 3FN.

Ejemplo
MATRICULA

Nombre_al Num_exp Cod_asig

Nombre_al Num_exp
Laso, Ana 32678 2745
Laso, Ana 32678 3752
Mas, Luis 25663 3752
... ... ...

El esquema está 3FN porque no tiene atributos que

no formen parte de la clave, pero tiene redundancia.

ALUMNOS

Nombre_al Num_exp

Laso, Ana 32678

Mas, Luis 25663 MATRICULA
... ...
Num_exp Cod_asig

32678 2745
32678 3752
25663 3752
... ...
Forma normal de Boyce-Codd (FNBC):

Un esquema de relación, R, está en BCNF si y sólo si para
todas sus dependencias funcionales elementales de la
forma X → Y se verifica que X es una clave de R.

X → Y es trivial (i.e., Y ⊆ X)

X es clave de R

No siempre es posible transformar un relación a FNBC sin

que se produzca pérdida de dependencias funcionales, pero
sí sin pérdida de información.

Puede ocurrir que ciertas relaciones que se encuentran en

FNBC presenten todavía redundancias y anomalías, pero
éstas ya no se deben a las DF, y por tanto, para evitarlas
hay que recurrir a las formas normales avanzadas basadas
en otro tipo de dependencias.
Ejemplo
EXPEDIENTE
MATRICULA

Nombre_al Num_exp Nombre_al Num_exp Cod_asig Calificacion

Laso, Ana 32678 2745 APROBADO

Num_exp Cod_asig Calificacion 32678 3752
Laso, Ana
Mas, Luis 25663 3752 NOTABLE
Nombre_al Cod_asig Calificacion ... ... ... ...

El esquema No está BCFN pues ni Nombre_al ni Num_exp son

clave candidata de la relación.

ALUMNOS

Nombre_al Num_exp
Laso, Ana 32678
Mas, Luis 25663 NOTAS
... ...
Num_exp Cod_asig Calificacion
32678 2745 APROBADO
32678 3752
25663 3752 NOTABLE
... ... ...
Forma normal de Boyce-Codd (FNBC):

Si una relación cuyas claves no están solapadas
está en 3FN, está también en FNBC.

La existencia de claves candidatas solapadas no

siempre supone que la relación no esté en FNBC.
 Ejemplo:
MATRICULA

CodCurso CodEdic CodEstud Fecha

CodCurso CodEdic CodEstud Fecha
123 1 Laso, Ana 1-ene-06
122 1 Laso, Ana 1-jun-06
CodEdic CodEstud Fecha CodCurso 1 Mas, Luis 1-ene-06
123
... ... ... ...
Objetivo de diseño

Cumplir:
 Ausencia de pérdida de información.
 BCNF.
 Preservación de dependencias.

Si no se puede conseguir, se debe optar por 3FN aunque

presenta redundancia y en algún caso se requiera el uso de
nulos.

SQL no ofrece ninguna manera de especificar las

dependencias funcionales, salvo indicando la clave principal

Se pueden definir por medio de asertos pero es muy

costoso.
 Comparación FNBC – 3FN

Problemas debidos a la redundancia en 3FN
 R = (CodEstudiante, CodProfesor, Materia)
F = {CodEstudiante, Materia → CodProfesor
CodProfesor → Materia}
E P M
e1 p1 m1
Está en 3FN pero no en BC porque
e2 p1 m1
CodProfesor no es clave candidata
e3 p1 m1

null p2 m2
Un esquema en 3FN y no en FNBC tiene los problemas de
♠ Repetición de información (e.j., la relación p1, m1)
♠ Necesidad del uso de valores nulos (e.j., para representar la
relación p2, m2 donde no hay correspondiente valor de E).
Y la ventaja de que sí preserva las dependencias
 Comparación BCNF - 3NF (Cont.)

Para llevar el esquema a FNBC

E P P M
e1 p1 p1 m1
e2 p1 p1 m1
e3 p1 p1 m1
p2 m2

DF perdida: CodEstudiante, Materia → CodProfesor

DF preservada: CodProfesor → Materia

* Información se preserva

* Cualquier otra combinación, produce además pérdida de

información
 Dependencias multivaluadas

Algunos esquemas de relación aunque se hallen en FNBC sufre
problema de redundancia

Considera el esquema
CLASE (curso, profesor, libro)
tal que (c,p,l) ∈ CLASE significa que p está capacitado para
enseñar c y l es un libro de texto requerido para c

La BD recoge para cada curso, el conjunto de profesores que
puede dictarlo y el conjunto de libros requeridos para el curso
independientemente de quien lo dicte.

nombre_asig ->-> profesor

nombre_asig ->-> texto
 V W R-V-W

curso profesor libro

database Avi DB Concepts
database Avi Ullman
database Hank DB Concepts
database Hank Ullman
database Sudarshan DB Concepts
database Sudarshan Ullman
operating systems Avi OS Concepts t4
operating systems Avi Shaw t1
operating systems Jim OS Concepts t2
operating systems Jim Shaw t3
CLASE

No hay dependencias no triviales ya que la clave la forman los
tres atributos (curso, profesor, libro) y está en FNBC, PERO

Hay problema en la inserción, si Sara es una nueva profesora
de database, se han de insertar dos tuplas
(database, Sara, DB Concepts)
(database, Sara, Ullman)
Dependencia multivaluada

Sea R un esquema de relación y sea V ⊆ R y W ⊆
R. La dependencia de valores múltiples, V →→ W,
se cumple en R si en cualquier relación r(R), para
todas las parejas t1 y t2 de tuplas tales que:
 t1[V]=t2[V]
 t1[W]≠t2[W]
 t1[R-V-W]≠t2[R-V-W]

existen las tuplas t3 y t4 en r(R), tales que:

 t1[V]=t2[V]=t3[V]=t4[V]
 t3[W]=t2[W] y t3[R-V-W]=t1[R-V-W]
 t4[W]=t1[W] y t4[R-V-W]=t2[R-V-W]
Reglas de inferencia

Reglas que, dado un conjunto, D, de dependencias funcionales y
de valores múltiples, permiten encontrar el conjunto, D+, de
todas las dependencias funcionales y de valores múltiples que D
implica lógicamente.
1.- Regla de la reflexividad (“reflexivity”): Si Y ⊆ X ⇒ X →Y
2.- Regla de la amplificación (“augmentation”): Si X →Y ⇒ WX →WY
3.- Regla de la transitividad (“transitivity”): Si X →Y e Y →Z ⇒ X →Z
4.- Regla de la complementación (“complementation”): Si X → →Y ⇒ X → →R-Y-Z
5.- Regla de amplificación de valores múltiples (“augmentation for multivalued dependencies”):
Si X → →Y y V ⊆ R y W ⊆ R ⇒ WX → →WY
6.- Regla de transitividad de valores múltiples (“transitivity for multivalued dependencies”):
Si X → →Y e Y → →Z ⇒ X → →Z-Y
7.- Regla de repetición: Si X →Y ⇒ X → →Y
8.- Regla de condensación (“coalescence”):
Si X → →Y y Z ⊆ Y y ∃ W / W ⊆ R, W ∩ Y= ∅ y W →Z ⇒ X →Z
Estas reglas son válidas y completas.
Los tres primeros axiomas son los de Armstrong para dependencias funcionales, los tres
siguientes son propios de las dependencias de valores múltiples y los dos últimos relacionan
dependencias de valores múltiples y funcionales.
Cuarta forma normal (4FN)

Una relación R está en 4NF con respecto a un conjunto D
de dependencias funcionales y de valores múltiples si para
todas las dependencias de valores múltiples en D+ de la
forma X →→ Y, donde X ⊆ R e Y ⊆ R, se cumple una de las
condiciones siguientes:
 X →→ Y es trivial (i.e., Y ⊆ X o X ∪ Y = R)
 X es clave para R

Si una relación está en 4NF, está en BCNF

La definición de 4FN solo se diferencia de la FNBC en el

empleo de las dependencias multivaluadas.
Cuarta forma normal (4FN)

Dicho de otro modo, un esquema de relación está en 4NF si
y sólo si está en BCNF y todas sus dependencias no triviales
son dependencias funcionales (de valores simples). Esto
equivale a decir que una relación en 4FN no puede tener
ninguna dependencia de valores múltiples no trivial.

Básicamente, para evitar errores en los datos, por causa de

su redundacia, cada dependencia de valores múltiples
requiere una tabla separada.

Para evitar la redundancia es mejor descomponer
en dos relaciones:

curso profesor
database Avi
database Hank curso →→ profesor
database Sudarshan
operating systems Avi
operating systems Jim
enseña

curso libro
database DB Concepts
database Ullman curso →→ libro
operating systems OS Concepts
operating systems Shaw
textos

Estas dos relaciones están en 4FN, la inicial, CLASE, no porque curso

no es clave candidata de la relación, son los tres atributos.
Dependencia de combinación

Las dependencias funcionales y multivaluadas hasta ahora
permiten la descomposición sin pérdida de una relación en
dos proyecciones, sin embargo existen relaciones en las
que esto no es posible, existe una dependencia de
combinación.

Una relación tiene una dependencia de combinación si

puede ser reconstruida sin pérdida de información a partir
de una combinación de algunas de sus proyecciones. Si una
de esas proyecciones es la propia relación, entonces se
trata de una dependencia de combinación trivial.
 4NF (no existe ninguna dependencia funcional ni multivaluada)

Ejemplo Vendedor Aparato Marca

Luis TV Sony
Luis PC Sony
Luis TV Loewe
Pedro TV Sony

Vendedor Aparato Vendedor Marca Aparato Marca

Luis TV Luis Sony TV Sony

Luis PC Luis Loewe PC Sony
Pedro TV Pedro Sony TV Loewe

Vendedor Aparato Marca

1ª - 1ª Luis TV Sony
1ª - 2ª Luis TV Loewe
2ª - 1ª Luis PC Sony
2ª - 1ª Luis PC Loewe FALSA
3ª - 3ª Pedro TV Sony

Vendedor Aparato Marca

1ª - 1ª Luis TV Sony
3ª - 2ª Luis PC Sony
2ª - 3ª Luis TV Loewe
5ª - 2ª Pedro TV Sony
Quinta forma normal (5FN)

Un esquema de relación, R, está en 5NF si y sólo si, para
cada dependencia de combinación no trivial, cada
proyección incluye una clave de la relación original.

Como las proyecciones de la figura anterior no contienen la

clave de la relación de partida, ésta no está en 5NF.

Para solucionar este inconveniente, la tabla dada debe

descomponerse en las tres relaciones que constituyen las
proyecciones de la misma figura.

Al igual que ocurre con la FNBC y con la 4FN, una relación

está en 5FN si y solo si toda dependencia funcional,
multivaluada o de combinación no trivial es consecuencia
de sus claves candidatas.
Proceso de diseño

Análisis o descomposición
 Desde una relación R con todos los atributos, se realizan
sucesivas proyecciones hasta obtener esquemas que
cumplan las formas normales.
 Pasos:

Hallar el recubrimiento canónico

Determinar la(s) clave(s)

Identificar la FN en la que se encuentra la relación

Síntesis
 Se agrupan los atributos formando relaciones.

Pasos

 Hallar el recubrimiento canónico

 Se agrupan dependencias con el mismo implicante
 Se forma un esquema R para cada partición
Formas Normales. Resumen
1FN Todos los atributos son simples
2FN 1FN y cada atributo no de clave depende
funcionalmente de la clave y no de parte de ella

3FN 2FN y sus atributos no de clave son mutuamente

independientes, es decir, no hay dependencias
transitivas
BCodd 3FN y todas las dependencias funcionales
elementales, lo son de la clave
4FN BCFN y todas las dependencias no triviales son
dependencias funcionales
5FN Para cada dependencia de combinación no trivial,
cada proyección incluye una clave de la relación
original