NORMALIZACION

NORMALIZACION

Una BD relacional puede sufrir anomalías de actualización durante su procesamiento a menos

que cada tabla sea normalizada
.
La normalización es el método para conseguir un buen diseño y evitar anomalías de
actualización en la BD.

La normalización ayuda a clarificar la base de datos ya organizarla en partes más pequeñas y

más fáciles de entender.
NORMALIZACION
Minimund
Minimund
oo

OBTENCION Y ANALISIS DE
REQUERIMIENTOS

DISEÑO CONCEPTUAL
Modelo Entidad Relación
Extendido

Independiente del SGBD

DISEÑO LOGICO NORMALIZACION

Específico para cada SGBD Tablas

DISEÑO FISICO
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.
4
FORMAS NORMALES

Relaciones en 2ªFN

Relaciones en 3ªFN

Relaciones en FNBC

Relaciones en 4ªFN

Relaciones en 5ªFN

Relaciones normalizadas
5
Relaciones
NORMALIZACION DE BASES DE DATOS
NORMALIZACION DE BASES DE DATOS
EJERCICIO
EJERCICIO
 NORMALIZACION DE BASES DE DATOS

Segunda Forma Normal (2FN)

Para lograr la segunda forma normal (2FN) es necesario primero lograr la primera
forma normal (1FN). Una vez que se logre, todos los atributos no claves deben
depender de toda la clave primaria, en otras palabras deben estar en dependencia
funcional completa (DFC) . Si no se cumple, se debe separar en diferentes tablas para
que cumplan este requisito
 NORMALIZACION DE BASES DE DATOS

Segunda Forma Normal (2FN)

 NORMALIZACION DE BASES DE DATOS

Tercera Forma Normal (3FN)

La Tercera Forma Normal (3FN), consiste en que ningún atributo dato. que
depende de la PK, dependa de otro atributo dato. Es decir, no debe tener
DEPENDENCIA TRANSITIVA. Hacemos la siguiente analogía.

Para que los Datos estén en 3FN, deben estar en 2FN y NO DEBEN tener
Dependencia Transitiva DT.

X ---> Y --->Z
 NORMALIZACION DE BASES DE DATOS

Tercera Forma Normal (2FN)

Tercera Forma Normal (2FN)
EJERCICIOS
ANALIZAR Y APLICAR LA PRIMERA
FORMA NORMAL

FORMADORES
DIEGO RODRIGUEZ MARTIN
LUZ DE LEON
LUIS ANGEL PESCE
RICARDO BALBIN
ANALIZAR Y APLICAR LA PRIMERA
FORMA NORMAL
APLICAR LA 2DA FORMA NORMAL
APLICAR LA 2DA FORMA NORMAL
APLICAR LA 2DA FORMA NORMAL
APLICAR LA 2DA FORMA NORMAL
NORMALIZACION DE BASES DE DATOS
NORMALIZACION DE BASES DE DATOS
 NORMALIZACION DE BASES DE DATOS
2DA FORMA NORMAL
Ejemplo.- 7
 NORMALIZACION DE BASES DE DATOS
2DA FORMA NORMAL
Ejemplo.- 7
 APLICAR LA 3RA FORMA NORMAL

En este cuadro, tendríamos como Clave Primaria al C_Evento y los demás atributos
dependen de la PK. Sin embargo, vemos que la Dirección del local T_Dirección
depende del nombre del Local donde se realiza el evento. Para resolver este problema y
tener un mejor almacenamiento de datos, la 3FN hace que creemos una 2da tabla
haciendo PK al Nombre del local teniendo como atributo dato a la Dirección.
NORMALIZACION DE BASES DE DATOS
3RA. FORMA NORMAL
 3RA. FORMA NORMAL

Con la 3FN quedaría así

3RA. FORMA NORMAL
 NORMALIZACION DE BASES DE DATOS
3RA FORMA NORMAL
Ejemplo.- 4
OTROS EJERCICIOS
 TERCERA FORMA NORMAL
DEPENDENCIA TRANSITIVA: Sean A, B, C, tres campos o colección de campos de una
relación R. sí C es funcionalmente dependiente de B, y B lo es de A, entonces C es funcionalmente
dependiente de A. Sí A no es funcionalmente dependiente de B, o B no lo es de C, entonces, se dice
que C es transitivamente dependiente de A.

La Transitividad se da cuando un atributo NO CLAVE depende funcionalmente de un atributo

que a su vez depende de la clave primaria, es decir, depende de un campo no clave.

Para eliminar la transitividad se crean tantas tablas como sean necesarias, donde los campos que
dependen transitivamente de un atributo, pasen a depender directamente de una clave.
 TERCERA FORMA NORMAL
Ejemplo:

CIUDADES (Ciudad, Población, Superficie, País, Continente)

• Los atributos como Población y Superficie tienen dependencia funcional de Ciudad

• En esta relación podemos encontrar además las siguientes dependencias:

Ciudad ---> País, País ---> Continente, Además, País --->| Ciudad

Es decir, cada ciudad pertenece a un país y cada país pertenece a un continente, pero en cada país
pueden haber muchas ciudades. En este caso continente tiene una dependencia funcional transitiva con
respecto a ciudad, a través de país. Es decir, cada ciudad está en un país, pero también en un continente.

LA TERCERA FORMA NORMAL CONSISTE EN ELIMINAR LAS

DEPENDENCIAS TRANSITIVAS
 TERCERA FORMA NORMAL
Para eliminar la transitividad se crean tantas tablas como sean necesarias, donde los campos que
dependen transitivamente de un atributo, pasen a depender directamente de una clave.

IdCiudad NombreC Población Superficie País Continente

1 Paris 6000000 15 Francia Europa
2 Lion 35000000 9 Francia Europa
3 Pekin 75000000 16 China Asia
4 Berlin 19000000 36 Alemania Europa

Existe una relación entre país y continente, y ninguna de esos atributos es clave candidata. Por lo tanto, si
queremos que nuestra tabla este en 3FN debemos separar esa columna:

CIUDADES PAISES
IdCiudad NombreC Población NombrePaís NombrePaís NombreContinente
1 Paris 6000000 Francia Francia Europa
2 Lion 35000000 Francia Francia Europa
3 Pekin 75000000 China China Asia
4 Berlin 19000000 Alemania Alemania Europa
 TERCERA FORMA NORMAL
•Tercera Forma Normal (3FN): Una relación se halla en 3FN si se encuentra en
2FN y cada uno de sus atributos no primos, son dependientes no transitivos de cada
clave de R

•Tercera Forma Normal (3FN): Una relación se halla en 3FN si y sólo si se

encuentra en 2FN y además, cada atributo no clave depende de la clave primaria
de modo no transitivo. Dicho de otra forma, una relación esta en tercera forma
normal si y sólo si sus atributos no clave son:

•Mutuamente Independientes: es decir, no existe un atributo NO clave que dependa

funcionalmente de alguna combinación del resto de los atributos No clave; por lo
tanto

•Son completamente dependientes de la clave primaria

 METODOLOGÍA DE NORMALIZACIÓN
Para ver de forma práctica, como hacer uso de la teoría de Normalización de una Base de Datos, vamos a ir
aplicando cada una de las formas normales sobre un ejemplo práctico en que se nos pide diseñar una base de
datos para la parte de una empresa correspondiente a la facturación de los clientes.

FACTURA
Para identificar la factura, hemos elegido como clave primaria
Cod_Factura
Cod_Cliente el código de la Factura y además hemos indicado que

Nombre_Cliente necesariamente una factura debe tener esos campos.

Dirección_Cliente
Ciudad
Fecha_Factura A este diseño inicial de las Facturas, al cual debemos aplicarle
Forma_Pago la metodología de las formas normales para ver si se trata de
Cod_Articulo un buen diseño de base de datos.
Descripción
Cantidad
Monto
IVA
 PRIMERA FORMA NORMAL
Se considera que está en 1FN si cada atributo (campo) de una tabla contiene un solo valor atómico
(simple). Un atributo que contiene varios valores puede ocasionar una perdida de datos
(información).

FACTURA
Cod_Factura Analizando el diseño inicial de la tabla FACTURA,
Cod_Cliente observamos la existencia de múltiples valores para los
Nombre_Cliente atributos siguientes: cod_Articulo, Descripción, Cantidad,
Dirección_Cliente Monto e IVA. Por lo tanto vemos que no cumple con la
Ciudad condición de 1FN.
Fecha_Factura
Forma_Pago
La solución consiste en crear una nueva tabla a la que
Cod_Articulo
Descripción llamaremos DETALLE_FACTURA, la cual tendrá los campos

Cantidad referente a los articulos ( Cod_Articulo, Descripci{on,

Monto Cantidad, Importe e IVA)
IVA
 PRIMERA FORMA NORMAL
El diseño de la base de datos para las facturas en
1FN seria el siguiente:
DETALLE_FACTURA
FACTURA Cod_Factura
Cod_Factura Cod_Articulo
Cod_Cliente Descripción
Nombre_Cliente Cantidad
Dirección_Cliente Monto
Ciudad IVA
Fecha_Factura
Forma_Pago

Como regla, cuando se produce la separación de datos de la tabla original en una nueva
tabla, además de los atributos necesarios, se agrega la clave primaria de la tabla original
como parte de su nueva clave primaria, pro lo tanto la nueva tabla estará formada pro dos
atributos.
 SEGUNDA FORMA NORMAL
La 2FN se relaciona con el concepto de dependencia funcional. Se entiende por dependencia funcional ,
a la relación que tienen los campos de una tabla con otros atributos de la propia tabla. Un campo tiene
dependencia funcional si necesita información de otro campo para poder contener su valor.

Una tabla se dice que esta en 2FN si:

• Está en 1FN

• Cada atributo (campo) no clave depende totalmente de la clave primaria y no de parte de ella

Cod Cod Nombre Apellido Nombre

Años
Alumno Universidad Alumno Alumno Universidad

10 100 Luis González 3 UJAP

 SEGUNDA FORMA NORMAL
El objetivo principal de la 2FN es identificar todas las tablas con una clave compuesta, puesto que todas
aquellas tablas con clave simple están por defecto en 2FN.

Siguiendo con el ejemplo, la tabla FACTURA se encuentra en 2FN pues esta en 1FN y su claves
primaria es única. Sin embargo la tabla DETALLE_FACTURA ha de ser analizada pues su clave es
compuesta, es decir, esta formada por dos campos.

FACTURA
Cod_Factura DETALLE_FACTURA
Cod_Cliente
Cod_Factura
Nombre_Cliente
Cod_Articulo
Dirección_Cliente
Descripción
Ciudad
Cantidad
Fecha_Factura
Monto
Forma_Pago
IVA
 SEGUNDA FORMA NORMAL
Analizando la tabla Detalle_Factura, vemos que el atributo descripción depende únicamente del campo
Cod_Articulo, por lo tanto la descripción debe ser llevada a una nueva tabla junto con el atributo clave
Cod_Articulo.

DETALLE_FACTURA
DETALLE_FACTURA ARTICULO
Cod_Factura
Cod_Factura Cod_Articulo
Cod_Articulo
Cod_Articulo Descripción
Descripción
Cantidad
Cantidad
Monto
Monto
IVA
IVA

El campo IVA se aplica en común para toda la factura y no depende en cada factura de los artículos.
Por lo tanto, en este caso, el atributo IVA solo dependerá funcionalmente de Cod_Factura, por lo
que deber ser agregado en la tabla FACTURA como un único campo IVA que depende totalmente
de la clave primaria Cod_Factura.
 SEGUNDA FORMA NORMAL
Con este análisis el diseño de la base de datos para las facturas de la empresa expresado en 2FN
sería el siguiente:

FACTURA
Cod_Factura
Cod_Cliente
Nombre_Cliente
Dirección_Cliente
Ciudad DETALLE_FACTURA

Fecha_Factura Cod_Factura
Forma_Pago Cod_Articulo
IVA Cantidad
Monto ARTICULO
Cod_Articulo
Descripción
 TERCERA FORMA NORMAL
Se dice que una tabla esta en 3FN (Tercera Forma Normal) si:
• Esta en 2FN
• Todos los atributos (campos) que no son claves deben ser mutuamente independientes, es decir,
un campo no debe depender de otro atributo no clave de su tabla.

• Si un campo que no es clave depende de otro campo que no es clave, la tabla posiblemente
FACTURA
contiene datos acerca de más de una entidad, contradiciendo el principio de que cada tabla debe
Cod_Factura
almacenar información de una sola entidad.
Cod_Cliente
Nombre_Cliente
Dirección_Cliente DETALLE_FACTURA
Ciudad Cod_Factura
Fecha_Factura Cod_Articulo
ARTICULO
Forma_Pago Cantidad
Cod_Articulo
IVA Monto
Descripción
 TERCERA FORMA NORMAL
En nuestro ejemplo podemos observar que las tablas ARTICULO y DETALLE_FACTURA se
encuentran en 3FN.

DETALLE_FACTURA
ARTICULO
Sin embargo, la tabla FACTURA no esta en Tercera Forma Normal (3FN), pues los atributos
Cod_Factura
Cod_Articulo
Nombre_Cliente, Dirección_cliente, Ciudad dependen funcionalmente del campo (atributo)
Cod_Articulo
Cod_cliente, campo que NO es clave. Descripción
Cantidad
Monto FACTURA
Cod_Factura
Cod_Cliente
Nombre_Cliente
Dirección_Cliente
Ciudad
Fecha_Factura
Forma_Pago
IVA
 TERCERA FORMA NORMAL
Aplicando esto, nuestro diseño de la Base de Datos para las FACTURAS da lugar a las tablas que
pueden verse a continuación en la siguiente figura y que ya están en 3FN por lo que podemos considerar
que es un buen diseño.

FACTURA CLIENTE
Cod_Factura Cod_Cliente
Cod_Cliente Nombre_Cliente
Fecha_Factura
Dirección_Cliente
Forma_Pago
Ciudad
IVA

DETALLE_FACTURA
ARTICULO
Cod_Factura
Cod_Articulo
Cod_Articulo
Descripción
Cantidad
Monto
 Tercera Forma Normal

Una relación R está en 3FN si está en 2FN y

ningún atributo no primo de R depende en forma
transitiva de la clave primaria.
 Tercera Forma Normal

Definición General
Una relación R está en 3FN si para toda
dependencia funcional no trivial X Yse cumple:

a) X es superclave de R
o
b) Y es un atributo primo
 Tercera Forma Normal
Solución:
Si una relación no está en 3FN, descomponerla
creando otra relación que contenga el/los atributo/s no
clave que determinen funcionalmente a otro/s
atributo/s no clave.

Nota: “Tener cuidado con las posibles descomposiciones”

 Forma Normal de Boyce y Codd
Una relación R está en FNBC si todo determinante es
clave candidata.

Una relación que No necesariamente

está en 3FN está en BCNF

Una relación que

está en BCFN Está en 3FN
 Forma Normal de Boyce y Codd

Otra Definición
Una relación R está en FNBC si para toda
dependencia funcional no trivial X X Y, es
superclave de R.
 Forma Normal de Boyce y Codd
Cada parcela es
identificada dentro

Veamos un ejemplo:
de un municipio,
por su nro. de
parcela
Cada parcela
es
identificada
Las sup. de las
por su nro.
parcelas de cada
catastral
municipio son
DF1 diferentes, pero, no
existe una sup.que
DF2
corresponda a más
DF3 de un municipio.

Determinantes: Claves candidatas:

•Nro_Catastral •Nro_Catastral
•Nombre_Municipio+Parcela •Nombre_Municipio+Parcela
•Superficie No es clave candidata FNBC
 Forma Normal de Boyce y Codd
Al descomponer:

Determinantes: Determinantes:
• Nro_Catastral • Superficie

Claves candidatas: Claves candidatas:

• Nro_Catastral • Superficie

BCNF BCNF
 Cuarta Forma Normal
Se basa en el concepto de dependencia
multivaluada (DMV)
Dada una relación R con atributos (X,Y,Z), X multidetermina
a Y, y se simboliza X ,Y si se cumple que dado un par
(X,Z) el conjunto de valores de {Y} que coinciden con ese par,
dependen de X y no dependen de Z.
 Cuarta Forma Normal

Una relación R está en 4FN sii está en FNBC y

no existen DMV no funcionales.
DMV

DF

DMV no funcionales
Cuarta Forma Normal

Otra definición:
Una relación R está en 4FN sii está en
FNBC y toda DMV es DF.
DMV

DF
 Cuarta Forma Normal
Veamos un ejemplo:
• Cada curso puede ser dictado por varios profesores.
• Cada curso tiene libros asignados, independientemente del
profesor que lo dicte. Es decir, el profesor no decide los
libros que usa en un curso determinado.
 Cuarta Forma Normal
¿Curso Libro?

Dado un par (Curso, Profesor), por ejemplo (Bases de Datos I, Castro) el

conjunto de valores de Libro {Fundamentos de Bases de Datos,
Introducción a los DBMS}:
1. ¿Depende del Curso? Sí depende
Curso Libro
2. ¿Depende del Profesor? No depende
 Cuarta Forma Normal
En esta relación se verifican:

DMV1
DMV2

Las dos dependencias multivaluadas no son funcionales.

Por lo tanto, la relación no está en 4FN.
 Cuarta Forma Normal
Solución:

• Está en BCNF • Está en BCNF

• No presenta DMV • No presenta DMV

Está en 4FN Está en 4FN

 Quinta Forma Normal

Se basa en el concepto de Dependencia Join

(DJ)

Dependencia Join = n-descomponible n>2

 Quinta Forma Normal

Una relación R está en 5FN sii está en 4FN y

toda DJ es consecuencia de la clave primaria.

Cada proyección de la DJ contiene a la clave

primaria
 Quinta Forma Normal
Proveedores

¿La relación Proveedores está en 5FN?

 Quinta Forma Normal
¿Es posible descomponerla en al menos 3 proyecciones sin
perder información?
¿Existe al menos una Dependencia Join?

Contiene la clave Contiene la clave Contiene la clave

primaria primaria primaria
Quinta Forma Normal

Está en 5 FN
 Quinta Forma Normal
Ahora analicemos esta otra relación:

Supongamos que satisface la siguiente restricción en todo estado

válido:
Si (S1,P1), (P1,J1) y (S1,J1) entonces debe aparecer la
tupla (S1,P1,J1) en la relación.

Restricción cíclica
 Quinta Forma Normal
Esta restricción genera la siguiente situación:

La inserción de la tupla
 Quinta Forma Normal
Analicemos ahora si está en 5FN…
Clave primaria

No contiene la clave No contiene la clave No contiene la clave

primaria primaria primaria

Join de las 3 proyecciones genera la relación original

5FN
 Quinta Forma Normal

Solución:

No posee DJs No posee DJs No posee DJs

5FN 5FN 5FN

 Normalización

Bibliografía:
• Date - Introducción a los Sistemas de Bases
de Datos
• Elmasri - Fundamentos de Bases de Datos