Схема звезды: факты и измерения

Заказы «Гонца» уже лежат в хранилище, в правильном формате и с исправленным временем. Отто задаёт вопросы один за другим: «опаздывают ли пешие курьеры чаще, чем на велосипеде?», «а в выходные?», «а в Уралмаше?». Каждый раз аналитик пишет запрос заново, вспоминает, где лежит транспорт курьера, как перевести время и какой день считать выходным. Ошибиться легко, а ответы у разных аналитиков расходятся. Нужен такой порядок в таблицах, при котором любой вопрос Отто это пара JOIN и GROUP BY.

Чеки и справочники

Посмотри на чек из магазина. Каждая строка это одна покупка: товар, количество, цена. Чеков миллионы, и строки в них одинаково устроены.

А чтобы понять, что такое «товар 4607», есть справочник товаров: название, категория, производитель. Чтобы понять, в каком магазине пробит чек, справочник магазинов: город, адрес, площадь. Справочников мало, и они почти не меняются.

Вопрос «сколько молочного продали в Казани в выходные» решается так: берём строки чеков, через справочник товаров отбираем молочное, через справочник магазинов Казань, через календарь выходные, и складываем суммы.

Чеки это факты. Справочники это измерения. Вместе они складываются в звезду.

Факты и измерения

Таблица фактов хранит события бизнеса. Для «Гонца» это fact_deliveries: одна строка на одну доставку. В ней два вида колонок:

• ключи измерений: date_key, zone_id, courier_id. По ним факт соединяется со справочниками;
• меры: числа, которые складывают и усредняют. Цена, минуты доставки, опоздание.

Таблица измерения отвечает на вопросы «кто, где, когда»:

• dim_zone: название зоны, дата открытия;
• dim_courier: имя, транспорт, дата найма;
• dim_date: день, день недели, выходной или нет, месяц.

Факт в центре, измерения вокруг, от факта к каждому измерению одна связь. На схеме это похоже на звезду, отсюда схема звезды.

              dim_date
                 │
dim_zone ── fact_deliveries ── dim_courier