# Chapter 7 Solution Guide: Dimensional Sales Mart and SCD2 History

The reference solution builds a warehouse-style mart with `dim_date`, `dim_product`, `dim_customer`, and `fact_sales`. The fact table uses **one row per validated order line** as its grain. This grain is specific enough to support order, date, customer, product, and channel analysis without double counting.

The most important modeling decision is the customer surrogate key. Customer `C-1002` appears twice in `dim_customer`: first as a Samarkand customer from `2026-05-01` until `2026-05-30`, and then as a current Tashkent customer from `2026-05-30` onward. The `fact_sales` loader joins each order line to the customer version that was valid on the order date. Therefore, the `2026-05-29` sale joins to Samarkand, while the `2026-05-30` sale joins to Tashkent.

| Table | Expected rows | Validation purpose |
|---|---:|---|
| `dim_date` | 3 | One row for each order date in the source data. |
| `dim_product` | 4 | One row for each current product. |
| `dim_customer` | 5 | One row for each customer version, including two versions for `C-1002`. |
| `fact_sales` | 6 | One row for each validated order line. |

The final daily report contains three dates. The total net revenue is `575.50`, with `203.50` on `2026-05-28`, `192.00` on `2026-05-29`, and `180.00` on `2026-05-30`.

This lab intentionally keeps the warehouse physical design simple. In a production system, the same mart could be loaded into Snowflake, BigQuery, Redshift, MaxCompute, or a lakehouse table. The decision should be based on query latency, concurrency, governance, update frequency, and the need for multi-engine access rather than on technology fashion.