Digamos que tenemos una base de datos con los datos de ciudadanos para algún tipo de registro. A saber, los usuales: nombre(s), apellidos, dirección, teléfono, lugar y fecha de nacimiento, nivel socio económico estratificado, etc. y como dato adicional tenemos el RFC. Pero, en este caso, podríamos calcular la primera parte del RFC, es decir los primeros diez dígitos y almacenar sólo los últimos tres, que conforman la homoclave. Aún más, si contamos con el algoritmo empleado por la Secretaría de Hacienda y Crédito Público4.1, podríamos incluso no almacenar los tres últimos carácteres.
Ahorraríamos mucho espacio, trece carácteres por persona, que si almacenamos un millón de personas, significa casi trece megabytes4.2. Pero debemos de tener en cuenta que esta ganancia nos pegaría en cuanto a tiempo de respuesta en caso de que el campo RFC sea empleado contínuamente.
Digamos que a la rapidísima función que hackeamos anoche y lo calcula, le toma tan sólo una centésima de segundo, es decir, cada segundo calculamos cien RFC. Cada consulta sobre toda la tabla que utilice el RFC tomaría del orden de 36 horas. El costo de los discos duros es realmente barato ¿no? Vale más tener tiempo libre para ir al cine que esperar tanto ¿no?.
Ahora veamos el caso contrario, el gasto en tiempo de acceso. Obviamente es más rápido tener juntos todos los atributos, es decir, tener en un sólo registro todos los campos que necesitaremos acerca del objeto. Entonces ¿por qué romper en varias tablas si podemos tenerlo todo en una sola?
Supongamos que tenemos la base de datos del Registro Estatal Vehicular de Cuévano (REVC) de, digamos, un millón de vehículos. Entre las restricciones del sistema, sabemos que una persona puede tener varios vehículos registrados a su nombre.
Como tenemos un número grande de combinaciones entre los factores de modelo de vehículo, marca, color, número de puertas, si está o no equipado, etc., probablemente esta supera al número de vehículos que tenemos registrados.
Entonces, ¿qué pasa si decidimos que el registro para cada auto también lleva el registro del dueño con todos los datos?
Por el ejemplo anterior, extrapolando de tiempo de generación a tiempo de acceso, podemos llegar a la conclusión de que esto no es tan grave, porque a final de cuentas, lo más probable es que la mayoría de las personas sólo tengan un vehículo y poco probable que una persona tenga más de diez, por decir un número4.3.
Sabemos que una vez al año haremos una corrida secuencial sobre el total de los registros para generar las ordenes de pago de impuestos de tenencia. Entonces, el tamaño de cada registro importa, porque no es lo mismo leer ocho registros de un kilobyte en cada paso que dos de cuatro kilobytes. Pero el resto del tiempo, las búsquedas sólo serán individuales. Por supuesto, tenemos indices, llegamos directo al registro buscado.
Ahora bien, al REVC se le encarga también llevar el registro de licencias de conducir y de infracciones. Comienzan los problemas. Obviamente la mayoría de los poseedores de una licencia, son también propietarios de vehículos y viceversa4.4, de tal manera que entre la tabla de vehículos y la de licencias ya tenemos información duplicada. Y por supuesto, no tiene sentido almacenar en la tabla de infracciones el nombre y dirección del infractor, porque o bien el infractor tiene licencia o bien el dueño del vehículo es el responsable así que tenemos la manera de llegar hasta él por una de estas dos tablas.
Ahora bien, ¿qué pasa si pese a esto mantenemos la información de los ciudadanos en las dos tablas, de licencias y de control vehicular?
Un movimiento frecuente en vehículos es el de cambio de propietario. Por simplicidad diremos que la gran mayoría de los cambios son dentro del estado. Entonces si Perengano compra un auto nuevo y le vende el viejo a Sutano que da de baja el suyo, el REVC debe de copiar los datos de Perengano al nuevo vehículo, los de Sutano al nuevo y del vehículo viejo de Sutano, sólo examinamos que no adeude infracciones y lo pasamos a una tabla histórica. Pero estos cambios pueden llevar consigo errores de captura que nos dejan con una base de datos inconsistente, cuando puede ser que los datos anteriores fueran correctos.
Luego de esta pequeña disgresión esperamos que quede claro porque es importante evitar la redundancia y mantener la integridad de la información.