Curso de Introducción a SQL Server 2005

Las normas que debemos aplicar en la primera forma normal son muy básica y sencillas.

Esta regla que hemos anunciado puedes encontrarla con la definición de la regla de datos atómicos o indivisibles.

Para entender mejor el significado de esta regla, vamos a explicar como podríamos quebrantarla. En la tabla que acabamos de presentar, vemos que estamos guardando los datos del fabricante y de la distribuidora en dos campos diferentes. Un modo de saltarnos la regla de la forma normal A, es guardar el nombre del fabricante y el nombre de la distribuidora en un único campo. De este modo no estamos cumpliendo la norma, ya que estamos guardando información de diferentes características en un único campo.

Otra manera de no cumplir la regla que estamos viendo es la repetición de un campo. Esta técnica es muy común en administradores que se están iniciando en el desarrollo de bases de datos.

Vamos a poner un ejemplo de este error tan común. Nos situamos de nuevo en nuestra tabla, ahora imaginamos que una bebida puede ser recibida en diferentes envases: lata, vidrio... El desarrollador puede pensar, como tenemos varias opciones de envase para una misma bebida, la forma más sencilla de cubrir esta información es tener los siguientes campos en la tabla: envase_A y envase_B. De este modo parece lógico que podemos guardar dos tipos de envases para cada bebida.

Este tipo de soluciones provoca bastantes problemas, el principal causante de estos problemas es la poca flexibilidad que nos ofrece esta estructura. Nuestra tabla dejará de cumplir con nuestras necesidades en el momento en que una bebida nos llegue con más de un tipo de envase, hemos nombrado como posibles envases lata y vidrio, pero también podrían llegar como plástico, por citar un ejemplo. Por lo tanto esta estructura lejos de ser sencilla es muy compleja, es imposible definir en un principio  los diferentes tipos de envases que debemos controlar. Ahora podemos pensar, pues vamos a poner suficientes campos de modo que nuestras necesidades nunca superen ese número de campos. Como ya imaginarás, tomar este tipo de soluciones es una error enorme. Esteremos reservando memoria sin ninguna necesidad, muchas bebidas vendrán en un sólo tipo de envase y tendremos campos vacíos que resultarán completamente inútiles.

Para solucionar el problema que hemos planteado como ejemplo, tenemos varias soluciones, como almacenar la misma bebida en diferentes registros de nuestra tabla, un registro por cada tipo de envase. Esta es una solución válida, pero muy poco o nada eficaz desde el punto de vista del rendimiento. La mejor solución es sacar "fuera" una tabla con los tipos de envase llamada Tipos_Envase por ejemplo y utilizar la integridad referencial para relacionarla con la tabla Bebidas.

Para aplicar la forma normal A, debemos pensar en que actividad vamos a realizar en la tabla, campos por los que vamos a ordenar, como vamos a recoger sus registros, si los vamos a agrupar, etc...

La tabla que hemos presentado al principio podemos decir que cumple la primera forma normal, ha excepción del caso que tengamos varios tipos de envases. Vamos a suponer que sólo nos llegan las bebidas en un único tipo de envase.

Si nos fijamos en los registros, vemos que tenemos información que se repite:

Hemos resaltado en naranja algunos de los datos que se repiten.  Vemos que la distribuidora Enterlin se repiten para las bebidas Pacharán La Navarra Etiqueta Verde y para Pacharán Endrinas. Si se diese el caso de que la empresa contrata otra distribuidora para la entrega de pacharán, tendríamos que actualizar los dos registros. Esto puede provocar un fallo al realizar las actualizaciones si pasamos por alto uno de los registros, ya que tendríamos datos incoherentes. Por lo tanto tendremos que mejorar nuestra normalización.

Una clave principal contiene información de un registro de tal modo que gracias a esa información podamos distinguir ese registro de todos los demás, visto de otro forma, la información de la clave principal hace a un registro único e irrepetible en una tabla.

Un clave principal puede estar compuesta por una o varias columnas. En caso de estar formada por varias columnas es requisito indispensable que ninguna de esas columnas tenga información repetida en un mismo registro.

Como ya hemos visto, la clave principal garantiza la integridad de entidad en una tabla.

En una tabla podemos tener varias columnas que puedan formar parte de una clave principal, estas columnas reciben el nombre de claves candidatas. La función del administrador de la base de datos es definir estas claves candidatas como primer paso, para más adelante decidir de entre todas las claves candidatas cuales finalmente formarán parte de la clave principal. En nuestra tabla tenemos varios conjuntos de claves candidatas:

• Nombre
• nombre, fabricante
• nombre, fabricante, distribuidora

En cualquier tabla, podemos encontrar más de un grupo de claves candidatas. Veamos como seleccionar la clave principal más válida posible.

Para una correcta elección de la clave principal tenemos una serie conceptos que nos ayudan:

• Actividad: Una buena clave principal puede ser aquella que tiene una información a la que los usuarios pueden acceder con facilidad, o que de la que tienen mayor conocimiento. Un buen ejemplo de este caso puede ser los números de factura.
• Sencillez: Hemos explicado que una clave principal puede tener varias columnas. La mejor opción es tratar de que el número de columnas que forman la clave principal sean las menos posibles. Si una clave principal es válida con dos columnas, añadir más columnas no incremente la exclusividad de la clave principal (si es exclusiva con dos, será imposible aumentarla), lo único que provocamos si añadimos más columnas es bajar el rendimiento de las operaciones que se realicen con ellas.
• Permanencia:  Una columna que pertenezca a una clave principal debe ser constante, es decir su valor no puede ser modificado o actualizado. Las claves principales juegan un papel importante en la relaciones entre tablas, y se supone que estas relaciones deben ser administradas con los valores de las claves principales, por lo tanto si permanecen constantes, ganaremos mucho en estabilidad.

En una base de datos, nos podemos encontrar tablas de las cuales no podemos encontrar ninguna columna que sea clave candidata a formar una clave principal. Para cumplir con la forma normal A del proceso de normalización debemos incluir una clave principal como mínimo en nuestras tablas. La única solución que nos queda si se nos presenta una tabla de este tipo es incluir una columna extra en nuestra tabla, la cual no almacena información que defina la información que almacenamos, pero tiene la importante tarea de ser la clave principal que distinga un registro del resto, cumpliendo con la integridad de entidad, y nos ayude con las relaciones.

Por ejemplo podemos tener una agenda de teléfonos, con los campos nombre, teléfono y dirección. Esta persona puede cambiar de teléfono, dirección y hasta si nos ponemos drásticos, incluso de nombre. Solucionamos el problema añadiendo un campo con un número para cada uno de los contactos que tenemos en esta tabla, y el problema queda resuelto. Como vemos, este problema es muy frecuente en nuestras tablas y es una solución muy cómoda, incluso para tablas en las que dudemos que sus campos puedan cumplir con los tres conceptos que hemos definido para ayudarnos con la selección de claves principales.

La primera condición que debemos cumplir en la forma normal B, es que se cumplan las reglas que hemos fijado en la forma normal A.

La principal regla de esta segunda norma es:

Como hemos hecho antes, vamos a entender mejor estas condiciones, explicando como quebrantarlas. En nuestra base de datos de ejemplo, teníamos entre otras entidades los fabricantes y las distribuidoras. Para ambas entidades podríamos desear almacenar el nombre, la dirección y la ciudad. El primer error que podemos cometer como diseñadores de la base de datos es decidir que tanto los fabricantes como las distribuidoras pueden ser almacenadas en una misma tabla llamada Fabricantes_Distribuidoras. Esta decisión errónea la tomamos por el hecho de que ambas entidades comparten los mismos campos.

Esta decisión incumple la regla de la forma normal B que nos exige tener estas entidades en diferentes tablas, en caso de hacer caso omiso a esta regla nos encontraremos varios problemas. En el ejemplo que hemos tomado, tendríamos problemas para devolver la información de todos los fabricantes por un lado y por otro la de las distribuidoras.

Observa los datos de la siguiente tabla:

Esta tabla plantea el mismo problema que hemos identificado anteriormente si almacenamos los fabricantes y las distribuidoras en la misma tabla. Observa que entre otras cosas, estamos almacenando información relativa a las bebidas y del fabricante, en una misma tabla.

Los campos fabricante y localidad_fabricante, almacena información relativa a la entidad Fabricante, que no depende en ningún caso con la entidad Bebida. La solución separarlo en dos tablas, quedando del siguiente modo:

Separamos las entidades en dos tablas y cumplimos con la segunda forma normal. Si observamos los registros de las dos tablas, vemos que la información de la tabla original permanece una vez desglosada en dos tablas. Incluso vemos que tenemos información que se repite. Recuerda que el proceso de normalización no consiste en minimizar el espacio de la base de datos, sino de mejorar el rendimiento y la funcionalidad.

Vamos a definir las claves principales de estas dos tablas:

Tabla bebidas:

Tabla Fabricantes:

Hemos destacado en rojo las columnas que forman la clave principal de la primera tabla :nombre y fabricante, y en la segunda: fabricante.

Cuando dividimos una tabal en varias, como este caso, debemos ser capaces de combinar estas tablas para poder recoger los datos originales como si de una única tabla se tratara. Para ello, lo primero de todo buscamos un dato común que nos permite identificar uno (relación uno a uno) o varios (relación uno a varios) registros de una tabla a partir de un registro de la otra.

En nuestro caso el campo común es el nombre del fabricante.

El fabricante es la clave principal de nuestra tabla Fabricantes, y su correspondiente en la tabla Bebidas es la clave externa o foránea.

Cuando hemos identificado una clave externa y su correspondiente clave principal, nuestro servidor de base de datos es capaz de definir la integridad referencial que relacionan las dos tablas.

Ya conocemos las relaciones uno a varios y uno a uno, en función de los registros que se devuelven a partir de uno. Es posible crear relaciones varios a varios mediante una tercera tabla "auxiliar" que ayude a conectar dos tablas.

Para cumplir con la forma normal c debemos cumplir la forma normal B y la siguiente regla:

La definición de esta regla puede parecer complicada, pero es tan sencilla como cualquiera de las que hemos visto, o incluso más.

Una vez más, la explicamos comprobando como quebrantarla.

Observa la siguiente tabla Pedidos:

El camino más corto para cometer errores y no cumplir con esta tercera forma normal son los campos calculados. En la tabla, hemos incluido un campo Total que almacena el total de un pedido. Pero este campo es innecesario, ya que somos capaces de llegar a esa información a partir de los campos unidades y precio, en cualquier momento.

No debemos pensar, que este error que estamos cometiendo se limita a que almacenamos información extra y ocupamos espacio sin tener necesidad de ello. Además de esto, podemos tener problemas de coherencia, si por ejemplo modificamos las unidades del producto cuaderno y no recalculamos el valor del campo Total. Por lo tanto, debemos asegurarnos de que los campos de nuestras tablas son necesarios, y que no pueden ser obtenidos a partir de otros campos.

Otra característica importante de esta forma normal, es que es una gran ayuda para identificar que tablas deben ser divididas en otras a partir de la regla que nos exige que cada tabla sólo guarde información referente a una entidad.