Exam PL-300 All QuestionsBrowse all questions from this exam
Go to Exam
Question 65

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?

    Correct Answer: B

    Renaming the date table as Due Date and creating Order Date and Delivery Date as calculated tables does not meet the goal of supporting the analysis of sales over time based on all the date foreign keys. The proper approach would involve keeping the date table as a separate entity and establishing relationships between this date table and the sales table using the respective date foreign keys: Due Date, Order Date, and Delivery Date. This setup would allow Power BI to perform the necessary time-based analyses by leveraging these relationships to filter and aggregate data accurately.

Discussion
fred92Option: A

Yes, that will meet the goal. It will increase the model size, but that was not the question.

CHT1988

I agree with you. The model size is not mentioned in the question, so it would meet the goal.

poujorOption: B

NO is the Answer. To be able to create the calculations you need the Relationships. They are NOT stated in this suggestion.

Tiz88

These type of questions are not really clear. But agreed, you clearly need relationships. What if you have "autodetect relationship" option active?

sdawn

foreign keys imply having relationships in place, therefore it is absurd to assume otherwise.

semauniOption: B

No. We're dealing with role-playing dimensions, and creating additional tables will produce confusing results. Guy in a Cube explained this well in his video. We need ONE date table with inactive relationships. Source: https://www.youtube.com/watch?v=2BxaUXlx3K4 Source: https://learn.microsoft.com/en-us/power-bi/guidance/star-schema

Maniula

No, we need additional tables https://learn.microsoft.com/en-us/training/modules/dax-power-bi-add-calculated-tables/1-introduction

RazaTheLegendOption: A

Definitely YES You should follow this refactory methodology: 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. This question is about an IMPORT table. So the use of a calculated table is recommended. Source: https://learn.microsoft.com/en-us/power-bi/guidance/relationships-active-inactive

PREM77Option: B

Answer is No. Renaming the date table as "Due Date" and creating calculated tables for "Order Date" and "Delivery Date" will not provide the necessary functionality for analyzing sales over time. To achieve the goal, you would typically create relationships between the date table and the sales table based on the respective date foreign keys. This allows Power BI to perform time-based analysis by using the relationships to filter and aggregate data. Instead of renaming the date table, you should keep it as a separate table, typically named "Date" or "Calendar." Then, you would establish relationships between the date table and the sales table using the respective date foreign keys: Due Date, Order Date, and Delivery Date.

MoppuOption: A

Think the answer should be A, but you need the relationships. Not sure why this question is more one sided than the one above though.

Ryan_042Option: B

Creating a calculated table does not keep the original table relationship. This solution is even worse than the one using Power Query to duplicate the 3 date tables. If the auto-detect relationship is enabled, at least using Power Query might not require a relationship.

protivitiuserOption: A

after you read this https://learn.microsoft.com/en-us/power-bi/guidance/relationships-active-inactive the answer should be clear

IgetmyroleOption: B

B is the correct answer. No, this solution does not meet the goal of supporting the analysis of sales over time based on all the date foreign keys. Remaining the date table as "Due Date" and creating calculated tables for Order Date and Delivery Date using DAX expressions does not establish relationships between the sales table and the date table based on the different date foreign keys (Due Date, Order Date, and Delivery Date).

sergeyitalyOption: B

Noone of those who say Yes did not mention about creation relationship in the model. And this is a key element in data analysis. So, the answer is No.

mirzottiOption: B

No, for so many reasons already mentioned by others in this thread. Here is one other reason; only 2 out of 3 tables are mentioned as calculated tables. What happened to 3rd calcluated table? It is missing so it does not meet the goal.

Maniula

Third table already exists and is called "Due Date", you use it to create the other two.

ageleeOption: A

The question is if we do it in PowerQuery Editor. It's not said. In PowerQuery we can create a copy of table by DAX usage and it will work. "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." Departure Airport = 'Arrival Airport'. "Create an active relationship to relate the new table."

lukelin08Option: A

A. Yes (is correct) it's not the best method but it works

RMUKOption: B

No, again its about how will you design the data model. Even if you can create multiple date table for each date field. Standard approach in this case should be one date table, 1 active and 2 inactive relationships.

WRTopicsOption: B

No, the correct answer is B.

bakamonOption: B

No, the reference link given in the answer shows that it needs inactive relationship

UlyUkrOption: B

I would say NO, since the solution does not specify creating the relationships. Auto detection feature does not guarantee the correct relationships creation.