Проектирование хранилища данных с несколькими таблицами фактов
Я новичок в хранилищах данных. Во-первых, я хочу уточнить, чем находится моя копия набора инструментов хранилища данных на пути к моему почтовому ящику (обычная почта:P). Но я уже изучаю все это с тем, что нахожу в сети.
Однако в сети я не могу найти, что делать, когда у вас есть несколько фактов в DW. В моем случае (страхование) у меня есть возмещения, которые происходят нерегулярно. Один клиент не может иметь ни одного в течение 3 месяцев, а затем десять в те же месяцы. С другой стороны, у меня есть "абонентская плата" (не знаю, какой правильный английский термин, но вы понимаете, какой смысл), которая происходит каждый месяц или каждые три месяца. Мне кажется, что это два разных факта.
Эти два типа слабо связаны некоторыми измерениями, такими как клиент или "страховой продукт". Теперь это два разных хранилища, на которых мне нужно создать два разных отчета, а затем соединить отчеты за пределами DW? Или есть способ спроектировать это, чтобы соответствовать одному спуску DW. Или я должен объединить эти два факта в одном? Я бы, вероятно, потерял бы детализацию возврата.
В каком-то блоге, который я прочитал, говорится, что у DW всегда есть одна таблица фактов. Другие упоминают этап разработки таблиц фактов с помощью S, но нет четкой инструкции о том, существует ли связь между ними, или они являются просто отдельными компонентами одного и того же проекта DW.
Кто-нибудь знает некоторые ссылки на эту точную часть дизайна DW?
3 ответа
Принимая ваши вопросы задом наперед.
Хранилище данных может иметь более одной таблицы фактов. Однако вы хотите минимизировать объединения между таблицами фактов. Можно дублировать фактическую информацию в разных таблицах фактов.
Из объектов, которые вы упомянули:
Возврат факт. Отметка времени - это измерение факта возврата.
Абонентская плата является фактом. Отметка времени - это измерение факта платы за подписку.
Возврат может произойти более одного раза. Я предполагаю, что у каждого клиента есть одна абонентская плата. Итак, похоже, у нас есть две таблицы фактов: клиент и клиент.
Если вы знали, что может быть не более 3 возмещений (в качестве примера), то вы удалили бы таблицу фактов возмещения клиентов и поместили 3 столбца возмещения в таблицу клиентов.
Вы также упоминаете страхование. Клиент может иметь более одной политики. Итак, у нас есть третья таблица фактов.
Хранилище данных обычно проектируется с использованием звездообразной схемы. Схема "звезда" в основном представляет собой одну таблицу фактов, связанную с одной или несколькими таблицами измерений. Вы, вероятно, будете иметь более одной звезды в хранилище данных, так как мы уже определили 3 таблицы фактов.
Я понимаю, что отвечаю на старый пост, но меня не устраивает ни один из предоставленных ответов. Я чувствую, что ни один не ответил на вопрос.
Схема может иметь один или несколько фактов, но эти факты не связаны какими-либо ключевыми отношениями. Рекомендуется не объединять таблицы фактов в одном запросе, как при запросе к нормализованной / транзакционной базе данных. Из-за природы многих-многих объединений и т. Д. - результаты будут неверными, если попытаться.
Ответ, который вы ищете, заключается в том, что вам нужно "детализировать", что в основном означает, что вы запрашиваете каждую таблицу фактов (схему) отдельно и объединяете результаты. Это может происходить с использованием SQl или, предпочтительно, с помощью имеющегося у вас инструмента отчетности / аналитики, который ссылался на хранилище данных. Вместо того, чтобы дублировать ответы о том, как это сделать, я направлю всех к двум очень хорошим статьям:
Крис Адамсон: три способа бурения
а также
Вы можете иметь столько таблиц фактов, сколько захотите. В вашем примере у вас может быть что-то вроде:
В dimProduct перечислены несколько продуктов, в том числе подписка.dimTransactionType будет перечислять возможные транзакции (покупка, возврат, периодическая абонентская плата...)
Теперь предположим, что вы заинтересованы в упрощенной отчетности по подписке, вы можете добавить факт подписки следующим образом:
