Можно загрузить в BI одну огромную таблицу и быстро получить первый график. Потом появятся возвраты, несколько дат, история менеджеров и разные справочники. Таблица начнёт обрастать копиями, а сумма — размножаться.
Звёздная схема раскладывает модель на центральный факт и окружающие измерения. Название красивое, логика бытовая: отдельно события, отдельно их описания.
Что это такое простыми словами
Таблица фактов хранит строки на выбранном уровне детализации: один товар в заказе, один платёж, один рекламный расход за день. В ней лежат ключи измерений и показатели, которые можно суммировать или считать.
Измерения содержат описание: клиент, товар, канал, дата, регион, менеджер. Они отвечают за фильтры и группировки.
Самое важное слово — зерно. Нужно заранее закончить фразу: «одна строка факта — это…». Если в таблице смешаны заказ и позиция заказа, суммы почти наверняка удивят.
Зачем это бизнесу
Пользователю проще находить поля, разработчику — писать меры, системе — выполнять запросы. Один справочник продукта используется несколькими фактами и сохраняет единые категории.
Модель помогает отделить бизнес-логику от визуализации. Маржа считается одной мерой и работает на всех страницах отчёта, а не копируется в каждый график.
Звезда особенно полезна, когда отчётов становится много. Она не делает данные правильными автоматически, но создаёт место, где правила можно закрепить.
Как сделать: пошаговый порядок
- Определите бизнес-процесс: продажи, платежи, обращения или расходы.
- Зафиксируйте зерно таблицы фактов одним предложением.
- Выберите измерения, по которым пользователи будут фильтровать и сравнивать.
- Создайте стабильные ключи и обработайте неизвестные значения.
- Проверьте направления связей и отсутствие связи многие-ко-многим без явной причины.
- Сверьте суммы на нескольких срезах с исходной системой.
Формула или логика расчёта
Если факт продаж хранит позицию заказа, выручка = сумма количества × цены по строкам с учётом скидок и возвратов. Количество заказов при этом считают как число уникальных order_id, а не строк. Зерно подсказывает правильную агрегацию.
Подробный пример с числами
Есть 100 заказов и 280 товарных строк. В плоской таблице сумма заказа повторялась на каждой позиции. Отчёт показал 8,4 млн рублей вместо реальных 3 млн.
Мы выбрали зерно «одна позиция заказа», перенесли данные заказа и клиента в измерения, а в факт положили количество, цену, скидку и возврат. Выручка по строке стала рассчитываться отдельно.
После сверки получили 3 млн выручки, 100 уникальных заказов и средний чек 30 тысяч. Категории товара больше не дублировались в каждой выгрузке, а изменение названия не переписывало старые расчёты без контроля.
Модель стала не только аккуратнее. Новый срез по региону собрали за час, потому что регион уже был нормальным измерением.
Какие проверки спасают модель от тихих ошибок
Сначала проверьте уникальность ключей измерений. Если один product_id встречается дважды, связь один-ко-многим может размножить факт. Отчёт не обязательно выдаст ошибку — он просто уверенно покажет лишнюю выручку. Именно тихие ошибки особенно любят презентации.
Затем проверьте полноту связей. Все ключи факта должны находить строку измерения. Для неизвестных или ещё не приехавших значений создают техническую запись «не определено», а не теряют продажи при соединении. Доля таких строк становится отдельным показателем качества.
Контролируйте аддитивность. Выручку можно суммировать по времени и товарам, остаток на счёте — нельзя складывать по дням, а процент конверсии нужно пересчитывать из числителя и знаменателя. Тип показателя определяет безопасную агрегацию.
Несколько дат требуют ролевых измерений: дата заказа, оплаты, отгрузки и возврата отвечают на разные вопросы. Если отчёт молча использует одну из них, два пользователя получат разные месяцы продаж и оба будут правы в своей логике.
Историю изменений решайте осознанно. Если клиент переехал в другой регион, нужно ли прошлые продажи показать по новому региону или сохранить старый? Для второго сценария применяется историзация измерения. Это бизнес-правило, а не только техническая настройка.
Наконец, сделайте контрольный набор из десятка заказов: обычный, со скидкой, несколькими товарами, частичным возвратом и изменённым клиентом. Сверяйте его после каждой заметной правки модели.
Короткий чек-лист
- уникальные ключи измерений
- доля неизвестных связей
- зерно каждого факта
- правильная агрегация мер
- явный выбор даты
- контрольные заказы и суммы
Как превратить расчёт в решение
Отдельно продумайте общие измерения. Календарь, клиент и продукт должны одинаково работать с продажами, платежами и рекламой. Это позволяет сравнивать факты без копирования справочников и разъезда категорий.
Если между фактами нужна связь, чаще безопаснее фильтровать их через общие измерения, а не соединять напрямую. Прямая связь продаж и платежей по заказу может размножить строки при нескольких оплатах и товарах.
Названия полей делайте бизнесовыми. Пользователю нужен «Дата оплаты», а не paid_dt_utc. Техническое имя остаётся в источнике, семантическое — в модели. Описание уточняет часовой пояс и правила.
При росте модели следите за числом таблиц и направлением связей. Звезда ценна простотой. Если схема превращается в созвездие с проводами во все стороны, пора разделить домены или пересмотреть зерно.
Что должно быть зафиксировано
- общие измерения фактов
- отсутствие опасных связей факт-факт
- бизнесовые названия
- описание даты и часового пояса
- простота фильтрации
Рабочий план на четыре недели
Пилот нужен не ради ещё одного файла. За месяц команда должна получить воспроизводимый расчёт, увидеть ограничение и принять хотя бы одно решение. Объём специально небольшой: один сегмент, один процесс и один ответственный. Так результат можно проверить, а не объяснять масштабом.
- Неделя 1: определите процесс и зерно факта, затем выделите общие измерения.
- Неделя 2: загрузите контрольные заказы, возвраты и неизвестные ключи.
- Неделя 3: соберите меры и проверьте суммы на нескольких фильтрах и датах.
- Неделя 4: подключите один реальный отчёт и уберите поля, которые путают пользователя.
Перед стартом сохраните исходные значения, правила и дату. После каждого этапа записывайте не только итог, но и время команды, ручные действия и найденные ошибки. В конце сравните результат с исходной точкой и решите: расширяем подход, дорабатываем конкретное место или спокойно закрываем гипотезу. Любой из трёх ответов полезен, если он подтверждён данными.
Назначьте короткую встречу через неделю после пилота. На ней нужен один экран: что изменили, что получилось, где ограничение и какое действие приняли. Если ответ нельзя уместить на одном экране, скорее всего, пилот пытался решить слишком много задач одновременно.
Хороший пилот оставляет после себя рабочий артефакт: проверенную формулу, карту данных, правило процесса или прототип. Назначьте владельца и дату следующей проверки. Без этого даже удачный результат быстро становится презентацией, которую все помнят примерно, а повторить уже не могут (так себе наследство).
Сразу договоритесь о границе масштабирования. Запишите, какой результат считается достаточным, сколько ручной работы допустимо и что должно произойти, чтобы подключить следующий источник, отдел или сегмент. Это защищает от двух крайностей: бесконечного пилота без внедрения и слишком быстрого развёртывания сырого решения на всю компанию. Перед расширением повторите контрольный расчёт на новом участке и убедитесь, что правила не потеряли смысл.
И ещё: сохраните один неудачный пример. Он лучше общей инструкции показывает команде, где метод перестаёт работать, какое ограничение нужно проверить и почему автоматический вывод нельзя принимать без контекста.
Рядом с неудачным примером запишите способ ручной сверки и человека, который принимает решение в спорной ситуации. Тогда исключение не остановит весь процесс и не превратится в новую тайную формулу, известную одному сотруднику.
Ограничения и типичные ошибки
- Не смешивайте факты разного зерна в одной таблице без явного решения.
- Не связывайте измерения по названиям, которые меняются и повторяются.
- Не делайте двунаправленные связи стандартом — они усложняют фильтрацию.
- Не храните готовые итоги там, где они будут суммироваться повторно.
- Исторические изменения клиентов и товаров требуют отдельной стратегии.
Как мы используем это в работе
Я прошу команду сначала проговорить строку факта вслух. Затем на реальных заказах проверяем ключи, возвраты и несколько дат. Только после этого строим красивую модель.
Маркетингу отдаём измерение каналов, продажам — клиентов и менеджеров, финансам — правила суммы и периода. Общий факт связывает их без копирования логики.
Если в отчёте суммы меняются после добавления фильтра, можно проверить зерно и связи на ваших данных. Кнопка ниже — чтобы обсудить модель со мной.
Что сделать прямо сейчас
Возьмите одну таблицу отчёта и завершите фразу «одна строка — это». Затем разделите её колонки на ключи, показатели и описания. Уже на этом шаге всплывают основные дубли.
