Define a Course Case Study with Source Systems, Business Processes, KPIs, SLAs, Security, and Data Quality Expectations

Learning outcomes

The remaining 29 chapters need one stable case study so examples do not mutate silently. AtlasMart therefore needs a written contract for sources, business processes, candidate analytical questions, KPI semantics, freshness commitments, security boundaries, and data-quality expectations. This lesson creates that baseline without prematurely designing the star schema that Chapters 02–06 will derive.

1. Source systems and authority

“Authority” means which source owns the operational meaning in this fictional case study. It does not mean the warehouse should query that source for every dashboard request. Ingestion preserves the source key, source timestamp/position, ingestion batch identity, and raw evidence needed for replay where policy permits.

2. Business processes come before schemas

The table describes business reality, not warehouse tables. One process can later require several fact-table types, and one physical table must not mix incompatible grains merely because columns overlap.

3. Baseline KPI contracts must expose filters and exclusions

For the Chapter 01 fixture, paid_gmv = 625, paid_order_count = 4, average_paid_order_value = 156.25, paid units are 9, and current on-hand units are 137. Those numbers are control totals for this synthetic dataset only.

4. SLA, SLO, freshness, and quality are different contracts

An SLO is an internal target for service/data behavior; an SLA is a formal commitment whose consequences depend on the organization’s agreement. This course does not invent a legal contract. AtlasMart’s case study records operational targets and a fictional business availability commitment so later lessons have something measurable.

Data quality is separate from freshness. A dataset can arrive on time and be wrong. The baseline quality rules include required keys, positive quantities, nonnegative prices/inventory, referential integrity, uniqueness at the source key, accepted status values, and exact reconciliation of certified paid-GMV totals to the defined source control population.

5. Security and privacy are end-to-end properties

Dashboard row/column filters are not sufficient if the same user can bypass them through raw-table access or exports. Later chapters test effective privileges, lineage, copies, backups, and retention rather than assuming the front-end policy is the whole control.

6. Controlled failure: a KPI spreadsheet becomes the source of truth

Finance emails a spreadsheet containing “revenue,” sales copies the number into a dashboard, and data engineering later ingests the dashboard export because it is convenient. The lineage becomes circular: the reported output feeds the analytical input, the original filter logic is unknown, and reconciliation to the ERP is impossible.

The repair is to keep source authority and derived certification explicit. Human corrections can be legitimate, but they need their own governed input contract, owner, reason, effective period, and audit trail; they must not masquerade as original source evidence.

7. Hands-on lab — freeze the Chapter 01 AtlasMart contract

Save the contract below as atlasmart_contract.json. It is intentionally small; later chapters may extend it only by explicit versioned change.

{  "case_study": "AtlasMart",  "timezone": "UTC",  "sources": [    {"id":"erp","authority":["orders","order_lines","payments","returns"],"freshness_slo_minutes":30},    {"id":"crm","authority":["customer_profile","customer_segment"],"freshness_slo_minutes":60,"schedule":"daily 02:00 UTC"},    {"id":"inventory","authority":["on_hand_snapshot"],"freshness_slo_minutes":45}  ],  "metrics": {    "paid_gmv": {"formula":"sum(quantity * unit_price) for parent orders where status = paid","fixture_control":625},    "paid_order_count": {"formula":"count distinct paid order_id","fixture_control":4},    "average_paid_order_value": {"formula":"paid_gmv / paid_order_count","fixture_control":156.25},    "on_hand_units": {"formula":"sum(on_hand) for one chosen inventory snapshot","fixture_control":137}  },  "quality": {    "required_keys":["order_id","customer_id","product_id"],    "rules":["quantity > 0","unit_price >= 0","on_hand >= 0","referential integrity holds"]  },  "security": {    "raw_pii":"restricted",    "certified_analytics":"least privilege",    "bi_service":"read only"  }}

import jsonfrom decimal import Decimalfrom pathlib import Pathc = json.loads(Path("atlasmart_contract.json").read_text(encoding="utf-8"))assert c["case_study"] == "AtlasMart"assert c["timezone"] == "UTC"assert {s["id"] for s in c["sources"]} >= {"erp", "crm", "inventory"}for s in c["sources"]:    assert s["authority"], s["id"]    assert s["freshness_slo_minutes"] > 0m = c["metrics"]assert Decimal(str(m["paid_gmv"]["fixture_control"])) == Decimal("625")assert m["paid_order_count"]["fixture_control"] == 4assert Decimal(str(m["average_paid_order_value"]["fixture_control"])) == Decimal("156.25")assert m["on_hand_units"]["fixture_control"] == 137assert c["security"]["bi_service"] == "read only"print("contract valid")print("sources:", [s["id"] for s in c["sources"]])print("metrics:", sorted(m))

Run python validate_contract.py. Expected evidence is contract valid, the source IDs, and the sorted metric names. Deliberately change paid_gmv.fixture_control from 625 to 626; the validator must fail. Restore it and rerun.

Cross-check against the SQL fixture: paid GMV 625, four paid orders, AOV 156.25, on-hand 137. Cleanup: delete only atlasmart_contract.json and validate_contract.py from the lab directory.

8. What later chapters are allowed to change

Chapter 02 may refine requirements and declare fact-table grain. Chapters 03–11 may introduce fact/dimension structures, surrogate keys, SCDs, bridges, snapshots, and correction policy. Chapters 12–16 may formalize source contracts, quality, incremental/CDC behavior, and orchestration. Later chapters may change physical layout, semantic tooling, cloud platform, or lakehouse integration.

What must not change silently is the evidence chain: source authority, business event meaning, metric version, history policy, security requirement, control totals, and migration/reconciliation procedure. A course case study is useful only when each chapter can explain how its new design preserves or deliberately changes that chain.

9. Chapter 01 acceptance checklist

• AtlasMart source systems and authorities are named.
• Business processes are described without prematurely equating them to tables.
• Baseline KPI formulas and fixture control totals are explicit.
• Freshness targets identify source/consumer boundaries.
• Security roles separate ingestion, engineering, analyst, BI, and emergency administration.
• Data-quality rules are measurable and reconciled.
• All mandatory artifacts are local, synthetic, replayable, and deletable.
• Physical warehouse/cloud/lakehouse product choice remains open.

10. Production judgment and bridge to Chapter 02

AtlasMart now has enough stable context to design analytically without guessing. The next chapter starts from stakeholders and decisions, identifies business processes, declares grain in one precise sentence, and builds a requirements-to-model traceability matrix. That order matters: the warehouse model should be a consequence of questions and source reality, not a diagram chosen first.

Knowledge check

Summary and next step

Chapter 01 ends with a reproducible AtlasMart contract: sources, processes, metrics, freshness, quality, security, and control totals are explicit while physical implementation remains open.

Continue to Chapter 02: Start from Decisions and Questions: Stakeholders, Use Cases, Reports, Explorations, and Data Products.

Authoritative references

• Big Data Academy — Data Warehousing and Dimensional Modeling — Authoritative chapter/lesson sequence and course scope.
• Kimball Group — Declaring the Grain — Why precise row meaning follows business process/source reality and precedes dimensional details.
• Kimball Group — Grain — Binding grain contract and atomic-grain guidance used in Chapter 02.
• Kimball Group — Enterprise Data Warehouse Bus Matrix — Process/dimension planning context for later conformance work.
• Python documentation — json — Standard-library parser used to validate the local case-study contract.