Examice

Exam PL-300 All QuestionsBrowse all questions from this exam

Go to Exam

Question 67

HOTSPOT -

You have a Power BI report named Orders that supports the following analysis:

✑ Total sales over time

✑ The count of orders over time

✑ New and repeat customer counts

The data model size is nearing the limit for a dataset in shared capacity.

The model view for the dataset is shown in the following exhibit.

The data view for the Orders table is shown in the following exhibit.

The Orders table relates to the Customers table by using the CustomerID column.

The Orders table relates to the Date table by using the OrderDate column.

For each of the following statements, select Yes if the statement is true, Otherwise, select No.

NOTE: Each correct selection is worth one point.

Hot Area:

Correct Answer:

Box 1: No -

Would not support total sales over time.

Box 2: No -

Would not support new and repeat customer counts

Box 3: Yes

Discussion

Fer079

My answer is NO NO YES Summarizing Orders by CustomerID, OrderId and OrderDate means to group by CustomerID, OrderId and OrderDate and to aggregate the rest of the fields, however the OrderId has unique values so the aggregation will have the same number of rows as the original table

PinkZebra

Yes No Yes Removing unnecessary columns already help reduce the model size. We don't know for sure if other order ids have more than one product..

KoryMills

how do we know OrderID is unique just from the sample data?

HassanHijazi

You assume it is because the showed like so. For other columns, you see they included repetitive values to showcase they are not unique

khalidmirghnee

Each order may contains number of different products, that mean the orderid will be repeated more than one time in the Order table. The answer should be Yes, No, Yes.

Flix

Unique would be orderline, but since and order can have multiple products...

AzureJobsTillRetire

Box1: Yes The summarizing data will remove Product information which is not required for this analysis. We should not infer from the sample data that OrderId is the primary key for few reasons. 1) the Order table is a common table that is used by Microsoft in learning materials, and the table usually has a surrogate key as the primary key. 2) Order ID can be printed on the invoice, and it is not a surrogate key. BTW, the Customer ID is not a surrogate key as well. 3) An order usually consists of multiple products. 4) The Product Id is unique in the sample data as well, and we won't infer that we must create an order for a separate product. Box 2: No Customer ID is required for new and returned customer analysis Box3: Yes Product information is not required for analysis. Note: if the first analysis requirement changes from "Total sales over time" to "Total sales over time for products", we will have a different question to deal with

AzureJobsTillRetire

Please also refer to Question 38 in Topic 2 on how a more completed Sales Order table would look like. In that question the OrderID is called SalesOrderNumber and the surrogate key is the ID column. Please note that those two columns are separated

JudT

The correct answer is : * No ( "Orderid" is unique so can't be aggregated with other two columns) * No ( Star schema, "Customerid" is needed) * Yes ( Don't need those columns for analysis)

Igetmyrole

NO NO YES No: Summarizing orders with these columns may actually increase the model size as creates a more detailed representation of the data. It will not reduce the model size. No: Since there's a relationship between the Orders table and the Customers table using the CustomerID column, removing it might affect the ability to analyze data by customer, so it may not support the current analysis. Yes: Removing unnecessary columns like UnitPrice and Discount that are not used in the analysis will likely reduce the model size without affecting the ability to analyze total sales over time, order counts, and customer counts.

DANIEL

When you look at the data in the table you see customer TORTU having ONE order composed of THREE different productID with the same ordered date. Furthermore, looking at the data of OrderID, it pretty looks like an autonumber to me which is unique and incremental. Some might say no, TORTU made 3 different orders. Okay but then I suppose ordered date should be different, right ? Based on those assumptions, summarizing will have no effect on the size. So, NO, NO, YES

CG31

My answer is: 1. No- can you summarize the date column? 2. No- this is a star schema, you need to have a connection between the customer dimension and the fact table with the sales 3. No- the total sales seem to be a calculated column, Unit price*Qty, does it make sense to remove it?

Win_111

Total Sales column already calculated Unit Price * Qty

CRAKN1

WE CAN REMOVE THAT COLUMNS AFTER CALCULATING TOTAL SALES IN THE NEW COLUMN.

JudT

That's right

RazaTheLegend

If you see the table, the order ID is unique, so you are not going to have the same Order ID more than twice. For example, you will see that for the customer TORTU has 3 different products (18, 63, 75) under the same order because the OrderDate is exactly the same so we have to think it´s the same order, however the OrderID is sequential (unique). So NO, NO, YES

JudT

A Legend!

UlyUkr

1st statement NO. TotalSales is not included in the summarization, therefore won’t support current analysis. Normally after creating the aggregated table, you would disable the original table from loading into the model to reduce overall size. 2nd statement is NO, you can’t remove the key column, on which relationship is based. 3r statement is YES, you can remove those columns as they are not needed for current analysis. TotalSales will serve the purpose to calculate Total sales over time. I assume TotalSales is a normal column, not calculated one.

Dsbuff

No / No / Yes

Robert44

1/ yes because we remove ProductID. impossible to know if it is unique like OrderID 2/ No, CustomerID is used in a relationship 3/ No, UnitPrice is useful for calculating total sales. I don't understand why so many people think it's Yes. How do you calculate Total Sales?

walexis

we already have a total sales column. no need of units price for analysis cases

kelvin3105

Fer079 8 months, 4 weeks ago if you see the table, the order ID is unique, so you are not going to have the same Order ID more than twice. For example, you will see that for the customer TORTU has 3 different products (18, 63, 75) under the same order because the OrderDate is exactly the same so we have to think it´s the same order, however the OrderID is sequential (unique). So NO, NO, YES

kiwi69

Yes, No, Yes An order table with a ProductId column usually includes more products for the same OrderId, otherwise it will have an OrderLineId that here is not present. Also, it's never stated that OrderId is unique. Hence, summarizing will do the trick.

Shalaleh

My answer: NO: orderID is unique, suppose s CostumerID has several Orders in a day. we cannot aggregate that. NO we need CustomerID for the relationship YES we do not need them.

nmosq

No - Even if we don't know that OrderId is unique, if you want to see clients that buy more than once, you can summarize the data No - Removing this field will break the relationships Yes - They are not part of the analysis for the users, so they are "extra" data

Flix

Yes: Since you don't know the order ID is unique or not but it also contains products so probably not otherwise would have been orderline ID. YES: You can count the new customers based on this table so no need for a relationship with the customer, there is no extra information visible within the customer table. YES: Don't need the columns

khalidmirghnee

Yes No Yes

Robert44

1/ oui car on enlève ProductID. impossible savoir s'il est unique comme OrderID 2/ Non, CustomerID est utilisée dans une relation 3/ Non, UnitPrice est utile pour calculer le total des ventes. je ne comprend pas pourquoi il y a autant de gens qui pensent que c'est Yes. Comment calculez vous Total des ventes ?

DANIEL

parce que le dernier champ est le total des ventes donc inutile de recalculer