# Структура хранилища данных (для студентов SQL/Postgres)
> **Цель**: объяснить, как раскладывать данные в аналитической БД и почему именно так принято. Рус/Eng термины приводятся вместе (например, «витрина (Data Mart)»).
---
## 0. Навигация по статье
* [1. Введение: зачем слои и почему не «всё в одну таблицу»](#1)
* [2. Учебный домен/пример](#2)
* [3. Типичная структура слоёв (STG → ODS → DDS → DM)](#3)
* [4. Слои по отдельности](#4)
* [5. Модели данных для DDS/DM: 3NF, Звезда/Снежинка, Data Vault, Anchor](#5)
* [6. Ключевые понятия: факт/измерение, зерно, SK vs BK, SCD](#6)
* [7. Выбор подхода: дерево решений](#7)
* [8. Эволюция схемы и эксплуатации](#8)
* [9. MVP учебного проекта](#9)
* [10. Заключение](#10)
---
## 1. Введение: зачем слои и почему не «всё в одну таблицу»
**Коротко**: OLTP vs OLAP, управляемость, прозрачность, стоимость.
**Заглушки для текста**:
* Что такое слои и какую проблему решают.
* Почему «одна большая таблица» ломается на истории и изменениях.
* 3–4 тезиса о выгодах послойной архитектуры.
---
## 2. Учебный домен/пример (интернет-магазин)
**Описание**: используем один домен сквозь статью: клиенты, товары, заказы, позиции заказа, цены, акции.
**Диаграмма ER (эскиз)**:
```mermaid
erDiagram
CUSTOMER ||--o{ ORDER : places
ORDER ||--|{ ORDER_ITEM : contains
PRODUCT ||--o{ ORDER_ITEM : referenced
PRODUCT ||--o{ PRICE : has
PROMO ||--o{ ORDER_ITEM : applied
CUSTOMER {
int customer_id PK
string email
string phone
}
PRODUCT {
int product_id PK
string name
}
ORDER {
int order_id PK
date order_date
int customer_id FK
}
ORDER_ITEM {
int order_item_id PK
int order_id FK
int product_id FK
int qty
numeric price_at_sale
}
PRICE {
int product_id FK
date valid_from
date valid_to
numeric price
}
PROMO {
int promo_id PK
string code
}
```
**Заглушки**: 2–3 абзаца с пояснениями domain-гранулярности и бизнес-ключей (BK).
---
## 3. Типичная структура слоёв (STG → ODS → DDS → DM)
**Картинка-конвейер (эскиз)**:
```mermaid
flowchart TD
subgraph Sources[Источники]
A[CRM] --> STG
B[Billing] --> STG
C[E-comm] --> STG
end
STG[STG
Staging / Bronze] --> ODS[ODS
Operational / Silver]
ODS --> DDS[DDS
Integrated / Conformed]
DDS --> DM[DM
Data Marts / Gold]
DM --> BI[BI / Отчёты / Дашборды]
```
**Заглушки**:
* Соответствие Bronze/Silver/Gold.
* Что происходит на каждом переходе в 1–2 фразы.
---
## 4. Слои по отдельности
### 4.1 STG (Staging/Bronze)
**Коротко**: «как пришло». Идемпотентность, дедупликация, неизменяемость/переигрузка.
**TODO**: список «что можно» / «что нельзя»; форматы; контроль качества на входе.
### 4.2 ODS (Operational Data Store/Silver)
**Коротко**: чистка и выравнивание типов, базовая унификация кодов, ещё без тяжёлой бизнес-логики.
**TODO**: правила именования, ключи, простая история.
### 4.3 DDS (Integrated/Conformed Layer)
**Коротко**: интеграция источников, общие справочники, SK/BK, SCD. Здесь уже начинаются модели данных. Какие модели испольуют.
**TODO**: где хранить историю, антидубли, конформные измерения.
### 4.4 DM (Data Marts/Gold)
**Коротко**: модели под задачи BI (звезда/снежинка). Агрегаты, материализации.
**TODO**: границы ответственности витрин.
---
## 5. Модели данных для DDS/DM: 3NF, Звезда/Снежинка, Data Vault, Anchor
### 5.1 3NF (по Инмону, 3-я нормальная форма)
**Идея**: целостная интегрированная модель предприятия.
**Мини-эскиз (ER, нормализовано)**:
```mermaid
erDiagram
CUSTOMER ||--o{ ORDER : places
ORDER ||--|{ ORDER_ITEM : contains
PRODUCT ||--o{ ORDER_ITEM : referenced
CATEGORY ||--o{ PRODUCT : classifies
PRICE ||--o{ PRODUCT : defines
```
**TODO**: плюсы/минусы, когда выбирать.
### 5.2 Звезда/Снежинка (по Кимбаллу)
**Идея**: простые и быстрые аналитические запросы.
Упомянуть, что самая часто испольуемая модель.
**Эскиз звезды: факт + измерения**:
```mermaid
flowchart LR
F[fact_orders
order_id, date_key, customer_key, product_key, qty, amount]
D1[dim_date] --> F
D2[dim_customer] --> F
D3[dim_product] --> F
D4[dim_store] --> F
```
**Эскиз снежинки (нормализация измерения продукта)**:
```mermaid
graph LR
D3[dim_product] --> C[dim_category]
```
**TODO**: зерно факта, типы измерений, агрегаты.
### 5.3 Data Vault 2.0 (Hub–Link–Satellite)
**Идея**: масштабируемая интеграция многоисточниковых данных с полной историей.
**Эскиз DV (упорядоченная колонками)**:
```mermaid
flowchart LR
%% Hubs (слева)
HC[Hub_Customer]
HO[Hub_Order]
HP[Hub_Product]
%% Links (центр)
LOC[Link_OrderCustomer]
LOP[Link_OrderProduct]
%% Satellites (справа)
SC[SAT_Customer]
SO[SAT_Order]
SP[SAT_Product]
%% Связи к сателлитам
HC --> SC
HO --> SO
HP --> SP
%% Связи между хабами и линками
HC --> LOC
HO --> LOC
HO --> LOP
HP --> LOP
```
**TODO**: Raw Vault vs Business Vault, плюс/минус.
На каких слоях используем, зачем там оно нам.
Схема часто используется. Пишем, почему.
### 5.4 Anchor Modeling (Анкерное моделирование)
**Идея**: эволюционируемость атрибутов с версионированием на уровне «якорей/атрибутов/узлов».
**Эскиз (упрощённый)**:
```mermaid
flowchart LR
AC[Anchor CUSTOMER]
KC[Knot CUSTOMER_ID]
AC --> KC
AC --> AN[Attr NAME]
AC --> AE[Attr EMAIL]
AN --> NV[Name values history]
AE --> EV[Email values history]
```
**TODO**: где уместно, порог входа.
**TODO**: где уместно, порог входа.
Редко используется. Сложна для людей и для машин. Обосновываем.
---
## 6. Ключевые понятия (минимум для практики)
* **Факты (Facts)** и **Измерения (Dimensions)**; **зерно (grain)** факта.
* **Натуральные ключи (BK)** и **суррогатные ключи (SK)**.
* **SCD (Slowly Changing Dimensions)**: типы 1 / 2 / 4 / 6.
* **Bridge/Junk dimensions**, календарь, валюта, часовой пояс.
* **Поздно прибывающие события (late arriving)**.
**Эскиз SCD‑истории (Type 2) как лента времени**:
```mermaid
gantt
dateFormat YYYY-MM-DD
title SCD Type 2: dim_customer.name
section Customer 42
Version_1 :active, v1, 2023-01-01, 2023-06-14
Version_2 : v2, 2023-06-15, 2024-02-28
Version_3 : v3, 2024-03-01, 2025-10-26
```
**TODO**: короткие примеры для Type 1/2/4/6.
---
## 7. Выбор подхода: дерево решений (эскиз)
```mermaid
graph TD
Q0{Сколько источников?} -->|1–2| Q1{Требуется глубокая история?}
Q0 -->|3+| Q2{Схемы часто меняются?}
Q1 -->|нет| STAR[DM: Звезда/Снежинка]
Q1 -->|да| Q1a{Высокая BI‑нагрузка?}
Q1a -->|да| STAR2[DM: Звезда/Снежинка]
Q1a -->|нет| NF3[DDS: 3NF + DM при необходимости]
Q2 -->|да| DV[ DDS: Data Vault → DM: Звезда ]
Q2 -->|нет| MIX[ DDS: 3NF или упрощённый конформный слой → DM: Звезда ]
```
**TODO**: превратить в 6–8 вопросов с текстовыми пояснениями.
---
## 8. Эволюция схемы и эксплуатационные практики
* Совместимость назад/вперёд, view‑based миграции.
* Идемпотентные пайплайны, дедупликация, инкрементальные загрузки (CDC).
* Data Quality: уникальность, ссылочная целостность, распределения, «contracts».
* Каталог/линейка (Data Catalog / Lineage), словарь данных (Business Glossary), владение.
**TODO**: чек-лист из 8–10 пунктов.
---
## 9. MVP учебного проекта (рецепт)
1. STG: положить сырые данные из 2–3 источников.
2. ODS: очистка и выравнивание типов.
3. DDS: либо упрощённая интеграция (конформные справочники), либо Raw Vault.
4. DM: одна звезда `fact_orders` + 3–4 измерения.
5. Простой отчёт/дашборд и верификация цифр.
6. Мини‑тесты качества данных.
**Эскиз «дорожной карты»**:
```mermaid
graph LR
S[STG готов] --> O[ODS готов] --> D[DDS готов] --> M[DM готов] --> R[Отчёт готов]
```
---
## 10. Заключение
**Заглушки**: повторить ключевые тезисы, дать ссылки на дополнительные темы: CDC, оркестрация, тестирование данных, наблюдаемость.
---
## Примечания к иллюстрациям
* Диаграммы — **эскизы**: заменить/уточнить, когда будет готов текст.
* При необходимости добавить отдельные рисунки: «что можно/нельзя в слоях», SCD типы на одном полотне, пример late arriving events.