星型架構設計/最佳實踐

Question

我有一個系統，它具有4個數據庫工作：

• 帳戶（存儲銀行賬戶，交易等）
• 客戶端（客戶端的相關信息）
• 信用（從第三方系統變得率）
• 質量（而且內部計算）

我想創建4個事實表，一個事實表對於每個數據庫......例如，我將擁有一個以ClientAccount，Transaction，Provider作爲其維度表的Account Fact表。其他數據庫我將有3個類似的事實表。

我的問題是：在數據庫中包含每個相應的事實表是否有意義？即在賬戶數據庫中創建會計事實和維度表？或者爲我們的所有星型模式創建一個新的數據庫更好，並將所有維度和事實表包含在他們自己的數據庫中？

Answer 1

除非您的數據量非常小，否則您的數據倉庫應該放置在與事務數據不同的數據庫中。 DW具有不同的使用模式（OLTP vs OLAP），並且通常具有不同的維護時段。

我建議在一個專用的DW數據庫中創建所有的Dims and Facts。我想不出有什麼好處把它們分開，它可以通過沒有額外的數據庫來管理/安全/審計/文檔來減少DBA的開銷。

至於Dimensions與Facts，來自OLTP Account表的數據將用於創建一個Dim和一個事實。 DimAccount至少是包含賬號的退化維。您必須查看您的數據，以確定其他任何記錄是否具體是該帳戶的通用屬性。 FactAccount將包含對其他尺寸的引用（DimAccountType，DimCustomer，DimLocation等）

將尺寸視爲查找表/下拉列表中的值，這些值是發生任何事件之前存在的值。例如，銀行可以提供檢查&儲蓄賬戶，即使他們還沒有任何賬戶。

事實記錄一個事件。創建帳戶時，事實記錄將引用描述該事件的所有維度，並記錄與該事件相關的可測量值（如果有）。

Answer 2

不知道太多的系統，我會建議這些是維表而不是事實表。 維度表表示可用於構造事實的實體或對象。帳戶和客戶似乎很適合這一點。我不確定什麼是信用和質量，但它們也可能是尺寸。

您的事實表應代表類似交易的記錄。這可能是銷售，交易，電話或任何數據倉庫的報告。然後這個事實表將具有到每個維度表的外鍵。

關於單個或多個數據庫：我建議將它存儲在單個數據庫中。使用這種方式更容易，在查詢數據時不必擔心數據庫鏈接。用於填充這些事實和維度表的ETL過程可以從這四個數據庫中提取數據並將其加載到一個數據庫中，然後從那裏將多維數據集構建到單個數據庫中。