Module 07 Activity
Scenario
Two questions that summarising alone cannot answer: "how did revenue accumulate through the month?" and "what share of revenue does each country represent?" Both need per-row detail kept alongside the totals.
Task
- Produce daily completed revenue, one row per day.
- Add a running total that accumulates across days in date order.
- Confirm the final running-total value equals the overall completed revenue. If it does not, your
ordering or your frame is wrong.
- Separately, produce revenue by country with a share of total column, computed inside the query
rather than by dividing by a number you pasted in.
- Confirm the shares sum to 100%.
Deliverable
Two small tables: a daily accumulation table (date | daily | running total) and a country share table (country | revenue | % of total), each with the check that proves it closes.
Check your work
The first three days:
| Date | Daily | Running total |
|---|---|---|
| 2026-06-01 | ₹99,801 | ₹99,801 |
| 2026-06-02 | ₹96,522 | ₹1,96,323 |
| 2026-06-03 | ₹97,743 | ₹2,94,066 |
Each running-total value is the sum of every daily value up to and including that row. The final row, on 30 June, must reach ₹26,85,905 - the completed revenue total. That single check confirms your window covered every row exactly once.
Country shares:
| Country | Revenue | Share |
|---|---|---|
| IN | ₹18,20,744 | 67.8% |
| GB | ₹5,11,887 | 19.1% |
| SG | ₹1,88,437 | 7.0% |
| Not recorded | ₹1,64,837 | 6.1% |
Those sum to 100.0%. Computing the denominator with a window function rather than typing 2685905 into the query is what keeps this correct when the data changes tomorrow.
The trap
If you compute the share by dividing by a hardcoded total, the query silently becomes wrong the moment a new order arrives - and it will keep producing plausible percentages that no longer sum to 100. Let the query find its own denominator, then assert that the shares close.
