Chapter 9. Working with different granularity
We talked a lot about granularity in previous chapters, and you have seen how important it is to always have the data at the right granularity. But sometimes, data is stored in different fact tables at a different granularity, and the data model cannot be changed. For each table, the granularity is right. In that case, it might be painful to build calculations that use both tables.
In this chapter, we will perform a deeper analysis of how to handle different granularities, looking at different modeling options and a different kind of DAX code. All these models have one thing in common: Granularity cannot be fixed by changing the model. In most cases, the issue comes from having different levels of granularity in different tables, but for each table, the granularity is the right one. You start having problems when you mix both tables in the same report.
Introduction to granularity
Granularity is the level of detail at which you store information. In a typical star schema, granularity is defined by the dimensions—not by the fact table. The more dimensions, the higher the granularity. Likewise, the more detailed the dimensions, the higher the granularity. Look, for example, at the model shown in Figure 9-1.
FIGURE 9-1 This is a simple snowflake model with four dimensions and one fact table.
In this model, the granularity is defined by the presence of Date, Store, Customer, and Product. Product Subcategory and Product Category, being snowflaked dimensions, do not contribute to the granularity. The Sales table needs to contain at most one row for each unique combination of the values in the dimension. If two rows exist in Sales with the same combination of dimensional keys, they can be merged into a single row with no loss in expressivity. For example, look at the content of the Sales table, which is shown in Figure 9-2. Notice that there are multiple rows containing the very same set of keys and values.
FIGURE 9-2 The first eight rows of this table are totally identical.
There is no way to differentiate between these rows in a report. If you slice by any dimension, their values will always be aggregated together. You can compress the first eight rows in a single line that contains 8 for the quantity and with all the remaining columns identical. It looks strange at first, but it is correct. The expressivity of the model does not change in any way if you reduce the number of rows to the most detailed granularity needed. Having more rows only results in a waste of space.
Obviously, if you add a dimension, things change. For example, it might be the case that these eight rows had a difference in the promotional discount applied. If you add a new Promotion dimension, then you change the granularity, increasing it.
Snowflaked dimensions do not count when defining the granularity because they are at a lower level of detail than the dimension to which they are linked. In fact,