數據倉庫搭建步驟

數據倉庫是面向主題的、集成的、不可更新的、隨時間的變化而不斷變化的，這些特色決定了數據倉庫的系統設計不能採用同開發傳統的OLTP數據庫同樣的設計方法。
        數據倉庫系統的原始需求不明確，且不斷變化與增長，開發者最初不能確切瞭解到用戶的明確而詳細的需求，用戶所能提供的無非是需求的大的方向以及部分需求，更不能較準確地預見到之後的需求。所以，採用原型法來進行數據倉庫的開發是比較合適的，由於原型法的思想是從構建系統的簡單的基本框架着手，不斷豐富與完善整個系統。可是，數據倉庫的設計開發又不一樣於通常意義上的原型法，數據倉庫的設計是數據驅動的。這是由於數據倉庫是在現存數據庫系統基礎上進行開發，它着眼於有效地抽取、綜合、集成和挖掘已有數據庫的數據資源，服務於企業高層領導管理決策分析的須要。但須要說明的是，數據倉庫系統開發是一個通過不斷循環、反饋而使系統不斷增加與完善的過程，這也是原型法區別於系統生命週期法的主要特色。所以，在數據倉庫的開發的整個過程當中，自始至終要求決策人員和開發者的共同參與和密切協做，要求保持靈活的頭腦，不作或儘可能少作無效工做或重複工做。
    數據倉庫的設計大致上能夠分爲如下幾個步驟：
l        概念模型設計；
l        技術準備工做；
l        邏輯模型設計；   
l        物理模型設計；
l        數據倉庫生成；
l        數據倉庫運行與維護。
        下面咱們六個主要設計步驟爲主線，介紹在各個設計步驟中設計的基本內容。
第一節  概念模型設計
        進行概念模型設計所要完成的工做是：
< 1>界定系統邊界      
< 2>肯定主要的主題域及其內容
        概念模型設計的成果是，在原有的數據庫的基礎上創建了一個較爲穩固的概念模型。由於數據倉庫是對原有數據庫系統中的數據進行集成和重組而造成的數據集合，因此數據倉庫的概念模型設計，首先要對原有數據庫系統加以分析理解，看在原有的數據庫系統中「有什麼」、「怎樣組織的」和「如何分佈的」等，而後再來考慮應當如何創建數據倉庫系統的概念模型。一方面，經過原有的數據庫的設計文檔以及在數據字典中的數據庫關係模式，能夠對企業現有的數據庫中的內容有一個完整而清晰的認識；另外一方面，數據倉庫的概念模型是面向企業全局創建的，它爲集成來自各個面向應用的數據庫的數據提供了統一的概念視圖。
    概念模型的設計是在較高的抽象層次上的設計，所以創建概念模型時不用考慮具體技術條件的限制。
1. 界定系統的邊界
    數據倉庫是面向決策分析的數據庫，咱們沒法在數據倉庫設計的最初就獲得詳細而明確的需求，可是一些基本的方向性的需求仍是擺在了設計人員的面前：
l        要作的決策類型有哪些?
l        決策者感興趣的是什麼問題?
l        這些問題須要什麼樣的信息?
l        要獲得這些信息須要包含原有數據庫系統的哪些部分的數據?
    這樣，咱們能夠劃定一個當前的大體的系統邊界，集中精力進行最須要的部分的開發。於是，從某種意義上講，界定系統邊界的工做也能夠看做是數據倉庫系統設計的需求分析，由於它將決策者的數據分析的需求用系統邊界的定義形式反映出來。
2. 肯定主要的主題域
     在這一步中，要肯定系統所包含的主題域，而後對每一個主題域的內容進行較明確的描述，描述的內容包括：
l        主題域的公共碼鍵；
l        主題域之間的聯繫；
l        充分表明主題的屬性組。  
第二節  技術準備工做
    這一階段的工做包括：技術評估，技術環境準備。
        這一階段的成果是：技術評估報告、軟硬件配置方案、系統(軟、硬件)整體設計方案。管理數據倉庫的技術要求與管理操做型環境中的數據與處理的技術要求區別很大，二者所考慮的方面也不一樣。咱們之因此在通常狀況下老是將分析型數據與操做型數據分離開來，將分析型數據單獨集中存放，也就是用數據倉庫來存放，技術要求上的差別是一個重要緣由。
1. 技術評估
    進行技術評估，就是肯定數據倉庫的各項性能指標。通常狀況下，須要在這一步裏肯定的性能指標包括：
l        管理大數據量數據的能力；
l        進行靈活數據存取的能力；
l        根據數據模型重組數據的能力；

l        透明的數據發送和接收能力；
l        週期性成批裝載數據的能力；
l        可設定完成時間的做業管理能力。
2. 技術環境準備
    一旦數據倉庫的體系化結構的模型大致建好後，下一步的工做就是肯定咱們應該怎樣來裝配這個體系化結構模型，主要是肯定對軟硬件配置的要求；咱們主要考慮相關的問題：
l        預期在數據倉庫上分析處理的數據量有多大?
l        如何減小或減輕競爭性存取程序的衝突?
l        數據倉庫的數據量有多大?
l        進出數據倉庫的數據通訊量有多大?等等。
        根據這些考慮，咱們就能夠肯定各項軟硬件的配備要求，而且在這一步工做結束時各項技術準備工做應已就緒，能夠裝載數據了。這些配備有：
l        直接存取設備(DASD)；
l        網絡；
l        管理直接存取設備(DASD)的操做系統；
l        進出數據倉庫的界面(主要是數據查詢和分析工具)；
        管理數據倉庫的軟件，目前即選用數據庫管理系統及有關的選件，購買的DBMS產品不能知足管理數據倉庫須要的，還應考慮本身或軟件集成商開發有關模塊等等。
第三節  邏輯模型設計
    在這一步裏進行的工做主要有：
l        分析主題域，肯定當前要裝載的主題；
l        肯定粒度層次劃分；
l        肯定數據分割策略；
l        關係模式定義；
l        記錄系統定義
邏輯模型設計的成果是，對每一個當前要裝載的主題的邏輯實現進行定義，並將相關內容記錄在數據倉庫的元數據中，包括：
l        適當的粒度劃分；
l        合理的數據分割策略；
l        適當的表劃分；
l        定義合適的數據來源等。
1. 分析主題域
    在概念模型設計中，咱們肯定了幾個基本的主題域，可是，數據倉庫的設計方法是一個逐步求精的過程，在進行設計時，通常是一次一個主題或一次若干個主題地逐步完成的。因此，咱們必須對概念模型設計步驟中肯定的幾個基本主題域進行分析，並選擇首先要實施的主題域。選擇第一個主題域所要考慮的是它要足夠大，以便使得該主題域能建設成爲一個可應用的系統；它還要足夠小，以便於開發和較快地實施。若是所選擇的主題域很大而且很複雜，咱們甚至能夠針對它的一個有意義的子集來進行開發。在每一次的反饋過程當中，都要進行主題域的分析。
2. 粒度層次劃分
    數據倉庫邏輯設計中要解決的一個重要問題是決定數據倉庫的粒度劃分層次，粒度層次劃分適當與否直接影響到數據倉庫中的數據量和所適合的查詢類型。肯定數據倉庫的粒度劃分，可使用在粒度劃分一節中介紹的方法，經過估算數據行數和所需的DASD數，來肯定是採用單一粒度仍是多重粒度，以及粒度劃分的層次。
3. 肯定數據分割策略
    在這一步裏，要選擇適當的數據分割的標準，通常要考慮如下幾方面因素：數據量(而非記錄行數)、數據分析處理的實際狀況、簡單易行以及粒度劃分策略等。數據量的大小是決定是否進行數據分割和如何分割的主要因素；數據分析處理的要求是選擇數據分割標準的一個主要依據，由於數據分割是跟數據分析處理的對象緊密聯繫的；咱們還要考慮到所選擇的數據分割標準應是天然的、易於實施的：同時也要考慮數據分割的標準與粒度劃分層次是適應的。
4. 關係模式定義
    數據倉庫的每一個主題都是由多個表來實現的，這些表之間依靠主題的公共碼鍵聯繫在一塊兒，造成一個完整的主題。在概念模型設計時，咱們就肯定了數據倉庫的基本主題，並對每一個主題的公共碼鍵、基本內容等作了描述在這一步裏，咱們將要對選定的當前實施的主題進行模式劃分，造成多個表，並肯定各個表的關係模式。

第四節  物理模型設計
    這一步所作的工做是肯定數據的存儲結構，肯定索引策略，肯定數據存放位置，肯定存儲分配。
    肯定數據倉庫實現的物理模型，要求設計人員必須作到如下幾方面：
l        要全面瞭解所選用的數據庫管理系統，特別是存儲結構和存取方法。
l        瞭解數據環境、數據的使用頻度、使用方式、數據規模以及響應時間要求等，這些是對時間和空間效率進行平衡和優化的重要依據。
l        瞭解外部存儲設備的特性，如分塊原則，塊大小的規定，設備的I／O特性等。
1. 肯定數據的存儲結構
    一個數據庫管理系統每每都提供多種存儲結構供設計人員選用，不一樣的存儲結構有不一樣的實現方式，各有各的適用範圍和優缺點，設計人員在選擇合適的存儲結構時應該權衡三個方面的主要因素：存取時間、存儲空間利用率和維護代價。
2. 肯定索引策略
    數據倉庫的數據量很大，於是須要對數據的存取路徑進行仔細的設計和選擇。因爲數據倉庫的數據都是不常更新的，於是能夠設計多種多樣的索引結構來提升數據存取效率。
在數據倉庫中，設計人員能夠考慮對各個數據存儲創建專用的、複雜的索引，以得到最高的存取效率，由於在數據倉庫中的數據是不常更新的，也就是說每一個數據存儲是穩定的，於是雖然創建專用的、複雜的索引有必定的代價，但一旦創建就幾乎不需維護索引的代價。
3. 肯定數據存放位置
    咱們說過，同一個主題的數據並不要求存放在相同的介質上。在物理設計時，咱們經常要按數據的重要程度、使用頻率以及對響應時間的要求進行分類，並將不一樣類的數據分別存儲在不一樣的存儲設備中。重要程度高、常常存取並對響應時間要求高的數據就存放在高速存儲設備上，如硬盤；存取頻率低或對存取響應時間要求低的數據則能夠放在低速存儲設備上，如磁盤或磁帶。
數據存放位置的肯定還要考慮到其它一些方法，如：決定是否進行合併表；是否對一些常常性的應用創建數據序列；對經常使用的、不常修改的表或屬性是否冗餘存儲。若是採用了這些技術，就要記入元數據。
4. 肯定存儲分配
    許多數據庫管理系統提供了一些存儲分配的參數供設計者進行物理優化處理，如：塊的尺寸、緩衝區的大小和個數等等，它們都要在物理設計時肯定。這同建立數據庫系統時的考慮是同樣的。
第五節  數據倉庫的生成
    在這一步裏所要作的工做是接口編程，數據裝入。
    這一步工做的成果是，數據已經裝入到數據倉庫中，能夠在其上創建數據倉庫的應用，即DSS應用。
1. 設計接口
    將操做型環境下的數據裝載進入數據倉庫環境，須要在兩個不一樣環境的記錄系統之間創建一個接口。乍一看，創建和設計這個接口，彷佛只要編制一個抽取程序就能夠了，事實上，在這一階段的工做中，的確對數據進行了抽取，但抽取並非所有的工做，這一接口還應具備如下的功能：
l        從面向應用和操做的環境生成完整的數據；
l        數據的基於時間的轉換；
l        數據的凝聚；
l        對現有記錄系統的有效掃描，以便之後進行追加。
    固然，考慮這些因素的同時，還要考慮到物理設計的一些因素和技術條件限制，根據這些內容，嚴格地制定規格說明，而後根據規格說明，進行接口編程。從操做型環境到數據倉庫環境的數據接口編程的過程和通常的編程過程並沒有區別，它也包括僞碼開發、編碼、編譯、檢錯、測試等步驟。
在接口編程中，要注意：
l        保持高效性，這也是通常的編程所要求的；
l        要保存完整的文檔記錄；
l        要靈活，易於改動；
l        要能完整、準確地完成從操做型環境到數據倉庫環境的數據抽取、轉換與集成。
2. 數據裝入
在這一步裏所進行的就是運行接口程序，將數據裝入到數據倉庫中。主要的工做是：
l        肯定數據裝入的次序；
l        清除無效或錯誤數據；
l        數據「老化」 ；
l        數據粒度管理；
l        數據刷新等。
最初只使用一部分數據來生成第一個主題域，使得設計人員可以輕易且迅速地對已作工做進行調整，並且可以儘早地提交到下一步驟，即數據倉庫的使用和維護。這樣既能夠在經濟上最快地獲得回報，又可以經過最終用戶的使用、儘早發現一些問題並提出新的需求，而後反饋給設計人員，設計人員繼續對系統改進、擴展。

第六節  數據倉庫的使用和維護
    在這一步中所要作的工做有創建DSS應用，即便用數據倉庫理解需求，調整和完善系統，維護數據倉庫。
    創建企業的體系化環境，不只包括創建起操做型和分析型的數據環境，還應包括在這一數據環境中創建起企業的各類應用。數據倉庫裝入數據以後，下一步工做是：一方面，使用數據倉庫中的數據服務於決策分析的目的，也就是在數據倉庫中創建起DSS應用；另外一方面，根據用戶使用狀況和反饋來的新的需求，開發人員進一步完善系統，並管理數據倉庫的一些平常活動，如刷新數據倉庫的當前詳細數據、將過期的數據轉化成歷史數據、清除再也不使用的數據、調整粒度級別等。咱們把這一步驟稱爲數據倉庫的使用與維護。
1. 創建DSS應用
    使用數據倉庫，即開發DSS應用，與在操做型環境中的應用開發有着本質區別，開發DSS應用不一樣於聯機事務處理應用開發的顯著特色在於：
l        DSS應用開發是從數據出發的；
l        DSS應用的需求不能在開發初期明確瞭解；
l        DSS應用開發是一個不斷循環的過程，是啓發式的開發。
DSS應用主要可分爲兩類：例行分析處理和啓發式分析處理。例行分析處理是指那些重複進行的分析處理，它一般是屬於部門級的應用，如部門統計分析，報表分析等等；而我的級的分析應用常常是隨機性很大的，企業經營者受到某種信息啓發而進行的一些即席的分析處理，因此咱們稱之爲啓發式的分析處理。
    DSS應用開發的大體步驟以下：
    步驟l——肯定所需的數據。爲知足DSS應用的要求，咱們必須從數據倉庫中肯定一個可能用到的數據範圍。這是一個試探的過程。
    步驟2——編程抽取數據。根據上面獲得的數據範圍，編寫一個抽取程序來得到這些數據。爲適應分析需求多變的特色，要求所編寫的抽取程序應該通用，易於修改。
    步驟3——合併數據。若是有多個數據抽取源，要將抽取來的數據進行合併、提煉，使數據符合分析處理的要求。
    步驟4——分析數據。在上步準備好的數據基礎上進行分析處理，並看所得的結果是否知足了原始的要求，若是不能知足，則返回步驟1，開始新的一次循環，不然就準備最終分析結果報告。
    步驟5——回答問題。生成最終分析結果報告。—般狀況下，最終的分析結果報告是在許屢次的循環後獲得的，由於一次分析處理不多是在一次循環後就完成的。
    步驟6——例行化、一次分析處理的最後、咱們要決定是否將在上面已經創建的分析處理例行化。若是創建的分析處理是重複進行的部門級的DSS應用，那麼最好是將它例行化，這樣在進行下一次一樣的分析處理時，沒必要再重複上述六步的循環過程。並且，不斷地積累這種例行處理，造成一個集合，咱們就能夠經過組合這些已有的處理來生成新的一個較大的複雜處理，或完成一個複雜處理的一部分。
2. 理解需求，改善和完善系統，維護數據倉庫
    數據倉庫的開發是逐步完善的原型法的開發方法，它要求：要儘快地讓系統運行起來，儘早產生效益；要在系統運行或使用中，不斷地理解需求，改善系統；不斷地考慮新的需求，完善系統。
維護數據倉庫的工做主要是管理平常數據裝入的工做，包括刷新數據倉庫的當前詳細數據，將過期的數據轉化成歷史數據．清除再也不使用的數據，管理元數據，等等；另外，如何利用接口按期從操做型環境向數據倉庫追加數據，肯定數據倉庫的數據刷新頻率，等等。