Module 13 Summary
What you have built
A small analysis-ready dataset, eight questions answered from it, every reported figure reconciled, and a memo a sceptical reader can check without asking you a single thing. That last property is the whole point.
What the capstone proved you can do
- Fix population, grain, and measure before writing any SQL
- Assemble a dataset in stages, checking the grain after every join
- Reconcile figures against independent sources rather than re-running the same query
- State limitations plainly, including the ones that make your analysis less impressive
The figures your submission had to land
1,000 orders - 988 completed - booked ₹27,01,463 - completed ₹26,85,905 - average completed order ₹2,718.53 - 3,812 customers who never ordered - 3,400 items sold - payments minus revenue owed ₹0.00 - country coverage 93.8%.
The three limitations every honest version states
300 customers have no recorded country. 12 orders remain pending, worth ₹15,558. And line-item values do not reconcile to order totals for 999 of 1,000 orders - so basket-level revenue analysis is not supported by this data at all.
An analysis that reports none of these looks stronger and is worth less.
What actually transfers
The SQL syntax in this course is available in any reference. What is not is the habit underneath it: state the grain, check the row count after every join, report the denominator, use half-open date ranges, normalise in one place, verify against something independent, and write the limitation down.
That habit is what makes a number something a colleague can act on rather than something they have to take on faith. Take it to the next database you are handed, and start by asking what one row means.