[[346087]]

 業(yè)務(wù)驅(qū)動(dòng)

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

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

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

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

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

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

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

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

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

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

概念模型設(shè)計(jì)

進(jìn)行概念模型設(shè)計(jì)所要完成的工作是 :

界定系統(tǒng)邊界

確定主要的主題域及其內(nèi)容

確定主題域的關(guān)系

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

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

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

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

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

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

2 ，確定主要的主題域

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

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

概念模型的構(gòu)建通常是企業(yè)的 shakeholder, 商務(wù)領(lǐng)域知識(shí)專家和 IT 專家共同企業(yè)級(jí)地跨領(lǐng)域業(yè)務(wù)系統(tǒng)需求分析的結(jié)果 .

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

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

普通用戶更關(guān)注的是某一類與工作相關(guān)的報(bào)表 , 包括報(bào)表的數(shù)據(jù)準(zhǔn)確性 , 報(bào)表的樣式 , 圖標(biāo)格式這類的細(xì)節(jié) .

而 IT 部門負(fù)責(zé)企業(yè) IT 系統(tǒng)的預(yù)算 , 采購 , 但是因?yàn)槁毮懿块T不同 , 無法深入了解各個(gè)信息系統(tǒng)的業(yè)務(wù) .

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

邏輯模型設(shè)計(jì)

邏輯建模是數(shù)據(jù)倉庫實(shí)施中的重要一環(huán)，因?yàn)樗苤苯臃从吵鰳I(yè)務(wù)部門的需求，同時(shí)對(duì)系統(tǒng)的物理實(shí)施有著重要的指導(dǎo)作用。通過實(shí)體和關(guān)系勾勒出真?zhèn)€企業(yè)的數(shù)據(jù)藍(lán)圖。

在這一步里進(jìn)行的工作主要有 :

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

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

適當(dāng)?shù)牧６葎澐?;

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

適當(dāng)?shù)谋韯澐?;

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

1. 分析主題域

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

2. 粒度層次劃分

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

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

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

4. 關(guān)系模式定義

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

物理模型設(shè)計(jì)

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

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

1. 確定項(xiàng)目資源

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

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

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

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

2. 確定軟硬件配置

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

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

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

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

3. 數(shù)據(jù)倉庫存儲(chǔ)設(shè)計(jì)

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

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

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

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

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

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

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

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

數(shù)據(jù)轉(zhuǎn)換策略

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

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

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

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

星型模型

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

本文轉(zhuǎn)載自微信公眾號(hào)「追夢(mèng)IT人」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系追夢(mèng)IT人公眾號(hào)。