Practice — Hot · The Inherited Model
Ungraded. Like L02's recipe review, this is a judgment exercise — you inherit a model, you audit it, you write the fix as if the builder will read it.
Scenario
An analyst leaves the company; you inherit their Lantern & Pine model. It works — reports render, numbers appear — and the handoff note is proud of three design decisions:
| # | Their decision | Their reason |
|---|---|---|
| 1 | Category was merged into sales in Power Query, and the products table deleted from the model | "One less table — simpler is better" |
| 2 | returns ↔ sales related on OrderID, many-to-many, bidirectional | "So returns and sales stay connected both ways" |
| 3 | The targets table (1,080 rows: region × category × month) is loaded but related to nothing | "Its columns didn't match any ID column, so I left it alone" |
Your review
- For each decision, write a verdict — sound, partially sound, or wrong — with the concrete downstream consequence. Consequences, not vibes: name a question the model now answers wrongly or cannot answer at all. (Decision 1 deserves the most careful thought: it worked in Lesson 3, so what changed?)
- Rebuild the model correctly — you have the CSVs and the lesson; your A04 star is most of the answer. For decision 3, propose how targets could join the model: what would the star need that it does not yet have? (You are not required to build that piece — naming it precisely is the task. It arrives for real in Lesson 6.)
- Write the handoff note back — five or six sentences a departed colleague could read without flinching: what you kept, what you changed, and the one principle that decides all three cases.
Hint — decision 1 is the subtle one
Merging Category into sales was exactly right in Lesson 3 — when sales was the only fact. Now ask: with products deleted, how does the returns table get a Category? Merge it there too? Now Category lives in two places. Finance's targets also carry a Category. Three copies, maintained separately, drifting independently — and the question "return rate by category" now depends on three columns agreeing. What was the dimension actually for?
Reflection
- All three decisions came with reasons, and the reasons sounded like principles ("simpler is better," "connected both ways," "don't force what doesn't fit"). What distinguishes a modeling principle from a modeling slogan?
- Decision 3 was actually the closest to defensible. Why is "related to nothing" less dangerous than decisions 1 and 2?