Chapter 01 · Data Warehouse Foundations: OLTP vs OLAP, Analytical Workloads, Architecture, and Lab Dataset
Classic Enterprise Warehouse, Dimensional Bus, Modern ELT, and Lakehouse-Centric Architectural Styles
Compare centralized enterprise warehouse, dimensional bus, modern ELT, and lakehouse-centric styles by integration, delivery, replay, and semantic contracts.
Learning outcomes
AtlasMart leadership wants a “modern architecture,” but the phrase is not a requirement. A centralized enterprise warehouse, an incremental dimensional bus, ELT inside an analytical platform, and a lakehouse-centric design place integration and transformation work differently. This lesson compares those styles by evidence and constraints rather than by fashion.
Explain centralized enterprise-warehouse, dimensional-bus, modern-ELT, and lakehouse-centric styles without treating them as mutually exclusive products.
Identify where each style establishes integration, business semantics, and serving contracts.
Separate transformation placement (ETL/ELT) from logical dimensional modeling.
Evaluate an architecture against AtlasMart delivery cadence, source diversity, governance, replay, BI usability, and operational complexity.
Write an architecture decision record whose claims can be revisited when requirements change.
Use only the lesson’s synthetic/local fixture for destructive setup, reset, correction, backfill, or cleanup steps. Record the stated runtime/version and assumptions, preserve the AtlasMart control totals, and never point cleanup commands at production data or credentials.
1. Architecture style answers “where do integration decisions live?”
A warehouse architecture must decide where source diversity is reconciled, where historical meaning is preserved, how reusable business definitions are shared, and how new analytical products are delivered. The four styles in this lesson are lenses on those decisions. Real platforms often combine them.
2. Classic centralized enterprise warehouse style
A classic centralized enterprise-warehouse approach integrates enterprise data into a centrally governed model before downstream presentation. Its strength is explicit enterprise integration; its risk is that broad centralized modeling can delay delivery if every domain must be resolved before useful output appears. The label does not prescribe a specific database or prohibit dimensional marts.
For AtlasMart, this style would emphasize a durable integrated enterprise layer for customer, product, order, fulfillment, and finance semantics, with marts derived afterward.
3. Dimensional bus architecture
Kimball’s bus architecture decomposes delivery by business process while integrating through reusable conformed dimensions. The bus matrix places business processes on rows and dimensions on columns. Teams can deliver one process at a time while preserving cross-process compatibility.
| AtlasMart process | Customer | Product | Date | Channel | Candidate delivery |
|---|---|---|---|---|---|
| Orders | ✓ | ✓ | ✓ | ✓ | Atomic order-line analytics |
| Returns | ✓ | ✓ | ✓ | ✓ | Return-event analytics |
| Inventory | ✓ | ✓ | Periodic inventory snapshot | ||
| Fulfillment | ✓ | ✓ | ✓ | Shipment/milestone analytics |
This is only an early planning sketch. Chapter 06 builds the actual bus matrix after Chapters 02–05 establish grain, facts, and dimensions.
4. Modern ELT changes transform placement, not the need for semantics
ETL transforms before loading the analytical target; ELT loads source-shaped data first and performs transformations using the target platform’s compute. Modern cloud warehouses and analytical engines make ELT attractive because storage and compute can scale independently and SQL transformations are easy to version and push down.
ELT does not answer what one fact row means, how customer history should be interpreted, or whether two marts share a metric definition. Those are modeling and governance decisions. A team can build excellent dimensional models with ELT or poor ones with ETL.
5. Lakehouse-centric architecture changes the storage/control plane
A lakehouse-centric style commonly keeps durable analytical data in object storage managed through table metadata/protocols, then attaches query engines, transformations, governance, and serving layers. This can improve interoperability and separate storage from compute, but it does not eliminate the need to define business process grain, quality, security, lineage, or BI-facing semantics.
AtlasMart might later store curated tables in an open table format while still exposing dimensional marts and governed metrics. Chapter 28 treats that coexistence directly; Chapter 03 should not pre-decide it.
6. Compare styles against requirements instead of slogans
| Decision surface | Centralized EDW style | Dimensional bus | Modern ELT | Lakehouse-centric |
|---|---|---|---|---|
| Integration focus | Central integrated enterprise model | Conformed dimensions/facts across processes | Depends on transformation models | Depends on curated table/semantic contracts |
| Incremental delivery | Can be slower if enterprise model blocks delivery | Explicit process-by-process delivery | Usually supports modular transformation graphs | Can support domain/layered delivery |
| Raw replay | Architecture-specific | Architecture-specific | Often natural because source-shaped data lands first | Often natural in object storage |
| BI usability | Usually through downstream marts/semantic models | Core design goal | Depends on modeled presentation outputs | Depends on serving/semantic layer |
| Primary failure mode | Central bottleneck or over-modeling | False conformance or inconsistent process grain | “Load first, define later” semantic debt | Treating storage format as a complete analytics architecture |
7. Controlled failure: choose “lakehouse” because it sounds newest
AtlasMart could migrate every CSV into object storage, register tables, and declare the modernization complete. Finance would still disagree with sales about paid revenue; customer history could still be overwritten; dashboards could still query incompatible grains. The architecture would be physically modern but semantically uncontrolled.
The repair is to write the decision in terms of requirements: preserve raw evidence, deliver sales analytics incrementally, share customer/product/date semantics across processes, support a 30-minute order-data target, keep mandatory labs local, and allow the physical engine to change. A future lakehouse may satisfy those requirements, but the requirements exist independently of the label.
8. Hands-on lab — write and challenge an architecture decision record
Save the following as ADR-001.md. Then review each
decision against one concrete requirement. For example, if
AtlasMart no longer needs cross-process analysis, conformance
may be relaxed; if the 30-minute target becomes five seconds,
ingestion architecture must change. The ADR is useful only if
its assumptions can be falsified.
# ADR-001 — AtlasMart analytical architecture baselineStatus: accepted for the course case studyDate: 2026-09-20Context- Multiple operational sources with different freshness.- Need incremental business-process delivery.- Cross-process customer/product/date consistency is required.- Mandatory course labs must be local and replayable.- Physical warehouse technology must remain replaceable.Decision- Preserve source-shaped evidence before business transformations.- Organize analytical delivery by business process.- Use explicit conformance contracts for shared dimensions/metrics.- Prefer transformations that are versioned, testable, and replayable.- Keep semantic definitions downstream of atomic analytical evidence.- Treat lakehouse/cloud choices as physical implementations, not semantic truth.Consequences- More metadata, tests, and reconciliation are required.- New processes can be delivered without waiting for a universal enterprise model.- Shared dimensions/metrics require stewardship rather than copy/paste reuse.- A later engine migration must preserve grain, history, and metric behavior.Verification: every decision maps to at least one stated requirement; no product name is required for correctness; ELT/lakehouse are not used as substitutes for grain or metric definitions; consequences include operational cost. Cleanup: delete the local ADR copy after the exercise or keep it as course notes.
9. Production judgment
Architecture style is a decomposition strategy. AtlasMart’s course baseline deliberately combines incremental business-process delivery, conformance contracts, replayable source evidence, and versioned transformations while leaving the physical engine open. This gives later chapters a stable semantic target without pretending that one architecture fits every organization.
The next lesson moves from architecture style to update cadence: batch, micro-batch, CDC, streaming, and measurable freshness.
Knowledge check
Check your understanding
- Why is ELT not an alternative to dimensional modeling?
- What does the dimensional bus integrate across independently delivered business processes?
- What problem can a centralized enterprise model create if treated as a prerequisite for every delivery?
- Why can a lakehouse-centric design still need marts and a semantic layer?
- What makes an architecture decision record testable rather than decorative?
Review the answers
1. ELT describes where transformations execute; dimensional modeling defines analytical row meaning, dimensions, measurements, and query semantics.
2. Conformed dimensions and compatible facts/definitions that preserve shared meaning across processes.
3. It can become a delivery bottleneck if teams wait for a universal model before shipping useful analytical products.
4. Table/storage architecture does not automatically create user-friendly grains, certified metrics, policy, or BI contracts.
5. Its assumptions, requirements, decisions, and consequences are explicit enough that new evidence can confirm or invalidate them.
Summary and next step
Centralized EDW, dimensional bus, modern ELT, and lakehouse-centric styles place integration and transformation responsibilities differently. Compare them using delivery, conformance, replay, governance, serving, and operational constraints—not age or popularity.
Next: Batch, Micro-Batch, Streaming/CDC, and Near-Real-Time Warehousing: Freshness vs Complexity Tradeoffs.
Authoritative references
- Kimball Group — Enterprise Data Warehouse Bus Architecture — Primary source for the business-process/conformed-dimension architecture taught here.
- Kimball Group — Enterprise Data Warehouse Bus Matrix — Rows as processes, columns as dimensions, and incremental delivery planning.
- Kimball Group — Dimensional Modeling Techniques — Named dimensional techniques used throughout the course.
- Apache Iceberg documentation — Authoritative example of an open table-format control plane; not a complete warehouse architecture by itself.
- Big Data Academy — course curriculum — Current course scope and sequence.