PL-300 Model the data Practice Question
Which THREE of the following are benefits of using a star schema in Power BI? (Select three.)
⚠ Common exam trap
Test-takers frequently confuse star schemas with snowflake schemas or assume that many-to-many relationships are a native benefit, when in fact star schemas rely on one-to-many relationships for optimal performance and simplicity.
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
✓
Simplified DAX formulas
Option A (Simplified DAX formulas) is correct because a star schema separates quantitative facts from descriptive dimensions, so measures typically aggregate a single fact table and filter through one-to-many relationships, avoiding complex bidirectional or multi-table filter logic in CALCULATE and RELATED calls. Option C (Improved query performance) is correct because the Power BI engine (VertiPaq) compresses and scans narrow dimension tables and a single fact table efficiently, and one-to-many relationships let the engine use simpler, faster join paths than snowflaked or normalized models. Option E (Easier for business users to understand) is correct because dimensions map to familiar business entities (Customer, Product, Date) and facts to measurable events, making the model intuitive for self-service report authors. Option B is not correct because star schemas rely on one-to-many relationships; many-to-many relationships are not native to the star design and require bridge tables or special handling. Option D is not correct because increased data redundancy is a drawback of denormalization, not a benefit—star schemas actually reduce redundancy compared with fully normalized models while accepting controlled duplication in 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.
- ✓
Simplified DAX formulas
Why this is correct
A star schema's single-hop relationship between each dimension and the fact table means measures written in DAX do not need to traverse multiple relationship levels or perform context transitions across a snowflake chain. Because each filter propagation follows one predictable path, CALCULATE and FILTER functions operate against a well-defined filter context, resulting in shorter, more maintainable measures that are easier to debug and audit. This simplicity directly reduces the amount of DAX needed to create accurate totals and percentage calculations.
- ✗
Supports many-to-many relationships natively
Why it's wrong here
A classic star schema assumes each fact row connects to exactly one row in each dimension, preserving a strict one-to-many relationship. Genuine many-to-many relationships, such as a customer buying multiple products and a product being bought by multiple customers, cannot be represented without an explicit bridge table or junction table to resolve the ambiguity. Therefore, star schemas do not natively support many-to-many relationships; claiming otherwise is a misconception because additional modeling constructs are always required.
- ✓
Improved query performance
Why this is correct
Because a star schema eliminates multi-level joins, a query from the fact table to any dimension is always a single join hop. This reduces the complexity of the query plan, improves cardinality estimation, and allows the VertiPaq storage engine to leverage columnstore compression and bitmap filters more effectively when applying filters or aggregations. Consequently, fewer joins mean less CPU and memory overhead, which directly translates to faster report rendering and smoother interactivity.
- ✗
Increased data redundancy
Why it's wrong here
This is incorrect because a star schema actually reduces redundancy in the fact table by moving descriptive attributes into separate dimension tables, leaving only numeric measures and foreign keys in each fact row. While dimension tables themselves may contain some denormalized columns, the fact table avoids repeating long text values like product descriptions or customer addresses for every transaction. The overall model is less redundant than a fully normalized OLTP structure, not more redundant.
- ✓
Easier for business users to understand
Why this is correct
The visual structure of a central fact table surrounded by descriptive dimension tables maps naturally to how business users think about queries, such as asking for 'sales by product across time' by simply dragging fields from the product and date dimensions. Since each dimension connects through a single intuitive relationship, users can explore data without understanding join paths or complex filter logic. This transparency accelerates ad-hoc reporting and reduces the dependency on IT to build custom measures.
Go deeper
Related to this question
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.