[[346087]]

 業(yè)務驅動

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

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

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

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

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

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

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

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

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

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

概念模型設計

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

界定系統(tǒng)邊界

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

確定主題域的關系

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

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

1. 界定系統(tǒng)的邊界

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

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

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

2 ，確定主要的主題域

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

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

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

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

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

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

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

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

邏輯模型設計

邏輯建模是數(shù)據(jù)倉庫實施中的重要一環(huán)，因為它能直接反映出業(yè)務部門的需求，同時對系統(tǒng)的物理實施有著重要的指導作用。通過實體和關系勾勒出真?zhèn)€企業(yè)的數(shù)據(jù)藍圖。

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

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

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

適當?shù)牧６葎澐?;

合理的數(shù)據(jù)分割策略 ;

適當?shù)谋韯澐?;

定義合適的數(shù)據(jù)來源等。

1. 分析主題域

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

2. 粒度層次劃分

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

3. 確定數(shù)據(jù)分割策略

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

4. 關系模式定義

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

物理模型設計

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

確定數(shù)據(jù)倉庫實現(xiàn)的物理模型，要求設計人員必須做到以下幾方面 :

1. 確定項目資源

根據(jù)預算和業(yè)務需求 , 并參考以往的數(shù)據(jù)倉庫項目經(jīng)驗 , 對該項目的成本周期和資源進行估算 .

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

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

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

2. 確定軟硬件配置

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

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

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

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

3. 數(shù)據(jù)倉庫存儲設計

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

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

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

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

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

4. 數(shù)據(jù)倉庫模式

數(shù)據(jù)抽取策略

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

數(shù)據(jù)轉換策略

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

數(shù)據(jù)加載策略

從業(yè)務系統(tǒng)中抽取、轉換后的數(shù)據(jù)加載到主題數(shù)據(jù)庫系統(tǒng)中。

數(shù)據(jù)質量的檢查

星型模型

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

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