Normalizar
Es
el proceso por el que se identifica y corrige los problemas de diseño de
records. Un diseño de record especifica los campos e identifica el
"key" primario, si alguno, para todos los records en un archivo en
particular. Se normaliza el record para desarrollar una base de datos simple,
flexible y libre de duplicidad de datos. Un record sin normalizar contiene
grupos repetitivos, o sea un solo record tiene varios valores en un mismo
campo.
El proceso de
normalizar se compone de tres fases: Primera Forma Normal (1FN), Segunda Forma
Normal (2FN) y Tercera Forma Normal (3FN). Mientras más normalizado esté un
record, mejor es su diseño.
Primera Forma Normal:
Un record está en 1FN si no contiene grupos repetitivos.
Un grupo repetitivo es un conjunto de datos que pueden ocurrir varias veces en
un mismo record. Para llevar un record a 1FN, se expande el "key"
primario para incluir el "key" del grupo repetitivo, combinando ambos
"keys" para identificar un record en forma única.
Grupo
repetitivo
Ejemplo:
Con grupo repetitivo:
Order (order-num,
order-date, (product-num, prod-desc, num-ordered))
En 1FN:
Order (order-num,
product-num, order-date, prod-desc, num-ordered)
Segunda Forma Normal:
Se usa el concepto
de dependencia funcional - un campo (X) depende funcionalmente de otro campo
(Y) si el valor del segundo campo (Y) determina el valor del primero (X). Por
ejemplo, la fecha de una orden depende del número de orden, para un número de
orden solo puede haber una fecha de orden. No es así con la descripción del
producto, pues un número de orden puede tener varias descripciones de
productos.
Un record está en
2FN si está también en 1FN y todos los campos que no son parte del
"key" primario dependen de todo el "key" primario. Si
cualquier campo en un record en 1FN depende de solo uno de los campos que
componen el "key" primario, el record no está en 2FN. Si el record en
1FN tiene tan solo un campo como "key" primario, entonces está
también en 2FN.
Para convertir un
record a 2FN:
1.
Se crea un
nuevo diseño de record para cada campo del "key" primario.
2.
Luego se
crea un nuevo diseño de record para todas las combinaciones de los campos de
"keys" primarios, comenzando con dos campos, luego tres y así
sucesivamente hasta tener ek "key" primario original.
3.
Para cada
nuevo diseño de record, se designa el campo o campos que serán "keys"
primarios.
4.
Se
colocan cada uno de los campos que
quedan con su "key" primario, que será aquél del cual el campo
dependa.
5.
Una vez asignados
todos los campos, se eliminan aquellos diseños de record que no tengan campos
asignados.
Ejemplo:
En 1FN
(pero no en 2FN):
Order (order-num,
product-num, order-date, prod-desc, num-ordered)
En 2FN:
Order (order-num,
order-date)
Product (product-num,
product-desc)
Order-line
(order-num, product-num, num-ordered)
Tercera Forma Normal:
Existe si el
diseño del record está en 2FN y ningún campo no-"key" depende de otro
campo no-"key". Para convertir el record a 3FN, se remueven los
campos no-"key" que dependen de otro campo no-"key" y se
crea un nuevo diseño de record con el campo del cual se depende como
"key" primario.
Ejemplo:
Record que
no está en 3FN:
Cliente (num-cliente, nombre-cliente, direccion,
num-rep-ventas, nombre-rep-ventas)
Record que
está en 3FN:
Cliente (num-cliente, nombre-cliente, direccion,
num-rep-ventas)
Rep-Ventas (num-rep-ventas, nombre-rep-ventas)