What Should Be Stored in a Dimension Table in Power BI Star Schema?
You are building a star schema in Power BI. The fact table contains sales transactions. Which of the following should be stored in a dimension table?
Quick Answer
The correct answer is product category, because it is a descriptive attribute that belongs in a dimension table within a star schema. In a properly designed star schema, dimension tables store the “who, what, where, when” context—such as product names, categories, or customer regions—while fact tables store quantitative measures like sales amount. For the Microsoft Power BI Data Analyst PL-300 exam, this question tests your understanding of star schema fundamentals and the separation of descriptive attributes from numeric measures. A common trap is confusing foreign keys, like customer ID, which reside in the fact table as links, with the descriptive attributes that populate dimension tables. Remember the memory tip: “Facts are numbers, dimensions are descriptors”—if it describes a business entity, it belongs in a dimension.
⚠ Common exam trap
PL-300 often tests whether candidates can distinguish descriptive dimension attributes from numeric measures and foreign keys, so the trap is picking a key or measure thinking it is a dimension attribute.
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
✓
Product category
In a star schema, dimension tables store descriptive attributes used for filtering, grouping, and labeling fact data. Product category is a descriptive attribute of the product dimension, so it belongs in a dimension table. Fact tables store numeric, additive measures and foreign keys that reference dimensions.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Product category
Why this is correct
Product category is descriptive, non-additive text used for slicing sales measures, so it belongs in a dimension. Fact tables hold numeric, aggregatable transaction data such as quantity and revenue, making category the correct dimensional attribute.
- ✗
Sales amount
Why it's wrong here
Sales amount is a numeric measure aggregated across transactions, so it belongs in the fact table, not a dimension. Dimensions hold descriptive attributes used for slicing; storing amounts there breaks aggregation and inflates the model.
- ✗
Customer ID
Why it's wrong here
Customer ID is a foreign key linking each sale to its customer, so it stays in the fact table; the dimension holds descriptive attributes such as name, city and segment. It tempts because it identifies a customer, but keys are not dimension attributes.
- ✗
Transaction date
Why it's wrong here
Transaction date is a degenerate dimension attribute stored on the fact row, not a dimension table member; it identifies each sale directly. It tempts because dates commonly populate a dedicated Date dimension, but that dimension holds calendar attributes (year, quarter, month) for slicing, not the per-transaction timestamp itself.
Go deeper
Related to this question
About these practice questions
One of 524 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 →
Same concept, more angles
1 more way this is tested on PL-300
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. You are building a Power BI model that includes a table 'Orders' with columns: OrderID, CustomerID, OrderDate, and TotalAmount. You also have a table 'Customers' with columns: CustomerID, CustomerName, and Segment. You need to create a relationship between Orders and Customers on CustomerID. Which relationship configuration should you choose to ensure that filtering Customers by Segment correctly filters Orders?
hard- ✓ A.One-to-many relationship from Customers to Orders
- B.Many-to-one relationship from Orders to Customers
- C.Many-to-many relationship with a bridge table
- D.One-to-one relationship
Why A: In a star schema, the dimension table (Customers) has a unique CustomerID and the fact table (Orders) has many rows per customer, so the relationship is one-to-many from Customers to Orders. Power BI's default filter direction is single, meaning Customers filters Orders, which is exactly what is needed for filtering Orders by Segment. This is the standard dimensional modeling pattern.
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Microsoft exam blueprint
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.