圖中的訂單表就是一個事實表，你可以理解他就是在現實中發生的一次操作型事件，我們每完成一個訂單，就會在訂單中增加一條記錄。事實表的特征：表里沒有存放實際的內容，他是一堆主鍵的集合，這些ID分別能對應到維度表中的一條記錄。事實表包含了與各維度表相關聯的外鍵，可與維度表關聯。事實表的度量通常是數值類型，且記錄數會不斷增加，表數據規模迅速增長。

明細表（寬表）：

事實表的數據中，有些屬性共同組成了一個字段（糅合在一起），比如年月日時分秒構成了時間，當需要根據某一屬性進行分組統計的時候，需要截取拼接之類的操作，效率極低。如：

local＿time2021－03－18 06：31：42

為了分析方便，可以事實表中的一個字段切割提取多個屬性出來構成新的字段，因為字段變多了，所以稱為寬表，原來的成為窄表。

將上述的local＿time字段擴展為如下6個字段：

yearmonthdayhourms20210318063142

又因為寬表的信息更加清晰明細，所以也可以稱之為明細表。

2．維度表

每個維度表都包含單一的主鍵列。維度表的主鍵可以作為與之關聯的任何事實表的外鍵，當然，維度表行的描述環境應與事實表行完全對應。維度表通常比較寬，是扁平型非規范表，包含大量的低粒度的文本屬性。

維度表示你要對數據進行分析時所用的一個量，比如你要分析產品銷售情況， 你可以選擇按類別來進行分析，或按區域來分析。每個類別就構成一個維度。事實表的圖中的用戶表、商家表、時間表這些都屬于維度表，這些表都有一個唯一的主鍵，然后在表中存放了詳細的數據信息。

總的說來，在數據倉庫中不需要嚴格遵守規范化設計原則。因為數據倉庫的主導功能就是面向分析，以查詢為主，不涉及數據更新操作。事實表的設計是以能夠正確記錄歷史信息為準則，維度表的設計是以能夠以合適的角度來聚合主題內容為準則。

2． 維度建模三種模式

1． 星型模式

星形模式（Star Schema）是最常用的維度建模方式。星型模式是以事實表為中心，所有的維度表直接連接在事實表上，像星星一樣。星形模式的維度建模由一個事實表和一組維表成，且具有以下特點：a． 維表只和事實表關聯，維表之間沒有關聯；b． 每個維表主鍵為單列，且該主鍵放置在事實表中，作為兩邊連接的外鍵；c． 以事實表為核心，維表圍繞核心呈星形分布；

2． 雪花模式

雪花模式（Snowflake Schema）是對星形模式的擴展。雪花模式的維度表可以擁有其他維度表的，雖然這種模型相比星型更規范一些，但是由于這種模型不太容易理解，維護成本比較高，而且性能方面需要關聯多層維表，性能也比星型模型要低。所以一般不是很常用

雪花模式

3．星座模式

星座模式是星型模式延伸而來，星型模式是基于一張事實表的，而星座模式是基于多張事實表的，而且共享維度信息。前面介紹的兩種維度建模方法都是多維表對應單事實表，但在很多時候維度空間內的事實表不止一個，而一個維表也可能被多個事實表用到。在業務發展后期，絕大部分維度建模都采用的是星座模式。

星座模型

3． 維度建模過程

我們知道維度建模的表類型有事實表，維度表；模式有星形模型，雪花模型，星座模型這些概念了，但是實際業務中，給了我們一堆數據，我們怎么拿這些數據進行數倉建設呢，數倉工具箱作者根據自身60多年的實際業務經驗，給我們總結了如下四步，請務必記住！

數倉工具箱中的維度建模四步走：

維度建模四步走

請牢記以上四步，不管什么業務，就按照這個步驟來，順序不要搞亂，因為這四步是環環相扣，步步相連。下面詳細拆解下每個步驟怎么做

1、選擇業務過程

維度建模是緊貼業務的，所以必須以業務為根基進行建模，那么選擇業務過程，顧名思義就是在整個業務流程中選取我們需要建模的業務，根據運營提供的需求及日后的易擴展性等進行選擇業務。比如商城，整個商城流程分為商家端，用戶端，平臺端，運營需求是總訂單量，訂單人數，及用戶的購買情況等，我們選擇業務過程就選擇用戶端的數據，商家及平臺端暫不考慮。業務選擇非常重要，因為后面所有的步驟都是基于此業務數據展開的。

2、聲明粒度

先舉個例子：對于用戶來說，一個用戶有一個身份證號，一個戶籍地址，多個手機號，多張銀行卡，那么與用戶粒度相同的粒度屬性有身份證粒度，戶籍地址粒度，比用戶粒度更細的粒度有手機號粒度，銀行卡粒度，存在一對一的關系就是相同粒度。為什么要提相同粒度呢，因為維度建模中要求我們，在同一事實表中，必須具有相同的粒度，同一事實表中不要混用多種不同的粒度，不同的粒度數據建立不同的事實表。并且從給定的業務過程獲取數據時，強烈建議從關注原子粒度開始設計，也就是從最細粒度開始，因為原子粒度能夠承受無法預期的用戶查詢。但是上卷匯總粒度對查詢性能的提升很重要的，所以對于有明確需求的數據，我們建立針對需求的上卷匯總粒度，對需求不明朗的數據我們建立原子粒度。

3、確認維度

維度表是作為業務分析的入口和描述性標識，所以也被稱為數據倉庫的“靈魂”。在一堆的數據中怎么確認哪些是維度屬性呢，如果該列是對具體值的描述，是一個文本或常量，某一約束和行標識的參與者，此時該屬性往往是維度屬性，數倉工具箱中告訴我們牢牢掌握事實表的粒度，就能將所有可能存在的維度區分開，并且要確保維度表中不能出現重復數據，應使維度主鍵唯一

4、確認事實

事實表是用來度量的，基本上都以數量值表示，事實表中的每行對應一個度量，每行中的數據是一個特定級別的細節數據，稱為粒度。維度建模的核心原則之一是同一事實表中的所有度量必須具有相同的粒度。這樣能確保不會出現重復計算度量的問題。有時候往往不能確定該列數據是事實屬性還是維度屬性。記住最實用的事實就是數值類型和可加類事實。所以可以通過分析該列是否是一種包含多個值并作為計算的參與者的度量，這種情況下該列往往是事實。

實際業務中數倉分層

數倉分層要結合公司業務進行，并且需要清晰明確各層職責，要保證數據層的穩定又要屏蔽對下游影響，一般采用如下分層結構：

數據分層架構數據層具體實現

使用四張圖說明每層的具體實現

數據源層ODS

數據源層

數據源層主要將各個業務數據導入到大數據平臺，作為業務數據的快照存儲。

數據明細層DW

數據明細層

事實表中的每行對應一個度量，每行中的數據是一個特定級別的細節數據，稱為粒度。要記住的是同一事實表中的所有度量必須具有相同的粒度。

維度表一般都是單一主鍵，少數是聯合主鍵，注意維度表不要出現重復數據，否則和事實表關聯會出現數據發散問題。

有時候往往不能確定該列數據是事實屬性還是維度屬性。記住最實用的事實就是數值類型和可加類事實。所以可以通過分析該列是否是一種包含多個值并作為計算的參與者的度量，這種情況下該列往往是事實；如果該列是對具體值的描述，是一個文本或常量，某一約束和行標識的參與者，此時該屬性往往是維度屬性。但是還是要結合業務進行最終判斷是維度還是事實。

數據輕度匯總層DM

數據輕度匯總層

此層命名為輕匯總層，就代表這一層已經開始對數據進行匯總，但是不是完全匯總，只是對相同粒度的數據進行關聯匯總，不同粒度但是有關系的數據也可進行匯總，此時需要將粒度通過聚合等操作進行統一。

數據應用層APP

數據應用層

數據應用層的表就是提供給用戶使用的，數倉建設到此就接近尾聲了，接下來就根據不同的需求進行不同的取數，如直接進行報表展示，或提供給數據分析的同事所需的數據，或其他的業務支撐。

最后

技術是為業務服務的，業務是為公司創造價值的，離開業務的技術是無意義的。所以數倉的建設與業務是息息相關的，公司的業務不同，數倉的建設也是不同的，只有適合的才是最好的。