The Shape of a Dataset

The one idea: Before you compute anything, know what a single row actually represents — one order, one customer, or one product within an order. Every number you produce is a claim about which rows survived your filters and joins. Get the meaning of a row wrong, and every total downstream is wrong too.

⚠️ The trap: "It's called the orders table, so obviously one row is one order — I'll just sum the revenue." That feels right and it's wrong. A table's name describes intent, not reality; run COUNT(*) against COUNT(DISTINCT order_id) before you trust the grain, because if each order secretly appears three times, every total you sum is inflated threefold.

Before you compute a single metric, before you write a line of SQL or ask an AI to "analyze this," there is one question that determines whether anything downstream will be true: what does one row mean? This is called the grain of a dataset, and it is the most consequential fact about any table you will ever touch. A table of orders where one row = one order gives different answers than a table where one row = one line item within an order — from the same underlying business activity.

Analysts who skip this question produce numbers that are internally consistent and externally wrong. They count "customers" from a table where customers appear once per purchase. They sum "revenue" from a table where each order appears three times. The queries run. The charts render. The numbers are wrong, and nobody notices until someone in finance does.

This lesson gives you the habits that prevent that: interrogating grain, checking key uniqueness, recognizing long vs…