743
OLAP聯機分析處理介紹
作用
聯機分析處理是共享多維信息的、針對特定問題的聯機數據訪問和分析的快速軟件技術。它通過對信息的多種可能的觀察形式進行快速、穩定一致和交互性的存取，允許管理決策人員對數據進行深入觀察。決策數據是多維數據，多維數據就是決策的主要內容。OLAP專門設計用於支持複雜的分析操作，側重對決策人員和高層管理人員的決策支持，可以根據分析人員的要求快速、靈活地進行大數據量的複雜查詢處理，並且以一種直觀而易懂的形式將查詢結果提供給決策人員，以便他們準確掌握企業（公司）的經營狀況，了解對象的需求，製定正確的方案。聯機分析處理具有靈活的分析功能、直觀的數據操作和分析結果可視化表示等突出優點，從而使用戶對基於大量複雜數據的分析變得輕鬆而高效，以利於迅速做出正確判斷。它可用於證實人們提出的複雜的假設，其結果是以圖形或者表格的形式來表示的對信息的總結。它並不將異常信息標記出來，是一種知識證實的方法。
起源
聯機分析處理 (OLAP) 的概念最早是由關係數據庫之父E.F.Codd於1993年提出的，他同時提出了關於OLAP的12條準則。OLAP的提出引起了很大的反響，OLAP作為一類產品同聯機事務處理 (OLTP) 明顯區分開來。
Codd提出OLAP的12條準則來描述OLAP係統：
準則1 OLAP模型必須提供多維概念視圖
準則2 透明性準則
準則3 存取能力準則
準則4 穩定的報表能力
準則5 客戶/服務器體係結構
準則6 維的等同性準則
準則7 動態的稀疏矩陣處理準則
準則8 多用戶支持能力準則
準則9 非受限的跨維操作
準則10 直觀的數據操縱
準則11 靈活的報表生成
準則12 不受限的維與聚集層次
分類
當今的數據處理大致可以分成兩大類：聯機事務處理OLTP（on-line transaction processing）、聯機分析處理OLAP（On-Line Analytical Processing）。OLTP是傳統的關係型數據庫的主要應用，主要是基本的、日常的事務處理，例如銀行交易。OLAP是數據倉庫係統的主要應用，支持複雜的分析操作，側重決策支持，並且提供直觀易懂的查詢結果。下表列出了OLTP與OLAP之間的比較。
| OLTP | OLAP | |
| 用戶 | 操作人員，低層管理人員 | 決策人員，高級管理人員 |
| 功能 | 日常操作處理 | 分析決策 |
| DB 設計 | 麵向應用 | 麵向主題 |
| 數據 | 當前的， 最新的細節的， 二維的分立的 | 曆史的， 聚集的， 多維的集成的， 統一的 |
| 存取 | 讀/寫數十條記錄 | 讀上百萬條記錄 |
| 工作單位 | 簡單的事務 | 複雜的查詢 |
| DB 大小 | 100MB-GB | 100GB-TB |
發展背景
隨著數據庫技術的廣泛應用，企業信息係統產生了大量的數據，如何從這些海量數據中提取對企業決策分析有用的信息成為企業決策管理人員所麵臨的重要難題。傳統的企業數據庫係統（管理信息係統）即聯機事務處理係統（On-LineTransactionProcessing,簡稱OLTP）作為數據管理手段，主要用於事務處理，但它對分析處理的支持一直不能令人滿意。因此，人們逐漸嚐試對OLTP數據庫中的數據進行再加工，形成一個綜合的、麵向分析的、更好的支持決策製定的決策支持係統（DecisionSupportSystem，簡稱DSS）。企業的信息係統的數據一般由DBMS管理，但決策數據庫和運行操作數據庫在數據來源、數據內容、數據模式、服務對象、訪問方式、事務管理乃至物理存儲等方麵都有不同的特點和要求，因此直接在運行操作的數據庫上建立DSS是不合適的。數據倉庫（DataWarehouse）技術就是在這樣的背景下發展起來的。數據倉庫的概念提出於20世紀80年代中期，20世紀90年代，數據倉庫已從早期的探索階段走向實用階段。業界公認的數據倉庫概念創始人W.H.Inmon在《BuildingtheDataWarehouse》一書中對數據倉庫的定義是：“數據倉庫是支持管理決策過程的、麵向主題的、集成的、隨時間變化的持久的數據集合”。構建數據倉庫的過程就是根據預先設計好的邏輯模式從分布在企業內部各處的OLTP數據庫中提取數據並對經過必要的變換最終形成全企業統一模式數據的過程。當前數據倉庫的核心仍是RDBMS管理下的一個數據庫係統。數據倉庫中數據量巨大，為了提高性能，RDBMS一般也采取一些提高效率的措施：采用並行處理結構、新的數據組織、查詢策略、索引技術等等。
包括聯機分析處理（On-LineAnalyticalProcessing，簡稱OLAP）在內的諸多應用牽引驅動了數據倉庫技術的出現和發展；而數據倉庫技術反過來又促進了OLAP技術的發展。聯機分析處理的概念最早由關係數據庫之父E.F.Codd於1993年提出的。Codd認為聯機事務處理（OLTP）已不能滿足終端用戶對數據庫查詢分析的要求，SQL對大數據庫的簡單查詢也不能滿足用戶分析的需求。用戶的決策分析需要對關係數據庫進行大量計算才能得到結果，而查詢的結果並不能滿足決策者提出的需求。因此，Codd提出了多維數據庫和多維分析的概念，即OLAP。OLAP委員會對聯機分析處理的定義為：從原始數據中轉化出來的、能夠真正為用戶所理解的、並真實反映企業多維特性的數據稱為信息數據，使分析人員、管理人員或執行人員能夠從多種角度對信息數據進行快速、一致、交互地存取，從而獲得對數據的更深入了解的一類軟件技術。OLAP的目標是滿足決策支持或多維環境特定的查詢和報表需求，它的技術核心是“維”這個概念，因此OLAP也可以說是多維數據分析工具的集合。
特點
在過去的二十年中，大量的企業利用關係型數據庫來存儲和管理業務數據，並建立相應的應用係統來支持日常業務運作。這種應用以支持業務處理為主要目的，被稱為聯機事務處理(OLTP，On-line Transaction Processing)應用，它所存儲的數據被稱為操作數據或者業務數據。
隨著市場競爭的日趨激烈，企業更加強調決策的及時性和準確性，這使得以支持決策管理分析為主要目的的應用迅速崛起，這類應用被稱為聯機分析處理，它所存儲的數據被稱為信息數據。
聯機分析處理的用戶是企業中的專業分析人員及管理決策人員，他們在分析業務經營的數據時，從不同的角度來審視業務的衡量指標是一種很自然的思考模式。例如分析銷售數據，可能會綜合時間周期、產品類別、分銷渠道、地理分布、客戶群類等多種因素來考量。這些分析角度雖然可以通過報表來反映，但每一個分析的角度可以生成一張報表，各個分析角度的不同組合又可以生成不同的報表，使得IT人員的工作量相當大，而且往往難以跟上管理決策人員思考的步伐。
聯機分析處理的主要特點，是直接仿照用戶的多角度思考模式，預先為用戶組建多維的數據模型，在這裏，維指的是用戶的分析角度。例如對銷售數據的分析，時間周期是一個維度，產品類別、分銷渠道、地理分布、客戶群類也分別是一個維度。一旦多維數據模型建立完成，用戶可以快速地從各個分析角度獲取數據，也能動態的在各個角度之間切換或者進行多角度綜合分析，具有極大的分析靈活性。這也是聯機分析處理被廣泛關注的根本原因，它從設計理念和真正實現上都與舊有的管理信息係統有著本質的區別。
事實上，隨著數據倉庫理論的發展，數據倉庫係統已逐步成為新型的決策管理信息係統的解決方案。數據倉庫係統的核心是聯機分析處理，但數據倉庫包括更為廣泛的內容。
-概括來說，數據倉庫係統是指具有綜合企業數據的能力，能夠對大量企業數據進行快速和準確分析，輔助做出更好的商業決策的係統。它本身包括三部分內容：
1、數據層：實現對企業操作數據的抽取、轉換、清洗和匯總，形成信息數據，並存儲在企業級的中心信息數據庫中。
2、應用層：通過聯機分析處理，甚至是數據挖掘等應用處理，實現對信息數據的分析。
3、表現層：通過前台分析工具，將查詢報表、統計分析、多維聯機分析和數據發掘的結論展現在用戶麵前。
從應用角度來說，數據倉庫係統除了聯機分析處理外，還可以采用傳統的報表，或者采用數理統計和人工智能等數據挖掘手段，涵蓋的範圍更廣；就應用範圍而言，聯機分析處理往往根據用戶分析的主題進行應用分割，例如：銷售分析、市場推廣分析、客戶利潤率分析等等，每一個分析的主題形成一個OLAP應用，而所有的OLAP應用實際上隻是數據倉庫係統的一部分。
邏輯概念
OLAP展現在用戶麵前的是一幅幅多維視圖。維（Dimension）：是人們觀察數據的特定角度，是考慮問題時的一類屬性，屬性集合構成一個維（時間維、地理維等）。
維的層次（Level）：人們觀察數據的某個特定角度（即某個維）還可以存在細節程度不同的各個描述方麵（時間維：日期、月份、季度、年）。
維的成員（Member）：維的一個取值，是數據項在某維中位置的描述。（“某年某月某日”是在時間維上位置的描述）。
度量（Measure）：多維數組的取值。（2000年1月，上海，筆記本電腦，0000）。
OLAP的基本多維分析操作有鑽取（Drill-up和Drill-down）、切片（Slice）和切塊（Dice）、以及旋轉（Pivot）等。
鑽取：是改變維的層次，變換分析的粒度。它包括向下鑽取（Drill-down）和向上鑽取（Drill-up）/上卷(Roll-up)。Drill-up是在某一維上將低層次的細節數據概括到高層次的匯總數據，或者減少維數；而Drill-down則相反，它從匯總數據深入到細節數據進行觀察或增加新維。
切片和切塊：是在一部分維上選定值後，關心度量數據在剩餘維上的分布。如果剩餘的維隻有兩個，則是切片；如果有三個或以上，則是切塊。
旋轉：是變換維的方向，即在表格中重新安排維的放置（例如行列互換）。
體係結構
數據倉庫與OLAP的關係是互補的，現代OLAP係統一般以數據倉庫作為基礎，即從數據倉庫中抽取詳細數據的一個子集並經過必要的聚集存儲到OLAP存儲器中供前端分析工具讀取。典型的OLAP係統體係結構如下圖所示：
OLAP係統按照其存儲器的數據存儲格式可以分為關係OLAP（RelationalOLAP，簡稱ROLAP）、多維OLAP（MultidimensionalOLAP，簡稱MOLAP）和混合型OLAP（HybridOLAP，簡稱HOLAP）三種類型。
ROLAP
ROLAP將分析用的多維數據存儲在關係數據庫中並根據應用的需要有選擇的定義一批實視圖作為表也存儲在關係數據庫中。不必要將每一個SQL查詢都作為實視圖保存，隻定義那些應用頻率比較高、計算工作量比較大的查詢作為實視圖。對每個針對OLAP服務器的查詢，優先利用已經計算好的實視圖來生成查詢結果以提高查詢效率。同時用作ROLAP存儲器的RDBMS也針對OLAP作相應的優化，比如並行存儲、並行查詢、並行數據管理、基於成本的查詢優化、位圖索引、SQL的OLAP擴展(cube,rollup)等等。
MOLAP
MOLAP將OLAP分析所用到的多維數據物理上存儲為多維數組的形式，形成“立方體”的結構。維的屬性值被映射成多維數組的下標值或下標的範圍，而總結數據作為多維數組的值存儲在數組的單元中。由於MOLAP采用了新的存儲結構，從物理層實現起，因此又稱為物理OLAP（PhysicalOLAP）；而ROLAP主要通過一些軟件工具或中間軟件實現，物理層仍采用關係數據庫的存儲結構，因此稱為虛擬OLAP（VirtualOLAP）。
HOLAP
由於MOLAP和ROLAP有著各自的優點和缺點（如下表所示）,且它們的結構迥然不同，這給分析人員設計OLAP結構提出了難題。為此一個新的OLAP結構——混合型OLAP（HOLAP）被提出，它能把MOLAP和ROLAP兩種結構的優點結合起來。迄今為止，對HOLAP還沒有一個正式的定義。但很明顯，HOLAP結構不應該是MOLAP與ROLAP結構的簡單組合，而是這兩種結構技術優點的有機結合，能滿足用戶各種複雜的分析請求。
rolap molap
沿用現有的關係數據庫的技術
專為olap所設計
響應速度比molap慢；
現有關係型數據庫已經對olap做了很多優化，包括並行存儲、並行查詢、並行數據管理、基於成本的查詢優化、位圖索引、sql 的olap擴展(cube,rollup)等，性能有所提高
性能好、響應速度快
數據裝載速度快
數據裝載速度慢
存儲空間耗費小，維數沒有限製
需要進行預計算,可能導致數據爆炸，維數有限；無法支持維的動態變化
借用rdbms存儲數據，沒有文件大小限製
受操作係統平台中文件大小的限製，難以達到tb 級(隻能10~20g)
可以通過sql實現詳細數據與概要數據的存儲
缺乏數據模型和數據訪問的標準
–不支持有關預計算的讀寫操作
–sql無法完成部分計算
–無法完成多行的計算
–無法完成維之間的計算
–支持高性能的決策支持計算
–複雜的跨維計算
–多用戶的讀寫操作
–行級的計算
維護困難
管理簡便
實現方式
同樣是仿照用戶的多角度思考模式，聯機分析處理有三種不同的實現方法：
· 關係型聯機分析處理(ROLAP,Relational OLAP)
· 多維聯機分析處理(MOLAP,Multi-Dimensional OLAP)
· 前端展示聯機分析處理(Desktop OLAP)
其中，前端展示聯機分析需要將所有數據下載到客戶機上，然後在客戶機上進行數據結構/報表格式重組，使用戶能在本機實現動態分析。該方式比較靈活，然而它能夠支持的數據量非常有限，嚴重地影響了使用的範圍和效率。因此，隨著時間的推移，這種方式已退居次要地位，在此不作討論。
實施方法
以下就ROLAP和MOLAP的具體實施方法進行討論：
關係型聯機
顧名思義，關係型聯機分析處理是以關係型數據庫為基礎的。唯一特別之處在於聯機分析處理中的數據結構組織的方式。
讓我們考察一個例子，假設我們要進行產品銷售的財務分析，分析的角度包括時間、產品類別、市場分布、實際發生與預算四方麵內容，分析的財務指標包括：銷售額、銷售支出、毛利(=銷售額-銷售支出)、費用、純利(=毛利-費用)等內容，則我們可以建立如下的數據結構：
該數據結構的中心是主表，裏麵包含了所有分析維度的外鍵，以及所有的財務指標，可計算推導的財務指標不計在內，我們稱之為事實表(Fact Table)。周圍的表分別是對應於各個分析角度的維表(Dimension Table)，每個維表除了主鍵以外，還包含了描述和分類信息。無論原來的業務數據的數據結構為何，隻要原業務數據能夠整理成為以上模式，則無論業務人員據此提出任何問題，都可以用SQL語句進行表連接或匯總(table join and group by)實現數據查詢和解答。（當然，有一些現成的ROLAP前端分析工具是可以自動根據以上模型生成SQL語句的）。這種模式被稱為星型模式(Star-Schema)，可應用於不同的聯機分析處理應用中。
以下是另一個采用星型模式的例子，分析的角度和指標截然不同，但數據結構模式一樣。我們看到的不是表的數據，而是表的結構。在聯機分析處理的數據模型設計中，這種表達方式更為常見：
有時候，維表的定義會變得複雜，例如對產品維，既要按產品種類進行劃分，對某些特殊商品，又要另外進行品牌劃分，商品品牌和產品種類劃分方法並不一樣。因此，單張維表不是理想的解決方案，可以采用以下方式，這種數據模型實際上是星型結構的拓展，我們稱之為雪花型模式(snow-flake schema).
無論采用星型模式還是雪花型模式，關係型聯機分析處理都具有以下特點：
· 數據結構和組織模式需要預先設計和建立；
· 數據查詢需要進行表連接，在查詢性能測試中往往是影響速度的關鍵；
· 數據匯總查詢（例如查詢某個品牌的所有產品銷售額），需要進行Group by 操作，雖然實際得出的數據量很少，但查詢時間變得更長；
· 為了改善數據匯總查詢的性能，可以建立匯總表，但匯總表的數量與用戶分析的角度數目和每個角度的層次數目密切相關。例如，用戶從8個角度進行分析，每個角度有3個匯總層次，則匯總表的數目高達3的8次方。
可以采取對常用匯總數據建立匯總表，對不常用的匯總數據進行Group by 操作，這樣來取得性能和管理複雜度之間的均衡。
多維聯機
多維聯機分析處理實際上是用多維數組的方式對關係型數據表進行處理。下圖是ROLAP與MOLAP的對比：
圖中左邊是ROLAP方式，右邊是MOLAP方式，兩者對應的是同一個三維模型。MOLAP首先對事實表中的所有外鍵進行排序，並將排序後的具體指標數值一一寫進虛擬的多維立方體中。當然，虛擬的多維立方體隻是為了便於理解而構想的，MOLAP實際的數據存儲放在數據文件(Data File)中，其數據放置的順序與虛擬的多維立方體按x,y,z坐標展開的順序是一致的(如上圖)。同時，為了數據查找的方便，MOLAP需要預先建立維度的索引，這個索引被放置在MOLAP的概要文件(Outline)中。
概要文件是MOLAP的核心，相當於ROLAP的數據模型設計。概要文件包括所有維的定義（包括複雜的維度結構）以及各個層次的數據匯總關係(例如在時間維，日匯總至月，月匯總至季，季匯總至年)，這些定義往往從關係型維表中直接引入即可。概要文件也包括分析指標的定義，因此可以在概要文件中包含豐富的衍生指標，這些衍生指標由基礎指標計算推導出來（例如ROLAP例子1中的純利和毛利）。概要文件的結構如下圖所示：
一旦概要文件定義好，MOLAP係統可以自動安排數據存儲的方式和進行數據查詢。從MOLAP的數據文件與ROLAP的事實表的對比可以看出，MOLAP的數據文件完全不需要紀錄維度的外鍵，在維度比較多的情況下，這種數據存儲方式大量地節省了空間。
但是，如果數據相當稀疏，虛擬的多維立方體中很多數值為空時，MOLAP的數據文件需要對相關的位置留空，而ROLAP的事實表卻不會存儲這些紀錄。為了有效地解決這種情況，MOLAP采用了稀疏維和密集維相結合的處理方式，如下圖。
上圖的背景是某些客戶隻通過某些分銷渠道才購買，但是隻要該客戶存在，他在各個月和各個地區內均有消費(例如，華南IBM隻通過熊貓國旅定購南航機票，但在華南四省在每個月均有機票訂購)。則時間和地區維是密集維，客戶和分銷渠道是稀疏維，MOLAP將稀疏維建成索引文件(Index File)，密集維所對應的數值仍然保留在數據文件中，索引文件不存儲空紀錄。這樣保持了對空間的合理利用。我們也可以看到，如果所有維都是稀疏維，則MOLAP的索引文件就退化成ROLAP的事實表， 兩者沒有區別了。
在實際應用中，不可能所有分析的維度都是密集的，也絕少存在所有分析的維度都是稀疏的，因此稀疏維和密集維並用的模式幾乎主導了所有的MOLAP應用。而稀疏維和密集維的定義全部集中在概要文件中，因此，隻要預先定義好概要文件，所有的數據分布就自動確定了。
在這種模式中，密集維的組合組成了的數據塊(Data Block)，每個數據塊是I/O讀寫的基礎單位(如上圖)，所有的數據塊組成了數據文件。稀疏維的組合組成了索引文件，索引文件的每一個數據紀錄的末尾都帶有一個指針，指向要讀寫的數據塊。因此，進行數據查詢時，係統先搜索索引文件紀錄，然後直接調用指針指向的數據塊進行I/O讀寫(如果該數據塊尚未駐留內存)，將相應數據塊調入內存後，根據密集維的數據放置順序直接計算出要查詢的數據距離數據塊頭的偏移量，直接提取數據下傳到客戶端。因此，MOLAP 方式基本上是索引搜索與直接尋址的查詢方式相結合，比起ROLAP的表/索引搜索和表連接方式，速度要快得多。
特點
· 需要預先定義概要文件；
· 數據查詢采用索引搜索與直接尋址的方式相結合，不需要進行表連接，在查詢性能測試中比起ROLAP有相當大的優勢；
· 在進行數據匯總查詢之前，MOLAP需要預先按概要文件中定義的數據匯總關係進行計算，這個計算通常以批處理方式運行。計算結果回存在數據文件中，當用戶查詢時，直接調用計算結果，速度非常快。
· 無論是數據匯總還是計算衍生數據，預先計算的方式實際上是用空間來換時間。當然，用戶也可以選擇動態計算的方式，用查詢時間來換取存儲空間。MOLAP可以靈活調整時空的取舍平衡。
· 用戶難以使用概要文件中沒有定義的數據匯總關係和衍生指標。
· 在大數據量環境下，關係型數據庫可以達到TB級的數據量，現有的MOLAP應用局限於基於文件係統的處理和查詢方式，其性能會在100GB級別開始下降，需要進行數據分區處理，因此擴展性不如ROLAP。因此，MOLAP多數用於部門級的主題分析應用。
其它因素
聯機分析處理其他要素包括假設分析(What-if)，複雜計算，數據評估等等。這些因素對用戶的分析效用至關重要，但是與ROLAP和MOLAP的核心工作原理的不一定有很緊密的關係，事實上，ROLAP和MOLAP都可以在以上三方麵有所建樹，隻不過實現的方法迥異。因此，這些因素更取決於各個廠商為他們的產品提供的外延功能。對於像IBM的DB2 OLAP Server這樣一個成熟的產品來說，這三方麵均有獨特的優勢：
假設分析
假設分析提出了類似於以下的問題："如果產品降價5%，而運費增加8%，對不同地區的分銷商的進貨成本會有什麼影響？"這些問題常用於銷售預測、費用預算分配、獎金製度確定等等。據此，用戶可以分析出哪些角度、哪些因素的變化將對企業產生重要影響；並且，用戶可以靈活調節自己手中掌握的資源(例如費用預算等)，將它用到最有效的地方中去。
假設分析要求OLAP係統能夠隨用戶的思路調整數據，並動態反映出在調整後對其他數據的影響結果。事實上，進入OLAP的數據分兩大類：事實數據和預算數據。事實數據一般情況下不容修改，而預算數據則應常常進行調整。DB2 OLAP Server通過詳細的權限定義區分了數據的讀寫權限，允許用戶對預算數據進行更改，係統可以對其他受影響的數據進行計算，以反映出"假如發生如上情況，將會引起以下結果"的結論。
複雜計算
分析人員往往需要分析複雜的衍生數據，諸如：同期對比、期初/期末餘額、百分比份額計算、資源分配(按從頂向下的結構圖逐級分配)、移動平均、均方差等等。對這些要求，DB2 OLAP Server提供豐富的功能函數以便用戶使用。因為隻有在無需編程的環境下，商業用戶才能更好地靈活利用這些功能進行複雜的真實世界模擬。
數據評估
數據評估包括兩方麵內容，有效性評估和商業意義評估。在有效性評估方麵，數據抽取、清洗和轉換的規則的定義是至關重要的。而合理的數據模型設計能有效防止無效數據的進入。例如在ROLAP中，如果維表沒有采用範式設計(normalise design)，可能會接受如下的維表：
機構代碼 機構名稱 所屬區縣 所屬城市 所屬省份
001 越秀支行 越秀區 廣州 廣東
002 祖廟支行 佛山 廣州 廣東
003 翠屏支行 佛山 南海 廣東
004 。。。 。。。 。。。 。。。
顯然，002中顯示的佛山屬於廣州市，與003中顯示的佛山屬於南海市是矛盾的。這顯示出數據源有問題，但是如果采用星型模式設計，ROLAP無法自動發現數據源的問題！
在類似情況下，MOLAP的表現稍占優勢。因為MOLAP需要預先定義概要文件，而概要文件會詳細分析維度的層次關係，因此生成概要文件時會反映數據源的錯誤。因此，在DB2 OLAP Server中，記錄003會被拒收，並紀錄在出錯日誌中，供IT人員更正。
但是，OLAP對數據源有效性的驗證能力畢竟是有限的，因此，數據有效性必須從源數據一級和數據抽取/清洗/轉換處理一級來進行保障。
對用戶而言，數據的商業含義評估更有意義。在商業活動中，指標數值的取值範圍是比較穩定的，如果指標數值突然發生變化，或者在同期比較、同類比較中有特殊表現，意味著該指標代表的方方麵麵具有特別的分析意義。普通的OLAP往往需要用戶自己去觀察發現異常指標，而DB2 OLAP Server的OLAP Minor(多維數據挖掘功能)能為用戶特別地指出哪些條件下的哪些指標偏離常值，從而引起用戶的注意和思考。例如：12月份南部的聖誕禮品銷售額不到同期類似區域（東部、中部、西部）的50%。
綜上所述，無論ROLAP還是MOLAP，都能夠實現聯機分析處理的基本功能，兩者在查詢效率，存儲空間和擴展性方麵各有千秋。IT人員在選擇OLAP係統時，既要考慮產品內部的實現機製，同時也應考慮假設分析，複雜計算，數據評估方麵的功能，為實現決策管理信息係統打下堅實的基礎。
最後更新：2017-04-03 12:53:51