[[346087]]

 業務驅動

任何需求均來源于業務 , 業務決定了需求 , 需求分析的正確與否是關系到項目成敗的關鍵所在 , 從任何角度都可以說項目是由業務驅動的所以數據倉庫項目也是由業務所驅動的 。

但是數據倉庫不同于日常的信息系統開發 , 除了遵循其他系統開發的需求 , 分析 , 設計 , 測試等通常的軟件聲明周期之外 ; 他還涉及到企業信息數據的集成 , 大容量 數據的階段處理和分層存儲 , 數據倉庫的模式選擇等等 , 因此數據倉庫的物理模型異常重要 , 這也是關系到數據倉庫項目成敗的關鍵 .

數據倉庫的結構總的來說是采用了三級數據模型的方式 :

概念模型 : 也就是業務模型 , 由企業決策者 , 商務領域知識專家和 IT 專家共同企業級地跨領域業務系統需求分析的結果 .

邏輯模型：用來構建數據倉庫的數據庫邏輯模型。根據分析系統的實際需求決策構建數據庫邏輯關系模型 , 定義數據庫物體結構及其關系。他關聯著數據倉庫的邏輯模型和物理模型這兩頭 .

物理模型：構建數據倉庫的物理分布模型 , 主要包含數據倉庫的軟硬件配置 , 資源情況以及數據倉庫模式。

 

如上圖所示 , 在數據倉庫項目中 , 物理模型設計和業務模型設計象兩個輪子一樣有力的支撐著數據倉庫的實施 , 兩者并行不悖 , 缺一不可 . 實際上 , 我有意的擴大了 物理模型和業務模型的內涵和外延 . 在這里物理模型不僅僅是數據的存儲 , 而且也包含了數據倉庫項目實施的方法論 , 資源 , 以及軟硬件選型等等 ; 而業務模型不僅 僅是主題模型的確立 , 也包含了企業的發展戰略 , 行業模本等等 .

一個優秀的項目必定會兼顧業務需求和行業的標準兩個方面 , 業務需求即包括用戶提出的實際需求 , 也要客觀分析它隱含的更深層次的需求 , 但是往往用戶的需求是 不明確的 , 需要加以提煉甚至在商務知識專家引導下加以引導升華 , 和用戶一起進行需求分析工作 ; 不能滿足用戶的需求 , 項目也就失去原本的意義了 .

物理模型就像大廈的基礎架構 , 就是通用的業界標準 , 無論是一座摩天大廈也好 , 還是茅草房也好 , 在架構師的眼里 , 他只是一所建筑 , 地基 -> 層層建筑 -> 封頂 , 這樣的工序一樣也不能少 , 關系到住戶的安全 , 房屋的建筑質量也必須得以保證 , 唯一的區別是建筑的材料 , 地基是采用鋼筋水泥還是石頭 , 墻壁 采用木質還是鋼筋水泥或是磚頭 ; 當然材料和建筑細節還是會有區別的 , 視用戶給出的成本而定 ; 還有不可忽視的一點是 , 數據倉庫的數據從幾百 GB 到幾十 TB 不 等 , 即使支撐這些數據的 RDBMS 無論有多么強大 , 仍不可避免的要考慮到數據庫的物理設計 .

接下來 , 將詳細闡述數據倉庫概念模型 ( 業務模型 ), 邏輯模型 , 物理模型的意義

概念模型設計

進行概念模型設計所要完成的工作是 :

界定系統邊界

確定主要的主題域及其內容

確定主題域的關系

概念模型設計是，在原有的業務數據庫的基礎上建立了一個較為穩固的概念模型。因為數據倉庫是對原有數據庫系統中的數據進行集成和重組而形成的數據集合，所 以數據倉庫的概念模型設計，首先要對原有數據庫系統加以分析理解，看在原有的數據庫系統中 “ 有什么 ” 、 “ 怎樣組織的 ” 和 “ 如何分布的 ” 等，然后再來考慮應 當如何建立數據倉庫系統的概念模型。一方面，通過原有的數據庫的設計文檔以及在數據字典中的數據庫關系模式，可以對企業現有的數據庫中的內容有一個完整而 清晰的認識 ; 另一方面，數據倉庫的概念模型是面向企業全局建立的，它為集成來自各個面向應用的數據庫的數據提供了統一的概念視圖。

概念模型的設計是在較高的抽象層次上的設計，因此建立概念模型時不用考慮具體技術條件的限制。

1. 界定系統的邊界

數據倉庫是面向決策分析的數據庫，我們無法在數據倉庫設計的最初就得到詳細而明確的需求，但是一些基本的方向性的需求還是擺在了設計人員的面前 :

• 要做的決策類型有哪些 ?
• 決策者感興趣的是什么問題 ?
• 這些問題的需要什么樣的信息 ?
• 要得到這些信息需要包含原有數據庫系統的哪些部分的數據 ?

這樣，我們可以劃定一個當前的大致的系統邊界，集中精力進行最需要的部分的開發。因而，從某種意義上講，界定系統邊界的工作也可以看作是數據倉庫系統設計的需求分析，因為它將決策者的數據分析的需求用系統邊界的定義形式反映出來。

2 ，確定主要的主題域

在這一步中，要確定所包含的主題域，然后對每個主題域的內容進行較明確數據倉庫建模技術在 XX 行業中的應用的描述，描述的內容包括 :

• 主題域的公共碼鍵 ;
• 主題域之間的聯系 :
• 充分代表主題的屬性組。

概念模型的構建通常是企業的 shakeholder, 商務領域知識專家和 IT 專家共同企業級地跨領域業務系統需求分析的結果 .

通常企業決策者有自己的發展戰略和規劃 , 他們會定期閱讀由各部門經理上報的分析報告 , 他們也知道大致了解自己企業信息系統的功能 , 但是未必清楚自己的每一個業務系統的每一個功能和每一部分數據 , 畢竟決策者不是信息專家 , 他們更關心的企業的經營業績 , 資產負債 , 盈虧受益等等核心指標 .

各個部門經理往往很了解自己部門的信息系統 , 在信息系統規劃時優先考慮的是自己的利益 , 因此每個部門往往都在獨立的構建自己的信息系統 , 無法或者不可能從 企業總體角度和其他業務系統接軌 , 如 ERP 系統 ,MIS 系統 ,CRM 系統等等 , 這就造成了企業在發展企業信息系統時的不平衡 , 導致了所謂的孤島效應 , 他們 會閱讀下屬提供的分析報告 , 然后進行歸納整理 , 形成部門報表進行上報 , 但是最終結果卻是每個部門都在上報自己的經營業績 , 卻始終缺乏一個一致的統一的數 字 .

普通用戶更關注的是某一類與工作相關的報表 , 包括報表的數據準確性 , 報表的樣式 , 圖標格式這類的細節 .

而 IT 部門負責企業 IT 系統的預算 , 采購 , 但是因為職能部門不同 , 無法深入了解各個信息系統的業務 .

有這么一句話 : 如果你想實施某個企業信息系統 , 你必須能夠具備擔當這個企業副總的能力 . 這就要求項目負責人能夠站在企業的戰略高度考慮 , 同時具備很高的協 調能力和管理能力 ; 所以必須引入商務領域知識專家和 IT 專家的角色 ( 就是通常所說的咨詢顧問 ), 這些人往往具備比較資深的行業背景 , 具備豐富的獨立實施該 行業信息系統建設的經驗 , 了解該行業最先進和通用的標準和規范 , 同時在結合現有企業信息系統的基礎上 , 以及融合企業發展戰略的基礎上 , 提出當前企業的業務 模型 , 來幫助企業提高決策支持分析能力 , 但是這樣的模型不能太超前 , 太超前則意味脫離了實際 , 不具備實際可操作性 ; 當然更不能停留在于企業目前的信息建設 水平上 , 否則就失去了意義 .

 

邏輯模型設計

邏輯建模是數據倉庫實施中的重要一環，因為它能直接反映出業務部門的需求，同時對系統的物理實施有著重要的指導作用。通過實體和關系勾勒出真個企業的數據藍圖。

在這一步里進行的工作主要有 :

• 分析豐富主題域，確定當前要裝載的主題 ;
• 確定粒度層次劃分 ;
• 確定數據分割策略 ;
• 關系模式定義 ;
• 記錄系統定義

邏輯模型設計的成果是，對每個當前要裝載的主題的邏輯實現進行定義，并將相關內容記錄在數據倉庫的元數據中，包括 :

適當的粒度劃分 ;

合理的數據分割策略 ;

適當的表劃分 ;

定義合適的數據來源等。

1. 分析主題域

在概念模型設計中，我們確定了幾個基本的主題域，但是，數據倉庫的設計方法是一個逐步求精的過程，在進行設計時，一般是一次一個主題或一次若干個主題地逐 步完成的。所以，我們必須對概念模型設計步驟中確定的幾個基本主題域進行分析，一并選擇首先要實施的主題域。選擇第一個主題域所要考慮的是它要足夠大，以 便使得該主題域能建設成為一個可應用的系統 ; 它還要足夠小，以便于開發和較快地實施。如果所選擇的主題域很大并且很復雜，我們甚至可以針對它的一個有意義 的子集來進行開發。在每一次的反饋過程中，都要進行主題域的分析。具體的實施細節需要和 AAA 業務部門和信息中心溝通。

2. 粒度層次劃分

數據倉庫邏輯設計中要解決的一個重要問題是決定數據倉庫的粒度劃分層次，粒度層次劃分適當與否直接影響到數據倉庫中的數據量和所適合的查詢類型。由于主題 數據庫響應企業級業務 OLTP 需求，所以必須保存最細類度數據，同時根據業務部門的查詢需求考慮確定多重粒度來提高復雜查詢速度。

3. 確定數據分割策略

在這一步里，要選擇適當的數據分割的標準，一般要考慮以下幾方面因素 : 數據量〔而非記錄行數 ) 、數據分析處理的實際情況、簡單易行以及粒度劃分策略等。數 據量的大小是決定是否進行數據分割和如何分割的主要因素 ; 數據分析處理的要求是選擇數據分割標準的一個主要依據，因為數據分割是跟數據分析處理的對象緊密 聯系的 ; 我們還要考慮到所選擇的數據分割標準應是自然的、易于實施的 : 同時也要考慮數據分割的標準與粒度劃分層次是適應的。

4. 關系模式定義

數據倉庫的每個主題都是由多個表來實現的，這些表之間依靠主題的公共碼鍵聯系在一起，形成一個完整的主題。在概念模型設計時，我們就確定了數據倉庫的基本 主題，并對每個主題的公共碼鍵、基本內容等做了描述在這一步里，我們將要對選定的當前實施的主題進行模式劃分，形成多個表，并確定各個表的關系模式。

物理模型設計

這一步所做的工作是根據信息系統的容量 , 復雜度 , 項目資源以及數據倉庫項目自身的軟件生命周期確定數據倉庫系統的軟硬件配置 , 數據倉庫分層設計模式 , 數據的存儲結構，確定索引策略，確定數據存放位置，確定存儲分配等等。這部分應該是由項目經理和數據倉庫架構師共同實施的 .

確定數據倉庫實現的物理模型，要求設計人員必須做到以下幾方面 :

1. 確定項目資源

根據預算和業務需求 , 并參考以往的數據倉庫項目經驗 , 對該項目的成本周期和資源進行估算 .

關于項目周期的估算 , 主要基于 ETL 函數功能點以及加權后的復雜度進行估算 , 因為 ETL 過程占據了整個數據倉庫項目的 70%,;ETL 過程主要是基于 源 <=> 目的的原則進行處理的 , 而不同的功能點具有不同的復雜度 , 通過以往項目經驗和專家評估 , 然后再根據軟件生命周期的劃分 , 可以有效的得 知項目的整體周期 .

關于人員的估算 , 主要取決于人員的工作經驗 , 素養 , 對新技術的掌握能力 , 還要考慮到人員流動等方面的人員備份 .

協作 , 每一個 IT 企業都應該具備一個豐富的技能和人力資源庫 , 當項目資源遇到瓶頸的時候 , 就可以考慮需求協作 .

2. 確定軟硬件配置

數據倉庫項目與其他業務系統不同 , 尤其需要對數據容量進行估算 , 這是因為數據倉庫是歷史的穩定的基于主題的集成的等等特性所決定的 , 他是對以往歷史數據的集成 , 如果項目初期不加以考慮 , 很快就會造成災難性的后果 .

數據倉庫的容量估算應該是可預見的 , 首先確定核心明細數據的存儲年限 , 相關表的平均字段長度值 * 每年的記錄數 *( 每年預計的增長 ), 然后再加上 20% 的冗余 , 以及磁盤預留的 20% 的冗余 , 我們不難得到數據倉庫的預計容量 .

數據倉庫的處理能力和容量息息相關 , 也和具體的關系數據庫的性能息息相關 , 如何在 Oracle,SQLServer,DB,Sybase 甚至 MySQL 之間尋找平衡 , 既要考慮實際的預算 , 也要視實際的需求而定 .

關于硬件的配置 , 既需要發揮軟件的功能 , 滿足實際的處理要求 , 也要為將來的系統擴展保留一定的空間 .

3. 數據倉庫存儲設計

數據倉庫一般采用分層設計 , 即 ODS 層 , 數據倉庫層 , 數據倉庫聚合層數據集市等等 ; 數據倉庫的分層是靈活的 , 沒有固定的模式 , 一切視實際情況而定 .

ODS 層存放從原系統采集來的原始交易數據，只保存一定期限內的數據，同時 ODS 支持部分近實時性報表的展示 .

數據倉庫層保存經過清洗，轉換和重新組織的歷史業務數據，數據將保留較長時間 (5~10 年不等 ), 滿足系統最細粒度的查詢需要 .

數據倉庫聚合層面向 KPI 指標計算和分析，支持匯總層面交易級的指標查詢 , 提高匯總級的 KPI 數據展示速度和數據保存時間。保存較長的歷史數據 .

數據集市是基于部門或者某一類特定分析主題需要 , 從企業級數據倉庫單獨獲取的一個數據的邏輯或者物理的子集 .

4. 數據倉庫模式

數據抽取策略

制定系統的主題數據庫 ETL 抽取方案來滿足主題數據庫的業務處理，數據倉庫系統分析及決策支持分析的需要，同時必須保證不能影響業務系統的性能

數據轉換策略

數據轉換是指對從業務系統中抽取的源數據根據主題數據庫系統模型的要求，進行數據的轉換、清洗、拆分等處理，保證來自不同系統、不同格式的數據的一致性和完整性，并按要求裝入主題數據庫

數據加載策略

從業務系統中抽取、轉換后的數據加載到主題數據庫系統中。

數據質量的檢查

星型模型

數據通常采用星型模型存儲。星型模型由維表與事實表構成，一般并非業務系統中的規范化的范式結構。在核心層中，針對即定的主題，通常會建立若干星型模型。

本文轉載自微信公眾號「追夢IT人」，可以通過以下二維碼關注。轉載本文請聯系追夢IT人公眾號。