Предновогодний пост с новогодними элементами: Звезда, Снежинка и Data Vault⁠⁠

Ну что, новый год не за горами, за окном зимнее настроение и в преддверии новогоднего чуда поговорим о моделях данных.

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

Их больше чем три, просто эти самые часто используемые.

Ну об этом ниже.

А пока подписывайся на мой канал На связи: SQL
Там я публикую посты про особенности и нюансы SQL.

Этот канал про то, как не бояться баз данных, понимать, что такое JOIN, GROUP BY и почему NULL ≠ 0. Его я веду с нуля подписчиков.
Разбор задач со скользящим окном уже в канале.
Присоединяйся!

Почему вообще возникают схемы хранения данных?

Представь обычную рабочую базу: CRM, биллинг, сайт, мобильное приложение.
Там данные живые:
- что-то постоянно обновляется
- что-то удаляется
- что-то правится «прямо сейчас»

Такая база нужна, чтобы система работала.

А теперь представь аналитика, который приходит и спрашивает:
- сколько мы продали за год
- как изменилась выручка
- кто покупал чаще
- что происходило в прошлом квартале

И тут выясняется неприятная вещь:
базы, удобные для работы системы, неудобны для анализа.

Именно в этот момент появляются специальные способы моделирования данных.

Звезда

Самая дружелюбная и любимая для аналитика схема.

Она выглядит очень просто:
в центре - таблица с событиями, ее иногда называют таблицей фактов.
вокруг - таблицы с описанием этих событий (фактов).

Например, продажа - это событие.
А клиент, товар, дата, магазин - это описание.

В результате получается структура, где:
- запросы читаются легко
- JOIN-ы понятные
- отчёты считаются быстро

Звезда - это про комфорт.
Про «я открыл SQL и через 5 минут понял, что тут происходит».

Поэтому почти все BI-отчёты, дашборды и витрины данных в итоге сводятся именно к звезде, даже если внутри системы всё гораздо сложнее.

Снежинка

Снежинка чаще всего возникает, когда разрастаются справочники, которые описывают события, когда сами справочники становятся многоуровневыми.

Например: у клиента есть адрес, а адрес по ФИАСу имеет несколько уровней: Регион, район, город/населенный пункт и т.д.

В таких случаях "звезда" начинает таять и превращается в снежинку.

Если структурно, то снежинку можно описать так:
В снежинке таблицы описаний дробятся:
категории выносятся отдельно,
регионы - отдельно,
справочники становятся иерархиями.

Данных дублируется меньше, структура логичнее, архитектор доволен.
А вот аналитик уже не так счастлив - запросы длиннее, JOIN-ов больше, ошибок больше.

Снежинка - это компромисс.
Она аккуратнее, но сложнее.
Её выбирают там, где важен порядок, а не только скорость анализа.

Data Vault

Эта модель отвечает на вопрос:

Как сохранить данные так, чтобы ничего не потерять?

Здесь никого не волнует, удобно ли тебе писать SELECT.
Здесь волнует:
- откуда пришли данные
- когда они изменились
- какими они были раньше

Data Vault специально спроектирован так, чтобы история не затиралась.
Ничего не обновляется "поверх".
Каждое изменение - это новая версия.

Как это ощущается на практике

В обычной аналитической модели клиент сменил фамилию - и всё, старая пропала.
В Data Vault фамилия просто получила новую запись с датой изменения.
И теперь можно узнать, какой она была год назад, два года назад, пять лет назад.

Поэтому Data Vault так любят банки, финтех и большие корпорации:
- аудит
- юридическая точность
- десятки источников
- постоянные изменения

Часто Data Vault используют как "внутреннее хранилище правды",
а поверх него уже строят звёзды - для аналитиков и отчётов.

Да и в принципе Data Vault переводится как "хранилище данных", "сейф данных".

В моем канале На связи: SQL все простыми словами и с конкретными примерами.
Подписывайся!