PL-300 Prepare the data Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Create a star schema with Sales as a fact table and Customers and Products as dimension tables.

  Why this is correct

  Star schema is the recommended modeling approach in Power BI because it separates measure-bearing numeric data (Sales) from descriptive attributes (Customers, Products). This structure leverages VertiPaq's columnar compression by storing dimensions as small, indexed tables, and enables unambiguous one-to-many relationships that make DAX filters propagate correctly. As a result, queries are simpler, more performant, and the model is easier for report consumers to navigate.

• ✗

  Create separate fact tables for each dimension.

  Why it's wrong here

  Creating a separate fact table for each dimension is incorrect because fact tables are meant to store transactional metrics—not dimension attributes. Doing so would result in multiple fact tables that need to be joined to one another, creating ambiguous relationships and forcing DAX to use CROSSFILTER or bidirectional filters just to connect a single sale to its customer and product. This anti-pattern bloats the model, complicates measure logic, and drastically reduces row-level aggregation performance.

• ✗

  Create a single flat table by joining all columns from Sales, Customers, and Products into one table.

  Why it's wrong here

  Combining Sales, Customers, and Products into a single flat table denormalizes the model and inflates storage: every sale row would repeat customer names, product categories, and other text attributes, expanding the in-memory footprint and slowing refresh and query times. It also makes attribute changes difficult to maintain—updating a customer's region requires touching every row rather than a single dimension record—and can produce incorrect granularity when users expect to filter or group by product attributes.

• ✗

  Create a snowflake schema by normalizing Customers into multiple related tables.

  Why it's wrong here

  While snowflake schemas reduce duplicate data in traditional relational databases, Power BI's columnar engine performs best with fewer, wider dimension tables. Normalizing Customer into separate region, territory, and contact tables forces queries to traverse multiple one-to-many relationships, which increases DAX complexity, creates more chances for ambiguous filter paths, and can degrade performance due to extra joins and larger metadata overhead. Power BI does not need the same normalization that OLTP systems do; a star schema maximizes both speed and ease of use.

Go deeper

Related to this question