Имеет ли смысл, чтобы параметр также был метрикой

В настоящее время я работаю над схемой склада, грубо используя подход Dimensional Modeling.

Общая идея состоит в том, чтобы иметь единую таблицу фактов, полную интересующих метрик событий, на самом низком уровне детализации. Наряду с этим, конечно же, будет таблица размеров (а), в которой будут храниться размеры записываемого события. Эти таблицы связаны dimension_id.

Мой вопрос таков: возможно ли или, скорее, имеет ли смысл, чтобы что-то было и измерением, и метрикой.

Примером может служить позиция продукта в некоторых результатах поиска. Позицию данного продукта можно считать метрикой; пользователи могут выполнить следующий запрос для продукта:

На какой средней позиции отображались товары с параметром x = y на прошлой неделе?

В то же время позиция сама по себе может считаться параметром:

Покажите рейтинг кликов всех товаров с позицией = 2 за последний месяц

Как правильно решить что-то подобное в хранилище данных (мы рассматриваем решения, ориентированные на столбцы, если это имеет значение).


comment
Вы имеете в виду меру?   -  person Neil McGuigan    schedule 22.08.2013


Ответы (1)


Мне кажется, что в обоих случаях вы просто выполняете запрос по мере в факте

товары с позицией = 2 за последний месяц

Размышляя о методах его создания, его можно получить, сгенерировав правильный список продуктов из таблицы фактов на лету, а затем ограничив внешний запрос фактов этими продуктами.

Это хорошо, если у вас есть способный аналитик, выполняющий пользовательский SQL, но нетехническому аналитику гораздо сложнее создать это в любом инструменте отчетности, который я когда-либо использовал.

OR

вы можете «закрепить» свою позицию как атрибута в медленно меняющемся измерении. Но для быстро меняющихся данных это обычно не вариант... поскольку ваше измерение меняется так быстро, что это нецелесообразно.

Если бы вы могли связать требуемый период анализа с месяцем, было бы целесообразно внедрить месячный рейтинг (и многие другие атрибуты, включая атрибуты типа скользящего периода) в медленно изменяющееся измерение, что означало бы, что у вас будет как минимум двенадцать измерений продукта. участников в год, но вы сводите каждый мыслимый реальный KPI в столбец измерения, что обычно очень полезно.

Но я предполагаю, что это не является чем-то новым для вас.

person Nick.McDermaid    schedule 23.08.2013
comment
Я предполагаю, что мой вопрос больше — дублируете ли вы некоторую часть информации (позицию), сохраняя как в таблице фактов как метрику, так и в таблице измерений как атрибут, или вы настраиваете свои системы отчетности, чтобы разрешить запросы агрегирования на числовые размеры. Надеюсь, это имеет больше смысла. - person Edwardr; 23.08.2013
comment
На мой взгляд, размерный склад с пакетной загрузкой дает вам роскошь дублировать все виды информации для удобства и скорости. - person Nick.McDermaid; 25.08.2013