docs(modeling): пояснена разница между снимковым и событийным ODS

- Зачем:
  - менти видит два разных паттерна ODS (снимок vs event log) и не понимает почему
- Что:
  - в решении домашки (блок 1 ODS): комментарий, почему customer_status хранит все события
  - в домашке (раздел 3.2): пометка о сознательном выборе модели ODS
- Проверка:
  - визуальная проверка diff

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

dwh-modeling/Homework_Customer_Status_DDS_DM.md

@@ -122,6 +122,8 @@ SELECT * FROM stg.customer_status_raw LIMIT 10;
 
 ### 3.2. ODS: очистка и типизация
 
+> 💡 Обратите внимание: в основном примере `ods.customers` хранит **снимок** (одна строка на клиента, PK = `customer_id`), а здесь `ods.customer_status` хранит **все события** (PK = `customer_id + event_ts`). Это не ошибка, а сознательный выбор: источник данных о статусах - поток событий, и ODS сохраняет эту природу. Подробнее - в комментариях к решению.
+
 В файле `08_dml_hw_customer_status_template.sql` найдите заготовку блока ODS и допишите SQL:
 
 - привести:

dwh-modeling/sql/09_dml_hw_customer_status_solution.sql

@@ -36,6 +36,13 @@
 --   - STG хранит "как пришло" (обычно TEXT);
 --   - ODS хранит "аккуратно": правильные типы + простая чистка.
 -- Для простоты пересобираем ODS с нуля.
+--
+-- Обратите внимание: ods.customer_status хранит ВСЕ события (PK = customer_id + event_ts),
+-- а не только последнее состояние, как ods.customers (PK = customer_id).
+-- Причина: источник данных здесь - поток событий ("статус стал X в момент Y"),
+-- а не снимок ("вот текущие данные клиента"). ODS сохраняет природу источника:
+-- снимок остаётся снимком, события остаются событиями.
+-- Благодаря этому full backfill SCD2 (блок 2) строится прямо из ODS, а не из STG.
 
 TRUNCATE ods.customer_status;