Power BI Semantic Models Explained Like You're Five

Two dashboards, two different revenue numbers, same meeting. If that's ever happened to you, you've already met the problem a semantic model exists to solve — you just haven't met the term yet.

Imagine a restaurant kitchen. In the back, there's a walk-in fridge stuffed with raw ingredients — tomatoes, flour, chicken, cheese — none of it useful to a hungry customer on its own.

Now imagine a customer orders soup. If every server just ran into the fridge and grabbed whatever looked right, table four's soup would taste nothing like table seven's soup, and neither would taste the same way twice. That's what a business runs on before it has a semantic model — reports built straight from raw data, calculated a slightly different way by whoever happened to build them.

A semantic model is the recipe book sitting between the fridge and the dining room. It doesn't hold the ingredients itself — it defines how they connect, what a proper bowl of soup actually contains, and hands out the exact same dish to every table, every time, no matter who's working the kitchen that day.

• 🥕 Tables are the ingredients — raw, sitting in the fridge, not useful by themselves
• 🔗 Relationships are how they connect — this sauce goes with this pasta, this customer goes with this order
• 📖 Measures are the recipes — the same formula, followed the same way, every single time

Here's the rest of the kitchen.

The Fridge: Tables

A table is just a list of one kind of thing — customers, orders, products — sitting in its own drawer. A drawer of customers doesn't tell you what they bought. A drawer of orders doesn't tell you who placed them. Each one, alone, is an ingredient waiting for a recipe that hasn't been written yet.

The Recipe Cards: Relationships

A relationship is what tells the kitchen that this sauce goes with that pasta — or, less deliciously, that this row in the orders table belongs to that row in the customers table. Without it, "how much did each customer spend" isn't answerable, because nothing has told the kitchen those two drawers are even talking about the same meal.

Most well-run kitchens organize this the same way: one big pot of orders in the middle — Microsoft calls this a star schema — surrounded by smaller prep bowls of context around it: customers, products, dates. The pot does the heavy lifting; the bowls just say who, what, and when.

Here's the same idea without the kitchen — a real star schema, drawn the way a data model actually looks.

One fact table at the center, connected to five dimension tables — each relationship is one dimension row to many fact rows, which is what gives a star schema its shape and its name.

The Recipes: Measures

A measure is a calculation with a name — "Total Revenue," "Average Order Size" — written once and followed exactly the same way every time it's used. The recipes in this kitchen happen to be written in a language called DAX, which is really just shorthand for "add this, divide by that." Nobody needs to speak the shorthand to enjoy what comes out of the kitchen; someone just needs to have written it correctly, once. (If the fifty most useful recipes in that shorthand sound worth knowing, we've got a full breakdown coming soon — worth a bookmark.)

The Head Chef: Security

Not everyone gets a key to every part of the walk-in fridge. A regional sales rep can usually see their own region's numbers and nobody else's — the same recipe book, the same kitchen, but a rule that quietly limits which drawer each person is allowed to open. In Power BI this is called row-level security, and it works the same way behind the scenes no matter who's asking.

There's a second kind of key, too: some staff can't see certain ingredients at all, no matter which drawer they're in — a cost or margin figure kept off-limits to anyone outside finance. Microsoft calls this object-level security, the sibling to row-level security: one limits which rows a person sees, the other hides whole columns or tables outright. Together with who's allowed to edit a recipe in the first place, this is what falls under the broader umbrella Microsoft calls governance.

Restocking the Fridge: Refresh

The fridge doesn't restock itself. A delivery truck shows up on a schedule — every night, every hour, whatever the kitchen has arranged — and swaps yesterday's ingredients for today's. If the truck doesn't come, the kitchen keeps cooking with what it already has, which is why a report can look "wrong" simply because it's a day behind, not because anything actually broke.

There's a newer trick, too: kitchens built inside Microsoft Fabric can skip the delivery truck almost entirely. Instead of waiting for a scheduled restock, they read straight from a shared pantry called OneLake that other parts of the business are already stocking — what Microsoft calls Direct Lake. The practical effect is data that's nearly as current as constantly calling the supplier, without paying the price that usually comes with checking in on every single order.

Every table in the dining room is served from the same recipe book — different plates, same kitchen, same consistent numbers.

Why One Recipe Book Beats Ten

Without a shared recipe book, every report is its own kitchen improvising from the same fridge. "Revenue" ends up meaning three slightly different things depending on which analyst built which report, and nobody notices until two dashboards disagree in a meeting. A semantic model doesn't make the business simpler — it makes sure everyone arguing about the numbers is at least arguing about the same number.

Away from the kitchen for a moment: picture a retail chain where every store manager keeps their own weekly sales spreadsheet. By the time headquarters compares stores, "sales" already means five different things — some count returns, some don't; some use the order date, some the ship date. A shared semantic model fixes this not by making anyone's job harder, but by moving that one decision — what "sales" actually means — into a single place every report pulls from automatically. That's semantic model reuse in practice: the definition gets written once and reused everywhere, instead of rewritten, slightly differently, every time.

Common Misconceptions

• "A semantic model is just a database." Not quite — a database stores the ingredients; a semantic model defines how to cook with them. The same database can sit underneath several different semantic models, each with its own recipes.
• "Once it's built, it's done." A recipe book still gets edited — new dishes added, old ones tweaked — every time the business starts asking a new kind of question.
• "Every report needs its own version." That's exactly the problem a semantic model solves — one recipe book, shared by every table in the dining room, not a new cookbook per server.
• "It only matters for big companies." Even a kitchen of one benefits from writing recipes down instead of remembering them by feel — consistency matters at any size.
• "DAX is only for experts." It's the kitchen's shorthand, not a foreign language — everyone who uses it fluently today started out not knowing it.

Recognize one of these misconceptions from your own team? Let's talk about what's actually happening in your reports.

FAQ

Is a semantic model the same thing as a "dataset"?

In Power BI, yes — Microsoft renamed the dataset content type to semantic model a while back. Same thing, more accurate name.

Do I need to know DAX to understand a semantic model?

No. Understanding what a semantic model does doesn't require writing DAX any more than enjoying a meal requires knowing how to cook it.

Can one semantic model feed more than one report?

Yes — that's the whole point, often called semantic model reuse. One recipe book, as many dining rooms as needed, all serving the same consistent dish.

Who usually builds the semantic model?

Typically a BI developer or data analyst — the head chef — while report authors build the visuals on top of it, closer to servers plating dishes from what the kitchen already prepared.

What happens if the semantic model has a mistake in it?

Every report built on it inherits the mistake — which is exactly why getting the recipe right once matters more than getting any single dish right once.

Is a semantic model different inside Microsoft Fabric?

Not really — same tables, same relationships, same recipes. Fabric just means the kitchen can share a pantry (OneLake) with other parts of the business, and can use the faster restocking trick called Direct Lake described above.

Can Copilot build the semantic model for me?

It can draft measures and even write descriptions for the ones that don't have any yet — a genuinely useful head start. It still needs a head chef to check the recipes came out right — we're publishing a full look at what Copilot can and can't do in Power BI soon.

Does a semantic model require Power BI Premium or Fabric capacity?

No — a semantic model works fine on Power BI Pro. Premium or Fabric capacity unlocks specific capabilities, like Direct Lake and higher refresh limits, but the model itself doesn't need either to exist.

Closing the Loop

None of this makes semantic models sound smaller than they are — they're still real, technical, sometimes genuinely complicated things to build well, and a handful of well-known best practices (a clean star schema, sensible security, measures that are actually documented) separate a kitchen that scales from one that doesn't. But the idea underneath all of it is simple: a kitchen works better with one recipe book than with every server improvising from the fridge, and a business runs on numbers it can trust more than numbers it has to double-check every time someone asks a question.