NORMALIZACION

Dependencias funcionales y
normalización en bases de datos
relacionales.
 TEMARIO
• 5.1. Dependencia funcional
• 5.1.1. DF Completa y DF Parcial
• 5.1.2. DF Transitiva
• 5.2. Teoría de Normalización de datos
• 5.2.2. 1FN,2FN,3FN Formas normales generales
• 5.2.2. BCFN, 5FN,6FN Forma normal
• Practicas propuestas
• 5.3. Guía de Laboratorio 4: Normalizar documentos
• 5.4 Practicas Lenguaje de control
Teoría de Normalización de datos

Un modelo E/R bien diseñado evita la

necesidad de usarla
 Mundo
– Nombre único
Requisito
real – Atributos monovaluados
(genérico
Modelado – Filas únicas
Diseño de datos – Atributos (columnas) con nombre único
conceptu
al Diseño
Normalización
– Orden de filas/columnas irrelevantes
lógico

Diseño
Denormaliza físico
ción

Base de datos
Ejemplo de diseño inadecuado
¿ Qué errores encuentra?
 Ejemplo de diseño inadecuado

• Redundancia de información: ciudad, distancia (ciudad); precio (artículo).

• Anomalías de modificación: !podemos tener el mismo artículo con dos
precios! (igual argumento para ciudad y distancia). → inconsistencias
• Anomalías de inserción: ¿Podemos registrar nuevo artículo?, ¿Nuevo
cliente?, ¿Nueva ciudad, distancia?
• Anomalías de borrado: Si eliminamos tupla de pedido de artículo A3 o cliente
C4 → pérdida de información.
 Teoría de Normalización
• Técnica formal de análisis y organización de
datos en el diseño lógico de BDR; trata de
evitar la redundancia y anomalías de
actualización.
• Penaliza las consultas (combinación consume
muchos recursos).
"hechos
distintos se
deben
almacenar en
objetos
distintos"
 Línea de tiempo
• Primera Forma Normal (1NF), dos versiones, E. F. Codd - 1970 y C. J.
Date - 2003.
• Segunda Forma Normal (2NF) E. F. Codd en 1971.
• Tercera Forma Normal (3FN) E. F. Codd en 1971.
• Forma Normal de Boyce-Codd (BCNF) Raymond F. Boyce y E. F. Codd
en 1974.
• Cuarta Forma Normal (4NF) Ronald Fagin en 1977.
• Quinta Forma Normal (5NF) Ronald Fagin en 1979.
• Forma Normal de Dominio/Clave (DKNF) Ronald Fagin en 1981.
• Sexta Forma Normal (6NF) C. J. Date, Hugh Darwen y Nikos Lorentzos
en 2002.
 Formas normales
• un esquema de relación está en una determinada forma
normal si satisface un determinado conjunto específico
de restricciones definidas sobre los atributos del esquema
(dependencias).

– 1ª FN (Codd, 1970)
• Concepto de relación normalizada.
– 2ª, 3ª FN (Codd, 1970), FNBC (Boyce/Codd, 1974)
• Basadas en análisis de dependencias funcionales.
– 4ª FN. Fagin, 1977
• Basada en análisis de dependencias multivaluadas.
– 5ª FN. Fagin, 1979
• Basada en análisis de dependencias de proyección / combinación.
 Formas normales
• un esquema de relación está en una determinada forma
normal si satisface un determinado conjunto específico
de restricciones definidas sobre los atributos del esquema
(dependencias).

– Forma Normal de Dominio/Clave (DKNF) Ronald Fagin en

1981.
• Solo si la base de datos contenga restricciones de dominios y de
claves.
– Sexta Forma Normal (6NF) C. J. Date, Hugh Darwen y Nikos
Lorentzos en 2002.
• Descompone las variables de relación de componentes irreductibles
– Des normalización
 Dependencias

• Restricciones de integridad impuestas por

el usuario.
• Propiedades inherentes al contenido
semántico de los datos.
• No se pueden demostrar, pero sí afirmar por
observación
 Dependencia funcional
• Sean A y B atributos de una misma
tabla o relación R. Se dice que B es
funcionalmente dependiente de A
y se denota A →B si todo posible
valor de A tiene asociado un único
valor de B,
Diagrama de dependencias
funcionales
• Ejemplo: R ( A, DF ).
R: pedidos
A: {artículo, cliente, cantidad, precio, ciudad, distancia}.
DF: ({artículo,cliente} → {cantidad,precio,ciudad, distancia},
artículo → precio,
cliente → {ciudad, distancia},
ciudad → distancia )

Diagrama de
Dependencias
Funcionales
Dependencia funcional completa
• Sea X (conjunto de atributos). Se dice que Y
tiene dependencia funcional plena o completa
de X,
– si depende funcionalmente de X
– pero no depende de ningún subconjunto del mismo

• P.e. (artículo, cliente)  cantidad es una DF

completa, pero
• (artículo, cliente) → precio no es una DF
completa puesto que artículo → precio;
 Dependencia funcional transitiva
• Si X→Y, Y-/→X, Y→Z entonces Z depende
transitivamente de
X ( X--→Z ).

• P.e.
– Cliente → ciudad,
– ciudad -/→ cliente (no determina funcionalmente), y
– cliente → distancia,
– por tanto, ciudad ---→ distancia
– (cliente determina “transitivamente” a distancia).
Normalización de un esquema de
BD Relacional

17
 PRIMERA FORMA NORMAL (1PF)

• Es una restricción
inherente al
modelo relacional
por lo que su
cumplimiento es
obligatorio.
• Un atributo no
puede tomar más
de un valor del
dominio
subyacente.
 Segunda Forma Normal (2FN).
• Un esquema de relación R(A,DF) está en 2ªFN si y sólo si
– Debe cumplir con 1FN
– y sus atributos no primarios dependen completamente
de la clave primaria de R. (atributos no primarios: que no formen
parte de la clave primaria).

• Si una relación R no está en 2FN, se puede

normalizar descomponiendo esa relación en:
– Una relación con los atributos de clave primaria, más los
atributos con dependencia completa de ella.
– Una relación para cada "parte" de la clave primaria, más
los atributos que dependan funcionalmente de esa
parte.

DBD. Diseño Relacional y

19
Normalización
 Descomposición a 2 FN
(informal)
• Ejemplo: PEDIDOS se descompone en:
PEDIDOS'({artículo,cliente, cantidad},
{[artículo,cliente] → cantidad})
ARTICULOS ({artículo, precio}, {artículo → precio} )
CLIENTES({cliente,ciudad,distancia},
{cliente→ciudad,ciudad→distancia})

DBD. Diseño Relacional y

20
Normalización
 Tercera Forma Normal (3FN)
• Un esquema de relación R(A,DF) está en
FN3 si y sólo si
– está en FN2 y
– ninguno de sus atributos no primarios depende
transitivamente de la clave primaria de R.
• Es decir no hay Dependencia Funcional
Transitivas.

DBD. Diseño Relacional y

21
Normalización
 Descomposición a 3FN (informal)
• Ejemplo: CLIENTES la
descomponemos en:
CLIENTES' ({cliente, ciudad}, {cliente → ciudad})
CIUDADES ({ciudad, distancia}, {ciudad→ distancia})

DBD. Diseño Relacional y

22
Normalización
 Forma Normal de Boyce y Codd
(FNBC)

Una relación R está en FNBC si todo

determinante es clave candidata.

Una relación No
que está en necesariamente
3FN está en BCNF
Una relación
que está en Está en 3FN
BCFN
se define como determinante el atributo del cual
depende funcionalmente —por completo— algún
otro atributo.
 Forma Normal de Boyce y
Codd
Otra Definición
Requiere que no existan dependencias funcionales no
triviales de los atributos que no sean un conjunto de la
clave candidata. En una tabla en 3FN, todos los atributos
dependen de una clave, de la clave completa y de
ninguna A otra cosa excepto de la clave (excluyendo
A
dependencias triviales, como ). Se dice que una
tabla está en FNBC si y solo si está en 3FN y cada
dependencia funcional no trivial tiene una clave
candidata como determinante. En términos menos
se define como determinante
formales, una tabla el atributo
está del cual
en FNBC si está en 3FN y los
depende funcionalmente —por completo— algún
únicos
otro determinantes son claves candidatas.
atributo.
 EJEMPLO BCFN
• En la relación
• PRESTAMO1, el atributo fec_prest facilita
información acerca de las claves, ya que no
existen más atributos.

• PRESTAMO1( num_socio, nombre_socio,

cod_libro, fec_prest )

• Cuando normalicemos en 3FN estaremos

eliminando dependencia funcional transitiva
• En la relación LIBRO,
• LIBRO( cod_libro, editorial, país )
– el atributo país entrega información acerca de la
editorial que publica el libro, por lo que no está en
3FN.
• La solución es descomponerla en:
• LIBRO1( cod_libro, editorial )
• EDITORIAL( editorial, país ),
– que están en 3FN, ya que todo atributo no clave
facilita información acerca de la clave.
• La relación PRESTAMO1, que está en 3FN, todavía
presenta anomalías, ya que num_socio y
nombre_socio, se repiten innecesariamente por
cada cod_libro.

• Una relación está en FNBC si y solo si, las claves

candidatas son los únicos descriptores sobre los
que se facilita información por cualquier otro
atributo.

• En la relación PRESTAMO1, num_socio es

información acerca de nombre_socio y viceversa.
Ninguno de estos atributos son clave (aunque
formen parte de la clave).
• Para solucionarlo la descomponemos:

• SOCIO( num_socio, nombre_socio )

• PRESTAMO2( num_socio, cod_libro, fec_prest ),
que están en FNBC.

• Nuestro esquema relacional está compuesto

por las siguientes relaciones en FNBC:
– LIBRO1( cod_libro, editorial )
– EDITORIAL( editorial, país )
– SOCIO( num_socio, nombre_socio )
– PRESTAMO2( num_socio, cod_libro, fec_prest )
 Múltiples
grupos
repetitivos
Como normalizar un Pedido
 Preguntas
Leydi Manrique
lmanrique@ulasalle.edu.pe