Data Warehouse
Un data warehouse no es una base de datos con tablas más grandes.
Es una forma diferente de pensar los datos — orientada al análisis, a la historia, a las decisiones.
La diferencia entre un DWH que funciona y uno que se convierte en un problema está casi siempre en el modelo. Tablas de hechos con la granularidad equivocada, dimensiones mal diseñadas, jerarquías que no soportan las consultas de agregación. Problemas que no se ven en fase de desarrollo, pero explotan cuando el negocio pide reportes que el modelo no puede entregar.
En esta sección comparto casos reales de diseño y reestructuración de data warehouses: modelado dimensional, jerarquías balanceadas, slowly changing dimensions, estrategias de carga. No teoría del libro de Kimball, sino soluciones aplicadas en producción sobre sistemas que sirven decisiones empresariales reales.
Porque un data warehouse no se construye para contener datos.
Se construye para responder preguntas.
Jerarquías desbalanceadas: cuando el cliente no tiene padre y el grupo no tiene abuelo
Un cliente con una jerarquía de tres niveles — Top Group, Group, Client — donde no todas las ramas están completas. Cómo balanceé una ragged hierarchy con self-parenting: quien no tiene padre se convierte en padre de sí mismo.
SCD Tipo 2: la historia que el negocio no sabía que necesitaba
Un director comercial pregunta cuántos clientes tenía la región Norte en junio pasado. El DWH no sabe responder porque cada actualización sobrescribe los datos anteriores. Cómo implementé una SCD Tipo 2 con claves subrogadas y fechas de validez para devolver al negocio su memoria histórica.
Granularidad equivocada: cuando la fact table no responde las preguntas correctas
Una fact table construida sobre el total mensual de facturación parecía perfecta. Luego el negocio pidió detalle por producto, por línea, por cliente. Y el data warehouse enmudeció.