docs(modeling): исправлены ссылки на папки и markdown для сайта

- Зачем: - относительные ссылки на каталоги 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>
2026-07-12 19:11:49 +03:00
parent a4fa66c466
commit 9d8696f748
4 changed files with 36 additions and 35 deletions
@@ -126,7 +126,7 @@ erDiagram

 Чуть менее «сказочно», чуть более технично.

-### 3.1. Hub — сущность и её бизнес-ключ
+### 3.1. Hub: сущность и её бизнес-ключ

 **Hub** содержит:

@@ -137,6 +137,7 @@ erDiagram
    * иногда — хэш бизнес‑ключа (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:

@@ -265,7 +266,7 @@ Raw DV — первый слой поверх STG / ODS:
 * все источники показываются «как есть», только приведены к общим ключам;
 * структура стабильна: добавился новый источник → появился новый Satellite к тому же Hub.

-### 5.2. Business Vault — «там, где из Lego собирают модули»
+### 5.2. Business Vault: «там, где из Lego собирают модули»

 Business Vault (BV) — следующий слой над Raw DV:

@@ -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 (по желанию)

 Опциональное задание для закрепления: собрать небольшую витрину с количеством клиентов по статусам на каждую дату.

@@ -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).

 ---

@@ -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: сохраняем историю (подробнее)

 Чтобы хранить историю, мы меняем структуру таблицы. Вот ключевые поля: