Karim is presenting 2025 results to the board next week. His request is short and serious: “Before these numbers go on a slide, how sure are we about the data?” Every query you’ve written assumes the data means what the documentation says. This lesson is about checking that assumption systematically, so that “I’m confident” is backed by queries, not feelings.
\nThe most useful habit in data quality is to phrase each rule as a query that returns the rows breaking it. An empty result means the rule holds; anything else is evidence you can show someone. Here’s the rule “a product sits in a sub-category, never directly in a top-level one”, from the data documentation:
\nSELECT p.product_id, p.name, c.name AS category\nFROM products AS p\nJOIN categories AS c ON c.category_id = p.category_id\nWHERE c.parent_id IS NULL;Two rows: the Picnic Blanket filed directly under Outdoor and the Bamboo Cutting Board under Kitchen. That explains the odd “Kitchen” and “Outdoor” rows in the category revenue table from Section 2. A check that returns rows you can name is far more persuasive than a count.
\nMost rules fall into five families. Running at least one check from each catches the large majority of problems:
\n| Family | \nQuestion | \nCartwheel example | \n
|---|---|---|
| Uniqueness | \nIs the key really unique? | \nDuplicate emails, ignoring case | \n
| Completeness | \nAre values present where they must be? | \nTickets with no agent_id | \n
| Validity | \nAre values in their allowed range? | \nDiscount between 0 and 0.25 | \n
| Referential integrity | \nDoes every reference point to a real row? | \nOrder items whose order doesn’t exist | \n
| Consistency | \nDo related columns and tables tell the same story? | \nOrders marked ‘returned’ with no return record; open tickets that already have a rating | \n
Database constraints (PRIMARY KEY, NOT NULL, CHECK, FOREIGN KEY) enforce some of these at write time, if they were declared and, in SQLite’s case, if foreign-key enforcement was switched on. Analysts rarely control that, and consistency rules across tables usually can’t be expressed as constraints at all. So you check.
One check is a query; a dozen checks are a suite. Give each a name, count its failures, and stack them with UNION ALL:
SELECT 'customers: duplicate email (any case)' AS check_name, COUNT(*) AS failures\nFROM (SELECT LOWER(email) FROM customers GROUP BY LOWER(email) HAVING COUNT(*) > 1)\nUNION ALL\nSELECT 'order_items: no matching order', COUNT(*)\nFROM order_items AS oi\nWHERE NOT EXISTS (SELECT 1 FROM orders AS o WHERE o.order_id = oi.order_id)\nUNION ALL\nSELECT 'order_items: discount outside 0-0.25', COUNT(*)\nFROM order_items\nWHERE discount NOT BETWEEN 0 AND 0.25\nUNION ALL\nSELECT 'products: filed under a top-level category', COUNT(*)\nFROM products AS p\nJOIN categories AS c ON c.category_id = p.category_id\nWHERE c.parent_id IS NULL\nUNION ALL\nSELECT 'orders: returned but no return record', COUNT(*)\nFROM orders AS o\nWHERE o.status = 'returned'\n AND NOT EXISTS (\n SELECT 1 FROM order_items AS oi\n JOIN returns AS r ON r.order_item_id = oi.order_item_id\n WHERE oi.order_id = o.order_id)\nUNION ALL\nSELECT 'tickets: rated while still open', COUNT(*)\nFROM support_tickets\nWHERE closed_at IS NULL AND satisfaction IS NOT NULL;Three checks fail. Each compound part must return the same number of columns; the first SELECT names them. UNION ALL keeps every row, whereas UNION would deduplicate, which costs time and could merge two checks that happen to share a name and count. Save the suite next to your analysis and run it every time the data is refreshed; a check that passed in October can fail in December.
Now read the failures like an analyst, not a linter:
\nThere’s one more failure hiding in this data, and it’s the most interesting one: products that appear in orders before their recorded launch date. Finding it is your exercise.
\n\nNext you’ll look at the other side of trust, performance: why some of these queries are instant and others crawl, and how to see what the database is actually doing.
\n","toc":[{"id":"sec-1","text":"A check is a query that returns the bad rows","level":2},{"id":"sec-2","text":"The five families of checks","level":2},{"id":"sec-3","text":"A suite you can rerun","level":2},{"id":"sec-4","text":"Failures are questions, not verdicts","level":2}],"takeaways":["Phrase every data-quality check as a query that returns the rows breaking a rule, so zero rows means the check passes.","Cover uniqueness, completeness, valid ranges, referential integrity and cross-table consistency; each catches a different kind of problem.","Bundle checks into one UNION ALL query with a name and a failure count per check, and run it before any important analysis.","A failing check is a question to take to the data’s owner, not something to filter away silently; record what you found and what you decided."],"further":[{"title":"SQLite compound SELECT statements (UNION ALL)","url":"https://www.sqlite.org/lang_select.html#compound_select_statements"},{"title":"SQLite CREATE TABLE constraints","url":"https://www.sqlite.org/lang_createtable.html#constraints"},{"title":"PostgreSQL constraints","url":"https://www.postgresql.org/docs/current/ddl-constraints.html"}],"quiz":[{"q":"Which query is the best data-quality check for “every order item belongs to an existing order”?
","options":[{"text":"SELECT COUNT(*) FROM order_items JOIN orders USING (order_id)","why":"An inner join silently drops orphans, so the count looks fine whether or not orphans exist."},{"text":"SELECT * FROM order_items oi WHERE NOT EXISTS (SELECT 1 FROM orders o WHERE o.order_id = oi.order_id)","why":"Correct. It returns exactly the rows that break the rule, so an empty result means the check passes and any row is evidence."},{"text":"SELECT COUNT(DISTINCT order_id) FROM order_items","why":"This counts orders referenced by items but can’t tell whether those orders exist."},{"text":"SELECT * FROM orders WHERE order_id IS NOT NULL","why":"This checks the wrong table and the wrong rule; primary keys are never NULL anyway."}],"answer":1},{"q":"Two orders have status ‘returned’ but no row in returns. Both were placed in the last two weeks of December 2025. What’s the most sensible next step?
Why use UNION ALL rather than UNION to combine check results into one suite?
Three discontinued products (is_active = 0) still have orders in December 2025. What kind of problem is this?
is_active flag holds a valid 0 or 1; the value itself is not out of range."},{"text":"A consistency question between tables, which may be a data error or a legitimate business case such as clearing stock.","why":"Correct. The flag and the sales disagree. Whether that’s wrong depends on what “discontinued” means at Cartwheel, which is a question for the product team."}],"answer":3}],"exercise":{"kind":"sql","starter":"-- Data-quality check: products sold before their launch date\n-- Write it from scratch. One row per offending product with:\n-- product_id, name, launched_on, first_sold (YYYY-MM-DD), lines\nSELECT product_id, name, launched_on\nFROM products;","solution":"SELECT\n p.product_id,\n p.name,\n p.launched_on,\n date(MIN(o.order_date)) AS first_sold,\n COUNT(*) AS lines\nFROM order_items AS oi\nJOIN orders AS o ON o.order_id = oi.order_id\nJOIN products AS p ON p.product_id = oi.product_id\nWHERE o.order_date < p.launched_on\nGROUP BY p.product_id, p.name, p.launched_on;","orderMatters":false,"title":"Sold before launch","prompt":"Write this check from scratch. Rule: a product can’t be ordered before its launched_on date.
Return one row per product that breaks the rule, with product_id, name, launched_on, first_sold (the date of its earliest order, as ‘YYYY-MM-DD’) and lines (how many order lines were placed before the launch date). Only count lines from before launch. Row order doesn’t matter.
order_items (the lines), orders (the date) and products (the launch date).","The rule-breaking condition compares two columns from different tables: o.order_date < p.launched_on. ISO text compares correctly.","Group by the product columns, then use date(MIN(o.order_date)) and COUNT(*)."],"explanation":"Joining lines to their orders and products puts the order date and the launch date on the same row, so the rule becomes a WHERE condition. Grouping by product turns 149 offending lines into 8 products. Some gaps are huge: the Adjustable Dumbbells were selling from February 2024 but ‘launched’ in May 2025. That pattern suggests launched_on records something else, perhaps a relaunch or a catalogue import date, rather than true first availability. Take that question to the product team before using launched_on in any ‘new product’ analysis.