DAX is an exceptional language, enabling anyone able to extract insights out of almost any data. But DAX is considered difficult and complex, requiring the user to understand concepts like row, filter and evaluation context.

But here is the thing – while all those concepts are important, the underlying data model is the main driver of how complex the DAX code needs to be.

In the world of data, most people know about data modelling, and they will nod enthusiastically when words like normal forms, dimensions and facts come up in a conversation. When pressed on modelling in more detail, they might say that “the point of data modelling is to organize data in such a way as to allow businesses to extract maximum value from it”.

Get your ducks in a row, got it – but what does it really mean? Does this even apply in the world of Fabric?

It is easy to find an explanation for what the normal forms are, how a dimension is structured, and what issues might arise with a poor data model. But what is a poor data model, and – more importantly – WHY is it a poor data model? Why should you even care?

What if I told you that a proper data model will make your DAX code much, much easier to write and maintain?

That’s why you should care.

This session will give you a solid grounding in relational data modelling from both the perspective of normalizing a transactional data model as well as creating a star schema for a dimensional data model. We will look at increasingly complex examples from real world scenarios, we will explore why it generally is a Very Bad Idea(tm) to create a Power BI report based on a transactional data model, and discuss why a star schema will make both a better model and help you dodge unnecessarily complex DAX for as long as possible.