Ну что, новый год не за горами, за окном зимнее настроение и в преддверии новогоднего чуда поговорим о моделях данных.
Многие из нас привыкли работать с таблицами и воспринимаем набор данных как плоскую структуру. Но если расширить фокус не просто на таблицы с данными, а на таблицы и их связи между ними, то сразу можем переходить к обсуждению моделей данных.
Их больше чем три, просто эти самые часто используемые.
А пока подписывайся на мой канал На связи: 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 все простыми словами и с конкретными примерами.
Подписывайся!
