TEMA 6

NORMALIZACIÓN

1. Teorı́a de la Normalización . . . . . . . . . . . . . . . . . . . . 2

2. Dependencia funcional . . . . . . . . . . . . . . . . . . . . . . . . 7

3. Formas normales de Codd (1NF, 2NF, 3NF) . . 14

4. Forma Normal de Boyce-Codd (BCNF) . . . . . . . 38

5. Cuarta Forma Normal (4NF) . . . . . . . . . . . . . . . . . 51

6. Quinta Forma Normal (5NF) . . . . . . . . . . . . . . . . . 69

7. Procés de Normalització . . . . . . . . . . . . . . . . . . . . . 73

1
 Teorı́a de la Normalización

• Reglas de definición de relaciones en una BD rela-

cional.

• Importante tenerlas en cuenta en la etapa de diseño

de la BD.

Diseño de la BD:
– Interesan propiedades que siempre se cumplan
⇓
CABECERA
– No interesan propiedades que sólo sean ciertas
en un momento determinado
⇓
CUERPO

2
• Permite detectar ciertas propiedades no deseables
en las relaciones y define métodos para convertir
estas relaciones en formas más tratables.
Ejemplo: Base de Datos S, SP, P
Suposemos que sacamos el atributo CIUTAT de S y lo ponemos
en SP (relación SP 2).

SP2: S# CIUTAT P# CANT

S1 Londres P1 300
S1 Londres P2 200
S1 Londres P3 400
S1 Londres P4 200
S1 Londres P5 100
S1 Londres P6 100
S2 Paris P1 300
S2 Paris P2 400

Atributo CIUTAT relacionado a suministrador

↓
Redundancia en SP2: Peligro de inconsistencia si se intro-
duce S1 con CIUTAT=’Atenas’ en SP 2
⇓

Atributos han de estar asociados

semánticamente en relaciones.

• Normalización: sucesivas reducciones (proyecciones)

de un conjunto de relaciones hasta obtener un nuevo
conjunto de relaciones que cumplen ciertas restric-
ciones.
↓
basada en
FORMAS NORMALES
3
FORMAS NORMALES

• Conjunto de restricciones sobre las relaciones.

• "Relación está en una Forma Normal"

↓
Si relación satisface restriccciones de la Forma Nor-
mal

• Diferentes formas normales relacionadas por inclusión

(nNF cumple (n − 1)NF . . . 1NF)

– CODD (1972): Definición 1NF, 2NF y 3NF.

– BOYCE-CODD (1974): Definición forma normal que

mejora la 3NF de Codd
↓
FORMA NORMAL DE BOYCE-CODD (BCNF)

– FAGIN: Definición 4NF (1977) y 5NF (1979)

4
IMPORTANTE EN DISEÑO:

Inicialmente, intentar definir relaciones en 5NF, que ga-

rantizarán una buena estructura del esquema conceptual
en BD relacional.

• No obstante, puede ser que en la BD no sea recomendable

llegar a la 5NF.
↓

Dependerá del entorno de la aplicación

(pero como a mı́nimo la 1NF).

• Diseñador ha de conocer las formas normales y los mecanis-

mos para normalizar las relaciones.
↓

Normalización: Formalización del sentido común.

5
 PROCEDIMIENTO DE NORMALIZACIÓN:

Procedimento mediante el cual una relación con una

forma normal (por ej. nNF) se puede convertir en un
conjunto de relaciones en forma más óptima ((n+1)NF).

Relación proyección k relaciones

−→
nNF (n + 1)NF

↓
Reducción sucesiva de un conjunto de rela-
ciones a una forma normal más deseada.

Procedimiento reversible: No se pierde información

en el proceso de normalización.

Relación join k relaciones

←−
nNF (n + 1)NF

⇓
FORMAS NORMALES DE PROYECCIÓN/REUNIÓN

Tres primeras formas normales (1NF, 2NF, 3NF) basadas

en el concepto de DEPENDENCIA FUNCIONAL

6
 Dependencia funcional

Definición: Dada una relación R, el atributo Y de R

depende funcionalmente del atributo X de R (R.X
determina funcionalmente R.Y ) denotado com

R.X −→ R.Y

⇐⇒

un sólo valor Y en R está asociado a cada valor X en

R. (X, Y pueden ser compuestos)

Ejemplo: BD S, SP, P

¾
S.S# → S.SNOM
S.S# → S.ZONA S.S# → S.(SNOM,ZONA,CIUTAT)
S.S# → S.CIUTAT

³ ´
P1 roja → PES=12
P .COLOR 6→ P .PES P6 roja → PES=19

7
Si el atributo X es clave candidata (o clave pri-
maria) en R:
↓
Atributos Y en R han de depender funcional-
mente de forma OBLIGATORIA de X (por
definición de clave candidata).

Ejemplo: BD S, SP, P
S.S# → S.(SNOM,CIUTAT,ZONA)

P .P# → P .(PNOM,COLOR,PES,CIUTAT)

SP .(S#,P#) → SP .CANT

8
Por la definición de dependencia funcional (DF),

• No se obliga a que X sea clave candidata.

• Puede aparecer un valor de X en diferentes tuplas dentro de

R, pero si existe DF, han de tener el mismo valor de Y .

↓ otra definición de DF

Definición: Dada una relación R, el atributo Y de R

depende funcionalmente del atributo X de R (X −→
Y)

⇐⇒

siempre que dos tuplas de R concuerden con su valor de

X, han de concordar por fuerza con su valor de Y

Ejemplo: BD SP 2

SP 2.S# no es clave candidata en SP 2 (no tiene valor

único), y en cambio,

SP 2.S# −→ SP 2.CIUTAT

9
Definición: Dada una relación R, el atributo Y de R
depende funcionalmente DE FORMA COMPLETA
del atributo X de R
⇐⇒

depende funcionalmente de X y no depende funcional-

mente de ningún subconjunto de X (X mı́nimo)

Ejemplo: BD SP 2

SP 2.(S#,P#) −→ SP 2.CIUTAT : DF NO COMPLETA,

pues

SP 2.(S#) −→ SP 2.CIUTAT : DF COMPLETA

•
Si Y depende funcionalmente, pero no
de forma completa de X ⇒ X es compuesto

• Por defecto, a partir de ahora

DF ≡ DF completa

10
DIAGRAMA DE DEPENDENCIAS FUNCIONALES:
Representación de las dependencias funcionales de una
relación. Grafo dirigido.

Ejemplo: BD S, SP, P

Usualmente, en una relación,

• DF aparecen de claves candidatas, por definición de clave

candidata. No se pueden eliminar estas DF.

• Otras flechas (no sobre claves candidatas), pueden dar pro-

blemas.
⇓

Normalización: Eliminar flechas que no salen de claves

candidatas.

11
Observaciones:

• DF: Concepto semántico. Crear DF significa en-

tender qué significan los atributos
↓ Ejemplo:

DF S.S# −→ S.CIUTAT implica

– Restricción en el mundo real: cada proveedor está situado

en una sola ciudad.

– Restricción anterior ha de cumplirse en la BD.

– Para garantizar su cumplimiento, se ha de especificar en

el esquema conceptual para que el DBMS controle que
se cumpla.

– Para especificar restricción en esquema conceptual

⇓
declarar DF

• DF: Restricción de integridad. Especificarlo en

un lenguaje para el DBMS.

CREATE INTEGRITY RULE SCDF

CHECK FORALL SX FORALL SY
(IF SX.S# = SY.S# THEN SX.CIUTAT=SY.CIUTAT);

S.S# −→ S.CIUTAT

12
Observaciones:

• Restricciones referenciales tienen fuerte relación con

DF.

S#
SP −→ S ⇒ SP.S# −→ S.S#
↓
Atributos de clave externa tienen DF con
atributos de la relación referenciada.

↓
DF entre atributos de diferentes relaciones
(RESTRICCIONES INTERRELACIONALES)

• DF representan interrelaciones de varios a uno.

SP.S# → S.CIUTAT

⇓
n
Un proveedor en una ciudad: 1→1
Muchos proveedores en una ciudad: n→1

13
 Formas normales de Codd
(1NF, 2NF, 3NF)

Suposición para las formas normales de Codd: Toda

relación tiene una sola clave candidata.

Def. ATRIBUTO NO CLAVE: Cualquier atributo que

no participa en la clave primaria de la relación.

Def. ATRIB. MÚTUAMENTE INDEPENDIENTES:

Dos o más atributos en qué ninguno de ellos de-
pende funcionalmente de los otros.
Puede actualizarse un atributo sin afectar a los
otros.

Ejemplo: BD S, SP, P

PNOM
)
COLOR * mútuamente independientes entre sı́
P# −→ PES * dependientes de CP P#
CIUTAT

14
1NF:

”Una relación está en PRIMERA FORMA NORMAL

(1NF)
⇐⇒
todos los dominios simples contienen valores
atómicos.”

Problemas con relaciones sólo en 1NF:

↓
Ejemplo: Relación P RIM ERA(S#,ZONA,CIUTAT,P#,CANT).

Diagrama Funcional:

• Atributos no clave NO son mútuamente independentes

(CIUTAT → ZONA)

• Atributos no dependientes completamente de la clave primaria

(CIUTAT,ZONA dependientes de S#, no de P#).

15
 PRIMERA: S# CIUTAT ZONA P# CANT

S1 Londres 20 P1 300
S1 Londres 20 P2 200
S1 Londres 20 P3 400
S1 Londres 20 P4 200
S1 Londres 20 P5 100
S1 Londres 20 P6 100
S2 Paris 10 P1 300
S2 Paris 10 P2 400
S3 Paris 10 P3 200
S4 Londres 20 P2 200
S4 Londres 20 P4 300
S4 Londres 20 P5 400

Redundancias (ciutat proveedor,zona proveedor) provo-

can
ANOMALÍAS DE ACTUALIZACIÓN
↓

Problemas con las tres operaciones:

INSERT: No podemos insertar datos de un proveedor

determinado hasta que no haga una entrega.
(S#,P#) clave primaria ⇒ P#=NULL si 6 ∃ entrega

DELETE: Si eliminamos la última tupla de un prove-

edor, se elimina la entrega y perdemos los datos del
proveedor.

UPDATE: Si cambiamos de ciudad a un proveedor,

hemos de cambiar todos los valores de ciudad de
las tuplas del proveedor.
Ejemplo: Modificar la ciudad del suministrador S1.

16
SOLUCIÓN: Dividir la relación P RIM ERA en dos rela-
ciones:

1. SEGON A(S#,CIUTAT,ZONA)

2. SP (S#,P#,CANT)

Diagrama Funcional:

17
PRIMERA: S# CIUTAT ZONA P# CANT

S1 Londres 20 P1 300
S1 Londres 20 P2 200
S1 Londres 20 P3 400
S1 Londres 20 P4 200
S1 Londres 20 P5 100
S1 Londres 20 P6 100
S2 Paris 10 P1 300
S2 Paris 10 P2 400
S3 Paris 10 P3 200
S4 Londres 20 P2 200
S4 Londres 20 P4 300
S4 Londres 20 P5 400

SEGONA: S# CIUTAT ZONA

S1 Londres 20
S2 Paris 10
S3 Paris 10
S4 Londres 20
S5 Atenas 30
S6 Londres 20

SP: S# P# CANT

S1 P1 300
S1 P2 200
S1 P3 400
S1 P4 200
S1 P5 100
S1 P6 100
S2 P1 300
S2 P2 400
S3 P3 200
S4 P2 200
S4 P4 300
S4 P5 400

18
• Se eliminan los problemas anteriores (INSERT,
DELETE, UPDATE).

• Solución adoptada: Eliminar dependencias no com-

pletas.

19
2NF:

”Una relación está en SEGUNDA FORMA NORMAL

(2NF)

⇐⇒
• Está en 1NF.

• Todos los atributos no clave dependen fun-

cionalmente (de forma completa) de la
clave primaria.”

Observaciones:

• Relaciones SEGON A, SP están en 2NF. P RIM ERA

no está en 2NF.
↓

Si relación está en 1NF, pero no en 2NF

⇓
CLAVE COMPUESTA: Existe un atri-
buto de la clave primaria no dependiente
de un atribut no clave.

20
• Toda relación en 1NF puede REDUCIRSE a un con-
junto equivalente de relaciones 2NF.

1NF → 2NF

REDUCCIÓN:

– Sustituir 1NF por projecciones apropiadas en 2NF.

– PROCÉS REVERSIBLE: Relaciones 2NF unificadas en

1NF mediante JOIN.

Descomposición: PROYECCIÓN
Recomposición: JOIN

21
PRIMER PASO DE NORMALIZACIÓN:
Realizar proyecciones para eliminar las dependencias fun-
cionales no completas.

Sustituir relación R por dos proyecciones R1 , R2


R(A,B,C,D)  ⇒ NO en 2NF
PRIMARY KEY: (A,B) ↓
 Atributo D depende de A, no
R.A → R.D de clave primaria (A,B).


R1 (A,D) 
D depende de clave primaria
PRIMARY KEY: (A)  (A).


R2 (A,B,C)  C depende de
clave primaria
PRIMARY KEY: (A,B) 
FOREIGN KEY (A) REFERENCES R1 (A,B).

22
 R = R1 JOIN R2

Descomposición SIN PÉRDIDAS:

• No se pierde información en la proyección.

• Información en R → también en R1 , R2

• Pero nueva estructura (R1 , R2 ) puede contener in-

formación que no se podrı́a representar en la original
(R).
↓
Ejemplo: Proveedor S5 de Atenas que
no ha hecho ningún envio.

23
DEPENDENCIA FUNCIONAL TRANSITIVA

Siguiendo el ejemplo relaciones SEGON A y SP

Dependencia funcional transitiva:

a, b → c

¾
S# → CIUTAT
⇒ S# → ZONA
CIUTAT → ZONA

24
Dependencias funcionales transitivas pueden producir
ANOMALÍAS DE ACTUALIZACIÓN

INSERT: No podemos insertar información del tipo

"Ciudad C tiene un zona X"
hasta que no exista un subministrador situado en la
ciudad.
↓
Mientras 6 ∃ proveedor → valor de clave primaria
S# a NULL

DELETE: Si eliminamos la única tupla de una ciudad

determinada, eliminamos la información de ciudad
y zona asociada a la ciudad.
Ejemplo: Si eliminamos la tupla S5 en relación SEGONA, se
pierde la información que la zona de Atenas es 30.

UPDATE: La Zona de una ciudad dada aparece dife-

rentes veces, uno por subministrador de la ciudad.
Si se cambia la zona de ciutat (Ejemplo: revisar la
zona de Londres de 20 a 30),

• hay que revisar relación SEGONA hasta encontrar todas

las tuplas de Londres y modificarlas, o bien

• se puede producir resultado inconsistente si DBMS no

localiza inconsistencias.

25
Dependencias funcionales en la relación SEGON A

Posibles descomposiciones:

a) S# → CIUTAT
1.
b) CIUTAT → ZONA

a) S# → CIUTAT
2.
c) S# → ZONA

b) CIUTAT → ZONA
3.
c) S# → ZONA

Cuál ses la mejor descomposición, y según qué crite-

rios?.
↓
BUENAS Y MALAS DESCOMPOSICIONES
26
BUENAS Y MALAS DECOMPOSICIONES

Proceso de reducción: Diferentes formas de descom-

poner una relación.

Ejemplo: Relación SEGON A con las dependencias fun-

cionales

¾
S# → CIUTAT DF transitiva
⇒
CIUTAT → ZONA S# → ZONA

↓ 2 descomposiciones:


DESCOMP. A: SC(S#,CIUTAT) 
CZ(CIUTAT,ZONA) 


 Proyecciones
3NF sin

 pérdidas
DESCOMP. B: SC(S#,CIUTAT) 


SZ(S#,ZONA)

• Descomp. B menos satisfactoria que descomp. A.

• Inconveniente en descomp. B: No podemos insertar infor-

mación de la zona de una ciudad determinada hasta que no
haya un proveeedor situado en la ciudad.

27
 Descomp. A:

Proyecciones SC, CZ son INDEPENDENTES (es posible

actualizar una relación sin tener que tocar la otra).

SEGONA: S# CIUTAT ZONA

S1 Londres 20
S2 Paris 10
S3 Paris 10
S4 Londres 20
S5 Atenas 30
S6 Londres 20

SC: S# CIUTAT
CZ: CIUTAT ZONA
S1 Londres
S2 Paris Atenas 30
S3 Paris Londres 20
S4 Londres Paris 6 10 → 80
S5 Atenas Roma 50
S6 Londres
↓
SC JOIN CZ: S# CIUTAT ZONA

S1 Londres 20
S2 Paris 80 ⇒ CIUTAT → ZONA
S3 Paris 80 ⇒
S4 Londres 20
S5 Atenas 30
S6 Londres 20

La reunión (JOIN) de las dos proyecciones después de la

actualización siempre dará la relación SEGON A válida.
↓
JOIN no podrá incumplir las restricciones de DF de
relación SEGON A.
28
 Descomp. B:
Proyecciones SC, SZ NO son INDEPENDENTES.

SEGONA: S# CIUTAT ZONA

S1 Londres 20
S2 Paris 10
S3 Paris 10
S4 Londres 20
S5 Atenas 30
S6 Londres 20

SC: S# CIUTAT SZ: S# ZONA

S1 Londres S1 20
S2 Paris S2 6 10 → 80
S3 Paris S3 10
S4 Londres S4 20
S5 Atenas S5 30
S6 Londres S6 20

↓
SC JOIN SZ: S# CIUTAT ZONA

S1 Londres 20
S2 Paris 80 ⇒ CIUTAT 6→ ZONA
S3 Paris 10 ⇒
S4 Londres 20
S5 Atenas 30
S6 Londres 20

Es necesario controlar las actualizaciones de SC, SZ para garantizar

la DF

SEGONA.CIUTAT → SEGONA.ZONA
↓
Si dos proveedores tienen la misma ciudad, han de
tener la misma zona.
29
En la descomp. A, la RESTRICCIÓN INTERRELA-
CIONAL es la DF transitiva
S# → ZONA
↓
y el cumplimiento de esta restricción se consigue
de forma automática si se cumplen las RESTRIC-
CIONES INTRARRELACIONALES

S# → CIUTAT
CIUTAT → ZONA

y el cumplimiento de estas restricciones intrarrelacio-

nales se verifica según la restricción de unicidad de la
clave primaria (S# para la relación SC y ciudad para
CZ)

S# → CIUTAT
CIUTAT → ZONA

PROBLEMA: En la descomp. B, la DF
CIUTAT → ZONA

se ha convertido en una RESTRICCIÓN INTERRELA-

CIONAL

que no se puede garantizar a partir de las DF:

S# → CIUTAT
S# → ZONA

30
 Substituir relación SEGON A,

SEGON A[S#,CIUTAT]
−→ SC(S#,CIUTAT)

SEGON A
(S#,ZONA,CIUTAT) ←−
SC JOIN CZ

SEGON A[CIUTAT,ZONA]
−→ CZ(CIUTAT,ZONA)

Eliminar dependencia funcional transitiva, quedando

31
3NF:

”Una relación está en TERCERA FORMA NORMAL

(3NF)

⇐⇒
• Está en 2NF.

• Los atributos no clave dependen de manera

no transitiva de la clave primaria.”

Observaciones:

Falta de Atributos no clave

• dependencias transitivas ⇒ mútuamente independentes

• Relaciones CZ, SC están en 3NF. SEGONA no está

en 3NF.

32
Más informalmente,

3NF:

• ”Una relación está en TERCERA FORMA NOR-

MAL (3NF)
⇐⇒
n
mútuamente independientes
Atributos no clave són dependientes completamente de la CP”

• ”Una relación está en 3NF

⇐⇒

En todo momento cada tupla está formada por:

– Valor de clave primaria que identifica.

– Conjunto de cero o más valores de atributos independien-

tes entre sı́.

33
SEGUNDO PAS DE NORMALIZACIÓN:
Obtener proyecciones para eliminar dependencias tran-
sitivas.


 R1 (A,B)





 PRIMARY KEY (A)
R(A,B,C) 
 FOREIGN KEY (B)
PRIMARY KEY (A) REFERENCES R2
=⇒


R.B → R.C 


 R2 (B,C)



PRIMARY KEY (B)

⇐=
R = R1 JOIN R2

Cómo saber si una descomposición es buena (indepen-

dente) o no?
↓
NORMA PARA OBTENER
BUENAS DESCOMPOSICIONES

34
 NORMA PER OBTENER
BUENAS DESCOMPOSICIONES:

Obtener descomposiciones con proyecciones indepen-

dientes.

Definición: (demostrada por Risanen)

Las proyecciones R1 , R2 de una relación R son indepen-

dientes
⇐⇒

1. ∀ DF en R se puede deducir lógicamente de las DF

en R1 , R2 .

2. Los atributos comunes de R1 , R2 forman una clave

primaria de al menos una de las dos relaciones.

35
Ejemplo: Descomposición A

SC(S#,CIUTAT) CP: S# S# → CIUTAT

CZ(CIUTAT,ZONA) CP: CIUTAT CIUTAT → ZONA

Relacions SC, CZ son INDEPENDIENTES:

1.

S# → CIUTAT : SC 

 ∀ DF en SEGONA
CIUTAT → ZONA : CZ
se puede deducir de

 R1 y R2
S# → ZONA : DF 
transitiva

2. CIUTAT (atributo común de CZ, SC) es clave pri-

maria de al menos una de las dos relaciones (CZ).

36
Ejemplo: Descomposición B

SC(S#,CIUTAT) CP: S# S# → CIUTAT

SZ(S#,ZONA) CP: S# S# → ZONA

Relaciones SC, SZ NO SON INDEPENDIENTES:

1.
¾ DF
S# → CIUTAT : SC CIUTAT → ZONA no
S# → ZONA : SZ deducible a
partir de estas DF

2. S# (atributo común de SC, SZ) es clave primaria

de al menos una de las dos relaciones (SC).
⇓
Descomposición B NO ES CORRECTA

37
 Forma Normal de Boyce-Codd
(BCNF)

Aparece para resolver los problemas existentes en rela-

ciones que estan en 3NF donde:

• Hay varias claves candidatas

• Claves candidatas son compuestas

• Claves candidatas se solapan (tienen atributos comunes)

↓

Si no se verifican estas condiciones, BCNF ≡ 3NF

Definición: Un conjunto de atributos X de R es un

determinante
⇐⇒

∃ un conjunto de atributos Y de R t.q. X → Y

38
BCNF:

”Una relación está en la FORMA NORMAL DE

BOYCE-CODD (BCNF)

⇐⇒

todo determinante es clave candidata”.

39
Observaciones:

• Únicos determinantes son las claves candidatas.

• Las únicas flechas en el diagrama de dependencia

son las que salen de las claves candidatas (no sólo
de las claves primarias-CP).

• BCNF no hace referencia a la 1NF, 2NF ni a la DF

transitiva.

• BCNF es una restricción más fuerte que la 3NF.

• Toda relación puede descomponerse sin pérdidas en

un conjunto equivalente de relaciones BCNF.

40
Ejemplos:

Relación P RIM ERA(S#,ZONA,CIUTAT,P#,CANT)

• No está en 2NF

 
 S# S# → CIUTAT 
 CIUTAT CIUTAT → ZONA 



Det: S#,P# S#,P# → CANT
 S#,P# → CIUTAT No está en

S#,P# → ZONA 
 BCNF



CC: { S#,P#

Relación SEGON A(S#,ZONA,CIUTAT)

• No está en 3NF

n 
Det:
S# S# → CIUTAT,ZONA 
CIUTAT CIUTAT → ZONA No está en
 BCNF
CC: { S#

41
Ejemplos: Relación SP (S#,P#,CANT)

¾
Det: { S#,P# S#,P# → CANT
Está en BCNF
CC: { S#,P#

Relación SC(S#,CIUTAT)

¾
Det: { S# S# → CIUTAT
Está en BCNF
CC: { S#

Relación CZ(CIUTAT,ZONA)

¾
Det: { CIUTAT CIUTAT → ZONA
Está en BCNF
CC: { CIUTAT

42
Ejemplo: Relación S(S#,SNOM,ZONA,CIUTAT)

Ejemplo de dos claves candidatas sin atributos comunes.

Condiciones:
• Nombre de proveedor único

• Atributos ZONA, CIUTAT independientes

(CIUTAT 6→ ZONA)

DF:

Todas las flechas existentes salen de claves candidatas

n 
S# S# → SNOM,CIUTAT,ZONA 
Det: SNOM SNOM → S#,CIUTAT,ZONA 
Está en
n  BCNF
CC:
S# 
SNOM

Importante: Hay que especificar SNOM como clave candidata para

que DBMS considere este atributo como tal para que verifique la
BCNF:

RELATION S (S#,SNOM,ZONA,CIUTAT)
PRIMARY KEY (S#)
ALTERNATE KEY (SNOM)
43
Ejemplo: Relación SP (S#,SNOM,P#,CANT)

Ejemplo de claves candidatas solapadas.

Condició:

• Nombre de proveedor único

DF:

n 
CC:
S#,P# 

SNOM,P# 


( S#,P# S#,P# → SNOM,CANT
No está en
SNOM,P# SNOM,P# → S#,CANT 
 BCNF
Det: S# S# → SNOM 


SNOM SNOM → S#

44
 SP S# SNOM P# CANT

S1 Salazar P1 300
S1 Salazar P2 200
S1 Salazar P3 400
S1 Salazar P4 200
S1 Salazar P5 100
S1 Salazar P6 100
S2 Jaime P1 300
S2 Jaime P2 400
S3 Bernal P3 200
S4 Corona P2 200
S4 Corona P4 300
S4 Corona P5 400

Tabla con redundancia → Anomalı́as de actualización

SP está en 3NF porque todo atributo no clave {CANT} depende
funcionalmente de forma no transitiva de la clave primaria
S#,P# → CANT
↓

3NF no pide dependencia completa a la clave primaria

para un atributo que sea componente de alguna clave
candidata de la relación.
↓

SNOM no depende completamente de S#,P#

S#,P# → SNOM : DF NO COMPLETA, pues

S# → SNOM

Solución: Descomponer la relación SP en dos PROYECCIONES:

• S(S#,SNOM) y SP (S#,P#,CANT)

• S 0 (S#,SNOM) y SP 0 (SNOM,P#,CANT)

45
Proyección: S(S#,SNOM) y SP (S#,P#,CANT)

 n 
 S# S# → SNOM 
 Det: SNOM SNOM → S# 



S: n 


 S# 

CC: SNOM
Estan en BCNF
½ 

Det: { S#,P# S#,P# → CANT 

SP : 



CC: { S#,P# 

Proyección: S 0 (S#,SNOM) y SP 0 (SNOM,P#,CANT)

 n 
 S# S# → SNOM 
 Det: SNOM SNOM → S# 



S0 : n 


 S# 
CC: Estan en
SNOM

 BCNF
½ 
SNOM,P# → CANT 
Det: { SNOM,P# 

SP 0 : 

CC: { SNOM,P#

46
Ejemplo: Relación EPA (Estudiante/Profesor/
Asignatura)

Ejemplo del claves candidatas solapadas.

Condiciones:

• Un estudiante de una asignatura sólo tiene un profesor para

ella (e,a → p).

• Cada profesor da una única asignatura (p → a).

• Una asignatura puede ser dada por más de un profesor

(a 6→ p).

EPA e p a

Gòdia Enric Bases de Datos

Gòdia Juanjo Gráficos
Lacruz Enric Bases de Datos
Lacruz Martı́ Gráficos

DF:

47
Está en 3NF (no existe ningún atributo no clave)

n 
e,a 
CC: 
e,p 
½ No está en BCNF
e,a e,a → p 
Det: p p→a 

e,p e,p → a

Anomalı́as de actualización: Si eliminamos ”Lacruz

estudia Gráficos”, eliminamos también el hecho ”Martı́
enseña Gráficos”.

Solución: Descomponer la relación EP A en dos PROYEC-

CIONES:

• EP (e,p) y P A(p,a)

EP e p
PA p a
Gòdia Enric
Enric Bases de Datos
Gòdia Juanjo
Juanjo Gráficos
Lacruz Enric
Martı́ Gráficos
Lacruz Martı́

¾ ¾
Det: ∅ Det: {p p→a
Está en Está en
CC: {e,p BCNF CC: {p BCNF

48
PROBLEMA: Relaciones EP, P A NO SON INDEPEN-
DIENTES

DF en Relación EP A DF en relaciones EP, P A

p → a p → a
e,p → a
e,a → p

e,a → p no puede deducirse de p → a

Relaciones EP ,P A no pueden modificarse independien-

temente.

• Si cambiamos de profesor a EP (cambiar profesor a alumno),

hemos de cambiar el profesor a P A (cambiar profesor de assig-
natura).

• Ejemplo: No podemos insertar ”Gòdia-Martı́” en la relación

EP , pues Martı́ enseña Gráficos y Gòdia ya tiene profesor de
Gráficos (Juanjo). Para saber esto último hemos de consultar
la relación P A.

No siempre es posible descomponer una relación en com-

ponentes BCNF y componentes independientes de forma
que se satisfagan a la vez.
↓

Diremos que la relación EP A es ATÓMICA:

si no puede ser descompuesta en relaciones
independientes.

49
Ejemplo: Relación EAR (Estudiante/Asignatura/
Ranking)
Ejemplo del claves candidatas solapadas.

Condició:
• Dos estudiantes no pueden tener el mismo ranking (posición)
en la misma asignatura (no hay empates – a,r → e).

• Un estudiante no puede tener dos posiciones en el ranking de

una misma asignatura (e,a → r).

DF:

n 
e,a e,a → r 
Det: a,r a,r → e 
n 
Está en BCNF
CC:
e,a 
a,r

En conclusión, BCNF
• elimina problemas de la 3NF.

• más sencilla que la 3NF al no hacer referencia a la 1NF, 2NF,

CP ni a DF transitivas.

50
 Cuarta Forma Normal (4NF)

• Formulada por Fagin (1977)

• Concepto introductorio: Dependencias MultiValo-

radas (DMV).

51
Ejemplo: Relación CPT (Cursos/Profesores/ Textos)
Relación no normalizada.
Condiciones:
• Cada tupla de la relación contiene el nombre del curso + un
grupo repetitivo de profesores, + un grup repetitivo de textos.

• Para cada curso, n profesores y m textos.

• Cada profesor → n cursos.

• Cada texto → n cursos.

• Para cada curso se siguen los mismos libros, sea quien sea el
profesor.

CPT0 c p t
n o
Date
Base de Datos {Enric} Rogers
n o ½ ¾
Hearn-Baker
Juanjo
Gráficos Foley-Van Dam
Enric
Rogers

↓ pasada a 1NF

CPT c p t

Base de Datos Enric Date

Base de Datos Enric Rogers
Gráficos Juanjo Hearn-Baker
Gráficos Juanjo Foley-Van Dam
Gráficos Juanjo Rogers
Gráficos Enric Hearn-Baker
Gráficos Enric Foley-Van Dam
Gráficos Enric Rogers

52
Observaciones:

• ∃ redundancias ⇒ Anomalı́as de actualización Ejemplo: Si

queremos añadir un nuevo profesor de BD, hay que añadir
dos tuplas nuevas, una para cada libro de texto.

• CP T
¾
Det: ∅
Está en BCNF
CC: {c,p,t

• Tupla (c, p, t): curso c puede ser impartido por profesor p

utilizando el libro de texto t.
↓
Dado un curso c, ha de aparecer una tupla para cada combi-
nación texto/profesor:
⇓

si hay las tuplas (c,p1,t1) y (c,p2,t2)

entonces tambien han de existir (c,p1,t2) y (c,p2,t1)
⇓
REDUNDÁNCIA

Problema: Independencia entre profesores y textos.

Solución: Descomponer la relación CP T en dos PROYEC-
CIONES:
– CP (c,p) y CT (c,t)

53
Proyecciones CP (c,p) y CT (c,t)

CP c p

Base de Datos Enric

Gráficos Juanjo
Gráficos Enric

CT c t

Base de Datos Date

Base de Datos Rogers
Gráficos Hearn-Baker
Gráficos Foley-Van Dam
Gráficos Rogers

Propiedades:
• Relación CP : ¾
Det: ∅
Está en BCNF
CC: {c,p

• Relación CT : ¾
Det: ∅
Está en BCNF
CC: {c,t

• Descomposición de la relación CP T en las relaciones CP ,CT

en base a
DEPENDENCIAS MULTIVALORADAS (DMV)
↓

Generalización de las DF
→
∀ DF 6← DMV

54
Definición: Dada una relación R, con los atributos
A, B, C, la dependencia multivalorada (DMV) entre
A y B denotada como

R.A −→
>> R.B

se cumple
⇐⇒

el conjunto de valores de B correspondiente a un par

dado (a : A, c : C) en R sólo depende del valor de A
y es independiente del valor de C (A, B, C pueden ser
compuestos).

55
Observaciones:

• Las dependencias multivaloradas pueden existir sólo si la relación

tiene un mı́nimo de tres atributos.

• Dada una relación R(A, B, C)

A −→
>> B ⇒ A −→
>> C
↓
A −→ >> B|C

Ejemplo: Relación CP T
c −→
>> p ⇒ c −→
>> t
↓
c −→>> p|t

• DF: DMV donde el conjunto de valores dependientes es 1.

• Problema a la relación CP T : Presencia de DMV que no son

DF
↓

Proyecciones CP, CT no tienen DMV

↓ Teorema de Fagin determina

como hacer esta sustitución

Teorema de Fagin:
La relación R, con atributos A, B, C se puede descomponer
sin pérdidas en sus dos proyecciones R1 (A, B) y R2 (A, C)
⇐⇒
se cumplen en R las dependencias multivaloradas
A −→
>> B | C

56
4NF:

”Una relación está en CUARTA FORMA NORMAL

(4NF)

⇐⇒
• Está en BCNF.

• Todas las dependencias multivaloradas en

R son DF.”

57
Consideraciones:

• CP T no está en 4NF (tiene una DMV que no es

DF).

• Proyecciones CP, CT estan en 4NF (no tienen DMV).

• 4NF elimina estructura no deseada: las DMV.

• Fagin demuestra que siempre es posible llegar a la

4NF
↓
pero en algunos casos podrı́a no ser conveniente
hacer la descomposición

• Teorema de Risanen sobre proposiciones indepen-

dents y DF, aplicable también sobre DMV

Dada una relación Es conveniente

R(A, B, C) con DF descomponer relación
=⇒ en proyecciones (A,B) y
A→B
B→C (B,C)

↓ sobre DMV

Dada una relación Es conveniente

R(A, B, C) con DMV descomponer relación
=⇒ en proyecciones (A,B) y
A −→
>> B
B −→
>> C (B,C)

58
 Quinta Forma Normal (5NF)

• Hasta ahora, toda relación es descomponible sin

pérdidas en 2 proyecciones
↓

no todas pueden ser descomponibles en 2 proyecciones.

• Existen relaciones que pueden descomponerse sin

pérdidas en 3 o más proyecciones.

Definición: Dada una relación R, esta es n-descom-

ponible
⇐⇒

la relación puede descomponerse sin pérdidas en n proyec-

ciones, siendo n el mı́nimo número de proyecciones en
que puede descomponerse R sin pérdidas.

Si n = 2 → relación 2-descomponible.

59
 Ejemplo: Relación SP J(S#,P#,J#)

Está en 4NF (no tiene DF ni DMV).

SPJ S# P# J#

S1 P1 J2
S1 P2 J1
S2 P1 J1
S1 P1 J1

SP S# P# PJ P# J# JS J# S#

S1 P1 P1 J2 J2 S1
S1 P2 P2 J1 J1 S1
S2 P1 P1 J1 J1 S2

SP JOIN PJ S# P# J# PJ JOIN JS S# P# J#

S1 P1 J2 S1 P1 J2
S1 P1 J1 S1 P2 J1
S1 P2 J1 S1 P1 J1
espuria → S2 P1 J2 espuria → S2 P2 J1
S2 P1 J1 S2 P1 J1

(SP JOIN PJ) (PJ JOIN JS)

JOIN JS S# P# J# JOIN SP S# P# J#

S1 P1 J2 S1 P1 J2
S1 P1 J1 S1 P2 J1
S1 P2 J1 S1 P1 J1
S2 P1 J1 S2 P1 J1

60
• Relación SP J: Relación 3-descomponible, pues pre-
cisamos de 3 relaciones para recuperar SP J

SPJ = (SP JOIN PJ) JOIN JS

• Propiedad 3-descomponible,
– en función de los valores especı́ficos en la relación.
– como RESTRICCIÓN INDEPENDIENTE DEL
TIEMPO.

61
RESTRICCIÓN INDEPENDIENTE DEL TIEMPO

La proposición ”SPJ equivale a la reunión (join) de

SP,PJ,JS” implica
SI la pareja (S1,P1) aparece en SP
Y la pareja (P1,J1) aparece en PJ
Y la pareja (J1,S1) aparece en JS
ENTONCES (S1,P1,J1) aparecd en SPJ.
↓
(S1,P1) ∧ (P1,J1) ∧ (J1,S1) → (S1,P1,J1)

(S1,P1) ∧ (P1,J2) ∧ (J2,S1) → (S1,P1,J2)

(S2,P1) ∧ (P1,J1) ∧ (J1,S2) → (S2,P1,J1)
(S1,P2) ∧ (P2,J1) ∧ (J1,S1) → (S1,P2,J1)

↓ restricció sobre relación SP J

SI (S1,P1,J2), (S2,P1,J1), (S1,P2,J1) aparecen en SPJ

ENTONCES (S1,P1,J1) aparece también en SPJ.
↓

Si la restricció se verifica en todo momento,

↓

• RESTRICCIÓN INDEPENDIENTE DEL

TIEMPO

• RESTRICCIÓN 3-D (3-Descomponible)

• RESTRICCIÓN CÍCLICA

62
Definición: Una relación R es n-descomponible (para
alguna n > 2)

⇐⇒

satisface una restricción cı́clica n-D independiente del

tiempo

63
Si relación SP J satisface una restricción 3-D indepen-
diente del tiempo, SP J representa un hecho como

(a) PEPE suministra LLAVES INGLESAS

(b) En el proyecto EUREKA se utilizan LLAVES INGLESAS

(c) PEPE suministra piezas al proyecto EUREKA

↓ luego
PEPE suministra LLAVES INGLESAS al proyecto EUREKA

Observaciones:

• En condiciones normales, (a),(b),(c) 6→ (d)

⇓
TRAMPA DE CONEXIÓN

• Pero es cierto en este caso si se cumple la restric-

ción 3-D
↓
la reunión de sus
Restricción 3-D ⇐⇒
proyecciones da la
se satisface
relación principal.

↓ DEPENDENCIA DE REUNIÓN (DR)

64
Definición: La relación R satisface la dependencia de
reunión (DR)

∗(X, Y . . . Z)

⇐⇒

R es igual a la reunión de sus proyecciones según X, Y . . . Z,

donde X, Y . . . Z son subconjuntos del conjunto de atri-
butos de R.

65
Ejemplo: Relación SP J(S#,P#,J#)

Satisface la DR *(SP,PJ,JS) ⇒ se puede descomponer.

Dependencias de reunión: Presentan

Anomalias de actualización
↓

(1) Ejemplo: Relación SP J(S#,P#,J#)

SPJ S# P# J#

S1 P1 J2
S1 P2 J1

1. Si insertamos (S2,P1,J1) → hemos de insertar (S1,P1,J1)

(S1,P1,J2) → (S1,P1) ∧ (P1,J2) ∧ (J2,S1)

(S1,P2,J1) → (S1,P2) ∧ (P2,J1) ∧ (J1,S1)
(S2,P1,J1) → (S2,P1) ∧ (P1,J1) ∧ (J1,S2)

(S1,P1,J1) ← (S1,P1) ∧ (P1,J1) ∧ (J1,S1)

2. Si insertamos (S1,P1,J1) 6→ hemos de insertar (S2,P1,J1)

(S1,P1,J2) → (S1,P1) ∧ (P1,J2) ∧ (J2,S1)

(S1,P2,J1) → (S1,P2) ∧ (P2,J1) ∧ (J1,S1)
(S1,P1,J1) → (S1,P1) ∧ (P1,J1) ∧ (J1,S1)

(S2,P1,J1) ← (S2,P1) ∧ (P1,J1) ∧ (J1,S2)

66
(2) Ejemplo: Relación SP J(S#,P#,J#)
SPJ S# P# J#

S1 P1 J2
S1 P2 J1
S2 P1 J1
S1 P1 J1

1. Se puede eliminar (S2,P1,J1) sin problemas, pues

no afecta a las otras tuplas.
(S1,P1,J2) → (S1,P1) ∧ (P1,J2) ∧ (J2,S1)
(S1,P2,J1) → (S1,P2) ∧ (P2,J1) ∧ (J1,S1)
(S1,P1,J1) → (S1,P1) ∧ (P1,J1) ∧ (J1,S1)

(S2,P1,J1) ← (S2,P1) ∧ (P1,J1) ∧ (J1,S2)

2. Si eliminamos (S1,P1,J1), hay que eliminar otra tu-

pla
(S1,P1,J2) → (S1,P1) ∧ (P1,J2) ∧ (J2,S1)
(S1,P2,J1) → (S1,P2) ∧ (P2,J1) ∧ (J1,S1)
(S2,P1,J1) → (S2,P1) ∧ (P1,J1) ∧ (J1,S2)

(S1,P1,J1) ← (S1,P1) ∧ (P1,J1) ∧ (J1,S1)

Si se elimina (S1,P1,J1), hay que eliminar alguna de las

tres tuplas existentes para evitar que el cumplimiento
de las tres implique (S1,P1,J1), tupla que queremos
eliminar.

↓
PROBLEMA: Cuál de las tres eliminamos?
67
TEOREMA DE FAGIN (pag. 56) se puede expresar
como
R(A,B,C) sat- satisface
isface la DR ⇐⇒ las DMV
*(AB,AC) A −→ >> B|C.

Observacions:

• DMV es un caso especial de DR → DF es un caso

especial de DR.

• DR es la forma más general posible de dependencia

siempre que se trabaje a partir de proyecciones /
reunions.
↓
DR es la dependéncia más alta

• Problema en la relación SP J: Relación que in-

cluye una DR que no es ni DMV ni DF.

68
5NF:

”Una relación está en QUINTA FORMA NORMAL

(5NF)

⇐⇒

toda dependencia de reunión en R es consecuencia de

las claves candidatas de R.”

69
Dependencia de reunión consecuencia de claves can-
didatas:

Claves candidatas son atributos comunes de las relaciones de-

scompuestas en la DR.
↓

Ejemplo: Relación S(S#,SNOM,ZONA,CIUTAT)

• Satisface la DR *((S#,SNOM,ZONA),(S#,CIUTAT)), pues

S=(S#,SNOM,ZONA) JOIN (S#,CIUTAT)
↓
S# es clave candidata

• Satisface la DR *((S#,SNOM),(S#,ZONA),(SNOM,CIUTAT)),
doncs

S=(S#,SNOM) JOIN (S#,ZONA) JOIN (SNOM,CIUTAT)

↓
S#,SNOM son claves candidatas

satisface DR que no es conse-

– Relación SP J NO →
cuencia de la clave candidata de
está en 5NF
SP J que es S#,P#,J#.
Relaciones
– SP, P J, JS estan → no contienen ninguna DR
en 5NF

70
Observaciones:

• Toda relación en 5NF ⇒ está también en 4NF

↓
DMV es un caso especial de una DR

• Toda relación se puede descomponer sin pérdidas

en un conjunto de relaciones 5NF.

• Dada una relación R, podemos saber si está en 5NF

si conocemos

– las claves candidatas de R.

– todas las dependencias de reunión en R: Hay que

encontrar cuáles son provocadas por claves candidatas y
cuáles no.

Problema: Detectar DR que no sean DMV ni

DF no es fácil, pues el significado intuitivo de
una DR no es sencillo de deducir.

71
Una relación en 5NF:

• Relación llbre de anomalı́as que pueden eliminarse

con proyecciones.

• Únicas DR existentes en la relación son consecuen-

cia de las claves candidatas.

• Únicas descomposiciones válidas son las basadas en

claves candidatas.
↓

cada descompósición estará formada por una o más

claves candidatas
↓

Ejemplo: Relación S(S#,SNOM,ZONA,CIUTAT)

Puede descomponerse sin pérdidas de diferentes formas, y

todas las proyecciones seguirán incluyendo la clave candidata.

– *((S#,SNOM,ZONA),(S#,CIUTAT))
– *((S#,SNOM),(S#,ZONA),(SNOM,CIUTAT))

72
 Proceso de Normalización

Diseño de la Base de Datos basada en la técnica de

descomposición sin pérdidas.

Dada una relación R en 1NF y una lista de restricciones

(DF,DMV,DR) aplicables a R,
↓
reducir R de manera sistemática en un conjunto
de relaciones más pequeñas equivalentes a R
y más convenientes, mediante proyecciones de
las relaciones obtenidas en el paso anterior, te-
niendo en cuenta las restricciones sobre R.

73
PASOS:

1. Proyecciones de la relación 1NF para eliminar DF

no completas.
↓
Resultado: Conjunto de relaciones 2NF

2. Proyecciones de las relaciones 2NF para eliminar

DF transitivas.
↓
Resultado: Conjunto de relaciones 3NF

3. Proyecciones de las relaciones 3NF para eliminar DF

restantes donde el determinante no sea una clave
candidata.
↓
Resultado: Conjunto de relaciones BCNF

4. Proyecciones de las relaciones BCNF para eliminar

DMV que no sean DF.
↓
Resultado: Conjunto de relaciones 4NF

5. Proyecciones de las relaciones 4NF para eliminar

cualquier DR que no sea consecuencia de las claves
candidatas.
↓
Resultado: Conjunto de relaciones 5NF

74
PASOS 1-3: Pueden ser condensados en un único
paso:

1-3. Proyecciones de la relación original 1NF para eli-

minar todas las DF en las cuales el determinante
no sea una clave candidata.
↓
Resultat: Conjunto de relaciones BCNF

EN LA PRÁCTICA:

• A menudo es suficiente llegar hasta la BCNF, o

como máximo a la 4NF.

• 5NF puede considerarse como un caso patológico

que pocas veces se producirá.

75