PL-300 Prepare the data Practice Question
You are creating a Power BI report from a SQL Server database that contains a table Orders with columns: OrderDate, CustomerID, ProductID, Quantity, UnitPrice. You need to build a star schema. Which THREE tables should you create? (Choose three.)
⚠ Common exam trap
Many candidates confuse dimension tables with fact tables or think that line-item details (Option A) should be a separate dimension, when in fact they belong in the fact table to maintain a star schema's simplicity and performance.
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
✓
Date dimension table with date attributes.
In a star schema, dimension tables contain descriptive attributes (e.g., dates, products, customers) and are connected to a central fact table. For the Orders table, a Date dimension (B) is essential for time-based analysis, a Product dimension (C) provides product details, and a Customer dimension (D) stores customer attributes. These three dimensions normalize the data and enable efficient slicing and dicing in Power BI.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
OrderDetails table with line items.
Why it's wrong here
The OrderDetails table stores transactional line items at the lowest grain, such as individual product quantities and prices for each sales order. In a star schema, this is the fact table (or part of it), not a dimension, because it contains the measurable numerical data and foreign keys to dimensions. Adding it as a dimension would duplicate the fact data and break the dimensional modeling principle where dimensions are descriptive, non-repetitive attributes.
- ✓
Date dimension table with date attributes.
Why this is correct
A Date dimension table is essential for time intelligence in Power BI, as it provides a contiguous set of dates with attributes like year, quarter, month, and week. By marking it as the date table, DAX functions such as TOTALYTD and SAMEPERIODLASTYEAR can perform time-based calculations correctly. Without a dedicated Date dimension, filtering by fiscal periods or comparing periods across years becomes unreliable, especially if the fact table has gaps in dates.
- ✓
Product dimension table with product attributes.
Why this is correct
The Product dimension table holds descriptive product attributes such as category, subcategory, brand, and unit cost, enabling slicers and report filters by product characteristics rather than raw keys. It maintains a one-to-many relationship with the fact table via a surrogate key, allowing users to aggregate sales metrics like revenue and units sold across any product hierarchy. This dimension is correct because it enriches the analysis with business perspectives that are not available in the fact table itself.
- ✓
Customer dimension table with customer attributes.
Why this is correct
A Customer dimension table is vital for customer-oriented analytics, containing attributes like name, region, industry, and segmentation that let report creators drill into behavioral patterns and demographics. It links to the fact table through a customer key, supporting calculations such as customer lifetime value, churn rate, and geographic sales distribution. Modeling customers as a separate dimension is correct because it avoids repeating long descriptive strings in the fact table and enables dynamic grouping and filtering.
- ✗
Sales fact table with measures.
Why it's wrong here
The Sales fact table is the central repository of measurable business events, holding numeric measures such as order quantity, unit price, and sales amount, along with foreign keys to all dimension tables. It is the backbone of the star schema, not a dimension, because dimensions are the descriptive context used to slice and dice these numbers. Treating the Sales fact table as a dimension would confuse the model and degrade query performance, as facts typically contain many rows at transactional grain, not unique attributes.
Go deeper
Related to this question
About these practice questions
Courseiva writes every PL-300 question from scratch — 217 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.