數據倉庫系統的設計及開發2024/3/24數據倉庫系統的設計及開發2.3.數據倉庫設計—數據建模最佳實踐—構建高性能的數據倉庫數據倉庫設計—ETL設計數據倉庫設計—建模過程日程安排數據倉庫設計—界面設計數據倉庫的開發應用過程2024/3/24數據倉庫系統的設計及開發3.靈活性能夠很好的分離出底層技術的實現和上層業務的展現當上層業務發生變化時，通過數據模型，底層技術實現可以較為輕松的完成業務的變動，從而達到整個數據倉庫系統的靈活性1.業務核理改善業務流程能夠全面了解業務系統的業務架構圖和整個業務運行情況2)能夠將業務按照特定的規律進行分門別類和程序化2.解決信息孤島及數據差異1)建立全方法的數據視角；2)

保證整個企業的數據的一致性；3)

消除各個部門之間的信息孤島；4.加快數據倉庫系統的建設開發人員和業務人員能夠很容易達成系統建設范圍的邊界的界定能夠使整個項目組明確當前的任務，加快整個系統建設的速度為什么需要數據模型2024/3/24數據倉庫系統的設計及開發數據倉庫建模人員所需的技能和能力分析能力見樹又見林模擬論證學習能力抽象綜合交流能力組交互演示調查訪談原型設計能力企業體系架構2024/3/24數據倉庫系統的設計及開發數據倉庫設計建模的要點和原則建模原則選擇創建什么模型對如何動手解決問題和如何解決方案有深遠影響每一種模型可以在不同的精度級別上表示最好的模型是與現實相聯系單個模型不充分，需要一組模型去處理建模的要點正確認識建模方法論2024/3/24數據倉庫系統的設計及開發利用圖形來建立數據模型圖形具有直觀性、簡單性以及可理解性等優點圖形能自然地表達客觀世界理解圖中路徑探索2024/3/24數據倉庫系統的設計及開發什么是數據模型業務建模，生成業務模型，主要解決業務層面的分解和程序化。領域建模，生成概念模型，主要是對業務模型進行抽象處理，生成領域概念模型。邏輯建模，生成邏輯模型，主要是將領域模型的概念實體以及實體之間的關系進行數據庫層次的邏輯化。物理建模，生成物理模型，主要解決，邏輯模型針對不同關系型數據庫的物理化以及性能等一些具體的技術問題。2024/3/24數據倉庫系統的設計及開發思考需求建模與業務建模需求建模與業務建模誰先誰后？軟件開發過程是否應該是：業務調研，業務建模(業務分析)，(業務模型分析)需求調研（這時，已經有一部分需求可從業務模型中獲得）,需求建模，需求分析……2024/3/24數據倉庫系統的設計及開發業務建模—組織結構分析2024/3/24數據倉庫系統的設計及開發組織結構,用戶及權限的分析客戶組織結構的分析公司組織機構區域位置集團/省/地市用戶的分析用戶組角色權限的分析功能權限分析數據權限分析2024/3/24數據倉庫系統的設計及開發例：三大運營商的組織架構調整2024/3/24數據倉庫系統的設計及開發業務建模—業務流程分析2024/3/24數據倉庫系統的設計及開發什么是業務流程2024/3/24數據倉庫系統的設計及開發業務流程分析的內容（1）原有流程的分析。（2）業務流程的優化。（3）確定新的業務流程（4）新系統的人機界面。2024/3/24數據倉庫系統的設計及開發業務流程分析的步驟1.系統環境調查2.組織機構和職責的調查3.功能體系的調查與分析4.管理業務流程的調查與分析

2024/3/24數據倉庫系統的設計及開發案例學習：

新業務客戶服務業務流程—新業務查詢流程2024/3/24數據倉庫系統的設計及開發業務流程可以代替業務建模嗎在業務流程的背后，有一個更加根本的因素——商業需求。商業需求才是真正的業務模型，業務流程只是一種實現手段而已。例：新用戶入網業務流程：1：首先把SIM卡和號碼在交換網絡上做對應關系的注冊；2：市場部把SIM卡存入一定的金額，發給銷售商，收取銷售商的貨款；3：銷售商把卡賣給用戶，用戶填寫入網合同，SIM裝入手機可以立即通話；4：銷售商把入網合同交給市場部，市場部資料錄入人員將用戶的資料錄入系統；5：計費系統按照用戶選擇的資費對話單進行計費；6、市場部按照用戶的消費情況給銷售商計算傭金和返利。思考：真正的業務模型(需求)是什么？2024/3/24數據倉庫系統的設計及開發從業務流程中提取概念和邏輯模型心得體會：看到背后的商業需求，你會發現模型原來非常穩定不需要急于知道所有的細節性的需求，只要了解比較重要的20％的需求2024/3/24數據倉庫系統的設計及開發數據倉庫數據模型-星型模型與雪花模型2024/3/24數據倉庫系統的設計及開發數據倉庫建模的原則兼顧效率與數據粒度的需要1支持需求的變化2避免對業務運營系統造成影響3滿足不同用戶的需要4考慮末來的可擴展性52024/3/24數據倉庫系統的設計及開發數據倉庫建模的三個階段概念模型設計(ConceptDataModeling)：這一階段之前的首要工作是通過需求分析，明確需求所涵蓋的業務范圍。然后再對需求范圍內的業務及其間關系進行高度概括性的描述，把密切相關業務對象進行歸類，即劃分主題域。概念模型的設計是為邏輯模型的設計做準備，它沒有統一的標準，主要根據設計者的經驗。邏輯模型設計(LogicalDataModeling)：分別對概念模型的各個主題域進行細化，根據業務定義、分類和規則，定義其中的實體并描述實體之間的關系，并產生實體關系圖（ERD），然后遵照規范化思想在實體關系的基礎上明確各個實體的屬性。實體產生于中國移動開展的業務、服務及其涉及的對象（如客戶、帳戶、員工、機構、資源），實體間的對應、約束關系則來自于各業務過程中的規則。可以說，這一階段面對的是業務。

物理模型設計(PhysicalDataModeling)：物理模型設計主要依據邏輯模型針對具體的分析需求和物理平臺采取相應的優化策略。此時會在一定程度上增加數據冗余或者隱藏實體之間的關系或者進行實體的合并和拆分，目的是提高數據分析的速度，適應具體數據庫的容量、性能等限制。可以說，這一階段面對的是具體軟硬件平臺和性能要求。一旦邏輯模型到位，物理模型就有了可參照的依據，開發工作內容也同時得到明確。物理模型設計一般在架構設計階段2024/3/24數據倉庫系統的設計及開發數據倉庫系統所采用的建模流程概念模型為邏輯模型的設計作準備，沒有統一標準，主要根據設計者經驗邏輯模型對概念模型的各個主題域進行細化，根據業務定義、分類和規則，定義其中的實體并描述實體之間的關系，并產生實體關系圖（ERD）一旦邏輯模型到位，物理模型就有了可參照的依據，開發工作內容也同時得到明確2024/3/24數據倉庫系統的設計及開發數據倉庫概念模型

主題域的設計DW主題的劃分必須是基于需求的主題劃分，而不僅僅是基于已有查詢和報表數據的主題劃分DW主題是通過對業務人員的訪談，充分了解業務流程和信息使用需求為主要根源的DW主題的設計必須能夠滿足業務人員的內在的分析需求DW主題設計的過程中，業務環節點分析是關鍵DW細化分析主題，解決指標的歧義問題，為模型設計、數據提取、數據展現等多個方面奠定基礎2024/3/24數據倉庫系統的設計及開發數據倉庫的數據模型系統記錄域（SystemofRecord）：這部分是主要的數據倉庫業務數據存儲區，數據模型在這里保證了數據的一致性。內部管理域（Housekeeping）：這部分主要存儲數據倉庫用于內部管理的元數據，數據模型在這里能夠幫助進行統一的元數據的管理。匯總域（SummaryofArea）：這部分數據來自于系統記錄域的匯總，數據模型在這里保證了分析域的主題分析的性能，滿足了部分的報表查詢。分析域（AnalysisArea）：這部分數據模型主要用于各個業務部分的具體的主題業務分析。這部分數據模型可以單獨存儲在相應的數據集市中。反饋域（FeedbackArea）：可選項，這部分數據模型主要用于相應前端的反饋數據，數據倉庫可以視業務的需要設置這一區域。2024/3/24數據倉庫系統的設計及開發數據模型的技術功能結構劃分

分段存儲區（StagingArea）是為了保證數據移動的順利進行而開設的階段性數據存儲空間，它是業務系統原始數據進入數據倉庫前的緩存區。基礎數據倉庫根據業務需求的不同，基礎數據倉庫的組織形式以三范式模型為主，在有的系統中也可能采用星型或雪花模型。數據集市（DataMart）數據集市中的數據通常由基礎數據倉庫的詳細數據聚合而來，根據數據聚合程度的不同包含輕度聚合、中度聚合和高度聚合三種不同的層次。匯總的方式將依據數據量的大小和使用頻度綜合考慮2024/3/24數據倉庫系統的設計及開發數據倉庫的模型—關系模型2024/3/24數據倉庫系統的設計及開發數據倉庫的模型—星型模型通過數據預連接和建立有選擇的數據冗余，設計者為訪問和分析過程大大簡化了數據。星型連接應用于設計數據倉庫中很大的實體，而數據模型則應用于數據倉庫中較小的實體。2024/3/24數據倉庫系統的設計及開發數據倉庫的模型—雪花模型許多維度存在著比較復雜的結構，它們有的還具有多層的層次結構。因此，很難將這樣的維表只采用一個關系表的形式表達出來，必須將這些維表規范成有多個外鍵關聯的關系表2024/3/24數據倉庫系統的設計及開發星型模型VS雪花模型比較項目優點缺點星型模式1.查詢效率高，事實表作連接時其速度較快;2.便于用戶理解。比較直觀，通過分析星形模式，很容易組合出各種查詢增加了存儲空間雪花模式1.在一定程度上減少了存儲空間2.規范化的結構更容易更新和維護1.比較復雜，用戶不容易理解;2.瀏覽內容相對困難3.額外的連接將使查詢性能下降2024/3/24數據倉庫系統的設計及開發寬表橫表與縱表處理方便性與業務支撐靈活性的差異寬表在橫表的基礎上拓展，強化處理方便性開放給業務人員使用，直接解決業務問題單條記錄包括用戶基本信息、產品選擇和使用量、費用信息2024/3/24數據倉庫系統的設計及開發數據倉庫建模方法—范式建模法優點:從關系型數據庫的角度出發，結合了業務系統的數據模型，能夠比較方便的實現數據倉庫的建模缺點:在某些時候反而限制了整個數據倉庫模型的靈活性，性能等2024/3/24數據倉庫系統的設計及開發數據倉庫建模方法—維度建模法優點:維度建模非常直觀，緊緊圍繞著業務模型，可以直觀的反映出業務模型中的業務問題缺點:如果只是依靠單純的維度建模，不能保證數據來源的一致性和準確性2024/3/24數據倉庫系統的設計及開發數據倉庫建模方法—實體建模法優點:能夠很輕松的實現業務模型的劃分，因此，在業務建模階段和領域概念建模階段，實體建模法有著廣泛的應用缺點:不太適用于物理建模2024/3/24數據倉庫系統的設計及開發數據倉庫建模的十大戒律1)

必須回答緊迫的問題；2)

必須有正確的事實表；3)

將有正確的維表，描述必須按最終用戶的業務術語表達；4)

必須理解數據倉庫所影響的公司過程或影響數據倉庫的公司過程；5)

對于事實表，應該有正確的“粒度”；6)

根據需要存儲正確長度的公司歷史數據；7)

以一種對于公司有意義的方式來集成所有必要的數據；8)

創建必要的總結表；9)

創建必要的索引；10)

能夠加載數據倉庫數據庫并使它以一種適宜的方式可用。2024/3/24數據倉庫系統的設計及開發數據倉庫緩慢變化維的一個案例一個案例在一個零售業數據倉庫中，事實表保存著各銷售人員的銷售記錄，某天一個銷售人員從北京分公司調到上海分公司了，那么如何來保存這個變化呢？也就是說銷售人員維度要怎么恰當的處理這一變化。如果我們要統計北京地區或上海地區的總銷售情況的時候，這個銷售人員的銷售記錄應該算在北京還是算在上海？當然是調離前的算在北京，調離后的算在上海,但是如標記這個銷售人員所屬區域？這里就需要處理一下這個維度的數據，即我們緩慢變化維需要做的事情。

2024/3/24數據倉庫系統的設計及開發數據倉庫緩慢變化維的解決方案新數據覆蓋舊數據保存多條記錄，并添加字段加以區分．添加記錄的生效日期和失效日期來標識新舊數據

不同字段保存不同值

，這種方法用不同的字段保存變化痕跡.但是這種方法不能象第二種方法一樣保存所有變化記錄,它只能保存兩次變化記錄.適用于變化不超過兩次的維度。另外建表保存歷史記錄，而維度只保存當前數據

混合模式2024/3/24數據倉庫系統的設計及開發數據倉庫建模_案例2024/3/24數據倉庫系統的設計及開發案例：怎樣構建數據倉庫模型確定主題域確定主題域及各主題域之間的關系確定主題域的業務數據確定業務數據中的業務實體確定業務實體之間的關系確定物理模型2024/3/24數據倉庫系統的設計及開發確定主題域及各主題域之間的關系服務通過網絡實現/網絡支持服務網絡產生事件/事件包括網絡類產品被銷售給客戶/參與人使用和管理產品跟蹤應付&應收/提供成本&收入歷史事件包含財務類參與人產生和經歷事件/事件包括參與人的產品/服務產生事件事件包括產品類營銷產生事件事件實現營銷營銷被鎖定位置/位置定位營銷針對特定產品/產品通過營銷推向市場為參與人建立帳戶、帳單/記錄帳戶、成本和付款服務使用的帳務信息/帳務記錄產品的成本和付款定位網絡/網絡支持的位置營銷的目標針對參與人/參與人是營銷的受眾包括消費者和運營商在內/位置定位FinanceManagement（財務管理）BILLING（帳務）NETWORK（網絡資源）PRODUCT（產品）MARKETING（市場營銷）LOCATION（地域）PARTY（參與人）EVENT(事件)跟蹤總帳/負責2024/3/24數據倉庫系統的設計及開發基本結構特征獎勵隱私參與人主題描述了和電信運營商有著業務聯系的任何個人、企業、組織、團體等。

確定主題域的業務數據2024/3/24數據倉庫系統的設計及開發參與人間關聯

參與人角色組織層次結構層次結構級別層次結構類型商業組織內部組織標準分類代碼確定基本結構業務數據的業務實體及關系參與人：和電信運營商有著業務聯系的任何個人、組織機構、家庭和虛擬客戶。例：財務市場營銷網管例：客戶潛在客戶電信運營商代理商供應商管理者雇主職工個人家庭組織參與人2024/3/24數據倉庫系統的設計及開發特征符合程度特征類別值客戶特征帳戶特征特征類別例：個人喜好信用類信息家庭類信息教育類信息職業類信息機構類信息

例：信用等級職業狀態收入子女數教育程度特征分組完全符合部分符合不符合確定特征業務數據中的業務實體及關系2024/3/24數據倉庫系統的設計及開發獎勵計劃管理參與人角色獎勵目標客戶群目標群獎勵等級獎勵類型參與人獎勵歷史記錄獎勵計劃獎勵計劃：記錄電信運營商向客戶提供獎勵和回報的歷史。確定獎勵業務數據中的業務實體及關系2024/3/24數據倉庫系統的設計及開發隱私信息類別同意周期組織隱私策略信息參與人帳戶隱私信息帳戶同意等級信息參與人同意等級信息參與人隱私信息隱私信息類別確定隱私業務數據中的業務實體及關系2024/3/24數據倉庫系統的設計及開發業務系統與數據倉庫模型的映射2024/3/24數據倉庫系統的設計及開發數據倉庫建模_案例實踐2024/3/24數據倉庫系統的設計及開發國內社保行業背景目前我們國家的社保主要分為養老，失業，工傷，生育，醫療保險和勞動力市場這6大塊主要業務領域。在這6大業務領域中，目前的狀況養老和事業的系統已經基本完善，已經有一部分數據開始聯網檢測。對于工傷，生育，醫療和勞動力市場這一塊業務，有些地方發展的比較成熟，而有些地方還不夠成熟。請大家思考并簡單描述社保行業的數據倉庫模型：大致的業務模型大致的概念模型2024/3/24數據倉庫系統的設計及開發社保行業數據倉庫業務模型2024/3/24數據倉庫系統的設計及開發社保行業數據倉庫領域概念模型2024/3/24數據倉庫系統的設計及開發社保行業數據倉庫邏輯模型通過領域概念模型細化邏輯模型每一個抽象的實體，例如：“人”的屬性包括年齡，性別，受教育程度等等。各個抽象實體間的聯系。例如：對于養老金征繳這個“事件”的屬性得考慮，對于失業勞動者培訓這個“事件”的屬性得考慮等等。找出抽象事件的關系，并對其進行說明。例如：對于“事件”中的地域，事件等因素的考量等等。建議:可以參考3NF的建模方法，表達出實體的屬性，以及實體與實體之間的聯系。例如：在這個階段，我們可以通過采用ERWIN等建模工具等作出符合3NF的關系型數據模型來。

2024/3/24數據倉庫系統的設計及開發社保行業數據倉庫物理模型完成物理模型生成創建表的腳本。不同的數據倉庫平臺可能生成不同的腳本。針對數據集市的需要，按照維度建模的方法，生成一些事實表，維表等工作。針對數據倉庫的

ETL

車和元數據管理的需要，生成一些數據倉庫維護的表，例如：日志表等。注:根據業務實際的需要和自己對抽象能力的把握來創建適合自己的數據模型

2024/3/24數據倉庫系統的設計及開發總結:

數據倉庫建模需注意的幾個問題數據粒度和數據組織維和度量的唯一性和公用性數據粒度一旦變粗，就要考慮多個主題的融合匯總不論如何歸并，需要保持數據之間的聯系對ODS中的各個主題的事實數據進行時間上的匯總把包含細節過多的交易記錄進行拆分匯總、再匯總2024/3/24數據倉庫系統的設計及開發2.3.數據倉庫數據模型—星形與雪花最佳實踐—構建高性能的數據倉庫數據倉庫設計—ETL設計數據倉庫設計—建模過程日程安排數據倉庫設計—界面設計數據倉庫的開發應用過程2024/3/24數據倉庫系統的設計及開發ETL數據轉換過程的功能模塊設計ETL數據轉換操作大致可以分為6個組或模塊：數據的提取、驗證、清理、集成、聚集和裝入。2024/3/24數據倉庫系統的設計及開發ETL的設計要點(1)ETL的設計一定是針對具體的應用相關的，針對不同的業務和分析模型有不同的抽取要求在設計過程中需要考慮是否需要預留字段，增加屬性等等數據的粒度，在同一CUBE中必須統一數據周期的確定，在設計ETL時需要事先確定抽取的時間抽取的方式盡量采用增量的抽取以減小每次抽取的數量數據流和工作流的考慮2024/3/24數據倉庫系統的設計及開發ETL的設計要點(2)流程的異常處理ETL的調整，運行管理以及監控針對業務的需求進行ETL的配置和設置界面ETL對CUBE的管理ETL裝載數據初始化的過程程序具有自修復功能2024/3/24數據倉庫系統的設計及開發確定ETL的抽取及加載策略抽取策略每日增量每日全量每月增量每月全量抽取策略全表覆蓋歷史加載直接追加主表加載初始加載其它加載2024/3/24數據倉庫系統的設計及開發ETLMapping實體映射表2024/3/24數據倉庫系統的設計及開發確定ETL接口需求系統和任何其他外部系統或組件進行交互相關需求接口一般由系統間的傳輸方式、傳輸協議、傳輸過程、接口處理模式、抽取周期、編碼原則、命名規則、驗證方式和數據單元等組成2024/3/24數據倉庫系統的設計及開發確定ETL接口的實現方式2024/3/24數據倉庫系統的設計及開發確定ETL接口的數據要求及保障2024/3/24數據倉庫系統的設計及開發確定ETL接口文件的格式2024/3/24數據倉庫系統的設計及開發確定ETL接口文件的內容2024/3/24數據倉庫系統的設計及開發確定ETL接口單元2024/3/24數據倉庫系統的設計及開發ETL接口數據處理流程2024/3/24數據倉庫系統的設計及開發ETL接口出錯處理接口處理重傳機制1、經營分析系統方校驗數據源內容后把出錯記錄放入“出錯記錄文件存放目錄”2、數據源廠商定時查閱此目錄，分析錯誤原因，并采取糾正措施例如：重新傳送此數據項文件。具體的實現方式需雙方協定。大數據文件分拆機制只要是增量抽取的，原則上不考慮分拆，對于GSM清單和普通短信清單，數據量很大，考慮分拆成12個數據文件，每2小時一個。2024/3/24數據倉庫系統的設計及開發案例學習2024/3/24數據倉庫系統的設計及開發2.3.數據倉庫數據模型—星形與雪花BI項目設計開發的最佳實踐數據倉庫設計—ETL設計數據倉庫設計—建模過程日程安排數據倉庫設計—界面設計數據倉庫的開發應用過程2024/3/24數據倉庫系統的設計及開發確定界面元素界面主顏色字體顏色及大小界面布局界面交互方式界面功能分布界面輸入輸出模式2024/3/24數據倉庫系統的設計及開發某運營商KPI系統目標以最方便的形式讓各級領導對考核指標完成情況進行瀏覽分析采用良好方式實現常用指標的關聯展示，更加符合業務人員的分析邏輯采用樹型菜單對個體分散指標進行分類展示組織，提高指標分析的操作的便捷性詳細編寫各業務指標的統計口徑，讓用戶可以方便查詢和檢索2024/3/24數據倉庫系統的設計及開發KPI系統指標體系2024/3/24數據倉庫系統的設計及開發數據準確性刷新/上載數據的頻率(定期)數據下鉆能力訪問控制KPI系統關鍵性:低高KPI分層KPI系統主要功能2024/3/24數據倉庫系統的設計及開發1。支持角色，有預定義好的權限視圖2。分層管理:每個KPI有對應的“保障”KPI的層次定義3。動態交互式環境用戶可以設置KPI分解的百分比支持分解維度（按部門、運營中心如地市等）可調整的KPI分解規則4。閥值預警5。內部標桿共享KPI系統框架和關鍵功能2024/3/24數據倉庫系統的設計及開發整體KPI首頁界面分為三個目錄級★KPI考核指標★KPI通報指標★KPI個體指標體現以表格的形式展現數據，輔助以圖型增加指標之間的關聯性，從多角度體現指標的內容。增加指標說明的模塊，對用戶使用該指標時容易產生理解誤差的內容提供相應解釋。KPI系統首頁界面2024/3/24數據倉庫系統的設計及開發樹狀的目錄力求簡單，清晰，操作方便，減少用戶的點擊切換環節過程。KPI系統樹狀目錄結構2024/3/24數據倉庫系統的設計及開發簡單明了的KPI指標往往成為管理者和普通市場人員最關注的對象領導的聊望臺滾動指標告警指標列表區首頁或結果展示區滾動指標告警區KPI系統首頁界面2024/3/24數據倉庫系統的設計及開發增強指標之間的關聯性，對若干指標的內在聯系，進行歸類對比展示，以多種圖形方式進行多角度地展現。KPI系統界面12024/3/24數據倉庫系統的設計及開發KPI指標主要展現此項指標在時間上的對比，例如，上月當日，歷史同期，環比等。KPI指標按業務分析邏輯有機排列，方便業務人員對比觀看。KPI在表格上增加趨勢的展現，分為三種，“平穩”，“升高”，“降低”點擊以后將展示最近一周的趨勢KPI系統界面22024/3/24數據倉庫系統的設計及開發2.數據倉庫數據模型—星形與雪花BI項目設計開發的最佳實踐數據倉庫設計—ETL設計數據倉庫設計—建模過程日程安排數據倉庫的開發應用過程數據倉庫設計—界面設計2024/3/24數據倉庫系統的設計及開發自頂向下(Top-downApproach)建造企業數據倉庫建設中心數據模型一次性的完成數據的重構工作最小化數據冗余度和不一致性存儲詳細的歷史數據從企業數據倉庫中建造數據集市得到大部分的集成數據直接依賴于數據倉庫的可用性對信心的極大考驗：投資大，建設時間長，階段成果顯現困難！ExternalDataODSCentralDataWarehouseDataMartDataMart2024/3/24數據倉庫系統的設計及開發自底而上(Bottom-upApproach)創建部門的數據集市范圍局限于一個主題區域快速的ROI--局部的商業需求得到滿足本部門自治--設計上具有靈活性對其他部門數據集市是一個好的指導容易復制到其他部門擴大到企業數據倉庫創建EDW作為一個長期的目標重復投資：每個部門都重復進行數據整理！企業數據倉庫建設困難：數據口徑、不一致性問題突出！DataMartDataMartCentralDataWarehouseExternalDataODSpartpartpartpartpartpart2024/3/24數據倉庫系統的設計及開發數據倉庫工程項目的特點數據倉庫工程既包括數據又包括程序，而且是以數據為基礎的系統數據倉庫工程中的數據倉庫的目標是面向主題數據倉庫工程是以處理分析型目標為主而不是事物型目標，它對數據內容正確性與形式規范性有嚴格要求數據倉庫工程中數據來源已有多種信息系統，因此對系統的數據要有一定的限制制約，也就是有了建立統一數據平臺的需求2024/3/24數據倉庫系統的設計及開發數據倉庫工程項目的開發應用過程解決方案啟動（Solutionstartup）業務發現（Businessdiscovery）解決方案建議（Solutionproposal）解決方案計劃（Solutionplanning）倉庫概念建模（Warehouseconceptualmodeling）倉庫階段設計（Warehousephasedesign）解決方案實現周期（Solutionimplementationcycle）解決方案部署（Solutiondeployment）

2024/3/24數據倉庫系統的設計及開發數據倉庫業務發現過程收集記錄業務需求理解客戶業務環境差異分析，理解客戶的業務難題及需求，彌補當前業務狀態及其業務需求之間差異2024/3/24數據倉庫系統的設計及開發收集記錄業務需求確定業務對象確定數據分析場景確定功能需求理解客戶的業務環境理解基礎架構環境理解數據環境差異分析需求分析識別業務主題領域識別數據差異識別基礎設施差異識別資源的差異理解客戶環境三個任務可以重疊進行

數據倉庫的業務發現內容2024/3/24數據倉庫系統的設計及開發2024/3/24數據倉庫系統的設計及開發數據倉庫工程項目的開發流程圖2024/3/24數據倉庫系統的設計及開發數據倉庫的數據流程（1）：對原始數據進行數據抽取、清洗、整理后成為數據倉庫中的各種綜合度的數據表。（2）：經過維度分析得到維表并定義相應的格式表。（3）：從數據倉庫中抽取數據形成事實表及補充事實表。（4）：從數據倉庫中抽取信息，整理成數據挖掘寬表，用于數據挖掘。（5）：寬表中的數據通過數據挖掘程序處理后生成的擴展數據（挖掘結果）需要重新回寫進事實表。（6）：利用數據展現工具展現OLAP和數據挖掘的結果。2024/3/24數據倉庫系統的設計及開發數據倉庫需求分析數據倉庫的特點是面向主題，按主題組織數據。1、主題分析

對于在層次結構中的每個主題，需要進行詳細的調研，確定要分析的指標，確定用戶從哪些角度來分析數據即維度，還要確定用戶分析數據的細化或綜合程度即粒度。主題、指標、維度、粒度是是建立數據倉庫的基本要素。

2、數據分析

(1)數據源分析(2)數據數量分析(3)數據質量分析3、環境要求分析

需要對滿足需求的系統平臺與環境提出要求，包括設備、網絡、數據、接口、軟件等的要求。數據源分析主題分析數據質量分析環境要求分析2024/3/24數據倉庫系統的設計及開發數據倉庫系統總體設計體系結構設計接口設計應用程序模塊設計①數據源層②數據后端處理層③數據倉庫及其管理層④數據集市層⑤數據倉庫應用層⑥數據展示層①數據源與分析模型的接口②分析模型與應用的接口2024/3/24數據倉庫系統的設計及開發分析設計實施需求分析風險分析方案設計POC實施UAT發布環境準備Scope系統功能目標分析系統性能環境所帶來的風險分析可以容忍的見險關鍵流程的定義確定組織架構方案設計（技術／框架/流程)數據備份方案時間窗環境(DB/TOOL/DATA)源代碼/POC數據POC報告CUT計劃測試/用戶測試數據備份系統觀察系統發布BugFixＢＩ項目建設方法論2024/3/24數據倉庫系統的設計及開發

BI項目組織圖92*SteeringCommittee(項目經理)(甲方項目經理)ProjectManagerETL&DM(SeniorSE)Report(SeniorSE)TestQAKMSoultionArchitect2024/3/24數據倉庫系統的設計及開發BI項目組織說明項目指導委員會（SteeringCommittee）:項目指導委員會主要由甲方與HP的資深主管們所組成，負責決定項目的策略方向與目的，并提供項目執行所需要的支持與承諾。協助處理與仲裁項目執行過程由項目經理所提報（Escalate）所遇到之困難與爭議。協助處理項目執行上所需要之人力資源支持與調動，如項目團隊之人員指派等。項目經理（ProjectManager）:在項目經理的協助下，承擔并完成下列工作：規劃詳細的項目計劃書管理項目中所有的日常事務與工作事項，以期達成項目每的階段性任務及目標核審項目進度與項目里程碑定期與甲方項目經理共同執行項目的審核并商討項目的計劃定期以書面方式向項目指導委員會報告項目進行的狀況針對項目執行上所遭遇的例外事件進行處理，并適當提報給項目指導委員會以尋求支持與協助與甲方項目經理共同擔負起項目建置成功的責任93*2024/3/24數據倉庫系統的設計及開發BI項目組織說明專案架構師（SolutionArchitect）:負責項目相關之技術架構與功能設計等，并領導項目執行技術團隊確認項目技術架構符合甲方之維運要求與質量標準。ETL組2人：負責ETL部分的開發與實施Report組2人：負責BOReport部分的開發與實施Test組2人：負責項目的系統測試與用戶最終測試其中測試組有1人兼任QA和KM角色。94*2024/3/24數據倉庫系統的設計及開發M0M1M2M3M4M5BI項目里程碑Milestone項目啟動需求階段POC項目實施集成測試ReleaseUATM0.5M1.5M2.5M3.5M4.5RollOut注:在大約項目啟動后2個月，POC階段將完成,也即最初的原型構建,用戶可以得到一個階段性的Release,下一步的項目實施及集成測試將以迭代的方式實現。2024/3/24數據倉庫系統的設計及開發BI項目實施階段階段輸入輸出項目啟動-評估SOW/方案建議書/遷移評估問題清單評估計劃，遷移方案，原始系統檢查報告項目啟動-項目計劃項目實施方案，當前環境和業務需求，數據和屬性，適用的實施工具項目計劃，質量計劃，風險管理計劃，配置管理計劃，單元測試案例（持續更新），集成測試案例（持續更新）POC源代碼，POC數據，原始系統檢查報告，實施方案實施模塊，POC測試結果，POC經驗總結，實施方案（更新），模塊實施步驟報告遷移源代碼，POC數據，原始系統檢查報告，遷移方案實施的ETL腳本，數據模型，數據代碼，遷移測試腳本，模塊實施步驟報告集成測試測試計劃，測試案例，基準版本，質量計劃已測試應用，測試報告，測試案例（更新）發布已實施應用ReleaseNote用戶驗收測試(UAT)驗收測試計劃驗收測試報告RollOut已遷移應用部署計劃，培訓材料2024/3/24數據倉庫系統的設計及開發優化及案例分析－業務環境數據庫服務器:Windows2000Server+Oracle8i+IIS+PowerPlay

EnterpriseServer

應用服務器:Windows2000Server+Transformer

客戶端:IE5.0以上版本。2024/3/24數據倉庫系統的設計及開發優化及案例分析－優化內容1.RAID

2.索引的建立3.SQL優化4.直接裝載、分區選擇、網絡設置2024/3/24數據倉庫系統的設計及開發2.數據倉庫數據模型—星形與雪花BI項目設計開發的最佳實踐數據倉庫設計—ETL設計數據倉庫設計—建模過程日程安排數據倉庫的開發應用過程數據倉庫設計—界面設計2024/3/24數據倉庫系統的設計及開發影響倉庫性能的關鍵因素系統硬件磁盤（轉速、容量）IO速度（光纖卡、網卡、路由器）CPU（個數、主頻）主機個數數據模型邏輯模型物理模型應用復雜度及業務發展EDWDataWarehousing2024/3/24數據倉庫系統的設計及開發物理模型對性能的影響數據倉庫的創建（Build）

初始化每天數據載入每月數據載入數據維護應用查詢,統計的支持(Query）KPI固定報表OLAP數據挖掘專題分析即席查詢經營分析報告/策劃查詢性能更應該被優先保證!空間換取時間的優化思想依然適用!2024/3/24數據倉庫系統的設計及開發非規范化優化技術增加冗余列（預連接）避免查詢時進行表連接操作舉例：姓名、聯系方式、預存款、當前積分增加派生列（預計算）避免查詢時連接和使用聚合函數累計積分、ARPU、MOU、前3月平均話費、量收比重新組表（應用導向）經常使用的查詢內容以表的形式存放（物化視圖）分割（水平＋垂直）用戶常用屬性與不常用屬性當前資料與歷史資料非規范化技術建立在查詢統計分析的基礎上的適合對記錄數非常多的表進行需要維護數據的完整性，加大了建設、維護的復雜度非規范化是一項高級設計技巧!OLTP系統也有，但OLAP需要更多，而且是核心!2024/3/24數據倉庫系統的設計及開發分表優化技術利用數據倉庫的Partition功能數據倉庫引擎提供，發揮都處理器及多主機執行的并行性很方便使用，而且必須使用表大到一定程度后