一. 建模過程概述
開始討論維度建模設計工作前，必須考慮正確的人選 。最值得注意的是，我們強烈主張業務代表參加建模會議 。他們的加入與合作必然會增加最終模型解決用戶需求的可能性。同樣，組織的業務數據 管理人員也應該參加 ，特別是當討論涉及那些由他們來管理的數據時。
維度模型的構建是一個具有高度動態性且需要迭代產生的過程 。最初的準備過程完成後，設計工作將開始處理從總線架構獲取的圖形化模型 ，確定設計範圍並澄清所提出的事實表及相關維度表的粒度 。
高級模型設計完成後，設計小組將開展針對維度表屬性 、領域值 、來源 、關係、數據質量關注點和轉換等方面的工作。確定維度後，將建模事實表 。建模過程的最後階段是與感興趣的夥伴，特別是業務代表們一起對模型進行評審和驗證工作 。主要目標是建立滿足用戶需求的模型 ，檢驗加載到模型中的數據的可用性，爲ETL小組提供最初的源到目標的映射。
維度模型通過一系列設計會議展開，每一次會議將產生更詳細 、更健壯的按照業務需求反覆測試過的設計結果 。當模型清楚地滿足用戶需求後，結束建模過程。通常需要三四周時間完成一次業務過程維度模型的設計 ，當然需要的時間會隨着小組的經驗 、詳細業務需求的可用性 、涉及的業務代表或授權負責管理組織數據的人員 、數據源的複雜程度 、利用現存一致性維度的能力等的差異而存在較大的差異。
二. 組織工作
開始構建模型前，爲使維度建模過程能夠順利開展 ，必須開展適當的準備工作。除準備好適當的資源外，還需要考慮後勤保障問題，以便能夠富有成效地開展設計工作 。
2.1 確定參與人 ，特別是業務代表們
最好的維度模型往往是小組努力協同工作的結果 。沒有哪個個人能夠掌握有效地建立模型所需要的業務需求的所有知識以及源系統的所有特性 。儘管數據建模人員能夠使建模過程更加容易並專門負責交付物，但我們相信讓業務出身的主題業務專家參與其間是至關重要的：他們的見識是無價之寶 ，特別是因爲他們是那些能夠指出如何從源數據中得到數據並將這些數據轉換爲有價值的分析信息的人員 。儘管在設計活動中加入更多的人會增加過程變慢的風險，但得到豐富的、完整的設計可以證明這一額外的開銷是值得的 。
讓某些具備實際涉及的源系統的知識的人蔘與是非常有益的 。您可以將數據庫管理員 (DBA）和 ETL 小組代表加入到小組中 ，這樣他們既能夠學習到建模工作過程中揭示的知識 ， 又能夠抵制應用第 3 範式 (3NF)概念的誘惑或按照BI 應用的複雜性努力使 ETL 過程更加合理。記住目標是在 ETL 過程的複雜性與 BI 展現層的簡單性和可預測性之間取得平衡 。
深入討論建模過程前，應該花點時間考慮正在開展的DW/BI 環境問題 。如果組織正在考慮數據治理和管理計劃 ，那麼現在正是開展這 一計劃的合適時間 。如果沒有相關的管理 計劃 ，則正好是開始這 一計劃的良機 。企業 DW/BI 工作致力於維度建模同時也必須致力於 一致性維度策略 以確保整個企業業務過程的 一致性 。有效的數據管理程序能夠幫助組織實 現一致性維度策略 。在大型企業中要實現 一致性維度是非常困難的 。問題通常主要不在技術方面 ，而是組織交流和達成共識的挑戰 。
企業中不同的小組通常致力於自己專有的業務規則和定義 。數據管理人員必須與相關的小組緊密合作，開發公共的業務規則和定義 ，然後在組織中游說 ，讓大家都使用公共規則和定義以獲得企業的一致認可 。多年來，始終有人在批評一致性維度 “太強硬”。是的 ， 讓企業中不同領域的人們同意採用公共的屬性名稱、定義及數值是非常困難的事情 ，但這樣做的要義在於能夠獲得統 一的、集成的數據 。如果每個人都使用自己的標識和業務規則， 就沒有辦法發佈一種 DW/BI 系統承諾提供的統一版本的真實集合 。最後，Kimball 方法時常被批評說它對那些希望找尋快速解決方案的人來說非常困難的原因之 一是我們闡述了實際完成工作的詳細步驟。
2.2 業務需求評審
開始建模之前，小組必須熟悉業務需求 。第 1 步是仔細評審業務需求文檔 。將業務需求轉換爲靈活的維度模型，用於支持範圍廣泛的分析，而不是僅僅支持特定的報表 。某些設計人員試圖跳過需求評審直接進入設計，如果這樣做，最後建立的模型通常是源數據驅動的而沒有考慮業務團體需要的增加的價值 。讓業務代表加入到建模小組中有助於避免此類數據驅動的方法 。
2.3 利用建模工具
開始建模活動前 ，準備一些工具是非常必要的。使用電子報表作爲最初的文檔工具是 有效的 ，因爲利用它可以在反覆法代過程中方便井快速地實施變更 。
在建模活動進入最後階段後，可以方便地將工作轉換到企業所使用的任何類型的建模工具中。多數建模工具都支持建立維度模型的維度設計功能 。在詳細設計完成後 ，建模工具可幫助DBA 將設計的模型 置換到數據庫中 ，包括建表 、索引、分區 、視圖及數據庫的其他物理元素 。
2.4 利用數據分析工具
在整個建模過程中 ，小組需要隨着理解深入不斷地開發源數據結構 、內容、關係和獲取規則。需要對處於可用狀態的數據進行驗證 ，或者至少可以對缺陷進行管理，瞭解在將它們轉換到維度模型時需要做些什麼 。數據分析（data profiling）利用查詢能力探索源數據系 統中實際存在的內容和關係 ，而不要依靠那些不完整的或過期的文檔 。簡單的數據分析工 作可以通過編寫簡單的 SQL 語句實現 ，複雜的數據分析工作可以通過專用工具來實現 。主 要的 ETL 提供商提供的產品 一般都包括數據分析功能 。
2.5 利用或建立命名規則
在建立維度模型的過程中 ，不可避免地會遇到命名規則的問題 。數據模型的標識必須 是描述性的並且與業務場景 一致 。表 和列名是 BI 應用接口的關鍵元素 。類似 “ 描述 (Description ）” 這樣的列名在數據模型環境中可能己非常清楚了 ，但對於報表環境來說 ，這 樣的命名顯然達不到交流的效果 。
設計維度模型的部分過程集中於對公共定義和標識的認定 。由於不同的業務小組可能對同一個名稱具有不同的理解（同名異義 ），或者不同的名稱表示的 是同種含義（異名同義）， 結果使命名工作非常困難 。人們一般都不願意放棄自己熟悉的詞彙而採用新的詞彙 。在命名規則上花費時間是一種看起來意義不大 ，但從長遠來看意義重大的任務 。
大型組織通常設有 IT 部門，專門負責命名規則 。常用的方法是採用包含 三個部分的命 名標準 ：主詞、限定詞（如果適合的話） 、類詞 。利用IT部門的工作成果 ，充分理解對有 已經存在的命名規則進行擴展能夠支持形成更有利於商業交流的表和列名 。如果組織沒有現成的命名規則，則必須在維度建 模過程中建立命名規則 。
2.6 日曆和設施的協調
最後但並非不重要的是 ，需要按照參與者的日程安排來設計會 議日程 。不一定要利用整天的時間 ，可以每週利用三 四天的上午和下午召開持續時間爲兩三個小時的會議 ，這是 比較現實的。這一方法充分考慮到小組成員可能會有其他工作需要處理 ，這樣留出會前、會間和會後的時間讓他們能夠處理於頭的工作 。設計小組可以利用非會議時間研究源數據並確認需求，留出時間讓數據建模人員在每次會議前更新設計文檔 。
如前所述，建模過程通常會用三四周的時間對單一過程開展建模工作 ，例如 ，銷售訂單，或對緊密相關的業務過程開展建模工作，例如，處於不同的但密切相關的事實表中的健康設施和專業要求事務 。多種因素會對工作量造成影響 。最終，先前已經存在的核心維度的可用性使建模工作能夠特別關注事實表的性能度量 ，這樣能夠顯著地降低開展工作所 需要的時間。
最後，您必須保留適當的設施 。在設計工作期間 ，最好能夠保留 一個專用的會議室 ， 當然在大多數組織中 ，這一想法不易實現 ，因爲會議室總是不夠用 。如果會議室的四壁都 有從地板到天花板的自板那就更好了 。除了會議設施外 ，小組還需要一些基本的用品 ，例 如，自粘白板紙。會議期間通 常需要電腦投影儀，設計評審絕對離不開它 。
三. 維度模型設計
在設計維度模型 期間存在 4 個關鍵決策 ：
• 確定業務過程
• 聲明業務過程的粒度
• 確定維度
• 確定事實
第 1 步確定業務過程通常按照需求獲取的結果來確定 。以此爲基礎 ，小組可以開展相關的設計任務。
• 定義模型範圍和粒度的高級模型
• 詳細設計每個表的屬性和度量
• IT 和業務代表的評審和驗收
• 設計文檔定稿
要完成所有 的數據建模工作 ，維度建模要採取法代方式開展 。對需求和源細節要反覆 考慮以進一步精煉模型 ，隨着理解的不斷深入 ，對模型進行必要 的修改。
3.1 統一對高層氣泡圖的理解
設計會議的初始任務是建立目標業務過程 的高層維度模型圖。由於您是從總線矩陣開始的 ，所以第1個草圖的建立相對比較直接 。儘管有經驗的設計人員可能會設計出初始的 向層維度模型井展示給 小組用於評審 ，但我們仍然建議不要採用 這種方法 ，因爲它沒有使整個小組參與到過程中。
高層圖圖形化地表示了業務過程的維度和事實 表 ，如下圖所示 。出於明顯可見的原因，我們將其稱爲氣泡圖 。這一實體級的圖形化模型確定了事實表和與之相關的維度表的粒度，清楚地展現給非技術人員。
粒度描述需要建模小組考慮滿足業務需求需要什麼以及物理數據源能夠提供什麼數據 。氣泡圖必須根據可用的物理數據設計 。總線矩陣 的一行可能會用多個氣泡圖表示 ，每個氣泡閣對應具有特定粒度的特定事實表 。
大多數主要的維度在確定了粒度後可以自然地獲得 。清楚的事實表粒度聲明的重要影響之一是可以精確地以圖示化方法表示有關的維度 。維度的選擇也可能會導致您重新思考粒度聲明 。如果提出的維度無法匹配事實表的粒度 ，那麼要麼不用該維度 ，改變事實表的粒度 ，要麼考慮使用多值設計解決方案 。
關方交流時介紹項目 、項目範圍以及數據內容 。
爲幫助理解 ，在給定業務過程的多個高層模型圖之間保持 一致性是非常有益的 。儘管每個事實表被文檔化到不同的頁面中，將相關的涉及多個氣泡圖的維度安排到 一個相似的 系列中是非常有用的 。
3.2 開發詳細的維度模型
在高層氣泡圖設計完成後 ，就可以開始關注細節了 。小組應該定期見面，以便逐表逐列地定義詳細的維度模型 。業務代表應該參加此類交互會議 ，您需要他們對屬性 、過濾器 、分組、標識和度量的反饋 。
最有效的方法是先開始設計維度表 ，然後考慮設計事實表 。我們建議在開始細節設計過程時己經具備明確的維度表。日期維度一般可以作爲首選開始考慮的維度表 。這樣能夠確保建模小組更早地獲得成功 ，理解建模過程 ，並學會作爲一個 小組而共同工作 。
詳細建模確定每個維度內有趣且有用的屬性 ，並確定每個事實表應該具有的適當的度量 。您也希望獲取源 、定義以及如何獲得這些屬性和度量的基本業務規則 。在設計會議期間對源系統和系統化數據概要的持續分析，將有助於小組更好地理解其擁有的源數據的實際情況。
確定維度及其屬性
在詳細設計階段 ，將定義關鍵的一致性維度 。因爲 DW/BI 系統是企業的資源 ，所以這些定義必須爲整個企業所接受 。數據管理人員和業務分析師是獲得組織一致認可的表和屬性命名、描述和定義的關鍵資源 。設計小組將主導該過程的展開井利用命名規則 （如果存在的話）。但是對標準業務定義和名稱達成致是最終的業務任務，其列名對業務用戶來說必須具有意義 。這一過程可能需要一定的時間才能完成，但這一投資可以獲得巨大回報 ，其結果是用戶願意並接受維度模型 。毫無疑問 ，管理指導委員會必須參與解決一致性維度和命名問題 。
在此點上，建模小組通常還需要充分考慮維度模型中可能包含的雜項維度和微型維度 。直到小組深入開展設計工作後 ，這些更關注性能的模式纔可能會有存在的必要性 。確定事實
聲明粒度是對事實表度量討論的成果，因爲事實都必須與粒度保持一致 。數據分析工作確定了由源系統的度量事件建立的計數和數量。然而，事實表並不會受制於這些 基表 。 可能會存在業務需要分析的來自基表的其他度量。確定緩慢變化維度技術
根據高層模型圖初步設計好維度和事實表後，應當再次考慮維度表的設計 。針對維度表的每個屬性 ，需要定義在源系統數據發生變化時，對維度表會產生何種影響 。再次強調， 業務數據管理員是建立適合的規則的重要來源 。有益的方法是詢問源系統專家是否能夠確 定某個數據元素的變化是由於源數據變化所引起的。建立詳細的表設計文檔
詳細建模階段的關鍵交 付品是設計工作單 。在我們的網站 WWW. kimballgroup.com 上 ，從書名 The Dαtα Warehouse Lifecycle Toolkit, Second Edition 下面的 Tools and Utilities 可以獲得其數字化模板 。通過與感興趣的業務相關方以及其他分析型業務 用戶、BI 應用開發人員 ，以及最重要的參與設計任務的 ETL 開發人員交流獲取工作單的各 個細節 。
應該爲每個維度和事實表建立不同的工作單。支持信息至少應該包含屬性 ／事實名稱 、描述示例值 、每個維度屬性的緩慢變化維度類型標識 。此外 ，詳細的事實表設計應該確認每個外鍵關係 、適當的退化維度 ，以及表明每個事實是可加 、半可加還是不可加的相關規則。
維度設計工作單是建立源到目標映射文檔的第 1 步。物理設計小組將不斷充實物理表 以及列名、數據類型和有關鍵的聲明 。對模型出現的問題進行跟蹤
在設計過程中發 現的所有問題 、定義、轉換規則和數據質量挑戰必須記錄到問題跟蹤日誌中。會議期間應指派專人獲取並跟蹤相關問題 。如果項目經理參與設計會議，則通常由他們擔負這一責任，因爲他們通常精於更新有關問題並負責推進解決發現的問題 。協調人在每次會議結束前應該留出適當的時間用於評審和驗證新的問題條目併爲發現的問題指派負責人。在兩次會議期間，設計小組通常忙於分析數據 ，澄清並達成大家認可的定義， 與源系統專家會面以解決突出的問題。
- 維護並更新總線矩陣
在詳細建模過程中 ，通常對被建模的業務過程會有新的發現。常見的情況是，這些新發現可能會引入新事實表以支持業務過程，可能產生新維度，也可能需要重新劃分或合併維度 。在整個設計過程中，必須始終保持對總線矩陣的更新，因爲總線矩陣是關鍵的交流和規劃工具。詳細的總線矩陣通常獲 取有關事實表粒度和度 量的額外信息。
3.3 模型評審與驗證
一旦設計小組對模型充滿信心後 ，過程將進入到評審與驗證階段，以從其他有關小組 獲得針對模型的反饋意見 ，包括 ：
• IT 資源，例如 ，未參加建模工作的 DW/BI 小組成員 、源系統專家以及 DBA 等
• 未參與建模工作的分析或強力商業用戶
• 範圍廣泛的商業用戶團體
IT 平審
通常，對詳細維度模型的第 1 次評審主要由 IT 組織同行參與 。評審人員通常由非常熟悉目標業務過程的人員組成，因爲他們設計或管理運行 的系統。至少他們可能熟悉部分的 目標數據模型，因爲您己經就與源數據相關的問題和 他們打過交道。
IT 評審是極具挑戰性的 ，因爲參與者通常都不太瞭解維度模型 。實際上 ，他們中的大 多數人可能都是精通並狂熱的第 3 範式（3NF）支持者 。他們趨向採用面向過程的事務型建模 規則處理維度模型 。與其將大量時間放到爭論不同建模方法 的優缺點上 ，不如在評審過程 巾積極主動地提供一些維度建模教育 。
當每個人都瞭解一些基本概念後，首先應該從總線矩陣開始評審 。這樣做可以讓參與 人對項目範圍和整個的數據結構有一些理解，闡明一致性維度的作用 ，展示相關的業務活 動優先順序 。接下來，描述如何從 總線矩陣上選擇行 ，並將其直接轉換到高層維度模型圖中。這樣做，可以讓所有人看到實體級別的模型映射 ，有利於後續討論的開展 。
多數評審會議主要通過瀏覽維度和事實表工作單細節開展 。在會議期 間，討論模型時， 對每個表存在 的問題進行評審也是非常好的辦法 。
會議可能會對模型進行修改 。記住要指定小組成員專門負責獲取相關 的問題和建議。核心用戶評審
在多數項目中 ，並不需要這樣的評審 ，因爲核心商業用戶都 是建模小組的成員且已經對維度模型有深刻的理解 。如果核心商業用戶未成爲建模小組成員 ，則核心用戶評審會議與IT評審會議的範圍和結構類似。核心商業用戶具有比普通商業用戶更強的技術背 景並能 夠處理模型 的細 節 。在小型組織中，經常將IT評審和核心用戶評審合併到一個會議中 。-
廣泛的業務用戶評審
這樣的會議與其說是設計評審 ，不如說是教育與培訓 。您希望就相關 內容給人們以教育和啓迪而不是強迫他們接受 ，同時應該描述維度模型如何能夠支持業務需求 。應當從企業DW/BI數據路標的總線矩陣開始 ，評審高層模型氣泡圖，最後 ，評審關鍵維度 ，例如客戶和產品維度等 。有時，在講解氣泡圖時輔以如下圖所示的描述維度中 的層次下鑽路徑 。
![]()
記得在這樣的教育／評審會上要分配 一定的時間用於描述如何使用模型來回答有關業務過程的範圍廣泛的問題。我們通常會在需求文檔中加入 一些示例 ，並簡略地說明如何解 決這些示例的問題。
- 形成設計文檔
在模型穩定後 ，應該對設計小組的工作文件進行編制 ，形成設計文檔 。該文檔通常包括：
• 項目的簡短描述
• 高級數據模型圖
• 詳細的針對每個事實和維度表的維度設計 工作單
• 開放的問題
參考:
- 《數據倉庫工具箱 維度建模權威指南》第三版