La forma normal cero

En muchas oportunidades me preguntan sobre las consideraciones que deben tomarse en cuenta al diseñar una base de datos. Respondo que antes del diseño de base de datos, el correcto levantamiento de requerimientos ayuda a minimizar los ciclos de diseño, desarrollo, pruebas e implantación de sistemas.

Luego agrego que suponiendo que los requerimientos están correctamente levantados y validados,  la consideración más importante para el diseño de bases de datos es la normalización de la misma. Aunque esto es lo adecuado, muchos programadores dejan a un lado la normalización y optan por un esquema con menos tablas que minimice la complejidad de las consultas y mejore el rendimiento de éstas.

Ahí comienzan los problemas.

Una tabla con muchos campos presentará columnas que aceptan valores nulos ya que dependiendo de la aplicación, algunos datos son requeridos para cierto tipo de registros y no requeridos para otro. Esto no sólo es problemático sino que genera un crecimiento importante de la base de datos. Además, si las reglas del negocio cambian, seguramente habrá que agregar nuevos campos y modificar las aplicaciones para que actualicen los mismos.

Definitivamente, es necesario normalizar la base de datos.

En esta oportunidad hablaré sobre una condición que no está documentada y que muchas veces no es tomada en cuenta: 

La forma normal cero. 

Ésta posee las siguientes condiciones:

• Todas las tablas deben tener una clave primaria. Esto es una característica del modelo relacional: Una tabla debe tener un discriminador que distinga sin ambigüedades un registro del resto. Si la clave primaria no existe no sólo será imposible diferenciar los registros sino que tampoco será posible relacionarlos correctamente con otras tablas.
• Los atributos primos deben ser numéricos. Desde el punto de vista computacional, la comparación y almacenamiento de números es más eficiente que la de caracteres, por lo tanto la búsqueda de registros cuya clave es numérica es más veloz que aquella que se ejecuta con una clave alfanumérica.  Otro motivo para preferir claves numéricas es que estructuras especiales como los índices son más compactos cuando están formados por este tipo de claves.
• Las claves no deben poseer atributos redundantes. Una clave debe ser simple o tener la mínima cantidad de atributos. Otra manera de decir esto es que la clave debe ser irreducible. Una clave irreducible es aquella que al quitarle cualquiera de sus atributos pierde la propiedad de identificar registros sin ambigüedad.
• Las claves no deben cambiar sus valores constantemente.  Considere que un registro de una tabla A está relacionado con 10.000 registros de una tabla B.  Si los valores de la clave en A cambian constantemente, se deben hacer cambios en los 10.000 registros de la tabla B.  Aunque un gestor de bases de datos puede realizar esto de manera eficiente, en sistemas con usuarios concurrentes el tiempo de respuesta puede ser prohibitivo.
• Las claves deben ser «familiares» o «fáciles de recordar»: Las claves deben poseer atributos que tengan sentido para los usuarios.  Considérese por ejemplo la identificación de automóviles.  Es sabido que existen varios atributos que tomados en forma independiente identifican un registro de otros: número de matrícula, serial del motor y serial de carrocería, los cuales de manera independiente identifican sin ambigüedad a los registros; sin embargo para un usuario es más sencillo recordar la matrícula de un automóvil (seis a ocho letras y números combinados) que el serial del motor o de la carrocería (por lo menos 15 caracteres y números).

Aunque esta forma normal no está completamente documentada, sí está mencionada en los documentos originales del modelo relacional propuesto por E. F. Codd, donde el autor menciona las características que los diseños de bases de datos deben tener. 

Un texto donde puede consultarse sobre éste y otros aspectos de la normalización de base de datos es la obra de C. J. Date «The Database Relational Model: A Retrospective Review and Analysis» el cual despliega un recorrido histórico sobre el modelo relacional de datos.