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