17  Data Marts: From the Data Warehouse to Business Unit Consumption

Architecture, Dimensional Design, and Reproducible Example

In the previous chapter, an OLAP data cube was defined as an aggregation function over dimensions: \(C:D_1\times\cdots\times D_k\to\mathbb{R}^m\). To calculate this function efficiently, data must be organized dimensionally. A fundamental question follows: where do the underlying fact and dimension tables queried by the cube originate? In most enterprise environments, the answer is a data mart: a specialized subset of the enterprise data warehouse tailored to a specific business domain, serving as the foundation for cubes, dashboards, reports, and analytical consumption APIs.

This chapter formalizes the concept of data marts, evaluates architectural paradigms (dependent, independent, and hybrid), introduces Kimball’s dimensional design framework, and applies it to an end-to-end retail hardware case study (Kimball and Ross 2013; Inmon 2005). The data mart built here serves as the authoritative backend for the Location × Time × Department cube explored previously.

17.1 What is a Data Mart?

An enterprise data warehouse (DW) integrates data across multiple business processes—sales, inventory, human resources, finance—into a single, historical, consistent repository. However, individual business analysts rarely require access to the entire warehouse. The Sales team focuses on transaction records; Human Resources analyzes payroll and turnover. Querying a monolithic DW containing dozens of fact tables and hundreds of attributes creates performance bottlenecks and unnecessary analytical complexity.

Definition. A data mart is a specialized, domain-specific subset of a data warehouse focused on a single functional area or business process, designed to serve the analytical queries of a dedicated user group. \[ DM_j \subseteq DW, \qquad DM_j = \pi_{A_j}\big(\sigma_{P_j}(DW)\big) \]

Here, \(\sigma_{P_j}\) selects fact records corresponding to business process \(P_j\) (e.g., retail sales), and \(\pi_{A_j}\) projects only the relevant dimensions and attributes for business unit \(A_j\). The result is a streamlined analytical model that is faster to query and simpler to analyze (Devlin and Murphy 1988).

Three characteristics distinguish a data mart from an enterprise data warehouse:

1. Focused Scope: Serves a single business process or department rather than the entire enterprise.
2. Targeted Audience: Optimized for specific business questions and operational workflows.
3. Explicit Dimensional Schema: Implemented as star or snowflake schemas optimized for analytical aggregations.

OLTP Sources

Sales, Inventory, HR, Finance: Disparate operational systems.

→

Data Warehouse

Integrated, historical, enterprise-wide repository.

→

Data Marts

Sales · Inventory · HR · Finance: Domain-specific dimensional subsets.

Architectural flow. Each data mart inherits dimensions and grain from the enterprise model while scoping data to a single business domain.

17.2 Architectural Approaches: Dependent, Independent, and Hybrid

How a data mart ingests data—either downstream from a central DW or directly from operational source systems—defines its architectural model and determines data consistency across the enterprise.

17.2.1 Dependent Data Marts (Inmon Top-Down Approach)

In Bill Inmon’s corporate information factory (CIF) framework, an Enterprise Data Warehouse (EDW) is constructed first as a fully normalized repository (Third Normal Form, 3NF) integrating all source data (Inmon 2005). Dependent data marts are constructed downstream as dimensional views derived from the centralized EDW.

Definition. A data mart is dependent when its sole data source is the integrated enterprise data warehouse. \[ DM_j = f_j(DW), \qquad \text{with } DW \text{ as single source of truth} \]

The primary advantage is strict enterprise consistency: because all data marts derive from a single integrated repository, dimensions like Customer, Product, or Employee retain identical definitions across all data marts. The primary drawback is implementation speed: building a normalized enterprise DW before releasing the first data mart requires substantial upfront time and capital.

17.2.2 Independent Data Marts (Bottom-Up Approach)

In the bottom-up approach associated with Ralph Kimball, organizations bypass building a centralized 3NF warehouse first. Instead, independent data marts are built directly from operational source systems to serve immediate business needs.

Definition. A data mart is independent when built directly from operational source systems without an intermediary enterprise warehouse. \[ DM_j = g_j(S_1, S_2, \ldots, S_n), \qquad S_i \text{ = operational source systems} \]

The advantage is rapid time-to-value: individual departments can build and deploy data marts within weeks. The critical risk is the creation of uncoordinated data silos: if Sales and Marketing define “active customer” or “net revenue” differently, cross-departmental metrics will conflict.

17.2.3 Hybrid Architecture: The Kimball Bus Architecture

Kimball reconciles time-to-value with enterprise consistency through the Data Warehouse Bus Architecture. Data marts are built iteratively, process by process, but share a set of conformed dimensions—standardized, enterprise-wide definitions for Time, Product, Customer, Location, etc., agreed upon before development (Kimball and Ross 2013). The collection of conformed data marts forms a virtual Enterprise Data Warehouse without requiring a monolithic 3NF repository upfront.

Comparison of Data Mart Architectures

Normalized EDW built first; data marts derived downstream. Maximum consistency, longer initial delivery timeline.

OLTP Sources

→

EDW (3NF)

Single integration point

→

Sales DM  |  HR DM  |  Finance DM

Derived, consistent across enterprise

Each data mart built directly from operational sources. Fast delivery, high risk of isolated data silos.

Sales Sources

↓

Sales DM

HR Sources

↓

HR DM

Finance Sources

↓

Finance DM

Lacking shared dimensions, "Customer" or "Product" definitions diverge between marts.

Data marts built iteratively per business process, linked by shared conformed dimensions.

Sales DM

Inventory DM

Finance DM

Conformed Dimension Bus

Time · Location · Product · Customer — single definition shared across all data marts.

Click tabs above to compare data flow across architectural styles.

Criterion	Dependent (Inmon)	Independent	Bus / Hybrid (Kimball)
Data Source	Integrated 3NF EDW	Direct operational sources	Direct operational sources
Cross-Domain Consistency	High	Low without governance	High via conformed dimensions
Initial Time-to-Value	Long (requires upfront EDW)	Short	Short per data mart iteration
Primary Risk	Upfront time/cost of EDW build	Data silos, conflicting definitions	Requires initial governance discipline
Organizational Scalability	High once EDW exists	Low without coordination	High, scales incrementally per mart

17.3 Conformed Dimensions and the Bus Matrix

Definition. A conformed dimension is a dimension table maintaining identical keys, attributes, and business definitions across multiple data marts, enabling cross-process drill-across analysis without transformation.

The primary planning framework for identifying conformed dimensions is the Data Warehouse Bus Matrix: a matrix mapping business processes (rows) to candidate dimensions (columns).

Business Process	Time	Location	Product/Dept	Customer	Employee
Sales	✔	✔	✔	✔	✔
Inventory	✔	✔	✔
Human Resources	✔	✔			✔
Finance	✔	✔

The bus matrix highlights Time and Location as primary candidates for early conformation, as they intersect every core business process.

17.4 Four-Step Dimensional Design Process

Kimball outlines four sequential steps for designing any dimensional data mart (Kimball and Ross 2013):

1. Select the Business Process: Identify the operational activity to model (e.g., retail point-of-sale transactions).
2. Declare the Grain: Define what an individual fact table row represents atomically.
3. Identify the Dimensions: Determine the surrounding context (Who, What, Where, When, Why).
4. Identify the Facts: Select the numeric measures accumulated by the business process.

17.4.1 Case Study: Hardware Retail Sales Data Mart

Applying this process to our hardware retail case study:

1. Business Process: Store sales transactions.
2. Grain: One row per store transaction line item per department per quarter.
3. Dimensions: dim_tiempo (quarter, year), dim_ubicacion (city, region), dim_departamento (department, category).
4. Facts: monto_venta (additive revenue measure), unidades (additive quantity measure).

The resulting star schema structure:

dim_tiempo

time_key (PK)
quarter
year

fact_ventas

time_key (FK)
location_key (FK)
dept_key (FK)
sales_amount
units

dim_ubicacion

location_key (PK)
city
region

dim_departamento

dept_key (PK)
department
category

Star Schema: A central fact table surrounded by three conformed dimension tables. The Location × Time × Department cube is an aggregated view over fact_ventas.

17.5 Reproducible Python Data Mart Implementation

We construct this physical data mart using pandas:

import pandas as pd

dim_tiempo = pd.DataFrame({
    "time_key": [1, 2],
    "quarter": ["Q1", "Q2"],
    "year": [2025, 2025],
})

dim_ubicacion = pd.DataFrame({
    "location_key": [1, 2, 3, 4],
    "city": ["CDMX", "Guadalajara", "Monterrey", "Merida"],
    "region": ["Central", "West", "North", "Southeast"],
})

dim_departamento = pd.DataFrame({
    "dept_key": [1, 2, 3, 4],
    "department": ["Wood", "Plumbing", "Decoration", "Electrical"],
})

# fact_ventas: (time_key, location_key, dept_key, sales_amount)
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=["time_key", "location_key", "dept_key", "sales_amount"])

fact_ventas.head()

	time_key	location_key	dept_key	sales_amount
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

The equivalent SQL query joining facts to dimensions:

SELECT
    u.region,
    t.quarter,
    d.department,
    SUM(f.sales_amount) AS total_sales
FROM fact_ventas f
JOIN dim_tiempo       t ON f.time_key = t.time_key
JOIN dim_ubicacion    u ON f.location_key = u.location_key
JOIN dim_departamento d ON f.dept_key = d.dept_key
GROUP BY u.region, t.quarter, d.department
ORDER BY u.region, t.quarter, d.department

In pandas, this dimensional join and aggregation is expressed as:

report = (
    fact_ventas
    .merge(dim_tiempo, on="time_key")
    .merge(dim_ubicacion, on="location_key")
    .merge(dim_departamento, on="dept_key")
    .groupby(["region", "quarter", "department"], as_index=False)["sales_amount"]
    .sum()
    .rename(columns={"sales_amount": "total_sales"})
    .sort_values(["region", "quarter", "department"])
)

report

	region	quarter	department	total_sales
0	Central	Q1	Decoration	20
1	Central	Q1	Electrical	30
2	Central	Q1	Plumbing	40
3	Central	Q1	Wood	70
4	Central	Q2	Decoration	22
5	Central	Q2	Electrical	28
6	Central	Q2	Plumbing	60
7	Central	Q2	Wood	50
8	North	Q1	Decoration	18
9	North	Q1	Electrical	26
10	North	Q1	Plumbing	38
11	North	Q1	Wood	48
12	North	Q2	Decoration	25
13	North	Q2	Electrical	30
14	North	Q2	Plumbing	55
15	North	Q2	Wood	36
16	Southeast	Q1	Decoration	15
17	Southeast	Q1	Electrical	37
18	Southeast	Q1	Plumbing	42
19	Southeast	Q1	Wood	52
20	Southeast	Q2	Decoration	20
21	Southeast	Q2	Electrical	28
22	Southeast	Q2	Plumbing	33
23	Southeast	Q2	Wood	44
24	West	Q1	Decoration	25
25	West	Q1	Electrical	40
26	West	Q1	Plumbing	35
27	West	Q1	Wood	60
28	West	Q2	Decoration	30
29	West	Q2	Electrical	35
30	West	Q2	Plumbing	50
31	West	Q2	Wood	45

17.5.1 Performing a Regional Roll-Up Query

Rolling up locations to macro zones:

zone_map = pd.DataFrame({
    "region": ["Central", "West", "North", "Southeast"],
    "zone": ["North-Central Zone", "West-Southeast Zone",
             "North-Central Zone", "West-Southeast Zone"],
})

zone_report = (
    fact_ventas
    .merge(dim_tiempo, on="time_key")
    .merge(dim_ubicacion, on="location_key")
    .merge(zone_map, on="region")
    .groupby(["zone", "quarter"], as_index=False)["sales_amount"]
    .sum()
    .rename(columns={"sales_amount": "total_sales"})
    .sort_values(["zone", "quarter"])
)

zone_report

	zone	quarter	total_sales
0	North-Central Zone	Q1	290
1	North-Central Zone	Q2	306
2	West-Southeast Zone	Q1	306
3	West-Southeast Zone	Q2	285

17.6 Data Marts to Data Products

In modern data architectures, data marts have evolved into data products within a data mesh framework: domain teams own their data marts as products complete with SLAs, quality contracts, and standardized consumption APIs (Dehghani 2022). The next chapter explores how to expose this data mart via REST and semantic layer APIs.

17.7 Conclusions

A data mart bridges raw operational data and business analytics. Adopting a Kimball bus architecture with conformed dimensions guarantees that individual data marts scale incrementally without degrading into isolated data silos.

17.8 References

Dehghani, Zhamak. 2022. Data Mesh: Delivering Data-Driven Value at Scale. O’Reilly Media.

Devlin, Barry A., and Paul T. Murphy. 1988. “An Architecture for a Business and Information System.” IBM Systems Journal 27 (1): 60–80. https://doi.org/10.1147/sj.271.0060.

Inmon, William H. 2005. Building the Data Warehouse. 4th ed. Wiley.

Kimball, Ralph, and Margy Ross. 2013. The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling. 3rd ed. Wiley.