Challenge 3: A Duplicate Key Silently Inflating Totals — Solution Walkthrough

What visibly goes wrong in the PivotTable:

Sales rows for the duplicated ProductID get matched against BOTH
copies of that product in Products, effectively duplicating those
specific sales rows within the relationship's join. Any measure or
value summarizing Sales for that product — a Total Sales figure, a
Count of Sales rows — comes out too HIGH, roughly double what it
should be for that one product specifically, while every other,
non-duplicated product's figures remain correct. This is a
particularly dangerous kind of bug precisely because it's silent and
PARTIAL — nothing errors out, the PivotTable looks completely normal,
and only the one affected product's numbers are actually wrong, which
makes it easy to miss during a normal review of the results.

The step from an earlier chapter that would have caught this first:

Before building the relationship at all, applying Excel Fundamentals
Chapter 7's Excel Table conversion plus a quick check, or more
directly, Excel Advanced Chapter 4's Power Query "Remove Duplicates"
step run on the Products query (specifically checking for duplicate
ProductID values before that data ever reaches the Data Model) would
catch and remove the duplicate row at the cleaning stage, before it
could ever corrupt a relationship. A simple PivotTable built from
Products alone, with ProductID in Rows and a Count of ProductID in
Values, would also immediately reveal any ProductID with a count
greater than 1 — a direct, cheap sanity check worth running on any
table intended to be the "one" side of a relationship.

Notes:
- This is exactly the scenario this chapter's own warning box
  describes: relationship problems caused by a non-unique "one" side
  don't necessarily prevent the relationship from being created at
  all — they can instead surface later as a silently inflated total,
  which is precisely why checking uniqueness BEFORE building the
  relationship is the safer habit.