From a8a122bdfa05d91bef4aedc4ea1b90539b61123f Mon Sep 17 00:00:00 2001 From: Dmitry Dementev Date: Sat, 15 Nov 2025 17:57:35 +0300 Subject: [PATCH] =?UTF-8?q?=D0=9F=D0=B5=D1=80=D0=B5=D0=B4=D0=B5=D0=BB?= =?UTF-8?q?=D0=BA=D0=B0=20=D1=80=D0=B0=D0=B7=D0=B4=D0=B5=D0=BB=D0=B0=20?= =?UTF-8?q?=D1=81=D0=BE=D0=B2=D0=B5=D1=82=D0=BE=D0=B2=20=D0=B4=D0=BB=D1=8F?= =?UTF-8?q?=20=D1=81=D0=BE=D0=BC=D0=BD=D0=B5=D0=B2=D0=B0=D1=8E=D1=89=D0=B8?= =?UTF-8?q?=D1=85=D1=81=D1=8F?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- dwh-modeling/README.md | 33 ++++++++++++++++++++++++++++----- 1 file changed, 28 insertions(+), 5 deletions(-) diff --git a/dwh-modeling/README.md b/dwh-modeling/README.md index 62226d3..be94b36 100644 --- a/dwh-modeling/README.md +++ b/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+ источниками и жёстких требованиях к аудиту. + --- -### 💡 И ещё один совет от практиков: +#### 💡 И ещё один совет от практиков: > **Лучше сделать простую модель — и вовремя переделать,** > чем сделать «идеальную» — и застрять на этапе проектирования.