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