Which DAX function enables a virtual relationship across unrelated tables?

Which DAX function enables a virtual relationship across unrelated tables?

• A. USERELATIONSHIP()
• B. TREATAS()
• C. CROSSFILTER()
• D. PATH()

Answer: (B)

When you need a relationship that isn’t defined in the model, you can create a virtual relationship in a DAX expression using TREATAS. It takes a set of values from one table and applies those values as filters to a column in another table, effectively simulating a relationship for the calculation. This lets you perform cross-table calculations even when the tables aren’t physically related. For example, if you have a fact table with a date key and a date dimension table but no relationship between them, you can sum sales by date by mapping the date values from the dimension table to the fact table’s date key: CALCULATE(SUM(FactSales[SalesAmount]), TREATAS(VALUES(DimDate[Date]), FactSales[DateKey])). The mechanism is useful because it injects the date values into the filter context of the target table, creating a one-time, calculation-time link without changing the data model. Other functions that modify existing relationships or filter directions don’t create this new virtual link between unrelated tables, and PATH is for navigating hierarchies, not establishing cross-table filters.

When you need a relationship that isn’t defined in the model, you can create a virtual relationship in a DAX expression using TREATAS. It takes a set of values from one table and applies those values as filters to a column in another table, effectively simulating a relationship for the calculation.

This lets you perform cross-table calculations even when the tables aren’t physically related. For example, if you have a fact table with a date key and a date dimension table but no relationship between them, you can sum sales by date by mapping the date values from the dimension table to the fact table’s date key: CALCULATE(SUM(FactSales[SalesAmount]), TREATAS(VALUES(DimDate[Date]), FactSales[DateKey])).

The mechanism is useful because it injects the date values into the filter context of the target table, creating a one-time, calculation-time link without changing the data model. Other functions that modify existing relationships or filter directions don’t create this new virtual link between unrelated tables, and PATH is for navigating hierarchies, not establishing cross-table filters.