1.1.2. Semantic Models as the Single Source of Truth
💡 First Principle: When every analyst builds their own copy of "revenue," the organization ends up with five different revenue numbers and a meeting to argue about which is right. A semantic model solves this by defining tables, relationships, and business calculations once, centrally, so every report that connects to it inherits the same answers.
A semantic model (formerly called a dataset) is the governed layer between raw data and reports. It contains the loaded tables (or connections to them), the relationships that link them, the measures that encode business logic (such as Gross Margin %), and the security rules that decide who sees which rows. Reports don't store data; they send queries to a semantic model and render the results.
This separation unlocks a pattern you'll see repeatedly on the exam: the shared semantic model. A central data team publishes one certified model; analysts across the business build their own thin reports that connect to it with a live connection. Each analyst gets self-service freedom over visuals, while the definitions of the numbers stay consistent. If an analyst needs to add their own data, such as a regional targets spreadsheet, they can convert the live connection into a composite model using DirectQuery for Power BI semantic models, which keeps the shared model intact and layers local tables beside it (you'll configure this in 2.1.1).
The single-source principle also explains several governance features covered in Phase 5. Endorsement (promoted and certified) tells users which models to trust. Build permission controls who may create new reports on a model. Row-level security lives in the model, so every report connected to it is protected automatically. Put security or logic in the model and it applies everywhere; put it in a report and it applies only there.
⚠️ Exam Trap: A thin report connected live to a shared semantic model cannot add Power Query transformations or calculated columns to that remote model; it can add only report-level measures. When a stem says the analyst must "add a local Excel table and relate it to the shared model," the answer is a composite model (DirectQuery for Power BI semantic models), not editing the shared model or importing a copy of it.
Reflection Question: Why does placing row-level security in the semantic model, rather than as filters on each report page, make it both more secure and less work to maintain?
