From 9d8696f7486f87bc2c01efbcd393bfb50041779e Mon Sep 17 00:00:00 2001
From: Dmitry Dementev <me@dementev.space>
Date: Sun, 12 Jul 2026 19:11:49 +0300
Subject: [PATCH] =?UTF-8?q?docs(modeling):=20=D0=B8=D1=81=D0=BF=D1=80?=
 =?UTF-8?q?=D0=B0=D0=B2=D0=BB=D0=B5=D0=BD=D1=8B=20=D1=81=D1=81=D1=8B=D0=BB?=
 =?UTF-8?q?=D0=BA=D0=B8=20=D0=BD=D0=B0=20=D0=BF=D0=B0=D0=BF=D0=BA=D0=B8=20?=
 =?UTF-8?q?=D0=B8=20markdown=20=D0=B4=D0=BB=D1=8F=20=D1=81=D0=B0=D0=B9?=
 =?UTF-8?q?=D1=82=D0=B0?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

- Зачем:
  - относительные ссылки на каталоги sql/ и data/ давали 404 на GitHub Pages;
  - em-dash в заголовках нарушает правило AGENTS.md (расходятся слаги GitHub/MkDocs);
  - 2-пробельная вложенность и списки без пустой строки ломали рендер в MkDocs
- Что:
  - ссылки на папки заменены на GitHub-tree-ссылки (работают на обеих платформах);
  - в 26 заголовках « — » заменено на «: » или убрано (README, SCD, DataVault, домашка);
  - пустая строка перед списком «Главные правила» в DataVault;
  - вложенные списки DataVault переведены на 4-пробельный отступ
- Проверка:
  - mkdocs build --strict (без ошибок);
  - grep по репо — якорных ссылок на старые слаги заголовков нет;
  - grep по site/dwh-modeling/*.html — списки рендерятся <ul>/<li>, вложенность сохранена

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---
 dwh-modeling/DataVault.md                     | 25 ++++++++++---------
 .../Homework_Customer_Status_DDS_DM.md        |  8 +++---
 dwh-modeling/README.md                        | 24 +++++++++---------
 dwh-modeling/SCD.md                           | 14 +++++------
 4 files changed, 36 insertions(+), 35 deletions(-)

diff --git a/dwh-modeling/DataVault.md b/dwh-modeling/DataVault.md
index f40ceb4..c3ace60 100644
--- a/dwh-modeling/DataVault.md
+++ b/dwh-modeling/DataVault.md
@@ -126,17 +126,18 @@ erDiagram
 
 Чуть менее «сказочно», чуть более технично.
 
-### 3.1. Hub — сущность и её бизнес-ключ
+### 3.1. Hub: сущность и её бизнес-ключ
 
 **Hub** содержит:
 
 * бизнес‑ключ (customer_bk, order_id, contract_number);
 * техническую информацию:
-  * record_source — из какой системы пришла первая запись;
-  * load_dttm — когда запись попала в DV;
-  * иногда — хэш бизнес‑ключа (hk_customer).
+    * record_source — из какой системы пришла первая запись;
+    * load_dttm — когда запись попала в DV;
+    * иногда — хэш бизнес‑ключа (hk_customer).
 
 Главные правила:
+
 * один бизнес‑ключ — один хаб (одна строка на сущность, без истории);
 * хаб не знает про атрибуты (имя, email) — только идентичность.
 
@@ -153,7 +154,7 @@ CREATE TABLE hub_customer (
 
 Конкретные типы данных (`BYTEA`, длины `VARCHAR`, детали `hashdiff`) и реализации хэш‑ключей можно не запоминать: на старте важнее понять саму идею — у сущностей есть стабильные ключи, а все изменения атрибутов мы записываем отдельными версиями в сателлитах.
 
-### 3.2. Link — связи между сущностями
+### 3.2. Link: связи между сущностями
 
 **Link** описывает факт связи, например:
 
@@ -178,7 +179,7 @@ CREATE TABLE link_order_customer (
 );
 ```
 
-### 3.3. Satellite — атрибуты и история
+### 3.3. Satellite: атрибуты и история
 
 **Satellite** хранит:
 
@@ -249,7 +250,7 @@ Star Schema]
 * **Raw Vault** — это про приём и хранение данных «как есть», но уже в форме Hub / Link / Satellite.
 * **Business Vault** — это про приведение этих данных в более «деловой» вид: с бизнес-правилами, PIT/Bridge и подготовленными представлениями.
 
-### 5.1. Raw Vault — «всё прилетевшее, аккуратно разложенное по ящичкам»
+### 5.1. Raw Vault: «всё прилетевшее, аккуратно разложенное по ящичкам»
 
 Raw DV — первый слой поверх STG / ODS:
 
@@ -261,20 +262,20 @@ Raw DV — первый слой поверх STG / ODS:
 
 * минимум бизнес-логики:
 
-  * никаких правил вроде «клиент активен, если была хотя бы одна покупка за 90 дней»;
+    * никаких правил вроде «клиент активен, если была хотя бы одна покупка за 90 дней»;
 * все источники показываются «как есть», только приведены к общим ключам;
 * структура стабильна: добавился новый источник → появился новый Satellite к тому же Hub.
 
-### 5.2. Business Vault — «там, где из Lego собирают модули»
+### 5.2. Business Vault: «там, где из Lego собирают модули»
 
 Business Vault (BV) — следующий слой над Raw DV:
 
 * здесь применяются бизнес-правила (что считать активным клиентом, как трактовать статусы);
 * здесь строятся вспомогательные структуры:
 
-  * PIT-таблицы,
-  * Bridge-таблицы,
-  * агрегаты и derived-таблицы.
+    * PIT-таблицы,
+    * Bridge-таблицы,
+    * агрегаты и derived-таблицы.
 
 Именно из BV чаще всего строятся витрины в формате Звезды, к которым подключаются BI и отчётность.
 
diff --git a/dwh-modeling/Homework_Customer_Status_DDS_DM.md b/dwh-modeling/Homework_Customer_Status_DDS_DM.md
index 2a8643c..8fdfdd5 100644
--- a/dwh-modeling/Homework_Customer_Status_DDS_DM.md
+++ b/dwh-modeling/Homework_Customer_Status_DDS_DM.md
@@ -71,7 +71,7 @@ customer_id,status,event_ts,_load_id,_load_ts
 
 ---
 
-## 3. Часть 1 — STG → ODS (обязательно)
+## 3. Часть 1: STG → ODS (обязательно)
 
 **Задача:** загрузить CSV в STG и переложить данные в ODS с приведением типов.
 
@@ -145,7 +145,7 @@ ORDER BY customer_id, event_ts;
 
 ---
 
-## 4. Часть 2 — ODS → DDS (SCD Type 2, обязательно)
+## 4. Часть 2: ODS → DDS (SCD Type 2, обязательно)
 
 **Задача:** по событиям в `ods.customer_status` построить измерение `dds.dim_customer_status`, где каждая строка — период действия статуса.
 
@@ -216,7 +216,7 @@ ORDER BY customer_bk, valid_from;
 
 ---
 
-## 5. Часть 3 — инкрементальная загрузка (по желанию)
+## 5. Часть 3: инкрементальная загрузка (по желанию)
 
 Если хочется потренироваться глубже:
 
@@ -241,7 +241,7 @@ cat dwh-modeling/data/customer_status_events_increment.csv | ./postgres-bookings
 
 ---
 
-## 6. Часть 4 — витрина в DM (по желанию)
+## 6. Часть 4: витрина в DM (по желанию)
 
 Опциональное задание для закрепления: собрать небольшую витрину с количеством клиентов по статусам на каждую дату.
 
diff --git a/dwh-modeling/README.md b/dwh-modeling/README.md
index 6e9c0c8..bc3fac8 100644
--- a/dwh-modeling/README.md
+++ b/dwh-modeling/README.md
@@ -145,7 +145,7 @@ flowchart TD
 
 Давайте проследим, как превращается строка заказа.
 
-### **STG (Staging / Bronze)** — «как пришло»
+### **STG (Staging / Bronze)**: «как пришло»
 
 - Таблицы: `stg.orders_raw`, `stg.customers_raw`;  
 - Структура — *точно как в источнике* (может быть `VARCHAR` даже у дат);  
@@ -158,7 +158,7 @@ flowchart TD
 
 ---
 
-### **ODS (Operational Data Store / Silver)** — «почистили, но не трогали смысл»
+### **ODS (Operational Data Store / Silver)**: «почистили, но не трогали смысл»
 
 - Таблицы: `ods.orders`, `ods.customers`;  
 - Здесь:  
@@ -174,7 +174,7 @@ flowchart TD
 
 ---
 
-### **DDS (Data Delivery Store / Core / Conformed)** — «интеграция + история»
+### **DDS (Data Delivery Store / Core / Conformed)**: «интеграция + история»
 
 Здесь рождается *единая бизнес-модель*.  
 Появляются понятия: **измерения**, **факты**, **суррогатные ключи**, **SCD**.
@@ -199,7 +199,7 @@ flowchart TD
 
 ---
 
-### **DM (Data Mart / Gold/ «Витрины»)** — «готово к употреблению»
+### **DM (Data Mart / Gold / «Витрины»)**: «готово к употреблению»
 
 Здесь — таблицы и представления для конкретных задач:  
 
@@ -266,7 +266,7 @@ erDiagram
     }
 ```
 
-### SCD Type 2 — как хранить историю
+### SCD Type 2: как хранить историю
 
 Клиент №101:  
 
@@ -418,7 +418,7 @@ WHERE c.city = 'Москва'
 
 ---
 
-### 3. Data Vault 2.0 — «конструктор Lego» для больших DWH
+### 3. Data Vault 2.0: «конструктор Lego» для больших DWH
 
 *Идея: Дэн Линстедт (Dan Linstedt). Цель — так организовать хранилище, чтобы можно было спокойно добавлять новые источники и хранить историю, не ломая старую модель.*
 
@@ -468,7 +468,7 @@ Anchor Modeling - ещё более атомарный подход к моде
 
 ---
 
-### Сравнение моделей — наглядно
+### Сравнение моделей наглядно
 
 ```mermaid
 quadrantChart
@@ -540,7 +540,7 @@ flowchart TD
 
 ### Готовые SQL-скрипты
 
-Все необходимые скрипты для построения хранилища находятся в папке [`sql/`](sql/):
+Все необходимые скрипты для построения хранилища находятся в папке [`sql/`](https://github.com/dementev-dev/de-roadmap/tree/main/dwh-modeling/sql):
 
 - [`01_ddl_stg-dds.sql`](sql/01_ddl_stg-dds.sql) — создание схем и таблиц (STG, ODS, DDS);
 - [`02_dml_stg-dds.sql`](sql/02_dml_stg-dds.sql) — первичная загрузка данных и демонстрация SCD2 через полный пересчёт (`full backfill`) из STG;
@@ -605,7 +605,7 @@ GROUP BY d.date_actual, p.product_name,
 
 ---
 
-### ✅ Базовые советы — с чего начать, если вы учитесь или делаете первый DWH
+### ✅ Базовые советы: с чего начать, если вы учитесь или делаете первый DWH
 
 1. **Начните с витрины в формате Звезды (Star Schema).**  
    — Это просто: одна таблица фактов + несколько «плоских» измерений.  
@@ -660,7 +660,7 @@ GROUP BY d.date_actual, p.product_name,
 
 ---
 
-### 📌 Кратко — что выбрать *сегодня*, если вы только учитесь
+### 📌 Кратко: что выбрать *сегодня*, если вы только учитесь
 
 | У вас… | Делайте… |
 |--------|----------|
@@ -791,7 +791,7 @@ SELECT 'OK' WHERE EXISTS (
 
 ### Мини-датасет (для практики)
 
-Все данные для практики находятся в папке [`data/`](data/) — тренируйтесь:
+Все данные для практики находятся в папке [`data/`](https://github.com/dementev-dev/de-roadmap/tree/main/dwh-modeling/data) — тренируйтесь:
 
 [`customers.csv`](data/customers.csv):
 ```csv
@@ -832,7 +832,7 @@ product_id,valid_from,valid_to,price
 9002,2023-01-01,,50
 ```
 
->  📂 Все SQL-скрипты для построения хранилища находятся в папке [`sql/`](sql/).
+>  📂 Все SQL-скрипты для построения хранилища находятся в папке [`sql/`](https://github.com/dementev-dev/de-roadmap/tree/main/dwh-modeling/sql).
 
 ---
 
diff --git a/dwh-modeling/SCD.md b/dwh-modeling/SCD.md
index 4daf7f5..42a324a 100644
--- a/dwh-modeling/SCD.md
+++ b/dwh-modeling/SCD.md
@@ -28,15 +28,15 @@ SCD — это подход к хранению изменений в измер
 
 ---
 
-## 3. Типы SCD — простыми словами
+## 3. Типы SCD простыми словами
 
 Существует несколько стандартных стратегий обработки изменений. Рассмотрим самые важные.
 
-### **Type 0 — Никогда не меняется**
+### **Type 0: никогда не меняется**
 Атрибут фиксирован навсегда. Например, дата рождения клиента.  
 Такие поля не требуют специальной обработки — они просто не обновляются.
 
-### **Type 1 — Просто перезаписать**
+### **Type 1: просто перезаписать**
 Вы просто делаете `UPDATE`, и старое значение исчезает.
 
 ✅ Просто.  
@@ -44,7 +44,7 @@ SCD — это подход к хранению изменений в измер
 
 > Подходит, если изменение — это исправление ошибки (например, опечатка в имени).
 
-### **Type 2 — Новая строка для новой версии**
+### **Type 2: новая строка для новой версии**
 Каждое изменение порождает **новую строку** в таблице. Старая строка остаётся, но помечается как «устаревшая».
 
 ✅ Полная история.  
@@ -53,7 +53,7 @@ SCD — это подход к хранению изменений в измер
 
 > Это **самый распространённый** подход в аналитике.
 
-### **Type 3 — Добавить колонку «предыдущее значение»**
+### **Type 3: добавить колонку «предыдущее значение»**
 В таблице появляются поля вроде `previous_category`, `category_change_date`.
 
 ✅ Простая история «до/после».  
@@ -61,7 +61,7 @@ SCD — это подход к хранению изменений в измер
 
 > Используется редко, чаще как компромисс в очень простых системах.
 
-### **Type 4, 5, 6 — Продвинутые гибриды**
+### **Type 4, 5, 6: продвинутые гибриды**
 Эти типы существуют, но **встречаются редко** и почти не используются новичками:
 
 - **Type 4**: история выносится в отдельную таблицу («мини-хранилище» для одного измерения).
@@ -99,7 +99,7 @@ WHERE customer_id = 1;
 
 ---
 
-### Type 2: сохраняем историю — подробнее
+### Type 2: сохраняем историю (подробнее)
 
 Чтобы хранить историю, мы меняем структуру таблицы. Вот ключевые поля: