Design a Star Schema

A star schema is one fact table surrounded by dimension tables. Write the model document that names the tables, the grain and the joins.

Validator

⏱ 0:00

IDLE — checks run live as you type commands; submit when done

01Requirements

live checks

5 steps

01
Create the model directory
The model document is reviewed like code - it lives with the pipeline that fills it.
mkdir -p ~/warehouse/model
02
Name the fact table and its grain
The grain is the answer to one row is what. Say it out loud before you design anything - it decides every key downstream.
echo '# Order warehouse model\n\n## fact_orders\n\nGrain: one row per order line item.\nColumns: order_line_id, order_id, customer_key, date_key, product_key, amount; > ~/warehouse/model/dimensions.md
03
Add the customer dimension
Dimensions hold the descriptive attributes. Join on the surrogate key, never on the business key - business keys change.
echo '\n## dim_customer\n\nJoin key: customer_key. Holds name, segment and country.' >> ~/warehouse/model/dimensions.md
04
Add the date dimension
The date dimension is the one everybody underestimates - it carries weekday, month, quarter and the fiscal calendar.
echo '\n## dim_date\n\nJoin key: date_key. Holds day, weekday, month, quarter and fiscal period.' >> ~/warehouse/model/dimensions.md
05
Verify and submit
cat the document, then submit for validation.
cat ~/warehouse/model/dimensions.md

0 of 3 revealed

Take a hint without losing the lab — each one points at the thing to look at, not at the answer.

guides, never solves

Tell me what you're stuck on — I'll nudge, not solve. Which requirement are you looking at?

saved locally in this browser

learner@lab — ubuntu:24.04

Session is disposable

↑/↓ recalls commands · Ctrl+Enter submits · type help for the command list

← Previous lab

Read a Query Plan

SQL & Query Craft

Next lab →

Handle Changing Dimensions

Modeling & Warehousing