Exam PL-300 topic 1 question 7 discussion

I'm very sure it's D. It's the Header/Detail Schema, and the most optimal way is to flatten the header into the detail table.

Should be A, because we need to get " Orders sold over time that include a measure of the total order value Orders by attributes of products sold" Order line detail for quantities ordered, and product for product's attribute

Brings product attributes (name, category, etc.) into the order line items table. Lets you calculate total order value easily (Price × Quantity). This is the best way to flatten the model and reduce need for real-time joins. Best for performance and required analysis Choosing option D adds unnecessary complexity, as product details will still be needed later for deeper insights. Merging Order Line Items with Products (option A) upfront simplifies the model, supports comprehensive analysis, and ensures better performance with minimal effort.

The best first step is D. From Power Query, merge the Orders query and the Order Line Items query. Here's why: You're analyzing orders over time and calculating total order value, which likely requires combining order-level and line-item-level data. Merging these two tables in Power Query (before loading to the model) ensures the heavy lifting is done during data prep, not at query time—this minimizes update times when interacting with visuals. It also allows you to precompute total order values or simplify relationships, which improves performance. Option A (merging Order Line Items with Products) might be useful later for product-level analysis, but it doesn't directly support the time-based order value analysis as efficiently as Option D does.

If we select A, which means we join Order details and product table. This can give me everything related to product wise total sale. Over we can get order wise sales also.

You’re doing analysis based on: Total order value over time → requires line-level transaction data Attributes of products sold → product info needs to be present at line level Merging Order Line Items with Products gives you a clean fact table with all required info in one place, optimized for aggregation. This results in faster visuals and lower model complexity. Considering the question specifically states, "The solution must minimize update times when interacting with visuals in the report," Answer D brings in unnecessary redundancy and will likely hurt performance, especially as data grows.

A because Orders by attributes of products sold meant that you have to join fact with prod. If choose D you still have to merge with prod. It not minimize update times when interacting with visuals

The order table's description says "contain high level information about order". Nothing else. And most importantly, the requirement is 1) order quantity, 2) order value and 3) order by product attributes - nothing else valuable can be acquired from the order table? Therefore if the requirement is to minimize update time of visual, don't bother connecting order and order line item table. Answer should be A

Answer is D. Tried and Tested.

Why not D: Merging these two tables would help calculate the total order value but does not associate product attributes (e.g., categories) with orders. Without merging Order Line Items and Products, you cannot analyze orders by product attributes effectively.

Note: We must suggest the action we should perform FIRST. Of course, we need the Products table for the product attributes but first, we need to merge the Orders and Order Line Items to get the time-based information from the Orders table. We need that for the "Orders sold over time". The Order Line Items table does not have time-based information(Date). As per the question, it only has those 3 columns. After using number D as the first step, we can merge the Product table, write DAX for total order value, etc...

I choose A. The Products table contains product attributes (e.g., category, brand), but it cannot directly connect to the Orders table since there’s no shared key. The Order Line Items table acts as a bridge between the Products table (via Product ID) and the Orders table (via Order ID). By merging Products with Order Line Items, the resulting table includes both product attributes and order-level details, enabling comprehensive analysis. For analysis 1 (orders sold over time with total order value): Use the merged table to calculate total order value (Quantity × Price) for each order and aggregate by the order date from the Orders table. For analysis 2 (orders by product attributes): Filter and group the merged table by product attributes (e.g., category or brand) to analyse sales performance for specific product groups.

D is right, Merging the Orders query with the Order Line Items query in Power Query creates a more efficient data model. This reduces the number of relationships and joins that need to be processed during report interactions, leading to faster update times. With the merged data, calculations such as total order value and orders by product attributes become simpler and more efficient. This reduces the need for complex DAX calculations that can slow down report performance

The Order Line Items table contains only the following columns: Product ID Quantity Price Details It does not include a date column or other high-level order information. The Orders table, on the other hand, likely contains essential information such as: Order Date (for time-based analysis) Order ID (to link with Order Line Items) Customer Details (if needed) so Answer is D

D - From Power Query, merge the Orders query and the Order Line Items query

Hello everyone, to make it clear we must to know: --- PBI will do the best aggregation base on Star Schema model, we now have 1 Fact table (Order Line Items) and 2 Dim tables (Products, Orders). Orders has common field with Products (ProductID), and pretty sure time series field (OrderDate); Orders Line Items has Price and Quanity. --- We need summarize some values like "price" and "quantity" over-time by attributes product. But we only have common field in Dim table (Orders) so we need to merge Dim (Orders) and Fact (Order Line Items) to new single Fact table to design the right Star Schema model. => So that D is correct

Might be option A. How about the orders by attribute without accessing the Product datasource ?