PL-300 Model the data Practice Question
You are modeling data from a SQL database that has a table with columns: OrderID, CustomerID, OrderDate, ProductID, Quantity, and Price. You want to create a star schema in Power BI. Which columns should you move to dimension tables?
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
✓
CustomerID, ProductID, OrderDate
In a star schema these columns are foreign keys or attributes that belong in dimension tables: CustomerID links to a Customer dimension, ProductID links to a Product dimension, and OrderDate links to a Date dimension for time-based analysis. The fact table should retain the numeric measures and the order identifier, so Quantity, Price, and OrderID stay in the fact table. Option A incorrectly moves Quantity and Price, which are measures, into dimensions. Option B incorrectly moves Quantity and Price and keeps CustomerID/ProductID out of dimensions. Option D incorrectly moves Quantity and Price while leaving the dimension keys in the fact table.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
OrderDate, Quantity, Price
Why it's wrong here
OrderDate is a foreign key to the Date dimension and would legitimately be replaced by date attributes (e.g., Year, Month). However, Quantity and Price are additive measures, not foreign keys; they should remain as numeric facts in the fact table. Including measures in a set of columns meant for attribute replacement conflates structural keys with business metrics and would lose aggregatable values.
- ✗
Quantity, Price, OrderID
Why it's wrong here
Quantity and Price are clearly measures in a sales fact table, while OrderID is the primary key that uniquely identifies each row and maintains the fact table's grain. None of these columns act as foreign keys referencing a dimension, so replacing them with dimension attributes is entirely inappropriate; doing so would remove the basis for row-level uniqueness and all numeric aggregation.
- ✓
CustomerID, ProductID, OrderDate
Why this is correct
CustomerID, ProductID, and OrderDate are all foreign keys that establish relationships to the Customer, Product, and Date dimension tables. In a proper star schema, these keys should be replaced with dimension attributes such as CustomerName, ProductCategory, and OrderMonth during reporting. This replacement makes reports readable and lets users filter and group by meaningful descriptions instead of opaque ID numbers.
- ✗
OrderID, Quantity, Price
Why it's wrong here
OrderID is the fact table's primary key, which must be retained to preserve each transaction's unique identity and the table's granularity, not replaced by a dimension attribute. Quantity and Price are measures—numeric values designed for aggregation—so converting them to attributes would break all SUM, AVERAGE, and count operations. Thus this combination is invalid because it targets neither foreign keys nor dimension-replaceable columns.
Go deeper
Related to this question
About these practice questions
Courseiva writes every PL-300 question from scratch — 524 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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.