數據倉庫技術作為一項數據管理領域的新技術，其精髓在于針對聯機分析處理(OLAP)提出了一種綜合的解決方案，與以往很多技術不同的是，它主要是一種概念，在此概念指導下完成系統的構造。既沒有可以直接購買到的現成產品，也沒有具體的分析規范和實現方法，也就是說沒有成熟、可靠且被廣泛接受的數據倉庫標準。在以往關系數據庫的設計和實現中，不僅有詳細的理論推導，還有無數的設計實例，無論你使用的是什么公司的數據庫產品、開發工具，只要按照規范做，那么實現同一業務需求的方案都會很相似。而現有數據倉庫的實現中，出現了MOLAP方案和ROLAP方案的區別，出現了形形色色的數據倉庫建模工具、表現工具，而設計人員的個人經驗和素質也會在其中扮演很重要的角色。

數據倉庫技術的實現方式

目前在數據倉庫技術的實際應用中主要包括如下幾種具體實現方式。

1、在關系數據庫上建立數據倉庫(ROLAP)

2、在多維數據庫上建立數據倉庫(MOLAP)

MOLAP方案是以多維方式來組織數據，以多維方式來存儲數據；ROLAP方案則以二維關系表為核心表達多維概念，通過將多維結構劃分為兩類表:維表和事實表，使關系型結構能較好地適應多維數據的表示和存儲。在多維數據模型的表達方面，多維矩陣比關系表更清晰且占用的存儲更少，而通過關系表間的連接來查詢數據的ROLAP系統，系統性能成為最大問題。MOLAP方案比ROLAP方案要簡明，索引及數據聚合可以自動進行并自動管理，但同時喪失了一定的靈活性。ROLAP方案的實現較為復雜，但靈活性較好，用戶可以動態定義統計和計算方式，另外能保護在已有關系數據庫上的投資。

由于兩種方案各有優劣，因此在實際應用中，往往將MOLAP和ROLAP結合使用，即所謂的混合模型。利用關系數據庫存儲歷史數據、細節數據或非數值型數據，發揮關系數據庫技術成熟的優勢，減少花費，而在多維數據庫中存儲當前數據和常用統計數據，以提高操作性能。

3、在原有關系庫上建立邏輯上的數據倉庫

由于目前正在運行的OLTP系統中已經積累了海量數據，如何從中提取出決策所需的有用信息就成為用戶最迫切的需要。新建數據倉庫固然能從功能、性能各方面給出一個完整的解決方案，但需要投入大量的人力、物力，并且數據倉庫的建設和分析數據的積累需要一段時間，無法及時滿足用戶對信息分析的迫切需要。因此在籌建數據倉庫的前期，可以采用一些合適的表現工具，在原有OLTP系統上建立起一個邏輯的數據倉庫系統。盡管由于原有OLTP系統設計上的局限性，這樣的系統可能無法實現很多分析功能，但這樣一個系統中數據結構固定、信息分析需求相對穩定成熟，因此數據倉庫的建模、實現過程會相對容易、便捷；同時，這樣的系統也會成為將來真正數據倉庫建設的原型。

信息系統與數據倉庫的關系

由于數據量大、數據來源多樣化，在商業銀行構建管理信息系統時，不可避免地會遇上如何管理這些浩如煙海的數據，以及如何從中提取有用的信息的問題；而數據倉庫的最大優點在于它能把企業網絡中不同信息島上的商業數據集中到一起，存儲在一個單一的集成的數據庫中，并提供各種手段對數據進行統計、分析。因此可以說，在銀行使用數據倉庫構建管理信息系統，既有壓力，又有數據基礎，它們之間的聯系是必然的，難以割舍的。

數據倉庫在商業銀行的應用范圍包括存款分析、貸款分析、客戶市場分析、相關金融業分析決策(證券、外匯買賣)、風險預測、效益分析等。

在銀行信息系統構建時，由于歷史情況和現實需求的不同，存在兩種途徑:

1、建設新系統

由于目前國內商業銀行對銀行內部運營的監管，缺乏很好的數據搜集機制，因此可以在構建管理信息系統時，分數據收集錄入和數據匯總分析兩部分來考慮。這樣的系統中由于不需考慮大量歷史數據的處理問題，同時考慮到搜集過程中可能存在多個數據來源，因此可以在系統建設的同時構建數據倉庫，將搜集來的各種數據通過數據抽取整合到數據倉庫中。

2、完善原有系統

而對于已經存在OLTP系統，其中沉淀了大量歷史數據，則可以先在原有系統上建立邏輯數據倉庫，即使用數據分析的表現工具，在關系模型上構建一個虛擬的多維模型。當系統需求穩定后，再建立物理數據倉庫，這樣既節省投資，又縮短開發工期。

實現中需要注意的問題

一、模型設計中的問題

模型設計(包括邏輯模型設計和物理模型設計)是系統的基礎和成敗的關鍵，在實際操作中，視實現技術的不同應分別對下列問題引起注意。

1、直接構建數據倉庫

直接構建數據倉庫時，必須按業務分析的要求重組OLTP系統中的數據，并要按不同側重點分別組織，使之便于使用。

*主題的確定

主題是一個邏輯概念，它應該能夠完整、統一地刻畫出分析對象所涉及的各項數據以及相互聯系。劃分主題的根據主要來源于兩方面:對原有固定報表的分析和對業務人員的訪談。原有固定報表能較好地反映出以往工作對數據分析的需求，而且數據含義和格式相對成熟、穩定，在模型設計中需要大量借鑒。但僅僅滿足于替代目前的手工報表還遠遠不應是構建管理信息系統的目標，還應該通過業務訪談，進一步挖掘出日常工作中潛在的更廣、更深的分析需求。只有這樣，才能真正了解構建數據倉庫模型所需的主題劃分。

*分析內容的細化

主題的劃分實際上是與分析內容的范圍直接相關的，一旦主題劃分清楚了，下一步就是細化分析的具體內容以及根據分析內容的性質確定它在數據倉庫中的位置。通常維元素對應的是分析角度，而度量對應的是分析關心的具體指標。一個指標究竟是作為維元素、度量還是維屬性，取決于具體的業務需求，但從實際操作中可以總結出如下的概念性經驗:作為維元素或維屬性的通常是離散型的數據，只允許有限的取值；作為度量的是連續型數據，取值無限。如果一定要用連續型數據作為維元素，則必須對其按取值進行分段，以分段值作為實際的維元素。判斷分析指標是作為維元素還是維屬性時，則需要綜合考慮這個指標占用的存儲空間與相關查詢的使用頻度。

需要特別強調的是，在細化分析內容的過程中，務必解決指標的歧義問題。在不同報表中以及在業務訪談中同一名稱的指標，是否是在同樣條件限定下，通過同樣方法提取或計算得到的，它們之間的相互關系是什么，這些問題都必須從熟悉業務的分析人員那里得到準確、清晰的答案，否則將會影響到模型設計、數據提取、數據展現等多個方面。

*粒度的設計

數據倉庫模型中所存儲的數據的粒度將對信息系統的多方面產生影響。事實表中以各種維度的什么層次作為最細粒度，將決定存儲的數據能否滿足信息分析的功能需求，而粒度的層次劃分、以及聚合表中粒度的選擇將直接影響查詢的響應時間。

如果同一個信息系統要在大范圍、多層次上同時運行，如部門級和企業級，還應考慮不同層次的數據倉庫采用不同的粒度。

*模型設計中的技巧

復合指標尤其是比率類指標的定義，必須注意累加時是先加減后乘除，還是反之。戶數、筆數的計算，這類指標在分析或報表中經常出現，但不需要作為單獨的指標物理存在于數據庫中，但定義分析模型時一定應該準備。度量的時間特性，針對分析指標在時間維上的不同表現，可分為可累加指標、半可累加指標和不可累加指標。

2、在原有數據基礎上構建邏輯數據倉庫

如果直接使用OLTP系統中的數據進行數據分析處理，會遇到許多麻煩，有時甚至是不可能實現的。這并不是說關系數據庫不好，而是因為其設計思路不適應較大規模數據分析。因此在使用這種方法時，需要注意下列問題的處理:

*不同的時間單位

這是實現過程中最常遇到的問題，也往往是最難解決的問題。OLTP系統中存儲的時間往往采用與實際業務發生相同的時間單位，如帳務數據單位為日期，財務報表單位為月或半年。而面向分析時，往往要將不同時間單位的數據統一到同一個結果中，這樣就必須存在適當的轉換機制才能實現。

*冗余信息

所謂冗余信息，就是指不同關系表中存在的同一含義的字段，而同一含義不僅指這些字段的取得或計算方式一樣，還指它們成立的條件一樣，例如截止某一時間同一地區的同一貸種的貸款余額。在OLTP系統中，這樣的字段往往是基于性能考慮而設計的，而在面向分析設計模型時，為了保證結果的唯一性和準確性，就必須用且只用其中之一的數據產生分析結果。

*表間連接

由于OLTP系統中表的設計面向業務處理，既要保證數據的完整性、一致性，又要考慮響應時間，因此表與表之間既相對獨立，又相互依賴。在設計數據倉庫邏輯模型時，對表間的連接必須做出相應取舍，既要保證分析數據能通過連接取得或計算出，又要避免出現環路，造成分析數據的歧義。另外，不同的連接途徑還會出現不同的查詢速度，影響數據分析的響應性能。

*統計表的設計

如果上述問題不能在原有數據庫基礎上得到很好的解決，那么權益之計就是構建統計表，即簡單化的數據倉庫，形式類似數據倉庫的事實表，定時計算統計數據放入，將時間、冗余、連接等問題擯除，進行簡單分析。

二、數據抽取中的問題

數據抽取是一件技術含量不高，但非常煩瑣的工作，必須有專人負責數據抽取的工作。在對其進行設計時，要注意的問題有:

1、數據抽取的規則要作為元數據進行規范和管理，抽取過程中的源表、源字段、目的表、目的字段、轉換規則以及轉換條件都要作好詳細記錄。這樣不僅便于編程人員實現，而且在抽取規則或邏輯模型發生變化時也便于修改。

2、如何記錄業務數據庫中的變動情況是數據抽取中一個重要的環節。由于數據倉庫中按時間保存數據，因此不同時間點之間數據的差異就成為一個關鍵性因素。通常可以利用數據庫管理系統提供的手段在數據庫級產生數據變動日志，根據日志再判斷數據的變動情況完成抽取，這樣是一個從性能、可操作性以及對原業務系統的影響等多方面綜合考慮都比較理想的方法。

3、當數據倉庫中同一表中的數據來自于原有系統中不同的表，甚至不同的庫時，抽取時務必保證這些數據單位一致，而且都滿足同一時間條件。

4、數據抽取不僅要考慮數據的提取，還要考慮抽取的時間安排和執行方式，這樣才是一個完整的數據抽取方案，也才能保證抽取出來的數據準確、可用。

三、后期維護、優化中的問題

數據倉庫的建設是一個長期工作，它同其他系統一樣需要在運行的過程中不斷進行調整、完善。這其中包括兩方面的工作:

1、性能

數據倉庫涉及海量數據的查詢，數據的大量寫入讀出，不僅對數據庫系統的要求很高，而且與OLTP系統的要求極為不同，因此在系統設計、實施和維護的過程中，數據倉庫系統的性能都是一個不可忽視的問題。尤其是在運行期間，要密切關注應用對系統資源的消耗情況，針對應用的特點及時對系統進行調整，包括調整數據庫參數、數據分片放置、創建特殊索引乃至提高系統配置等。

2、模型

應用與需求是相互促進、不斷發展的，隨著信息系統建成運行，用戶在對系統了解不斷加深的過程中，也會對系統提出更新更高的要求。如何在最小投入的前提下滿足用戶的需求，也是一個值得注意和潛心研究的問題。首先要盡可能挖掘現有系統的潛力，其次考慮，對主題的增加或可在現有系統上增加少量指標就可解決的需求，對系統進行適當調整，最后才考慮對系統進行重構，盡可能減小系統建設中的投入。

數據倉庫應用的深化

按照上述方法實現的應用中，主要完成了報表的生成和日常業務的分析，這并不能給企業帶來真正的效益，也遠遠沒有發揮出數據倉庫的應用價值。隨著應用的深入，可以由企業的技術人員與業務人員緊密配合，規劃出對企業有實際價值的應用模型，并根據實際業務的發展不斷調整模型自身的參數，以期找出企業運作過程中的規律，即在數據倉庫上進行數據挖掘，構建DSS系統，這樣才能充分體現構建數據倉庫的意義，從而最終為企業帶來效益。

盡管數據倉庫技術還需要不斷發展、完善，但只要企業能認識到信息分析的重要性，業務人員和技術人員能真正配合起來，相信不久的將來會有更多的實用成果出現。

轉載于:https://www.cnblogs.com/fengye/archive/2007/02/04/639415.html

總結

以上是生活随笔為你收集整理的如何构建银行数据仓库的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。