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