CAPITULO 7

TEORIA DE
NORMALIZACION

INTRODUCCIÓN.
Los modelos de datos son instrumentos (objetos y reglas) que nos ayudan a representar la realidad,
es decir, nuestro Universo del Discurso.
Cuando se diseña una BD mediante el modelo relacional, se tiene distintas alternativas, así se
obtienen diferentes esquemas relaciónales y no todos ellos son equivalentes, ya que unos van a
representar mejor la realidad que otros.
La Teoría de Normalización, es en esencia una expresión formal de ideas sencillas.

El diseño de las bases de datos es en realidad el diseño de esquemas, por definición, :-a~do
diseñamos una base de datos, nos interesan las propiedades de los datos que : e~".cre se
cumplen, no propiedades que por casualidad son ciertas en algún instante especifico.
EL DISEÑO RELACIONAL.

Se puede abordar de dos formas:

Obteniendo directamente el esquema relacional a partir de la observación del Universo del
Discurso.
Realizando el proceso en dos fases:
Se lleva a cabo el diseño conceptual (Ejm. MER)
Transformar en un esquema relacional
Muchas de estas formas de abordar presentan inconvenientes como:
Redundancia
Ambigüedades
Perdida de información
Perdida de dependencias funcionales
Aparición de estados no validos en el mundo real
Incapacidad de almacenar ciertos hechos

DEPENDENCIA FUNCIONAL.
L as dependencias funcionales son una restricción al conjunto de relaciones del Modelo
Relacional, nos permiten expresar hechos sobre el sistema que estamos modelando
con la BD.
Para encontrar las dependencias funcionales que le sostienen en una relación es analizar el
significado de los atributos y no su valor. La existencia de una dependencia funcional no se puede
demostrar, pero si observar en el mundo real.
Sea el esquema de la relación R definido sobre el conjunto de atributos A y sean X y Y subconjuntos
de A. Se dice que, Y depende funcionalmente de X, o que X determina o implica a Y, (X determina
funcionalmente a Y) de otra forma [Y depende funcionalmente de X). representado por:
X -> Y
Donde:
X: determinante o implicante
Y: implicado
Si, Y solo si, cada valor de x tiene asociado en todo momento un único valor de Y.
Ejm. En la relación:
ESTUDIANTE(CI, NOMBRE, DIRECCIÓN, SEM_ING)
Cl->NOMBRE
Cl->DIRECCIÓN

A partir de ahora el esquema de una relación se considera como:

R=(A, DEP)
Donde:
A: Conjunto de atributos
DEP: Conjunto de dependencias
Ejm.
ESTUDIANTE({CI,NOMBRE,DIRECCIÓN,SEMJNG},{CI->NOMBRE,CI->DIRECCION,CI->SEM_ING,
NOMBRE->DIRECCION})
7.3.1. Diagrama de Dependencias Funcionales:
Una herramienta útil para explicar las dependencias funcionales es el grato o diagramas de
dependencias funcionales. Los nodos son atributos y los arcos dependencias funcionales.
Ejm. El "PRECIO- ITEM se determina con NOMBRE-ITEM y la "TIENDA" donde se vende el ítem.

Ejm. X->Y

Dependencias Funcionales especiales y axiomas:

a) Dependencia funcional completa:
Si el descriptor X es compuesto: X(X1,X2) se dice que Y tiene dependencia funcional completa, si
depende funcionalmente de X, pero de ningún subconjunto del mismo.
x->y
x1->y
x2->y
Ejem. En la relación REGISTRA(CI,SIGLA,NOTA,SEMESTRE)
C1,SIGLA,SEMESTRE->NOTA
Cl->NOTA
SIGLA->NOTA
SEMESTRE->NOTA

Dependencia funcional trivial:

Una dependencia funcional X->Y es trivial si Y es un subconjunto de X (Y⊆X).
CI,NOMBRE->NOMBRE
Descriptores equivalentes:
Se dice que X e Y son equivalentes si se cumple: X->Y, Y->X Representado por: X<->Y
Ejm. En la relación EMPLEADO(CI,NSS,NOMBRE,DIR) Cl NSS NSS-> Cl NSS Cl
Dependencia funcional transitiva:
Sea la relación R(X,Y,Z) con las siguientes dependencias: X->Y Y->Z Y->X
Se dice que Z tiene una dependencia transitiva respecto a X a través de Y.
Axiomas de Amstrong:
Los axiomas de Amstrong son útiles para encontrar dependencias funcionales de otras
dependencias funcionales. El conjunto de todas las dependencias funcionales se denomina Cierre
(O Cerradura):
Al: Si Y⊆X entonces X->Y (Reflexividad)
A2: Si Z⊆W y X->Y entonces XW->YZ (Aumentatividad)
A3: X->Y e Y-^Z entonces X->Z (Transitividad)
A4: X->YZ entonces X->Y y X->Z (Proyectividad)
A5: X->Z e X->Y entonces X->YZ (Unión o aditividad)
A3: X->Y e YW->Z entonces XW->Z (Pseudotransitividad)

NORMALIZACION.
Formalmente se plantea en los siguientes términos:
Dado un conjunto A de atributos y el conjunto D de dependencias existentes entre ellos, que
puede considerarse que constituyen un esquema de relación R(A,D) (esquema origen), se trata de
transformar estos conjuntos de partida en un conjunto de n esquemas de relación {R,(Ai,Di)} n i=i
(esquemas resultantes), tales que cumplan unas determinadas condiciones.
Propiedades:
 Conservación de la información.
 Conservación de dependencias.
 Mínima redundancia.
Si la transformación cumple las propiedades, entonces
{Ri} es equivalente a R
Si Ri está en formas normales más avanzadas que el esquema origen, entonces:

{Ri} es mejor a R

7.4.1. Formas Normales:

La teoría de la normalización tiene como fundamento el concepto de formas normales. Y consiste

en obtener esquemas (Tablas) relaciónales que cumplan unas determinadas condiciones.

Se dice que una relación está en una determinada forma normal si satisface un cierto
conjunto de restricciones (Formas normales definidas por).
CODD 1o. 2o, 3o Forma Normal.
BOYCE y CODD Forma Normal de BOYCE / CODD.
FAGIN 4a Forma Normal.
5a Forma Normal (Forma Normal de Proyección - Reunión).

Se han definido un gran número de formas normales. [Link] definió la Ira. 2da. Y 3ra. Formas
Normales. El motivo es las definiciones de Codd era que la 2NF era más deseable que la INF y la
3NF a su vez más deseable que la 2NF.

Es decir, una reducción sucesiva de un conjunto dado de relaciones a una forma más deseable.

La definición original de 3NF resulta ser inadecuada en ciertos aspectos. Boyce y Codd dieron
una definición modificada más sólida.
Hoy en día la nueva 3NF se conoce por ¡o regular como Forma Normar Boyce/Codd (BCNF) para
distinguirla de la Forma Normal anterior.
Más adelante Fagin definió una Cuarta Forma Normal (4NF) (cuarta porque en esa época a la
BCNF todavía se le llamaba Tercera).

Er fechas recientes Fagin, también definió otra forma normal, a la cual llamo: "Forma Normal de
Proyección-Reunión (PJ/NF) o Quinta forma normal (5NF)". Primera Forma Normal (INF):

Ejemplo: "Pedido"

Num - Pedido Día - Pedido Líneas - Pedido

Orden 1 21 Diciembre 98 Num - Elemento Cant - Pedido
P1 10
P2 40
Orden 100 20 Enero 99 Num - Elemento Cant - Pedido
P4 40
P5 60
P6 50

Normalizando:

Num - Pedido Día - Pedido Num - Elemento Cant - Pedido

Orden 1 21 Diciembre 98 P1 10
Orden 2 21 Diciembre 98 P2 40
Orden 100 20 Enero 99 P4 40
Orden 100 20 Enero 99 P5 60
Orden 100 20 Enero 99 P6 50

Normalizado -> 1 NF

Una relación, está en primera forma normal si cumple que sus elementos no tienen elementos que
a su vez sean conjuntos, en otras palabras, que no existan grupos repetidos.
 Una R para los grupos repetitivos.
 Una R para los campos únicos (vacíos).

Segunda Forma Normal: (2 NF)

Una relación esta 2NF cuando está en primera forma normal y solo si los atributos no llaves
dependen completamente de la llave primaria.
Ejemplo: De las Dependencias funcionales de la relación PEDIDOS
Llaves: Num – Pedido
 Num - Elemento
Num - Pedido -> Día - Pedido
Num - Pedido, Num - Elemento -> Cant – Pedido
Por tanto, la relación PEDIDOS puede descomponerse en dos relaciones:
Pedidos (Num – Pedido, Día - Pedido)
Líneas _ Pedido (Num - Pedido, Num - Elemento, Cant - Pedido)
Los atributos no clave están determinados por toda la clave (y no por parte) de la relación.
Las relaciones con esta propiedad se dice que están en 2NF.

Tercera Forma Normal: (3 NF)

Una relación R está en 3NF, si está en 2NF, y si todos los atributos no llave son independientes de
cualquier otro atributo no llave, es decir, que se deben eliminar las independencias transitivas de
atributos no llaves respecto a la llave primaria.
Ejemplo: La relación VEHÍCULOS, almacería información sobre autos.
NUM - REG PROPIETARIO MODELO FABRICANTE NUM - CILINDRO
LPA- 096 Javier Falcon Ford 4
HCA -124 Alma Laser Ford 6
CTA-201 Javier Corolla Toyota 4
STZ-211 Alina Laser Ford 4
HOO-431 Andrés Corolla Toyota 4

Sin embargo, nótese que hay dependencias funcionales entre atributos no clave de la relación.
Modelo, Fabricante -> Num - Cilindro
Si hay más de dos coches del mismo MODELO y FABRICANTE, la relación VEHÍCULOS, entonces sus
NUM-CILINDRO estarán almacenados dos veces, de nuevo una característica no deseable.
Las relaciones en 2NF, pero no es 3NF se pueden descomponer en relaciones en 3NF.
REGISTRO (NUM-REG, PROPIETARIO, MODELO, FABRICANTE)
VEHÍCULOS (MODELOS, FABRICANTE, NUM - CILINDRO)
Entonces, cada relación:
 Solo contiene hechos sobre la clave de la relación.
 No tiene sucesos entre columnas no clave.

Ejemplo:
Se desea diseñar una base de datos para el control de la producción de una empresa
farmacéutica. En la empresa se producen diferentes medicamentos. Cada medicamento puede
producirse en diferentes formas farmacéuticas. Para cada forma farmacéutica diferente de un
medicamento existe un plan de unidades un costo de producción.
En la producción de una forma farmacéutica de un medicamento dado intervienen indistintas
materias primas cada una en una determinada cantidad.
De cada medicamento se conoce el código que lo identifica y el nombre.
De cada forma farmacéutica se conoce el código que lo identifica y la descripción de su tipo.
De cada materia prima se conoce el código que la identifica el nombre, la unidad de medida y el
precio unitario.
 Determine las dependencias funcionales que existan.
 Determine las llaves candidatos y señale la llave primaria, suponiendo que inicialmente todos
los datos están agrupados en una sola relación.
 Diseñe el modelo de datos relacional normalizando las tablas.
Información:
Medicamento: Código Medicamento
Nombre
Forma Farmacéutica: Código
Descripción
Materia Prima: Código Materia Prima
Nombre
Unidad de Medida
Precio Unitario
Forma Farmacéutica ≠ Medicamento: Plan de Unidades
Costo Producción
Producción: Cantidad
"Relación Medicamentos"
Medicamentos (Cod_Med, Nombre, Cod_FF, Descripción, Cod_MP, Nombre_MP, UM, PU, Plan_U,
Costo, Cantidad)
a) Dependencias Funcionales:
Cod_Med -> Nombre
Cod_FF -> Descripción
Cod_MP -> Nombre_MP, UM, PU
Cod_Med, Cod_FF -> Plan_U, Costo
Cod_Med, Cod_MP, Cod_FF ->Cantidad

b) Llaves
Llaves Candidatas:
Cod_Med, Cod_FF, Cod_MP
Llaves Primarias
Cod_Med, Cod_FF, Cod_MP
c) Normalización:
1NF
MEDICAMENTOS (COD_MED, NOMBRE, COD_FF, DESCRIPCIÓN, COD_MP, NOMBRE_MP, UM, PU,
PLAN_U, COSTO, CANTIDAD)
2NF
Medicamentos (Cod_Med, Nombre)
Forma_Farmaceutica (Cod_FF, Descripción)
Materia_Prima (Cod_MP, Nombre_MP, UM, PU)
Plan (Cod_Med, Cod_MP,Cod_FF, Cantidad)
3NF
Las tablas son las mismas que la 2NF puesto que no existen atributos no llave que dependan
funcionalmente de otros atributos no llave.

Ejemplo: Llevar a la forma normal deseada.

Cliente
Numero Pedido Fecha Numero Nombre Cliente País Cliente Numero ITEM Descripcló n Cantidad Precio
Cliente
4001 10/07 3001 Carsa Perú 001 Diseñador 1 40.000
002 Planificador 1 30.000
003 l-CASE 1 7.000
4002 18/03 3006 Coin Bolivia 001 Diseñador 3 40.000
003 l-CASE 3 7.000
4003 30/10 3011 Sans Argentina 001 Diseñador 1 40.000

Relación
Pedido (Num_Pedido, Fecha, Num_Cliente, Nombre_Cliente, País_Cliente, Num _ ITEM, Descripción,
Cantidad, Precio)
1NF
Pedido (Num_Pedido, Fecha, Num_Cliente, Nombre_Cliente, País_Cliente)
ITEM (Num_Pedido, Num_ITEM, Descripción, Cantidad, Precio)
2NF
Pedido (Num_Pedido, Fecha, Num_Cliente)
Cliente (Num_Cliente, Nombre_Cliente, País_Cliente)
Línea Pedido (Num_Pedido, Num_ITEM, Cantidad)
ITEM (Num_ITEM, Descripción, Precio)

Forma Normal de BOYCEL CODD: (BC/NF)

Para la mayoría de las situaciones las tablas en la BCNF suelen estar libres de los problemas de
redundancia de datos y de anormalidades.
Sin embargo, ocasionalmente este tipo de tablas plantean situaciones un tanto extrañas, que
pueden resultar problemáticas.
Una tabla está en BCNF si está en la 3NF y si, y solo si, cada determinante es bien la clave, o bien
una clave alterna, donde por determinante entendemos cualquier conjunto de campos del que
otro campo depende funcionalmente de forma completa.

Ejemplo, Dada la siguiente tabla:

VENTAS (COD_PIEZA, COD_ALMACEN, NOMBRE_ALMACEN, CANTIDAD)

Donde suponemos que los almacenes se identifican unívocamente, tanto por el código como por
el nombre; existen dos claves, la formada por el conjunto COD_PIEZA, COD_ALMACEN y la que
componen COD_PIEZA, NOMBRE_ALMACEN. Sin embargo, existen cuatro determinantes; además
de las claves anteriores, tanto del campo COD_ALMACEN como NOMBRE_ALMACEN son
determinantes, ya que uno implica al otro y viceversa, por lo que, si queremos cumplir la BCNF,
debemos descomponer la tabla en:
ALMACENES (COD_ALMACEN, NOMBRE_ALMACEN)
N_VENTAS (COD_PIEZA, COD_ALMACEN, CANTIDAD)

4.1 DEPENDENCIA MULTIVALUADA.

Algunas relaciones satisfacen las restricciones impuestas por las independencias funcionales; pero
contienen redundancia. Para solucionar esta redundancia Fagin (1977) introdujo la idea de
dependencia multivaluada y de la Cuarta forma normal.
La notación X ->->Y indica que un conjunto de Y muestra una dependencia multivaluada (DMV)
en un conjunto de atributos de X.
A diferencia de la DF, la DMV no son propiedades de la información que se representan con
relaciones. Más bien, dependen de la forma en que se estructuran los atributos en las relaciones.

Definición:
En la relación R (X, Y, Z), X->->Y si cada valor de X se junta con un grupo de valores en Y, en una
forma que no dependa de los valores de Z.
Ejm.
Un valor de ID_PERSONA siempre determina un conjunto de valores de CONOCIMIENTOS.
ID_PERSONA ->-> CONOCIMIENTOS
Una persona identificada por ID_PERSONA tiene un número de CONOCIMIENTOS y trabaja en un
número de proyectos, identificados por ID_PROYECTO. Así CONOCIMIENTOS e ID_PROYECTO son
dependencias multivaluadas sobre ID_PERSONA (Por que una persona puede tener muchos
conocimientos y trabajar en muchos proyectos).
Almacenando diferentes valores de multi-ocurrencias en filas diferentes:
PERSONA
ID PERSONA CONOCIMIENTOS ID PR®YECT»
Emilio Informática -
 Emilio - -
Emilio - Proy1
Emilio - Proy3
José Francés -
José Económicas -
José - Proy1
Javier Informática -
Javier - Proy2
Javier - Proy1

Cada fila contiene un solo valor de CONOCIMIENTOS o de un ID_PROYECTO, y la otra columna está
en blanco. El problema de este método es que hay excesivos campos en blanco (resultando un
mal almacenamiento) y que los programas del sistema tendrían que manejar esos campos en
blanco
Minimizando el número de filas:
PERSONA
ID PERSONA CONOCIMIENTOS ID PROYECTO
Emilio Informática Proy1
Emilio Francés Proy3
José Francés Proy1
José Económicas -
Javier Informática Proy1
Javier - Proy2

Se minimiza el número de filas almacenando valores para CONOCIMIENTOS e ID_PROYECTO en la

misma fila. Si el número de valores de CONOCIMIENTOS e ID_PROYECTO para una persona es el
mismo, entonces no hay valores en blanco. Sin embargo, si el número de valores es diferente
(como es más normal), entonces habrá valores en blanco.
Producto cruzado:
PERSONA
ID_PERSONA CONOCIMIENTOS ID_PROYECTO
Emilio Informática Proy1
Emilio Francés Proy1
Emilio Informática Proy3
Emilio Francés Proy3
José Francés Proy1
José Económicas Proy1
Javier Informática Proy1
Javier Informática Proy2
Sé tiene una fila por cada posible combinación de CONOCIMIENTOS, ID_PROYECTO para cada
persona.
Propiedades de dependencias multivaluadas:
Como las Dependencias funcionales, las nuevas dependencias multivaluadas se pueden derivar
de las DMV existentes (Beery 1977).
Axiomas:
 Si Y ⊂ X, entonces X->->Y (regla de reflexividad DMV).
 Si X->->Y, entonces X->->U-X-Y es válida (regla de complementación).
 Si X->->Y y W ⊂ U y V ⊂ W, entonces WX->->VY (regla de aumento DMV).
 Si X->->Y y Y->Z, entonces X->->Z-Y (regla de transitividad DMV).

Algunas reglas DMV útiles que pueden derivarse de las reglas anteriores son:
 Si X->->Y y X->->Z, entonces X->->YZ (regla de unión DMV)
 Si X->->Y y WY->->Z, entonces WX(Z-WY) (regla de pseudotransitividad DMV)
 Si X->->Y y X->->Z, entonces X->->YZ (regla de unión DMV)
 Si X->->Y y X->->Z, entonces X->->Y ∩ Z (regla de intersección DMV)

 Si X->->Y y X->->Z, entonces X->Y-Z y X->->Z-Y (regla de diferencia DMV)

Axiomas adicionales DF-DMV son:

 Si X->Y, entonces X->->Y (regla de replicación)
 Si X->->Y y Z ⊂ Y y hay una W tal que W ⊂ U y W∩Y=falso y W->Z, entonces X->Z (regla de

coalescencia)
 Si X->->Y y XY->Z, entonces X->Z-Y
Cuarta Forma Normal (4NF):
Las relaciones en 4NF no deben contener más de una dependencia multivaluada independiente o
una dependencia multivaluada independiente junto con una dependencia funcional.
Ejm. En la relación PERSONA
CONOCIMIENTOS e ID_PROYECTO son dependencias multivaluadas independientes de
ID_PERSONA.
Los conocimientos de una persona son independientes de los proyectos en los que trabaja, y los
proyectos en los que trabaja una persona son independientes de sus conocimientos.
ASIGNACIONES
ID PERSONA ID PROYECTO
Emilio Proy1
Emilio Proy3
José Proy1
Javier Proy1
Javier Proy2
CONOCIMIENTO
ID PERSONA CONOCIMIENTOS
 Emilio Informática
Emilio Francés
José Francés
José Económicas
Javier Informática
Una relación esta en 4NF si no contiene dependencias multivaluadas independientes.

Quinta Forma Normal (5NF):

Se puede considerar como una extensión de la 4NF en el sentido de que ahora las dependencias
multivaluadas no son independientes.
Ejm. En la relación PERSONA
De esta forma, un conocimiento de persona y un proyecto de persona serian cargados en
relaciones separadas de la forma:
ID PERSONA ID PROYECTO
Emilio Proy1
Emilio Proy3
José Proy1
Javier Proy1
Javier Proy2
ID PERSONA CONOCIMIENTOS
Emilio Informática
Emilio Francés
José Francés
José Económicas
Javier Informática

Conocimientos necesarios
ID PROYECTO CONOCIMIENTOS
Proy1 Informática
Proy1 Económicas
Proy2 Informática
Proy3 Informática
Proy3 Francés

Supóngase que en vez de contener información sobre CONOCIMIENTOS e ID_PROYECTO de una

persona, la relación también contiene información sobre los conocimientos que la persona aplica
en un proyecto dado. Ello asegura que, si una persona posee un conocimiento, entonces podrá
aplicarlo a un proyecto si ese proyecto lo necesita.
La relación se mostraría de la forma:
APLICACIÓN-CONOCIMIENTOS
ID PERSONA CONOCIMIENTOS ID PROYECTO
Emilio Informática Proy1
Emilio Informática Proy3
Emilio Francés Proy3
José Francés -
 José Económicas Proy1
Javier Informática Proy1
Javier Informática Proy2

Esta relación está en 4NF, pero todavía tiene propiedades indeseables:

 Algunos hechos esta almacenados dos veces
 Hay atributos en blanco
Estas propiedades indeseables surgen porque APLICACIÓN-CONOCIMIENTOS contiene
dependencias multivaluadas dependientes, esto es, el valor de CONOCIMIENTOS que está
asociado con ID_PROYECTO depende de los CONOCIMIENTOS necesarios para el proyecto.
Una propiedad de la relación que está en 4NF, pero no en 5NF es que no se puede descomponer
en dos relaciones, sino que debe descomponerse en tres relaciones: