PL-300: Model the Data Domain Explained

If Prepare the Data is the foundation, Model the Data (25-30% of the PL-300) is the structure you build on it. This is the conceptual heart of Power BI and where candidates either shine or struggle. It tests whether you can design a sensible data model, connect tables correctly, and write DAX that returns the right numbers.

This guide walks through star schema design, relationships, DAX, date tables, and row-level security, with hands-on steps and Indian retail examples.

The star schema: the single most important idea

Power BI is built to love the star schema. Get this right and everything else gets easier; get it wrong and you will fight the tool forever.

A star schema has two kinds of tables:

• Fact tables hold the events you measure - one row per transaction. For a retailer this is Sales, with columns like order_id, date, product_id, customer_id, city_id, quantity and amount.
• Dimension tables hold the descriptive context you slice by - Product, Customer, Date, Geography. Each has a key and attributes (product name, category, customer segment, state).

The fact table sits in the centre, dimensions surround it, and relationships radiate out like a star. Avoid the snowflake (dimensions split into further sub-tables) where you can, and especially avoid one giant flat table, which kills performance and breaks filtering.

Exam tip: if a question gives you a wide flat table, the "best" answer often involves splitting it into a fact plus dimensions - a star schema.

Relationships: cardinality and cross-filter direction

You create relationships in the Model view by dragging a key from one table to another. Two properties matter enormously.

Cardinality

• One-to-many (1:*) is the normal, healthy relationship: one row in a dimension (one product) relates to many rows in the fact (many sales). The dimension is the "one" side.
• Many-to-one is the same thing viewed the other way.
• One-to-one is rare and usually a sign two tables should be merged.
• Many-to-many is powerful but risky; use it deliberately, not by accident.

Cross-filter direction

• Single is the default and the safe choice: filters flow from the dimension (one side) down to the fact (many side). Selecting a category filters sales.
• Both (bidirectional) lets filters flow in both directions. It is occasionally necessary but can create ambiguity and performance issues, so use it sparingly and know why.

Exam tip: understand that filters flow from the one side to the many side by default, and be ready to explain when bidirectional filtering is justified.

Calculated columns vs measures

This distinction is heavily tested.

• Calculated columns are computed row by row and stored in the model. They consume memory and recalculate on refresh. Use them when you need a value on every row - for example a Profit Margin % per transaction, or a column to slice or group by.
• Measures are calculated on the fly at query time, in the current filter context. They use almost no storage and are the right choice for aggregations like total sales, average order value, or year-over-year growth.

Rule of thumb: if you can make it a measure, make it a measure.

Total Sales = SUM ( Sales[amount] )

Average Order Value =
DIVIDE ( [Total Sales], DISTINCTCOUNT ( Sales[order_id] ) )

DAX essentials

DAX is the language of the model. For the exam, be comfortable with these building blocks.

• Aggregations - SUM, AVERAGE, COUNT, DISTINCTCOUNT, MIN, MAX.
• CALCULATE - the most important DAX function; it modifies filter context.
• FILTER - returns a filtered table to feed into CALCULATE.
• Iterators - SUMX, AVERAGEX compute row by row then aggregate.
• DIVIDE - safe division that handles divide-by-zero.

A classic example: total sales for one state only.

Maharashtra Sales =
CALCULATE (
    [Total Sales],
    Geography[state] = "Maharashtra"
)

Understanding filter context - the set of filters applied when a measure evaluates - is the single biggest DAX hurdle. CALCULATE works precisely because it changes that context.

Date tables and time intelligence

Almost every report needs date analysis, so a dedicated Date table is essential. You can create one in DAX:

Date =
CALENDAR ( DATE ( 2023, 4, 1 ), DATE ( 2026, 3, 31 ) )

Then add columns for Year, Month, Quarter, and the Indian financial year (April-March), and mark it as a date table in Power BI. Once you have it, time-intelligence functions unlock month-over-month and year-over-year analysis.

Sales YTD =
TOTALYTD ( [Total Sales], 'Date'[Date] )

Sales LY =
CALCULATE ( [Total Sales], SAMEPERIODLASTYEAR ( 'Date'[Date] ) )

Exam tip: time-intelligence functions require a proper, continuous date table related to your fact table - they will not work reliably on a raw date column.

Row-level security basics

Row-level security (RLS) restricts which rows a user can see. You define it in the Manage roles dialog under Modeling, writing a DAX filter on a table.

[state] = "Karnataka"

That role shows only Karnataka rows. For dynamic security where each manager sees only their region, you use USERPRINCIPALNAME() to match the logged-in user against a mapping table. You create the roles in Power BI Desktop, test them with View as roles, and assign users to roles in the Power BI Service after publishing.

Exam pointers

• Recognise and justify a star schema; know fact vs dimension tables.
• Explain cardinality and cross-filter direction, and that filters flow one-to-many by default.
• Distinguish calculated columns (stored, per row) from measures (computed at query time) and prefer measures.
• Know what CALCULATE does to filter context.
• Understand why a marked date table is required for time intelligence.
• Describe static vs dynamic RLS and where roles are assigned.

A clean model with the right relationships and well-written measures makes visualisation almost effortless. This is the domain that turns a Power BI button-clicker into a real data analyst.

Related: Top 25 Power BI Interview Questions with Real Answers · Take a PL-300 mock exam

Don't just read. Prove your skill on DevWithData.