PL-300 · Question #309
Note: This question is part of a series of questions that present the same scenario. Each question in the series contains a unique solution that might meet the stated goals. Some question sets might h
The correct answer is A. Yes. Here's a methodology to refactor a model from a single role-playing dimension-type table, to a design with one table per role. 1. Remove any inactive relationships. 2. Consider renaming the role-playing dimension-type table to better describe its role. In the example (not present
Question
Note: This question is part of a series of questions that present the same scenario. Each question in the series contains a unique solution that might meet the stated goals. Some question sets might have more than one correct solution, while others might not have a correct solution. After you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not appear in the review screen. You have a Power BI report that imports a date table and a sales table from an Azure SQL database data source. The sales table has the following date foreign keys:
- Due Date
- Order Date
- Delivery Date
You need to support the analysis of sales over time based on all the date foreign keys. Solution: From the Fields pane, you rename the date table as Due Date. You use a DAX expression to create Order Date and Delivery Date as calculated tables. Does this meet the goal?
Options
- AYes
- BNo
How the community answered
(19 responses)- A79% (15)
- B21% (4)
Explanation
Here's a methodology to refactor a model from a single role-playing dimension-type table, to a design with one table per role. 1. Remove any inactive relationships. 2. Consider renaming the role-playing dimension-type table to better describe its role. In the example (not present here), the Airport table is related to the ArrivalAirport column of the Flight table, so it's renamed as Arrival Airport. 3. Create a copy of the role-playing table, providing it with a name that reflects its role. If it's an Import table, we recommend defining a calculated table. If it's a DirectQuery table, you can duplicate the Power Query query. In the example, the Departure Airport table was created by using the following calculated table Departure Airport = 'Arrival Airport' Create an active relationship to relate the new table. 4. Consider renaming the columns in the tables so they accurately reflect their role. In the example, all columns are prefixed with the word Departure or Arrival. These names ensure report visuals, by default, will have self-describing and non-ambiguous labels. It also improves the Q&A experience, allowing users to easily write their questions. 5. Consider adding descriptions to role-playing tables. (In the Fields pane, a description appears in a tooltip when a report author hovers their cursor over the table.) This way, you can communicate any additional filter propagation details to your report authors. https://docs.microsoft.com/en-us/power-bi/guidance/relationships-active-inactive
Community Discussion
No community discussion yet for this question.