The leader track 🤝 · for C-level, heads of data & curious minds · 6 x 45 min · no code to write
Thinking mode: why every disagreement about a number is really a disagreement about grain, what a bad model costs in rework and lost trust, how to make one metric mean one thing, what to buy versus standardise, who owns a table, and why an AI analyst is only as good as the model beneath it. Each session ends with the questions to ask your data team.
Why the schema decides everything
Every dashboard argument traces back to a modeling choice somebody made in a hurry. Where those choices live, and why they outlive the tools.
💸 Leader 2 · easyThe cost of a bad model
Duplicate customers, the metric nobody trusts, the quarterly rework tax - what a schema shortcut actually bills you, and when to pay to fix it.
🎯 Leader 3 · mediumGrain, and one number one meaning
The single most useful sentence in data: "one row is one ___". How to run a meeting where two teams stop having different revenue numbers.
🧰 Leader 4 · mediumThe tooling landscape
ERD tools, dbt, catalogs, semantic layers - read as decisions rather than logos, with what to buy, what to standardise, and what to skip.
🏷️ Leader 5 · mediumNaming standards and ownership
Conventions that survive team turnover, who may change a table, and how a data contract turns a model into something other teams can depend on.
🤖 Leader 6 · mediumAgent-ready data
Text-to-SQL and AI analysts are only as accurate as the model underneath. What to fund so "ask your data a question" actually works.
The builder track 🛠️ · for practitioners · 10 sessions x 45 min (b10: 60) · live SQLite in your browser
One running project: Bazaar, a multi-merchant ecommerce marketplace. You design its transactional schema from a flat export (b1-b4), find out why analysts cannot query it (b5), build six dimensions and three fact tables they can query (b6-b7), answer four real business questions with the result (b8), publish it so an AI agent gets the right answer (b9), and extend the whole thing to returns and refunds in the capstone (b10). Every page runs real SQLite compiled to WebAssembly - editable, offline after one 660 KB load - and every session ships files into sql/, python/ and semantic/.
Bazaar's source reality
From one flat export to eight entities. The conceptual / logical / physical ladder, and the first thing wrong with the spreadsheet everyone works from.
🧪 Builder 2 · easyThe anomaly lab
Four levers, one wide table, real UPDATE/INSERT/DELETE probes. Turn the anomalies off one by one and derive 3NF instead of memorising it.
🔗 Builder 3 · mediumER, cardinality and keys
Resolve the many-to-many, pick natural versus surrogate keys, and decide what a composite key is really saying about your grain.
⚙️ Builder 4 · mediumPhysical OLTP
Types, NOT NULL, CHECK, foreign keys and the first indexes - then ship the DDL and generate 90 days of deterministic marketplace data.
🧭 Builder 5 · mediumWhy analysts cannot query OLTP
Write the business question against the source schema, feel the pain, then meet grain, conformance and the two-model split that fixes it.
📐 Builder 6 · hands-onDimension design
Six dimensions, surrogate keys, flat-and-wide over snowflaked, no NULLs ever, and slowly-changing type 2 where history actually matters.
📊 Builder 7 · hands-onFact design
Three facts, three grains: what was sold, what was paid, what was wanted. Additivity, degenerate dimensions, and why you never join two facts.
🔍 Builder 8 · hands-onAnswering the four questions
Which merchant dropped, why sales fell, why one day collapsed, when the peak hours are - built as marts, and one hypothesis dies on the evidence.
🤖 Builder 9 · hardestAgent-ready modeling
Schema card, metric table, data contract, golden question set - then measure it: the same agent scores 0/20 without them and 20/20 with them.
🏁 Builder 10 · hardest · 60 minCapstone: returns and refunds
A brand-new subject area, all the way down the ladder - entities, keys, DDL, dimension, fact, mart, agent view - and 27 validation checks green.
What you leave with - runnable, not slideware
01_oltp_ddl.sql
02_seed.sql
10_dim_ddl.sql
11_fact_ddl.sql
12_oltp_to_star.sql
20_marts.sql
30_business_questions.sql
40_agent_views.sql
gen_bazaar_data.py
build_star.py
validate_model.py
answer_questions.py
agent_text_to_sql.py
agent_query_to_text.py
eval_golden_questions.py
schema_card.md
contract.yaml
golden_questions.jsonl
This is the prerequisite the deng bucket was missing: the schema that learn-sql-with-phoebe hands you to query is a schema somebody designed - this is where that work happens. Take it before learn-sql if you are starting fresh, or after it if you already write SQL and want to know why the tables look like that. Next along the ladder: learn-data-warehouse-with-phoebe operates the star you design here, and learn-data-engineering-with-phoebe builds the pipelines that fill it.
Built from Kimball & Ross (The Data Warehouse Toolkit), Inmon, relational-theory fundamentals, the dbt layering and model-contract conventions, and published text-to-SQL benchmark practice - every source named on the session that uses it, with an honest out-of-scope list.
Choose your path 🗺️
Two doors, one marketplace. Leaders never write code; builders never sit through theory they have not just run themselves.
The knowledge map 🧠
Both tracks at a glance - hover a session to spotlight its concepts, click any node to jump in.
The whole course on one sheet 📐
Seven modules: both tracks, why two honest teams report two different numbers, the Bazaar source reality, the builder ladder from source to semantic layer, the star it builds, the four expensive failures that dimension rules exist to prevent, and the four questions that are the exam.
learn data modeling
with phoebe
SEC-01 Two tracks
LEADER TRACK / NO CODE
- a1Why the schema decides everything
- a2The cost of a bad model
- a3Grain, and one number one meaning
- a4The tooling landscape
- a5Naming standards and ownership
- a6Agent-ready data
BUILDER TRACK / REAL SQL
- b1Bazaar's source reality
- b2The anomaly lab
- b3ER, cardinality and keys
- b4Physical OLTP
- b5Why analysts cannot query OLTP
- b6Dimension design
- b7Fact design
- b8Answering the four questions
- b9Agent-ready modeling
- b10Capstone: returns and refunds
SEC-02 The disagreement
You will sit in a room where two competent teams present two different numbers for the same word, and you will be expected to decide which one is right. Almost every time, neither team is wrong and neither is lying. They are counting different rows.
A fact table is where the numbers live, so it is the table people fight about. Almost every fight traces back to the same missing artifact: nobody wrote down what one row means.
SEC-03 The source reality
Every number quoted in the course was produced by running its code against this data. A modelling course on invented rows cannot show you a failure that only appears at scale or at a boundary.
SEC-04 The builder ladder
SEC-05 The star it builds
dimensions6
- four rules govern all six
- history that holds
- stable join paths
- no NULL attributes
facts3
- one grain sentence each
- written first,
- not added later
- as a comment
marts4
- what the business asks
- plus a semantic
- layer an agent
- can query
Each of the four dimension rules answers one of the four failures in the next module. The rules are not a house style; they are the shape those failures left behind.
SEC-06 Four expensive failures
Session b6 builds the six dimensions that prevent the first three. Session b7 writes the grain sentence that prevents the fourth from hiding. Session b10 takes the whole thing to returns and refunds, which is where grain stops being obvious.
SEC-07 The four questions
A model is not good because it is normalized, or star-shaped, or documented. It is good because the questions the business actually asks are cheap and unambiguous to answer with it.