Одни таблицы хранят события и показатели, другие объясняют их контекст. Разбираем модель «звезда» и показываем, почему сначала нужно определить смысл одной строки.
Сначала решите, что означает одна строка
Представим условный магазин. Руководителю нужен отчёт о продажах по товарам, магазинам и дням. Прежде чем выбирать диаграмму, команде нужно договориться, что именно будет записано в каждой строке: целый чек, отдельная позиция чека или итог за день. Эти варианты описывают одну деятельность с разной подробностью и отвечают на разные вопросы.
Такую подробность называют гранулярностью. Например, строка может означать продажу одного вида товара в конкретном чеке. В ней уместны количество и стоимость этой позиции. Общая сумма чека относится уже к другому уровню. Если заранее не определить смысл строки, даже аккуратно оформленный отчёт может складывать несопоставимые сведения.
Факты описывают события, измерения добавляют контекст
В руководстве Microsoft таблицы фактов хранят наблюдения или события, а измерения описывают связанные сущности. Для нашего магазина факт — продажа позиции. Измерениями могут быть товар, магазин и календарная дата. Они позволяют рассматривать одни и те же продажи в нужных разрезах: например, по категории товара или городу.
Связи между таблицами опираются на идентификаторы. Короткая ссылка на товар в записи продажи ведёт к его описанию: названию, категории и другим признакам. Если нарисовать одну таблицу фактов в центре, а связанные измерения вокруг, получится фигура, напоминающая звезду. Это название устройства модели, а не особый вид графика в отчёте.
Почему нельзя смешивать чек и позицию
Разберём условные числа. В первом чеке две позиции стоимостью 1000 и 500 рублей, во втором — одна на 700 рублей. Для модели с одной строкой на позицию получатся три записи, а сумма продаж составит 2200 рублей. В модели с одной строкой на чек записей будет две, но общая сумма останется той же.
Ошибка возникает, если в обе строки первого чека положить его полную сумму — 1500 рублей. Вместе со вторым чеком отчёт насчитает 3700 рублей. Это уже не вопрос оформления. По правилу Kimball Group, гранулярность определяют до выбора фактов и измерений, а разные уровни не смешивают в одной таблице фактов.
Какие вопросы сможет задать читатель отчёта
В предложенной модели можно сопоставить продажи разных категорий по дням. Но если исходная запись хранит только дневной итог магазина, восстановить из неё отдельные позиции чеков нельзя. Добавление красивого названия столбца не возвращает утраченную подробность. Поэтому требования к будущим вопросам стоит обсуждать до окончательного сворачивания исходных событий в итоги.
Также нужно понимать, что измеряет показатель. Сумма продаж за день и остаток товара на конец дня имеют разный смысл. Складывать ежедневные остатки и называть результат количеством проданных товаров нельзя. Одинаковый числовой вид ещё не делает показатели взаимозаменяемыми. Для учебного разбора достаточно подписать словами каждое значение и ожидаемый способ его использования.
Модель не выбирает правильные правила за команду
Для условного магазина предложим описать один чек и пройти его путь до отчёта. Какие записи появятся, где хранится стоимость каждой позиции, как выбирается описание товара? Затем повторим проверку для чека с несколькими позициями. Такой небольшой пример помогает обсуждать требования, но сам по себе не доказывает правильность всей рабочей загрузки.
Схема «звезда» не означает, что любую систему следует перестраивать одинаково. Назначение модели, доступная подробность и правила показателей остаются отдельными решениями. Важно также договориться, какое описание товара требуется для прошлого периода: нынешнее или действовавшее тогда. Это дополнительный вопрос проектирования, а не свойство, которое автоматически появляется от расположения таблиц.
Как связать модель с устройством системы
Логическое разделение фактов и измерений отличается от физического хранения файлов. Последнее объясняет статья о хранении по строкам и столбцам. Вопросы согласования всей системы рассматривает материал о работе архитектора данных. Эти темы дополняют выбор смысла одной строки.
Продолжить знакомство с проектированием можно на программе «Архитектор данных». Полезный первый результат — объяснить модель без технической схемы: какое событие записываем, какие показатели ему принадлежат и какие описания помогают анализировать это событие.
