Что такое модели данных?
Большая часть аналитиков начинает свой путь с создания визуализаций для плоских Excel табличек, которые уже обладают всей нужной информацией. Но рано или поздно этого перестает хватать, появляется желание загрузить больше таблиц, которые, в идеале, должны взаимодействовать друг с другом. Вот тут и начинается моделирование данных.
Данные в базах хранятся в виде отдельных таблиц, между которыми можно создавать связи. Организованная структура этих таблиц и связей между ними и называется моделью данных. Чтобы избежать ошибок на начальном уровне создания отчетов, мы предлагаем вам ознакомиться с наиболее распространенным методом создания моделей. Конечно, это не единственный верный подход, которому нужно следовать всегда и везде, но он является логически целостным и довольно легко масштабируемым, что позволяет создавать как простые, так и сложные модели, в которых вам будет легко ориентироваться в дальнейшем.
Схема “звезда”
На сегодняшний день большинство экспертов в один голос утверждают, что наиболее оптимальная модель это “звезда”. Мы, в свою очередь, исключением не являемся и сами используем данный принцип. Так что же такое “звезда” и чем она так хороша?
Схема “звезда” — способ организации данных, основанный на логическом разделении их на два типа, для хранения которых используются таблицы измерений и таблицы фактов. Таблицы измерений содержат набор описательных атрибутов, характеризующих объект. Это могут такие сведения как категория объекта, его название, какие-то физические характеристики объекта и т.д. Таблицы фактов содержат сведения о событиях, в которые вовлечены те или иные объекты. На практике это выглядит как связи с таблицами измерений в виде внешних ключей и цифровые показатели, характеризующие событие, такие как цена, количество и т.д.
В качестве примера мы будем рассматривать модель, созданную в Power BI на основе выгрузки данных по рекламе из сервиса Яндекс.Директ:
На скриншоте представлена классическая “звезда”, в центре которой находится таблица фактов, вокруг которой размещены таблицы измерений. Если говорить именно о нашем примере, то в таблицах измерений содержатся следующие сведения:
- параметры кампаний;
- параметры групп объявлений;
- параметры объявлений;
- домены;
- UTM-метки;
- даты.
В таблице фактов содержатся ссылки на таблицы измерений и статистика по объявлениям:
- показы на поиске и в рекламной сети;
- клики на поиске и в рекламной сети;
- расходы на поиске и в рекламной сети;
- средняя позиция показа;
- средняя позиция клика.
Основной принцип, который нельзя нарушать: таблицы измерений не могут иметь связи между собой. Это необходимо соблюдать всегда. К примеру, вы решите связать таблицы, содержащие сведения о кампаниях и группах объявлений — это кажется вполне логичным, но это может вызвать неоднозначность в связях или просто ограничить вас в использовании данных, находящихся в одной из этих таблиц. Все связи между разными объектами реализуются только через таблицы фактов.
Однако ради справедливости стоит отметить, что это правило не всегда является абсолютным.
Схема “снежинка”
Все-таки связи между таблицами измерений возможны, и, хотя это является частным случаем “звезд”, подобный способ организации данных носит название “снежинка”. Пример такой структуры показан на следующем скриншоте, на котором появились новые таблицы по таргетингу на регионы, связанному с группами объявлений, и быстрым ссылкам, связанным с объявлениями:
Подобный способ также имеет право быть, но его следует использовать с большей осторожностью, а лучше вообще пытаться избегать по мере возможности. Основная причина в том, что чем больше связей мы имеем, тем больше шансов в них запутаться. Кроме этого, наличие большого количества иерархических связей ( A -> B -> C -> D … ) может негативно сказаться на производительности.
В приведенном примере мы просто не можем сделать иначе, поэтому и применяем подобный подход: у одного объявления может быть несколько быстрых ссылок и одна группа объявлений может быть нацелена на показ в нескольких регионах. В тоже время мы имеем только иерархические связи, а не циклические, что позволяет избежать неоднозначности, о которой упоминалось выше.
Какие преимущества имеют эти схемы?
Данный подход на протяжении многих лет использовался для проектирования аналитических баз данных и отличается от других именно своей простотой получения необходимых сведений. В то же время, это только вершина айсберга, самое интересное вытекает как раз из основного принципа разделения данных на логические элементы (объекты). Дело в том, что при использовании различных источников данных некоторые объекты могут повторяться, но здесь стоит отметить, что речь идет не столько об их названиях, сколько о структуре. К примеру, если мы возьмем рекламные кампании в том же Яндекс.Директ и Facebook, то по своему существу они похожи, но по структуре данных отличаются. В то же время, если мы возьмем UTM-метки, которыми размечены URL объявлений в этих кампаниях, или дату, за которую мы выгрузили статистику, то они одинаковы во всех смыслах. Поэтому такие данные можно вынести отдельно в так называемые общие таблицы измерений, которые одинаковы и могут использоваться в разных таблицах фактов:
В данном случае мы имеем две таблицы фактов, которые находятся по бокам, и три таблицы общих измерений, которые размещены по середине. Данные были выгружены из разных рекламных площадок, но, учитывая их организацию, мы можем их использовать совместно, т.е. посчитать общий расход на рекламу по дням или сайтам. Более того, в эту модель можно легко добавить данные из других рекламных площадок или Google Analytics.
Обратная сторона модели
Сложно сказать, есть ли у данного подхода есть явные недостатки, но ради справедливости следует отметит тот факт, что при его использовании есть вероятность незначительного увеличения объема памяти, занимаемого моделью, и, как следствие, некоторое снижение производительности, по сравнению с тем, если бы все данные хранились в одной большой таблице. В тоже время не стоит забывать, что на практике мы редко имеем возможность работы с такого рода данными… Поэтому возможность получения прозрачности данных и масштабируемости модели за счет незначительного снижения производительности сложно назвать недостатком.
Мы прекрасно понимаем, что в рамках одной статьи невозможно описать все тонкости моделирования, но в то же время мы и не ставили перед собой такой задачи, а хотели лишь выделить основные моменты, которые возможно заставят читателей задуматься о роли создания моделей и постараться разобраться в этой интересной теме чуть-чуть более подробно. Со своей стороны, мы не планируем останавливаться на этом, и в следующий раз постараемся рассмотреть более практичный и немного более сложный пример, чем те, которые мы рассматривали в этой статье.