PL-300 Visualize and analyze the data Practice Question
Which THREE factors should you consider when designing a Power BI data model for a star schema? (Select three.)
⚠ Common exam trap
Microsoft often tests the misconception that normalization (Option C) is beneficial for star schemas, when in fact denormalization is preferred to avoid performance penalties from extra join hops in Power BI's query engine.
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
✓
Fact tables should contain numeric measures and foreign keys
Option B is correct because in a star schema the fact table stores the quantitative, numeric measures (such as Sales Amount or Quantity) along with foreign keys that reference the dimension tables, forming the core of the model. Option D is correct because dimension tables hold the descriptive, textual attributes (such as Product Name, Category, or Customer City) used for slicing and filtering the measures. Option E is correct because star schema relationships are one-to-many, with the dimension on the "one" side and the fact table on the "many" side, filtered in a single direction from dimension to fact. Option A is incorrect because many-to-many relationships between dimensions are not a star schema design factor; they add ambiguity and are typically avoided or resolved via bridge tables. Option C is incorrect because dimension tables in a star schema are intentionally denormalized (flattened) to reduce the number of joins and improve query performance, not normalized to reduce redundancy.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use many-to-many relationships between dimensions
Why it's wrong here
Using many-to-many relationships between dimensions violates the star schema principle of maintaining a clean, denormalized model. These relationships typically require bridge tables and introduce ambiguous row context, which can cause measures to multiply or filter incorrectly across unrelated dimension records. For a straightforward Power BI model, avoid many-to-many and instead design one-to-many relationships from dimensions to facts.
- ✓
Fact tables should contain numeric measures and foreign keys
Why this is correct
Fact tables should contain numeric, additive measures—such as sales amount, quantity, or margin—and foreign keys that reference dimension tables. This structure is fundamental to star schema design because it enables efficient aggregation and lets facts be filtered by dimension attributes. Without numeric measures or proper foreign keys, the fact table cannot support reliable calculations or relational integrity.
- ✗
Dimension tables should be normalized to reduce redundancy
Why it's wrong here
Normalizing dimension tables reduces data redundancy but produces a snowflake schema with multiple related lookup tables. This increases the number of joins Power BI must perform, degrading query performance and adding complexity for report authors and DAX expressions. Star schemas deliberately denormalize dimension tables to keep them wide and flat, optimizing for filtering, grouping, and user comprehension.
- ✓
Dimension tables should contain descriptive attributes
Why this is correct
Dimension tables should contain descriptive attributes—such as product names, customer segments, and geographic regions—that provide business context for measures. These attributes support intuitive filtering, grouping, and labeling in reports, allowing end users to explore data without technical knowledge. A dimension table with rich descriptive data is central to a self-service BI experience.
- ✓
Relationships should be one-to-many from dimension to fact
Why this is correct
Relationships in a star schema should be one-to-many from each dimension to the fact table, meaning a single dimension row can link to many fact rows. This cardinality ensures that filters applied to dimension attributes propagate correctly to fact rows, producing accurate aggregations. It also guarantees that dimension keys are unique, preventing double-counting of measures when slicers are used.
Visual reference
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 →
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.