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