17  Data Marts: del Almacén de Datos al Consumo por Área de Negocio

Arquitectura, diseño dimensional y ejemplo reproducible

Autor/a

Diego Villalba

Fecha de publicación

16 de octubre de 2026

En el capítulo anterior se definió un cubo OLAP como una función que agrega medidas sobre varias dimensiones, \(C:D_1\times\cdots\times D_k\to\mathbb{R}^m\). Esa función necesita datos organizados de forma dimensional para poder calcularse de manera eficiente. La pregunta natural es: ¿de dónde salen exactamente esas tablas de hechos y dimensiones que el cubo consulta? La respuesta, en la mayoría de las organizaciones, es un data mart: un recorte del almacén de datos empresarial, diseñado para un área de negocio específica, sobre el cual se construyen los cubos, los reportes y —como se verá en el siguiente capítulo— las APIs de consumo analítico.

Este capítulo formaliza el concepto de data mart, distingue sus arquitecturas (dependiente, independiente e híbrida), presenta el proceso de diseño dimensional de Kimball y lo aplica al mismo caso de la ferretería multiestado usado en el capítulo de cubos OLAP (Kimball y Ross 2013; Inmon 2005). Así, el data mart que se construye aquí es exactamente la fuente que alimentaría el cubo Ubicación × Tiempo × Departamento discutido previamente.

17.1 ¿Qué es un data mart?

Un data warehouse (DW) empresarial integra datos de múltiples procesos de negocio —ventas, inventario, recursos humanos, finanzas— en un repositorio único, histórico y consistente. Sin embargo, pocas veces un analista de un área específica necesita consultar todo el DW: al equipo de Ventas le interesan las transacciones de venta; a Recursos Humanos, la nómina y la rotación de personal. Consultar directamente un DW completo, con decenas de tablas de hechos y cientos de atributos, resulta ineficiente y difícil de entender para usuarios de negocio.

Definición. Un data mart es un subconjunto especializado de un data warehouse, delimitado por un área funcional o proceso de negocio, diseñado para responder las preguntas analíticas de un grupo específico de usuarios. \[ DM_j \subseteq DW, \qquad DM_j = \pi_{A_j}\big(\sigma_{P_j}(DW)\big) \]

En esta notación, \(\sigma_{P_j}\) selecciona los hechos correspondientes al proceso de negocio \(P_j\) (por ejemplo, ventas) y \(\pi_{A_j}\) proyecta únicamente los atributos y dimensiones relevantes para esa área \(A_j\). El resultado es una porción del almacén, más pequeña, más rápida de consultar y más fácil de entender para su audiencia (Devlin y Murphy 1988).

Tres características distinguen a un data mart de un data warehouse completo:

  1. Alcance acotado. Cubre un proceso o departamento, no la organización entera.
  2. Audiencia definida. Se diseña pensando en las preguntas de un grupo de usuarios de negocio concreto.
  3. Modelo dimensional explícito. Casi siempre se implementa como un esquema estrella o copo de nieve, optimizado para consultas de agregación, no como una réplica normalizada de sistemas operacionales.

17.2 Arquitecturas: dependiente, independiente e híbrida

La forma en que un data mart obtiene sus datos —directamente del DW o directamente de las fuentes— define su arquitectura y tiene consecuencias importantes sobre la consistencia de la información en toda la organización.

17.2.1 Data marts dependientes (enfoque Inmon)

En el enfoque de Bill Inmon, el DW corporativo se construye primero como un repositorio normalizado (tercera forma normal) que integra y depura todas las fuentes (Inmon 2005). Los data marts se derivan después, como vistas dimensionales de ese DW ya integrado.

Definición. Un data mart es dependiente cuando su única fuente de datos es el data warehouse corporativo ya integrado. \[ DM_j = f_j(DW), \qquad \text{con } DW \text{ como única fuente} \]

La ventaja principal es la consistencia: como todos los data marts parten de la misma fuente integrada, un mismo cliente, producto o empleado tiene exactamente la misma definición en cualquier data mart. El costo es tiempo: el DW corporativo debe existir y estar completo antes de poder entregar el primer data mart, lo cual puede tardar meses o años en organizaciones grandes.

17.2.2 Data marts independientes (enfoque bottom-up)

En el enfoque bottom-up asociado a Ralph Kimball, no es necesario esperar a un DW normalizado completo. Cada data mart se construye directamente desde las fuentes operacionales de su propio proceso de negocio, con su propio proceso ETL.

Definición. Un data mart es independiente cuando se construye directamente desde sistemas fuente, sin pasar por un data warehouse integrado previo. \[ DM_j = g_j(S_1, S_2, \ldots, S_n), \qquad S_i \text{ = sistemas fuente} \]

La ventaja es velocidad de entrega: un equipo puede construir y poner en producción el data mart de Ventas en semanas, sin depender de que otras áreas terminen su integración. El riesgo, si no se gestiona con cuidado, es la aparición de silos de datos (stovepipes): si el data mart de Ventas y el de Marketing definen “cliente activo” de formas distintas, sus reportes no van a coincidir, y reconciliar esa diferencia después es costoso.

17.2.3 Arquitectura híbrida: el bus de Kimball

Kimball resuelve el dilema de velocidad contra consistencia con la arquitectura de bus: los data marts se construyen de forma incremental, proceso por proceso, pero comparten un conjunto de dimensiones conformadas —definiciones únicas de Tiempo, Producto, Cliente, Ubicación, etc.— acordadas de antemano entre equipos (Kimball y Ross 2013). El conjunto de data marts conformados, visto en conjunto, constituye un DW empresarial virtual, sin necesidad de construir primero un modelo normalizado centralizado.

Comparación de arquitecturas de data marts
El EDW normalizado se construye primero; los data marts se derivan de él. Máxima consistencia, mayor tiempo de entrega.
Fuentes OLTP
→
EDW (3FN)
Único punto de integración
→
DM Ventas  |  DM RRHH  |  DM Finanzas
Derivados, siempre consistentes entre sí
Cada data mart se construye directamente desde sus propias fuentes. Entrega rápida, riesgo de silos si no hay gobierno de datos.
Fuentes Ventas
↓
DM Ventas
Fuentes RRHH
↓
DM RRHH
Fuentes Finanzas
↓
DM Finanzas
Sin dimensiones compartidas, "Cliente" o "Producto" puede tener definiciones distintas en cada data mart.
Cada data mart se construye por separado y de forma incremental, pero todos comparten dimensiones conformadas (Tiempo, Producto, Ubicación...).
DM Ventas
DM Inventario
DM Finanzas
Bus de dimensiones conformadas
Tiempo · Ubicación · Producto · Cliente — una sola definición, reutilizada por todos los data marts.
Haz clic en cada pestaña para comparar cómo fluyen los datos en cada arquitectura.

La siguiente tabla resume las diferencias prácticas entre las tres arquitecturas.

Criterio Dependiente (Inmon) Independiente Bus / Híbrida (Kimball)
Fuente de datos EDW integrado Sistemas fuente directos Sistemas fuente directos
Consistencia entre áreas Alta Baja si no hay gobierno Alta, vía dimensiones conformadas
Tiempo de entrega inicial Largo (requiere EDW previo) Corto Corto por data mart
Riesgo principal Costo y tiempo de construir el EDW Silos de datos, definiciones divergentes Requiere disciplina de gobierno desde el inicio
Escalabilidad organizacional Alta una vez construido el EDW Baja sin coordinación Alta, crece data mart por data mart

17.3 Dimensiones conformadas y la matriz de bus

Definición. Una dimensión conformada es una dimensión con la misma clave, atributos y significado de negocio en dos o más data marts, de manera que puede reutilizarse sin transformación adicional entre ellos.

La herramienta principal para planear qué dimensiones deben conformarse es la matriz de bus: una tabla donde las filas son procesos de negocio y las columnas son dimensiones candidatas. Una marca indica que ese proceso usa esa dimensión con la definición conformada.

Proceso de negocio Tiempo Ubicación Producto/Departamento Cliente Empleado
Ventas ✔ ✔ ✔ ✔ ✔
Inventario ✔ ✔ ✔    
Recursos Humanos ✔ ✔     ✔
Finanzas ✔ ✔      

La matriz de bus revela que Tiempo y Ubicación son candidatas naturales a conformarse primero, porque las usan todos los procesos: conviene diseñarlas una sola vez, con una sola clave y una sola jerarquía, y reutilizarlas en cada data mart que se construya después.

17.4 Diseño dimensional de un data mart

Kimball propone cuatro decisiones, en orden, para diseñar cualquier data mart (Kimball y Ross 2013):

  1. Elegir el proceso de negocio. Un evento medible y repetible: una venta, un movimiento de inventario, una nómina.
  2. Declarar la granularidad. ¿Qué representa exactamente una fila de la tabla de hechos? (Ver el capítulo de modelado multidimensional para la definición formal de granularidad.)
  3. Identificar las dimensiones. Los ejes de análisis relevantes para ese proceso: quién, qué, cuándo, dónde.
  4. Identificar los hechos. Las medidas numéricas que se desean agregar.

17.4.1 Ejemplo integrador: el data mart detrás del cubo de la ferretería

En el capítulo anterior se trabajó con una cadena de ferreterías con sucursales en CDMX, Guadalajara, Monterrey y Mérida, departamentos Madera, Plomería, Decoración y Eléctrico, y ventas trimestrales como medida. Ese cubo no aparece de la nada: es el resultado de consultar un data mart de Ventas diseñado explícitamente con las cuatro decisiones anteriores.

  1. Proceso de negocio: ventas en tienda.
  2. Granularidad: una fila por ticket de venta, departamento y trimestre.
  3. Dimensiones: dim_tiempo (trimestre, año), dim_ubicacion (tienda, ciudad, región), dim_departamento (departamento, categoría).
  4. Hechos: monto_venta (medida aditiva), unidades (medida aditiva).

El esquema estrella resultante se representa así:

17.5 Ejemplo reproducible: construir el data mart en Python

A continuación se construye este data mart en Python usando pandas. En un entorno de producción, estas mismas tablas suelen vivir en un motor analítico como DuckDB, BigQuery o Snowflake, y las consultas se expresan en SQL en lugar de operaciones de DataFrame; aquí se usa pandas para mantener continuidad con el resto del curso, y las consultas se escriben primero en SQL (para mostrar la estructura relacional) y luego se resuelven con merge/groupby. Se reutilizan los mismos datos del capítulo de cubos OLAP para que ambos capítulos sean consistentes entre sí.

import pandas as pd

dim_tiempo = pd.DataFrame({
    "id_tiempo": [1, 2],
    "trimestre": ["T1", "T2"],
    "anio": [2025, 2025],
})

dim_ubicacion = pd.DataFrame({
    "id_ubicacion": [1, 2, 3, 4],
    "ciudad": ["CDMX", "Guadalajara", "Monterrey", "Mérida"],
    "region": ["Centro", "Occidente", "Norte", "Sureste"],
})

dim_departamento = pd.DataFrame({
    "id_departamento": [1, 2, 3, 4],
    "departamento": ["Madera", "Plomería", "Decoración", "Eléctrico"],
})

# fact_ventas: (id_tiempo, id_ubicacion, id_departamento, monto_venta)
fact_ventas = pd.DataFrame([
    (1, 1, 1, 70), (1, 1, 2, 40), (1, 1, 3, 20), (1, 1, 4, 30),
    (2, 1, 1, 50), (2, 1, 2, 60), (2, 1, 3, 22), (2, 1, 4, 28),
    (1, 2, 1, 60), (1, 2, 2, 35), (1, 2, 3, 25), (1, 2, 4, 40),
    (2, 2, 1, 45), (2, 2, 2, 50), (2, 2, 3, 30), (2, 2, 4, 35),
    (1, 3, 1, 48), (1, 3, 2, 38), (1, 3, 3, 18), (1, 3, 4, 26),
    (2, 3, 1, 36), (2, 3, 2, 55), (2, 3, 3, 25), (2, 3, 4, 30),
    (1, 4, 1, 52), (1, 4, 2, 42), (1, 4, 3, 15), (1, 4, 4, 37),
    (2, 4, 1, 44), (2, 4, 2, 33), (2, 4, 3, 20), (2, 4, 4, 28),
], columns=["id_tiempo", "id_ubicacion", "id_departamento", "monto_venta"])

fact_ventas.head()
id_tiempo id_ubicacion id_departamento monto_venta
0 1 1 1 70
1 1 1 2 40
2 1 1 3 20
3 1 1 4 30
4 2 1 1 50

El data mart queda expresado como cuatro tablas relacionadas por llaves foráneas: exactamente la estructura de un esquema estrella. La consulta analítica equivalente en SQL —el equivalente a un roll-up del capítulo anterior— sería:

SELECT
    u.region,
    t.trimestre,
    d.departamento,
    SUM(f.monto_venta) AS total_ventas
FROM fact_ventas f
JOIN dim_tiempo       t ON f.id_tiempo = t.id_tiempo
JOIN dim_ubicacion    u ON f.id_ubicacion = u.id_ubicacion
JOIN dim_departamento d ON f.id_departamento = d.id_departamento
GROUP BY u.region, t.trimestre, d.departamento
ORDER BY u.region, t.trimestre, d.departamento

En pandas, el mismo JOIN seguido de GROUP BY se expresa encadenando merge y groupby, en lugar de operar sobre un cubo ya materializado:

reporte = (
    fact_ventas
    .merge(dim_tiempo, on="id_tiempo")
    .merge(dim_ubicacion, on="id_ubicacion")
    .merge(dim_departamento, on="id_departamento")
    .groupby(["region", "trimestre", "departamento"], as_index=False)["monto_venta"]
    .sum()
    .rename(columns={"monto_venta": "total_ventas"})
    .sort_values(["region", "trimestre", "departamento"])
)

reporte
region trimestre departamento total_ventas
0 Centro T1 Decoración 20
1 Centro T1 Eléctrico 30
2 Centro T1 Madera 70
3 Centro T1 Plomería 40
4 Centro T2 Decoración 22
5 Centro T2 Eléctrico 28
6 Centro T2 Madera 50
7 Centro T2 Plomería 60
8 Norte T1 Decoración 18
9 Norte T1 Eléctrico 26
10 Norte T1 Madera 48
11 Norte T1 Plomería 38
12 Norte T2 Decoración 25
13 Norte T2 Eléctrico 30
14 Norte T2 Madera 36
15 Norte T2 Plomería 55
16 Occidente T1 Decoración 25
17 Occidente T1 Eléctrico 40
18 Occidente T1 Madera 60
19 Occidente T1 Plomería 35
20 Occidente T2 Decoración 30
21 Occidente T2 Eléctrico 35
22 Occidente T2 Madera 45
23 Occidente T2 Plomería 50
24 Sureste T1 Decoración 15
25 Sureste T1 Eléctrico 37
26 Sureste T1 Madera 52
27 Sureste T1 Plomería 42
28 Sureste T2 Decoración 20
29 Sureste T2 Eléctrico 28
30 Sureste T2 Madera 44
31 Sureste T2 Plomería 33

Esta salida es, cifra por cifra, la misma información que el cubo del capítulo anterior representaba como \(C(\text{región}, \text{tiempo}, \text{departamento})\). La diferencia es de capa: el data mart es el modelo de almacenamiento relacional; el cubo es la forma de consultarlo y navegarlo interactivamente.

17.5.1 Consultar el mismo data mart con la sintaxis de un roll-up regional

El siguiente ejemplo agrupa dim_ubicacion en zonas antes del GROUP BY, ilustrando que un roll-up no es más que sustituir el nivel de agrupación de una dimensión conformada, sin tocar la tabla de hechos.

zona_map = pd.DataFrame({
    "region": ["Centro", "Occidente", "Norte", "Sureste"],
    "zona": ["Zona Norte-Centro", "Zona Occidente-Sureste",
             "Zona Norte-Centro", "Zona Occidente-Sureste"],
})

reporte_zona = (
    fact_ventas
    .merge(dim_tiempo, on="id_tiempo")
    .merge(dim_ubicacion, on="id_ubicacion")
    .merge(zona_map, on="region")
    .groupby(["zona", "trimestre"], as_index=False)["monto_venta"]
    .sum()
    .rename(columns={"monto_venta": "total_ventas"})
    .sort_values(["zona", "trimestre"])
)

reporte_zona
zona trimestre total_ventas
0 Zona Norte-Centro T1 290
1 Zona Norte-Centro T2 306
2 Zona Occidente-Sureste T1 306
3 Zona Occidente-Sureste T2 285

17.6 El riesgo de los data marts independientes: dimensiones no conformadas

Para ilustrar por qué la conformidad de dimensiones importa, supongamos que el equipo de Marketing construyó su propio data mart de manera independiente, sin coordinarse con Ventas, y definió “región” con una granularidad distinta (por zona comercial, no por ciudad).

Data mart Definición de “región” Valores
Ventas (este capítulo) Ciudad sede de la sucursal CDMX, Guadalajara, Monterrey, Mérida
Marketing (hipotético, independiente) Zona comercial agregada Zona Norte-Centro, Zona Occidente-Sureste

Ambas definiciones son legítimas por separado, pero si un directivo intenta cruzar un reporte de Ventas por “región” con uno de Marketing por “región” sin saber que la granularidad difiere, llegará a conclusiones incorrectas o a totales que no cuadran. La solución de gobierno de datos es simple de enunciar y difícil de ejecutar en la práctica: acordar la dimensión dim_ubicacion (y su jerarquía ciudad → zona → región) una sola vez, en la matriz de bus, antes de que cada equipo construya su propio data mart.

17.7 Ventajas, limitaciones y buenas prácticas

Los data marts existen porque resuelven un problema real: un DW corporativo completo puede ser demasiado grande, lento y genérico para las preguntas cotidianas de un área específica. Entre sus ventajas destacan:

  • Consultas más rápidas, al reducir el volumen de datos y el número de tablas relevantes.
  • Modelo más simple, alineado al vocabulario de negocio del área (menos jerga técnica de todo el DW).
  • Entrega incremental, especialmente en la arquitectura de bus, sin depender de un proyecto monolítico.
  • Gobernanza más manejable, al delimitar quién es dueño de qué datos.

Sus limitaciones más comunes son:

  • Riesgo de silos cuando se construyen de forma independiente sin dimensiones conformadas.
  • Redundancia de almacenamiento, al replicar dimensiones compartidas en varios data marts.
  • Necesidad de mantener sincronizados los procesos ETL/ELT de cada data mart conforme cambian las fuentes.

Buenas prácticas recomendadas al diseñar un nuevo data mart:

  1. Revisar la matriz de bus antes de crear una dimensión nueva; reutilizar una conformada si ya existe.
  2. Documentar la granularidad exacta de la tabla de hechos desde el día uno.
  3. Versionar el esquema (nombres de columnas, tipos, claves) igual que se versiona código.
  4. Validar que las medidas declaradas sean aditivas, semi-aditivas o no aditivas, y documentarlo explícitamente (Kimball y Ross 2013).
  5. Definir desde el diseño quién consumirá el data mart y cómo (reportes, cubos OLAP, o —tema del siguiente capítulo— una API).

17.8 De data marts a productos de datos

En años recientes, el concepto de data mart ha evolucionado hacia el de producto de datos dentro de arquitecturas de data mesh: cada dominio de negocio no solo publica su data mart, sino que lo trata como un producto con dueño, documentación, garantías de calidad y, sobre todo, una interfaz de consumo estándar en lugar de acceso directo a tablas (Dehghani 2022). Esa interfaz de consumo es, cada vez con más frecuencia, una API. El siguiente capítulo retoma exactamente el data mart de Ventas construido aquí y muestra cómo exponerlo mediante REST, GraphQL y una capa semántica moderna.

17.9 Conclusiones

Un data mart es el punto de encuentro entre el modelo dimensional (hechos, dimensiones, granularidad) y las necesidades concretas de un área de negocio. La decisión de construirlo de forma dependiente, independiente o mediante una arquitectura de bus no es solo técnica: determina qué tan rápido se entrega valor y qué tan consistentes serán los números entre departamentos. El ejemplo de la ferretería mostró que un cubo OLAP no es una estructura aislada, sino la forma de consultar un data mart bien diseñado; y que las mismas operaciones de roll-up estudiadas antes corresponden, a nivel relacional, a sustituir el nivel de una dimensión conformada dentro de una consulta SQL.

17.10 Referencias