- •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
more complex scenario into smaller ones. Thus, each single formula is much simpler and easier to write and debug, and the final aggregation formulas become extremely easy to write and fast to execute.
Conclusions
This chapter deviated from the standard models to perform a deeper analysis of scenarios in which duration is the primary concept. As you have seen, duration forces you to think in a slightly different way, redefining the very concept of a fact. You might store a fact along with its duration, but in doing so, you will need to reconsider the concept of time because a single fact might extend its effects into different periods. The following is a brief overview of what you learned in this chapter:
Date and time must be separate columns.
Aggregating simple intervals is easy. You should only try to reduce the cardinality of the facts to the best one that satisfies your analytical needs, and at the same time, reduce the cardinality of the Time column.
When you store duration (or intervals) that cross the time dimension, you must define the model in the right way. There are many options, and you are responsible for finding the best one. The good news is that you can move from one solution to another by simply changing the data model. Then, you can use the one that works best for your specific scenario.
Sometimes, changing the way you think about time might help. If your day does not end at midnight, you can model it the way you want—for example, making it start at 2:00 a.m. You are not a slave of the model. Instead, it is the model that must change according to your needs.
Analysis of active events is a very common scenario that is frequently used in many businesses. You learned multiple ways of solving this scenario. The more tailored the model, the easier the DAX code, but at the same time, the more complex the data-preparation steps.
When you have multiple tables where each one defines its own set of durations, trying to solve the problem with a single DAX measure makes the code very complex. On the other hand, pre-computing the values in a calculated column or a calculated table and obtaining the right degree of denormalization will lead to much simpler DAX code, which you can trust more.
The main takeaway is nearly always the same: If the DAX code becomes too complex, then it is a very good indicator that you might need to work on the
model. Although it is true that the model should not be built for a single report, it is also true that a good model is the key to an efficient solution.