La Tercera Forma Normal (se abrevia: 3FN) nos dice que para estar en 3FN una tabla debe:

  1. Estar en la 2FN
  2. No tener dependencias transitivas

Se dice que una dependencia es transitiva si una columna depende de otra/s columna/s que no son Primary Key ni de la tabla actual ni de alguna otra tabla.

Ejemplo 1.

Esta tabla no está en la 3FN.

3FN1

Captura 1. Si haces clic en la imagen la verás más grande

3FN2

Captura 2. Si haces clic en la imagen la verás más grande

¿Cuál es el problema? ¿Por qué no está en la 3FN? Porque la columna EMP_TOTALX depende de otras columnas que no son Primary Key, ni de esta tabla ni de alguna otra tabla:

EMP_TOTALX = EMP_SALBAS + EMP_BONIFI – EMP_DESCUE

Como puedes ver, el valor de la columna EMP_TOTALX se halla sumándole al Salario Básico del empleado sus Bonificaciones (o sea el dinero que tiene a su favor) y restándole sus Descuentos (o sea el dinero que tiene en su contra). Por lo tanto no se necesita que exista la columna EMP_TOTALX ya que su valor puede ser fácilmente calculado en un SELECT.

SELECT
   EMP_IDENTI,
   EMP_NOMBRE,
   EMP_APELLD,
   EMP_SALBAS,
   EMP_BONIFI,
   EMP_DESCUE,
   EMP_SALBAS + EMP_BONIFI - EMP_DESCUE AS SALARIO
FROM
   EMPLEADOS

3FN3

Captura 3. Si haces clic en la imagen la verás más grande

Como ves, pudimos calcular el Salario final del Empleado sin necesidad de usar la columna EMP_TOTALX. Eso significa que la columna EMP_TOTALX está de más, está sobrando, es innecesaria, es inútil.

NOTA: Tampoco esta es la manera adecuada para registrar los pagos de sueldos, es solamente un ejemplo para mostrar que la columna EMP_TOTALX no era necesaria y por lo tanto la tabla EMPLEADOS no cumplía con la 3FN.

Ejemplo 2.

Esta tabla no cumple con la 3FN.

3FN4

Captura 4. Si haces clic en la imagen la verás más grande

3FN5

Captura 5. Si haces clic en la imagen la verás más grande

Como puedes ver, esta tabla tampoco cumple con la 3FN. ¿Por qué no? Porque la columna MOV_TOTALX es el resultado de multiplicar el valor de la columna MOV_CANTID por el valor de la columna MOV_PRECIO. Eso implica que la columna MOV_TOTALX es redundante, está sobrando, es innecesaria, es inútil.

Ejemplo 3.

En una tabla se guardan los despachos aduaneros. Uno de los impuestos a pagar es del 2% del total de la mercadería importada. ¿Debemos tener una columna con el importe que corresponde a ese 2%? No, porque el valor de ese impuesto puede ser calculado. ¿Y si el porcentaje del impuesto varía más adelante? Porque sabemos que los gobiernos tienen la mala costumbre de alzar los porcentajes de los impuestos. No importa, porque podemos tener dos tablas para los impuestos: cabecera y detalle.

Impuestos cabecera

Identificador

Nombre del impuesto

Impuestos detalle

Identificador

Identificador de la cabecera

Vigente desde el día

Vigente hasta el día

Porcentaje a pagar

De esta manera, guardamos el “Identificador” del impuesto, no el “Importe” del impuesto. Trabajamos más, sí, es cierto, pero también tenemos nuestras tablas mucho mejor diseñadas e inclusive podemos responder preguntas como ¿ése impuesto cuándo estuvo en vigencia? ¿cuál era el porcentaje de ese impuesto hace 2 años?

Conclusión:

Nunca debes tener en tus tablas columnas que no sean estrictamente necesarias. Si el valor de una columna puede hallarse mediante otras columnas de esa misma fila entonces esa columna está sobrando, está de más, es redundante, es innecesaria, es inútil. Y debes eliminarla para cumplir con la 3FN.

Artículos relacionados:

Consideraciones a tener en cuenta al diseñar una Base de Datos

Diseño de bases de datos. 1FN

Más ejemplos de tablas que no cumplen con la 1FN

Diseño de bases de datos. 2FN

El índice del blog Firebird21