維度建模是DW/BI系統的核心，他是ETL系統的目標、資料庫的結構、支援使用者查詢和製作報表的模型。建模要實現3個主要設計目標，分別是：能儘可能簡潔的向用戶展示需要的資訊；能儘快返回查詢結果給使用者；能提供相關資訊，以便精確的跟蹤潛在的業務過程。

維度建模能使任何事情儘可能簡單，但絕不是簡化。在資料倉庫和商業智慧中，維度模型是給使用者顯示資訊的首選結構，其比典型的原系統規範化模型更便於使用者理解。維度建模中表更少，資訊分組為對使用者有意義的、一致的業務類別。這些類別稱為維度，有助於使用者瀏覽模型，因為可以忽略與特定分析無關的全部類別。但是儘可能簡潔並不意味著模型一定簡單。模型必須反映業務，而業務通常都比較複雜，如果簡化的過多，一般來說只表示了聚合資料，模型就會丟失對理解業務非常重要的資訊。無論如何進行資料建模，資料內容在的複雜性都使大多數人最終願意通過結構化報表和分析應用程式來訪問DW和BI系統。

維度建模能提供更好的查詢效能，因為在建立維度時採用了反規範化的方法，通過預先連線各種層次結構和查詢表，優化程式考慮的連線路徑較少，建立的中間臨時表更少。

為了精確跟蹤潛在的業務過程，需要採用各種設計模式，以創建出精確捕獲和跟蹤業務模型。維度模型由一個或者多箇中心事實表和與其相關的維度構成。事實表位於中心，而維度環繞在其周圍，類似於星型結構，因此又把維度模型成為星型模型。

一、維度建模概念

1、事實表

事實表是維度模型的基本表，存放有大量的業務效能度量值。應力圖將從一個業務處理過程得到的度量值資料存放在單個數據中心。由於度量值資料壓倒性的成為任何資料中心的最大部分，因此應該避免在企業範圍內的不同地方儲存其拷貝。用術語“事實”代表一個業務度量值。例如：商品銷售記錄每個商店每種產品的銷售數量和銷售額。在各維度值（日期、產品和商店）的交叉點就可以得到一個度量值。維度值的列表給出了一個事實表的粒度定義，並確定出度量值的取值範圍是什麼。

事實表的設計中要解決幾個重要問題：

• 粒度（記錄事實的細節級）：事實表中包含資訊的詳細程度稱為粒度。強烈建議以原始來源中可能的最小細節級別構建事實表--通常稱為原子級別。原子事實表提供了完整的靈活性，資料可以累積到現在或將來任何維度需要的任何聚合級別。每個事實表必須只有一種粒度。例如，如果在同一事實表中包含每月預測項和單獨的銷售訂單項，就很容易引起混淆併產生危險。
• 相加性：事實的可加性是至關重要的，因為資料倉庫應用幾乎從不僅僅只檢索事實表的單行資料。相反，往往一次性帶回數百、數千乃至數百萬行的事實，並且處理這麼多行的最有用的事就是將它們加起來。但是有些事實是半加性質的，而另外一些是非加性質的。半加性事實僅僅沿某些維度相加，而非加性事實根本就不能相加。對於非加性事實，如果希望對其進行總結就不得不使用計數或平均數，或者降為一次一行的打印出全部事實行。對這長達數十億行的事實表來說，將是一個遲緩而乏味的工作。
• 文字度量值：度量事實在理論上可以是文字形式的，文字度量可以是某種事物的描述。但是設計者應該儘量將文字度量轉換成維度，原因在於維度能夠與其他文字維度屬性更有效關聯起來，並且消耗少的多的空間。不能將冗餘的文字資訊存放在事實表內。除非文字對於事實表的每行來說都是唯一的，負責他應該歸屬到維度表中。真正的文字事實在資料倉庫中很少出現，因為文字事實具有像自由文字內容那樣不可預見性，這幾乎是不可能進行分析的。
• 鍵選擇：多維資料建模中的鍵選擇是一個難題。它包含效能和易於管理之間的權衡（trade-off）。鍵選擇主要適用於維度。您為維度所選擇的鍵必須是事實的外來鍵。維度鍵有兩種選擇：您可以分配一個任意鍵，或者使用作業系統中的識別符號。任意鍵通常只是一個序列號，當需要一個新鍵時，就分配下一個可用的號碼。【為了使用作業系統中的識別符號惟一地表示維度，您有時需要使用一個複合鍵。複合鍵就是由多個列組成的鍵。任意鍵是一列，通常比操作派生的鍵要小。因此，任意鍵通常可以更快地執行連線。】【鍵選擇中的最後一個因素就是它對事實表的影響。在建立事實時，必須將每個維度的鍵分配給它。如果維度將帶有時間戳的操作派生的鍵用於歷史資料，那麼在建立事實時，就沒有附加工作。連線將自動發生。對於任意鍵或任意歷史識別符號，在建立事實時，就必須將一個鍵分配給事實。】【分配鍵的方式有兩種。一種就是維護操作和資料倉庫的鍵的轉換表。另一種就是儲存操作鍵，並且在必要時，儲存時間戳作為維度上的屬性資料。】【那麼，選擇就在任意鍵的更好效能和操作鍵的更易維護之間進行。效能提高多少和維護增加多少的問題就必須在您自己的組織中進行評估了。】【無論做出什麼選擇，都必須在元資料中用文件記錄生成它們的過程。該資訊對於管理和維護資料倉庫的技術人員來說是必要的。如果您所使用的工具沒有隱藏連線處理，那麼使用者可能也需要理解這一點。】

2、維度表

維度表包含有業務的文字描述。在一個設計合理的維度模型中，維度表有許多列或者屬性，這些屬性給出對維度表的行所進行的描述。維度表傾向於將列數做的特別大，每個維度用單一的主關鍵字進行定義，主關鍵字是確保同與之相連的任何事實表之間存在應用完整性的基礎。

維度屬性是查詢約束條件、成組與報表標籤生成的基本來源。例如，一個使用者要按照“星期”和“商標”來檢視銷售額，那麼“星期”與“商標”就必須是可用的維度屬性。資料倉庫的能力直接與維度屬性的質量和深度成正比。在提供詳細的業務用語屬性方面所化的時間越多，資料倉庫就越好。在屬性列值的給定方面所花的時間越多，資料倉庫就越好。在保證屬性列值的質量方面所花的時間越多，資料倉庫就越好。

最好的屬性是文字的和離散的。屬性應該是真正的文字而不應是一些編碼簡寫符號。例如：對於產品來說，典型的屬性應該包括一個短描述、一個長描述、一個商標名、一個分類名、包裝型別、尺寸以及大量其他產品特徵等方面的內容。

維度表時常描述業務中的層次關係。例如：產品劃分為商標、然後是分類。產品維度的每行都存放有與產品有關的商標和分類。但是存放層次描述資訊顯得很冗餘， 不過也是基於容易使用和查詢效能方面的考慮才這樣做的。不要受僅僅儲存商標編碼併為其建立一個單獨的商標查詢表的固有想法所限制，這種形式可以稱為雪花。維度表一般是很不規範的，通常也非常小。既然維度表一般都很小，通過規範化或者雪花來提高儲存效率的做法也起不了大作用，所以實際應用中，幾乎總是用維度表的空間來換取簡明性和可訪問性。

3、事實與維度的融合

由數字型度量值組成的事實表連線到一組填滿描述屬性的維度表上。這個星型特徵結構通常被叫做星型連線方案。關於維度方案，應該注意第一件事就是其簡明性與對稱性。簡明性是指使用者可以很容易的理解和瀏覽資料；簡明性也提升了效能上的好處，倉庫在處理時首先對維度表進行過濾處理，然後用滿足使用者約束條件的維度表關鍵字的笛卡爾乘積一次性處理全部的事實表。

維度表模型能夠很自然的進行擴充套件以適應變化的需求。維度模型的可預訂框架能夠經受住無法預見的使用者行為變化所帶來的考驗。每個維度都是平等的，所有維度都是進入事實表的對等入口。每個邏輯模型不存在內建的關於某種期望的查詢形式方面的偏向，不存在這個月要問的業務問題相對於下個月來說具有優化方面的考慮。沒有誰希望，如果業務使用者採用新的方式進行業務分析，就要調整設計方案這樣的事情發生。維度模型的事實與維度表如下：

在設計過程中，最佳粒度或者原子資料具有最佳的維度。被聚合起來的原子資料是最有表現力的資料。原子資料應該成為每個事實表設計的基礎。從而經受住業務使用者無法預見的查詢所引起的特別攻擊。對於維度模型來說，完全可以向方案中加入新的維度，只要其值對於每個現有的事實行存在唯一性定義就行。同樣，可以向事實表加入新的不曾預料到的事實，只要其詳細程度與現有事實表處在一致的水平面上就可以了。可以用新的不曾預料到的屬性補充先前存在的維度表，也可以從某個前向時間點的角度在一個更低的粒度層面上對現存維度進行分解。在每種情況下，可以簡單的在表中加入新的資料行或者對現在表進行適當的修改。

認識事實與維度表之間互補性的另外一種方式是在所形成的報表中瞭解他們。如上圖，維度屬性提供了生成報表標籤的內容，而事實表則提供了報表的數字型取值。

最後就像已經強調的那樣，展示環節的資料應該是維度形式的。不過，維度模型與規範化模型之間存在著一種自然的關係。理解這種關係的關鍵在於認識到，單個規範化ER圖通常分解為多個維度方案。為機構建立的大型規範化模型可以將電話銷售、訂購單、裝貨發票、顧客付款、產品利潤等內容全部放在一個圖中。在某種程度上講，規範化ER圖對自身就是一種傷害，原因在於他將許多從來就不會出現在單個數據集中的多個業務處理放在了單張繪製圖中。可見，規範化模型看起來很複雜，是不足為奇的。

如果有一張已經存在的規範化ER圖，將它轉換為一組維度模型的第一步是，將ER圖分成一些分散的業務處理過程，然後分別單獨建模。第二步是選出ER圖中那些含有數字型與可加性非關鍵字事實的多對多關係，並將他們標記為事實表。最後一步是，將剩下的所有表複合成具有直接連線到事實表的單連關鍵字的平面表，這些表就成為維度表。

二、維度建模的設計過程

維度建模具有一定順序，分別是：①業務處理②粒度③維度④事實。

1、選取業務處理

業務處理過程是機構中進行的一般都是有源系統提供支援的自然業務活動。聽取使用者的意見是選取業務處理過程的效率最高的方式。在選取業務階段，資料模型設計者需要有全域性和發展的視角，應該理解整體業務流程的基礎上，從全域性角度選取業務處理。

要記住的重要一點是，這裡談到的業務處理並不是指業務部門或者職能。通過將注意力集中放在業務處理過程方面，就能在機構範圍內更加經濟的提交一致的資料。如果建立的維度模型是同部門捆綁在一起的，就無法避免出現具有不同標記與術語的資料拷貝的可能性。多重資料流向單獨的維度模型，會使使用者在應付不一致性的問題方面顯得很脆弱。確保一致性的最佳辦法是對資料進行一次性的釋出。單一的釋出過程還能減少ETL的開發量，以及後續資料管理和磁碟儲存方面的負擔。

2、定義粒度

粒度定義意味著對各事實錶行，實際代表的內容給出明確的說明。粒度傳遞了同事實表度量值相聯絡的細節所達到的程度方面的資訊。他給出了後面這個問題的答案“如何描述事實表的單個行？”

粒度定義是不容輕視的至關重要的步驟。在定義粒度時應優先考慮為業務處理獲取最有原子性的資訊而開發維度模型。原子性資料是所收集的最詳細的資訊，這樣的資料不能再做更進一步的細分。通過在最低層面上裝配資料，大多原子粒度在具有多個前段的應用場合顯示出其價值所在。原子型資料是高度維結構化的。事實度量值越細微並具有原子性，就越能夠確切的知道更多的事情，所有那些確切知道的事情都轉換為維度。在這點上，原子型資料可以說是維度方法的一個極佳匹配。

原子型資料可為分析方面提供最大程度的靈活性，因為他可以接受任何可能形式的約束，並可以以任何可能的形式出現。維度模型細節性資料是穩如泰山的，並隨時準備接受業務使用者的特殊攻擊。

當然，可以總是給業務處理定義較高層面的粒度，這種粒度表示最具有原子性的資料的聚集。不過，只要選取較高層面的粒度，就意味著將自己限制到更少或者細節性可能更小的維度上了。具有較少粒度性的模型容易直接遭到深入到細節內容的不可預見的使用者請求的攻擊。聚集概要性資料作為調整的一種手段起著非常重要的作用，但他絕不能作為使用者存取最底層面細節內容的替代品。遺憾的是，有些權威人士在這方面一直含糊不清，他們宣稱維度模型只適合於總結性資料，並批判那些認為維度建模方法可以滿足預測業務需求的看法。這樣的誤解會隨著細節性的原子型資料在維度模型中的出現而慢慢的消失。

3、選定維度

維度所引出的問題是：“業務人員將如何描述從業務處理過程得到的資料？”。應該用一組在每個度量上下文中取單一值而代表了所有可能情況的豐富描述，將事實表裝扮起來。如果對粒度方面的內容很清楚，那麼維度的確定一般是非常容易的。通過維度的選定，可以列出那些使每個維度表豐滿起來的離散的文字屬性。常見的例子包括：日期、產品、客戶、賬戶和機構等。

4、確定事實

他是設計過程的第四步也是最後一步，在於仔細確定那些事實要在事實表中出現。事實的確定可以通過回答“要對什麼內容進行評測”這個問題來進行。業務使用者在這些業務處理效能度量值的分析方面有濃厚的興趣。設計中所有供選取的資訊必須滿足在第2步中定義的粒度要求。明顯屬於不同粒度的事實必須放在單獨的事實表中。通常可以從以下三個角度來建立事實表：

• 針對某個特定的行為動作，建立一個以行為活動最小單元為粒度的事實表。最小活動單元的定義，依賴於分析業務需求。比如使用者的一次網頁點選行為、一次網站登入行為，一次電話通話記錄。這種事實表，主要用於從多個維度統計，行為的發生情況，主要用於業務分佈情況，績效考核比較等方面的資料分析。
• 針對某個實體物件在當前時間上的狀況。我們通過對這個實體物件在不同階段儲存他的快照，比如使用者的餘額、使用者擁有的產品數等。通過這種可以統計實體在不同生命週期中的關鍵數量指標。
• 針對業務活動中的重要分析和跟蹤物件，統計在整個企業不同業務活動中的發生情況。比如會員，可以執行或參與多個特定的行為活動。這種事實表是以上兩種事實表的一個總計和歸納。它主要用於針對我們業務中的活動物件進行跟蹤和考察。

三、資料倉庫匯流排結果

業務與IT機構一般都對不同的業務處理過程的整合很感興趣。低級別業務分析師在這方面的願望可能並不是很迫切，單那些處於較高管理階層的人員非常清楚，在跨業務的範圍內進行資料的檢視對於提高評估效能是很必要的。眾多的資料倉庫專案將注意力放在從終端到終端的視角，更好的理解顧客關係的管理需求方面了。如下圖，在某大型國有銀行中，業務價值的產品運營中，包含許多相關的業務處理，如營銷支援、產品運營、風險管控、財務績效等諸多業務管理。

如果針對這些業務處理分別進行維度建模、建立獨立資料集市，資料集市之間沒有共享公共維度，那麼就會出現問題，資料集市就會變成獨立的集市，不能組合成資料倉庫，而一致性維度的提出正是為了解決這個問題。如下圖給出了這種維度共享情形的邏輯表示形式。

共享公共的維度對於設計可以進行整合的資料集市來說，具有絕對的決定性作用。這樣做使得來自不同處理的效能度量值可以被組合到單個報表中去。具體的實現過程是，使用多通路的SQL單獨查詢各個集市，然後基於共同的維度屬性對查詢結果施加外連線。這個通常稱作交叉探查（Drill Across）的連線，在維度屬性具有一致性的情況下是很直接的。

將一組分佈在各處的有關業務處理成一個綜合的資料倉庫來說，匯流排結構師最基本的要素。

1、資料倉庫匯流排結構

很顯然，想一個步驟就建成企業資料倉庫太令人望而生畏。然而，將它分成獨立的片段進行建造又會挫敗一致性這個壓倒一切的目標。要使資料倉庫能夠長期的成功運轉，很需要有一種在體系結構上可以按照增量方式建造企業資料倉庫的方法。這裡提倡使用的一種方法就是資料倉庫匯流排結構。

通過為資料倉庫環境定義標準的匯流排介面，獨立的資料集市就可以由不同的小組在不同的時間進行實現。只要遵循這個標準，獨立的資料集市就可以插入到一起並有效的共存。所有業務處理將建立一個維度模型系列，這些模型共享一組綜合的具有一致性的共用維度。如下圖

資料倉庫匯流排結構提供了一種可以用於分解企業資料倉庫規劃任務的合理方法。在體系結構確立階段的較短時間內，開發團隊設計出一整套在企業範圍內具有統一解釋的標準化維度和事實。這樣，資料體系結構的框架就建立起來了。然後，開發團隊可以全力以赴實現嚴格依照體系結構進行迭代開發的獨立資料集市。隨著獨立資料集市的投入使用，他們就像積木塊一樣搭在一起。在某種意義上講，需要存在足夠的資料集市才可能為整合的企業資料倉庫帶來美好的前景。

匯流排結構使資料倉庫管理人員獲取兩個方面的優勢。一方面，他們有了指導總體設計的體系框架，並且將問題分成了可以根據具體時限加以實施的以位元組計量的資料集市塊。另一方面，各資料集市開發團隊遵照體系指南，可以相對獨立的非同步開展工作。

2、一致性維度

在瞭解匯流排結構的重要性以後，現在可以進一步開發發揮資料匯流排奠基石作用的一致性維度。一致性維度要麼是統一的，要麼是具有最佳粒度性與細節性的維度在嚴格數學意義上的子集。例如：如果建立月維度，月維度的各種描述必須與日維度中的完全一致，最常用的做法是在日維度上建立檢視生成月維度。這樣月維度就可以是日期維度的子集，在後續鑽取操作時可以保持一致。

一致的維度具有一致的關鍵字、一致的屬性列名字、一致的屬性定義以及一致的屬性值。如果屬性標籤的記錄不同或者包含不同的值，維度表就不是一致的。如果客戶或者產品維度是按照非一致的方式進行配置的，那麼，要麼分散的資料集市不能在一起使用，要麼更為嚴重的是，檢視將他們用在一起將產生無效的結果。

一致的維度以幾種不同的樣式出現。在最基本的層次上，一致的維度意味著與同他們相連線的每種可能的事實表具有完全相同的內容。連線到產品服務簽約的事實上的日期維度與連線到產品服務賬戶餘額事實上的日期維度表是統一的。實際上，一致的維度在資料庫範圍內可能就是相同的物理表。不過，基於對配有多種資料庫平臺的資料倉庫技術環境的典型複雜性的考慮，維度更有可能同時在每個資料集市都存在拷貝。在其中任何一種情況下，兩個資料集市的日期維度都將具有相同的行、相同的關鍵字值、相同的屬性標籤、相同的屬性定義與相同的屬性值等。同樣，也存在一致的資料內容、資料解釋與使用者展示。

3、一致性事實

通常，像利潤、經濟資本、產品覆蓋度、客戶滿意度以及其他關鍵性指標（KPI）需要在企業級共享的度量指標，都是必須保持一致性的事實。一般的說，事實表資料並不在各個資料集市之間明確的進行拷貝。不過，如果事實確實存在於多個位置，那麼支撐這些事實的定義與方程都必須是相同的，假如將他們當做同種事物看待的話，如果這些事實具有相同地 標記，那麼需要在相同維度環境下對他們進行定義，同時使其在各個資料集市之間具有相同的度量單位。必須在資料命名實踐中接受規範的約束，如果不可能做到使事實完全一致，那麼應該對不同的解釋給出不同的名稱。這樣可以減少計算中使用不相容的事實的可能性。