維度建模的基本概念及過程
摘要：本文首先介紹維度模型中的維度表和事實表這2個基本構成要素的基礎知識；其次，介紹設計維度模型的4個基本步驟；再次，圍繞某銀行爲實現業務價值鏈數據集成的需要，介紹多維體系結構中的3個關鍵性概念：數據倉庫總線結構、一致性維度、一致性事實。
關鍵詞：維度表;事實表;維度模型設計過程;數據倉庫總線結構;一致性維度;一致性事實。
0 引言
與流行的說法不同，Ralph Kimball本人並沒有定義“維度”和“事實”這樣的術語。術語“維度”與“事實”，最初是20世紀60年代在一個由General Mills與Dartmouth大學主持的聯合研究計劃中提出的。70年代，AC Nielsen和IRI都一致地使用這些術語描述他們的數據發佈應用，用現在更爲準確的話來說，就是關於零售數據的維度數據集市（Data Mart）。在簡明性成爲生活方式的潮流之前的長時期內，早期的數據庫壟斷組織們致力於將這些概念用來簡化用做分析的信息。他們意識到，除非數據庫做得簡單易用，否則沒有人會用它。因此，在將可理解性和性能作爲最高目標的驅動下，產生了維度模型的構造思想。
1 維度表和事實表
1.1 事實表
事實表是維度模型的基本表，其中如圖1.1所示存放有大量的業務性能度量值。力圖將從一個業務處理過程得到的度量值數據存放在單個數據集市。由於度量值數據壓倒性地成爲任何數據集市的最大部分，因此應該避免在企業範圍內的不同地方存儲其拷貝。用術語“事實”代表一個業務度量值。可以設想一個作爲例子的情形：查詢某個客戶在某個機構下某個產品合約賬戶的某個幣種的某個時點餘額，在各維度值(客戶、產品合約、賬戶、機構、幣種、日期)的交點處就可以得到一個度量值。維度值的列表給出了事實表的粒度定義，並確定出度量值的取值範圍是什麼。
圖 1.1 示例事實表
事實表的一行對應一個度量值，一個度量值就是事實表的一行；事實表的所有度量值必須具有相同的粒度。最有用的事實是諸如賬戶餘額這樣的數字類型爲可做加法的事實。可加性是至關重要的，因爲數據倉庫應用不僅僅只檢索事實表的單行數據。相反，往往一次性帶回數百、數千乃至數百萬行的事實，並且處理這麼多行的最有用的事就是將它們加起來。
當然，有些事實是半加性質的，而另外一些是非加性質的。半加性事實僅僅沿某些維度相加，例如銷售佔比，週期餘額；而非加性事實根本就不能相加，例如狀態。對於非加性事實，如果希望對行進行總結就不得不使用計數或平均數，或者降爲一次一行地打印出全部事實行。
度量事實在理論上講可以是文本形式的，不過這種情況很少出現。在大多數情況下，文本度量值可以是某種事物的描述並取自某個離散列表的值。設計者應該盡各種努力將文本度量值轉換成維度，原因在於維度能夠與其他文本維度屬性更有效地關聯起來，並且消耗少得多的空間。不能將冗餘的文本信息存放在事實表內。除非文本對於事實表的每行來說都是唯一的，否則它應該歸屬到維度表中。真正的文本事實在數據倉庫中是很少出現的，文本事實具有像自由文本內容那樣的不可預見性內容，這幾乎是不可能進行分析的。
所有事實表有兩個或者兩個以上的外關鍵字(如圖1.1中FK符號標記的部分)，外關鍵字用於連接到維度表的主關鍵字。例如，事實表中的“產品合約關鍵字”總是匹配產品合約維度表的一個特定“產品合約關鍵字”。如果事實表中的所有關鍵字都能分別與對應維度表中的主關鍵字正確匹配，就可以說這些表滿足引用完整性的要求。事實表要通過與之相連的維度表進行存取。
事實表根據粒度的角色劃分不同，可分爲事務事實表、週期快照事實表、累積快照事實表。事務事實表用於承載事務數據，通常粒度比較低，例如產品交易事務事實、ATM交易事務事實；週期快照事實表用來記錄有規律的、固定時間間隔的業務累計數據，通常粒度比較高，例如賬戶月平均餘額事實表；累積快照事實表用來記錄具有時間跨度的業務處理過程的整個過程的信息，通常這類事實表比較少見。這裏需要值得注意的是，在事實表的設計時，一定要注意一個事實表只能有一個粒度，不能將不同粒度的事實建立在同一張事實表中。
1.2 維度表
維度表是事實表不可分割的部分。如圖1.2所示，維度表包含有業務的文字描述。在一個設計合理的維度模型中，維度表有許多列或者屬性，這些屬性給出對維度表的行所進行的描述。應該儘可能多地包括一些富有意義的文字性描述。對於維度表來說，包含50到100個屬性的情形並不少見。維度表傾向於將行數做得相當少(通常少於100萬行)，而將列數做得特別大。每個維度用單一的主關鍵字(如圖1.2中PK符號標記的部分)進行定義，主關鍵字是確保同一與之相連的任何事實表之間存在引用完整性的基礎。
圖1.2 示例維度表
維度屬性是查詢約束條件、成組與報表標籤生成的基本來源。在查詢與報表請求中，屬性用by這個單詞進行標識。例如，一個用戶表示要按“產品合約編號”與“機構編號”來查看賬戶餘額，那麼“產品合約編號”與“機構編號”就必須是可用的維度屬性。
維度表屬性在數據倉庫中承擔着一個重大的角色。由於它們實際上是所有令人感興趣的約束條件與報表標籤的來源，因此成爲使數據倉庫變得易學易用的關鍵。在許多方面，數據倉庫不過是維度屬性的體現而已。數據倉庫的能力直接與維度屬性的質量和深度成正比。在提供詳細的業務用語屬性方面所花的時間越多，數據倉庫就越好。在屬性列值的給定方面所花的時間越多，數據倉庫就越好。在保證屬性列值的質量方面所花的時間越多，數據倉庫就越好。
維度表是進入事實表的入口。豐富的維度屬性給出了豐富的分析切割能力。維度給用戶提供了使用數據倉庫的接口。最好的屬性是文本的和離散的。屬性應該是真正的文字而不應是一些編碼簡寫符號。應該通過用更爲詳細的文本屬性取代編碼，力求最大限度地減少編碼在維度表中的使用。有時候在設計數據庫時並不能很確定，從數據源析取出的一個數字型數據字段到底應該作爲事實還是維度屬性看待。通常可以這樣來做出決定，即看字段是一個含有許多的取值並參與運算的度量值(當事實看待)，還是一個多少變化不多並參與作爲約束條件的離散取值的描述(當維屬性看待)。
在維度類型中，有一種重要的維度稱作爲退化維度(Degenerate Dimension)，這種維度指的是直接把一些簡單的維度放在事實表中而不專門去做一個維度表。退化維度是維度建模領域中的一個非常重要的概念，它對理解維度建模有着非常重要的作用，退化維度經常會和其他一些維度一起組合成事實表的主鍵。退化維度在分析中可以用來做分組使用。
1.3 維度表和事實表的融合
在理解了事實和維度表之後，現在就考慮將兩個組塊一起融合到維度模型中去的問題。如圖1.3所示，由數字型度量值組成的事實表連接到一組填滿描述屬性的維度表——這個星型特徵結構通常被叫做星型連接方案。該術語可以追溯到最早的關係數據庫時期。
圖1.3維度模型中的事實與維度表
關於其中用到的維度方案，應該注意的第一件事就是其簡明性與對稱性。很顯然，業務用戶會因爲數據容易理解和瀏覽而從簡明性方面受益。
維度模型的簡明性也帶來了性能上的好處。數據庫優化器可以更高效率地處理這些連接關係較少的簡單方案。數據庫引擎可以採取的非常強勁的做法是，首先集中對建立了充足的索引的維度表進行約束(過濾)處理，然後用滿足用戶約束條件的維度表關鍵字的笛卡爾乘積一次性處理全部的事實表。令人驚奇的是，利用這種方法只需使用一次事實表的索引，就可以算出與事實表之間的任意n種連接結果。
最後，維度模型能夠很自然地進行擴展以適應變化的需要。維度模型的可預定框架能夠經受住無法預見的用戶行爲變化所帶來的考驗。每個維度都是平等的，所有維度都是進入事實表的對等入口。這個邏輯模型不存在內置的關於某種期望的查詢形式方面的偏向，不存在這個月要問的業務問題相對於下個月來說具有優先方面的考慮。沒有誰會希望，如果業務用戶採用新的方式進行業務分析，就要調整設計方案這樣的事情發生。
最佳粒度或者原子數據具有最佳的維度。被聚合起來的原子數據是最有表現力的數據。原子數據應該成爲每個事實表設計的基礎，從而經受住業務用戶無法預見的查詢所引起的特別攻擊。對於維度模型來說，完全可以向方案中加入新的維度，只要其值對於每個現有的事實行存在唯一性定義就行。同樣，可以向事實表加入新的不曾預料到的事實，只要其詳細程度與現有事實表處在一致的水平面上就可以了。可以用新的不曾預料到的屬性補充先前存在的維度表，也可以從某個前向時間點的角度在一個更低的粒度層面上對現存維度行進行分解。在每種情況下，可以簡單地在表中加入新的數據行或者執行一條SQL ALTER TABLE命令來對現存表格進行適當的修改。數據用不着重新加載，所有現存的數據存取應用可以繼續運行而不會產生不同的結果。
2 維度建模設計過程
本文按照圖2.1具有一定順序的四個步驟的方式進行維度數據庫的設計。
圖2.1四步驟維度設計過程
2.1 第一步 選取業務處理
業務處理過程是機構中進行的一般都由源系統提供支持的自然業務活動。聽取用戶的意見是選取業務處理過程的效率最高的方式。在選取業務階段，數據模型設計者需要具有全局和發展的視角，應該理解整體業務流程的基礎上，從全局角度選取業務處理。
要記住的重要一點是，這裏談到的業務處理過程並不是指業務部門或者職能。通過將注意力集中放在業務處理過程方面，而不是業務部門方面，就能在機構範圍內更加經濟地提交一致的數據。如果建立的維度模型是同部門捆綁在一起的，就無法避免出現具有不同標記與術語的數據拷貝的可能性。多重數據流向單獨的維度模型，會使用戶在應付不一致性的問題方面顯得很脆弱。確保一致性的最佳辦法是對數據進行一次性地發佈。單一的發佈過程還能減少ETL的開發量，以及後續數據管理與磁盤存儲方面的負擔。
2.2 第二步 定義粒度
粒度定義意味着對各事實錶行實際代表的內容給出明確的說明。粒度傳遞了同事實表度量值相聯繫的細節所達到的程度方面的信息。它給出了後面這個問題的答案:“如何描述事實表的單個行?”。
粒度定義是不容輕視的至關重要的步驟。在定義粒度時應優先考慮爲業務處理獲取最有原子性的信息而開發維度模型。原子型數據是所收集的最詳細的信息，這樣的數據不能再做更進一步的細分。通過在最低層面上裝配數據，大多原子粒度在具有多個前端的應用場合顯示出其價值所在。原子型數據是高度維結構化的。事實度量值越細微並具有原子性，就越能夠確切地知道更多的事情，所有那些確切知道的事情都轉換爲維度。在這點上，原子型數據可以說是維度方法的一個極佳匹配。
原子型數據可爲分析方面提供最大限度的靈活性，因爲它可以接受任何可能形式的約束，並可以以任何可能的形式出現。維度模型的細節性數據是穩如泰山的，並隨時準備接受業務用戶的特殊攻擊。
當然，可以總是給業務處理定義較高層面的粒度，這種粒度表示最具有原子性的數據的聚集。不過，只要選取較高層面的粒度，就意味着將自己限制到更少或者細節性可能更小的維度上了。具有較少粒度性的模型容易直接遭到深入到細節內容的不可預見的用戶請求的攻擊。聚集概要性數據作爲調整性能的一種手段起着非常重要的作用，但它絕對不能作爲用戶存取最低層面的細節內容的替代品。遺憾的是，有些權威人士在這方面一直顯得含糊不清。他們宣稱維度模型只適合於總結性數據，並批評那些認爲維度建模方法可以滿足預測業務需求的看法。這樣的誤解會隨着細節性的原子型數據在維度模型中的出現而慢慢地消逝。
2.3 第三步 選定維度
維度所引出的問題是，“業務人員將如何描述從業務處理過程得到的數據?”應該用一組在每個度量上下文中取單一值而代表了所有可能情況的豐富描述，將事實表裝扮起來。如果對粒度方面的內容很清楚，那麼維度的確定一般是非常容易的。通過維度的選定，可以列出那些使每個維度表豐滿起來的離散的文本屬性。常見維度的例子包括日期、產品、客戶、賬戶和機構等。
2.4 第四步 確定事實
設計過程的第四步同時也是最後一步，在於仔細確定哪些事實要在事實表中出現。事實的確定可以通過回答“要對什麼內容進行評測”這個問題來進行。業務用戶在這些業務處理性能度量值的分析方面具有濃厚的興趣。設計中所有供選取的信息必須滿足在第2步中定義的粒度要求。明顯屬於不同粒度的事實必須放在單獨的事實表中。通常可以從以下三個角度來建立事實表[2]：
1、針對某個特定的行爲動作，建立一個以行爲活動最小單元爲粒度的事實表。最小活動單元的定義，依賴於分析業務需求。比如用戶的一次網頁點擊行爲、一次網站登錄行爲，一次電話通話記錄。這種事實表，主要用於從多個維度統計，行爲的發生情況，主要用於業務分佈情況，績效考覈比較等方面的數據分析。
2、針對某個實體對象在當前時間上的狀況。我們通過對這個實體對象在不同階段存儲它的快照，比如賬戶的餘額、用戶擁有的產品數等，通過這種可以統計實體對象在不同的生命週期中的關鍵數量指標。
3、針對業務活動中的重要分析和跟蹤對象，統計在整個企業不同業務活動中的發生情況。比如會員，可以執行或參與多個特定的行爲活動。這種事實表是以上兩種事實表的一個總結和歸納。它主要用於針對我們業務中的活動對象進行跟蹤和考察。
3 數據倉庫總線結構
業務與IT機構一般都對不同業務處理過程的集成很感興趣。低級別業務分析師在這方面的願望可能並不是很急迫，但那些處於較高管理階層的人員非常清楚，在跨業務的範圍內進行數據的查看對於提高評估性能是很必要的。衆多的數據倉庫項目將注意力放在從終端到終端的視角，更好地理解顧客關係的管理需求方面了。如圖3.1所示，在某大型國有銀行中，在業務價值鏈的產品運營中，包含許多相關的業務處理，如營銷支持、產品運營、風險管控、財務績效等諸多業務處理。
圖3.1業務價值鏈
如果針對這些業務處理分別進行維度建模、建立獨立數據集市，數據集市之間沒有共享公共的維度，那麼就會出現問題，數據集市就會變成孤立的集市，不能組合成數據倉庫，而一致性維度的提出正式爲了解決這個問題。圖3.2給出了這種維度共享情形的邏輯表示形式.
圖3.2業務處理之間的維度共享
共享公共的維度對於設計可以進行集成的數據集市來說，具有絕對的決定性作用。這樣做使得來自不同處理的性能度量值可以被組合到單個報表中去。具體的實現過程是，使用多通路的SQL單獨查詢各個集市，然後基於共同的維度屬性對查詢結果施加外連接。這個通常稱作交叉探查(Drill Across)的連接，在維度表屬性具有同一性的情況下是很直接的。
將一組分佈在各處的相關業務處理成一個綜合的數據倉庫來說，總線結構是最基本的要素。
3.1 數據倉庫總線結構
很顯然，想一個步驟就建成企業數據倉庫太令人望而生畏了，然而，將它分成孤立的片段進行建造又會挫敗一致性這個壓倒一切的目標。要使數據倉庫能夠長期地成功運轉，很需要有一種在體系結構上可以按增量方式建造企業數據倉庫的方法。這裏提倡使用的一種方法就是數據倉庫總線結構。
通過爲數據倉庫環境定義標準的總線接口，獨立的數據集市就可以由不同的小組在不同的時間進行實現。只要遵循這個標準，獨立的數據集市就可以插入到一起並有效地共存。所有業務處理將創建一個維度模型系列，這些模型共享一組綜合的具有一致性的共用維度，如圖3.3。
圖3.3 數據倉庫總線結構
數據倉庫總線結構提供了一種可用於分解企業數據倉庫規劃任務的合理方法。在體系結構確立階段的較短時間內，開發團隊設計出一整套在企業範圍內具有統一解釋的標準化維度與事實。這樣，數據體系結構的框架就建立起來了。然後，開發團隊可以全力以赴去實現嚴格依照體系結構進行迭代開發的獨立數據集市。隨着獨立數據集市的投入使用，它們像積木塊一樣搭在了一起。在某種意義上講，需要存在足夠的數據集市纔可能爲集成的企業數據倉庫帶來美好的前景。
總線結構使數據倉庫管理人員獲取兩個方面的優勢。一方面，他們有了指導總體設計的體系框架，並且將問題分成了可以根據具體時限加以實施的以字節計量的數據集市塊。另一方面，各數據集市開發團隊遵照體系指南，可以相對獨立地異步地開展工作。
3.2 一致性維度
在理解了總線結構的重要性以後，現在可以進一步開發發揮數據倉庫總線奠基石作用的一致性標準維度了。一致性維度要麼是同一的，要麼是具有最佳粒度性與細節性的維度在嚴格數學意義上的子集。例如，如果建立月維度話，月維度的各種描述必須與日期維度中的完全一致，最常用的做法就是在日期維度上建立視圖生成月維度。這樣月維度就可以是日期維度的子集，在後續鑽取等操作時可以保持一致。
一致的維度具有一致的維度關鍵字、一致的屬性列名字、一致的屬性定義以及一致的屬性值(將轉化成一致的報表標籤與分組標識)。如果屬性標籤的標記不同或者包含不同的值，維度表就不是一致的(不被處理成一致的)。如果客戶或者產品維度是按非一致的方式進行配置的，那麼，要麼分散的數據集市不能在一起使用，要麼更爲嚴重的是，試圖將它們用在一起將產生無效的結果。
一致的維度以幾種不同的樣式出現。在最基本的層次上，一致的維度意味着與同它們相連接的每種可能的事實表具有完全相同的內容。連接到產品服務簽約事實上的日期維度表與連接到產品服務賬戶餘額事實上的日期維度表是同一的。實際上，一致的維度在數據庫範圍內可能就是相同的物理表。不過，基於對配有多種數據庫平臺的數據倉庫技術環境的典型複雜性的考慮，維度更有可能同時在每個數據集市都存在拷貝。在其中任何一種情況下，兩個數據集市的日期維度都將具有相同數目的行、相同的關鍵字值、相同的屬性標籤、相同的屬性定義與相同的屬性值等。同樣，也存在一致的數據內容、數據解釋與用戶展示。
3.3 一致性事實
到現在爲止，我們已經討論了建立一致性維度以將數據集市維繫在一起的中心任務。這涵蓋了數據倉庫遷移開發所要付出的大量工作努力，餘下的努力要投入到建立一致性事實定義上。
通常，像利潤、經濟資本、產品覆蓋度、客戶滿意度以及其他關鍵性指標（KPI）需要在企業級共享的度量指標，都是必須保持一致性的事實。一般地說，事實表數據並不在各個數據集市之間明確地進行拷貝。不過，如果事實確實存在於多個位置，那麼支撐這些事實的定義與方程(公式)都必須是相同的，假如將它們當作同種事物看待的話，如果這些事實具有相同的標記，那麼需要在相同維度環境下對它們進行定義，同時使其在各個數據集市之間具有相同的度量單位。必須在數據命名實踐中接受規範的約束，如果不可能做到使事實完全一致，那麼應該對不同的解釋給出不同的名稱。這樣可以減少計算中使用不兼容的事實的可能性。
4 總結
本文作爲維度建模綜述性文章，基於維度建模理論知識並結合某企業的維度建模實踐介紹了事實表、維度表、數據倉庫總線結構、一致性維度、一致性事實等維度模型中的基本概念以及維度建模的設計過程。
5 參考資料
[1].Ralph Kimball著，譚明金譯.《數據倉庫工具箱：維度建模的完全指南（第二版）》，電子工業出版社，2003.
2參照3種不同類型的事實表
