Why business questions break raw SQL

Imagine three people at a company answer the question "what was revenue last quarter?" by each writing their own SQL. One counts refunded orders, one forgets to subtract discounts, one joins in a way that double-counts multi-item orders. You now have three different revenue numbers and no way to know which is right. This is the everyday reality of analytics without a semantic layer.

The root problem: operational SQL tables store facts, not business meaning. "Revenue" isn't a column — it's a definition (units × price − discounts, refunds excluded) that lives in someone's head. Every query re-implements that definition, and every re-implementation is a chance to get it subtly wrong.

The same question, two reasonable SQL answers

-- Analyst A: revenue = everything ordered
SELECT SUM(quantity * unit_price) FROM order_items;

-- Analyst B: revenue = net of discounts, refunds excluded
SELECT SUM(oi.quantity * oi.unit_price - oi.discount)
FROM order_items oi
JOIN orders o ON o.order_id = oi.order_id
WHERE o.status = 'completed';

Both are "revenue." They differ by tens of thousands of dollars. Neither analyst is wrong about SQL — they disagree about the business definition. Multiply this by every metric (AOV, CAC, MRR, churn) and every dimension (by channel, by region, by month) and you get an organization that argues about numbers instead of acting on them.

The fix is not "write better SQL each time." It's to define each metric once, in one place, and make everyone — humans and AI — go through that definition. That single source of truth is the semantic layer, and building it is the first half of this course.