Roberto Carrancio

Continuamos donde lo dejamos el otro día en nuestro artículo de ¿cómo no hacer un DWH? y seguimos repasando los errores más comunes a la hora de diseñar un DWH. Si no habéis leído la primera parte os recomiendo hacerlo ahora, antes de este artículo ya que este es la continuación directa de ese primer post. 

Errores del 12 al 7

Antes de empezar con los 6 errores más graves que cometemos a la hora de diseñar un DWH vamos a repasar brevemente los errores que vimos en la primera parte de este artículo.

• Error 12: Incluir campos de texto en tablas de hechos para filtrar u ordenar
• Error 11: Escatimar en la información de nuestras dimensiones para ahorrar espacio
• Error 10: Dividir las jerarquías y en varias dimensiones
• Error 9: No enfrentar las dimensiones lentamente cambiantes
• Error 8: No crear foreign keys específicas
• Error 7: Añadir dimensiones a la tabla de hechos

Errores más graves al crear un DWH

Ahora si, ya conocemos los 6 primeros errores más comunes a la hora de crear nuestro DWH vamos a repasar los 6 que nos quedan, los más graves.

Error 6: Crear el modelo dimensional del DWH a la medida de un informe particular

No hay mucho más que decir, el título lo dice todo. Construir el modelo de datos a medida para los informes que se van a realizar es un grave error que a la larga dificultará mucho el escalado de nuestro DWH y la integración de nuevos reportes. Es común definir primero los objetivos de nuestro DWH y los reportes que los usuarios de negocio van a necesitar previamente antes de la propia arquitectura del modelo, estas definiciones son necesarias pero no pueden ser la base del DWH de fondo. Como arquitectos de datos debemos pensar en todo y dejar el modelo preparado para futuros requisitos. 

Este error es común sobre todo cuando se delega la creación en equipos externos y se definen como objetivos la entrega de unos informes predefinidos. Mucho cuidado con los términos de tu contrato de externalización.

Error 5: Compartir una tabla de hechos para hechos de distinta granularidad

Como sabes, las tablas de hechos pueden acumular miles de millones de registros a lo largo del tiempo y eso hace que operaciones pesadas como agregaciones para, por ejemplo, calcular el total de ventas por meses puedan llevar mucho tiempo y recursos. Una buena solución para eso es persistir ese dato ya agrupado en otra tabla para disponer de él de una manera mucho más rápida. Sin embargo, aunque estemos hablando de los mismos hechos (las ventas en este caso), el detalle y los agregados no tienen la misma granularidad por lo que no deben compartir la misma tabla o a la larga podremos caer en errores de incoherencia de datos.

Error 4: No añadir todo el detalle a la última capa del DWH

Tradicionalmente, los DWH se han dividido en capas, tenemos una primera capa de staging donde cargamos en bruto la información de los sistemas operacionales, una segunda capa relacional (normalmente en un modelo copo de nieve) donde ya la información ha sido integrada y se han añadido las relaciones y una última capa dimensional que será nuestro modelo de estrella con las tablas de agregados adaptadas a nuestros KPIs que consumirán las herramientas de reportes. En la actualidad, esta nomenclatura se está reemplazando por bronce, plata y oro pero sigue respondiendo a los mismos términos.

Podemos pensar que es una buena idea no llevar información que no se va a consumir al modelo de estrella para aligerar el modelo y que las consultas puedan ir más rápido pero, sin embargo, lo que vamos a terminar consiguiendo es que cuando el usuario final necesite esa información tenga que atacar al modelo relacional o en su defecto un extra de trabajo para los equipos de desarrollo BI. En este sentido es mejor opción detallar al máximo la capa dimensional y que sea el usuario desde la herramienta de reporte quien decida qué información mostrar.

Error 3: No usar tablas de agregados

Cuando nos enfrentamos a un problema de rendimiento de nuestro DWH (lo haremos, todos rinden mal) podemos caer en la tentación de añadir más recursos de CPU y RAM cuando lo que normalmente solucionará el problema es crear tablas de agregados para evitar ese recálculo continuo a la hora de mostrar los informes. Las tablas de agregados son un objeto más a mantener y puede parecer que el esfuerzo no merece la pena pero realmente es lo que va a descargar de trabajo a nuestro servidor. Además, para evitar esto, podemos hacer uso de vistas materializadas o vistas indexadas siempre que nuestro gestor de base de datos lo permita.

Error 2: No unificar los hechos entre distintas tablas de hechos de nuestro DWH

En el artículo de ayer, cuando definimos un DWH dijimos que era un sistema donde la información de diferentes orígenes se encuentra integrada. Esto es un verdadero reto a la hora de modelar un DWH y en ocasiones, por necesidades de negocio optamos por separar la información de diferentes orígenes en tablas diferentes para una explotación individual. Esto no tiene nada de malo pero tenemos que tener cuidado y no caer en el error de no unificar los criterios. Aunque la información se encuentre en distintas tablas de hechos debe responder a las mismas dimensiones y tener los mismos criterios para permitir agregaciones entre sí.

Y el mayor error….

Error 1: No ajustar las dimensiones entre tablas de hechos

Cuando modelamos un DWH es común encontrarnos con información duplicada entre diferentes orígenes. Esto se puede ver con mayor frecuencia en los maestros de personas. En ocasiones una misma persona puede ser cliente y proveedor o cliente y empleado. O cliente en dos aplicaciones distintas como la tienda web y la tienda física. Muchas veces, por falta de tiempo, recursos o una mezcla de ambas se cargan los maestros tal cual sin identificar estas dimensiones duplicadas. Esto nos va a llevar a errores a la hora de aplicar agregaciones y filtrados por lo que debemos prestar especial atención a estos casos y dedicar el tiempo y los recursos que sean necesarios para solventarlos. De lo contrario nuestro DWH no cumplirá su función principal de tener la información integrada y unificada.

Conclusión

En esta serie de dos artículos hemos podido ver los errores más comunes a la hora de plantearse la arquitectura de un nuevo DWH. Espero que gracias a estos post no caigáis en estos errores o seáis capaces de subsanarlos a tiempo en caso contrario. Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

PD: El artículo original de Kimball fue borrado ya pero por suerte nada escapa del archivo de internet. Podéis encontrarlo aquí.