是規範化還是非規範化形式的事實表？

Question

我在事實表上做了一些R & D，無論它們是標準化的還是非標準化的。 我遇到了一些讓我困惑的發現。

根據Kimball：

三維模型結合規範化和非規範化表結構。描述性信息的維度表在相同表中具有高度非規範化的細節和分層累積屬性。同時，具有性能指標的事實表通常被標準化。儘管我們建議不要在單獨的表中爲完全標準化的雪花尺寸屬性（爲商業用戶創建類似於暴風雪的條件），但同一個表中包含度量和描述的單個非規範化大寬表也是不明智的。

其他發現，這也是我，我認爲是好的，by fazalhp at GeekInterview：

DW的主要豐達被解歸一化數據，以供報表工具更快速的訪問...因此，如果烏爾建立一個DW.90％它必須被去標準化，並且當然事實表必須被標準化...

所以我的問題是，事實表是標準化還是非標準化？如果其中任何一個如何&爲什麼？

Answer 1

從關係數據庫設計理論的角度來看，維度表通常在2NF和6NF之間的任何地方都是2NF和事實表。

然而，三維建模是methodology你們自己，量身定製：

• 一個用例，即報告查詢

• 主要是一個基本類型（模式）

• 一個主要用戶類別 - 業務分析師或類似

• 像Oracle，SQl服務器，Postgres一樣的行存儲RDBMS ...

• 一個獨立控制的加載/更新過程（ETL）;所有其他客戶端都只讀

還有其他DW設計方法在那裏，像

• Inmon的 - 數據結構驅動

• 數據存儲庫 - 數據結構驅動

• 錨點建模 - 架構演變驅動

最重要的不是混淆數據庫設計理論與特定的設計方法。您可以通過數據庫設計理論的角度來看待某種方法，但必須分別研究每種方法。

Answer 2

大多數使用數據倉庫的人都熟悉事務性RDBMS並應用各種標準化級別，因此這些概念用於描述工作星型模式。他們正在做的是試圖讓你忽略所有這些規範化習慣。這可能會讓人困惑，因爲有一種傾向於專注於「不」做的事情。

事實表可能是最規範化的，因爲它們通常只包含數值以及用於鏈接到維度的各種ID。他們使用事實表的關鍵在於您需要如何獲取數據。 「採購」示例可以是訂單中產品的特定訂單項，也可以是每日，每週，每月的彙總數。

我的建議是繼續搜索和研究如何根據您的需求設計倉庫。不要期望達到高水平的規範化形式。仔細考慮要生成的報告和分析功能，以便爲用戶提供幫助。