Module 6 of 16

Marts: Facts and Dimensions

Create the business-facing layer: facts, dimensions, and star schemas.

110 minutes1 exercisesFree

Start here

Learning objectives

  • Design simple fact and dimension tables
  • Understand star schema basics
  • Choose the right mart grain for reporting
Marts: Facts and Dimensions Follow the arrows. Each box is one idea you will practice in this module. Facts step 1 Dimensions step 2 Keys step 3 Schema step 4 Users step 5 Production analytics engineering turns raw records into governed, trusted business meaning.

The Mental Model

Marts are the tables business users and dashboards should trust. Facts store measurable events; dimensions store descriptive context.

If staging is clean ingredients and intermediate is prep work, marts are the served plates. This is the layer people actually consume.

Tiny Example

We will use a small ecommerce dataset throughout the course. Think of these as the only tables in your first warehouse:

TableGrainExample columns
raw_ordersone row per order eventorder_id, customer_id, amount, status, created_at
raw_order_itemsone row per item inside an orderorder_id, product_id, quantity, item_price
raw_customersone row per customercustomer_id, email, country, created_at

Interactive Check

Question: Should customer country live in fct_orders or dim_customers?

Reveal the answer

Usually dim_customers owns customer country. fct_orders can join to it for analysis, but the descriptive customer attributes belong in the customer dimension.

Inline Practice Lab

This lab is intentionally small. You can solve it by reading the table, writing the SQL/YAML mentally, or pasting the snippet into any SQL scratchpad later.

-- Example starter table
select
  order_id,
  customer_id,
  amount,
  status,
  created_at
from raw_orders;

The goal is not tooling setup. The goal is learning the production habit: state the grain, clean one thing, test one assumption, and explain the downstream impact.

Self-Check Quiz

  1. What is the grain of the table you are building?
  2. Which downstream metric or dashboard would be wrong if this model broke?
  3. What test would catch the most likely beginner mistake here?

Real world

Where this shows up

  • Reliable executive dashboards that do not disagree across teams
  • AI analytics agents that query governed metrics instead of guessing SQL
  • Auditable metric changes where owners can see downstream impact before merge

Production notes

Keep these close

  • Name marts based on business concepts, not source systems. Business users do not care which app emitted the raw table.

Common mistakes

What usually breaks

  • Creating one giant flat table for every question
  • Putting measures in dimensions
  • Ignoring slowly changing attributes

Think like an engineer

Questions to answer before shipping

  • Can you explain the grain of this model in one sentence?
  • What breaks downstream if this field becomes null tomorrow?
  • Where should this logic live so it is reused instead of copied?

Key terms

Vocabulary used in this module

Mart

A business-facing model intended for analytics consumption.

Dimension

A descriptive table such as customers, products, or accounts.

Exercises

Practice inside the lesson

30-45 minutesBeginner to Intermediate

Design an Ecommerce Mart

Create a simple star schema with fct_orders, dim_customers, and dim_products.

  1. List each table grain
  2. Choose primary keys
  3. Choose foreign keys
  4. Choose three measures on fct_orders
  5. Choose five descriptive columns for dimensions

Recap

Key takeaways

  • Marts should be easy and safe for downstream consumers
  • Facts and dimensions make reporting grain explicit
  • Star schemas remain useful even in modern warehouses

Related resources

Keep learning across CodersSecret