Model size

Creating your own date table and creating relationships with all the date columns in your model will reduce the model size, sometimes significantly. This will speed up both refreshes and report load times. I have seen reports go from load times of more than 5 minutes to under 30 seconds, just by removing the hidden date tables.

For many smaller reports, these date tables are great. They speed up development and allow less-savvy report creators to get going with a shallower learning curve.

For larger reports, these date tables can be a performance killer. They slow down large datasets and can make date math confusing. Using a date table allows you to standardize on one date across all your data.

Role-playing with our date table

We already touched on this when we talked about role-playing dimensions, but I want to reiterate it here. Date tables are awesome to role-play with; they provide a single date field for all reporting but can pretend to be any date field in your report.

Note

Make certain all the relationships with the date table are marked as Single direction. This way, our order date won’t filter out the shipped date.

Define the appropriate level of data granularity

One key way to establish what your report can contain is establishing its granularity, or grain. The grain is the smallest level your report can go to. It is not uncommon for data in a fact table to be stored as a daily or monthly total. If you are storing sales by store by day, you should not divide that number by 24 to get hourly totals. That number implies a degree of certainty that is not actually in the data.

I’m going to present a screenshot from earlier, but this time talk about what we are relating, not how.

Figure 5.17– The grain of the Sales table is product by Region Name and OrderNumber

Here, you can see that our Manager table can filter our Sales table through the Region table, and the other way around: Sales>Region>Manager. If I filter the Manager table by ManagerName, it will filter the Sales table by Region. So, if Ted and Ananya both manage the Midwest region, both will end up showing the exact same revenue.

Figure 5.18 – This is incorrect

If you noticed that the total is not a summation of the Net Profit column, you are correct. Power BI calculated the net profit total separately; it doesn’t just add the columns above it. We will talk about filter context later in this book, in Chapter 9, Creating Reports.

Just remember, you can never have more detail than your model allows. When it comes time for me to hand out my bonuses, I can’t just give half credit to each manager. That would not be fair if the bulk of my profit come from one of them. That’s a quick way to lose a good manager.