Пересобран раздел 8

dwh-modeling/README.md

@@ -607,79 +607,77 @@ GROUP BY d.date_actual, p.product_name, c.customer_segment;
 
 ---
 
-### 🛑 Что делать **не стоит** (если опыта еще мало):
+### 🛑 Что делать **не стоит** (если опыта ещё мало):
 
 | Что делать не стоит | Почему |
 |---------------------|--------|
-| **Брать Data Vault «потому что модно»** | DV требует глубокого понимания интеграции, CDC, идемпотентности. Без этого — получите «историю», где невозможно найти актуальные данные. |
+| **Брать Data Vault «потому что модно»** | DV требует глубокого понимания интеграции, CDC, идемпотентности. Без этого легко получить «историю», в которой невозможно найти актуальные данные. |
-| **Строить сложную 3NF «как в книжках» под 10 таблиц** | Если у вас 2 источника — вы потратите 2 недели на нормализацию, чтобы потом делать 5 JOIN’ов ради простого отчёта. |
+| **Строить сложную 3NF «как в книжках» под 10 таблиц** | Если у вас 2–3 источника — вы потратите недели на нормализацию, чтобы потом делать 5 JOIN’ов ради простого отчёта. |
 | **Пытаться «сделать сразу гибко на 5 лет вперёд»** | Гибкость = сложность. А сложность = баги, задержки, выгорание команды. |
 
 ---
 
-### ✅ **Базовые советы — с чего начать, если вы учитесь или делаете первый DWH**
+### ✅ Базовые советы — с чего начать, если вы учитесь или делаете первый DWH
 
-#### **Начните с витрины в формате Звезды (Star Schema).**  
+1. **Начните с витрины в формате Звезды (Star Schema).**  
-   — Это просто: одна таблица фактов + несколько «плоских» справочников.  
+   — Это просто: одна таблица фактов + несколько «плоских» измерений.  
    — Это быстро: отчёт в BI — за 10 минут.  
    — Это понятно: даже менеджер поймёт структуру.
 
-#### **Стройте DDS только когда это *действительно нужно*.**  
+2. **Стройте DDS только когда это *действительно нужно*.**  
-   — Если источников ≤ 3 и они стабильны — можно `ods → dm` напрямую.  
+   — Если источников ≤ 3 и они стабильны — можно идти `ods → dm` напрямую.  
-   — Если появятся расхождения («email в CRM и в заказах — разные»), *тогда* заводите `dds.dim_customer`.
+   — Если появляются расхождения («email в CRM и в заказах — разные») — тогда заводите `dds.dim_customer` и другие общие сущности.
 
-#### **Историю (SCD) включайте *постепенно*.**  
+3. **Историю (SCD) включайте *постепенно*.**  
    — Сначала — без истории (Type 1: просто обновляете строку).  
-   — Потом — только для ключевых сущностей (клиент, товар).  
+   — Потом — только для ключевых сущностей (клиент, товар, договор).  
-   — Только потом — думайте про DV или полную историзацию.
+   — Только потом — думайте про DV или полную историзацию всего.
 
-#### **Если сомневаетесь — спросите: «А кто будет этим пользоваться?»**  
+4. **Если сомневаетесь — спросите: «А кто будет этим пользоваться?»**  
-   — Аналитик в Metabase → Звезда.  
-   — BI-разработчик в Power BI → Звезда.  
-   — Инженер, который строит ML-фичи → 3NF или даже сырые ODS-таблицы.  
-   — Аудитор или регулятор → DV (но только если вы *готовы* к его сложности).
 
-#### **Если сомневаетесь — спросите: «А кто будет этим пользоваться?»**
+   Выбор модели начинается не с технологий, а с вопроса: **кто будет работать с результатом?**  
+   Это как выбрать инструмент в мастерской: для гвоздей — молоток, для саморезов — отвёртка.
 
-Выбор модели данных начинается не с технологий, а с вопроса: **кто будет работать с результатом?** Это как выбрать инструмент в мастерской: для гвоздей — молоток, для саморезов — отвертка.
+   Вот как это выглядит на практике:
 
-Вот как это выглядит на практике:
+   — **Аналитик в Metabase / Looker Studio** → **Звезда (Star Schema)**  
+   Почему: ему нужны готовые метрики без сложных JOIN’ов. Звезда даёт понятные таблицы: «продажи по дням и товарам» — без углубления в атомарные сущности.
 
-— **Аналитик в Metabase** → **Звезда**  
+   — **BI-разработчик в Power BI / Tableau** → **Звезда**  
-Почему: ему нужны готовые метрики без сложных JOIN'ов. Звезда даёт понятные таблицы: «продажи по дням и товарам» — без углубления в атомарные сущности.
+   Почему: все инструменты визуализации оптимизированы под star schema. Один факт + несколько измерений = быстрые отчёты и простою модель.
 
-— **BI-разработчик в Power BI** → **Звезда**  
+   — **Инженер ML (Data Scientist / ML-инженер)** → **3NF или сырые ODS-таблицы**  
-Почему: все инструменты визуализации оптимизированы под star schema. Один факт + несколько измерений = быстрые отчёты и простое обновление.
+   Почему: для фичей нужны атомарные события и детальные атрибуты. Машинное обучение ценит полноту и детализацию данных больше, чем удобство отчётов.
 
-— **Инженер ML** → **3NF или сырые ODS-таблицы**  
+   — **Юрист, финансовый контролёр, аудитор / регулятор** → **3NF с SCD Type 2, иногда + DV в ядре**  
-Почему: для построения фичей нужны атомарные события и детальные атрибуты. Машинное обучение ценит полноту данных больше, чем удобство отчётов.
+   Почему: им нужна доказуемая история изменений, но не инфраструктурная сложность DV на каждый чих.  
+   Обычно достаточно хранить аудит-историю по ключевым сущностям (клиенты, договоры, счета) в формате 3NF + SCD Type 2.  
+   **Data Vault имеет смысл только если** у вас 10+ разнородных источников и жёсткие требования по аудиту и трассировке.
 
-— **Юрист или финансовый контролёр** → **3NF с SCD Type 2**  
+💡 **Золотое правило:**  
-Почему: им нужна доказуемая история изменений, но не инфраструктурная сложность DV. Достаточно хранить аудит-логи по ключевым сущностям (клиенты, договоры) с указанием «кто, когда и что изменил».
+«**Собирай данные как DV (максимально детально), показывай как Звезду (максимально просто).**»  
 
-💡 **Золотое правило**:  
+На начальных этапах вам почти всегда хватит **SCD Type 2 в рамках 3NF/Звезды**.  
-«Собирай данные как DV (максимально детально), показывай как Звезду (максимально просто)».  
+**Data Vault** нужен тогда, когда основная боль — интеграция множества систем и аудит, а не «первый отчёт для маркетинга».
-
-На начальных этапах хватит SCD Type 2 в рамках 3NF/Звезды. Data Vault оправдан только при работе с 10+ источниками и жёстких требованиях к аудиту.
 
 ---
 
-#### 💡 И ещё один совет от практиков:
+### 💡 Ещё один совет от практиков
 
 > **Лучше сделать простую модель — и вовремя переделать,**  
 > чем сделать «идеальную» — и застрять на этапе проектирования.
 
-Переделать Звезду → Звезда с SCD Type 2 — легко.  
+Переделать Звезду → Звезду с SCD Type 2 — относительно легко.  
-Переделать «недоделанный DV» → что-то рабочее — в 10 раз сложнее.
+Переделать «недоделанный DV» → что-то рабочее — в разы сложнее.
 
 ---
 
-### 📌 Кратко — что выбрать *сегодня*, если вы только учитесь:
+### 📌 Кратко — что выбрать *сегодня*, если вы только учитесь
 
 | У вас… | Делайте… |
 |--------|----------|
 | Учебный проект, 1–2 CSV | `ods → dm` по модели **Звезда** (без DDS, без истории) |
-| Первый рабочий DWH, 3–5 источников | `stg → ods → dds (3NF/простая Звезда) → dm (Звезда)` |
+| Первый рабочий DWH, 3–5 источников | `stg → ods → dds (3NF или простая Звезда) → dm (Звезда)` |
 | Команда из 1 инженера + 1 аналитика | **Не трогайте DV и Anchor** — они «съедят» ваше время без отдачи |
 
 А когда наберётесь опыта — приходите в DV. Он того стоит. Но *не раньше времени*.