2.2. Normalización.

2.2.1. PRIMERA FORMA NORMAL (1FN)[1]

 Las formas normales se usan para asegurar que varios tipos de anomalías e inconsistencias no sean introducidas en la base de datos. La primera, segunda y tercera forma normal fue originalmente definida por el Dr. E. F. Codd. Posteriormente, Boyce y Codd introdujeron otra forma normal llamada  Forma Normal de Boyce-Codd. (FNBC).

 Una tabla está en 1FN si todos los atributos no clave, dependen funcionalmente de la clave (es decir, si dada una clave se puede obtener el valor de todos sus atributos), o lo que es lo mismo, no existen grupos repetitivos para un valor de clave.

 Pasos a seguir:



[1]Tomado de I.E.S. Celia Viñas. Documento 00047541.

 

A. Se crea a partir de la tabla inicial una nueva tabla con los atributos que dependen funcionalmente de la clave (Que tendrán la misma clave que la tabla inicial). Esta tabla ya está en primera forma normal.

 B. Se crea una nueva tabla con los atributos restantes, eligiendo de entre estos uno como clave de la tabla (o más de uno). Los criterios de elección de clave serán los mismos que se expusieron para los tipos de clave.

 C. Se comprueba si esta tabla esta en primera forma normal. Si es así, la tabla inicial ya está normalizada y finaliza el proceso. Si no, tomamos esta tabla como tabla inicial y volvemos a realizar el apartado A.

Ejemplo

EJEMPLO.

DOMINIO Y VALORES.

Suponga que un diseñador principiante desea guardar los nombres y los números telefónicos de los clientes. Procede a definir una tabla Cliente como la que sigue:

  T1
  En este punto, el diseñador se da cuenta de la necesidad de guardar múltiples números telefónicos para algunos clientes. Razona que la manera más simple de hacer esto es permitir que el campo "Teléfono" contenga más de un valor en cualquier registro dado:
  T1
  Asumiendo, sin embargo, que la columna "Teléfono" está definida en algún tipo de dominio de número telefónico (por ejemplo, el dominio de cadenas de 12 caracteres de longitud), la representación de arriba no está en 1FN. La 1FN prohíbe a un campo contener más de un valor de su dominio de columna.

 

Ejemplo

EJEMPLO.

GRUPOS REPETIDOS A TRAVÉS DE COLUMNAS.

El diseñador puede evitar esta restricción definiendo múltiples columnas del número telefónico:

 
 

Sin embargo, esta representación hace uso de columnas que permiten valores nulos, y por lo tanto no se conforman con la definición de la 1NF dada. Incluso si se contempla la posibilidad de columnas con valores nulos, el diseño no está acorde al concepto de 1NF. Teléfono 1, Teléfono 2, y Teléfono 3, comparten exactamente el mismo dominio y exactamente el mismo significado; dividir el número de teléfono en tres encabezados es artificial y causa problemas lógicos. Estos problemas incluyen:

  • Dificultad en hacer consultas a la tabla. Es difícil contestar preguntas tales como "¿Qué clientes tienen el teléfono X?" y "¿Qué pares de clientes comparten un número de teléfono?".
  • La imposibilidad de hacer cumplir la unicidad de los enlaces Cliente-a-Teléfono por medio del RDBMS. Al cliente 789 se le puede dar equivocadamente un valor para el Teléfono 2 que es exactamente igual que el valor de su Teléfono 1.
  • La restricción de los números de teléfono por cliente a tres. Si un cliente tiene cuatro números de teléfono, estamos obligados a guardar solamente tres y dejar el cuarto sin guardar. Esto significa que el diseño de la base de datos está imponiendo restricciones al proceso del negocio, en vez de (como idealmente debe ser el caso) al revés.

 

Ejemplo

EJEMPLO

REPETICIÓN DE GRUPOS DENTRO DE COLUMNAS.

El diseñador puede, alternativamente, conservar una sola columna de número de teléfono, pero alterando su dominio, haciendo una cadena de suficiente longitud para acomodar múltiples números telefónicos:

 
  Éste es defendiblemente el peor diseño de todos, y otra vez no mantiene el espíritu de la 1NF. El encabezado "Teléfono" llega a ser semánticamente difuso, ya que ahora puede representar, o un número de teléfono, o una lista de números de teléfono, o de hecho cualquier cosa. Una consulta como "¿Qué pares de clientes comparten un número telefónico?" es virtualmente imposible de formular, dada la necesidad de proveerse de listas de números telefónicos así como números telefónicos individuales. Con este diseño en la RDBMS, son también imposibles de definir significativas restricciones en números telefónicos.

 

Un diseño conforme con 1FN

Un diseño que está completamente en 1FN hace uso de dos tablas: una tabla de cliente y una tabla de teléfono del cliente.

 

En este diseño no ocurren grupos repetidos de números telefónicos. En lugar de eso, cada enlace Cliente-a-Teléfono aparece en su propio registro. Es valioso notar que este diseño cumple los requerimientos adicionales para la segunda (2NF) y la tercera forma normal (3FN).

 

Ejemplo

EJEMPLO.

Un dato sin normalizar no cumple con ninguna regla de normalización. En base a los datos de la siguiente tabla, aplicaremos primera forma normal.

 
 

Al examinar estos registros, podemos darnos cuenta que contienen un grupo repetido para NUM_ITEM, DESC_ITEM, CANT y PRECIO. La 1FN prohíbe los grupos repetidos, por lo tanto tenemos que convertir a la primera forma normal. Los pasos a seguir son:

  • Tenemos que eliminar los grupos repetidos.
  • Tenemos que crear una nueva tabla con la PK de la tabla base y el grupo repetido.
Los registros quedan ahora conformados en dos tablas que llamaremos ÓRDENES y ARTICULOS_ORDENES.
 

- ORDENES

 

   
  - ARTICULOS_ORDENES
 

 

2.2.2. SEGUNDA FORMA NORMAL (2FN)

 Una tabla esta en segunda forma normal si esta en primera forma normal y además todos los atributos que no pertenecen a la clave dependen funcionalmente de forma completa de ella.

De esta definición se desprende que de una tabla en primera forma normal y cuya clave está compuesta por un único atributo está en segunda forma normal.

 El proceso de normalización es como sigue: 

A. Se crea a partir de la tabla inicial una nueva tabla con los atributos que dependen funcionalmente de forma completa de la clave (Que tendrán la misma clave  que la tabla inicial). Esta tabla ya está en segunda forma normal.

 B. Se crea una nueva tabla con los atributos restantes, siendo su clave el subconjunto de atributos de la clave inicial de los que dependen de forma completa.

 C. Se comprueba si esta tabla esta en segunda forma normal. Si es así, la tabla inicial ya está normalizada y finaliza el proceso. Si no, tomamos esta tabla como tabla inicial y volvemos a realizar el apartado A.

Las formas normales más arriba que la 1NF son pensadas para ocuparse de las situaciones en las que una tabla sufre de problemas de diseño que pueden comprometer la integridad de los datos dentro de ella. Por ejemplo, la tabla siguiente está en 1NF, pero no está en 2NF y por lo tanto es vulnerable a inconsistencias lógicas:

 

La clave de la tabla es {ID del subscriptor, Dirección de correo}.

Si Carol Robertson cambia su apellido por el de casada, el cambio debe ser aplicado a dos filas. Si el cambio es aplicado solamente a una fila, resulta en una contradicción: la pregunta "cuál es nombre del cliente 252?" tiene dos respuestas que están en conflicto. La 2NF aborda este problema.

Ejemplo

EJEMPLO.

Continuando con el ejemplo de la forma normal 1, ahora procederemos a aplicar la segunda forma normal, es decir, tenemos que eliminar cualquier columna no clave que no dependa de la llave primaria de la tabla. Los pasos a seguir son:

 
  • Determinar cuáles columnas que no son clave no dependen de la llave primaria de la tabla.
  • Eliminar esas columnas de la tabla base.
  • Crear una segunda tabla con esas columnas y la(s) columna(s) de la PK de la cual dependen.

La tabla ÓRDENES está en 2FN. Cualquier valor único de ID_ORDEN determina un sólo valor para cada columna. Por lo tanto, todas las columnas son dependientes de la llave primaria ID_ORDEN.
Por su parte, la tabla ARTICULOS_ORDENES no se encuentra en 2FN ya que las columnas PRECIO y DESC_ITEM son dependientes de NUM_ITEM, pero no son dependientes de ID_ORDEN. Lo que haremos a continuación es eliminar estas columnas de la tabla ARTICULOS_ORDENES y crear una tabla ARTICULOS con dichas columnas y la llave primaria de la que dependen.

Las tablas quedan ahora de la siguiente manera.

 

- ARTICULOS_ORDENES

 

- ARTICULOS

2.2.3. TERCERA FORMA NORMAL (3FN)

Una tabla esta en tercera forma normal si esta en segunda forma normal y además no existen atributos no claves que dependan transitivamente de la clave, es decir, no debe haber atributos no clave que dependan de otros atributos no primos (que no pertenecen a la clave). 

El proceso de normalización es como sigue: 

A. Se crea a partir de la tabla inicial una nueva tabla con los atributos que no poseen dependencias transitivas. (Que tendrán la misma clave  que la tabla inicial). Esta tabla ya está en segunda forma normal.

B. Se crea una nueva tabla con los atributos restantes, siendo su clave el subconjunto de atributos de la clave inicial de los que dependen de forma completa.

C. Se crea una nueva tabla con los dos atributos no clave, que intervienen en la dependencia transitiva, seleccionando entre ambos a aquel que cumpla los requerimientos de clave. Esta nueva tabla está ya en tercera forma normal.

Ejemplo

EJEMPLO.

La tercera forma normal nos dice que tenemos que eliminar cualquier columna no llave que sea dependiente de otra columna no llave. Los pasos a seguir son:

  • Determinar las columnas que son dependientes de otra columna no llave.
  • Eliminar esas columnas de la tabla base.
  • Crear una segunda tabla con esas columnas y con la columna no llave de la cual son dependientes.
   

Al observar las tablas que hemos creado en el ejemplo que hemos tomado como modelo, nos damos cuenta que tanto la tabla ARTICULOS, como la tabla ARTICULOS_ORDENES se encuentran en 3FN. Sin embargo la tabla ÓRDENES no lo está, ya que NOM_CLIENTE y ESTADO son dependientes de ID_CLIENTE, y esta columna no es la llave primaria.

Para normalizar esta tabla, moveremos las columnas no llave y la columna llave de la cual dependen dentro de una nueva tabla CLIENTES. Las nuevas tablas CLIENTES y ÓRDENES se muestran a continuación.
 

- ORDENES

 

- CLIENTES

2.2.4 FORMA NORMAL DE BOYCE Y CODD (FNBC)

 Una relación está en FNBC si lo está en 3FN y si además el conocimiento de las claves permite averiguar todas las relaciones existentes entre los datos de la relación. Las claves candidatas deben ser los únicos descriptores sobre los que se facilita información por cualquier otro atributo. Cada determinante (atributo con el cual otro atributo tiene dependencia funcional total) debe ser una clave candidata. Se eliminan claves candidatas compuestas que se solapan. No siempre es posible transformar un esquema de relación en FNBC sin que se produzca pérdida de dependencias funcionales. Sí se puede hacer sin pérdida de información.

2.2.5 DEPENDENCIAS MULTIVALUADAS Y 4FN

Una tabla está en cuarta forma normal si y sólo si para cualquier combinación clave - campo no existen valores duplicados. Veámoslo con un ejemplo:

Comparemos ahora la clave (Figura) con el atributo Tamaño, podemos observar que Cuadrado Grande está repetido; igual pasa con Círculo Azul, entre otras. Estas repeticiones son las que se deben evitar para tener una tabla en 4NF.La solución en este caso sería la siguiente:

Ahora si tenemos nuestra base de datos en 4NF.