Lavado de datos sucios

Dos problemas han estado ocupando la mayor parte de mi tiempo este mes: uno fue con el diseño de la base de datos (falta de) y el otro fue con el mapeo. El problema de la base de datos surgió cuando uno de nuestros clientes decidió que era hora de prestar la atención que tanto necesitaba a su aplicación de línea de negocio. Esta aplicación comenzó como un solo archivo MDB de Access, pero luego se dividió en dos archivos MDB de Access: uno para los datos y otro que contiene la interfaz de usuario. Por último, las tablas de datos se actualizaron a SQL Server, dejando solo el front-end en Access.

Lavado de datos sucios

Los problemas de este sistema eran innumerables, pero las personas que lo usaban realmente no podían verlos. Hubo discrepancias en el tipo de datos y la longitud; texto contenido en secuencias de clasificación no estándar; casi ninguna relación definida; y no hay valores predeterminados sensibles para ningún campo. El front-end de Access funcionó, pero nadie quería hacerle más cambios porque se estaba volviendo cada vez más frágil. Parches sobre parches, consultas sobre consultas, un laberinto bizantino de formularios y subformularios, macros y código VBA hacían demasiado difícil predecir cuánto tardaría incluso un pequeño cambio y casi imposible evitar consecuencias no deseadas. Por lo tanto, para poder generar informes adicionales, la empresa ahora recurrió a SQL Server Reporting Services y está viendo las tablas de datos sin procesar en todo su esplendor: una experiencia reveladora e incluso deslumbrante.

Aunque no había relaciones definidas en la base de datos, había relaciones implícitas en los nombres de campo, los datos y dentro del front-end. Desafortunadamente, sin embargo, a veces los datos relacionados se almacenaban como un número entero en una tabla y como caracteres en la otra. En otros lugares, estos mismos datos se almacenaban como nvarchar(50) o nvarchar(100), según la tabla que estuviera consultando. (Las columnas Nvarchar contienen texto Unicode de longitud variable hasta el número máximo de caracteres definido entre paréntesis). Siempre que el front-end de Access copiaba datos de un nvarchar(100) a un nvarchar(50), era posible que todos los caracteres más allá del 50 se truncaría sin previo aviso.

Ahora bien, si los tipos de datos y las longitudes no coinciden, SQL Server le impide definir relaciones entre las columnas, por lo que todos estos problemas debían solucionarse antes de que pudiéramos definir las relaciones. Para encontrar todas las discrepancias, enumeramos todas las columnas en todas las tablas, junto con sus tipos de datos, y luego las ordenamos por nombre de columna. Todas las columnas con nombres iguales o similares aparecían una al lado de la otra, y podíamos ver dónde no coincidían sus tipos y longitudes. Solucionar estos problemas significaba editar las definiciones de la tabla dondequiera que encontráramos una discrepancia, lo que hicimos en una copia de la base de datos usando SQL Server Management Studio, asegurándonos de guardar el script de cambio cada vez. Una vez que se realizaron estos cambios, pudimos probar que la aplicación aún funcionaba y, cuando estuviera satisfecho, reproducir los scripts de cambio en la base de datos en vivo.

También aprovechamos la oportunidad para corregir el uso inapropiado de ciertos tipos de datos. Muchas columnas que contienen datos financieros se han definido como tipos de datos FLOAT, que están bien para números científicos cuya magnitud puede ser muy grande o pequeña pero inútiles para el dinero. Los flotantes no almacenan números exactamente, y la conversión de binario a decimal puede causar anomalías, como que el valor 36.2 se almacene como 36.199999996754. Definir una columna como DINERO en lugar de FLOTANTE permite que los valores se almacenen exactamente con cuatro decimales: 36,2 se almacena como 36,2000 y se evitan los errores de conversión de base.

Cuando el valor no es monetario pero aún debe almacenarse exactamente, puede especificar en su lugar DECIMAL(18,4), que tiene exactamente el mismo formato que MONEY pero sin la implicación de que este valor es monetario. Usamos este tipo de datos para cosas como tasas de descuento, tasas de IVA o tasas de cambio. Los números entre paréntesis después de la palabra DECIMAL indican que queremos almacenar 18 dígitos, de los cuales los últimos cuatro están después del punto decimal; por ejemplo, un número como 12.345.678.901.234,5678.