La Segunda Forma Normal (se abrevia: 2FN) nos dice que para estar en la 2FN una tabla debe:

  1. Estar en la 1FN
  2. Todas las columnas que no sean parte de la Primary Key deben depender de toda la Primary Key, no solamente de una parte de la Primary Key
  3. Ninguna columna debe depender de otra/s columna/s. Solamente debe depender de la Primary Key y de nada más.

Como vemos, la 2FN depende de la 1FN ya que solamente las tablas que ya están en la 1FN pueden llegar a estar en la 2FN.

Además, si la Primary Key está compuesta por solamente una columna autoincremental, la tabla casi siempre ya está automáticamente en la 2FN.

Es por eso que en mis artículos siempre insisto en que la Primary Key debe estar compuesta por solamente una columna autoincremental. La excepción es cuando necesitarás hacer replicación, en ese caso podría estar compuesta por dos columnas: Código de la Sucursal y Columna autoincremental.

Por lo tanto, mis consejos son:

Si no necesitarás replicación:

La Primary Key debe estar compuesta por solamente una columna autoincremental

Si necesitarás replicación:

La Primary Key puede estar compuesta por dos columnas: CódigoSucursal + ColumnaAutoIncremental

Ejemplo de una tabla que no cumple con la 2FN

2FN1

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

¿Cuáles son los errores de diseño de esta tabla?

  1. En la columna PRD_NOMPRO se guarda el “Nombre del Proveedor” y en esa columna debería guardarse el “Identificador del Proveedor”. Recuerda que todo lo que puede identificarse mediante una Primary Key debe identificarse con una Primary Key.
  2. En la columna PRD_PAISXX se guarda el país de procedencia del producto pero ese dato debería guardarse en otra tabla. ¿Por qué está mal aquí? porque está dependiendo de la columna PRD_NOMPRO y la columna PRD_NOMPRO no es la Primary Key de esta tabla. Y según la condición 3 de la 2FN (mira arriba, al principio de este artículo) eso no está permitido.

El diseño correcto implica tener 3 tablas:

  1. PROVEEDORES (Identificador, Nombre, etc.)
  2. PRODUCTOS (Identificador, Nombre, etc.)
  3. PRODUCTOS_X_PROVEEDOR(Identificador, Identificador del Proveedor, Identificador del Producto, Precio de Costo, etc.)

En el caso de que los Proveedores nos provean de productos únicos, es decir que ningún Proveedor nos provea el mismo Producto que otro Proveedor entonces necesitaríamos solamente dos tablas: PROVEEDORES y PRODUCTOS, y los datos de la tabla PRODUCTOS_X_PROVEEDOR (Identificador del Proveedor, Precio de Costo, etc.) estarían incluidos en la tabla de PRODUCTOS.

Verificando si todas las tablas están en la 2FN

Cuanto antes verifiques que todas las tablas de tu Base de Datos cumplen con la 2FN, mucho mejor.

Para cada una de las tablas deberás preguntarte:

  • ¿Tiene una Primary Key autoincremental?
  • ¿Hay alguna columna que dependa de otra columna y esa otra columna no es la Primary Key?

Conclusión:

Como habrás notado, cuando normalizamos las tablas trabajamos más, pero en contrapartida nuestro diseño mejora mucho y nos ahorraremos muchísimo trabajo más adelante porque al normalizarlas estamos evitando una gran variedad de problemas. En nuestro ejemplo, supongamos que el Proveedor “LA GRAN CONTINENTAL S.A.” decide mudarse a Chile. Si tenemos nuestras tablas normalizadas entonces ese cambio de país se guarda una sola vez y en una sola tabla. Si no las tenemos normalizadas deberemos guardar el nombre del nuevo país en muchísimas filas de quizás varias tablas, con el riesgo de olvidarnos de alguna y tener así datos inconsistentes.

Por lo tanto, si normalizas tus tablas trabajarás más … pero tarde o temprano valdrá la pena haber hecho ese trabajo.

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

El índice del blog Firebird21