簡介
業務環境是在快速變化的，而業務數據的類型也是如此。一個成功的數據倉庫解決方案的基礎就是靈活的設計，這種設計可以適應不斷變化的業務數據。數據倉庫的架構和倉庫數據的建模是倉庫設計中的核心過程。
數據倉庫的架構
當使用數據模型捕獲業務需求時，您就已經完成了數據倉庫設計中的部分工作。然而，正式的數據倉庫設計應該從數據倉庫的架構開始。
倉庫架構是基於一些因素所做的關鍵決策，這些因素包括當前基礎設施、業務環境、期望的管理和控制結構、實現工作的承諾和范圍、企業所采用的技術環境的功能以及可用的資源等。
架構選擇
倉庫架構將決定數據倉庫和數據集市本身的位置，以及控制所駐留的位置，或者反之。例如，數據可以駐留在集中進行管理的中心位置中。或者，數據可以駐留在集中或獨立管理的分布式的本地和/或遠程位置中。
有以下一些架構選擇：
業務范圍（Business-wide）的數據倉庫
獨立的數據集市
互連的數據集市
這些架構選擇也可以組合使用。例如，數據倉庫架構可以在物理上分布或集中管理。
業務范圍的數據倉庫架構
業務范圍的數據倉庫就是將支持整個或一大部分業務的數據倉庫，該業務需要更加完全集成的數據倉庫，跨部門和業務線（line of business）具有較高的數據訪問和使用率。即基於整個業務需求設計和構造倉庫。可以將之視作可跨整個企業使用的決策支持數據的公共存儲庫，或其中的一個大型子集。這裡所使用的術語“業務范圍（business-wide）”反映的是數據訪問和使用的范圍，而非物理結構。在整個企業中，業務范圍的數據倉庫在物理上可以是集中式的，也可以是分布式的。
獨立的數據集市架構
獨立的數據集市架構暗指單獨的數據集市，這些數據集市是由特定的工作組、部門或業務線進行控制的，完全是為滿足其需求而構建的。實際上，它們甚至與其他工作組、部門或業務線中的數據集市沒有任何連通性。
圖 1. 數據倉庫架構選擇
數據倉庫的實現方法
實現方法的選擇受這些因素的影響：當前的 IT 基礎設施、可用的資源、所選擇的架構、實現的范圍、對於跨企業進行的更大業務范圍的數據訪問的需求、投資回報率（return-on-investment）需求以及實現的速度。實現方法的選擇是數據倉庫設計中的重要部分；該決策需要在數據倉庫項目的早期階段做出。
自頂向下的實現
自頂向下的方法就是在單個項目階段中實現數據倉庫。自頂向下的實現需要在項目開始時完成更多計劃和設計工作。這就需要涉及參與數據倉庫實現的每個工作組、部門或業務線中的人員。要使用的數據源、安全性、數據結構、數據質量、數據標准和整個數據模型的有關決策一般需要在真正的實現開始之前就完成。
自底向上的實現
自底向上的實現包含數據倉庫的計劃和設計，無需等待安置好更大業務范圍的數據倉庫設計。這並不意味著不會開發更大業務范圍的數據倉庫設計；隨著初始數據倉庫實現的擴展，將逐漸增加對它的構建。現在，該方法得到了比自頂向下方法更廣泛的接受，因為數據倉庫的直接結果可以實現，並可以用作擴展更大業務范圍實現的證明。
您應該選擇哪種實現？
每種實現方法都有利弊。在許多情況下，最好的方法可能是某兩種的組合。該方法的關鍵之一就是確定業務范圍的架構需要用於支持集成的計劃和設計的程度，因為數據倉庫是用自底向上的方法進行構建。
在使用自底向上或階段性數據倉庫項目模型來構建業務范圍架構中的一系列數據集市時，您可以一個接一個地集成不同業務主題領域中的數據集市，從而形成設計良好的業務數據倉庫。這樣的方法可以極好地適用於業務。每個數據集市都可以處理可識別的業務問題或主題領域，從而可以計算 ROI。構建團隊可以測試並調整產品，而該方法也為構建團隊提供了寶貴的學習曲線。
對於中間市場的公司，有一些額外的理由要采用自底向上的方法：
在中間市場的業務及其業務數據結構中，存在比企業業務數據中更多的易變性。
較小的公司通常存在有限的項目預算。
中間市場的公司需要快速解決方案以減輕其業務難度。
該類項目所需要的人員必須具有對業務的廣泛理解以及特定業務領域的詳細知識。找到這樣的人是很困難的，但即使可以，使用他們的時間來進行數據建模也比讓他們盡普通業務職責更加困難。
數據倉庫基礎設施
既然已經具有關於高級數據倉庫架構的一些決策，您就可以開始考慮數據倉庫應該具有什麼組件了。
圖 2. 商業智能基礎設施組件的高級視圖
兩層數據倉庫設計的好處包括：
靈活且易於維護。可以隨時根據用戶的報表需求修改數據集市的數據結構。但是，它不影響數據存儲庫中數據庫的數據結構。
易於伸縮和集成。關系類型的業務數據存儲庫數據庫比數據集市中非正規（denormalized）和匯總性（summarized）的數據庫更易於伸縮和集成。
用戶友好。將數據集市和數據存儲庫分離使得數據集市的設計更加是終端用戶所驅動的，因為數據建模師不需要過多考慮數據集成和模式可伸縮性問題。
更好的安全設計。兩層的方法將數據存儲和數據訪問管理相分離。終端用戶只能訪問授權給他們的數據集市，而非所有的數據倉庫數據。
更好的數據管理設計。數據倉庫是為存儲集成的業務范圍的歷史數據而設計的。但是，數據倉庫中的許多數據集市都不一定需要那麼多的歷史數據。兩層設計是存儲歷史數據的好地方。
請記住，上面兩層的倉庫設計是概念倉庫布局。例如，在數據存儲庫層，登台數據庫和存儲庫數據庫可以在不同的服務器上、在同一服務器上或者甚至在不同模式下的同一數據庫中。
倉庫數據建模層
數據建模有三層：概念、邏輯和物理。在數據倉庫的設計中，數據建模的每一層都有自己的目的。
概念
高級數據模型是所有業務主題領域以及業務的公共數據元素的一致性定義，從高級的業務視圖到通用的邏輯數據設計。您可以從中派生出通用的范圍，並獲得對業務需求的理解。這個概念數據模型是當前和將來數據倉庫開發階段的基礎。
邏輯
邏輯數據模型包含關於業務主題領域的更多詳細信息。它捕獲目標業務主題領域中的詳細業務需求。邏輯數據模型是當前項目的物理數據建模的基礎。
從這一階段開始，該解決方案就適用自底向上的方法了，這意味著這個邏輯數據模型中僅僅將最重要和緊迫的業務主題領域鎖定為目標。
邏輯數據模型的功能包括：
對於所有實體及其之間的關系的規范。
對於每個實體的屬性的規范。
對於所有主鍵和外鍵的規范。
規范化（Normalization）和聚集。
對於多維數據結構的規范。
物理
物理數據建模應用物理約束，如空間、性能以及數據的物理分布。物理數據模型是與數據庫系統以及您將使用的數據倉庫工具緊密相關的。該階段的目的是設計真正的物理實現。
將邏輯建模與物理建模清晰分離是特別重要的。良好的邏輯建模實踐關注問題域的本質。邏輯建模解決“什麼”之類的問題。物理建模為模型解決“如何”之類的問題，這表示給定的計算環境中實現的真實性。因為業務計算環境隨時間變化，所以邏輯和物理數據建模的分離將幫助穩定一個階段到另一階段的邏輯模型。
一旦實現了數據倉庫，且客戶開始使用它，他們就常常會生成新的請求和需求。這將啟動另一開發周期，繼續數據倉庫構建的迭代和進化過程。正如您可以看到的，邏輯數據模型是數據倉庫的活動部分，在數據倉庫的整個生命周期中使用和維護。數據倉庫的建模過程確實是無止境的。
圖 4. 數據倉庫邏輯數據模型的生命周期
數據集市的數據建模
因為倉庫終端用戶直接與數據集市進行交互，所以數據集市的建模是捕獲終端用戶業務需求的最有效工具之一。數據集市的建模過程取決於許多因素。下面描述了三個最重要的：
數據集市的建模是終端用戶驅動的。終端用戶必須參與數據集市的建模過程，因為他們顯然是要使用該數據集市的人。因為您應期望終端用戶完全不熟悉復雜的數據模型，所以應該將建模技術和建模過程作為整體進行組織，以便使復雜性對終端用戶透明。
數據集市的建模是由業務需求驅動的。數據集市模型對於捕獲業務需求十分有用，因為它們通常由終端用戶直接使用，且易於理解。
數據集市的建模極大地受到了數據分析技術的影響。數據分析技術可以影響所選擇的數據模型的類型及其內容。目前，有幾種常用的數據分析技術：查詢和報表制作、多維分析以及數據挖掘。
如果僅僅意圖提供查詢和報表制作功能，那麼帶有正規（normalized）或非正規（denormalized）數據結構的 ER 模型就是最合適的。維度數據模型也可能是較好的選擇，因為它是用戶友好的，並具有更好的性能。如果其目標是執行多維數據分析，那麼維度數據模型就是這裡的惟一選擇。然而，數據挖掘通常在可用的最低細節級（level of detail）工作得最好。因此，如果數據倉庫是用於數據挖掘的，就應該在模型中包含較低細節級（level of detail）的數據。
因為本文沒有包括 ER 建模，所以本小節將討論維度數據建模，這是數據集市設計中最重要的數據建模方法。
星型和雪花型模型
有兩種基本的數據模型是可以在維度建模中使用的：
星型模式（或模型）
雪花型模型
星型模式已經成為一個公共術語，用於表示維度模型。數據庫設計師長期使用術語“星型模式”來描述維度模型，因為結果結構看上去像一個星星。一些業務用戶不習慣術語“模式”，所以他們接受聽起來更加簡單的術語“星型模型”。術語“星型模型”和“星型模式”是可以相互交換的。
星型模型是維度模型的基本結構。它通常有一個大型的中心表（稱作事實表）和一組小型表（稱作維度表），維度表以放射模式圍繞事實表。
傳統的 ER 模型具有均勻且平衡的實體樣式和實體之間的復雜關系，而星型模型卻是完全不對稱的。維度模型中的事實表與其他所有維度表之間存在單一連接。
維度建模通常在收集了業務需求之後，首先指定事實和維度。初始的維度模型在外表上通常像星星一樣，一個事實位於中心，一個級別上的多個維度則圍繞在周圍。雪花型模型是一個或多個維度的分解結果，它們自己有時具有層次結構。您可以將一個維度表中成員之間多對一的關系定義為一個單獨的維度表，從而形成層次結構。
分解的雪花型結構很好地展示了維度的層次結構。雪花型模型易於數據建模師的理解以及數據庫設計師用於維度的分析。然而，雪花型的結構看起來更復雜，並且可能趨於使業務用戶用起來感到不如更簡單的星型模型舒服。開發人員也可以選擇雪花型，因為它通常節省了數據存儲。考慮一個銀行應用程序，其中針對一個維度有一個極其大型的帳戶表。您可以選擇通過不存儲極其頻繁重復的文本字段，而是將其一次性放置在一個子維度表中，節省該大小的表中的大量空間。
雖然雪花型模型不節省空間，但與事實表相比時，這通常是不重要的。大多數數據庫設計師都不將節省空間作為選擇建模技術的主要決策標准來考慮。
圖 6. 星型模式結構示例
維度
維度的基本結構就是層次結構。維度層次結構用於在比維度模型中測度所呈現的基本粒度更小的細節級（level of detail）來聚集業務測度，如銷售總收入（Total Revenue of Sales）。本例中，操作稱作上卷（roll-up）處理。上卷處理是對維度模型中的基本事實或測度執行的。
如果將測度上卷到更小的細節級（level of detail），那麼終端用戶就顯然可以執行逆操作（下鑽），該操作包含查看更詳細的測度，或按照維度層次結構探索更低的細節級聚集測度。
維度建模最重要的活動之一就是捕獲聚集路徑或終端用戶執行上卷和下鑽所依照的聚集層次結構。該過程將產生維度模型，您將在稍後執行其他建模活動時擴展和修改該模型，如慢變化的時間維度的建模、維度中約束的處理以及跨維度的關系和約束的捕獲。
維度建模與終端用戶和業務過程緊密相關。為了使維度模型持續更長時間並適用於更多用戶組，特別重要的是從概念的觀點建模維度，尋找終端用戶社區大致會感興趣的基本的聚集路徑和聚集級別。
您通常可以向良好定義的事實添加測度，且根本不對模型造成很大影響。然而，對於維度，這就肯定不正確了，因為維度層次結構的結構可能變得復雜。
當您在廣闊的環境中考慮問題域時，將期望一個維度中具有多個不同的聚集路徑。維度層次結構中的分割可以在不同的級別上出現。已經分割的層次結構可以在稍後再次進行分割。該過程可能導致復雜的模式，也許太過於復雜，以致終端用戶無法處理。請咨詢您的終端用戶以避免不必要的糾紛。
一個通常難以做出的重要決策就是一個聚集層是否真正是（結構化）層次結構的一個元素，或它是否僅僅是維度中一項的屬性。例如，將產品包裝單元、品牌或存儲類型作為維度路徑的顯式元素（即，作為維度層次結構中潛在的實體類型）是否是明智或必要的呢？或者是否可以僅僅將它們考慮成產品的屬性呢？
查找維度（如 Product 維度）中的基本聚集路徑通常意味著調查維度中的許多典型關系。
構造或結構化關系：信息分析員使用這些關系來探索產品及其組件之間的構造性關系。例如，通過與產品組件相關的成本和產品構造相關的成本，它們可以用於計算產品成本。
變化（Variation）關系：變化用於就產品模型、版本、實現、組件混合、調配等而言區分產品。
變化還可用於指定產品替換。信息分析員使用變化關系來組合相關產品和聚集相關測度，因為較低級類別的產品可能只存在於一段有限的時期內，或者因為它們頻繁用於在某一過程中相互替換（例如，當“初始”產品缺貨，而將某一版本的產品賣給客戶時）。
分類關系：分類是將相似的產品分成組。關系分類顯然是產品之間出現最頻繁的關系，信息分析員用於上卷詳細的測度。請注意，通常需要多個不同類型的分類。例如，可以根據面向銷售、面向制造、面向儲備或面向供應的特點來對產品進行分類。信息分析員將分類用於統計組中的聚集測度，統計組有總數、平均數、最小值和最大值等。
事實
事實表只包含用於引用維度表的 ID，以及用於測量所有維度成員變化或性能的測度。下一步就是將維度和測度組織成事實。這是以可以解決指定需求的方式將維度和測度進行分組的過程。
事實表的設計中要解決幾個重要問題：
粒度（記錄事實的細節級）：如果要有效地分析數據，就必須都在同一粒度級別上。一般說來，您應該將數據放在最詳細的粒度級別上。這是因為您無法將數據修改到您所決定設置的細節級上。但是，您總是可以上卷（匯總）數據以創建一個略粗的粒度級別的表。
相加性（要總結的測度的能力）：測度分成三個類別：全相加的（fully additive）、非相加的（nonadditive）和半相加的（semiadditive）。一個非相加測度的例子就是百分率。您無法簡單地將兩個事實的百分率相加到一起，並產生有意義的結果。一個半相加測度的例子就是余額。雖然您可以將兩個帳戶的余額相加獲得總的余額，但無法將同一帳戶在兩個不同時間點的兩個余額相加。因為余額只是跨一些維度進行相加的，所以我們稱之為半相加測度。將可以跨所有維度相加的值視作全相加的。當您考慮將在事實表上發生的可能匯總時，相加性就變得很重要。通常，全相加的測度是最理想的。當測度不是全相加的時，應考慮將它們分成其原子元素。
鍵選擇：多維數據建模中的鍵選擇是一個難題。它包含性能和易於管理之間的權衡（trade-off）。鍵選擇主要適用於維度。您為維度所選擇的鍵必須是事實的外鍵。維度鍵有兩種選擇：您可以分配一個任意鍵，或者使用操作系統中的標識符。任意鍵通常只是一個序列號，當需要一個新鍵時，就分配下一個可用的號碼。
為了使用操作系統中的標識符惟一地表示維度，您有時需要使用一個復合鍵。復合鍵就是由多個列組成的鍵。任意鍵是一列，通常比操作派生的鍵要小。因此，任意鍵通常可以更快地執行連接。
鍵選擇中的最後一個因素就是它對事實表的影響。在創建事實時，必須將每個維度的鍵分配給它。如果維度將帶有時間戳的操作派生的鍵用於歷史數據，那麼在創建事實時，就沒有附加工作。連接將自動發生。對於任意鍵或任意歷史標識符，在創建事實時，就必須將一個鍵分配給事實。
分配鍵的方式有兩種。一種就是維護操作和數據倉庫的鍵的轉換表。另一種就是存儲操作鍵，並且在必要時，存儲時間戳作為維度上的屬性數據。
那麼，選擇就在任意鍵的更好性能和操作鍵的更易維護之間進行。性能提高多少和維護增加多少的問題就必須在您自己的組織中進行評估了。
無論做出什麼選擇，都必須在元數據中用文檔記錄生成它們的過程。該信息對於管理和維護數據倉庫的技術人員來說是必要的。如果您所使用的工具沒有隱藏連接處理，那麼用戶可能也需要理解這一點。
既然您理解了維度和事實表的處理，就讓我們看一看真實世界的例子，以探索如何從業務需求中識別維度和測度。該例子只是對於一系列業務問題的基本分析。這些業務問題被定義為示例需求：
按照銀行支行，本月客戶的平均余額和交易數是多少？
按照支行、產品和地區匯總，要付給每位客戶的年淨利潤和利息是多少？
百分之幾的客戶是盈利的？將他們按照支行、地區和年分類。
本年一位客戶的總交易量是多少？
按照地區，最盈利的前 5 位產品是什麼？
在最近 5 年裡，最盈利的前 5 個支行是什麼？
最盈利的客戶的人口和地理特點是什麼？
通過分析這些問題，我們就定義了需要滿足需求的維度和測度（見表 1）。
表 1. 維度和測度表
維度和測度 Q1 Q2 Q3 Q4 Q5 Q6 Q7 維度 ? ? ? ? ? ? ? 支行 ?X ?X ?X ? ? ?X ?X 地區 ? ?X ?X ? ?X ? ?X 客戶 ?X ?X ?X ?X ? ? ?X 產品 ? ?X ?X ? ?X ? ? 時間 ?X ?X ?X ?X ? ?X ? ? ? ? ? ? ? ? ? 測度 ? ? ? ? ? ? ? 余額 ?X ? ? ? ? ? ? 交易量 ? ? ? ?X ? ? ? 交易數 ?X ? ? ? ? ? ? 淨利潤 ? ?X ?X ? ?X ?X ?X 所付利息 ? ?X ? ? ? ? ?
此時，您要檢查維度以確保：
您具有需要用於回答問題的數據。
在最細的級別定義了所有的測度。
使用這些簡化的分析問題來決定最終的星型模型中包含什麼以及排除什麼：
余額和交易數基於交易量的聚集，所以它們是派生的測度。
所付利息的計算是將帳戶利率乘以余額。這是基於帳戶和基於月份的計算。因為利率是 Account 表的一個屬性，所以需要添加 Account 維度表。正如您可以看到的，所付利息也是派生的測度。
假定淨利潤基於（投資收益）- （所付利息）的計算。因為投資收益是銀行級的測度，而所付利息是派生的測度，所以淨利潤也是派生的測度。
從以上分析得出的結論有：
交易量是惟一需要的測度。
需要帳戶維度來產生利率和投資收益信息。
模型元數據
在傳統的開發周期中，完成一個模型之後，只有需要進行修改或其他項目需要數據時，才使用它。但是在該倉庫中，要連續使用模型。倉庫的用戶不斷訪問該模型以決定他們需要用於分析組織的數據。倉庫中數據結構的修改速度比操作性數據結構要快得多。因此，倉庫的技術用戶（管理員、建模師、設計師等等）也將定期使用您的模型。
這就是元數據所承擔的任務。遠遠不只是一副漂亮的圖畫，該模型必須是所存儲數據的完整表示，否則，它對於任何人都毫無用處。
為了正確理解模型，以及可以確認它滿足了需求，用戶必須訪問按照容易理解的業務術語描述倉庫的元數據。因此，您應在此時記錄非技術的元數據。在設計階段，您將向它添加技術元數據。
在倉庫級上，您應提供倉庫中可用東西的列表。該列表包含可用的模型、維度、事實和測度，因為當用戶開始分析數據時，這些都將用作初始的進入點。
對於每個模型，提供名稱、定義和目的。名稱僅僅給用戶提供一些搜索時關注的東西。它通常與事實相同。定義指定建模的內容，而目的描述模型用於什麼。模型的元數據也應包含與之相關的維度、事實和測度列表，以及聯系人員的姓名，以便用戶在有關於模型的問題時，能夠獲得附加的信息。
模型驗證
在投入大量時間和精力實現倉庫數據庫之前，與用戶一起驗證模型是一個很好的想法，特別是數據集市模型。進行該檢查的目的是雙重的。首先，它確認模型可以真正滿足用戶的需求。第二，檢查應確認用戶可以理解該模型。請記住，一旦實現了倉庫，用戶就會定期依靠模型訪問倉庫中的數據。無論模型多麼好地滿足了用戶的需求，如果用戶無法理解模型以訪問數據，您的倉庫都是失敗的。
此時，驗證是在高級別上完成的。與用戶一起檢查該模型以確認它是可以理解的。與用戶一起，通過解決您將如何回答需求中指定的部分問題來測試模型。
模型不必滿足用戶的所有需求，這一點是好的。這不意味著您應停止並返回到開始。期望您模型的第一次切入滿足約 50% 的需求。接受模型的這 50%（或者不管驗證了多少），並開始進行物理設計。應將剩余的送回給需求的收集階段。要麼需要更好地理解需求，要麼通常需要修改並重新定義它們。這常常會導致對已創建的模型進行添加和修改。同時，模型的有效部分將通過設計階段，並開始向用戶提供好處。
開發的重復和部分完整模型的繼續創建是提供快速開發數據倉庫能力的關鍵元素。
圖 7. 倉庫數據模型評估過程
