張靖笙
信息技術應用的卓越成效在經過20多年的信息化建設進程中已經初步顯現，信息技術廣泛應用的同時帶來了信息的泛濫，正如John Naisbett所說，“我們已被信息所淹沒，但是卻正在忍受缺乏知識的煎熬”。如何從大量的數據中快速有效的提取出我們需要的信息和知識也顯得越來越重要，讓我們不至于被信息海洋所淹沒；如何有效利用多年信息系統積累下來的大量數據，從被深埋的歷史數據中挖出財富；如何解決信息化建設過程中，由于歷史的認識水平和技術條件的限制所造成的信息化各子系統的脫節，而直接導致的信息孤島問題。以上這些都是我們當今政府和企業的信息系統迫切需要解決的問題。
“工欲善其事，必先利其器”，商業智能（BI，BusinessIntelligence）正是為了解決上述問題而應運而生的，商業智能本身是一個龐大的技術體系，也是一個還在發展中的概念，如何理解商業智能的內涵，業界有不同的觀點，而本章從工程實踐的角度，把商業智能看成實現“數據－>信息－>知識－>行動－>智慧”過程所用到的技術和方法，所以本章內容在組織安排上，體現了兩種對商業智能的觀點：
ü 一種觀點把商業智能看成是一個過程，這是DWReview的觀點，商業智能是幫助企業實現“數據－>信息－>知識”的過程，這是本文1.1-1.3節所描述的內容，力求讀者對商業智能有一個技術視野以外的認識；
ü 另外一種觀點是把商業智能看成一系列的技術和方法，這是代表了最早由Gartner Group于1996年提出商業智能定義的觀點：商業智能為一類由數據倉庫（或數據集市）、查詢報表、數據分析、數據挖掘、數據備份和恢復等部分組成的、以幫助企業決策為目的技術及其應用，這是本文1.4和其他幾節所要描述的內容，具體描述各個相關技術點的知識。
這一節將從時代發展需要和現實需求的角度，對應用商業智能的深層原因進行探討。
企業與政府機構的信息化建設從零開始到現在，大致經歷了三個階段（如圖6－1）：第一階段是部門級與基礎信息化階段，在這一階段，機構內往往是一些需求最迫切的部門首先采用了信息技術，如財務系統，計算機輔助設計系統，電子數據交換系統等等，以電子化和處理自動化來取代低效繁雜的手工處理；第二階段是企業級信息化階段，這一階段政府機構與企業往往已經擁有了幾個分別建設的業務處理系統，機構期望從總體角度建設高度集中的、或互相聯接的綜合業務管理系統，如MIS，ERP，OA等等；第三是企業或政府機構的戰略與決策信息化階段，這時企業或政府機構往往已經建成了比較完整的業務處理系統，而企業和政府機構在對業務系統里面數據的綜合利用主要面臨著三大問題，分別是不同業務數據的共享與綜合處理問題、歷史數據的利用問題以及數據角度的事務處理與決策差異性問題，這三大問題也是滿足企業或機構的領導者和決策者通過數據來做出正確判斷和決策的障礙，因此建立專門面向各級領導與決策層的信息系統，實現企業或政府機構戰略和決策的信息化，可以說是這一階段的核心任務，圖1表示了這三個發展階段。
圖1 企業信息化建設的三個階段
可見，隨著企業的發展所帶來的對信息需求分別從廣度和深度兩個層面不斷擴展，第一期階段的發展瓶頸在于信息的空間局限性，第二階段的發展瓶頸在于信息的時間局限性，可以說，企業信息化進程經過這三個發展階段，企業的管理水平也從“基于數據”，發展為“基于信息”，進而上升為“基于知識”。顯然，在競爭日益激烈的環境下，錯誤的決策對企業的打擊是顛覆性的，一個企業只有達到“基于知識”的學習型組織的管理境界，才能不斷成長，在市場上生存。
把企業形象地比喻一個人的話，第一階段是針對手指的自動化，第二階段是針對眼睛和耳朵的自動化，第三階段是針對大腦的自動化。從圖1的縱坐標我們也可以看到，信息化的價值以及由此給企業帶來的實力也是獲得提升的。
而第三階段正是商業智能走上歷史舞臺并且成為主角的時代，也是企業求生存求發展不得不走向學習型組織管理方式的歷史選擇，促成商業智能產生和發展的根源，筆者認為，不單純是技術的進步，當然不可否認，技術的進步創造了物質上的條件，然而從因果關系的角度來說，企業選擇商業智能的根本原因，是市場競爭下求生存謀發展的必然。
商業智能的概念最早是Gartner Group于1996年提出來的。其實，商業智能所涉及的技術與應用，在Gartner Group命名之前就有，起初被稱為領導信息系統（EIS，Executive Information System），在羽化成商業智能之前也稱為決策支持系統（DSS, Decision Support System）。
從技術層面上講，商業智能或數據倉庫并不是什么新技術，它只是數據庫技術、OLAP技術、數據采集和遷移技術、網絡技術、GUI技術、查詢&報表技術、統計學、人工智能、知識發現技術等理論和技術的綜合運用，從這個意義上，把商業智能看成是一種體系結構應該比較恰當。關于體系結構與具體技術的關系，W.H.Inmon形象地比喻成新墨西哥州的一個城市圣達菲和磚塊的關系，圣達菲這個體系結構由磚塊和裸露的橫梁構成，沒有這些磚塊就沒有圣達菲的各種建筑，而磚塊本身并不能構成圣達菲這個體系。
商業智能的核心內容是從許多來自企業不同的業務處理系統的數據中，提取出有用的數據，進行清理以保證數據的正確性，然后經過抽取（Extraction）、轉換（Transformation）和裝載（Load），即ETL過程，整合到一個企業級的中心數據倉庫(DW, Data Warehousing)里，從而得到企業信息的一個全局視圖，在此基礎上利用合適的查詢和分析工具、數據挖掘工具等對數據倉庫里的數據進行分析和處理，形成信息，更進一步把規律性的信息提煉成知識，并且把對決策有幫助的信息和知識呈現給管理者，為管理者的決策提供支持。商業智能的這個基本過程如圖2所示。
圖2 商業智能的基本過程
數據倉庫是商業智能的基礎，商業智能的應用必須基于數據倉庫技術，所以數據倉庫的設計工作占一個商業智能項目的核心位置，所以在很多項目命名時，往往是把數據倉庫和商業智能相提并論，要么把它們等同起來，有時這會給人一種很混淆的感覺，覺得BI,DW,BIDW是相同的概念，造成了很多初學者在認識上的誤區。一般來說，上面所描述的是一個廣義上的商業智能概念，在這個概念層面上，數據倉庫是其中非常重要的組成部分，數據倉庫從概念上更多地側重在對企業各類信息的整合和存儲工作，包括了數據的遷移，數據的組織和存儲，數據的管理與維護這些我們平常稱之為后臺的基礎性的數據準備工作，與之對應，俠義的商業智能概念則側重在數據查詢和報告、多維/聯機數據分析、數據挖掘和數據可視化工具這些平常稱之為前臺的數據分析應用方面，其中數據挖掘是商業智能中比較高層次的一種應用。下圖6－3表達了商業智能過程中對應使用的技術和方法。
圖3 商業智能過程及其對應的技術和方法
商業智能系統的服務對象包括了企業或組織機構的決策人員、數據分析專家、中下級別經理和一般業務人員。而不同層次的用戶對商業智能應用的需求有明顯的差異。
l 高層決策者需要了解業務的總體情況和總的發展態勢，他們可能使用系統提供的分析工具自己發現問題，但更主要的是利用分析結果進行決策，高層決策者需要通曉業務的具體狀態和發展趨勢，包括業務的狀態和構成（機構構成、時間構成、產品構成、客戶構成等等）以及對業務的發展趨勢做出預測；
l 數據分析專家需要更加深入地從數據倉庫的數據中發現問題、市場機會和風險，需要及時把發現的結果報告給高層決策者；
l 中下級經理和業務人員通常僅僅關心與各自工作相關的內容，他們或許對報表和固定的數據查詢更為習慣。
圖4描述了商業智能系統中各種用戶角色對系統數據深度、廣度、分析復雜性、對目標軟件易用性，對軟件的控制能力和客戶化程度要求以及對業務整體和局部信息需求程度的要求。
圖4 商業智能用戶類型分析圖
分析用戶類型是系統功能設定、分布的依據。圖中以色譜形式表示對信息服務深度的需求，從最淺顯的數據查詢到深度數據挖掘。八條坐標線表示用戶對不同系統特性的需求。這些系統性能是：數據深度和廣度、分析的復雜性、軟件的易用性、靈活性和客戶化程度，對業務的全局性和局部性信息的需求（戰略、戰術需求）。
商業智能的用戶類型、角色、需求、分析方法對照如表1
表1商業智能用戶對照表
用戶類型 | 角色 | 需求 | 分析方法 |
中下級經理和業務人員 | 固定報表讀者 | 需要閱讀數據倉庫定時或按條件產生的固定報表； | 固定查詢、產生報表；
|
信息瀏覽者 | 根據不同的業務需求，通過建立簡單的查詢，進行分析，產生動態報表；
| 自助查詢、動態報表 | |
高層決策者 | 管理（或稱領導）信息系統用戶 | 了解宏觀業務狀況,并能迅速定位到反映問題原因的微觀細節； | 了解反映業務狀況的關鍵性能指標(KPI),多維分析，穿透和鉆取； |
數據分析專家 | 數據分析用戶 | 根據不同的業務要求，建立自己的數據模型進行 隨機查詢； 通過多維分析，進行各種高級查詢和報表； | 多維分析、趨勢分析、對比分析、排名分析、意外分析、原因影響分析、假設分析（What if）; |
數據挖掘用戶 | 根據現有的數據情況，動態構建或修改模型，進行預測分析、數據挖掘等深層次操作； | 統計分析（預測、假設檢驗等等）； 數據挖掘(估計、預測、分類、聚類分析等等) |
把商業智能系統工作的過程進行技術上的抽象，可以把商業智能的體系結構進行分層，如圖5所示，根據數據的不同形態，整個體系被劃分為四個大的層面，并根據數據的處理和應用過程再細分成七個環節，這些環節通過密切的協助完成商業智能的功能。
數據從數據源經過抽取(Extra，E)、轉換（Transform，T）、裝載（Load，L）過程加載到中央數據倉庫, 再從數據倉庫經過分類加工放到數據集市(DM, Data Market), 或者將數據集市中的數據進一步存放到多維數據庫(MDD, Multi-dimension Database)，這都屬于數據組織的問題，從中間層到終端用戶或從多維數據庫到終端用戶可將其劃歸為前端應用實現的問題。而貫穿整個體系數據處理環節的，是系統的流程調度控制和元數據管理。
圖5 商業智能解決方案體系結構圖
數據源可以是企業日常運作積累下來的各類的業務數據，也可以是外部的數據。這些數據在存放方式，存放格式，存放地點上可能是多種多樣的，這就要求了數據倉庫的體系結構必須能處理這種多樣性帶來的種種問題，如訪問多種技術平臺下，多種類型的DBMS內的數據，并解決由于數據遠程遷移所帶來的完整性和安全性的問題。
數據抽取、轉換和裝載完成如下任務：從源數據抽取數據、進行一定的變換、裝載到數據倉庫。在上述過程中，需要進行如下數據處理：
簡單變換：是數據變換最簡單的形式，一次只針對一個字段，而不是考慮相關字段的值。主要有數據類型的轉換、日期/時間的格式轉換、字段解碼等。
清潔和刷洗：目的是為了保證前后一致地格式化和使用某一字段或相關的字段群。清潔和刷洗是兩個可以互換的術語，指的是比簡單變換更為復雜的一種變換。在這種變換中，要檢查的是字段和字段組中的實際內容而不僅是存儲格式。一種檢查是檢查數據字段值的有效值，它指的是檢驗一個字段的有效值以保證它落在預期的范圍之內，通常是數字范圍和日期范圍。數據刷洗的另一主要類型是重新格式化某些類型的數據，這種方法適用于可以用許多不同方式存儲在不同數據來源中的信息，必須在數據倉庫中把這類信息轉換成一種統一的表示方式。
集成：要把從全然不同來源的數據結合在一起，真正的困難在于將其集成一個緊密結合的數據模型。這些數據來源往往遵守的不是同一套業務規則，在生成新數據時，必須考慮到這一差異。
聚集和概括：大多數數據倉庫都要用到數據的某種聚集和概括。這通常有助于將某一實例的數目減少到易于駕馭的水平，也有助于預先計算出廣泛的概括數字，以使每個查詢不必計算它們。概括是指按照一個和幾個業務維將相近的數值加在一起，聚集是將不同業務元素加在一起或為一個公共總數，在數據倉庫中它們是以相同的方式進行的。
操作型數據存儲區(ODS, Operational Data Store)是為了彌補業務系統和數據倉庫之間的數據同步差距而提出的，要解決的是這種問題：“對一個特定的業務流程來說，我怎么才能提供最新的、跨功能部門之間的信息”，例如對客戶服務人員，他需要銷售、庫存、市場和研發等各部門的最新數據，而這些數據原來是分散在不同部門的不同應用系統的。如果通過數據倉庫來實現數據集成，則實時性難以保證，或者建設成本很高。
ODS是數據倉庫體系結構中的一個可選部分，ODS具備數據倉庫的部分特征和OLTP系統的部分特征，它是“面向主題的、集成的、當前或接近當前的、不斷變化的”數據，與數據倉庫類似，ODS也是面向主題的、集成的，但是其最大特點是數據是可更新的，甚至由業務系統通過觸發器直接更新。因此，ODS是業務系統和DW之間更偏向業務系統的數據存儲區域。
一般在帶有ODS的系統體系結構中，ODS都設計為如下幾個作用：
1、在業務系統和數據倉庫之間形成一個隔離層。
一般的數據倉庫應用系統都具有非常復雜的數據來源，這些數據存放在不同的地理位置、不同的數據庫、不同的應用之中，從這些業務系統對數據進行抽取并不是一件容易的事。因此，ODS用于存放從業務系統直接抽取出來的數據，這些數據從數據結構、數據之間的邏輯關系上都與業務系統基本保持一致，因此在抽取過程中極大降低了數據轉化的復雜性，而主要關注數據抽取的接口、數據量大小、抽取方式等方面的問題。這種運用有時被稱為數據準備區（Data Staging Area）。
2、轉移一部分業務系統細節查詢的功能
在數據倉庫建立之前，大量的報表、分析是由業務系統的數據庫直接支持的，在一些比較復雜的報表生成過程中，對業務系統的運行產生相當大的壓力。ODS的數據從粒度、組織方式等各個方面都保持了與業務系統的一致，那么原來由業務系統產生的報表、細節數據的查詢自然能夠從ODS中進行，從而降低業務系統的查詢壓力。
3、完成數據倉庫中不能完成的一些功能。
一般來說，帶有ODS的數據倉庫體系結構中，DW層所存儲的數據都是進行匯總過的數據，并不存儲每筆交易產生的細節數據，但是在某些特殊的應用中，可能需要對交易細節數據進行查詢，這時就需要把細節數據查詢的功能轉移到ODS來完成，而且ODS的數據模型按照面向主題的方式進行存儲，可以方便地支持多維分析等查詢功能。
在一個沒有ODS層的數據倉庫應用系統體系結構中，數據倉庫中存儲的數據粒度是根據需要而確定的，但一般來說，最為細節的業務數據也是需要保留的，實際上數據的內容也就相當于ODS，但與ODS所不同的是，這時的細節數據不是“當前、不斷變化的”數據，而是“歷史的，不再變化的”數據。ODS可以和DW形成互補的整體，構成完整的戰術決策支持系統架構。利用ODS＋DW實現戰術決策支持有其非常直觀的優勢：利用ODS實現實時或者準實時的數據抽取，而且ODS的數據量不大，可以比較高效地進行數據的修改和更新，并且可以提高查詢的效率。而利用數據倉庫的海量存儲實現歷史數據的查詢，實現戰略決策支持。
但是，這種也有很明顯的劣勢：由于ODS和DW的結構和模型是不同的，這需要進行不同的系統和數據模型設計，也需要不同的系統維護過程，相應增加系統的使用成本。
數據倉庫的一個目的就是把企業的信息訪問基礎從一種非結構化的或發展中的環境改變成一種結構化或規劃良好的環境。關于數據倉庫的詳細描述留到后面的章節。
簡單地把數據集市(DM，Data Market)理解成數據倉庫的一部分是不對的，因為兩者雖然在數據上有非常密切的聯系，而定位上卻是不同的，關于數據集市的詳細描述留到后面的章節。
商業智能的前端應用是建立數據倉庫的目的，沒有前端應用數據倉庫就失去了意義。另一方面，由于最終用戶的要求多種多樣，不可能用同一個界面滿足所有用戶的信息查詢要求，必須根據用戶的特點提供不同的界面。最終用戶對數據倉庫的數據的訪問方式包括：即席查詢、報表、聯機分析處理(OLAP)、數據挖掘(DM, Data Mining)以及領導信息系統(EIS)等,用戶可以通過瀏覽器或其它前端工具訪問數據倉庫的數據。
即席查詢和報表
即席查詢(Adhoc Query)和報表是商業智能系統提供給業務人員最基本的信息訪問能力，滿足他們日常報表和隨時獲取業務信息的需要。不同的業務人員，如銷售、市場、財務等人員有著自己獨特的分析要求，且這種要求需根據業務的需要不斷變化。在傳統的技術條件下，由于種種理由業務人員實質上是不能直接接觸到存在計算機內的數據，如果業務人員需要對一段時間的業務匯總數據，往往只能提出要求，由IT人員編寫相應的程序把數據庫中的數據讀出來生成報表，再通過批處理打印的方法將結果交給業務人員，這種方法已經日益不能滿足業務人員對動態、及時及個性化信息的要求。同時，這種對IT人員過多的依賴消耗太多的IT資源，增加了管理和運作的成本。因此必須在IT與業務用戶之間正確地劃分權限，既能方便用戶自助查詢，又能保證IT的統一管理的即席查詢和報表功能是商業智能系統必須具備的功能。
用戶界面的友好性是一直以來商業智能的前端工具的一個著力點，用戶可通過簡單的鼠標點擊、拖拉等操作就可以完成復雜的查詢功能，可以在一個文檔中包含來自多個數據源的數據，可以完成各種統計、排序、分組、計算工作，可以通過限制字段的值對結果進行過濾，可以通過高亮度顯示突出特殊的結果集。而用傳統的方式下，構造復雜的SQL查詢語句，各種復雜的統計和處理，結果的輸出這些都需要編寫大量程序代碼來實現，而報表用戶任何輕微的改動會給IT技術人員帶來的繁復的編程工作。
可以說引入這些為最終用戶設計的數據查詢和報表工具，一方面讓最終用戶真正擁有了自由查詢自己需要信息的能力，另一方面，把信息的查詢直接還給最終用戶，IT人員就可以把更多的精力放在為滿足大的方面業務需求的數據后臺整合工作上，對于IT人員和業務人員來說雙重的解放。
圖6 著名的即席查詢和報表工具BrioQuery 的查詢請求界面
即席查詢和報表工具是集成查詢和報表的解決方案，具有易于使用和二次開發的特點。
OLAP分析，又稱多維分析，管理人員往往希望從不同的角度觀察數據來審視業務情況，比如從時間、地域、產品、客戶等來看收入、利潤、支出等業務統計數字。每一個分析的角度可以叫做一個維，因此，我們把多角度分析方式稱為多維分析。以前，每一個分析的角度需要制作一張報表。多維分析工具的主要功能，是根據用戶常用的多種分析角度，事先做好匯總和計算，以便在查詢時能盡快訪問到所要的匯總數字，并快速地從一個維度轉變到另一維度繼續觀察數據。
圖7 信貸分析模型
圖7直觀地表示了一個貸款分析模型所能實現的可能的分析角度(維度)和數據層次（粒度）:
圖8 貸款分析的角度和層次
很明顯，這個簡單的分析模型已經包含了8╳8╳4╳4 = 1024 種不同角度不同層次對授信金額和貸款金額的統計分析，下面讓我們看看一些多維分析的操作。
在多維數據結構中，按二維進行切片，按三維進行切塊，可得到所需要的數據。如在“貸款銀行、貸款質量、時間”三維立方體中進行切塊和切片，可得到各貸款銀行、各種貸款的統計情況。每次都是沿其中一維進行分割稱為分片，每次沿多維進行的分片稱為分塊。
圖9 切片一 2004年4月份所有貸款情況
圖10 切片二所有不良貸款情況
鉆取包含向下鉆取(Drill-down)和向上鉆取(Drill-up)/上卷(Roll-up)操作， 鉆取的深度與維所劃分的層次相對應。
圖11 鉆取示意圖
通過旋轉可以得到不同視角的數據
圖12 旋轉示意圖
從上面的多維操作，我們可以看到通過對數據觀察角度的變換，可以更容易全面而深入地了解到一些關于為什么的信息。
領導信息系統(EIS，Executive Information System)
EIS（領導信息系統），是針對管理人員的需要，整合上述各種功能控制的前端應用。通過EIS，將管理人員所需的決策信息按需集成到統一的界面中，幫助他們能夠快速、直接地訪問信息。與其他信息查詢方式相比，EIS更強調與用戶的交互能力，除了以多種形式展示數據內容外，EIS還可以以下拉列表、按鈕、選項、圖標等多種屏幕控件響應用戶的操作，并能通過對界面的美工增強對用戶的親和力。
圖13 信貸分析的EIS示例
從上面一節的描述中我們已經知道，數據倉庫的設計是商業智能應用中十分重要的一環，數據倉庫是商業智能應用最基本的環境，OLAP分析，報表和查詢，數據挖掘等商業智能應用都需要數據倉庫作為共同的基礎。
數據倉庫來源于數據庫，其本身也是由數據庫管理系統來管理的，但是它的結構、功能和設計都和傳統的數據庫設計方法不同，本節將會對數據倉庫技術的知識和設計方法進行深入學習，探究創建數據倉庫的理論和方法。
傳統的企業信息化實現的是用計算機信息處理代替人工信息處理，主要解決的是業務上的數據流問題。讓我們來看一個簡單的例子。在銀行中, 一般都有存款、貸款、信用卡、代理業務等多種業務系統, 它們都是支持相關業務處理而設計的交易處理系統, 系統主要任務是完成日常業務交易過程中的數據處理，這種操作型系統的使用人員通常是企業的具體操作人員，處理的數據通常也是企業業務中的細節信息，譬如具體的一筆業務。
針對操作型數據處理的聯機業務處理(OLTP)系統,我們總是按照業務應用來建立它的數據模型,換言之, 業務處理系統是面向操作應用來設計的，聯機業務處理系統更是面向交易來設計，存儲操作型數據的數據庫在設計的時候主要是圍繞性能和完整性方面，而每個交易涉及的數據往往只是記錄的層面，數據庫設計主要考慮對并行更新的支持比較多，并不需要考慮為全局查詢做優化。另外，企業針對不同業務往往可能有多個操作型的系統，這些系統開發的時候都是獨立進行的，相互之間沒有什么數據聯系,各系統之間對實際業務中相同的信息在數據上是冗余，而在不同的系統表達方式和數據內容上很可能不一致，甚至項目矛盾。比如每個系統中都會有存放客戶部分信息的數據, 信息分布的零碎和冗余，使決策者很難從這些業務系統中直接地獲取全面的信息。
分析型系統的使用人員通常是企業的中高層的管理者，或者是從事數據分析的分析師，他們關注的更多是企業宏觀的信息而非具體的細節，其使用數據的目的是為企業的決策者做決策提供支持。分析型系統直接在操作型系統中提取數據會遇到下面很多問題。
其一是操作型數據之間往往需要復雜的關系來保持快捷性、一致性和實時性，要將其直接用于分析，需要創建很復雜的特殊查詢語句，這項工作的技術復雜度明顯不符合數據分析的用戶群的需要；
其二是在事務處理系統中進行數據分析，由于短時間需要查詢大量的數據，一方面會明顯影響事務處理系統的處理速度和性能，另一方面也會由于響應時間過慢而影響分析的效率；
其三是在進行預測、決策時需要大量全面、正確的集成數據，所有這些集成數據不僅包括企業內部的數據，還包括企業外部的數據，如行業信息、競爭對手信息等。而操作型數據僅僅保存與本業務相關的信息，缺少與決策相關的集成數據尤其是企業外部數據。
其四是歷史數據問題。供決策分析的數據一般是歷史數據，而操作型數據庫一般只保留當前或近期的數據信息。
以上諸多問題的存在，導致企業或其他組織機構無法直接使用現有的業務系統中存儲操作型數據的傳統數據庫系統以滿足預測、決策分析的需要。因此，預測、決策分析需要一個能夠不受傳統事務處理的約束，高效率處理決策分析數據的支持環境，數據倉庫就是滿足分析型系統要求的數據存儲和數據組織環境。
功能決定結構，承接上一節的討論，我們知道OLAP系統和OLTP系統從本質上是不同的，數據倉庫雖然是從傳統數據庫系統發展而來，但是兩者還是存在著諸多差異，如：從數據存儲的內容看，數據庫只存放當前值，而數據倉庫則存放歷史值；數據倉庫數據的目標是面向業務操作人員的，為業務處理人員提供數據處理的支持，而數據倉庫則是面向中高層管理人員的，為其提供決策支持。表6-2詳細說明了數據倉庫與傳統數據庫的區別。
表2 數據倉庫與傳統數據庫的比較
比較項目 | 數據庫 | 數據倉庫 |
數據內容 | 當前值 | 歷史的、歸檔的、歸納的、計算的數據（處理過的） |
數據目標 | 面向業務操作程序、重復操作 | 面向主體域，分析應用 |
數據特性 | 動態變化、更新 | 靜態、不能直接更新，只能定時添加、更新 |
數據結構 | 高度結構化、復雜，適合操作計算 | 簡單、適合分析 |
使用頻率 | 高 | 低 |
數據訪問量 | 每個事務一般只訪問少量記錄 | 每個事務一般訪問大量記錄 |
對響應時間的要求 | 計時單位小，如秒 | 計時單位相對較大，除了秒，還有分鐘、小時 |
數據倉庫的特點可以從數據倉庫的定義來理解，目前，數據倉庫一詞尚沒有一個統一的定義，著名的數據倉庫專家W.H.Inmon在其著作《Building the Data Warehouse》一書中給予如下描述：“數據倉庫（Data Warehouse）是一個面向主題的（Subject Oriented）、集成的（Integrated）、非易失的（Non-Volatile）、且隨時間變化的（Time Variant）的數據集合，用于支持管理決策。”他指出了數據倉庫4個最重要的特征。
1） 面向主題的（Subject Oriented）：操作型數據庫的數據組織面向事務處理任務（面向應用），各個業務系統之間各自分離，而數據倉庫中的數據是按照一定的主題域進行組織。主題是一個抽象的概念，是指用戶使用數據倉庫進行決策時所關心的重點方面，一個主題通常與多個操作型系統的數據相關。例如，一個銀行的事務處理（應用問題）包括存款業務、信用卡業務、貸款業務和代理業務等，而銀行的主要主題范圍是客戶、產品和渠道等。
圖14 數據倉庫面向主題的特性
2） 集成的（Integrated）：在數據倉庫的所有特性中，這是最重要的。面向事務處理的操作型數據庫通常與某些特定的應用相關，數據庫之間相互獨立，并且往往是異構的。而數據倉庫中的數據是在對原有分散的數據庫數據抽取、清理的基礎上經過系統加工、匯總和整理得到的，必須消除源數據中的不一致性，以保證數據倉庫內的信息是關于整個企業的一致的全局信息。下例說明當數據由面向事務處理的操作型數據向數據倉庫傳送時所進行的集成。有四個不同的應用系統，系統中對人的性別的標識分別為：
表3 示例
| 男性 | 女性 |
系統A | 男 | 女 |
系統B | M | f |
系統C | 1 | 0 |
系統D | M | F |
那么，在將四個系統的性別信息向數據倉庫導入時就涉及到集成問題，例如，可以統一將性別信息表示為m，f。
3） 非易失的（Non-Volatile）：操作型數據庫中的數據通常實時更新，數據根據需要及時發生變化。數據倉庫的數據主要供企業決策分析之用，所涉及的數據操作主要是數據查詢，一旦某個數據進入數據倉庫以后，一般情況下將被長期保留，也就是數據倉庫中一般有大量的查詢操作，但修改和刪除操作很少，通常只需要定期的加載、刷新。
圖15 數據倉庫的相對穩定性、非易失性
圖15說明了操作型數據環境下，是正規地一次訪問和處理一個記錄，可以對數據進行修改和更新。但數據倉庫中的數據卻表現出不同的特性：數據通常是被一起載入和訪問的，而且在數據倉庫環境中并不進行一般意義上的數據更新操作。
4） 時變的（Time-Variant）：反映歷史變化或者說是隨著歷史變化。操作型數據庫主要關心當前某一個時間段內的數據，而數據倉庫中的數據通常包含歷史信息，系統記錄了企業從過去某一時點(如開始應用數據倉庫的時點)到目前的各個階段的信息，通過這些信息，可以對企業的發展歷程和未來趨勢做出定量分析和預測。
數據倉庫的反映歷史變化的屬性主要表現在：
1） 數據倉庫中的數據時間期限要遠遠長于傳統操作型數據系統中的數據時間期限，傳統操作型數據系統中的數據時間期限可能未為數十天或數個月，數據倉庫中的數據時間期限往往為數年甚至幾十年；
2） 傳統操作型數據系統中的數據含有“當前值”的數據，這些數據在訪問時是有效的，當然數據的當前值也能被更新，但數據倉庫中的數據僅僅是一系列某一時刻（可能是傳統操作型數據系統）生成的復雜的快照；
3） 傳統操作型數據系統中可能包含也可能不包含時間元素，如年、月、日、時、分、秒等，而數據倉庫中一定會包含時間元素。
目前數據庫技術中主流的關系數據庫是采用二維表的形式來表示數據，在設計上使用關系模型理論來建模，建模方法是第三范式(3NF, 即 Third Normal Form)，3NF是關系數據庫設計的基礎理論，按3NF設計的數據庫存放業務處理的數據是合適的，同時也體現了操作型數據的信息局部性，如果直接在上面做分析操作，必然需要由很多個表做連接操作才能得到需要的相對完整的信息。
而數據倉庫的結構是要面向多維分析的，并且是按面向主題的方式來組織，星型模式體現的是多維的數據關系,它由一個事實表(Fact Table)和一組維表(Dimension Table)組成。每個維表都有一個維作為主鍵，所有這些維的主鍵組合成事實表的主鍵。事實表的非主鍵屬性稱為度量值（Measure）或者事實 (Fact),它們一般都是數值或其他可以進行計算的數據; 而維大都是文字、時間等類型的數據，按這種方式組織好數據我們就可以按照不同的維(事實表的主鍵的部分或全部)來對這些度量值數據進行求和(summary)、求平均(average)、計數(count)、百分比(percent)的聚集計算，這樣就可以從不同的角度觀察反映所分析的業務狀況的數據，下面給出一個針對銀行貸款業務狀況的分析模型的例子。
圖16 例子:貸款分析星型模型
圖16是銀行貸款分析的模型設計，其中加邊框的為主關鍵字(PK, Primary Key)，其中貸款分析表是一個事實表，其中的貸款授信金額，貸款金額（發生額）是需要從各角度觀察的數據(度量值)，而對這兩個數據的觀察的角度可以有區域、銀行、時間，質量這四個方面組合進行，通過這些分析角度的組合，可以對授信金額和貸款余額進行4 ╳ 8 ╳ 4 ╳ 8種不同角度的數據統計，以此可以對貸款情況的從多個角度(維)不次(數據不同的匯總程度)進行分析和觀察，貸款分析人員既可以宏觀地看到貸款業務的整體情況，又可以微觀地觀察到具體某一家銀行某一天某一類貸款情況。進行多維分析的時候，維度選擇越多數據越細節(劃分得更細了)，維度選擇越少數據越匯總越宏觀。
這個模型中，一個中間一個細長的大表（事實表，記錄數很多，字段數目卻不多）形成主表，周圍一組小表（維表，記錄數很少）與主表相關聯的結構，形態上如圖17所示呈星星的形狀，所以被命名為星型結構，星型模型是數據倉庫的數據模型與傳統關系數據庫應用相區分的一個重要特征。
圖17 數據倉庫典型的邏輯模型形狀
星型模型雖然也是一個關系模型，但是它不是一個規范化的模型，在星型模型中，維度表被故意非規范化了，使用星型模式主要有兩方面原因：
提高查詢效率：同一個主題的主要的數據都存放在龐大的事實表中，只要掃描事實表就可以進行查詢，而不必把多個表聯接起來；
便于用戶理解：星型模式比較直觀，通過星型模式，很容易組合出各種查詢。
雪花模型是對星型模型的一個擴展，每一個維表還可以向外面連接多個詳細類別表。例如上面的貸款銀行維表可以再擴展一個銀行級別類表，而形成一個雪花型的結構。而由于數據倉庫不必要考慮滿足第三范式，也不必要考慮避免冗余，可以考慮把詳細類別表的字段合并入維表里面，由此可見，在星型模式的基礎上拓展而成的雪花型模型，實際上是對分析查詢性能和數據倉庫容量兩方面的平衡。
圖18 雪花模型示意圖
一個復雜的商業智能應用往往會在數據倉庫中存放多個事實表，這時就出現多個事實表共享一個或者多個維表的情況，這就形成了星座模式，例如我們可以復用以上貸款分型模型的維表到存款分析模型中，如圖19, 公共維表設計在數據倉庫項目中有普遍意義。
圖19 例子:存、貸款分析星座模型
2.5數據集市
簡單地把數據集市(DM，Data Market)理解成數據倉庫的一部分是不對的，因為兩者雖然在數據上有非常密切的聯系，而定位上卻是不同的。數據倉庫所對應的是整個企業的層面的整體信息視圖，體現決策信息在企業的共性需求。而對于企業內同一個業務概念，由于業務觀點的不同導致大家對數據的理解和運用有不同的視角，缺乏針對性的單一個模型并不能都滿足這種不同觀點的數據需求。例如客戶是現在企業非常重要的一個信息主題，而從產品經理的角度，可能關心的是客戶的消費喜好和消費行為，而從財務經理的角度，更多地可能是關心客戶的成本和帶來的收益，這些不同的數據的使用觀點需要不同的數據模型來滿足，一般而言，數據倉庫可以理解為企業決策信息平臺提供總數據支持的，數據集市可以理解為部門范圍級別的決策支持應用而設計的，其數據模型設計和數據組織上更多地服務于一個部門的信息需求。
結合數據集市的數據來源，數據集市有兩種，獨立的數據集市（Independent Data Mart）和從屬的數據集市（DependentData Mart）。如圖20所示：
圖20 數據集市類型
從屬數據集市的數據直接來自于中央數據倉庫，這樣有利于保持數據的一致性，因為來自同一數據源并且已經經過一致性處理和檢驗。從屬數據集市的作用在于，為一些部門建立數據集市，將需要的數據復制、加工到其中，這樣不僅可以提高該部門的訪問速度，同時也為能滿足該部門的一些特殊的分析需求。
獨立數據集市的數據直接來自于業務系統，由于為各個部門都建立了各自的數據集市，而當需要從整體上建立一個數據倉庫時，不同數據集市中的數據表達由于各部門的不同特殊需要而有所不同，將這種不一致的數據整合到一個中心數據倉庫時，可能會遇到一些困難，比如重新設計、各部門協調等。其優點是建立迅速、價格相對低廉。因此建立獨立數據集市往往是由于投資方面的考慮或工期的緊迫，或解決某部門的迫切需要。然而需要注意的是，在設計其它部門的數據集市或中心數據倉庫時，要充分考慮現有數據集市的設計，以避免設計的不一致性而造成后期整合的困難及昂貴的費用。
表4 從屬數據集市與獨立數據集市對比表
對比 | 優點 | 缺點 |
從屬數據集市 | 保證數據一致性； 架構比較理想，可擴展能力強 | 依賴與中心數據倉庫的實施； 實施周期長； 實施成本高； |
獨立數據集市 | 實施周期短； 實施成本低； | 沒有消除信息分割； 可擴展能力弱； 后期整合困難。 |
粒度
粒度是數據倉庫的重要概念。粒度可以分為兩種形式，第一種粒度是對數據倉庫中的數據的匯總程度高低的一個度量，它既影響數據倉庫中的數據量的多少，也影響數據倉庫所能回答詢問信息的種類。在數據倉庫中，多維粒度是必不可少的。由于數據倉庫的主要作用是多維分析，因而絕大多數查詢都基于一定程度的匯總數據之上的，只有極少數查詢涉及到細節。
還有一種粒度形式，即樣本數據庫。它根據給定的采樣率從細節數據庫中抽取出一個子集。這樣樣本數據庫中的粒度就不是根據匯總程度的不同來劃分的，而是有采樣率的高低來劃分，采樣粒度不同的樣本數據庫可以具有相同的數據匯總程度。
聚合
事實表中存放的度量值，根據其實際意義可以分成是可加性的度量值和非可加性的度量值。可加性的度量值指將同一個事實表里面的不同記錄的該數值相加得到的結果還有具體意義，譬如上面例子中的貸款金額，將一個季度的3個月的數字相加可以得到季度的數據，1年12個月的數字相加可以得到年度的數據。
由于事實表一般記錄數都非常多，而且會隨著時間數據越積累越多，用戶直接在上面做匯總計算來觀察一些度量值的時候，可能需要等很長時間才能得到匯總計算的結果。所以在確定了數據的粒度后，為了提高數據倉庫的使用性能，可以根據用戶的要求，可以按照維度的不同組合來設計聚合模型，從而在事實表的基礎上再設置一些聚合表，存儲一些在事實表的基礎上預先匯總好的聚合數據，讓用戶獲得更好的查詢性能。
分割
分割是數據倉庫中的數據存儲中的另外一個重要概念,它的目的在于提高效率。它是將數據分散到各自的物理單元中去, 以便能分別獨立處理，以實現查詢操作的并行。有許多數據分割的標準可供參考:如時間、地域、業務領域等等,也可以是其組合。一般而言,分割標準總應包括一些能讓它十分自然而且分割均勻的項目，例如時間項。
往往一個數據倉庫需要包容和整合成千上萬的信息內容，內容的多樣性使數據倉庫的數據結構顯得異常的龐大很復雜，因此，要簡單地用一種不需要言傳的方式來描述一個數據倉庫的內容和結構是不可能的事情，因而在從開發到運行維護的整個數據倉庫生命周期中，如何描述數據倉庫里面有的東西成了一件非常重要的事情。
元數據(Meta-data)通常定義為“關于數據的數據”，是描述和管理數據倉庫自身內容對象、用來表示數據項的意義及其在系統各組成部件之間的關系的數據。實際上，數據倉庫所提供的“統一的企業級的信息視圖”能力，主要就是靠元數據來體現，如果把建設數據倉庫比喻成搭建房子，元數據就是房子的“圖紙”。是從廣義上來講，用元數據來描述數據倉庫對象的任何東西——無論是一個表、一個列、一個查詢、一個商業規則，或者是數據倉庫內部的數據轉移。它在數據源的抽取、數據加工、訪問與使用等過程中都會存在。實現元數據管理的主要目標就是使企業內部元數據的定義標準化。數據倉庫的維護工具可以根據元數據的“指示”完成數據的抽取、清洗和轉換，并做適度的匯總，數據倉庫的元數據包括：
（1）數據資源：包括各個數據源的模型，描述源數據表字段屬性及業務含義，源數據到數據倉庫的映射關系；
（2）數據組織：數據倉庫、數據集市表的結構、屬性及業務含義，多維結構等等；
（3）數據應用：查詢與報表輸出格式描述、OLAP、數據挖掘等的數據模型的信息展現、商業術語；
（4）數據管理：這里包括數據倉庫過程以及數據倉庫操作結果的模型，包括描述數據抽取和清洗規則、數據加載控制、臨時表結構、用途和使用情況、數據匯總控制。
元數據貫穿整個數據倉庫項目，所有數據處理環節必須最大化的參照元數據，這樣才能保證數據倉庫項目不會因為不斷增長的數據多樣性而失去秩序，特別是現行應用的異構性與分布性越來越普遍的情況下，統一的元數據就愈發重要了。“信息孤島”曾經是很多企業對其應用現狀的一種抱怨和概括，而合理的元數據則會有效的描繪出信息的關聯性，從而大大降低了數據倉庫后期的維護和運行成本。
按照元數據的使用情況和面向對象的不同，可以將元數據分為業務元數據、技術元數據、操作元數據。
業務元數據用業務名稱、定義、描述和別名來表示數據倉庫和業務系統中的各種屬性，直接供最終用戶使用。業務元數據使最終用戶能夠更好理解、使用數據倉庫，成為最終用戶在數據倉庫中的業務信息地圖。
業務元數據在系統的數據倉庫中的體現是全方位的，例如，最終用戶通過瀏覽元數據可以清晰地了解當前指標代表什么業務、如何計算得出的、以什么為單位等相關描述信息。
技術元數據描述了源系統、數據轉換、抽取過程、工作流、加載策略以及目標數據庫的定義等。技術元數據可供信息系統人員和一部分最終用戶使用，用來進行影響分析、變化管理、數據庫優化、任務調度和安全管理等。
OLTP業務系統和數據倉庫OLAP分析系統之間存在復雜、多方面的區別，因此，數據在業務系統和分析系統之間的處理、加載也是復雜和涉及多方面的。技術元數據對數據在兩個系統間處理、加載的規則、過程、相關策略進行了描述。
操作元數據描述了目標表中的信息，如粒度、創建目標表和索引的信息、刷新時間、記錄數、按時執行任務的設置以及有權訪問數據的用戶。操作元數據用于數據倉庫的維護和分布。
雖然元數據依據具體應用特點分為業務元數據、技術元數據和操作元數據，但是，在實際應用中以上三類元數據是相互參照和關聯的。只有業務、技術、操作之間的協調和互補才能充分發揮數據倉庫的潛能，提高數據倉庫的利用效率。
4、元數據標準CWM
OMG于2001年頒布元數據標準CWM 1.0（CommonWarehouse Metamodel Version 1.0）。CWM定義一個描述數據源、數據目的、轉換、分析的元數據框架，以及定義建立和管理數據倉庫的過程和操作，提供使用信息的繼承。
目前宣布支持CWM的廠商包括：IBM、Oracle、Hyperion、DimensionEDI、Genesis IONA、HP、NCR和Unisys等。
CWM基于3個工業標準：
（1）UML - Unified Modeling Language，OMG建模標準；
（2）MOF - Meta Object Facility，OMG建立元模型和模型庫的標準，提供在異構環境下的數據交換的接口；
（3）XMI - XML Metadata Interchange，OMG元數據交換標準。
數據倉庫是以商業智能應用為目的而設計的，所以從廣義的數據倉庫設計應該包括數據倉庫中的數據模型設計和在其上面的數據分析應用設計2個方面，數據倉庫的應用和數據倉庫的設計一脈相承，共同構成整個數據倉庫系統的生命周期，這個周期包括3個階段：數據倉庫規劃階段，數據倉庫設計實施階段，數據倉庫使用維護階段。
正如1.2節描述的商業智能是一個過程，這3個階段也構成了一個不斷循環、完善和提高的過程，一般情況下數據倉庫不可能在一個循環過程中完成，而是需要多次循環開發，每次循環會為系統增加新的功能，使數據倉庫的應用得到新的提高。
圖21 數據倉庫的生命周期
微觀上的數據倉庫設計實際上是指數據倉庫的數據模型設計，這個層面的主要任務是數據建模，確定數據倉庫中數據的內容及其構成關系。和數據庫的設計一樣，數據倉庫的設計也是在概念模型、邏輯模型和物理模型的依次轉換過程中實現，而作為建設數據倉庫的“圖紙”，元數據模型則自始至終伴隨著數據倉庫的開發、實施和使用。
圖22 數據倉庫數據模型設計的步驟
總體來說，創建數據倉庫的方式，一般而言，有三種方式：
1. 自上而下。把數據倉庫定義為一個大系統，“全局考慮，全面實施”，建立適合企業信息共性需求的完整的數據模型，然后從業務運營系統中提取數據，進行數據的清洗、合并、規范化和合理化，并加載到數據倉庫中，形成企業統一的數據集成平臺，最后可以根據部門個性需要將數據倉庫的數據分發到面向主題的數據集市中。
自上而下開發方法的優點包括
◆ 企業統一的數據集成平臺；
◆ 集中化的控制管理；
◆ 數據容易分發到各個數據集市中；
自上而下開發方法的缺點包括
◆ 開發過程復雜，費用高；
◆ 開發時間長，難以滿足快速變化的業務需求；
◆ 需要進行大量的業務需求分析，需要大量的資源；
◆ 結構比較僵化，比較難以擴展；
2. 自下而上。大量的舊系統，要想在短時間內進行數據的合理性和完整性統一是相當困難的，而市場變化和企業決策規則變化不允許花大量的時間和精力去建立一個滿足日后需求，但不滿足現在變化的系統。自下而上的開發方法就是根據特定的業務主題，“分部門考慮，分部門實施”，可以在很短的時間內實現部門級的數據集市，多個數據集市組成企業聯邦制的數據倉庫。
自下而上開發方法的優點包括：
◆ 可以并行開發；
◆ 見效快；
◆ 分散化的資源和管理控制；
自下而上開發方法的缺點包括：
◆ 很難協調各個數據集市的建設；
◆ 可能存在著部門之間的政治斗爭和數據集市歸屬問題；
◆ 如果采用不同的技術建立起來的數據集市，最終造成多個相互獨立、互不兼容的“煙囪式”數據集市，給維護和數據共享帶來很大的障礙；
◆ 多種數據源采集系統，可能造成對業務系統的沖擊和數據的不一致；
3. 元數據驅動的實施方法。元數據驅動、螺旋上升的數據倉庫建立的過程就是“建立元數據――構造數據倉庫/集市”的不斷循環、不斷上升的過程，如圖23所示。
圖23 不斷循環、螺旋上升的元數據驅動方法
元數據驅動的數據倉庫開發過程可以細分為以下階段：
1) 建立元數據
a. 根據業務數據源，外部數據源定義元數據；
b. 添加和更新維護元數據的內容和屬性；
c. 定義元數據使用規則；
d. 聲明元數據聯合使用的規則；
2) 構造數據倉庫/集市
e. 基于元數據進行數據抽取/清洗/轉換/聚合/加載/分布；
f. 基于元數據進行前端應用界面定制。
從另外一個層面來說，第1)步中構造和維護元數據信息可以看作虛擬地構造商業智能平臺的過程，能否在第2)步實現這種虛擬的構造過程和實際的構造過程的有機結合，是落實元數據驅動的關鍵。
圖24 以元數據為中心的開發方法
這種開發方式優點是顯而易見的，包括：
u 建立企業數據的統一視圖；
u 有統一的元數據管理；
u 具有靈活可擴展的體系結構；
u 分步式開發，螺旋式上升，既能快速看到效果，又保證系統的連續性、一致性。
這種開發方式的主要缺點就是如何真正實現這種方式，提取和維護元數據并不是一件很難的事情，而在實際的實施過程中，如何真正地實現元數據的驅動則不是一件容易的事情，由于傳統程序開發思想的影響，很多開發者對需求問題的解決更多地依賴于程序設計，這樣使得很多控制邏輯很難被抽象出來，因此也難于把數據的處理過程標準化、規范化，這種以程序驅動的方式很容易把所謂的元數據驅動流于形式。
[1] 李艷. 商業智能是一種解決方案.中國計算機用戶. 2003.11.03
[2] 九城信息智能平臺白皮書. 九城集團BI事業部. 2002.11
[3] Gartner ArticleMRR-0798-17, 1 July 1998, Kevin Strange, “Data Warehouse Data Model: Neutralityis the Key”
[4] Eric Sperley著.企業數據倉庫規劃、建立與實現. 陳武, 袁國忠譯.人民郵電出版社，2000年8月第1版
[5] OLAP技術應用研究，https://www.dwway.com/document.php?id=682
[6] 朱德利.SQL Server 2005數據挖掘與商業智能完全解決方案，電子工業出版社.2007.10
[7] IBM商業智能解決方案綜述.IBM公司.2004
[8] （法/美）伯納德·利奧陶德，（美）馬克·哈蒙德著.商務智能:把知識轉化為價值. 鄭曉舟，胡睿譯. 2002
[9] (美)W.H.Inmon著.建設數據倉庫.王志海,林友芳譯.機械工業出版社.2003年3月
[10] 本人.用需求來創造價值-----論數據倉庫與商業智能需求與需求分析，2006中國軟件工程大會暨系統分析員年會演講稿，2006
浙公網安備 33010802003509號
杭州講師網絡科技有限公司
