Practice — Medium · Solution

Part 1 — the silent card

With sales → stores deleted: the region slicer still filters the returns-side visuals (that relationship survives) — but the units-sold card and the category bar sit still at their unfiltered totals. The slicer renders, the click highlights, the page looks alive, and the sales numbers are silently answering a different question than the one on screen. No error at any point — the course's oldest theme, now inside the model. The repair is one drag, and the proof is the card moving again.

Part 2 — the table with no key

• The proposed relationship: stores.StoreID is unique (39 = 39); inventory.StoreID repeats heavily (5,700 rows, 38 distinct — the online store holds no inventory). So the dialog offers a healthy many-to-one, inventory → stores — the suggestion was actually right, once you know which side is which.
• The harder question: profile every inventory column — SnapshotMonth 30 distinct, StoreID 38, Category 5, UnitsOnHand heavily repeated. No single column is unique. Inventory's identity is the combination store × category × month: a compound grain. That is the signature of a fact table, and it can never be a "one" side.
• Correct wiring: inventory → stores (StoreID, *:1). Category is trickier — inventory's Category column matches products' Category values, but products.Category is not unique (240 rows, 5 categories), so no clean relationship exists to products. Reachable options: leave Category as inventory's own column (fine for now), or — the professional answer, coming in this course — a tiny Category dimension shared by both. Either way, units on hand by Region flows through stores and proves the wiring.

Part 3 — the multiplication, witnessed

With the forbidden many-to-many in place, the table visual's Quantity column no longer reconciles with the star's verified figures — sales quantities recompute through the returns-side filter paths and drift from the honest 60,508-per-Lighting world you verified. The exact wrongness depends on how the engine resolves the ambiguous paths, which is itself the lesson: you cannot predict it, and numbers you cannot predict are numbers you cannot defend. Delete the copy; keep the memory.

Reflection answers

• In a 50-visual report you find it the way you found it here: a known figure and a deliberate click. Keep one visual whose correct value you know cold (total units, total revenue) and click a slicer while watching it. A card that ignores a filter is a broken relationship announcing itself — but only to someone who knew what movement to expect. Prediction, again.
• "Every table needs an ID column" is a habit from transactional databases, not a modeling law. Facts are identified by their grain — sometimes a compound of several columns — and adding a surrogate ID to inventory would change nothing about how it relates. Dimensions need keys; facts need grains.