What Is a Power BI Semantic Model?

If you've spent any time in Power BI, you've probably seen the term "semantic model" (and its older name, "dataset") and wondered what actually lives inside it. The short answer: the semantic model is the reusable data layer behind your reports — the tables, the relationships between them, and the calculations. Get this layer right and every chart, KPI, and dashboard you build on top of it just works.

This guide explains the semantic model in plain English: what it contains, how it differs from a report, why the star schema matters, and the one storage-mode decision (Import vs DirectQuery) you'll actually need to make.

The semantic model is your data layer, not your charts

Think of a Power BI file as two stacked layers:

• The semantic model — the data and the logic. Tables of data, the relationships that connect them, and the DAX measures that calculate things like total revenue or year-over-year growth.
• The report — the visuals. Pages of charts, cards, slicers, and tables that query the model and display the answers.

The visuals don't store any numbers themselves. When you drop "Total Sales" onto a bar chart sliced by month, the visual asks the semantic model for those values and the model does the math. Change a measure once in the model and every visual that uses it updates everywhere.

That separation is the whole point. One well-built model can power many reports, and several analysts can build different reports on the same trusted source of truth — without redefining what "revenue" means each time.

"Dataset" and "semantic model" are the same thing

If the terminology trips you up, you're not alone. Microsoft renamed "dataset" to "semantic model" in the Power BI Service in November 2023. It's the same object.

• Newer menus, docs, and the Fabric experience say semantic model.
• Older blog posts, training, and the .pbix file format still say dataset.
• DAX, Power Query, and everything else inside work identically regardless of the label.

So when a tutorial from 2022 tells you to "publish your dataset," that's the same step a 2026 article calls "publishing your semantic model." Microsoft has confirmed the change is a rename only — nothing about how the object works changed.

What's actually inside a semantic model

Three ingredients, in the order you build them:

1. Tables. Your data, loaded and cleaned. This is where Power Query does its work — connecting to sources (CSV, Excel, SQL, an API), renaming columns, fixing data types, splitting and merging. Tables fall into two roles:

• Fact tables hold the events you measure: orders, transactions, sessions, support tickets. They're long and narrow, full of numbers and keys.
• Dimension tables hold the descriptive context you slice by: Date, Customer, Product, Region. They're shorter and full of labels.

2. Relationships. The links that connect tables on a shared key — for example, a CustomerID in your Sales fact table connecting to CustomerID in your Customer dimension. Relationships are what let you slice sales by customer attributes that live in a different table.

3. Measures. Reusable DAX calculations evaluated on the fly based on whatever a user has filtered. A measure like Total Revenue recalculates instantly when someone clicks a region slicer or drills into a single month.

Total Revenue = SUM ( Sales[Amount] )

Revenue YoY % =
VAR CurrentRevenue = [Total Revenue]
VAR PriorRevenue =
    CALCULATE ( [Total Revenue], DATEADD ( 'Date'[Date], -1, YEAR ) )
RETURN
    DIVIDE ( CurrentRevenue - PriorRevenue, PriorRevenue )

A common beginner mistake is to use a calculated column (computed row-by-row at refresh time and stored in the table) where a measure (computed at query time, in context) is the right tool. The rule of thumb: if the number should respond to filters and slicers, make it a measure.

Why the star schema is the model that works

The way you arrange those tables matters enormously. The recommended shape in Power BI is the star schema: one central fact table surrounded by dimension tables, each connected by a single relationship.

                  ┌──────────┐
                  │   Date   │
                  └────┬─────┘
                       │
   ┌──────────┐   ┌────┴──────┐   ┌──────────┐
   │ Customer ├───┤   Sales   ├───┤ Product  │
   └──────────┘   │  (facts)  │   └──────────┘
                  └────┬──────┘
                       │
                  ┌────┴─────┐
                  │  Region  │
                  └──────────┘

It's called a star because the diagram looks like one. Star schemas matter because:

• DAX measures behave predictably — filters flow cleanly from the dimensions down into the fact table.
• The model is fast; Power BI's storage engine is built and optimized for this shape.
• It's easy to reason about. Each dimension answers a "by what?" question (sales by product, by month, by region).

The opposite — one giant flat table with everything jammed in, or a tangle of tables linked in every direction — is where most "my measure returns the wrong number" problems come from. A dedicated Date table, marked as the model's official date table, is especially important: it's what makes time-intelligence functions like year-to-date and prior-year comparisons work correctly. If you're starting fresh, our guide to building a star schema in Power BI walks through it step by step.

Import vs DirectQuery: the storage mode choice

When you load data, each table uses a storage mode. The two you'll meet first are Import and DirectQuery.

	Import	DirectQuery
Where data lives	Copied into the model, compressed in memory	Stays in the source system
Performance	Very fast	Depends on the source
Data freshness	As of the last refresh	Live, every query
Works offline	Yes	No (needs a live connection)
Best for	Most reports	Very large data or strict real-time needs

Import is the default and the right choice for the large majority of reports. Power BI compresses the data and holds it in memory, so visuals are snappy and you can work offline. The tradeoff: data is only as current as your last refresh. Scheduled refresh in the Power BI Service handles that, and publishing typically requires a paid license — Power BI Pro is roughly $14/user/month as of 2026 (always check Microsoft's pricing page for the current figure).

DirectQuery leaves the data in the source and fires a live query every time a visual renders. Use it when the data is too large to import, or when you genuinely need up-to-the-second numbers. The cost is performance — your reports are only as fast as the underlying database — and some DAX patterns are restricted. There's also a Composite model that mixes both modes, plus Live connection for connecting to an existing shared model. For most people building their first reports, start with Import and don't look back unless you hit a real reason to switch.

How the model fits into the Power BI ecosystem

A few practical notes on where the model lives:

• A .pbix file (built in the free Power BI Desktop) usually bundles the semantic model and a report together in one file.
• The newer .pbip (Power BI Project) format splits them into readable, source-control-friendly folders — handy for version control and for tools that generate reports programmatically.
• When you publish to the Power BI Service, the semantic model becomes a shared object in a workspace. Other reports can connect to it, so it acts as a single source of truth for a team.
• In Microsoft Fabric, the semantic model is one of several item types, but the concept is unchanged: it's still tables, relationships, and measures.

You build the model in Power BI Desktop, which is free. You only pay (Pro, or Premium / Fabric capacity) when you want to publish and share in the Service.

Build the model first, then the visuals

The order of operations that saves the most headaches:

1. Clean and shape your tables in Power Query.
2. Arrange them into a star schema with a proper Date table.
3. Set relationships correctly (one-to-many, from dimension to fact).
4. Write measures for every number you'll display.
5. Then build report pages on top.

People who skip straight to dropping charts on a page almost always end up reworking everything once the numbers don't add up. A solid semantic model is the foundation; the visuals are the easy part once it's right. To make a finished report look polished, our free Power BI theme generator gives you a branded color theme to apply once the model is done.

---

Building a correct semantic model — clean tables, a proper star schema, a real Date table, and measures that respond to filters — is the part that takes experience to get right. That's exactly what Instant PowerBI is built to handle. Send your raw CSV or Excel data and you get back a finished, branded Power BI report with the semantic model already built — relationships, measures, and a clean star schema included. It opens in the free Power BI Desktop, so you can explore, tweak, and publish it yourself. Get started and skip straight to the insights.