Having worked with Power BI for BIM for quite some time, I keep noticing a familiar pattern: we are repeating the same mistakes we made in the early days of BIM. Data schemas and fundamentals are often neglected, while the focus shifts almost entirely to one goal - a beautiful, and seemingly performant, dashboard.
The problem? It’s no different from a Revit model that looks impressive, but doesn’t fulfill its purpose - hard to reuse, hard to trust, and cluttered with project families, groups, and other well-known “sins.”
While there are many courses and books on Power BI, most are tailored to traditional business scenarios and focus on sales and revenue data. Even though the same principles apply to BIM data, adopting them requires rethinking established workflows and can be challenging at first. In this series of articles, I’ll break down the most relevant fundamentals for BIM experts over the coming weeks.
But before we start, an important question:
Why Power BI for BIM at all?
BIM is driven by data. Models are far more than geometry; they contain structured information about components, quantities, costs, phases, trades, and classifications. Power BI isn’t a BIM tool—it’s a data analysis and visualization tool, and its power lies in translating complex data into something everyone can understand, with or without BIM knowledge.
Before building the first dashboard, it’s essential to understand the Power BI mindset and the different data schemas that come with it.
What is a data schema - and why is it so important?
A data schema describes how data is structured, organized and linked to each other - very similar to IFC, for example. In Power BI, the schema is the deciding factor:
- how simple the calculations are,
- how performant reports run,
- how intuitively filters and evaluations work.
This is especially critical for BIM, where models are inherently complex and packed with components and properties.
You can think of the data schema as the building foundation: You can't see it in the finished building - but if not planned correctly, the whole building becomes unstable.
The three common data schemas in Power BI
1. Flat Schema
In its simplest form, all data is contained in one large table. This is exactly what happens when a Data Exchange is loaded into Power BI: one row per component, one column per property.
The advantages of the flat scheme are:
- It is very easy to understand
- It requires no modeling effort
- Ideal for small analyses and simple data models
Data Exchange makes it easier to get started by using the flat schema, as the data can be used and analyzed immediately - even for Power BI beginners.
However, the flat scheme also has some disadvantages:
- It contains a lot of redundant data (e.g. certain properties such as type names or materials are repeated hundreds of times) and is therefore often confusing.
- Poor performance with large models due to data redundancy, which has a similar effect to in-place families in Revit: Memory requirements increase and performance suffers.
- Is not suitable for more complex data sets with different data sources (you can find a very nice example of this in our Data Exchange Documentation)
While a flat data schema works well for initial exploration, it is not scalable for complex project analyses and should be seen only as a starting point. Fortunately, in Power BI the data schema can be reworked at any time - most commonly by transforming it into a star schema.
2. Star Schema
The star schema is the recommended standard in Power BI and consists of a central fieldcts table, which is surrounded by several dimension tables and has clearly defined relationships (usually based on the element ID).
The aim of the schema is to avoid repetition - as this has an unnecessary impact on performance. This is achieved through the correct implementation of the fact and dimension tables:
The advantages of the Star Schema are
- Very good performance by avoiding data redundancy
- Clear separation of elements (facts) and properties (dimensions)
- Easy to understand
However, there are also a few disadvantages
- The star schema requires clearly defined relationships between the tables and therefore varies depending on the data set / model.
- Cannot always do justice to the complex BIM relationships - for example, the nested relationships such as component → room → level → building.
Despite its limitations, the star schema fits naturally with the BIM mindset: components at the core, surrounded by contextual information. It works well for most use cases, since many analyses can be performed without deeply nested relationships. When additional complexity is required, the data model can still be broken down further.
3. Snowflake Schema
In the snowflake schema, the dimensions are further normalized and linked together. In the context of Power BI, normalization means avoiding repetitive data by storing it in separate dimension tables, which are then linked together.
This also makes it easier to model complex relationships, such as element → room → level → building.
Advantages
- Very clean data structure
- Less redundancy
Disadvantages
- More complex relationships
- Poorer performance in Power BI
- More difficult to understand for beginners
The snowflake schema can be an ideal solution for complex scenarios, but in many cases it adds unnecessary complexity and should therefore be used only when the star schema reaches its limits.
Conclusion
Power BI is not rocket science - but it thinks logically, not spatially. Therefore, a basic understanding of data schemas in Power BI is required to ensure that the dashboards have a solid foundation.
Next week, we'll take a closer look at relationships in Power BI in part 2 - because just like in real life, relationships in Power BI can be tricky! 😉
One more thing: Next week we are hosting a webinar about the new features in the Data Connector for Power BI, hope to see you there (if you can't attend live, you will of course receive the link to the recording).