I have already delivered two training courses in 2026. One was with a more technically oriented audience, the other with business specialists. During those sessions, a question quietly started to nag me: does it make didactic sense to mention dimensional modelling on the very first slides? Does a business user, or a technical user without a background in business intelligence, really need to understand or even know about dimensional modelling?
Personally, I have grown up with dimensional modelling ever since I started working with Power BI. It was always a given, so I never questioned it. It simply felt logical.
When asked why, I often fall back on the answer that „it’s best practice.“ My esteemed colleague Raphael Branger once asked me: do we really need a star schema? For a moment I was taken aback that Raphael would ask me something like that. But I thought about it briefly and then answered: because of the filter context. That is one of the most important features in Power BI. He simply said that this made sense, and the discussion was over.
At the time, I gave the filter context as one answer among several. Writing this post, I have come to think it is actually *the* answer — nearly every other reason I will list is just the filter context wearing a different costume.
I keep running into this topic, though — in projects, in trainings, and in discussions. That is why I want to write this blog post and genuinely reflect on what the valid reasons for a star schema actually are. There are certainly already blogs on this topic, but I really want to take it apart for myself, so that I have a better set of arguments going forward and can answer the question for myself: do we really need a dimensional model?
In this part, I will only look at the reasons. In a second follow-up post, I will revisit them and challenge them critically.
There are mainly two alternatives. One is a single large, flat table with all the columns; the other is connecting various Excel files, tables, or extracts together. Here, I will mainly use the large flat table as my point of comparison.
I have already named two reasons — the filter context and „best practice“ — but there has to be more to it.
The Core Idea: What a Star Schema Actually Buys You
Before I go through the reasons one by one, it is worth naming the mechanism underneath all of them. A star schema cleanly separates what I want to filter by — the dimensions — from what I want to aggregate — the facts. That separation is what makes the filter context predictable. Almost everything below is a consequence of it. So I have ordered the reasons for how directly they descend from this one idea, starting with the ones that are really the same reason.
Reusability of Measures
The goal in Power BI is to write a measure once. Let us take the following example:
„`dax
CALCULATE(SUM(Sales[Amount]), Sales[Country] = „Germany“)
„`
This calculation always returns only the sales for Germany. That can make sense in a specific use case. But if I instead write `SUM(Sales[Amount])` and drag in the dimension attribute Country, I get a breakdown across all available countries. With a visual filter, I can then narrow it down to Germany. That way, I have one formula for all countries and can filter it whenever needed.
If I have 50 countries, then in the worst case I would have to write 50 measures. That is not the goal of Power BI.
DAX Was Built for This
The DAX formula language was developed with dimensional modelling in mind. Functions such as `CALCULATE`, `FILTER`, `ALL`, and especially the time intelligence functions expect a clear separation between fact tables and dimension tables.
Fact tables contain measures, quantities, and amounts. Dimensions contain the context for filtering. The questions here are who, what, when, and where. Or, using the customer example:
- Which customer bought the product?
- Which products did the customer buy?
- At what point in time did the customer buy the product?
- Where was the product bought?
Another reason often cited is that DAX measures become harder to implement and to maintain without this structure, and you frequently end up with the wrong context because of incorrect filtering. In other words, DAX assumes the fact-and-dimension split — so fighting that split means fighting the language itself.
A hardcoded country filter also cannot be reused: the country cannot be reused in another data model or report. If you have a Geography dimension instead, you can make it available to other semantic models, for example via a Dataflow Gen2. And you only have to build it once.
Time Intelligence Functions
One of the most important reasons is probably the time intelligence functions. Power BI offers ready-made functions such as `TOTALYTD`, which calculates a year-to-date value without much effort.
However, this function only works if you have a clean date dimension with the following properties:
- One row per date
- No gaps (large tables can have gaps)
- Marked as a date table in Power BI
Without this date dimension, you cannot use these functions. It is precisely these functions that give Power BI even more depth and magic. The date dimension is really just a conformed dimension you cannot avoid — which is also a good place to argue why you might want more than one date dimension right from the start.
A Model That Is Easier to Maintain
The reasons so far were really one reason: the filter context. The next two are different in kind — they are structural.
One good reason is that a model becomes simpler and more maintainable. But why does it become easier to maintain?
I think you could argue about the word „simpler,“ because deriving a dimensional model is anything but simple. Extending one large table is more in our nature, since we know it from Excel. Loosely put: just add a column.
The idea behind dimensional modelling is, in simplified terms, to gather all the attributes you want to filter by into a dimension. A good example is the Customer dimension. I might need a customer’s name, their place of residence, and their date of birth. That way, I can filter my sales by customer and by location. In my trainings, I always say that this is where the magic of Power BI begins, because the filtered customers travel across the relationships onto my sales — or, in simple technical terms, the filter context starts to take effect.
But back to maintainability. It is easy, for example, to add a new customer to the Customer dimension. Say I have a new customer, Meier. I only must make sure I add one new row. Or if a customer has moved, I just change the location.
If I extend a single large flat table that contains an existing customer, then I must reconcile every row, or regenerate the entire table.
The idea of dimensional modelling is reusability — for instance, of a customer dimension. I only have to extend a small, manageable table. I will not go into how you create these dimensions and facts here. There is good literature for that, such as the books by Ralph Kimball.
Scalability Across Multiple Tables — The Conformed Dimension
This, for me, is the strongest structural argument, because it is the one thing a single flat table genuinely cannot do cleanly.
If I only have a single table and I need budget information, then I either have to laboriously merge the tables, or find or build a bridge table. That can become very tedious and frustrating.
If I have the idea of dimensional modelling in mind from the start, then I can connect several fact tables (or transaction tables) through a so-called conformed dimension. I can, for instance, connect my budget via a Region. I have a budget by region and the actual sales. Within the same context, I can then show my sales and budget per region.
In a single denormalised table this is not just inconvenient — it is dishonest, because budget and actuals live at different grains. Forcing them into one table means inventing a grain that does not really exist.
Performance
You would probably expect performance to be at the top of this list, because it is the argument most people have heard. It is not, and the second post is where I will put it properly to the test.
The usual story goes like this. A very large table with repeating text values is compressed poorly by the Power BI engine and is slow to scan. The reason is that the engine behind Power BI is column-oriented. Power BI splits each column out individually, and then counts the number of distinct text values that occur.
Example: We have a large table with 10 million rows. In one column I have 50 countries. Power BI then counts the countries — say Switzerland 5 million, Germany 3 million, and so on. That takes time.
It is far simpler if I have a Geography dimension with 50 countries where each one appears only once.
I will be honest, though: this is the argument I am least sure of. A low-cardinality column like 50 countries compresses very well even inside a flat table, so the picture is more nuanced than „flat is slow.“ The real cost tends to show up with high-cardinality attributes repeated across millions of rows. I will dig into this properly in the second post.
Summary
I have tried to show that dimensional modelling makes sense. We get better performance, simpler DAX, less code, time intelligence functions, and better maintainability without duplicates. But the thread running through almost all of it is the same one: the filter context.
Which brings me back to the question I opened with: does a business user really need to understand dimensional modelling? I now think the answer is no — and that is itself an argument for doing it. The star schema is a semantic layer. It maps to how the business already thinks — subjects (customers, products, dates) on one side, events (sales, bookings) on the other — so the user gets clean, intuitive, sliceable field lists without ever needing to know the term „dimensional modelling.“ They do not need to understand the modelling; they benefit from its results. That is not a reason to put it on the first slide. It is a reason to do it, so I do not have to.
There are certainly further reasons, but from my perspective these were the most important ones. In a second post, I will try to explain these reasons with practical examples — and put the performance argument properly to the test.
Now the big question at the end: are you only ever allowed to model dimensionally? Dogmatically, you would have to say yes — but personally, I am more of a pragmatist. In most cases, I will continue to model dimensionally. However, for a prototype, an ad-hoc analysis, or first experiments, I think you do not have to model dimensionally. What matters is that you document your solution and aim for a plan to rebuild it into a sustainable solution in the medium term.
Let the filter context make Power BI’s magic sparkle.