Documentation
🗂️ Модели данных
Модели данных

Витрина Данных

Ничего общего с магазином, конечно же, нет!

Витрина данных (Data Mart) — это просто таблица или таблицы. Чаще всего DE используют это слово, когда говорят про таблицу для дата аналитиков. Грубо говоря, дата инженеры загрузили данные в хранилище, очистили их от ненужной инфы, обогатили таблицу еще другими таблицами и получили какую-то общую. В ней может быть например собраны все заявки по кредитам, все заявки по ипотекам и кредитным картам в банке за вчерашний день. Хотя на входе там были данные просто с действиями пользователей на сайте.

Дата инженер раскопал все источники, понял, как с ними работать и сделал для дата аналитика некий готовый срез.

Витрина данных, аналогично дашборду, позволяет аналитику увидеть агрегированную информацию в определенном временном или тематическом разрезе, а также сформировать отчетные данные в виде шаблонизированного документа. Витрина данных часто представлена в виде денормализованой таблицы, однако это не всегда удобно и не позволяет решать все задачи, поэтому чаще встречается таблица фактов и таблица измерений.


Таблица фактов — главная таблица, в которой пишутся события, например, текущие заказы или действия пользователей на сайте. Т.е. некие события, которые скорее всего имеют уникальный характер.

Таблица измерений (англ. dimension table) — таблица, в которой хранятся описания объектов. Например id, ФИО курьера, который доставил заказ. Или данные каждого клиента. Таблицы измерений удобны тем, что там можно хранить те данные, которые не часто меняются. Очевидно, что писать в таблице фактов номер телефона клиента будет избыточно. Нам достаточно один раз его записать в таблицу измерений и дать ссылку на это в таблице фактов. И при любом запросе к определенному заказу, мы всегда получим актуальный номер телефона клиента, потому что мы изменили его в таблице измерений.


Модели "Звезда" и "Снежинка"

Модель "Звезда"

Схемы «звезда» и «снежинка» — это два способа структурировать хранилище данных.

Схема типа «звезда» (пространственная модель, модель измерений и фактов, модель «сущность-связь», dimensional model, star schema) представляется двумя видами таблиц: таблицами фактов и таблицами измерений, которые описывают факты. Схема разбивает таблицу фактов на ряд денормализованных таблиц измерений. Таблица фактов содержит агрегированные данные, которые будут использоваться для составления отчетов, а таблица измерений описывает хранимые данные. Денормализованные проекты менее сложны, потому что данные сгруппированы. Таблица фактов использует только одну ссылку для присоединения к каждой таблице измерений. Более простая конструкция звездообразной схемы значительно упрощает написание сложных запросов.

Модель "Снежинка"

Схема типа «снежинка» отличается тем, что использует нормализованные данные. Нормализация означает эффективную организацию данных так, чтобы все зависимости данных были определены, и каждая таблица содержала минимум избыточности. Таким образом, отдельные таблицы измерений разветвляются на отдельные таблицы измерений. Схема «снежинки» использует меньше дискового пространства и лучше сохраняет целостность данных. Основным недостатком является сложность запросов, необходимых для доступа к данным — каждый запрос должен пройти несколько соединений таблиц, чтобы получить соответствующие данные.


SCD [Slowly Changing Dimensions]

Эта штука очень важна. Обязательно изучите это.

SCD 0

SCD 0 — данные записываются один раз и дальше никогда не меняются. История не ведется, потому что изменения в принципе не допускаются. Пример: справочник с фиксированными категориями, где значения не должны изменяться.

SCD 1

SCD 1 — это перезапись значения "в лоб": старое значение заменяется новым, без хранения истории.

item_id name price aisle
93201 Картошка 3.99 11
07879 Помидоры 7.99 13

item_id name price aisle
93201 Картошка 3.99 6
07879 Помидоры 7.99 13

Пример: у товара 93201 значение aisle поменялось с 11 на 6, старая версия строки не сохраняется.

SCD 2

SCD 2 — история хранится построчно. При изменении атрибута у текущей строки обновляется end_date, а новая версия записи добавляется отдельной строкой с новой start_date.

item_id name price aisle start_date end_date
93201 Картошка 3.99 11 2024-11-13 2099-12-31
07879 Помидоры 7.99 13 2024-08-24 2099-12-31

item_id name price aisle start_date end_date
93201 Картошка 3.99 11 2024-11-13 2025-01-03
07879 Помидоры 7.99 13 2024-08-24 2099-12-31
93201 Картошка 7.99 6 2025-01-04 2099-12-31

SCD 3

SCD 3 — в одной строке хранят и текущее, и предыдущее значение атрибута в отдельных колонках. Глубина истории обычно ограничена 1-2 предыдущими состояниями.

team_id team_name sport current_stadium_name previous_stadium_name
123456 Спартак Москва Футбол Открытие Арена NULL
789012 ЦСКА Москва Футбол ВЭБ Арена NULL

team_id team_name sport current_stadium_name previous_stadium_name
123456 Спартак Москва Футбол Газпром Арена Открытие Арена
789012 ЦСКА Москва Футбол ВЭБ Арена NULL

SCD 4

SCD 4 — текущие данные хранятся в основной таблице, а исторические версии выносятся в отдельную history-таблицу. Удобно, когда рабочие запросы идут только по актуальному срезу.

5 и 6 версии являются уже просто комбинациями из выше перечисленных. Шарить за них не нужно. Да и о них мало кто знает вообще.

SCD 6

SCD 6 — гибрид SCD 1/2/3: есть полная история версий (как в SCD 2), часть полей может перезаписываться (SCD 1), а для ключевых атрибутов хранятся предыдущие значения отдельными колонками (SCD 3).