SQL, warehouses and AI

You do not run any of these - you need to know what each does so you can place a problem. A wrong number in a dashboard could be a bad source, a broken pipeline into the warehouse, a metric defined differently in the SQL layer, or just a filter set wrong on the tile. Knowing the four layers lets you point at the right one instead of blaming "the data".

• Sources: where data is born - your product, Stripe, ad platforms. Garbage here is garbage everywhere downstream.
• Warehouse: the single queryable store. The whole point is that everything lands in one place SQL can reach.
• SQL + semantic layer: where raw rows become "revenue" and "active customer" - the definitions the whole company should share.
• BI dashboards: the display. Every tile is a saved SQL query underneath, as you saw in session a4.

Before cloud warehouses, data lived in a dozen disconnected systems and answering a cross-team question meant a project. The modern warehouse put everything in one place that SQL can query at speed, which is why the whole stack rearranged around it. It is also why SQL, a 50-year-old language, is more central than ever: the warehouse speaks SQL, so SQL is how you get anything out. Every layer above the warehouse - semantic layers, BI tools, AI copilots - ultimately emits SQL for the warehouse to run.

• One store, one language: consolidation is what made self-serve analytics possible at all.
• Separation of storage and compute: the cloud-warehouse trick that made querying huge data affordable.
• SQL as the universal interface: whatever tool sits on top, the warehouse still runs SQL underneath.

Below is the kind of query an AI copilot might generate for "top 5 customers by revenue". You do not have to write it - you have to read it and answer one question: did it remember to exclude refunds? Read the WHERE line. It says status = 'completed' - so refunded and cancelled orders are left out, which is what "revenue" should mean. Run it to see the ranked list. The copilot got this one right; your job was to check, and now you can say so with confidence.

SELECT c.name, ROUND(SUM(oi.quantity*oi.unit_price),2) AS spend
FROM customers c
JOIN orders o ON c.customer_id = o.customer_id
JOIN order_items oi ON o.order_id = oi.order_id
WHERE o.status = 'completed'
GROUP BY c.customer_id
ORDER BY spend DESC
LIMIT 5;

A copilot writes fluent SQL that runs cleanly and returns a plausible number - and can still answer the wrong question. It does not know your business meant "completed revenue" unless the definition is written down somewhere it can read. When a board asks "how did we get this number?", "the AI wrote it" is not a defensible answer; "it sums completed order revenue, refunds excluded, and here is the query" is. The skill this whole track built - reading a query and questioning a metric - is precisely the skill that lets you stand behind an AI-generated number, or catch it before it costs you.

• Fluent is not correct: a query that runs is not a query that is right for your definition.
• The AI inherits your ambiguity: if "active" was never defined, the copilot invents one - and may not tell you.
• Verification is the human's job: the faster machines write SQL, the more valuable the person who can read it becomes.

A semantic layer is where "revenue" is defined once, in one place, and every tool - the dashboard, the copilot, the analyst's ad-hoc query - is required to use that definition. It is the technical form of the discipline you learned in session 5: pin the metric so two people get the same number, then enforce it so a thousand queries get the same number too. Without it, AI copilots multiply your definitions; with it, they safely reuse the one you certified. When you ask your data team what to build next, this is often the answer that pays back for years.

• Define once, reuse everywhere: the copilot pulls the certified "revenue", not its own guess.
• Trust becomes the default: when every tool reports the same number, arguments about whose figure is right disappear.
• It scales AI safely: governed definitions are what let you say yes to text-to-SQL without chaos.