To create a virtual relationship for filtering across an unrelated table, which DAX function should be used?

Study for the Fabric Analytics Engineer Associate Test. Engage with interactive flashcards and multiple-choice questions complete with hints and explanations to solidify your understanding. Get thoroughly prepared for your certification exam!

Multiple Choice

To create a virtual relationship for filtering across an unrelated table, which DAX function should be used?

Explanation:
Creating a virtual relationship to filter an unrelated table is done with a DAX function that applies a set of values from one table to filter another table as if a relationship existed. TREATAS takes values from a source column (often from a slicer or a table in your measure) and “treats” them as if they were filtering a target column in another table. This lets you propagate filter context across tables that aren’t physically connected in the data model. For example, if you have a Customers table and a Sales table that aren’t related, you can still filter Sales by the customer selections you make in Customers by writing something like: CALCULATE([Total Sales], TREATAS(VALUES(Customers[CustomerID]), Sales[CustomerID])) Here, the values from Customers[CustomerID] are mapped to Sales[CustomerID], creating a temporary, virtual linkage just for that calculation. This is precisely what you need when the goal is to drive filtering across unrelated tables without adding a physical relationship. The other options don’t create this kind of cross-table filter: a function like RELATEDTABLE returns rows related to the current context, not a cross-table filter; a function that activates an existing relationship only toggles an existing link rather than creating a new virtual one; and the option that combines “All” isn’t a function for this purpose.

Creating a virtual relationship to filter an unrelated table is done with a DAX function that applies a set of values from one table to filter another table as if a relationship existed. TREATAS takes values from a source column (often from a slicer or a table in your measure) and “treats” them as if they were filtering a target column in another table. This lets you propagate filter context across tables that aren’t physically connected in the data model.

For example, if you have a Customers table and a Sales table that aren’t related, you can still filter Sales by the customer selections you make in Customers by writing something like:

CALCULATE([Total Sales], TREATAS(VALUES(Customers[CustomerID]), Sales[CustomerID]))

Here, the values from Customers[CustomerID] are mapped to Sales[CustomerID], creating a temporary, virtual linkage just for that calculation. This is precisely what you need when the goal is to drive filtering across unrelated tables without adding a physical relationship. The other options don’t create this kind of cross-table filter: a function like RELATEDTABLE returns rows related to the current context, not a cross-table filter; a function that activates an existing relationship only toggles an existing link rather than creating a new virtual one; and the option that combines “All” isn’t a function for this purpose.

Subscribe

Get the latest from Examzify

You can unsubscribe at any time. Read our privacy policy