Construir un modelo de datos sólido depende de la metodología que elijas. Las metodologías de business intelligence definen cómo conectar fuentes, dimensiones, modelos dimensionales y visualizaciones para que tu negocio tome decisiones con datos confiables. Aquí verás las tres más usadas y cuándo conviene cada una.

¿Qué propone la metodología de Bill Inmon?

Bill Inmon es considerado el precursor del business intelligence moderno y su enfoque parte de una arquitectura robusta y centralizada [0:14].

Su propuesta sigue este flujo:

• Llevar los datos desde las fuentes hasta un área de staging, una base de datos temporal que evita golpear las bases transaccionales.
• Mover esos datos mediante un proceso de ETL hacia un data warehouse centralizado.
• Construir data marts a partir del data warehouse para alimentar tableros y reportes.

El staging es clave porque permite hacer transformaciones pesadas sin afectar la operación del negocio [0:50]. Una vez procesados, los datos viajan al repositorio central y de ahí se segmentan en data marts especializados por área.

¿Qué es un área de staging? Es una base de datos temporal donde almacenas datos brevemente para hacer transformaciones pesadas sin afectar el rendimiento de las bases de datos transaccionales del negocio.

¿En qué se diferencia el enfoque de Ralph Kimball?

Ralph Kimball simplifica el flujo y elimina el paso intermedio del data warehouse como obligatorio [1:30]. Su propuesta lleva los datos desde el staging directamente a los data marts, que alimentan las visualizaciones.

No se trata de que una opción sea mejor que la otra. Puedes tener solo data warehouse, solo data marts o ambos, según el tamaño y necesidad del negocio.

¿Cuál es el flujo de Kimball para crear modelos de datos?

Kimball propone seis etapas claras para diseñar un proyecto de BI:

1. Planificación del proyecto: define propósito, objetivos y alcance.
2. Requerimientos de negocio: identifica las preguntas y necesidades de decisión mediante entrevistas.
3. Modelo dimensional: determina la granularidad de los datos, elige el proceso de negocio a intervenir y define dimensiones y medidas.
4. Diseño físico: define infraestructura, servidores locales o en la nube y dimensionamiento.
5. Diseño e implementación del subsistema de ETL: construye el flujo que extrae, transforma y carga los datos al data warehouse.
6. Implementación: despliega y divulga el proceso al negocio.

El modelo dimensional es donde se decide, por ejemplo, si vas a medir ventas por día, por producto o por región. Esa granularidad define el detalle máximo al que podrás llegar en tus análisis.

¿Qué aporta la metodología Hefesto?

Hefesto es una metodología alternativa relativamente nueva que muchos analistas combinan con Kimball para sacar lo mejor de ambas [3:51]. Su enfoque es más directo y práctico.

Sus etapas son:

• Análisis de requerimientos: entender qué necesita el negocio e identificar el nivel de granularidad.
• Análisis de los OLTP: conocer las fuentes de datos, su ubicación, nivel de detalle, datos faltantes y permisos necesarios para capturarlos.
• Modelo lógico del data warehouse: crear las tablas, dimensiones y tablas de hechos que almacenarán los datos.
• Integración de los datos: aplicar el proceso de ETL desde las fuentes hasta el destino final.

¿Qué es un sistema OLTP? Son las bases de datos transaccionales que soportan la operación diaria del negocio, como ventas, inventarios o registros de clientes, y son la fuente original de los datos que llevarás al data warehouse.

¿Qué arquitectura conviene en negocios pequeños?

Una arquitectura práctica combina lo mejor de las tres metodologías [5:00]. El flujo recomendado funciona así:

• Conectar las fuentes de datos a un área de staging para proteger el performance transaccional.
• Construir procesos de ETL que muevan la información del staging al data warehouse.
• Consumir los datos directamente desde el data warehouse para alimentar dashboards, cubos o reportes.

En negocios pequeños puedes prescindir de los data marts y centralizar todo en el data warehouse. Esto reduce complejidad sin perder capacidad analítica.

¿Necesito siempre un data warehouse y data marts? No. Puedes tener uno, otro o ambos. La decisión depende del tamaño del negocio, el volumen de datos y qué tan segmentado necesitas el consumo por áreas.

¿Qué metodología usas tú o cuál te ha funcionado mejor en tus proyectos? Déjalo en los comentarios.