Primera forma normal

La primera forma normal nos indica que los elementos de una tabla deben ser atómicos, es decir, que no acepten descomposición. Otra forma de ver esto es que dentro de una tabla no debe haber arreglos.

Aunque no tiene sentido definir un arreglo dentro de una tabla (Hacer esto en SQL estándar no es apropiado ni viable), muchos programadores se las arreglan para simular esto. Otros programadores más audaces introducen campos que almacenan varios datos. Mostraré  un ejemplo de cada situación:

• Arreglos en tablas: Expondré un caso con el que recientemente tuve que lidiar: Una tabla almacena los datos de un producto como nombre, código y fabricante. Además de esto, almacena los distintos precios a los que el producto se vende. Seguidamente se muestra dicha tabla.

CREATE TABLE PRODUCTO (
PRODUCTO_ID INTEGER NOT NULL PRIMARY KEY,
CODIGO_INTERNO CHAR (20) NOT NULL UNIQUE,
DESCRIPCION VARCHAR (128) NOT NULL,
PRECIO_A NUMERIC (10.2) NOT NULL,
PRECIO_B NUMERIC (10.2) NULL,
PRECIO_C NUMERIC (10.2) NULL,
PRECIO_D NUMERIC (10.2) NULL)

• Campos que almacenan varios datos: En este caso, el campo CODIGO_INTERNO de la tabla anterior contenía la siguiente información.

Caracteres 1 al 5: Número del fabricante.
Caracter 6: Una raya.
Caracteres 7 al 11: Tipo del producto.
Caracter 12: Una raya.
Caracteres 13 al 20: Otros datos internos de la organización.

• Algunas consideraciones importantes:

1. El cliente manejaba un stock de 223.000 piezas distintas.
2. Había una tabla de fabricantes.
3. Había una tabla de tipos de producto.

Algunos productos podían tener el primer campo de precio vacío y algunos de los otros campos de precio con algún valor. Como el primer campo de precio era requerido (NOT NULL), se llenaba este campo con valor cero cuando este campo debía estar vacío.

En el primer caso (Arreglos en tablas) se me contrató para resolver los siguientes problemas:

• Averiguar por qué la tabla de productos crecía tan rápido.
• Modificar las aplicaciones para que aceptara una mayor cantidad de precios por producto.
• Mejorar los reportes de precios de producto.

En el segundo caso (Campos que almacenan varios datos), el cliente quería mejorar los siguientes elementos:

• Que el sistema no pudiera eliminar o modificar fabricantes o tipos de productos que tuvieran registros relacionados en la tabla de productos.
• Mejorar los tiempos de respuestas de los reportes de productos discriminados por tipo y por fabricante.

Con el esquema de datos proporcionado por el cliente, la tarea implicaba reconstruir las tablas de productos ya que:

• La cantidad de precios por producto era variable: en algunos casos los productos podían tener un precio, en otros casos los productos podían tener tres o cuatro precios. Muy pocos productos tenían cinco precios. En menor cantidad, los precios podían ser siete u ocho por producto. Solución: Se construyó una tabla de precios vinculada con la tabla de productos. En esta nueva tabla se insertan tantos registros como precios tenga el producto.
• No era posible crear una integridad referencial entre la tabla de fabricantes y tabla de tipos con la tabla de productos ya que no existían campos foráneos en esta última. Solución: El campo CODIGO_INTERNO se dividió en los campos necesarios para poder realizar la integridad referencial con las tablas de fabricantes y tipos de producto.