Courseiva
Model the datamediumMultiple ChoiceObjective-mapped

PL-300 Model the data Practice Question

You have a Power BI data model with a fact table and multiple dimension tables. You notice that many-to-many relationships cause ambiguous results. What is the best practice to resolve this?

⚠ Common exam trap

A common mix-up: candidates confuse bidirectional cross-filter direction as a quick fix for many-to-many relationships, but Microsoft explicitly warns that bidirectional filtering can lead to ambiguous results and performance degradation, whereas a bridge table is the recommended pattern.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

Add a bridge table with appropriate relationships

In Power BI, many-to-many relationships between fact and dimension tables can produce ambiguous results because the model cannot determine a unique filter propagation path. The best practice is to introduce a bridge table that resolves the many-to-many relationship into two one-to-many relationships, ensuring unambiguous filter context and correct aggregations.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • Change the relationship to one-to-one

    Why it's wrong here

    Setting the relationship to one-to-one falsely assumes every fact row has exactly one matching dimension row and vice versa. In a normal star schema with a fact table and multiple dimensions, this granularity mismatch would force the engine to either drop unmatched rows or require the fact table to be unique on the dimension key, which is rarely true and can silently lose data. It does not resolve the underlying many-to-many cardinality; it simply imposes an invalid constraint that breaks the model.

  • Use a bidirectional cross-filter direction

    Why it's wrong here

    Bidirectional cross-filtering propagates filters from one side to the other for both tables, which can introduce ambiguous filter paths when multiple dimensions are involved. In a many-to-many situation, this direction setting can cause a single dimension selection to multiply fact rows unexpectedly, leading to inflated measures and degraded query performance because the storage engine cannot resolve the filter context deterministically. It is a workaround, not a modeling fix, and is generally discouraged unless the relationship is genuinely 1:1.

  • Create a calculated table to merge the dimensions

    Why it's wrong here

    Merging the multiple dimensions into one calculated table does not change the relationship cardinality between the fact table and the original dimension tables; the fact table still contains separate keys to each separate dimension. The merged table would create fanouts or duplicates when it tries to represent all dimension combinations, and it would break the integrity of each dimension's independent slicing, because the fact table cannot map cleanly to a single merged key. This approach conflates dimensions that should remain distinct and fails to address the root cause of the many-to-many mismatch.

  • Add a bridge table with appropriate relationships

    Why this is correct

    A bridge table is the standard pattern for handling many-to-many relationships in Power BI: it holds unique combinations of the involved keys and connects to the fact table via one-to-many relationships to each dimension. This normalizes the originally ambiguous many-to-many relationship into two clear one-to-many paths, allowing filters from either dimension to propagate correctly without duplicating fact rows. It preserves each dimension's granularity and ensures that measures aggregate exactly once per relevant fact record, making it the correct modeling solution.

Visual reference

Client Recursive Resolver Root DNS (13 root servers) TLD DNS (.com, .org, …) Authoritative example.com query IP addr answer

About these practice questions

One of 217 original PL-300 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This PL-300 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the PL-300 exam.