具有多個事實表的數據倉庫的設計

Question

我是數據倉庫的新手。首先，我不想精確到Datawarehouse Toolkit的副本在我的郵箱中（snail mail：P）。但我已經在網上找到了所有這些東西。

但是，我不在網上找到，但是，當你似乎有一個以上的事實在DW中是做什麼。在我的情況下（保險），我退還了非定期發生的事件。一個客戶可以在3個月內沒有，然後在同一個月內沒有10個。另一方面，我有「訂閱費」（不確定什麼是正確的英文術語，但你明白了），每月或每三個月發生一次。這看起來很像我的兩個不同的事實。

這些也有些鬆散耦合的一些維度，如客戶端或「保險產品」。現在是這兩個不同的倉庫，我必須生成兩個不同的報告，然後連接DW之外的報告？或者有沒有一種方法來設計這個適合單個下降DW。或者我應該將這兩個事實合併爲一個？那麼我可能會鬆散退款的粒度。

有些博客我讀過說一個DW總是有一個事實表。其他人提到用S設計什麼是事實表的步驟，但是沒有明確的指示說明它們之間是否存在聯繫，或者它們只是同一個DW項目的不同組成部分。

有沒有人知道一些DW設計的精確部分的參考？

Answer 1

將您的問題向後推。

數據倉庫可以有多個事實表。但是，您確實想要最小化事實表之間的連接。可以在不同的事實表中複製事實信息。

您提到的物品有：

退款是事實。時間戳是退款事實的維度。

認購費是一個事實。時間戳是訂閱費用事實的維度。

退款可能會發生一次以上。我猜每個客戶都有一個訂閱費。所以目前看來我們有兩個事實表，客戶和客戶退款。

如果您知道最多隻能退款3次（例如），那麼您將取消客戶退款事實表，並將3個退款列放在客戶表中。

你還提到保險。客戶可以有多個策略。所以我們有第三個事實表。

數據倉庫通常使用star schema來設計。星型模式基本上是一個連接到一個或多個維度表的事實表。因爲我們已經定義了3個事實表，所以您可能會在數據倉庫中擁有多個明星。

Answer 2

只要你喜歡，你可以擁有儘可能多的事實表。在您的例子中，你可能會碰到這樣的：

dimProduct列出了幾種產品 - 訂閱是其中的一個。 dimTransactionType將列出可能的交易（購買，退款，定期訂閱費......）

現在假設你有興趣認購簡化報告，你可以添加一個factSubscription這樣的：

Answer 3

我意識到我正在回答一箇舊帖子，但我對所提供的答案都不滿意。我覺得沒有回答這個問題。

模式可以有一個或多個事實，但這些事實不通過任何關鍵關係鏈接。最好不要在單個查詢中加入事實表，因爲您會查詢規範化/事務數據庫。由於許多連接的性質等 - 如果嘗試結果將是不正確的。

您正在尋找的答案是您需要「鑽取」，這意味着您要分別查詢每個事實表（模式）併合並結果。這可以使用SQl或最好通過您可能擁有哪些引用數據倉庫的報告/分析工具進行。而不是重複上如何做到這一點的答案，我就直接給大家兩個非常好的文章：

Three ways to drill across by Chris Adamson

和

Should of the Warehouse - Drilling Across by Ralph Kimball