- •Contents at a glance
- •Contents
- •Introduction
- •Who this book is for
- •Assumptions about you
- •Organization of this book
- •Conventions
- •About the companion content
- •Acknowledgments
- •Errata and book support
- •We want to hear from you
- •Stay in touch
- •Chapter 1. Introduction to data modeling
- •Working with a single table
- •Introducing the data model
- •Introducing star schemas
- •Understanding the importance of naming objects
- •Conclusions
- •Chapter 2. Using header/detail tables
- •Introducing header/detail
- •Aggregating values from the header
- •Flattening header/detail
- •Conclusions
- •Chapter 3. Using multiple fact tables
- •Using denormalized fact tables
- •Filtering across dimensions
- •Understanding model ambiguity
- •Using orders and invoices
- •Calculating the total invoiced for the customer
- •Calculating the number of invoices that include the given order of the given customer
- •Calculating the amount of the order, if invoiced
- •Conclusions
- •Chapter 4. Working with date and time
- •Creating a date dimension
- •Understanding automatic time dimensions
- •Automatic time grouping in Excel
- •Automatic time grouping in Power BI Desktop
- •Using multiple date dimensions
- •Handling date and time
- •Time-intelligence calculations
- •Handling fiscal calendars
- •Computing with working days
- •Working days in a single country or region
- •Working with multiple countries or regions
- •Handling special periods of the year
- •Using non-overlapping periods
- •Periods relative to today
- •Using overlapping periods
- •Working with weekly calendars
- •Conclusions
- •Chapter 5. Tracking historical attributes
- •Introducing slowly changing dimensions
- •Using slowly changing dimensions
- •Loading slowly changing dimensions
- •Fixing granularity in the dimension
- •Fixing granularity in the fact table
- •Rapidly changing dimensions
- •Choosing the right modeling technique
- •Conclusions
- •Chapter 6. Using snapshots
- •Using data that you cannot aggregate over time
- •Aggregating snapshots
- •Understanding derived snapshots
- •Understanding the transition matrix
- •Conclusions
- •Chapter 7. Analyzing date and time intervals
- •Introduction to temporal data
- •Aggregating with simple intervals
- •Intervals crossing dates
- •Modeling working shifts and time shifting
- •Analyzing active events
- •Mixing different durations
- •Conclusions
- •Chapter 8. Many-to-many relationships
- •Introducing many-to-many relationships
- •Understanding the bidirectional pattern
- •Understanding non-additivity
- •Cascading many-to-many
- •Temporal many-to-many
- •Reallocating factors and percentages
- •Materializing many-to-many
- •Using the fact tables as a bridge
- •Performance considerations
- •Conclusions
- •Chapter 9. Working with different granularity
- •Introduction to granularity
- •Relationships at different granularity
- •Analyzing budget data
- •Using DAX code to move filters
- •Filtering through relationships
- •Hiding values at the wrong granularity
- •Allocating values at a higher granularity
- •Conclusions
- •Chapter 10. Segmentation data models
- •Computing multiple-column relationships
- •Computing static segmentation
- •Using dynamic segmentation
- •Understanding the power of calculated columns: ABC analysis
- •Conclusions
- •Chapter 11. Working with multiple currencies
- •Understanding different scenarios
- •Multiple source currencies, single reporting currency
- •Single source currency, multiple reporting currencies
- •Multiple source currencies, multiple reporting currencies
- •Conclusions
- •Appendix A. Data modeling 101
- •Tables
- •Data types
- •Relationships
- •Filtering and cross-filtering
- •Different types of models
- •Star schema
- •Snowflake schema
- •Models with bridge tables
- •Measures and additivity
- •Additive measures
- •Non-additive measures
- •Semi-additive measures
- •Index
- •Code Snippets
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,