1.基本概念
1.1 收集業務需求及數據實現
開始維度建模工作前，項目組需要立即業務需求，以及作為基礎的源數據的實際情況，通過與業務代表交流來發現需求，用於理解他們的基於關鍵性能指標、競爭性商業問題、決策制定過程、自持分析需求的目標。同時，數據實際情況可以通過與源系統專家交流，構建高層次數據分析訪問數據可行性來揭示。
1.2 協作維度建模研討
維度建模應該有主題專家與企業數據管理代表合作設計而成。工作由數據建模者負責，但模型應該通過與業務代表開展一些列高級別交互討論獲得。這些討論組也為豐富業務需求提供了一種機會。維度建模不應該由那些不懂業務需求的人來設計，協作是成功的關鍵
1.3 4步維度設計過程
維度模型設計期間主要設計4個主要的決策：
1. 選擇業務過程
2. 聲明粒度
3. 確認維度
4. 確認事實
1.4 業務過程
業務過程是組織完成的操作型活動，例如，活動的訂單、處理保險索賠、學生課程注冊或每個月每個賬單的快照等。業務過程事件簡歷或獲取性能度量，並轉換成事實表中的事實。多數事實表關注某一些業務過程的結果。過程的選擇是非常重要的，因為過程定義了特定的設計目標以及對粒度、維度、事實的定義。每個業務過程對應企業數據倉庫總線矩陣的一行
1.5 粒度
聲明粒度是維度設計的重要步驟。粒度用於確定某一事實表中的行表示什么。粒度聲明式設計必須履行的合同。在選擇維度或事實前必須聲明粒度，因為每個候選維度或事實必須與定義的粒度保持一致。在所有維度設計中強制實行一致性是保證BI應用性能和易用性的關鍵。在從給定的業務過程獲取數據時，原子粒度是最低級別的粒度。我們強烈建議從關注原子級別粒度數據開始設計，因為原子粒度數據能夠承受無法預測的用戶查詢。上卷匯總粒度對性能調整來說非常重要，但這樣的粒度往往要猜測業務公共問題。針對不同的事實表粒度，要建立不同的物理表，在同一事實表中不要混用多種不同的粒度。
1.6 描述環境的維度
維度提供圍繞某一業務過程事件所涉及的“誰、什么、何處、何時、為什么、如何”等背景，維度表包含BI應用所需要的用於過濾機分類實時的描述性屬性。牢牢掌握事實表的粒度，就能夠將所有可能的維度區分開。當與給定事實表行關聯時，任何情況下都應使維度保持單一值。
維度表優勢被稱為數據倉庫的“靈魂”，因為維度表包含確保DW/BI系統能夠被用作業務分析的入口和描述性標識，主要的工作都放在數據管理與維度表的開發方面，因為他們是用戶BI經驗的驅動者。
1.7 用於度量的事實
事實設計來自業務過程事件的度量，基本上都是以數量值表示。一個事實表行與按照事實粒度描述的度量事件之間存在一對一關系，因此事實表對應一個物理可觀察的事件，在事實表內，所有事實只允許與聲明的粒度保持一致。例如，在零售事務中，銷售產品的數量與其總額是良好的事實，然而商店經理的工資不允許存在於零售事務中
1.8 方便地拓展到維度模型
維度模型對數據關系發生變化具有靈活的適應性，當發生以下所列舉的變化時，不需要改變現存的BI查詢或應用，就可以方便地適應，且查詢結果不會有任何改變。
- 當事實與存在的事實表粒度一致時，可以創建新列
- 通過建立新的外鍵列，可以將維度關聯到已經存在的事實表上，前提是維度列與事實表粒度保持一致
- 可以在維度表上通過建立新列添加屬性
- 可以使事實表的粒度更原子化，方法是在維度表上增加屬性，然后以更細的粒度重置事實表，小新保存事實表及維度表的列名
2. 事實表技術基礎
2.1 事實表結構
發生在現實世界中的操作型事件，其所產生的可度量數值，存在在事實表中，從最低的粒度級別來看，事實表行對應一個度量時間。反之亦然，因此，事實表的設計完全依賴於物理活動，不受可能產生的最終報表的影響。除了數字度量外，事實表總是包含外鍵，用於關聯與之對應的維度，也包含可選的退化維度建和日期/時間戳。查詢請求的主要目標是基於事實表開展計算和聚集操作。
2.2 可加、半可加、不可加事實
事實表中的數字度量可划分為三類：最靈活、最有用的事實是完全可加，可加性度量可以按照與事實表關聯的任意維度匯總。半可加度量可以對某些維度匯總，但不能對所有維度匯總。差額是常見的半可加事實，除了時間維度外，他們可以跨所有維度進行加法操作。另外，一些度量是完全不可加的，例如，比率，對非可加事實，一種好的方法是，盡可能存儲非可加度量的完全可加的分量，並在計算出最終的非可加事實前，將這些分量匯總到最終的結果集中。最終計算通常發生在BI層或OLAP多維數據庫層。
2.3 事實表中的空值
事實表中可以存在空值度量，但是在事實表的外鍵中不能存在空值，否則會導致違反參照完整性的情況發生。關聯的維度表必須用默認行（代理鍵）而不是空值外鍵表示未知的或無法應用的條件
2.4 一致性事實
如果某些度量出現在不同的事實表中，需要注意，如果需要比較或計算不同事實表中的事實，應保證針對事實的技術定義是相同的，如果不同的事實表定義是一致的，則這些一致性事實應該具有相同的命名，如果他們不兼容，則應該有不同的命名用於告誡業務用戶和BI應用
2.5 事務事實表
事務事實表的一行對應空間或時間上某點的度量事件。原子事務粒度事實表是維度化及可表達的事實表，這類健壯的維度確保對事務數據的最大化分片和分塊。事務事實表可以是稠密的，也可以是稀疏的，疑問僅當存在度量時才會建立行，這些事實表總是包含一個與維度表關聯的外鍵，也可能包含精確的時間戳和退化維度減，度量數字事實必須與事務粒度保持一致。
2.6 周期快照事實表
周期快照事實表中的每行匯總了發生在某一標准周期，如某一天，某周，某月的多個度量事件，粒度是周期性的，而不是個體的事務。周期快照事實表通常包含許多事實，因為任何與事實表粒度一致的度量事件都是被允許存在的。這些事實表其外鍵的密度是均勻的，因為即使周期內沒有活動發生，也會在事實表中為每個事實插入包含0或空值的行。
2.7 累積快照事實表
累積快照事實表的行匯總了發生在過程開始和結束之間可預測步驟內的度量時間。管道或工作流過程（例如，履行訂單或索賠過程）具有定義的開始點，標准中間過程，定義的結束點，他們再此類事實表中都可以被建模。通常在事實表中針對過程中的關鍵步驟都包含日期外鍵。累積快照事實表中的一行，對應某一具體的訂單，當訂單產生時會插入一行。當管道過程發生時，累積事實表行被訪問並修改，這種對累積快照事實表行的一致性修改在三種類型事實表中具有特性，除了日期外鍵與每個關鍵過程步驟關聯外，累積快照事實表包含其他維度和可選退化維度的外鍵。通常包含數字化的與粒度保持一致的，符合里程碑完成計數的滯后性度量。
2.8 無事實的事實表
例如，在給定的某一天中發生的學生參加課程的事件，可能沒有可記錄的數字化事實，但該事實行帶有一個包含日歷天，學生、教師、地點、課程等定義良好的外鍵。同樣，客戶交際也是一種事件，但沒有相關的度量。利用無事實的事實表也可以分析發生了什么，這類查詢總是包含兩個部分：包含素有可能事件的無事實覆蓋表，包含實際發生的事件的活動表。當活動從覆蓋表中減除時，其結果是尚未發生的事件。
3. 維度表技術基礎
3.1 維度表結構
每個維度表都包含單一的主鍵列。維度表的主鍵可以作為與之關聯的任何事實表的外鍵，當然，維度表行的描述環境應與事實表行完全對應。
3.2 維度代理鍵
維度表中會包含一個列，表示唯一主鍵。該主鍵不是操作型系統的自然鍵，由於需要跟蹤變化，因此若采用自然鍵，將需要多個維度行表示。另外，維度的自然鍵可以由多個源系統建立，這些自然鍵將出現兼容性問題，難以管理。
3.3 自然鍵、持久鍵和超自然鍵
由操作型系統建立的自然鍵受業務規則影響，無法被DW/BI系統控制。例如，如果雇員辭職，然后重新工作，則雇員號碼（自然鍵）可能會發生變化。數據倉庫希望為該雇員創建單一鍵，這就需要建立新的持久鍵以確保在此種情況下，雇員號保持持久性不會發生變化。該鍵有時被稱為持久性超自然鍵。最好的持久鍵其格式應該獨立於原始的業務過程
3.4 下鑽
3.5 退化維度
有時，維度除了主鍵外沒有其他內容，例如，但某一發票包含多個數據項時，數據項事實行繼承了發票的所有描述性維度外鍵，發票除了外鍵外無其他項。但發票數量仍然是在此數據項級別的合法維度鍵。退化維度常見於交易和累積快照事實表中
3.6 非規范化扁平維度
3.7 多層次維度
例如，日歷日期維度可以按照財務周期層次從天到周進行划分，也可能存在從天到月再到年的層次。
3.8 維度表中的空值屬性
當給定維度行沒有被全部填充時，或者當存在屬性沒有被應用到所有維度行時，將產生空值維度屬性。上述兩種情況，推薦采用描述性字符串替代空值。例如，使用Unknown或Not Applicable替換空值。應該避免在維度屬性中使用空值，因為不同的數據庫系統在處理分組和約束時，針對空值的處理方法不一致
3.9 日歷日期維度
3.10 扮演角色的維度
單個物理維度可以被事實表多次引用，每個引用連接邏輯上存在差異的角色維度。例如，事實表可以有多個日期，每個日期通過外鍵表示不同的日期維度，原則上每個外鍵表示不同的日期維度視圖，這樣引用具有不同的含義。這些不通過的維度視圖（唯一的屬性列名）被稱為角色。
3.11 雜項維度
事務性商業過程通常產生一系列混雜的，低粒度的標識和指示器，與其為每個標識或屬性定義不同的維度，不如建立單獨的將不同維度合並到一起的雜項維度。這些維度，通常在一個模式中標記為事務性概要維度，不需要所有屬性可能值的笛卡爾積，但應該只包含實際發生在源數據中的合並值
3.12 雪花維度
3.13 支架維度
維度可包含對其他維度的引用。例如，銀行賬戶維度可以引用表示開戶日期的維度。這些被引用的輔助維度被稱為支架維度。支架維度可以使用，但應該盡量少用，多數情況下，維度之間的關聯應該由事實表來實現。在事實表中通過兩個維度的不同外鍵相關聯
4.使用一致性維度集成
4.1 一致性維度
當不同維度表的屬性具有相同列名和領域內容時，稱維度表具有一致性。
4.2 縮減維度
縮減維度是一種一致性維度，由基本維度的列與（或）行的子集構成。當構建聚集事實表時需要縮減上卷維度。當商業過程自然地獲取粒度級別較高的數據時，也需要縮減維度，例如，某個按月和品牌進行的預測（不需要與銷售數據關聯的更原子級別的數據和產品）。另外一種情況下，也就是當兩個維度具有同樣粒度級別的細節數據，但其中一個僅表示行的部分子集時，也需要一致性維度子集
4.3 跨表鑽取
跨表鑽取的意思是當每個查詢的行頭包含相同的一致性屬性時，使不同的查詢能夠針對兩個或更多的事實表進行查詢
4.4 價值鏈
價值鏈用於區分組織中主要業務的自然流程。例如，銷售商的價值鏈可能包括購買、庫存、零售額等。
4.5 企業數據倉庫總線結構
企業數據倉庫總線架構提供了一種建立日期DW/BI系統 的增量式方法。這一架構通過關注業務過程將DW/BI規划過程分解為可管理的模塊。通過重用跨不同過程的標准化一致性維度發布實現集成。
4.6 企業數據倉庫總線矩陣
企業數據倉庫總線矩陣適用於設計並與企業數據倉庫總線架構交互的基本工具。矩陣的行表示業務過程，列表示維度，矩陣中的點表示維度與給定的業務過程是否存在關聯關系。
4.7 總線矩陣實現細節
總線矩陣實現細節是一個更加粒度化的總線矩陣，其中拓展每個業務過程行以展示特定事實表或OLAP多維數據庫。在此細節粒度上，可以文檔化精確的粒度描述以及事實列表
4.8 機會/利益相關方矩陣
在確定了企業數據倉庫總線矩陣行之后，可以通過替換包含業務功能（例如，市場、銷售、財務等）的維度列規划不同的矩陣。通過確定矩陣點以表示哪些業務功能與哪些業務過程行相關。
5.處理緩慢變化維度（SCD）屬性
5.1 類型0：原樣保留
5.2 類型1：重寫
維度行中原來的屬性被新值覆蓋，只保留最新的情況。該方法易於實現且不需要建立額外的維度行，但是受此影響的聚集事實表和OLAP多維數據庫將會重復計算
5.3 類型2：增加新行
最小需要在維度行中增加三個額外列：
- 行有效的日期/時間戳列
- 行截止日期/時間戳列
- 當前行標識
5.4 類型3：增加新屬性
不太常用
5.5 類型4：增加微型維度
對類型4，當維度中的一組屬性快速變化並划分為微型維度時采用。此種情況下的維度通常被稱為快速班花魔鬼維度。通常在包含幾百萬行的維度表中使用的屬性是微型維度設計的候選，及時他們並不經常變化。變化類型4微型維度需要自己的唯一主鍵，基維度和微型維度主鍵從相關的事實表中獲取。
5.6 類型5：增加微型維度及類型1支架
5.7 類型6：增加類型1屬性到類型2維度
5.8 類型7：雙類型1和類型2維度
6.處理維度層次關系
6.1 固定深度位置的層次
固定深度層次是多對一關系的一種，例如，從產品到品牌，再到分類，到部分。
6.2 輕微參差不齊/可變深度層次
輕微參差不急層次沒有固定的層次深度，但層次深度有限。地理層次深度通常包含3到6層。
6.3 具有層次橋接表的參差不齊/可變深度層次
在關系數據庫中，深度不確定的可變深度層次非常難以建模。這個問題可以通過在關系型數據庫中采用構建橋接表方式建模參差不齊層次來解決。這樣的橋接表對每個可能的路徑保留一行，確保能夠遍歷所有層次的形式。
6.4 具有路徑字符屬性的可變深度層次
可以在維度中采用路徑字符屬性，以避免使用橋接表表示可變深度層次。對維度中的每行，路徑字符屬性包含特定的嵌入文本字符，包含從層次最高節點到特定維度行所描述節點的完整路徑描述。
7.高級事實表技術
7.1 事實表代理鍵
代理鍵可用作所有維度表的主鍵。此外，可使用單列代理事實鍵，盡管不太需要。不與任何維度關聯的事實表代理鍵，是在ETL加載過程中順次分配，可用於
1. 作為事實表的唯一主鍵列
2. 在ETL中，用作事實表行的直接標識符，不必查詢多個維度
3. 允許將事實表更新操作分解為風險更小的插入和刪除操作
7.2 蜈蚣事實表
一些設計者為多對一層次的每層建立不同的規范化維度，例如，日期維度、月份維度、季度維度和年維度等，並將所有外鍵包含在一個事實表中。
7.3 屬性或事實的數字值
設計者有時會遇到一些數字值，難以確定將這些數字值分類到維度表或是事實表的情況。典型的實例是產品的標准價格。如果該數字值主要用於計算目的，則可能屬於事實表。如果該數字值主要用於確定分組或過濾，則應將其定義為維度屬性，離散數字值用值范圍屬性進行補充。在某些情況下，將數字值既建模為維度又建模為屬性是非常有意的，例如，定量准時交貨度量以及定性文本描述符。
7.4 日志/持續時間事實
7.5 頭/行事實表
7.6 分配的事實
7.7 利用分配建立利潤與損失事實表
7.8 多種貨幣事實
7.9 多種度量事實單位
某些業務過程需要事實同時以多種度量單位表示。例如，按照業務用戶的觀點，供應鏈可能需要對相同事實以平台、船運、零售以及單個掃描單元構建報表。如果事實表包含大量事實，而每個事實都必須以所有度量單位表示，此時較好的方式是將事實以公認的標准度量單位存儲，同時存儲標准度量與其他度量的轉換系數。這種事實表可按照不同用戶的觀點部署，使用適當選擇的轉化系數。轉換系數必須存儲在事實表行中以確保計算簡單正確，並盡量降低查詢復雜性。
7.10 年-日事實
7.11 多變SQL以避免事實表間的連接
7.12 針對事實表的時間跟蹤
存在三種基本事實表粒度：事務級別、周期快照和累積快照。個別情況下，在事實表中增加行有效時期、行截止日期和當前行表示是非常有用的，與采用類型2緩慢變化維度，在事實行有效時獲取時間的方式類似。
7.13 遲到的事實
8.高級維度技術
8.1 維度表連接
8.2 多值維度與橋接表
經典的維度模式中，每個與事實表關聯的維度都有一個與事實表粒度一致的單一值。但是在某些情況下，維度存在合理的多值。例如，某個病人接收了一次健康體檢，可能同時出現多個診斷。在此情況下，多值維度必須通過一組維度鍵通過橋接表使一組中的每個診斷與事實表一行關聯。
8.3 隨時間變化的多值橋接表
8.4 標簽的時間序列行為
數據倉庫中幾乎所有的文本都是維度表中的描述性文本。數據挖掘客戶聚類分析通常產生文本化的行為標簽，通常可以用作區分周期，在此情況下，跨時間范圍的客戶行為度量稱為由這些行為標簽構成的一種的序列，該事件序列應該以位置屬性被存儲在客戶維度中，包含可選文本串，構成完整的序列標簽。行為標簽在位置設計時建立，因為行為標簽是復雜並發查詢並不是數字計算的目標。
8.5 行為研究分組
8.6 聚集事實作為維度屬性
商業用戶通常對基於聚集性能度量的客戶維度感興趣。例如，過濾去年或整個階段所有花費超過一定數額的客戶。選擇聚集事實可以放入作為約束和作為行標識報表的目標維度。度量通常表示為度量表中的帶狀范圍。維度屬性表述聚集性能度量將增加ETL處理的負擔，但是可以方便BI應用層的分析功能