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
materials/
official-course-map.md
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 - full source map and honest out-of-scope list in materials/official-course-map.md.
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.