PL-300 Model the data Practice Question

Answer analysis

Option-by-option breakdown

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

• ✓

  Create a one-to-many relationship from Customers to Orders with single direction.

  Why this is correct

  This is the correct star schema design. The Customers table is a dimension with a unique CustomerID per row, while Orders is a fact table that can contain many rows per CustomerID. A one-to-many relationship from Customers to Orders lets filters applied to customers (e.g., region, segment) automatically propagate to their orders in visualizations and measures. The single cross-filter direction ensures one-way filtering from the dimension to the fact, which is the standard, repeatable pattern that avoids ambiguity and keeps DAX calculations predictable.

• ✗

  Create a one-to-one relationship between Customers and Orders based on CustomerID.

  Why it's wrong here

  A one-to-one relationship is invalid here because the cardinality is wrong: each customer can place multiple orders, so there are many Order rows per single CustomerID. Moreover, a true one-to-one requires unique values in both key columns, but Orders.CustomerID will have duplicates, so such a relationship cannot be created or would force data to be combined into a single table. Even if it were technically possible, it would incorrectly imply that each order belongs to a unique customer and each customer has exactly one order, distorting all order-level aggregations.

• ✗

  Create an inactive relationship and use USERELATIONSHIP in measures.

  Why it's wrong here

  This approach is unnecessarily complex and counterproductive for default filtering. The active relationship already exists, so Power BI uses it automatically in every visual, measure, and filter context; introducing a second inactive relationship would require every measure to explicitly call USERELATIONSHIP just to restore the default filtering. USERELATIONSHIP is intended for cases where you need to temporarily override the active relationship (e.g., toggling between order date and ship date), but here it adds complexity with no benefit and could cause confusion or subtle bugs if you forget to activate it in some measures.

• ✗

  Create a many-to-one relationship from Orders to Customers with both directions.

  Why it's wrong here

  A many-to-one relationship from Orders to Customers is semantically the same cardinality as one-to-many from Customers to Orders, but setting the cross-filter direction to Both is the critical flaw. Bidirectional filtering means filters on Orders (or non-key columns in Orders) would also flow back to Customers, potentially creating ambiguities when multiple fact tables or disconnected dimensions are involved, and it can degrade query performance. In this simple scenario, only the one-way filter direction from Customers to Orders is needed; both directions are not required and violate the recommended star schema guidance.