Primera Forma Normal (1FN)

 Una tabla se considera en 1FN si:

1. La tabla contiene una clave principal.
2. La clave principal no contiene atributos nulos. Esto lo hemos analizado en la unidad anterior, es fundamental que cuando determinamos que una campo será la clave de la tabla tengamos presente que éste dato no podrá quedar nunca sin completar.

3.   Todos los atributos son atómicos. Un atributo es atómico si los elementos del dominio son indivisibles, mínimos. Dicho de otro modo, una tabla no puede tener múltiples valores en cada.

Por ejemplo, si deseáramos almacenar qué proveedores nos suministran los productos con los cuales trabajamos, podríamos pensar en registrarlo del siguiente modo:

   

(*)Código de Producto	Descripción	Precio Unitario	…	Proveedor
12332480	Tarugos 8”	1,20		1013; 1027; 2189

Este diseño, que registra más de un Número de Proveedor en la misma columna para un producto, no es eficiente. No respeta la 1FN. ¿Cuál sería el inconveniente? Pensemos qué sucederá cuando queramos relacionar este campo Número de proveedor con el existente en la tabla Proveedores, para poder saber su Razón Social; la búsqueda sería imposible ya que el SGBD tomará la cadena de caracteres “1013; 1027; 2189” como un único contenido, no pudiendo localizar quién es exactamente el proveedor 1013.

4. No debe existir variación en el número de columnas.

Siguiendo con el ejemplo anterior, esta condición se refiere por ejemplo, a registrar a los distintos proveedores del siguiente modo:

(*)Código de Producto	Descripción	Precio Unitario	…	Proveedor
12332480	Tarugos 8”	1,20		1013	1027	2189	….

            Pensar una tabla con la idea de tener “Celdas combinadas” no es un diseño viable en Base de Datos normalizadas.

5. No deben existir grupos repetidos en diferentes columnas.

Del mismo modo, deberemos evitar registrarlo de la siguiente manera:

(*)Código de Producto	Descripción	Precio Unitario	…	Prov. 1	Prov. 2	Prov. 3
12332480	Tarugos 8”	1,20		1013	1027	2189	…

  

6. Debe existir una independencia del orden tanto de las filas como de las columnas. Lo cual implica que si cambiáramos el orden de los registros o de visualización de los campos, éstos no debieran cambiar sus significados.

Para el ejemplo presentado, un diseño correcto que respetaría la 1FN sería el que relaciona la tabla Productos con la tabla Proveedores utilizando una tercera tabla (como se mencionara en la Unidad 1, llamada, tabla Unión), en la cual figuren los campos claves de las tablas a relacionar, lo que definiría el siguiente diseño:                                                                                                                                                                                                Tabla Productos

(*)Código de Producto	Descripción	Precio Unitario	…
12332480	Tarugos 8”	1,20

                                              Tabla Proveedores

(*)Número de Proveedor	Razón Social	CUIT	…
1013	Zuniga Hnos. SA	27-33333333-1

                                              Tabla Producto-Proveedor

(*)Código de Producto	(*)Número de Proveedor	Precio de Costo	…
12332480	1013	0,25
12332480	1027	0,30
12332480	2189	0,20

(*) Representa el campo clave.

De este modo, repitiendo solamente los campos claves en la nueva tabla podremos registrar todas las combinaciones posibles: un mismo producto suministrado por varios proveedores y un mismo proveedor  que suministra varios productos.

Para evitar la inconsistencia de cargar dos veces el mismo producto con el mismo proveedor (con el riesgo de registrar Precios de costo diferentes), deberemos indicar que nuestra tabla tiene una clave múltiple conformada por el Código de Producto y el Número de Proveedor.