Does Removing ProductID Shrink the Model Yet Keep City Analysis?
Note: This section contains one or more sets of questions with the same scenario and problem. Each question presents a unique solution to the problem. You must determine whether the solution meets the stated goals. More than one solution in the set might solve the problem. It is also possible that none of the solutions in the set solve the problem.
After you answer a question in this section, you will NOT be able to return. As a result, these questions do not appear on the Review Screen.
You are creating a Power BI semantic model named Model1 that contains the following tables.
The tables have the following relationships.
You have 100 salespeople in 10,000 cities. Each salesperson sells in multiple cities.
You import one million rows into the Sales table.
You need to reduce the size of Model1. The solution must ensure that you can analyze the total number of sales by salesperson per city.
Solution: You remove the ProductID column from the Sales table.
Does this meet the goal?
Community Insight
The question tests whether you can trim a fact table without breaking the required grain of analysis—the trap is assuming every column a fact table carries is needed, or that dropping a foreign key always invalidates the model.
In this PL-300 model-size scenario, deleting the ProductID column from the one-million-row Sales table removes roughly a million string/integer values plus its relationship, materially shrinking Model1. Because the required analysis only needs total sales by salesperson per city, the solution satisfies the stated goal.
Choosing "No" (option B) because ProductID participates in a relationship with the Product dimension, believing the model would break; learners overlook that the stated analysis path (Salesperson → City) never traverses the product dimension.
Community Discussion (1 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
The Sales table holds one million rows, so each column it carries is replicated a million times—dropping ProductID eliminates the largest remaining per-row cost and also removes the Product relationship metadata, directly reducing the size of Model1. The only stated requirement is analyzing the total number of sales by salesperson per city, and that aggregation flows through the SalesPerson and City attributes (or their keys), which are untouched. Nothing in the goal mentions products, product categories, or product-level slicing, so no product attribute is needed at the reporting layer. Therefore the solution meets the goal and the answer is A.Why the Other Options Are Wrong
Option B (No) would be correct only if the required analysis depended on the product dimension—for example, if the goal were "total sales by salesperson per city per product." It does not. Selecting B also reflects a common misconception: that a fact table must keep every foreign key it was loaded with. A well-designed star schema keeps a fact table narrow and stores only the keys needed for the relationships actually used for reporting. Removing ProductID does not corrupt the remaining SalesPerson and City relationships, so measures such as Sales Count or Sales Amount still compute correctly per person and per city.Community Comment Notes
Only one comment was posted, from rocketmery, who argued for A: "Remove ProductID does not affect the ability to analyze the total number of sales by salesperson per city." That reasoning matches the analysis here—the dropped column is not on the required analysis path, so the size-reduction goal is met. No dissenting comment offered a scenario in which the product dimension would be needed for this requirement.Official Reference
Exam Strategy
Read the goal clause first and list exactly which columns/relationships the required analysis uses, then treat every other fact-table column as a legitimate deletion candidate for model-size questions. Watch for these paired "Does this meet the goal?" items—each alternative solution usually hinges on whether a different column or relationship sits on that required analysis path.
Frequently Asked Questions
Does deleting ProductID from Sales break the relationship to the Product table?
Yes, that relationship disappears, but the required analysis only uses salesperson and city, so the model still meets the stated goal. Re-add a product key only if product-level reporting is needed.
Why does deleting one column noticeably reduce Model1's size?
A column in the Sales fact table is stored once per row, so with one million rows the ProductID values (and their relationship) add up quickly. Narrow fact tables are the primary way to compress a semantic model.
Related Analysis
Practice All PL-300 Questions
Access 116 questions with complete answers and detailed explanations.
View Full PL-300 Practice Test →