Data & Databases · Level 2
Getting the data
Mission briefing
Mission 6-B: An analytics dashboard you designed is showing wrong numbers — revenue figures that don't match finance's totals. The design is reading the data faithfully. The data it's being handed is wrong, and the reason is in how it's being fetched.
The dashboard runs a query to get its numbers — a precise request to the database for specific data. "Give me total revenue for June." If the query asks the wrong question, you get confident, wrong answers. The display is honest; the question was off.
Queries are written in SQL — the standard language for asking databases questions. This one joined the wrong tables. It pulled refunds in with sales because the connection between them was wired up incorrectly.
The wiring problem is about keys. Every row has a primary key — a unique ID, like a fingerprint for that record. A foreign key is how one table points to a row in another. The query matched on the wrong foreign key, so it stitched together rows that don't actually belong together.
So my dashboard is fine — it's faithfully displaying a flawed query. The fix is upstream in how the data's joined, not in my charts. Knowing that, I can describe the bug precisely instead of doubting my own design.
Your dashboard shows wrong revenue, but the design renders exactly what it's given. Where's the bug?