Переделка раздела советов для сомневающихся

dwh-modeling/README.md

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