Mejores prácticas para construir un Data Warehouse

Este artículo aborda los principales retos a los que se enfrentan los profesionales involucrados en la construcción de un Data Warehouse. Entendiendo y anticipando tales retos, los desarrolladores podrán añadir valor agregado a su diseño final.

1. Asegurarse de que ha sido suministrado un diccionario de datos antes de empezar con las etapas fuertes de desarrollo.

Es común que algunas tareas de desarrollo comiencen mientras otras tareas de análisis están realizandose en paralelo. En este tipo de escenario los desarrolladores juegan a los “detectives” por tiempos indefinidos, mientras realizan la codificación o el mapeo de datos, generando restricciones de tiempo. Por eso un diccionario de datos debe estar disponible antes de que cualquier proceso crítico inicie. Que al menos contenga reglas, validaciones y descripciones. Este diccionario debe estar almacenado en la Intranet de la empresa y disponible tanto para usuarios finales como para desarrolladores.

Los Data Warehouse que son construídos sin un diccionario de datos resultarán en duplicidad de datos y procedimientos, así como confusiones y problemas con los resultados finales.

2. Guardar planes de Consultas, tiempos de ejecución y referencias de rendimiento en la base de datos.

Esto se puede realizar fácilmente. Por ejemplo, guardar un tiempo de inicio y un fin de tiempo para cada proceso crítico, puede ser implementado a través de Stored Procedures, Scripts o ETL’s.

Guardar puntos de referencia en la Base de Datos ayuda a señalar los puntos problemáticos en el rendimiento, ayudando a que el equipo de desarrollo se enfoque en la resolución de estos. Guardar puntos de referencia de los procesos como parte de los meta datos, es una extensión lógica para fortalecerlos. Es una forma de mejorar mediante el rastreo de la actividad del usuario, identificación de cuellos de botella y queries mas usados, obtención de accesos a la base de datos, estadisticas de los queries y mucho más.

3. Guardar ETL’s, validaciones y errores en tablas compartidas de la Base de Datos.

La practica de “atrapar” todos los errores de proceso es similar al punto anterior. Estos errores deben ser detectados, consolidados y enviados a una tabla. Es importante establecer límites para los errores y que acciones deben ser tomadas cuando estos límites son sobrepasados. Una meta importante en este punto es automatizar el envio de un correo electrónico cuando se sobrepasen los límites en la ocurrencia de un error.

4. Evitar transacciones con tiempos de ejecución largos.

Puede darse el caso de operaciones sobre millones de registros que llenen completamente la bitácora de transacciones de la Base de Datos, haciendo que el procesamiento prácticamente se detenga. Para evitar esto, se debe programar modularmente los Stored Procedures y hacer que las transacciones tengan operaciones pequeñas. Además esto permite una recuperación más rápida y menor número de cambios cuando un error suceda.

5. Usar la Integridad Referencial cuidadosamente.

Es recomendable no abusar de la integridad referencial. Mientras que las restricciones en llaves foraneas ayudan a la integridad de los datos, tienen asociado un costo en cada inserción, actualización o eliminación. Se puede considerar la ventaja de implementar ciertas validaciones en los ETL’s.

6. Aprender a reconocer cuando el rendimiento decrece en realidad.

Muchas veces “buen rendimiento” es aceptable. Hay que evitar la urgencia por realizar mejoras en un ciclo sin fin con el fin de optimizar el código de la Base de Datos. Aparentemente es un mal consejo, pero al cliente solo hay que cumplirle hasta donde quede satisfecho.

7. Entender siempre la optimización de la Base de Datos y los planes de Consultas (Query Plans).

Algunos consejos en este apartado incluyen comprender la naturaleza de los datos y su relación con las demás entidades. Antes de ejecutar una consulta se puede compilar y ejecutar en modo non-exec verificando el Query Plan. Limitar los resultados de las consultas cuando se este en fase de prueba.

8. Conocer las limitaciones de la herramienta para ETL’s.

Siempre tener en cuenta estas limitaciones, considerandolas en el ciclo de desarrollo para sacar el mejor provecho de la herramienta. En pocas palabras, se debe ajustar el código a la herramienta y no la herramienta al código.