FIGURE 8-11 A single bridge table can link multiple tables together.
Note
This model that links three tables together is also used for categorized many-to-many, which is a many-to-many relationship that has another table used to filter it. For example, you might have different kinds of relationships between entities (different kinds of owners of current accounts, where one is the primary account and others are secondary accounts). You can model them with a bridge table that also contains a link to the category. It is a simple model, yet it is extremely powerful and effective.
Obviously, you will need to build such a super-bridge table. In the example, we used a simple calculated table built with DAX, but, as usual, you can use SQL or the query editor to obtain a similar result.
Temporal many-to-many
In the previous section, you learned that you can model many-to-many relationships even in cases where the bridge links multiple tables. When the
bridge links three tables, you can consider each of the three tables as a separate filter, and at the end, you can find the rows in the fact table that satisfy all the conditions. A variation of this scenario happens when the many-to-many relationship has a condition, but this condition cannot be expressed with a simple relationship. Instead, it is expressed by a duration. Such a relationship is known as a temporal many-to-many, and it is an interesting mix between duration handling (covered in Chapter 7, “Analyzing date and time intervals”) and many- to-many (the topic of this chapter).
You can use these kinds of relationships to model, for example, a team of people that might change over time. An individual might belong to different teams and change his or her team over time, so the relationship between individuals and teams has a duration. The starting model is shown in Figure 8-12.
FIGURE 8-12 A single bridge table can link multiple tables together.
As you can see, it is a standard many-to-many model.
The key of this model is not the many-to-many, but the fact that the bridge table contains two dates (FromDate and ToDate) that determine in which period the individual was working with the team. In fact, if you use this model as it is and slice the number of worked hours by team and individual, you obtain an incorrect result. This is because you need to carefully use the time constraints to correctly map individuals to teams in any given period. A simple filter by individual will not work. To better understand what happens, see Figure 8-13, which depicts the bridge table and highlights the rows pertinent to Catherine.
FIGURE 8-13 Filtering the bridge by Catherine, you obtain all the teams for which she worked at any time.
If you filter by name, you obtain all the teams for which Catherine worked. But when you look at 2015, for example, you want to obtain only the first two rows. Moreover, because Catherine worked for two different teams in 2015, you want to account January to the Developers team, and February through December to the Sales team.
Temporal many-to-many relationships are complex models to solve, and usually, they are very hard to optimize. In fact, it is extremely easy to fall into the many traps they hide. You might be tempted to simply apply a temporal filter to the many-to-many to show only the rows that are considered valid during the period selected. But imagine you restrict the rows to only Catherine in the year 2015. You will still see two different teams (Developers and Sales).
To solve the scenario, you need to perform the following steps in the right way:
1.Determine the periods during which each individual worked for a given team.
2.Move the filter on the dates to the fact table, taking care to intersect it with any other filter that is already applied on the fact table.
These two operations need to be executed inside an iteration at the individual level because different individuals might have different periods to take into account. You can do this with the following code:
Click here to view code image
HoursWorked := SUMX (
ADDCOLUMNS ( SUMMARIZE (
IndividualsTeams,
Individuals[IndividualKey],
IndividualsTeams[FromDate],
IndividualsTeams[ToDate]
),
"FirstDate", [FromDate],
"LastDate", IF ( ISBLANK ( [ToDate] ), MAX (
), CALCULATE (
SUM ( WorkingHours[Hours] ),
DATESBETWEEN ( 'Date'[Date], [FirstDate], [L VALUES ( 'Date'[Date] )
)
)
In this scenario, you have no way of modeling the many-to-many relationship in the data model because the duration of the relationship forces you to rely on DAX code to transfer the filter from the bridge table to the fact table. The code is not simple, and it requires you to have a deep understanding of how filter context propagates through relationships. Moreover, because of its complexity, this code is sub-optimal. Still, it works just fine, and you can use it to produce reports like the one shown in Figure 8-14, which demonstrates how the filter on the periods is correctly moved to the fact table.
FIGURE 8-14 The report shows the number of hours worked by individuals on different teams.
As you have seen, the code is very complex. Moreover, it is worth noting that in this specific model, many-to-many is probably the wrong tool. We deliberately chose a model where many-to-many seemed like the right choice, but after looking closer at the model, it becomes clear that there are better choices. In fact, even if it is true that over time an individual might belong to different teams, on a given day that person should belong to a single team. If this condition is met, then the correct way of modeling this scenario is to consider the team as a dimension unlinked from the individuals, and to use the fact table to store the relationship between teams and individuals. In the model we are using as an example, this condition is not met, as shown in Figure 8-15, which reveals that Paul, during August and September 2015, was on two different teams.
FIGURE 8-15 In August and September 2015, Paul is working for two different teams.
We are going to use this scenario to introduce the next topic, which is the reallocation factors in the many-to-many.