1. The use case for a virtual relationship arises when you have a fact table (typically a summary table of some kind) with natural relationships with dimension tables but not at the many-to-one grain
1.1. For example, consider the City Budgets fact table in this model
1.1.1. The grain of City Budgets is City + Year
1.1.2. There is a natural many-to-many relationship with the Regions dimension table and another natural many-to-many relationship with the Dates dimension table
1.1.3. In this scenario, we should ***not* ** create two physical relationships in the model (even though Power BI will allow us to)
1.1.3.1. Instead, we should consider creating a virtual relationship within measures via the TREATAS function
2. TREATAS
2.1. Let's continue our City Budgets example and add a simple measure for budgets
2.1.1. Total Budget = SUM( 'City Budgets'[Sales Budgets] )
2.1.1.1. When we add to a table visual the lack of relationship is apparent
2.1.1.1.1. The Year slicer comes from the 'Dates' dimension and the City column in the table visual comes from the 'Regions' dimension, but our [Total Budget] measure is summing from the 'City Budgets' table with no relationship to either of these, so it just repeats the grand total over and over.
2.1.1.1.2. The Year slicer has no effect on the [Total Budget] numbers due to the absence of relationship between 'Dates' and 'City Budgets'
2.1.1.2. Now let's add a new measure called [Regional Budget] that uses virtual relationships with 'Dates' and 'Regions'
2.1.1.2.1. Regional Budget = CALCULATE( [Total Budget], TREATAS( VALUES( 'Regions'[City] ), 'City Budgets'[City] ), TREATAS( VALUES( 'Dates'[Year] ), 'City Budgets'[Year] ) )
3. Comparing TREATAS with USERELATIONSHIP
3.1. Although it might feel tempting to use the more intuitive USERELATIONSHIP rather than TREATAS, the use cases are different
3.1.1. For USERELATIONSHIP to work, an inactive relationship must be created in the data model and it's only appropriate to create such relationships as 1-to-many.