Power BI semantic model

Open any finance slide and find the revenue number. Now go looking for it in the database. You will not find it.

There is no revenue column. There is a quantity, and a unit price, and a returns table, and an amount in whatever currency the sale used. Revenue is quantity times price, minus the returns, changed into the currency you report in. It is a calculation, not a value. Nobody wrote it down as a cell.

So here is the odd part. Three different dashboards, built by three different people, all show the exact same revenue number. They agree on a number that exists in no table. How?

Because somewhere between the raw tables and the reports, one layer defined what "revenue" means, one time, and every report reads that one definition instead of making its own.

A number can be a definition, not a column

It is easy to think analytics is only about columns you add up. Some of it is. But the numbers a business really runs on, revenue, margin, churn rate, active users, are not stored anywhere. They are agreements about how to compute something from the raw rows.

Leave that agreement unwritten and every report ends up with its own version. One analyst forgets to subtract returns. Another adds euros and dollars into the same total. A third counts an order twice because it shipped in two boxes. Each one looks correct on its own. Put them in the same meeting and the numbers do not match, and now the meeting is about whose spreadsheet is right instead of about the business.

The fix is plain and strong. Write the definition once, in a place every report can reach, and do not let anyone change it later. That single named calculation is a measure. Revenue is a measure. Margin is a measure. The point of a measure is not that it is hard to compute. It is that it is computed in exactly one place, so there is exactly one answer.

Facts in the middle, dimensions around them

Measures need something to compute over, and they need something to slice by. That shape has a name, and it looks like a star.

In the middle sits the fact table: the rows that record what happened, one per sale, per click, per reading. Facts are where the numbers live, quantity and price and amount. Around the fact table sit the dimensions: the tables that describe the context, who the customer was, which product, what date, which region. You do not sum a dimension. You group by it. "Revenue by region" means the measure computed over the facts, sliced by the region dimension.

Dimensions also carry hierarchies, and hierarchies do a lot of work. A date is not just a date. It belongs to a month, which belongs to a quarter, which belongs to a year. Set that rollup up once and a single revenue measure answers "by day" and "by quarter" and "by year" without anyone writing three versions. The model knows how the levels nest, so the same number works at every level.

Where a raw sum gives the wrong number

You might think a measure is just a fancy SUM. It is not, and the difference is exactly where careless analytics goes wrong. A raw sum over a column trusts every value as it is: it will add a refund as if it were a sale, and treat eighty euros as eighty dollars, and it will not warn you, because the column never said otherwise.

Switch between the two below. Same four line items: one correct total, and one that is wrong but still looks right.

The raw column gets a number. The measure gets the right number, and it gets it the same way every time, for every report, because the logic sits in the definition, not in whoever happened to write the query. That is the whole reason the layer exists.

The Power BI semantic model

In Microsoft Fabric this clean layer is the Power BI semantic model, the thing Power BI used to call a dataset. It sits over the tables in your lakehouse or warehouse (with Direct Lake storage mode it reads them straight from OneLake; import mode keeps its own copy) and it holds the pieces you just met: relationships between fact and dimension tables in a star schema, measures written in DAX (the formula language where revenue actually gets defined), and hierarchies for the rollups. Reports read from it, and so can a data agent, Fabric's name for an AI agent grounded in your data. Both get the same clean numbers because both read the same definitions.

This is a mature, generally available part of the platform. Semantic models have been the base of Power BI for years, and they are very good at their job: aggregation (adding numbers up) and the known analytical questions. Totals and trends sliced along the dimensions you planned for. Ask it revenue by region by quarter and it is exact and instant.

It helps to be clear about what it is not. A semantic model is built for the questions you modeled in advance. It is not built to reason across relationships you never joined, which is what the ontology and its knowledge graph are for. The two are partners, not rivals: the semantic model answers "how much," the ontology answers "how is this connected to that." As of July 2026 the semantic model and the graph engine are both generally available, while the ontology item that sits over them is still in preview, so expect that part to keep changing. But the split of jobs between them is stable.

The one trap

Do not treat a measure as a column you happen to add up. A column is raw material, and adding it up blindly is how a return becomes a sale and euros become dollars, with no warning, in a number an executive is about to say out loud. A measure is a definition that lives in one place, and that one place is its value: one place to fix, one answer everywhere. The moment a metric gets computed two different ways in two different reports, you do not have a semantic model. You have two different answers using the same name.

Now that you have seen both layers, the obvious question comes up. When do you use a semantic model, and when do you use an ontology? That is the next concept, and the whole point of this module: semantic model versus ontology, and how to tell which one a question needs.