PL-300 Model the data Practice Question
You have two tables: 'Orders' and 'Customers'. You want to create a relationship where each order is linked to one customer, but a customer can have many orders. Which cardinality should you choose?
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
✓
Many-to-one (*:1) from Orders to Customers
The correct choice is B, many-to-one (*:1) from Orders to Customers, because each individual order row references exactly one customer row, while the same customer key can appear in many order rows — which is precisely the *:1 direction when viewed from Orders toward Customers. In relational terms this is implemented by placing a foreign key in Orders pointing to the Customers primary key, enforcing referential integrity without duplicating customer data. Option A (*:*) is wrong because many-to-many requires a junction table and would let one order map to multiple customers, contradicting the scenario. Option C (1:* from Orders to Customers) reverses the direction, implying one order relates to many customers. Option D (1:1) is wrong because it would restrict each customer to at most one order.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Many-to-many (*:*)
Why it's wrong here
A many-to-many relationship between Orders and Customers would require a junction or bridge table because each order could theoretically be associated with many customers and each customer with many orders. This directly contradicts the business rule that every order is placed by exactly one customer. Without a linking table, the model would produce duplicate order rows when filtering from Customers, causing fan-out and incorrect aggregations.
- ✓
Many-to-one (*:1) from Orders to Customers
Why this is correct
The many-to-one (*:1) relationship from Orders to Customers is correct because the Orders table contains many rows that reference the same single customer row through the customer key. Each order belongs to exactly one customer, so the CustomerID column is not unique in Orders but is unique in Customers. This is the standard fact-to-dimension relationship in Power BI, where filtering from Customers to Orders yields all orders for that customer.
- ✗
One-to-many (1:*) from Orders to Customers
Why it's wrong here
A one-to-many (1:*) relationship from Orders to Customers would reverse the direction and imply that a single order can be linked to many customer records. That is semantically impossible because each order's CustomerID points to exactly one customer. In the correct model, the single side must be Customers (one customer) and the many side must be Orders (many orders per customer), making the from-Orders-to-Customers direction many-to-one, not one-to-many.
- ✗
One-to-one (1:1)
Why it's wrong here
A one-to-one (1:1) relationship would restrict both tables so that each order can have only one customer and each customer can have only one order. That would prevent customers from placing multiple orders and would require CustomerID to be unique in the Orders table as well as in Customers. This does not match the common business scenario where a customer can place many orders, so one-to-one is incorrect.
About these practice questions
This PL-300 question is part of Courseiva's 524-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
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.