3.1. Design and Implement a Data Model
💡 First Principle: A model is a set of tables plus the rules that connect and describe them. Relationships decide how filters travel; properties decide how columns sort, summarize, and appear to report authors; the date table decides how time behaves. Get these rules right and simple measures return correct answers everywhere; get them wrong and every measure needs a workaround.
Why care? Report authors and Copilot both see the model, not the source. A column sorted alphabetically instead of chronologically, a key column left visible, a relationship filtering the wrong way: each produces reports that look plausible and mislead. The exam tests these as precise settings ("which property should you configure?") and as diagnoses ("why does the total ignore the slicer?").
The mental model is plumbing with valves and labels. Relationships are pipes, cross-filter direction is the valve setting, cardinality is the pipe fitting (one-to-many, one-to-one, many-to-many), and properties are the labels that tell everyone what flows through each pipe and how to measure it.
⚠️ Common Misconception: Power BI can have several active relationships between the same two tables. Only one can be active; the others are inactive (dashed lines) until a measure activates them with USERELATIONSHIP, or you model the dimension separately for each role (3.1.3).
