объединение нескольких таблиц фактов с измерением между ними

Какой хороший подход к проектированию хранилища данных, если запрошенные отчеты требуют обобщенной информации об одних и тех же измерениях (и с той же степенью детализации), но базовые данные хранятся в отдельных таблицах фактов?

Например, отчет, показывающий общую выплаченную зарплату и общие расходы по каждому сотруднику за каждый год, когда зарплата и расходы регистрируются в разных таблицах фактов. Или отчет, в котором перечислены общие продажи за месяц и полученные за месяц запасы для каждой SKU, проданной компанией, когда продажи поступают из одной таблицы фактов, а получение - из другой.

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

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

Кроме того, есть ли у этого варианта использования "сэндвич измерений" название в канонической терминологии хранилищ данных? Если да, это упростит поиск через Google.

Мы работаем с SQL Server, но я надеюсь, что вопросы, которые у меня возникают, не зависят от платформы.


person Justin Grant    schedule 13.01.2014    source источник
comment
Вы также можете рассмотреть сводная таблица фактов.   -  person Marek Grzenkowicz    schedule 13.01.2014
comment
Консолидированные таблицы фактов также позволяют ввести полезные дополнительные или производные данные. Например, существует множество способов расчета оборачиваемости запасов с использованием данных о запасах и продажах, часто (не всегда) рекомендуется подготовить столбец для использования на этапе ETL, побуждая бизнес-пользователей использовать тот же расчет.   -  person momobo    schedule 13.01.2014
comment
Консолидированные таблицы фактов работают нормально для некоторых сценариев использования, но многие бизнес-сценарии нашего DW имеют как простые измерения (в отличие от описанного выше случая инвентаризации, где важны расчеты экспертов), так и требуются для поддержки специальной фильтрации и агрегации. результаты определены.   -  person Justin Grant    schedule 14.01.2014
comment
Но с помощью полезной ссылки Кимбалла, предоставленной @MarekGrzenkowicz, я смог найти Drilling Across, и это именно та проблема, которую я пытаюсь решить.   -  person Justin Grant    schedule 14.01.2014


Ответы (2)


Сегодня я узнал, что этот метод называется Переход по иерархии:

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

Похоже на наивное решение выше (запросить несколько таблиц фактов параллельно и объединить результаты) также является предлагаемым решением.

Больше информации:

Большое спасибо @MarekGrzenkowicz за то, что указал мне в правильном направлении, чтобы найти свой собственный ответ! Я отвечаю на него здесь, если кто-то еще ищет то же самое.

person Justin Grant    schedule 13.01.2014

Описанное вами "наивное решение" в большинстве случаев является предпочтительным.

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

person Ronnis    schedule 17.01.2014