Схема хранилища данных: можно ли напрямую связывать таблицы фактов в DWH?

Question

Можно ли напрямую связывать таблицы фактов в DWH?

Как я понимаю, в таблицах фактов схемы galaxy нет связи, они просто имеют общую таблицу измерений. Но если есть схема DWH, которая предполагает их прямую связь?

Answer 1

Нет, нельзя напрямую связывать таблицы фактов.

Во-первых, если вы правильно смоделируете свои таблицы фактов, вы не сможете связать их осмысленным образом. Единственное исключение - таблицы фактов, которые имеют отношения 1: 1, но тогда возникает вопрос - может быть, для начала их нужно смоделировать как одну таблицу фактов.

Во-вторых, связывание таблиц фактов напрямую идет вразрез с основной идеей многомерного моделирования - то, что модель должна отражать структуру основного бизнеса. Как правило, в моделях измерений таблицы фактов представляют конкретные бизнес-процессы, а измерения представляют их контексты. В этом ключевое отличие OLTP от многомерных баз данных: системы OLTP оптимизированы для эффективного и надежного захвата транзакций, тогда как многомерные модели оптимизированы для запроса данных и делают их бизнес-обоснованными. Ошибочно путать эти два понятия.

Answer 2

Ответом является очевидное НЕТ , согласно определению любая таблица, на которую ссылается внешний ключ из таблицы фактов , является таблицей измерений .

С другой стороны в модели Кимбалла нет строгой разделительной линии между фактами и измерениями - таблица может играть обе роли в зависимости от контекста.

Так, например, таблица, содержащая использование службы , представляет собой таблицу фактов с такими измерениями, как время , местоположение , контракт и т. д.

Но сам контракт может быть смоделирован как таблица фактов, т. Е. Таблица с транзакциями, которые изменяют контракт, и с такими измерениями, как время , клиент , рейтинг модели и т. Д. (Вы можете назвать это медленно меняющимся измерением - но это только альтернативное описание таблицы фактов).

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

Answer 3

ИМО, не должны, даже если могут. Таблицы фактов, как правило, огромные, с потенциально многими миллиардами строк и содержат измерения с определенным размером.

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

Если вам нужно связать факты в разных таблицах фактов (все измерения являются общими), лучше выполнить объединение только один раз, сохраняя результаты и используя вместо этого полученную таблицу. Еще лучше, если это можно сделать на уровне ETL, где вы можете присоединиться к пакету за пакетом.

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

Если ни один из наборов измерений не является надмножеством другого, вам может потребоваться агрегировать оба на общем уровне.

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

Наконец, помните, что DWH обычно имеет данные, загруженные процессами ETL. Они запускаются в пакетном режиме и могут проверять согласованность при каждом запуске, в отличие от OLTP, где предотвращение многократной записи одних и тех же данных имеет первостепенное значение для предотвращения несогласованности.

Мнения по этому вопросу различаются, и вы, скорее всего, получите разные мнения по этому вопросу. В конце концов, оба подхода имеют свои плюсы и минусы, изучите оба и выберите тот, который вам наиболее удобен.