PL-300 - Model the Data (35% of the exam) - Section 2.1

Design and implement a data model including relationships and star schema best practices.

Design a star schema by separating fact and dimension tables, and define relationships with appropriate cardinality to enable correct aggregations. Choose cross-filter direction carefully, recognising that bidirectional filtering can cause ambiguous results in complex models.

star schemafact and dimension tablesrelationshipscardinalitycross-filter direction

Practice question for this objective

Free sampleModel the Datamedium

You are classifying tables in a new sales semantic model. Which combination of characteristics best describes a fact table in star schema design?

ADescribes business entities with descriptive attributes and is typically a small table.
BHolds a snowflake set of normalised lookup tables for a single business entity.
CStores events with dimension keys and numeric measure columns, typically with many rows. Correct
DActs as a disconnected table that accepts slicer input for what-if scenario analysis.

Fact tables hold events and measures with dimension keys; dimensions describe the entities that filter them. Fact tables store observations or events such as sales orders, stock balances, exchange rates, or temperatures. They contain dimension key columns that relate to dimension tables plus numeric measure columns, and they typically grow much larger than dimension tables over time.

Why A is wrong: This describes dimension tables, which hold attributes used for filtering and grouping rather than the events themselves.

Why B is wrong: Snowflake dimensions are normalised sets of dimension tables for one entity, not a description of fact tables.

Why C is correct: Correct. Fact tables store observations or events such as sales orders, stock balances, exchange rates, or temperatures.

Why D is wrong: Disconnected tables are isolated input tables for what-if patterns; they do not hold business events.

See more PL-300 practice questions, answers explained.

Exam traps in Model the Data

Answers that look right on this material and are not. Each one is a distractor from a different question in the PL-300 bank for this domain.

Automatic conversion of all sibling relationships to many-to-many cardinality.
Why it is wrong: Changing cross-filter direction does not change the cardinality of sibling relationships; the engine flags ambiguity rather than rewriting cardinality.
Star schema eliminates the need for any DAX measures in the model.
Why it is wrong: Star schema does not eliminate DAX; explicit measures are still recommended for controlled summarisation and for MDX consumers.
Many to many (*:*) from Product to Sales using ProductID as the key.
Why it is wrong: Many-to-many is reserved for cases where both columns can contain duplicates; here Product[ProductID] is unique, so it is not many-to-many.

Examworthy is not affiliated with or endorsed by Microsoft. Original, blueprint-aligned practice material only.