1.2. Dimensional Modeling Fundamentals
💡 First Principle: People ask business questions in two parts: what happened and in what context. "How much did we sell (what happened) by product, by region, by month (the context)?" Dimensional modeling stores those two parts separately, events in fact tables and context in dimension tables, because that mirrors how questions are asked and how filters need to flow.
Why care? Model shape decides almost everything downstream. A good star schema makes DAX short and correct, keeps the model small, and makes slicers behave predictably. A poorly shaped model forces convoluted DAX, produces wrong totals, and runs slowly. On the exam, "you need to minimize model size" and "you need to simplify the DAX required" are frequently answered by reshaping tables rather than writing cleverer code.
The mental model is a receipt and a catalog. A receipt (fact row) records an event: on this date, this customer bought this product at this store for this amount. It's full of references (product code, store number) and numbers (quantity, price). The catalog (dimension) describes each referenced thing once: product code 1047 is a blue ceramic mug in the Kitchen category. You'd never reprint the full catalog description on every receipt, and a good model doesn't either.
⚠️ Common Misconception: One big flat table is the simplest and fastest model. It feels simple because it resembles a spreadsheet, but it repeats descriptive text on every row, compresses poorly, and makes time intelligence and multiple date roles awkward. A star schema is both smaller and easier to calculate over.
