Overview
Model the data is 25–30% of the PL-300 exam and the analytical heart of Power BI, turning prepared tables into a semantic model. It has three objective groups. Designing and implementing the model covers configuring table and column properties, role-playing dimensions, relationship cardinality and cross-filter direction, a common date table, and calculated columns and tables. Creating calculations with DAX covers single aggregation measures, the CALCULATE function, time intelligence, basic statistical functions, semi-additive measures, quick measures, calculated tables and columns, and calculation groups. Optimizing performance covers removing unnecessary rows and columns, identifying poorly performing measures, relationships and visuals with Performance Analyzer and the DAX query view, and reducing granularity.
The star schema and DAX are the most important and most tested parts of this domain. The exam rewards designing a clean star schema with correct relationships, writing correct DAX, especially CALCULATE and time intelligence, and optimizing the model for performance.
How it's tested
PL-300 questions in this domain describe a modeling or calculation need and ask which relationship, DAX pattern or optimization to use. PL-300 questions are scenario-based and hands-on, so read the data situation and choose the Power BI feature, DAX pattern or configuration it points to before answering.
-
Design the model
A modeling need is described, and you choose the relationship, cardinality, cross-filter direction or date table.
-
Write the DAX
A calculation need is described, and you choose the DAX measure, CALCULATE pattern or time intelligence.
-
Optimize performance
A slow-model situation is described, and you choose the optimization or diagnostic tool.
A measure must show total sales for the same period last year to enable a year-over-year comparison. A plain SUM gives only the current total, and manually filtering dates is fragile. Using CALCULATE with a time intelligence function such as SAMEPERIODLASTYEAR shifts the filter context to the prior year, returning the correct comparison value, which is the DAX pattern the exam expects for period-over-period analysis.
Functional groups 3
Official functional groups from the Microsoft outline, in outline order.
2.1 Design and implement a data modelTables, relationships, cardinality, cross-filter direction and date tables.
- What it means
- This covers configuring table and column properties, implementing role-playing dimensions, defining a relationship's cardinality and cross-filter direction, creating a common date table, and identifying use cases for calculated columns and calculated tables.
- What to understand
- A good model is a star schema: fact tables linked to dimension tables by single-direction one-to-many relationships. Cardinality (one-to-many, many-to-many) and cross-filter direction (single or both) control how filters flow, and incorrect choices cause wrong results or ambiguity. A dedicated date table enables time intelligence, and role-playing dimensions reuse a dimension for multiple roles. Sound model design is the foundation of correct analysis.
- How it shows up
- A modeling need is described, and you must choose the relationship, cardinality, cross-filter direction or table design.
- Common confusion
- Setting the wrong cardinality or using bidirectional cross-filtering where single-direction is correct, causing ambiguous or wrong results.
2.2 Create model calculations by using DAXMeasures, CALCULATE, time intelligence and calculation groups.
- What it means
- This covers creating single aggregation measures, using the CALCULATE function, implementing time intelligence measures, using basic statistical functions, creating semi-additive measures, creating measures with quick measures, creating calculated tables and columns, and creating calculation groups.
- What to understand
- DAX computes values over the model. Measures are evaluated in filter context, and CALCULATE is the key function that modifies that context to change what a calculation sees. Time intelligence functions compute period-based values like year-to-date and prior-year. Calculated columns are stored row by row while measures aggregate on demand, and calculation groups apply a calculation across many measures. Correct DAX is essential and heavily tested.
- How it shows up
- A calculation need is described, and you must choose the DAX measure, CALCULATE pattern or time intelligence function.
- Common confusion
- Confusing calculated columns (stored, row context) with measures (aggregated, filter context), or misunderstanding how CALCULATE changes filter context.
2.3 Optimize model performanceRemoving waste, diagnosing bottlenecks and reducing granularity.
- What it means
- This covers improving performance by identifying and removing unnecessary rows and columns, identifying poorly performing measures, relationships and visuals using Performance Analyzer and the DAX query view, and improving performance by reducing granularity.
- What to understand
- Model performance depends on size and design: removing unneeded columns and rows shrinks the model, reducing granularity (summarizing to the needed level) cuts data volume, and well-designed relationships and efficient DAX speed queries. Performance Analyzer shows how long each visual takes, and the DAX query view helps diagnose slow measures. Optimizing keeps reports responsive.
- How it shows up
- A slow-model or large-model situation is described, and you must choose the optimization or diagnostic.
- Common confusion
- Keeping unnecessary columns and high granularity, or not using Performance Analyzer to find the actual bottleneck.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Star schema
Fact tables linked to dimensions.
- Remember
- The preferred Power BI model shape.
- Tested as
- Modeling questions.
- Trap
- Using a flat or snowflake model unnecessarily.
-
Cardinality
One-to-many, many-to-many relationships.
- Remember
- One-to-many is the norm.
- Tested as
- Relationship questions.
- Trap
- Choosing the wrong cardinality.
-
Cross-filter direction
Single or both directions.
- Remember
- Prefer single; both can cause ambiguity.
- Tested as
- Relationship questions.
- Trap
- Overusing bidirectional filtering.
-
Common date table
A dedicated date dimension.
- Remember
- Required for time intelligence.
- Tested as
- Modeling questions.
- Trap
- Relying on dates in the fact table.
-
Measure vs. calculated column
Aggregated on demand versus stored per row.
- Remember
- Measures use filter context.
- Tested as
- DAX questions.
- Trap
- Confusing the two.
-
CALCULATE
Modifies the filter context of a calculation.
- Remember
- The most important DAX function.
- Tested as
- DAX questions.
- Trap
- Misunderstanding filter context.
-
Filter context
The filters applied when a measure evaluates.
- Remember
- CALCULATE changes it.
- Tested as
- DAX questions.
- Trap
- Ignoring how context drives results.
-
Time intelligence
Period-based calculations like YTD and prior year.
- Remember
- Needs a date table.
- Tested as
- DAX questions.
- Trap
- Computing periods manually.
-
Calculation groups
Apply a calculation across many measures.
- Remember
- Reduce measure duplication.
- Tested as
- DAX questions.
- Trap
- Rewriting the same pattern per measure.
-
Reduce granularity
Summarize to the needed level.
- Remember
- Cuts model size.
- Tested as
- Performance questions.
- Trap
- Keeping needless detail.
-
Performance Analyzer
Shows each visual's query time.
- Remember
- Find the slow visual or measure.
- Tested as
- Performance questions.
- Trap
- Guessing at bottlenecks.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Measure vs. calculated column
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Measure | Aggregates on demand | Uses filter context | Using a column where a measure fits |
| Calculated column | Stored value per row | Uses row context | Using a column to aggregate |
Single vs. bidirectional cross-filter
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Single direction | Filters flow one way | Clear, preferred default | Overusing bidirectional |
| Bidirectional | Filters flow both ways | Can cause ambiguity | Using it without need |
SUM vs. CALCULATE with time intelligence
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| SUM | Totals in current context | Current-period value | Using it for period comparison |
| CALCULATE + time intelligence | Shifts the filter context | Prior-period or YTD value | Filtering dates manually instead |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Bidirectional everywhere
- What candidates pick
- Set relationships to bidirectional cross-filtering by default.
- Why it looks right
- It makes filters flow freely.
- Why it's wrong
- Single-direction filtering is the clear default; bidirectional can create ambiguous or incorrect results and should be used sparingly.
Clue to watch for Filter results are ambiguous or wrong with both-direction relationships.
-
Column instead of measure
- What candidates pick
- Create a calculated column to compute an aggregated total.
- Why it looks right
- Columns are concrete and visible.
- Why it's wrong
- Measures aggregate on demand in filter context; a calculated column stores a value per row and is wrong for dynamic aggregation.
Clue to watch for The value must respond to filters and slicers.
-
Manual date filtering
- What candidates pick
- Compute prior-year sales by manually filtering date ranges in DAX.
- Why it looks right
- It seems direct.
- Why it's wrong
- Time intelligence functions with CALCULATE shift the filter context correctly for prior-period comparisons; manual filtering is fragile.
Clue to watch for The measure must compare to a prior period.
-
No date table
- What candidates pick
- Use the dates in the fact table for time intelligence.
- Why it looks right
- The dates are already there.
- Why it's wrong
- Time intelligence needs a dedicated, continuous date table marked as a date table; fact-table dates alone are insufficient.
Clue to watch for Time intelligence functions behave incorrectly.
-
Keep all detail
- What candidates pick
- Load every column and the finest granularity even when not needed.
- Why it looks right
- More data seems safer.
- Why it's wrong
- Removing unnecessary columns and reducing granularity shrinks the model and improves performance.
Clue to watch for The model is large and reports are slow.
Answer framework
For any Domain 2 scenario, use these steps to find the answer PL-300 expects.
- Design a star schema: fact tables linked to dimensions with correct one-to-many cardinality and single-direction cross-filtering by default.
- Add a dedicated, marked date table to enable time intelligence, and use role-playing dimensions where needed.
- Write DAX using measures for dynamic aggregation, CALCULATE to modify filter context, and time intelligence for period comparisons.
- Use calculation groups to apply a pattern across many measures and avoid duplication, and know when calculated columns or tables fit.
- Optimize by removing unnecessary rows and columns, reducing granularity, and using Performance Analyzer and the DAX query view to find bottlenecks. Where two options seem to fit, choose the one that most precisely matches the scenario's data, message or requirement.
Practice question
Want more like this? The PL-300 practice test has questions for every domain.
Checklist
0 of 10
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Give this domain heavy attention, since it is analytically demanding and where many candidates lose marks. Start with star-schema design, because the model's shape, fact and dimension tables, correct cardinality, and single-direction cross-filtering, determines whether everything downstream is correct. Learn why bidirectional filtering is risky and why a dedicated date table is needed.
Then invest the most in DAX, the heart of this domain: understand filter context and the CALCULATE function that modifies it, the difference between measures and calculated columns, time intelligence for period comparisons, and calculation groups. Practice writing these, not just reading them.
Finally, learn performance optimization: removing unneeded columns, reducing granularity, and using Performance Analyzer and the DAX query view. Build and tune a real star-schema model in Power BI Desktop to make it concrete. Because PL-300 is hands-on, practice every task in Power BI Desktop and the Power BI service with real data rather than only reading, and review missed practice questions by domain to find weak spots. Afterwards, move to Domain 3, Visualize and analyze the data.
FAQ
How much of PL-300 is Domain 2?
Model the data is 25–30% of the exam, one of three equally weighted largest domains, and the analytical core of Power BI.
Why is a star schema recommended?
A star schema, with fact tables linked to dimension tables by single-direction one-to-many relationships, gives clear filtering, correct results, good performance and simpler DAX, which is why Power BI is optimized for it.
What does the CALCULATE function do?
CALCULATE evaluates an expression in a modified filter context. It is the most important DAX function because changing the filter context is how most non-trivial calculations, including time intelligence and conditional totals, are expressed.
What is the difference between a measure and a calculated column?
A measure aggregates on demand in the current filter context and responds to slicers and filters. A calculated column computes and stores a value per row using row context, and is fixed once calculated.
Why do I need a dedicated date table?
Time intelligence functions require a continuous, dedicated date table marked as a date table to compute period-based values like year-to-date and prior-year correctly. Relying on dates in the fact table alone is insufficient.
When should I use bidirectional cross-filtering?
Rarely. Single-direction cross-filtering is the clear default; bidirectional filtering can create ambiguity and incorrect results and should be used only for specific, well-understood cases such as certain many-to-many scenarios.
How does Domain 2 connect to the rest of the exam?
The model built here uses the data prepared in Domain 1, drives every visual in Domain 3, and its size and design affect the performance and governance addressed in Domain 4.
Test your Domain 2 knowledge
You have covered star-schema design, DAX, CALCULATE, time intelligence and performance. Test whether you can build and optimize the model under exam conditions.
Keep going
- Training Training Built on your Weak areas
- Practice test Questions by domain, with explanations
- Mock exam Full length, timed like the real exam
- Readiness test Find your weakest domain in minutes
- Cheat sheet Key terms and formulas on one page
- Ask the PL-300 AI tutor Get any concept explained your way