次元模組化的基本概念及過程
摘要：本文首先介紹次元模型中的次元表和事實表這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種不同類型的事實表
http://blog.itpub.net/23716337/viewspace-1118751/