Дизайн хранилища данных с более чем одним фактором столов

Question

Я новичок в хранилище данных. Во-первых, я хочу точно, чем моя копия хранилища данных Toolkit находятся на пути к моему почтовому ящику (Snail Mail: P). Но я уже изучаю все эти вещи с тем, что я нахожу в сети.

То, что я не нахожу в сети, однако, что делать, когда у вас есть более одного факта в DW. В моем случае (страхование) у меня возмещение, которые происходят на не регулярной основе. Один клиент может иметь ни одного в течение 3 месяцев, а затем десять в те же месяцы. С другой стороны, у меня есть «плата за подписку» (не уверена, что является правильным английским термином, но вы получаете точку), которые происходят каждый месяц или каждые три месяца. Это кажется явно как две различные факты для меня.

Эти два разноятно связаны с некоторыми размерами, как клиент или «страховой продукк». Теперь эти два разных склада, на которых я должен производить два разных отчетах, а затем подключить отчеты за пределами DW? Или есть ли способ создать это, чтобы соответствовать одному спуску DW. Или я должен объединить эти два факта в одном? Я бы, вероятно, потеряю гранулярность на возврате тогда.

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

Кто-нибудь знает некоторые ссылки на точную часть DW Design?

Answer 1

Принимая ваши вопросы назад.

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

от объектов, которые вы упомянули:

Возврат - это факт. Timestamp - это размер факта возврата.

Плата за подписку - это факт. Timestamp - это размерность платы за подписку.

Возврат может произойти более одного раза. Я предполагаю, что у каждого клиента есть одна абонентская плата. Таким образом, кажется, что у нас пока есть два фактах, клиент и возврат клиентов.

Если вы знаете, что там могут быть только в большинстве 3 возврата (в качестве примера), то вы бы устранили таблицу фактов возврата клиентов и поместили 3 столбцы возврата в таблицу клиентов.

Вы также упомянули страховку. У клиента может быть более одной политики. Поэтому у нас есть третий стол факта.

Склад данных обычно разработан с использованием Звездная схема . Звездная схема в основном является одной фактом, подключенная к одному или нескольким таблицам измерений. Вы, вероятно, будете иметь более одной звезды на хранилище данных, поскольку мы уже определили 3 таблицы фактов.

Answer 2

Я понимаю, что отвечаю на старый пост, но я не удовлетворен любой из предоставленных ответов. Я чувствую, что ни один не ответил на вопрос.

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

Ответ, который вы ищете, так это то, что вам нужно «сверлить», в котором в основном означает, что вы запрашиваете каждый стол факта (схема) отдельно и объединяете результаты. Это может происходить с использованием SQL или предпочтительно через инструмент отчетности / аналитики, который у вас может быть, который ссылается на хранилище данных. Вместо того, чтобы дублировать ответы на то, как это сделать, я буду направлять всех до двух очень хороших статей:

Три способа сверлить Крис Адамсон

и

должен Склада - бурение через Ralph Kimball

Answer 3

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

<Сильный> DimProduct Перечисляет несколько продуктов - подписка, являющаяся одним из них. dimtransactiontype Перечислите возможные транзакции (покупка, возврат средств, рецидивирующая подписка ...)

Теперь предположим, что вы заинтересованы в упрощенной отчетности подписки, вы можете добавить factsubscription , как это: