En la anterior entrada de esta serie sobre cómo construir un datawarehouse se describía la importancia de unificar los hechos. Ahora hablaremos de unificar las dimensiones. No es más importante una cosa que la otra. Las dos son imprescindibles.

Sabemos que es normal que dentro de una compañía convivan muchas aplicaciones informáticas, cada una de ellas con sus propios maestros. Una función importante del DWH es la unificación de estas aplicaciones en unos maestros únicos.

Por ejemplo, la aplicación de recursos humanos puede utilizar los códigos "M" y "F" para indicar el sexo de los empleados, mientras que la aplicación de CRM puede estar utilizando los códigos "H" y "M". Es sólo un ejemplo tonto, pero es la realidad de todas las empresas. Incluso puede haber diferencias entre los códigos de las tiendas y productos que utilizan las distintas aplicaciones o módulos del ERP.

En el DWH, evidentemente, debe existir un solo maestro de género. Y un solo maestro de tiendas. Y un solo maestro de productos. Y un solo maestro de cualquier cosa. En el proceso de carga del datawarehouse, deben identificarse los códigos equivalentes, y asignarles una única clave subrogada.

Un caso especial, y muy problemático, es el maestro de clientes. Se puede captar información de los clientes a partir de un formulario en la página web, o un carnet de afiliación que solicita el cliente en la tienda, o una llamada al departamento de reclamaciones… Es importante identificar las personas entre distintos aplicativos. Ni el nombre y los apellidos del cliente, ni el email, ni la dirección, ni siquiera el DNI son métodos fiables para detectar una misma persona en diferentes aplicaciones. Para identificar adecuadamente un cliente debe utilizarse una combinación de todos los anteriores e incluso puede ser necesaria la intervención manual. Existen herramientas y compañías especializadas en esta tarea, y no suele considerarse una responsabilidad del modelizador del DWH. Normalmente, para realizar una identificación fiable resulta necesario modificar las aplicaciones orígen, para realizar el "matching" cuanto antes.

En todos los demás casos, el equipo del DWH debe estar obsesionado por entender y unificar todos los maestros de la compañía.

El primer error, el más grave según Raplh Kimbal, se refiere precisamente a este aspecto de la modelización:

Error 1: No compartir dimensiones entre diferentes tablas de hechos.

Efectivamente, por falta de tiempo y recursos, se pueden cargar los diferentes maestros tal cual llegan de los distintos operacionales. Es un error muy grave. Las dimensiones compartidas entre diferentes hechos permiten navegar por la información, o cruzar información de distintos orígenes.

Si se realiza correctamente, daremos mucha potencia y funcionalidad a los usuarios de negocio, el mantenimiento del sistema será más sencillo, y podrá añadirse nueva información al sistema Business Intelligence de manera paulatina y harmoniosa.

Si no se realiza correctamente, el datawarehouse perderá mucha de su utilidad y sentido.