PL-300 Model 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 calculated column in the sales table to extract the date part and relate it to the date table.

  Why it's wrong here

  Adding a calculated column to extract a date part from sales data is redundant because the dedicated date table already provides the appropriate granularity and key for time-sequential analysis. More importantly, this approach does not register the date table as a date table for DAX time intelligence, so functions like TOTALYTD and SAMEPERIODLASTYEAR will not behave correctly. It also increases model size and processing overhead, and any derived column with a different data type may break the relationship or filter propagation.

• ✓

  Create a one-to-many relationship from the date table to the sales table and mark the date table as a date table.

  Why this is correct

  This is the correct design: Power BI time intelligence functions (e.g., DATESYTD, DATEADD) rely on a date table that is explicitly marked with the Mark as Date Table option, and a one-to-many relationship from the date table to the sales table ensures each date filters its associated sales rows unambiguously. Marking the date table lets the engine identify the date column for time-based calculations, while the one-to-many cardinality matches the logical model where each calendar day can appear in many fact records. This star-schema pattern supports reliable, accurate time-series reporting.

• ✗

  Create a many-to-many relationship between the date table and the sales table.

  Why it's wrong here

  A many-to-many relationship between the date table and sales table is inappropriate because it implies that a single sales transaction can occur on multiple dates and a single date can be linked to multiple transactions, which is not true for typical fact tables with a date foreign key. Time intelligence functions require a clear one-to-many filter path to propagate date selections to fact rows; without it, totals can be double-counted and DAX calculations may become ambiguous. Power BI also does not allow marking a table that participates in many-to-many as a date table, making it impossible to use standard time intelligence patterns.

• ✗

  Create a one-to-many relationship from the sales table to the date table with bidirectional cross-filtering.

  Why it's wrong here

  Reversing the relationship direction—from sales to date—violates the filter flow expected in a star schema, since the dimension (date) must be on the one side and the fact (sales) on the many side to allow date filters to reach sales data. Adding bidirectional cross-filtering is unnecessary for time intelligence and actually increases model complexity, risk of ambiguous filter propagation, and query performance degradation. Marking the date table as a date table still requires the correct one-to-many direction and single-direction filtering to work properly.

Go deeper

Related to this question