一. 生命週期初始活動
1.1 程序／項目規劃與管理
毫無疑問，DW/BI 始於一系列的程序和項目規劃活動 。
1.1.1 評估準備
在開始 DW/Bl工作前 ，有必要花點時間評估組織的準備工作 。基於與上百家客戶約談所積累的經驗 ，我們認爲有三種因素可用於區分項目能夠順利開展還是需要付出艱辛的努力。這些因素將成爲決定 DW/BI 是否成功的先行指標 。我們將按照重要性討論這些特徵 。
最關鍵的準備因素是有一個強有力的執行業務主管 。業務主管應該對 DW/BI 系統對組織的潛在影響具有清晰的認識 。最佳情況是，業務主管具有成功完成其他內部活動的經歷 。 他們應該是能夠說服其他領導支持該項目的政策上精明的領導 。如果首席信息官（CIO）是指定贊助商 ，則項目將會冒更大的風險 。我們更喜歡現實的承諾而不是業務同事 。
準備期間第 2 個主要的因素是有一個強大的 、解決 DW/BI 活動的引人注目的動機 。這一因素往往與發起工作齊頭並進。DW/BI 項目需要解決關鍵的業務問題 ，這一工作需要爲獲得成功的開始和健康的生命期而獲取資源 。引人注目的動機通常會建立一種緊迫感 ，無 論這一動機是來自於外部資源 ，例如 ，競爭因素 ，還是內部資源 ，例如 ，完成收購後無法 對跨組織的指標進行分析等 。
第 3 個因素是評估準備的可行性 。可行性包含幾個方面的內容 ，儘管也涉及技術和資 源的可行性 ，但數據可行性最爲重要 。從實際的操作型源系統中收集的數據能夠支持業務 需求嗎 ？數據可行性是最重要的關注點 ，因爲如果無法以正確的粒度收集需要的源數據 ， 項目將無法在短期內完成 。
1.1.2 範圍及論證
在熟悉了組織的準備工作後 ，需要確定項目的邊界範圍 。確定範圍需要 IT 組織和業務 管理的聯合輸入 。DW/BI 項目的範圍對業務組織來說要有意義 ，對 IT 組織來說要可 管理。 應該先考慮關注單一業務過程的數據 ，這樣可以減少很 多困難，然後處理多過程項目 。記 住在確定範圍時要避免 “ 太” 規則一一項目時間表 “ 太” 短暫，涉及 “太” 多的系統 ，包 含 “ 太” 多的位於 “ 太” 多不同位置的具有 “ 太” 多不同分析需求的用戶 。
項目論證需要評估與 DW/BI 初啓工作有關的利 益和成本。理想的結果是 ，預期收益遠 遠大於成本 。信息技術通常是成本的主要來源 。DW/BI 系統趨向於快速擴展 ，因此評估一 定要考慮短期增長的空間 。與操作型系統開發不同 ，操作型系統在投產後對資源的需求會 變得越來越小 ，而對 DW/BI 支持的需求不會隨着時間的推移而顯著下降 。
業務團體主要負責確定預期財務收益 。DW/BI 環境的驗證通常基於增加收益或利潤的可 能性而不是僅僅關注降低費用 。僅僅提供 “唯一的真實版本” 或 “對信息的靈活存取” 顯然 還不能構成充分的財務論證 。需要層層深入地確定這些 方面對獲得高質量的決策制定的影 響。如果您正在開展論證工作 ，就會發現項目初啓 關注的可能是錯誤的業務發起或問題 。
1.1.3 人員配備
DW/BI 項目需要集成不同的功能小組以及來自業務和 IT 領域的不同資源 。同一個人 在小組中往往需要扮演不同的角色 。將命名的資源分配給角色需要考慮項目的大小及範圍 ， 以及每個人的可用性 、能力和經驗 。
從業務層面考慮 ，我們需要扮演下列角色的人員 ：
業務發起人 ：發起人是 DW/BI 系統的最終客戶 ，同時他們也是系統最強大的支持 者。發起人有時採用執行董事委員會的方式存在，特別是當發起人涉及多個企業時。
業務驅動者 ：在大型企業中 ，項目發起人可能地位較高或不能直接與項目組打交 道。在此情況下 ，發起人有時會將 DW/BI 系統中那些不具備戰略性的責任指派給 組織中的中層管理人員 。此時，業務驅動者與業務發起人具有同樣的特徵 。
業務領導者 ：商業項目領 導者應該是一位受大家尊敬的人 ，他應該將主要精力投 入到項目中 ，每天都與項目經理交流 。有時可 以由業務驅動者扮演這一角色。
業務用戶 ：理想的情況是 ，商業用戶是 DW/BI 的狂熱粉絲 。他們需要儘早且經常 性地參與確定項目範圍和業務需求 。從此，您必須找到創造性的方法在項目推進 過程中不斷地維持他們對系統的興趣和參與熱情 。記住 ，業務用戶的參與是DW/BI 能夠被接受的關鍵因素 。沒有商業用戶的參與和支持 ，DW/BI 系統就變成徒勞的 技術訓練 。
幾個位置的人員配置來自業務或 IT 組織。這些人員可以作爲了解業務的技術資源或了 解技術的業務資源 。業務分析師 ：業分析師主要負責確定業務需要並將需求轉 化爲結構 、數據和商業 應用需求 。
數據管理師 ：作爲主題專家 ，數據管理師通常是當前處理特設分析的 “ 關鍵” 人 力資源 。他們理解數據的含義 ，如何使用這些數據 ，何處可能存在數據不一致情 況 。考慮實現圍繞核心多維數據在組織中的共同理解問題 ，這是一個具有挑戰性 的角色，正如我們在第 4 章 “庫存” 中所描述的那樣。
Bl 應用設計人員／開發人 員：BI 應用資源負責設計並開發分析模板的最初集合 ，並 提供持續的 BI應用支持 。
以下角色通常來自 IT 組織：
項目經理 ：項目經理是 一個關鍵的角色 ，應該由高管們和技術團隊滿意的並受尊 敬的人來擔任 。項目經理必須具備交際和項目管理技能 。
技術架構師 ：架構師負責總體技術架構 。需要制定計劃將需要的技術功能粘合到 一起並能夠從總體技術架構的角度評估各種製品。
數據架構師／建模者 ：這一角色通常由強調規範 化的具有事務型數據背景 的人來擔 任 。他們支持維度建模概念並瞭解業務需求 ，而不是僅僅關注節省空間或減少 ETL 工作負載。
數據庫管理員 ：類似數據建模者 ，數據庫管理員應該放下一些傳統的數據庫管理 的看法 ，例如 ，在一個關係表中只應該建立 一個索引等。
元數據協調人 ：該角色幫助建立元數據庫策略並確保能夠收集 、管理 、發佈適當 的元數據。
ETL 架構師／設計人 員：該角色負責設計 ETL 環境和過程。
ETL 開發人員：在 ETL 架構師／設計人 員的指導下，開發人員建立並自動 化過程， 可能會要求使用 ETL 工具。
找們再次指出上述列表羅列的是角色 ，而不是具體的人。特別是在一些小型企業中 ， 具有多種技能的個人可以同時擔任多個角色 。
1.1.4 規劃的開發及維護
DW/BI 規劃要區分所有必要的生命週期任務 。詳細的任務列表可參考 Kimball 工作組 的網站 www.kimballgroup.com 。單擊書名爲 The Data Warehouse Lifecycle Toolkit, Second Edition 下面的 Tools & Utilities 標籤進入 。
任何瞭解小組成員的優秀項目經理應該制定不同任務需要的開發工作 量估計 ，項目經 理無法保證允許與期望的時間總能保持 一致。在每個主要 的里程碑和發佈物產生後 ，項目 規劃應該確定由業務代表參加的驗收檢查點 ，以保證項目按計劃推進。
DW/BI 項目需要廣泛的交流 。儘管項目經理通常擅長小組內交流 ，但仍然需要建立交 流策略以便爲其他參與者描述頻度 、討論會和重要消息 。其他參與者主要包括業務發起人 、 業務團體和其他 IT 同行。
最後 ，因爲非常需要滿足商業用戶的需求 ，因此 DW/BI 項目的範圍極易發生變化 。在 面對變化時 ，應該具有多種選擇：增加範圍（通過增加時間 、資源或預算），執行零和（zero-sum ) 遊戲（以放棄某些要求爲交換條件而保持原有範圍不變） ，或說 “ 不” （並非直接否定，而是 通過將變化當成增強的需求來處理） 。關於範圍的決策 ，最重要的事情是不應該只考慮 IT 的問題。正確的回答是依賴環境 。現在是利用業務夥伴 關係給出所有參與者都能夠接受的 答案的時候了 。
1.2 業務需求定義
要構建一個成功的 DW/BI 系統，最重要的工作是與商業用戶緊密合作 ，瞭解他們的需 求並確保他們的投入是有價值的 。
1.2.1 需求預規劃
在開始與業務代表坐下來收集業務需求前 ，爲保證會議的效果，我們提出以下建議 。
選擇討論話題
業務用戶需求討論會通常也涉及源系統專家的數據發現 。這種雙管齊下的方法能夠洞 悉業務需要及數據現實 。然而，不要問業務代表關於他們的關鍵數據的粒度和維度的問題 。 應該問他們希望做什麼 ，爲什麼要做 ，他們是如何制定決策的 ，他們希望未來能制定什麼樣的決策 。與對組織的治療類似 ，他們試圖發現問題和機會 。
獲取需求主要可以採用兩種技術 ：用戶訪談或用戶聯席會 。這兩種技術各有優缺點 。 用戶訪談鼓勵個人參與並且比較容易調度 。聯席會可以減少收集需求的時間 ，但對每個參 與者來說 ，需要花費更多的時間 。
基於我們的經驗 ，調查表並非是獲取需求的合理工具 ，因爲它們是平面的 、二維的。 其自選項僅包含那些我 們提前考慮好的答案 ，無法獲得更深入的情況 。此外 ，調查表方式 不利於我們努力要獲得的業務用戶與 DW/BI 發起人之間的聯繫 。
我們通常採用混合訪談方式獲得細節並通過聯席會議達成小組共識 。儘管我們會更詳 細地討論這一混合方法 ，多數討論可應用於聯席會議 。需求獲取論壇選擇依賴小組的技能 、 組織的文化以及業務用戶已有的業務 。一種方法並不能適用於所有的環 境。確定及籌備需求小組
無論採用哪種方式 ，都需要確定並籌備相關 的項目組成員 。如果您正在開展用戶訪談 工作，需要確定訪談負責人 ，其主要責任是 問一些開放式的問題 。同時，需要訪談抄錄員 記錄大量 的筆記。儘管使用錄音設備可以提供更完整的訪談內容 ，但我們不使用它 ，因爲 使用它會改變訪談的動態性 。我們寧願其他人員參加訪談也不依賴相關技術 。我們通常邀 請一個或兩個額外的項目成員 （要根據受訪者的數 量來定）作爲觀察員 ，這樣他們能夠直接 獲取用戶的需求 。
在與商業用戶交談前 ，需要確認自己以正確的心態來看待討論會 。不要認爲自己已經 什麼都清楚了 ，您一定會通過交談更進一步地瞭解業務 。另一方面 ，應該提前做點功課 ， 研究可用的資源 ，例如 ，年報 、網站和組織內部的圖表 。
得到正確答案的關鍵是正確 地提出問題 ，我們推薦起草 一個問卷調查 。不應該將問卷 調查視爲 一種劇本 ，它是一種用於組織您思想的工具 ，作爲在討論會期間 ，一旦您的想法 出現空白時可用的後備裝置 。在訪談過程中 ，當小組對業務主題事直更加了解的情況下 ， 調查問卷將被 更新。選擇、調度和準備業務代表
如果您是初次接觸 DW/BI ，或者是開發 一種處理現存數據的孤立狀態的銜接策略 ，您 應當與合理代表組織各方面業務的 人員交談 。合理 的範圍對制定企業數據倉庫總線矩陣藍 圖至關重要 。您需要理解涵蓋核心業務功能的公共數據詞彙 ，以便能夠建立一個可擴展的 環境 。
在 目標用戶團體內部，應當垂直地覆蓋組織 。DW/BI 項目小組自然地趨向於構建企業 強大的分析能力。儘管他們的見識是有價值的 ，但不能忽略企業高級和中層管理人員 。否 則就會過度關注 戰術，而把握不住小組的戰略方向 。
調度業務代表是最艱鉅 的需求任務 ，特別是要得到部門行政助理的幫助 。我們願意單 獨約見執行經理 。當約見處於組織機構中較低級別的人員時 ，將類別相同的兩 三個人分爲 一組同時會談是 比較合適的。一般單獨訪談的時間控制在 1 小時左右 ，小組訪談的時間控 制在 1.5 小時左右 。調度者需要 在會議之間安排 半小時時間用於處理彙報和其他事直 。出 於對新要求 的關注 ，訪談過程涉及的工作將極其繁 重 。因此，在一天中儘量只安排三四次 會議 。
在約見受訪者前 ，業務發起人應該與受訪者進行溝通 ，強調他們對該工作的承諾和每 個參與者 的重要性 。可以要求受訪者將其關鍵報表和分析的復件帶入會場 。這樣的溝通方 式傳播了一種一致的消息 ，並表達 出對業務用戶重要性的肯定 。有些時候 ，業務用戶不太 願意將關鍵 的報表帶米參加會議 。然而 ，我們發現在訪談結束後 ，這些人幾乎總是回到其 辦公率將這些報表帶問。
1.2.2 收集業務需求
現在是開始面對面 收集業務需求的時候了 。過程通常按照結構化問詢到最後的文檔形 成這一流程 。
初啓
在會議室收集需求前 ，首先要指定介紹會議的責任人 。該責任人應當用最初的幾分鐘 根據擬定的訪談會基調描述訪談要點 。這一介紹應該傳達簡單明晰的以業務爲中心的信息 ， 不要漫無邊際地介紹硬件 、軟件和其他技術術語 。訪談流程
訪談的目標是讓業務用戶說清楚他們做什麼和爲什麼要做 。簡單溫和的開啓話題的方 式是詢問受訪者的工作職責和在組織中所處的位置 。這一話題是每個受訪者都容易回 答的 問題。此後 ，通常會詢問 一些受訪者的關鍵指標度 量。確定他們是如何跟蹤進展併成功地 將這些指標直接放入到維度模型中 ，不需要您直接提問 ，他們就會將其關鍵業務過程和 事 實告訴您。
如果訪談對象有較高的應用數據經驗 ，應該考慮如何更好地通過訪談者理解業務的多 維性。類似 “您如何區分不同的產品（或代理商 、供應商或設施） ？” 或 “ 如何自然地分類 產品 ？” 等問題有助於識別關鍵維度屬性和層次 。
如果受訪者更側重分析工作 ，則詢問當前建立的分析類型 。理解這些分析工作的特性 ， 無論它們是自組織的還是標準的 ，將它們作爲 BI 工具需求以及 BI應用設計過程的輸入 。 理想情況下 ，受訪者會帶來關鍵圖表和報表的拷貝 。與其將它們放入文件夾中 ，不如立即 瞭解一下受訪者是如何進行分析的 ，可以作爲進一步改進的機會 。某些行業專家建議 ，您 不能將可擴展的分析環境設計成 一個僅僅能夠滿足用 戶最主要的 5 個報表的環境 。用戶的 問題必然會發生變化 ，因此決不能將設計關注點僅僅放在最 重要的 5 個問題上 。
假如與管理人員會面 ，不要落入這樣的戰術性細節中 。相反 ，應該詢問他們對於更好
地在整個組織中利用信息的構想 。也許項目小組設想構建 一個自組織環境 ，而業務管理層 對發佈標準化的分析更感興趣 。您需要確保 DW/BI 發佈物匹配業務需求和期望 。
詢問每個受訪者有關改進信息訪問的 影響問題。您可能 已經接收了初期項目資金 ，但 獲取更多潛在的 、可量化的利益 是有益無害的。形成最終文檔
在訪談進入最後總結階段時 ，請每個受訪者提出有關項 目成功的關鍵評判標準 。當然，關 鍵評判標準應該是可 度量的。“ 易於使用” 和 “快捷” 對每個人來說都有不同的考慮 ，因此， 受訪者需要提出清晰的細節 ，例如 ，他們爲運行預定義的 BI報表所需要花費的訓練次數 。
在這一情況下 ，始終要制定一個寬泛的免 責聲明。讓受訪者理解儘管在會議中討論了 能力問題 ，但不能保證討論的能力能夠在項目的 第 l階段就予以實施。感謝受訪者才華橫、溢的洞察力 ，讓他們知道下 一步將會做什麼，以及需要他們參與哪些工作 。
指導以數據爲中心的訪談
在關注理解業務 需求的過程中 ，讓源數據專家或主題業務專 家參加訪談會以評估支持業務需求的可行性是非常有益的 。開展這些以數據爲中 心的訪談與前面討論的那些訪談是不同的 。目標是查明在建立需求的動力前 ，需要的核心數據是否已經存在 。在以數據爲中心的訪談中 ，您可以深入瞭解 一些初期的隨後需要提供的數據分析結果 ，例如，一些關鍵 數據字段的領域值和計數 ，這樣可以確保您不至於站在流沙之上 。在維度建模過程中 ，將進行更加全面的數據審計 。在該點上努力學習 ，就可以恰當地管理組織的期望 。文檔化需求
訪談後緊接着需要做的事情是 ，訪談小組應完成詳細的訪談報告 。確認每個 小組成員 所記錄的內容 。如果每個人都能在會議後 ，趁對訪談內容尚具有清 晰記憶時 ，快速總結自 己的筆記是非常有用的，這樣做可以填補空白 。筆記中的縮略詞和記錄不全的句子在幾天 後會變得難 以理解。同樣，需要檢驗收集的報告以贏得對更多數據倉庫必須支持的多維性 的見解。
此後 ，可以將所聽到的內容變成文字材料 。儘管形成文檔是大家都不太喜歡做的工作 ， 但文檔無論是對用戶驗證 ，還是作爲項目組參考材料來說都是非常重要的 。在需求過程中 將形成兩個可能的文檔類別 。第 1 個文檔是記錄下每個訪談 ，該活動需要花費大 量時間， 因爲記錄不能僅僅是對意識流的抄寫 ，重要的是能夠使那些未參會的人 也能夠理解 。合併 結果的文檔是最爲關鍵的文檔 。該文檔將圍繞業務過程來組織 。因爲DW/Bl 項 目的處理是 以逐個的過程爲基礎的 ，因此將業 務需求放入不同 的領域中是非常適當的，這樣可以按照 不同領域開展實施工作 。
在完成合並文檔時 ，應該撰寫執行綜合文檔 ，緊接着撰寫項目概述 ，包括用到的過程 和有關的參與者 。總體上說 ，文檔要 以業務過程爲中心 。對每個過程 ，要描述爲什麼業務 用戶期望分析過程的指標度量 ，他們需要得到何種能力 ，當前他們所受到的限制 ，可能存 在的好處或影響是什麼 。處理每個過程的可行性評論 也是非常重要的 內容 。-
需求優先級
綜合結果文檔將成爲後面爲高管層和其他需求參與人員展示的基礎 。難以避免的是 ， 您不可能通過一次迭代就涵蓋所有需要處理的需求，因此需要考慮優先順序 。正如在討論項目範圍時所提到的那樣，不要憑空制定優先順序，需要與業務團隊的合作者 一起來建立 合適的優先順序。
在結果評審和優先順序考慮會議上要彙報需求總結 報告。參與者包括高級業務代表（參 與過訪談會 的優先），以及 DW/Bl 管理者和其他高級 IT 管理人員。會議 以概述每個確定的 業務過程開始 。應當使每個參與者對機會有共 同的理解。也可以評審機會／利益相關方矩陣 ， 以及簡化的總線矩陣 。
最終成果提交後 ，開始考慮優化使用如下 所示的優先級網格 。網格的縱制｜ 表示業 務潛在的影響或價值 。橫制l表達可行性 。每個最終成果的業務過程 主題按照業務代表 們所 確認的有關影響和可行性的綜合情況米放置 。它圖形化地表示 出您應該從哪裏着手 。需要 優先關注的項目位於右上角，因爲它們代表的是影響大、可行性高的項目 。而位於 左下角 的項目要盡力避免 ，它們對業務沒有 多少價值 。同樣，位 於右下角的項目也沒有短期啓動的意義，儘管項目組有時會被它們吸引，囚爲這些項目是可行的，但並非關鍵的。最後，左上角項目表示那些有意義的機會。這些項目具有較大的業務投資價值 ，但當前可行性不強。當 DW/BI 項目小組關注右上角陰影部分的項目時，其他 IT 小組應該解決那些位於 左上角的當前可行性受到限制的項目 。
![]()
1.3 生命週期技術路徑
1.3.1 技術架構設計
與新家的藍圖類似，技術架構是描繪 DW/BI 環境的技術服務和基礎設施的藍圖。類似裝修房屋的藍圖 ，技術架構包含 一系列揭示每個主要部件細節的模型 。無論哪種情況 ，架構確保能夠抓住紙面上的問題 （例如 ，洗碗機離水槽太遠），並減少項目中期的詫 異。支持並行工作 ，通過重用模塊化的組件加快開發進度 。架構可 以確定哪些是馬上就需 要的組件 ，哪些是可 以稍後完成的（例如 ，地面和玻璃門廊） 。最重要 的是，架構可作爲 交 流工具 。家庭建築藍圖可使建築師 、總承包商 、分包商和房屋主人通過 一個公共文檔進行 交流。同樣，DW/BI 技術架構支持在組內 、上層的管理者和外部的承包商間建立 一個對技 術需求具有一致性的集合 。
DW/BI 小組通常從架構設計過程範圍的兩端着手 。一些小組根本無法理解架構的益處， 感覺主題和任務太過模糊 。他們非常關注交付物 ，認爲架構像是 一種阻礙並干擾其工作進 展的東西，因此他們選擇繞過架構設計 。實際上 ，他們將完成第1次迭代所需要的組件使用口香糖和電線捏合起來 ，換來的是集成和接口需要花費更大的代價來增加更多的數據 、更多的用戶和更多的功能 。最終，這些小組需要重新構建 ，因爲沒有架構的結構無法承受壓力 。另外一種極端情況是 ，某些小組期望花費兩年的時間設計架構，忘記了 DW/BI 環境 的主要目的是解決商業問題，而不是解決任何貌似有理 （實際上並無道理）的技術挑戰。
從設計範圍的兩端開始都是不健康 的。最適當的響應應該是從中間開始 。我們將支持 以下的 8 步過程來幫助大家開展結 構化設計工作 。每個 DW/BI 系統都包含一個技術架構 ， 問題在於其規劃是清楚還是模糊 。
建立架構工作組
建立一個僅包含兩三個人的重點關注架 構的工作組是非常有用的。通常，他們由技術架構師組成，包括ETL架構師／設計師和BI應用架構師／設計師，這些人能夠代表後端和前端環境 。收集與架構有關的需求
建立架構主要是爲了支持業務需求 。不能將它當成購買最新的 、最好的產品的藉口 。實際上，設計過程的關鍵輸入來自業務需求定義 。然而 ，對待業務需求 ，需要有選擇地獲取，主要獲得那些能 夠驅動架構設計的需求 。主要關注點在於揭示出那些能夠對架 構產生影響的業務需求 。重 點關注涉及時間、可用性和性能方面的需求 。
您還應該召開 IT 組織內部的訪談會 。這些會議重點關注技術，以理解當前的標準，規 劃技術方向 以及確定邊界。此外，需要揭示那些從先前開展的信息交互產物中學習到的經 驗和教 訓 ，以及組織的有關用 DW/BI 項目適應操作變化的意願 ，例如 ，確定源系統中更新 的事務。架構需求 文檔化
在利用業務需求過程以及召開輔助性的訪談後 ，需要對產生的結果文檔化 。我們建 議使用簡單的圖表形式 ，僅需要列出影響架構的業務需求 ，以及受影響的架構的詳細列表 。 例如 ，如果需要每晚發佈總體銷售性能數據 ，那麼對技術方面的影響可能是 全局範圍內的 24月的可用性問題 ，爲加載需要進行的數據鏡像 ，支持全局訪 問的元數據的健壯性 ，適當 的網絡帶寬，足夠的用於處理操作型數據集成的 ETL 能力等。
建立架構模型
文檔化架構需求後 ，將爲發現的需求構建模型 。此時，架構小組通常要集中到會議 且 ， 與外界隔絕地仔細考慮一段時間 。將架構需求劃分爲主要的組件 ，包括 ETL 、BI 、元數據 和基礎設施 。從此，小組開始勾畫並逐步求精地建立高級的架構模型 。產生的結果與前文討論的建房的藍圖類似。它將描述從街面上看 ，建築看起來像什麼 ，但它還非常簡單，因爲相關的細節尚未加以考慮。確定架構實現階段
就像房屋擁有者夢想中的房屋 一樣 ，您不可能一次就將技術架構的方方面面都予以實現。有些方面是必須強制實施的 ，其他方面可能是最好具備 。再一次返回到業務需求來建立架構優先順序 ，因爲在項目初期必須提供包含最少元素的架構 。設計並定義子系統
所需的大部分功能可能通過主要的工具提供商的標準產品都能夠獲得 ，但是總會有 一些子系統無法在現成產品中找到 。必須對這些子系統詳盡地加以定義 ，這樣要麼有人能 夠 爲您構建這些產品 ，要麼可以根據您的需求來評價產品 。建立架構規劃
技術架構需要被文檔化 ，包括規劃的各個實現階段 ，可供那些未參加會議的人員使用 。技術架構規劃文檔應該包括十分詳盡的細節 ，這樣有經驗的職業人士可以處理框架的構建 ， 就像木匠基於藍圖構建房屋一樣 。然而 ，除非己經開始使用 ，否則一般不要指明特定的 產品。評審及確定技術架構
最後 ，讓我們結束關於架構設計過程的討論 。架構任務 工作團隊需要將架構規劃以各 種不同細節層次與項目小組 、IT 夥伴和業務領導者交流 。評審後，應該對文檔按照評審結 果進行更新並立即用於 產品選擇過程。
1.3.2 產品選擇與安裝
架構規劃在許多方面類似選擇滿足規劃框架的 產品的購物清單。以下6 種與 DW/BI 產 品選擇有關的任務與所有技術選擇類似 。
瞭解公司的採購流程
選擇新產品的第 1個步驟是瞭解公司內部的硬件和軟件採購流程 。建立產品評價矩 陣
以架構規劃爲起始點 ，開發出基於電 子圖表的用於確定評價準則的評價矩陣以及指 示 重要性的權衡因素 。評價準則越具體越好 。如果評價準則太模糊或太 一般化 ，則所有供應 商都能夠滿足您的需要 。進行市場調研
在選擇產品時，要成爲明智的買家 ，就應該開展市場調研以更好地瞭解提供商及其提 供的產品。請求建議(Request For Proposal ，盯P）是一個經典的產品評價工具 。儘管有些組 織別無選擇 ，但您應該盡力避免採用這 一技術 。構建 盯P 和評價響應需要耗費小組大量的 時間。同時，提供商會從最積極的角度主動響應問題 。最終 ，支付的價值可能與付出的努力不成比例 。評價的選項列表不要太多
儘管市場上存在大量的可用產品，但通常僅有 一小部分供應商能夠同時滿足功能和技 術需求 。通過比較評價矩陣的 基本得分 ，可以將目標集中到小部分供應商 而將其他大部分 排除在外。在確定供應商後 ，可以開展詳細的評估工作 。如果是評估 BI 工具 ，則應該將業 務代表包含進來 。作爲評估人員 ，您應該駕馭評估過程 ，而不是被供應商驅動 ，共享相關 的來自架構規劃的信息 ，這樣會議纔會關注您的需求 而不是產品 的表面浮華的特性 。一定 要討論供應商的 參考資料 ，這些資料包括從正規渠道獲得 的，以及從非正規的網絡 上獲 得的。必要情況下構建原型系統
詳細評估完成後 ，有時明確 的優勝者會浮出水面 ，通常是基於小組先前的經驗或關係 。 另外也可能出現一些其他情況 ，勝出方式是由於現有 的企業承諾 ，例如 ，站點協議或歷史 上存在的硬件購買。無論哪種情況 ，當出現唯一的候選者時 ，您可以繞過構建原型這 一步 驟（這關係到時間和金錢的投入 ） 。如果沒有 明顯的勝者 ，您應該考慮構建不超過兩個產品 的原型。再次說明 ，需要控制原型開發過程 ，開發有限的但非常現實的業務案例 。選擇產品 、安裝試驗以及談判
現在可以選擇產品了。不要立即就簽字成交 ，通過給單個供應商私下的 、非公開的承諾 ，保留您繼續談判的能力 。不要立即通知供應商您決定購買其產品 ，而是進入試用期 ， 您有機會將相關產 品應用到實際環境中。安裝產品、進行培訓和開始使用 ，這些需要花費 大量的精力，因此應當與中意的提供商 一起走過這一階段 ，不應該將測試作爲另外一種消 耗精力的遊戲 。試驗結束後 ，可以開展對各參與方都有利的購買談判工作 。
1.4 生命週期數據路徑
1.4.1 維度建模
參考之前的維度建模篇章。
1.4.2 物理設計
通過基本的源到目標映射而開發和文檔化的維度模型需要轉換成物理數據庫 。採用維度模型，邏輯和物理設計具有相似性，您肯定不希望數據庫管理員在物理設計過程中將您可愛的維度模型轉換爲規範化的結構 。
物理數據庫實現細節隨平臺和項目的不同而存在較大的差異 。此外，硬件、軟件和工 具發展迅速 ，因此後續的物理設計活動和考慮僅僅能提供簡單的參考 。
開發命名及數據庫標準
表和列名是用戶體驗的關鍵因素 ，用於數據模型和 BI 應用的導航 ，因此它們對業 務來 說應該是有意義的 。您還需要圍繞鍵的定義來建立標準以及確定是否允許存在空值 。開發物理數據庫模型
物理數據庫模型應該儘早建立在開發服 務器中 ，以便能夠被 ETL 開發小組使用 。幾個 附加的表集合應該作爲 DW/BI 系統的組成部分而 被設計和部署 ，這些表集合包括支持ETL 過程的臨時表 ，ETL 過程和質量的審計表 ，支持安全訪問 數據倉庫子集的結構等。開發初始索引規劃
除了要理解關係數據庫的查詢優化器和索引工作原理外 ，數據庫管理員還應當敏銳地 意識到 DW/BI 需求與聯機事務處理（OLTP）需求存在顯著的差別。因爲維度表具有單列主鍵 ，所以可以建立唯 一索引。如果可以用位圖索引的話 ，通常可以在維度屬性中增加 一個 位圖索引列 ，用於過濾和分組 ，特別是當需要屬性聯合約束時 •。否則，可以考慮針對這 些 屬性使用 B 樹索引。同樣，第 1 個事實表索引通常是針對 主鍵的 B 樹索引或聚集索引，確 定日期外鍵在索引的主導地位可以加快數據加載和 查詢操作 ，因爲日期通常會被頻繁使用 。 如果數據庫管理系統（DBMS）支持高粒度的位圖索引 ，則對事實表中獨立的外鍵使用位圖索 引是較好的選擇 ，因爲當用戶以未知方式約束維度時 ，它們比聚集索引更具有未知性 。其 他事實表索引的確定依賴於可用的索引及平臺的優化策略 。儘管聯機分析處理（OLAP）數據 庫引擎也使用索引並且有 查詢優化器 ，但與關係世界不同的是 ，數據庫管理員對這些環境 的控制能力有限。設計聚合 ，包括 OLAP 數據庫
與流行的觀念不同 ，增加更多的硬件不 一定是性能調整武器庫中最好的武器 ，利用聚集表是使成本更有效的可選方法 。無論使用 OLAP 技術還是使用關係聚集表 ，聚集都是 DW/BI 環境中必要的設計。當性能度量被聚集後，您要麼刪減維度 ，要麼將度量與遵守原子基本維度的縮減上卷維度關聯 。由於不可能建立、倉儲 、管理所有理論上可能存在的聚集 ，因此需要考慮兩個主要 的評價因素 。首先 ， 考慮從需求文檔中獲取的業務用戶的訪問模式 ，以及通過監控實際使用模式所獲得的輸入 。 其次 ，通過評價數據的統計分佈以提供划算的聚集點 。確定物理存儲細節
這包括塊、文件、磁盤 、分區和表空間以及數據庫的具體存儲結構細節 。大型事實表通常是按照活動日期劃分的 ，數據按月進行分段後放入不同的分區中，但仍然以 單一表的形式呈現給用戶 。按照日期分區能夠 爲數據加載 、維護和查詢性能帶來好處 。 聚集、索引及其他性能調整策略將隨着對實際使用模式更好的理解而不斷改進 ，因此要對不可避免 的持續更新有思想準備 。然而，您必須爲最初的上捲髮布適當的索引和聚集 數據，以確保 DW/BI 環境從開始就能具備合理的查詢性能 。
1.4.3 ETL 設計與開發
生命週期的數據路徑結束於 ETL 系統設計和開發 。
1.5 生命週期 Bl 應用路徑
儘管某些人可能認爲數據倉庫應該是完全隨時的、自服務的查詢環境，發佈參數驅動 的 BI 應用將滿足大部分業務團隊的需求 。對多數商業用戶來說 ，“隨時的” 意味着改變報 表的參數來建立他們個人的版本的能力 。沒有必要讓所有用戶都從頭開始 。構建一系列 的 BI 應用爲組織建立了一個一致的分析框架，而不會讓每個報表都存在差異 。BI 應用還服務 於獲取組織的分析知識，從監控性能到識別例外 ，確定因果因素 ，建模可替代的響應，這 種封裝提供 了更少的分析性趨向的跳躍 。
1.5.1 Bl 應用規範
業務需求定義完 成後，需要評審形成的產物並收集示 例報表以確定初始集合中包含的 大約 10-15 個 BI 報表和分析應用 。將着眼點收縮到關注最 爲關鍵的能力，對期望進行管 理並及時發佈 。對這一優先過程來說 ，業務團隊的輸入是非常關鍵的 。儘管 15 個應用昕起 來不算多 ，但僅僅改變簡單模板的變 量就可能會產生大量的分析。
開始設計初始應用時 ，建立標準（例如 ，常見的下拉菜單和一致性的輸出的外觀和感覺 ） 是非常有益的 。利用這些標準 ，定義每個應用模板並獲得足夠 的有關佈局 、輸入變量 、計算 、拆分的信息 ，這樣應用開發人員和業務代表都能夠獲得共同的理解 。
在BI 應用規範活動過程中 ，還應當考慮應用的組織。需要確定用於訪問應用的結構化的導航路徑 ，要反映用戶考慮其業務的方式 。利用可定製的信息門戶或儀表盤是傳播路徑 的主要策略 。
1.5.2 Bl 應用開發
此您進入BI應用開發階段時，需要再次關注標準 、命名規則 、計算 、庫和編碼標準的建立工作以最小化未來的修改工作 。數據庫開發工作結束後，Bl 工具和元數據安裝完成，部分歷史數據也己經加載完成，此時可以開展應用開發活動 。儘管模板定義已經完成 ，仍然應該重新考慮 BI 應用模板定義 ，以應對不可避免的模型修改 。
每個BI 工具都有特定的產品技能 ，因此可能需要重新加以考慮 。我們建議，與其通過反覆試驗獲取經驗 ，不如爲開發小組投資特定工具的教育培訓或補充資源的工作 。
開發BI應用時，一些輔助工作將有利於獲得良好的結果 。BI 應用開發人員採用健壯的訪問工具，將能夠在數據的草堆中快速發現針尖小的問題 ，儘管 ETL 應用已經對數據質量進行了驗證工作 。這也是我們爲什麼推薦在 BI 應用開發活動開展前 ，ETL系統已經完成的原因 。開發者還將首先開展對查詢響應時間的實際測試工作 。現在是評審主要的性能 調整策略的時候了 。
BI應用質量保證活動在數據穩定前是不會停止的 。您必須確保足夠的調度時間，超過最後的ETL截止時間 ，以允許順序完成 BI 應用開發任務 。
1.6 生命週期總結活動
後續部分提供確保項目達到有序結論的建議，同時確保您能夠爲未來的擴展做好準備 。
1.6.1 部署
技術、數據和BI 應用路徑收斂於部署 。遺憾的是 ，這一收斂並不能自然發生 ，需要預先進行大量的規劃 。也許更爲重要的是 ，成功的部署需要膽略和毅力以誠實地評價項目的部署準備 。部署與在假日裏爲親朋好友製作 一份大餐類似 。要準確地預測烹調主菜所需要 的時間是非常困難的事情 。當然，如果主菜尚未完成 ，廚師不得不在叫所有人上桌之前， 放慢配菜速度以補償延遲 。
就 DW/BI 部署來說 ，數據就是主菜 。在 ETL 廚房中 “ 烹調” 數據是最難以預測的任務。遺憾的是 ，即使數據沒有完全準備好 ，您通常仍然會繼續 執行部署工作 ，因爲您告訴 數據倉庫的使用者 ，他們將會在特定的日期和時間得到服 務 。由於您並未放慢部署的步伐 ， 所以帶着尚未 “ 烹調好” 的數據進入客戶的辦公室 。難怪用戶有時不再回來而去尋找其他 的幫助。
儘管在 DW/BI 開發任務期間 ，毫無疑問會進行測試，但您需要執行端到端的系統測試 ， 包括數據質量保證 、操作處理 、性能和可用性測試 。除了批判性地評價 DW/BI 發佈物的準 備情況外 ，還需要通過教育對其進行包裝且支持部署 。因爲用戶團體必須接受註定會取得 成功的 DW/BI 系統，因此教育是至關重要的 。DW/BI 支持策略依賴管理層的期望和現實 的發佈物的結合 。支持通常是按照層次結構組織的 。第 1 層是網站和自助服務支持 ；第 2 層由業務區域中的強力用戶支持 ；來自 DW/BI 小組的集中式支持提供最後 一道防線。
1.6.2 維護和發展
部署工作完成 ，您已經準備放鬆休息了 。別太着急 ！儘管部署結束 ，但工作遠未完成 。 您需要通過投資下列各類資源不斷地管理己有的環境 ：
支持 ：部署後，爲確保業務團隊能夠喜歡使用它們 ，用戶支持立即成爲關鍵 。您 不能坐在房間中並認爲沒有來自業務團隊的消息就是好消息 。如果沒有來自他們的消息，只可能是沒有人使用 DW/BI 系統。關注（至少臨時地）業務團體 ，使用戶能夠非常方便地使用支持資源 。如果數據或 BI 應用有錯誤被發現了 ，要誠實地告知，這樣才能建立相互的信任關係，同時立刻採取行動以改正存在的問題 。如果 DW/BI 發佈物質量不高，難以想象的對數據調整和應用返工予以支持的請求將會佔到問題的大多數。
教育 ：必須持續不斷爲 DW/BI 系統提供教育程序 。課程應該包括正規的進修和 高 級課程，以及不斷重複的入門課程 。可以爲開發者和強力用戶提供更多的非正規 教育以鼓勵思想交流 。
技術支持 ：應當將 DW/BI 系統視爲 具有服務級別許可的生產環境 。當然，技術支 持應當主動地監控性能和系統容量趨勢。您當然不希望由業務團體來告訴您性能 下降的情況。
程序支持 ：DW/BI 程序不是一個階段就能夠完成的 。您必須密切監視 ，然後推銷 您的成功經驗 。必須持續不斷地與不同的 DW/BI 支持者進行交流 。還必須確保己 有的實現能夠不斷地解決業務的需要 。不間斷的檢查點評審是評價和確定改進機 會的關鍵工具 。
如果您正確地開展工作 ，不可避免地會存在發展的需求 ，可能源於新用戶 、新數據、 新的 BI 應用 ，或對己有 的發佈物進行重大的改進 。與傳統的開發計劃不同 ，DW/BI 變化 應該被視爲是成功的 ，而不是失敗的信號 。正如我們在前面討論項目範圍時提出的建議那 樣 ，DW/BI 小組不要憑空臆想發展選項而做出決定 。業務需要按照優先過程來 處理 。如果您還沒有開展 這一工作 ，應該建立執行董事會來 設置 DW/BI 優先級以剪裁組織的總體目標 。在新 的優先級確定後 ，返回到生命週期起始點， 重新開展所有的工作 ，利用己經存在的技術 、數據 、BI 應用基礎 ，並重新建立它 們 ，當 然注意力要轉到滿足新的需求上 。
1.7 應當避免的常見錯誤
儘管我們能夠提供有關數據倉庫和BI 方面 的積極的建議 ，一些讀者最好關心一下常見 錯誤清單 。下面是我們提出 的在建立 DW1BI 系統時需要避免的 10 個常見錯誤：
錯誤 10：過於迷戀技術和數據 ，而沒有將重點放在業務需求和目標上 。
錯誤9：沒有或無法找到一個有影響的 、平易近人的 、明白事理的高級管理人員作爲 DW/Bl 工作的發起人 。
錯誤8：將項目處理爲一個巨大的持續多年 的項目，而不是追求更容易管理的、雖 然仍然具有挑戰性的迭代開發工作 。
錯誤7：分配大量的精力去構建規範化數據結構 ，在基於維度模型建立可行的展現 區前，用盡所有的預算 。
錯誤6：將主要精力投入到後端操作型性能和易開發性 ，而沒有重點考慮前端查詢 的性能和易用性 。
錯誤5：使存在於展現區的所謂的可查詢數據極端複雜 。喜歡提供複雜展現的數據 庫設計者花費大量時間支持業務用戶 ，他們的確應該通過簡化解決方案開發出更適合需要的產品 。
錯誤4：將維度模型放入單一基礎之上 ，不考慮使用可共享的 、一致性維度通過數據結構將這些模型聯繫在一起 。
錯誤3：只將彙總數據加載到展示區的維度結構中 。
錯誤2：臆想業務、業務需求及分析，其涉及的數據及支持技術都是靜態的。
錯誤 1：忽略承認DW/BI系統的成功直接來源於業務的認可 。如果用戶未將 DW/BI系統當成他們制定決策的基礎 ，那麼您所做的工作就是徒勞無益的 。
參考:
- 《數據倉庫工具箱 維度建模權威指南》第三版