簡寫為OLAP,隨著數(shù)據(jù)庫技術的發(fā)展和應用，數(shù)據(jù)庫存儲的數(shù)據(jù)量從20世紀80年代的兆（M）字節(jié)及千兆（G）字節(jié)過渡到現(xiàn)在的兆兆（T）字節(jié)和千兆兆（P）字節(jié)，同時，用戶的查詢需求也越來越復雜，涉及的已不僅是查詢或操縱一張關系表中的一條或幾條記錄，而且要對多張表中千萬條記錄的數(shù)據(jù)進行數(shù)據(jù)分析和信息綜合，關系數(shù)據(jù)庫系統(tǒng)已不能全部滿足這一要求。在國外，不少軟件廠商采取了發(fā)展其前端產(chǎn)品來彌補關系數(shù)據(jù)庫管理系統(tǒng)支持的不足，力圖統(tǒng)一分散的公共應用邏輯，在短時間內(nèi)響應非數(shù)據(jù)處理專業(yè)人員的復雜查詢要求。

聯(lián)機分析處理（OLAP）系統(tǒng)是數(shù)據(jù)倉庫系統(tǒng)最主要的應用，專門設計用于支持復雜的分析操作，側(cè)重對決策人員和高層管理人員的決策支持，可以根據(jù)分析人員的要求快速、靈活地進行大數(shù)據(jù)量的復雜查詢處理，并且以一種直觀而易懂的形式將查詢結果提供給決策人員，以便他們準確掌握企業(yè)（公司）的經(jīng)營狀況，了解對象的需求，制定正確的方案。

聯(lián)機分析處理是共享多維信息的、針對特定問題的聯(lián)機數(shù)據(jù)訪問和分析的快速軟件技術。它通過對信息的多種可能的觀察形式進行快速、穩(wěn)定一致和交互性的存取，允許管理決策人員對數(shù)據(jù)進行深入觀察。決策數(shù)據(jù)是多維數(shù)據(jù)，多維數(shù)據(jù)就是決策的主要內(nèi)容。OLAP專門設計用于支持復雜的分析操作，側(cè)重對決策人員和高層管理人員的決策支持，可以根據(jù)分析人員的要求快速、靈活地進行大數(shù)據(jù)量的復雜查詢處理，并且以一種直觀而易懂的形式將查詢結果提供給決策人員，以便他們準確掌握企業(yè)（公司）的經(jīng)營狀況，了解對象的需求，制定正確的方案。聯(lián)機分析處理具有靈活的分析功能、直觀的數(shù)據(jù)操作和分析結果可視化表示等突出優(yōu)點，從而使用戶對基于大量復雜數(shù)據(jù)的分析變得輕松而高效，以利于迅速做出正確判斷。它可用于證實人們提出的復雜的假設，其結果是以圖形或者表格的形式來表示的對信息的總結。它并不將異常信息標記出來，是一種知識證實的方法。

聯(lián)機分析處理 (OLAP) 的概念最早是由關系數(shù)據(jù)庫之父E.F.Codd于1993年提出的，他同時提出了關于OLAP的12條準則。OLAP的提出引起了很大的反響，OLAP作為一類產(chǎn)品同聯(lián)機事務處理 (OLTP) 明顯區(qū)分開來。

Codd提出OLAP的12條準則來描述OLAP系統(tǒng)：

準則1 OLAP模型必須提供多維概念視圖

準則2 透明性準則

準則3 存取能力準則

準則4 穩(wěn)定的報表能力

準則5 客戶/服務器體系結構

準則6 維的等同性準則

準則7 動態(tài)的稀疏矩陣處理準則

準則8 多用戶支持能力準則

準則9 非受限的跨維操作

準則10 直觀的數(shù)據(jù)操縱

準則11 靈活的報表生成

準則12 不受限的維與聚集層次

仔細再重溫E.F. Codd提出的這12條規(guī)則，我們可以發(fā)現(xiàn)傳統(tǒng)的OLAP有一點過時，已經(jīng)不足以滿足在大數(shù)據(jù)上的數(shù)據(jù)挖掘了。比如第6條“數(shù)據(jù)的每個維度都相當”對于非結構化的數(shù)據(jù)是沒有意義的。

當今的數(shù)據(jù)處理大致可以分成兩大類：聯(lián)機事務處理OLTP（on-line transaction processing）、聯(lián)機分析處理OLAP（On-Line Analytical Processing）。OLTP是傳統(tǒng)的關系型數(shù)據(jù)庫的主要應用，主要是基本的、日常的事務處理，例如銀行交易。OLAP是數(shù)據(jù)倉庫系統(tǒng)的主要應用，支持復雜的分析操作，側(cè)重決策支持，并且提供直觀易懂的查詢結果。下表列出了OLTP與OLAP之間的比較。

隨著數(shù)據(jù)庫技術的廣泛應用，企業(yè)信息系統(tǒng)產(chǎn)生了大量的數(shù)據(jù)，如何從這些海量數(shù)據(jù)中提取對企業(yè)決策分析有用的信息成為企業(yè)決策管理人員所面臨的重要難題。傳統(tǒng)的企業(yè)數(shù)據(jù)庫系統(tǒng)（管理信息系統(tǒng)）即聯(lián)機事務處理系統(tǒng)（On-LineTransactionProcessing,簡稱OLTP）作為數(shù)據(jù)管理手段，主要用于事務處理，但它對分析處理的支持一直不能令人滿意。因此，人們逐漸嘗試對OLTP數(shù)據(jù)庫中的數(shù)據(jù)進行再加工，形成一個綜合的、面向分析的、更好的支持決策制定的決策支持系統(tǒng)（DecisionSupportSystem，簡稱DSS）。企業(yè)的信息系統(tǒng)的數(shù)據(jù)一般由DBMS管理，但決策數(shù)據(jù)庫和運行操作數(shù)據(jù)庫在數(shù)據(jù)來源、數(shù)據(jù)內(nèi)容、數(shù)據(jù)模式、服務對象、訪問方式、事務管理乃至物理存儲等方面都有不同的特點和要求，因此直接在運行操作的數(shù)據(jù)庫上建立DSS是不合適的。數(shù)據(jù)倉庫（DataWarehouse）技術就是在這樣的背景下發(fā)展起來的。數(shù)據(jù)倉庫的概念提出于20世紀80年代中期，20世紀90年代，數(shù)據(jù)倉庫已從早期的探索階段走向?qū)嵱秒A段。業(yè)界公認的數(shù)據(jù)倉庫概念創(chuàng)始人W.H.Inmon在《BuildingtheDataWarehouse》一書中對數(shù)據(jù)倉庫的定義是：“數(shù)據(jù)倉庫是支持管理決策過程的、面向主題的、集成的、隨時間變化的持久的數(shù)據(jù)集合”。構建數(shù)據(jù)倉庫的過程就是根據(jù)預先設計好的邏輯模式從分布在企業(yè)內(nèi)部各處的OLTP數(shù)據(jù)庫中提取數(shù)據(jù)并對經(jīng)過必要的變換最終形成全企業(yè)統(tǒng)一模式數(shù)據(jù)的過程。當前數(shù)據(jù)倉庫的核心仍是RDBMS管理下的一個數(shù)據(jù)庫系統(tǒng)。數(shù)據(jù)倉庫中數(shù)據(jù)量巨大，為了提高性能，RDBMS一般也采取一些提高效率的措施：采用并行處理結構、新的數(shù)據(jù)組織、查詢策略、索引技術等等。

包括聯(lián)機分析處理（On-LineAnalyticalProcessing，簡稱OLAP）在內(nèi)的諸多應用牽引驅(qū)動了數(shù)據(jù)倉庫技術的出現(xiàn)和發(fā)展；而

數(shù)據(jù)倉庫技術反過來又促進了OLAP技術的發(fā)展。聯(lián)機分析處理的概念最早由關系數(shù)據(jù)庫之父E.F.Codd于1993年提出的。Codd認為聯(lián)機事務處理（OLTP）已不能滿足終端用戶對數(shù)據(jù)庫查詢分析的要求，SQL對大數(shù)據(jù)庫的簡單查詢也不能滿足用戶分析的需求。用戶的決策分析需要對關系數(shù)據(jù)庫進行大量計算才能得到結果，而查詢的結果并不能滿足決策者提出的需求。因此，Codd提出了多維數(shù)據(jù)庫和多維分析的概念，即OLAP。OLAP委員會對聯(lián)機分析處理的定義為：從原始數(shù)據(jù)中轉(zhuǎn)化出來的、能夠真正為用戶所理解的、并真實反映企業(yè)多維特性的數(shù)據(jù)稱為信息數(shù)據(jù)，使分析人員、管理人員或執(zhí)行人員能夠從多種角度對信息數(shù)據(jù)進行快速、一致、交互地存取，從而獲得對數(shù)據(jù)的更深入了解的一類軟件技術。OLAP的目標是滿足決策支持或多維環(huán)境特定的查詢和報表需求，它的技術核心是“維”這個概念，因此OLAP也可以說是多維數(shù)據(jù)分析工具的集合。

在過去的二十年中，大量的企業(yè)利用關系型數(shù)據(jù)庫來存儲和管理業(yè)務數(shù)據(jù)，并建立相應的應用系統(tǒng)來支持日常業(yè)務運作。這種應用以支持業(yè)務處理為主要目的，被稱為聯(lián)機事務處理(OLTP，On-line Transaction Processing)應用，它所存儲的數(shù)據(jù)被稱為操作數(shù)據(jù)或者業(yè)務數(shù)據(jù)。

隨著市場競爭的日趨激烈，企業(yè)更加強調(diào)決策的及時性和準確性，這使得以支持決策管理分析為主要目的的應用迅速崛起，這類應用被稱為聯(lián)機分析處理，它所存儲的數(shù)據(jù)被稱為信息數(shù)據(jù)。

聯(lián)機分析處理的用戶是企業(yè)中的專業(yè)分析人員及管理決策人員，他們在分析業(yè)務經(jīng)營的數(shù)據(jù)時，從不同的角度來審視業(yè)務的衡量指標是一種很自然的思考模式。例如分析銷售數(shù)據(jù)，可能會綜合時間周期、產(chǎn)品類別、分銷渠道、地理分布、客戶群類等多種因素來考量。這些分析角度雖然可以通過報表來反映，但每一個分析的角度可以生成一張報表，各個分析角度的不同組合又可以生成不同的報表，使得IT人員的工作量相當大，而且往往難以跟上管理決策人員思考的步伐。

聯(lián)機分析處理的主要特點，是直接仿照用戶的多角度思考模式，預先為用戶組建多維的數(shù)據(jù)模型，在這里，維指的是用戶的分析角度。例如對銷售數(shù)據(jù)的分析，時間周期是一個維度，產(chǎn)品類別、分銷渠道、地理分布、客戶群類也分別是一個維度。一旦多維數(shù)據(jù)模型建立完成，用戶可以快速地從各個分析角度獲取數(shù)據(jù)，也能動態(tài)的在各個角度之間切換或者進行多角度綜合分析，具有極大的分析靈活性。這也是聯(lián)機分析處理被廣泛關注的根本原因，它從設計理念和真正實現(xiàn)上都與舊有的管理信息系統(tǒng)有著本質(zhì)的區(qū)別。

事實上，隨著數(shù)據(jù)倉庫理論的發(fā)展，數(shù)據(jù)倉庫系統(tǒng)已逐步成為新型的決策管理信息系統(tǒng)的解決方案。數(shù)據(jù)倉庫系統(tǒng)的核心是聯(lián)機分析處理，但數(shù)據(jù)倉庫包括更為廣泛的內(nèi)容。

概括來說，數(shù)據(jù)倉庫系統(tǒng)是指具有綜合企業(yè)數(shù)據(jù)的能力，能夠?qū)Υ罅科髽I(yè)數(shù)據(jù)進行快速和準確分析，輔助做出更好的商業(yè)決策的系統(tǒng)。它本身包括三部分內(nèi)容：

1、數(shù)據(jù)層：實現(xiàn)對企業(yè)操作數(shù)據(jù)的抽取、轉(zhuǎn)換、清洗和匯總，形成信息數(shù)據(jù)，并存儲在企業(yè)級的中心信息數(shù)據(jù)庫中。

2、應用層：通過聯(lián)機分析處理，甚至是數(shù)據(jù)挖掘等應用處理，實現(xiàn)對信息數(shù)據(jù)的分析。

3、表現(xiàn)層：通過前臺分析工具，將查詢報表、統(tǒng)計分析、多維聯(lián)機分析和數(shù)據(jù)發(fā)掘的結論展現(xiàn)在用戶面前。

從應用角度來說，數(shù)據(jù)倉庫系統(tǒng)除了聯(lián)機分析處理外，還可以采用傳統(tǒng)的報表，或者采用數(shù)理統(tǒng)計和人工智能等數(shù)據(jù)挖掘手段，涵蓋的范圍更廣；就應用范圍而言，聯(lián)機分析處理往往根據(jù)用戶分析的主題進行應用分割，例如：銷售分析、市場推廣分析、客戶利潤率分析等等，每一個分析的主題形成一個OLAP應用，而所有的OLAP應用實際上只是數(shù)據(jù)倉庫系統(tǒng)的一部分。

OLAP展現(xiàn)在用戶面前的是一幅幅多維視圖。維（Dimension）：是人們觀察數(shù)據(jù)的特定角度，是考慮問題時的一類屬性，屬性集合構成一個維（時間維、地理維等）。

維的層次（Level）：人們觀察數(shù)據(jù)的某個特定角度（即某個維）還可以存在細節(jié)程度不同的各個描述方面（時間維：日期、月份、季度、年）。

維的成員（Member）：維的一個取值，是數(shù)據(jù)項在某維中位置的描述。（“某年某月某日”是在時間維上位置的描述）。

度量（Measure）：多維數(shù)組的取值。（2000年1月，上海，筆記本電腦，0000）。

OLAP的基本多維分析操作有鉆?。―rill-up和Drill-down）、切片（Slice）和切塊（Dice）、以及旋轉(zhuǎn)（Pivot）等。

鉆?。菏歉淖兙S的層次，變換分析的粒度。它包括向下鉆取（Drill-down）和向上鉆取（Drill-up）/上卷(Roll-up)。Drill-up是在某一維上將低層次的細節(jié)數(shù)據(jù)概括到高層次的匯總數(shù)據(jù)，或者減少維數(shù)；而Drill-down則相反，它從匯總數(shù)據(jù)深入到細節(jié)數(shù)據(jù)進行觀察或增加新維。

切片和切塊：是在一部分維上選定值后，關心度量數(shù)據(jù)在剩余維上的分布。如果剩余的維只有兩個，則是切片；如果有三個或以上，則是切塊。

旋轉(zhuǎn)：是變換維的方向，即在表格中重新安排維的放置（例如行列互換）。

數(shù)據(jù)倉庫與OLAP的關系是互補的，現(xiàn)代OLAP系統(tǒng)一般以數(shù)據(jù)倉庫作為基礎，即從數(shù)據(jù)倉庫中抽取詳細數(shù)據(jù)的一個子集并經(jīng)過必要的聚集存儲到OLAP存儲器中供前端分析工具讀取。典型的OLAP系統(tǒng)體系結構如下圖所示：

OLAP系統(tǒng)按照其存儲器的數(shù)據(jù)存儲格式可以分為關系OLAP（RelationalOLAP，簡稱ROLAP）、多維OLAP（MultidimensionalOLAP，簡稱MOLAP）和混合型OLAP（HybridOLAP，簡稱HOLAP）三種類型。

ROLAP將分析用的多維數(shù)據(jù)存儲在關系數(shù)據(jù)庫中并根據(jù)應用的需要有選擇的定義一批實視圖作為表也存儲在關系數(shù)據(jù)庫中。不必要將每一個SQL查詢都作為實視圖保存，只定義那些應用頻率比較高、計算工作量比較大的查詢作為實視圖。對每個針對OLAP服務器的查詢，優(yōu)先利用已經(jīng)計算好的實視圖來生成查詢結果以提高查詢效率。同時用作ROLAP存儲器的RDBMS也針對OLAP作相應的優(yōu)化，比如并行存儲、并行查詢、并行數(shù)據(jù)管理、基于成本的查詢優(yōu)化、位圖索引、SQL的OLAP擴展(cube,rollup)等等。

MOLAP將OLAP分析所用到的多維數(shù)據(jù)物理上存儲為多維數(shù)組的形式，形成“立方體”的結構。維的屬性值被映射成多維數(shù)組的下標值或下標的范圍，而總結數(shù)據(jù)作為多維數(shù)組的值存儲在數(shù)組的單元中。由于MOLAP采用了新的存儲結構，從物理層實現(xiàn)起，因此又稱為物理OLAP（PhysicalOLAP）；而ROLAP主要通過一些軟件工具或中間軟件實現(xiàn)，物理層仍采用關系數(shù)據(jù)庫的存儲結構，因此稱為虛擬OLAP（VirtualOLAP）。

由于MOLAP和ROLAP有著各自的優(yōu)點和缺點（如下表所示）,且它們的結構迥然不同，這給分析人員設計OLAP結構提出了難題。為此一個新的OLAP結構——混合型OLAP（HOLAP）被提出，它能把MOLAP和ROLAP兩種結構的優(yōu)點結合起來。迄今為止，對HOLAP還沒有一個正式的定義。但很明顯，HOLAP結構不應該是MOLAP與ROLAP結構的簡單組合，而是這兩種結構技術優(yōu)點的有機結合，能滿足用戶各種復雜的分析請求。

rolap molap

沿用現(xiàn)有的關系數(shù)據(jù)庫的技術

專為olap所設計

響應速度比molap慢；

現(xiàn)有關系型數(shù)據(jù)庫已經(jīng)對olap做了很多優(yōu)化，包括并行存儲、并行查詢、并行數(shù)據(jù)管理、基于成本的查詢優(yōu)化、位圖索引、sql 的olap擴展(cube,rollup)等，性能有所提高

性能好、響應速度快

數(shù)據(jù)裝載速度快

數(shù)據(jù)裝載速度慢

存儲空間耗費小，維數(shù)沒有限制

需要進行預計算,可能導致數(shù)據(jù)爆炸，維數(shù)有限；無法支持維的動態(tài)變化

借用rdbms存儲數(shù)據(jù)，沒有文件大小限制

受操作系統(tǒng)平臺中文件大小的限制，難以達到tb 級(只能10~20g)

可以通過sql實現(xiàn)詳細數(shù)據(jù)與概要數(shù)據(jù)的存儲

缺乏數(shù)據(jù)模型和數(shù)據(jù)訪問的標準

–不支持有關預計算的讀寫操作

–sql無法完成部分計算

–無法完成多行的計算

–無法完成維之間的計算

–支持高性能的決策支持計算

–復雜的跨維計算

–多用戶的讀寫操作

–行級的計算

維護困難

管理簡便

同樣是仿照用戶的多角度思考模式，聯(lián)機分析處理有三種不同的實現(xiàn)方法：

· 關系型聯(lián)機分析處理(ROLAP,Relational OLAP)

· 多維聯(lián)機分析處理(MOLAP,Multi-Dimensional OLAP)

· 前端展示聯(lián)機分析處理(Desktop OLAP)

其中，前端展示聯(lián)機分析需要將所有數(shù)據(jù)下載到客戶機上，然后在客戶機上進行數(shù)據(jù)結構/報表格式重組，使用戶能在本機實現(xiàn)動態(tài)分析。該方式比較靈活，然而它能夠支持的數(shù)據(jù)量非常有限，嚴重地影響了使用的范圍和效率。因此，隨著時間的推移，這種方式已退居次要地位，在此不作討論。

以下就ROLAP和MOLAP的具體實施方法進行討論：

顧名思義，關系型聯(lián)機分析處理是以關系型數(shù)據(jù)庫為基礎的。唯一特別之處在于聯(lián)機分析處理中的數(shù)據(jù)結構組織的方式。

讓我們考察一個例子，假設我們要進行產(chǎn)品銷售的財務分析，分析的角度包括時間、產(chǎn)品類別、市場分布、實際發(fā)生與預算四方面內(nèi)容，分析的財務指標包括：銷售額、銷售支出、毛利(=銷售額-銷售支出)、費用、純利(=毛利-費用)等內(nèi)容，則我們可以建立如下的數(shù)據(jù)結構：

該數(shù)據(jù)結構的中心是主表，里面包含了所有分析維度的外鍵，以及所有的財務指標，可計算推導的財務指標不計在內(nèi)，我們稱之為事實表(Fact Table)。周圍的表分別是對應于各個分析角度的維表(Dimension Table)，每個維表除了主鍵以外，還包含了描述和分類信息。無論原來的業(yè)務數(shù)據(jù)的數(shù)據(jù)結構為何，只要原業(yè)務數(shù)據(jù)能夠整理成為以上模式，則無論業(yè)務人員據(jù)此提出任何問題，都可以用SQL語句進行表連接或匯總(table join and group by)實現(xiàn)數(shù)據(jù)查詢和解答。（當然，有一些現(xiàn)成的ROLAP前端分析工具是可以自動根據(jù)以上模型生成SQL語句的）。這種模式被稱為星型模式(Star-Schema)，可應用于不同的聯(lián)機分析處理應用中。

以下是另一個采用星型模式的例子，分析的角度和指標截然不同，但數(shù)據(jù)結構模式一樣。我們看到的不是表的數(shù)據(jù)，而是表的結構。在聯(lián)機分析處理的數(shù)據(jù)模型設計中，這種表達方式更為常見：

有時候，維表的定義會變得復雜，例如對產(chǎn)品維，既要按產(chǎn)品種類進行劃分，對某些特殊商品，又要另外進行品牌劃分，商品品牌和產(chǎn)品種類劃分方法并不一樣。因此，單張維表不是理想的解決方案，可以采用以下方式，這種數(shù)據(jù)模型實際上是星型結構的拓展，我們稱之為雪花型模式(snow-flake schema).

無論采用星型模式還是雪花型模式，關系型聯(lián)機分析處理都具有以下特點：

· 數(shù)據(jù)結構和組織模式需要預先設計和建立；

· 數(shù)據(jù)查詢需要進行表連接，在查詢性能測試中往往是影響速度的關鍵；

· 數(shù)據(jù)匯總查詢（例如查詢某個品牌的所有產(chǎn)品銷售額），需要進行Group by 操作，雖然實際得出的數(shù)據(jù)量很少，但查詢時間變得更長；

· 為了改善數(shù)據(jù)匯總查詢的性能，可以建立匯總表，但匯總表的數(shù)量與用戶分析的角度數(shù)目和每個角度的層次數(shù)目密切相關。例如，用戶從8個角度進行分析，每個角度有3個匯總層次，則匯總表的數(shù)目高達3的8次方。

可以采取對常用匯總數(shù)據(jù)建立匯總表，對不常用的匯總數(shù)據(jù)進行Group by 操作，這樣來取得性能和管理復雜度之間的均衡。

多維聯(lián)機分析處理實際上是用多維數(shù)組的方式對關系型數(shù)據(jù)表進行處理。下圖是ROLAP與MOLAP的對比：

圖中左邊是ROLAP方式，右邊是MOLAP方式，兩者對應的是同一個三維模型。MOLAP首先對事實表中的所有外鍵進行排序，并將排序后的具體指標數(shù)值一一寫進虛擬的多維立方體中。當然，虛擬的多維立方體只是為了便于理解而構想的，MOLAP實際的數(shù)據(jù)存儲放在數(shù)據(jù)文件(Data File)中，其數(shù)據(jù)放置的順序與虛擬的多維立方體按x,y,z坐標展開的順序是一致的(如上圖)。同時，為了數(shù)據(jù)查找的方便，MOLAP需要預先建立維度的索引，這個索引被放置在MOLAP的概要文件(Outline)中。

概要文件是MOLAP的核心，相當于ROLAP的數(shù)據(jù)模型設計。概要文件包括所有維的定義（包括復雜的維度結構）以及各個層次的數(shù)據(jù)匯總關系(例如在時間維，日匯總至月，月匯總至季，季匯總至年)，這些定義往往從關系型維表中直接引入即可。概要文件也包括分析指標的定義，因此可以在概要文件中包含豐富的衍生指標，這些衍生指標由基礎指標計算推導出來（例如ROLAP例子1中的純利和毛利）。概要文件的結構如下圖所示：

一旦概要文件定義好，MOLAP系統(tǒng)可以自動安排數(shù)據(jù)存儲的方式和進行數(shù)據(jù)查詢。從MOLAP的數(shù)據(jù)文件與ROLAP的事實表的對比可以看出，MOLAP的數(shù)據(jù)文件完全不需要紀錄維度的外鍵，在維度比較多的情況下，這種數(shù)據(jù)存儲方式大量地節(jié)省了空間。

但是，如果數(shù)據(jù)相當稀疏，虛擬的多維立方體中很多數(shù)值為空時，MOLAP的數(shù)據(jù)文件需要對相關的位置留空，而ROLAP的事實表卻不會存儲這些紀錄。為了有效地解決這種情況，MOLAP采用了稀疏維和密集維相結合的處理方式，如下圖。

上圖的背景是某些客戶只通過某些分銷渠道才購買，但是只要該客戶存在，他在各個月和各個地區(qū)內(nèi)均有消費(例如，華南IBM只通過熊貓國旅定購南航機票，但在華南四省在每個月均有機票訂購)。則時間和地區(qū)維是密集維，客戶和分銷渠道是稀疏維，MOLAP將稀疏維建成索引文件(Index File)，密集維所對應的數(shù)值仍然保留在數(shù)據(jù)文件中，索引文件不存儲空紀錄。這樣保持了對空間的合理利用。我們也可以看到，如果所有維都是稀疏維，則MOLAP的索引文件就退化成ROLAP的事實表， 兩者沒有區(qū)別了。

在實際應用中，不可能所有分析的維度都是密集的，也絕少存在所有分析的維度都是稀疏的，因此稀疏維和密集維并用的模式幾乎主導了所有的MOLAP應用。而稀疏維和密集維的定義全部集中在概要文件中，因此，只要預先定義好概要文件，所有的數(shù)據(jù)分布就自動確定了。

在這種模式中，密集維的組合組成了的數(shù)據(jù)塊(Data Block)，每個數(shù)據(jù)塊是I/O讀寫的基礎單位(如上圖)，所有的數(shù)據(jù)塊組成了數(shù)據(jù)文件。稀疏維的組合組成了索引文件，索引文件的每一個數(shù)據(jù)紀錄的末尾都帶有一個指針，指向要讀寫的數(shù)據(jù)塊。因此，進行數(shù)據(jù)查詢時，系統(tǒng)先搜索索引文件紀錄，然后直接調(diào)用指針指向的數(shù)據(jù)塊進行I/O讀寫(如果該數(shù)據(jù)塊尚未駐留內(nèi)存)，將相應數(shù)據(jù)塊調(diào)入內(nèi)存后，根據(jù)密集維的數(shù)據(jù)放置順序直接計算出要查詢的數(shù)據(jù)距離數(shù)據(jù)塊頭的偏移量，直接提取數(shù)據(jù)下傳到客戶端。因此，MOLAP 方式基本上是索引搜索與直接尋址的查詢方式相結合，比起ROLAP的表/索引搜索和表連接方式，速度要快得多。

· 需要預先定義概要文件；

· 數(shù)據(jù)查詢采用索引搜索與直接尋址的方式相結合，不需要進行表連接，在查詢性能測試中比起ROLAP有相當大的優(yōu)勢；

· 在進行數(shù)據(jù)匯總查詢之前，MOLAP需要預先按概要文件中定義的數(shù)據(jù)匯總關系進行計算，這個計算通常以批處理方式運行。計算結果回存在數(shù)據(jù)文件中，當用戶查詢時，直接調(diào)用計算結果，速度非?？?。

· 無論是數(shù)據(jù)匯總還是計算衍生數(shù)據(jù)，預先計算的方式實際上是用空間來換時間。當然，用戶也可以選擇動態(tài)計算的方式，用查詢時間來換取存儲空間。MOLAP可以靈活調(diào)整時空的取舍平衡。

· 用戶難以使用概要文件中沒有定義的數(shù)據(jù)匯總關系和衍生指標。

· 在大數(shù)據(jù)量環(huán)境下，關系型數(shù)據(jù)庫可以達到TB級的數(shù)據(jù)量，現(xiàn)有的MOLAP應用局限于基于文件系統(tǒng)的處理和查詢方式，其性能會在100GB級別開始下降，需要進行數(shù)據(jù)分區(qū)處理，因此擴展性不如ROLAP。因此，MOLAP多數(shù)用于部門級的主題分析應用。

聯(lián)機分析處理其他要素包括假設分析(What-if)，復雜計算，數(shù)據(jù)評估等等。這些因素對用戶的分析效用至關重要，但是與ROLAP和MOLAP的核心工作原理的不一定有很緊密的關系，事實上，ROLAP和MOLAP都可以在以上三方面有所建樹，只不過實現(xiàn)的方法迥異。因此，這些因素更取決于各個廠商為他們的產(chǎn)品提供的外延功能。對于像IBM的DB2 OLAP Server這樣一個成熟的產(chǎn)品來說，這三方面均有獨特的優(yōu)勢：

假設分析提出了類似于以下的問題："如果產(chǎn)品降價5%，而運費增加8%，對不同地區(qū)的分銷商的進貨成本會有什么影響？"這些問題常用于銷售預測、費用預算分配、獎金制度確定等等。據(jù)此，用戶可以分析出哪些角度、哪些因素的變化將對企業(yè)產(chǎn)生重要影響；并且，用戶可以靈活調(diào)節(jié)自己手中掌握的資源(例如費用預算等)，將它用到最有效的地方中去。

假設分析要求OLAP系統(tǒng)能夠隨用戶的思路調(diào)整數(shù)據(jù)，并動態(tài)反映出在調(diào)整后對其他數(shù)據(jù)的影響結果。事實上，進入OLAP的數(shù)據(jù)分兩大類：事實數(shù)據(jù)和預算數(shù)據(jù)。事實數(shù)據(jù)一般情況下不容修改，而預算數(shù)據(jù)則應常常進行調(diào)整。DB2 OLAP Server通過詳細的權限定義區(qū)分了數(shù)據(jù)的讀寫權限，允許用戶對預算數(shù)據(jù)進行更改，系統(tǒng)可以對其他受影響的數(shù)據(jù)進行計算，以反映出"假如發(fā)生如上情況，將會引起以下結果"的結論。

分析人員往往需要分析復雜的衍生數(shù)據(jù)，諸如：同期對比、期初/期末余額、百分比份額計算、資源分配(按從頂向下的結構圖逐級分配)、移動平均、均方差等等。對這些要求，DB2 OLAP Server提供豐富的功能函數(shù)以便用戶使用。因為只有在無需編程的環(huán)境下，商業(yè)用戶才能更好地靈活利用這些功能進行復雜的真實世界模擬。

數(shù)據(jù)評估包括兩方面內(nèi)容，有效性評估和商業(yè)意義評估。在有效性評估方面，數(shù)據(jù)抽取、清洗和轉(zhuǎn)換的規(guī)則的定義是至關重要的。而合理的數(shù)據(jù)模型設計能有效防止無效數(shù)據(jù)的進入。例如在ROLAP中，如果維表沒有采用范式設計(normalise design)，可能會接受如下的維表：

機構代碼 機構名稱 所屬區(qū)縣 所屬城市 所屬省份

001 越秀支行 越秀區(qū) 廣州 廣東

002 祖廟支行 佛山 廣州 廣東

003 翠屏支行 佛山 南海 廣東

004 。。。 。。。 。。。 。。。

顯然，002中顯示的佛山屬于廣州市，與003中顯示的佛山屬于南海市是矛盾的。這顯示出數(shù)據(jù)源有問題，但是如果采用星型模式設計，ROLAP無法自動發(fā)現(xiàn)數(shù)據(jù)源的問題！

在類似情況下，MOLAP的表現(xiàn)稍占優(yōu)勢。因為MOLAP需要預先定義概要文件，而概要文件會詳細分析維度的層次關系，因此生成概要文件時會反映數(shù)據(jù)源的錯誤。因此，在DB2 OLAP Server中，記錄003會被拒收，并紀錄在出錯日志中，供IT人員更正。

但是，OLAP對數(shù)據(jù)源有效性的驗證能力畢竟是有限的，因此，數(shù)據(jù)有效性必須從源數(shù)據(jù)一級和數(shù)據(jù)抽取/清洗/轉(zhuǎn)換處理一級來進行保障。

對用戶而言，數(shù)據(jù)的商業(yè)含義評估更有意義。在商業(yè)活動中，指標數(shù)值的取值范圍是比較穩(wěn)定的，如果指標數(shù)值突然發(fā)生變化，或者在同期比較、同類比較中有特殊表現(xiàn)，意味著該指標代表的方方面面具有特別的分析意義。普通的OLAP往往需要用戶自己去觀察發(fā)現(xiàn)異常指標，而DB2 OLAP Server的OLAP Minor(多維數(shù)據(jù)挖掘功能)能為用戶特別地指出哪些條件下的哪些指標偏離常值，從而引起用戶的注意和思考。例如：12月份南部的圣誕禮品銷售額不到同期類似區(qū)域（東部、中部、西部）的50%。

綜上所述，無論ROLAP還是MOLAP，都能夠?qū)崿F(xiàn)聯(lián)機分析處理的基本功能，兩者在查詢效率，存儲空間和擴展性方面各有千秋。IT人員在選擇OLAP系統(tǒng)時，既要考慮產(chǎn)品內(nèi)部的實現(xiàn)機制，同時也應考慮假設分析，復雜計算，數(shù)據(jù)評估方面的功能，為實現(xiàn)決策管理信息系統(tǒng)打下堅實的基礎。

HyperionEssbaseOLAPServer，在上面有超過100個的應用程序，有300多個用Essbase作為平臺的開發(fā)商。具有幾百個計算公式，支持過程的腳本語言，及統(tǒng)計和基于維的計算。

強大的OLAP查詢能力，利用EssbaseQueryDesigner，商業(yè)用戶可以不用IT人員的幫助自己構件復雜的查詢。

廣泛的應用支持，可以擴展數(shù)據(jù)倉庫和ERP系統(tǒng)的價值，建立對電子商務、CRM、金融、制造業(yè)、零售和CPG（consumerpackagedgoods）等應用的分析程序。

Speed-of-Thought的響應時間，支持多用戶同時讀寫

Web-Enabled的，以服務器為中心的體系結構，支持SMP

強大的合作伙伴提供完整的解決方案，60多個包裝好的解決方案，300多個咨詢和實施公司。

豐富的前端工具，有30多個前端工具可供選擇，其中包括Hyperion自己的WiredforOLAP、Spider-ManWebApplication、Objects、EssbaseSpreadsheetAdd-In、WebGateway、Reporting。

HyperionEnterprise，為跨國公司提供的財務整合、報告和分析的解決方案。有3000多家組織在使用此套系統(tǒng)。

功能豐富：支持多種財務標準USGAAP，CanadianGAAP，UKGAAP，國際會計標準（ISA），F(xiàn)ASB，HGB。分公司間交易的自動平帳。FAS52貨幣轉(zhuǎn)換。FAS94。

易用：可通過Excel，Lotus1-2-3和各種瀏覽器訪問系統(tǒng)。

支持公司結構的調(diào)整。

跨國公司的支持：同時支持6種語言及各個不同國家的法律和稅收要求。

完整的過程控制和審計跟蹤，及安全等級的設置。

能與ERP或其他數(shù)據(jù)源集成

HyperionPillar，預算和計劃工具。全球用戶超過1500家，提供基于活動的預算，基于項目的計劃，集中式計劃，銷售預測和綜合計劃。

分布式體系結構

詳細計劃的制訂：允許一線經(jīng)理制訂詳細的計劃

復雜的建模和分析能力

ExpressServer提供全面的OLAP能力，有全球超過3000家用戶

用戶可通過Web和電子表格使用

靈活的數(shù)據(jù)組織方式，數(shù)據(jù)可以存放在ExpressServer內(nèi)，也可直接在RDB上使用

有內(nèi)建的分析函數(shù)和4GL來用戶自己定制查詢

PowerPlay，為商務效率評價BPM（BusinessPerformanceMeasurement）提供全面的報告和分析環(huán)境。向決策者提供企業(yè)運行效率的各種關鍵數(shù)據(jù)，進行各種各樣的分析。

只用鼠標點擊、拖拉就可以瀏覽多維數(shù)據(jù)

自動利用Web發(fā)布得到的分析報告

支持多種OLAPServer：MicrosoftOLAPServices、HyperionEssbase、SAPBW、IBMOLAPforDB2

完備的授權和安全體系

NovaView，是MicrosoftSQLServer7.0OLAPServices的客戶端應用程序。

MicroStrategy7，是新一代的智能平臺（IntelligencePlatform）面向電子商務應用e-business和電子客戶關系管理eCRM。

具有強大的分析能力

以Web為中心的界面

支持上百萬的用戶和TB的數(shù)據(jù)

快速開發(fā)能力，可直接利用已有的數(shù)據(jù)模式

IntelligenceServer，Oneforallanalyticapplications

Microsoft SQLServer7.0OLAPServices，是SQLServer7.0的OLAP模塊，可以使用任何關系數(shù)據(jù)庫或平面文件作為數(shù)據(jù)源，其中的PivotTableService提供了客戶端的數(shù)據(jù)緩存和計算能力。

智能的Client/Server數(shù)據(jù)管理，提高響應速度，降低網(wǎng)絡流量

通過OLEDBforOLAP，允許不同的客戶端訪問

BusinessObjects，是易用的BI工具，允許用戶存取、分析和共享數(shù)據(jù)。

可應用多種數(shù)據(jù)源：RDB，ERP，OLAP，Excel等

可應用VBA和開放式對象模型來進行開發(fā)定制

DB2OLAPServer，是強大的多維分析工具，把HyperionEssbase的OLAP引擎和DB2的關系數(shù)據(jù)庫集成在一起。

與EssbaseAPI完全兼容

數(shù)據(jù)用星型模型存放在關系數(shù)據(jù)庫DB2中

Brio.Enterprise，是強大的易用的BI工具，提供查詢，OLAP分析和報告的能力

支持多種語言，包括中文

Brio.Report，強大的企業(yè)級報告工具

OLAP控件，又叫做聯(lián)機分析處理控件，是數(shù)據(jù)分析控件。在不同環(huán)境下，有不同OLAP控件。

ComponentOne OLAP for Silverlight是一款功能強大的OLAP數(shù)據(jù)分析控件，在不需要cubes的情況下創(chuàng)建交互式的表格、圖表、和報表，提供了像Microsoft Excel Pivot Tables 和Pivot Charts一樣的分析處理功能，并且該控件還包含了整個ComponentOne Studio for Silverlight控件套包。

具體功能：
　　C1OlapPanel：該控件使用DataSource屬性提供原始數(shù)據(jù)用于分析，并且具備拖拉操作可定制多種數(shù)據(jù)視圖，該控件界面和Microsoft Excel Pivot Table界面十分相似，客戶很容易上手
　　C1OlapGrid：該控件主要用于顯示OLAP表格，該控件是著名的C1FlexGrid表格控件的擴展，提供了自動數(shù)據(jù)綁定到C1OlapPanel對象，可進行列分組，調(diào)整列大小，復制數(shù)據(jù)到剪貼板，并且可顯示每個單元格的詳細信息
　　C1OlapChart：用于顯示OLAP圖表，該控件是C1Chart控件的擴展，并且也提供了自動數(shù)據(jù)綁定到C1OlapPanel，該控件提供了多種圖表類型，如：Bar, Column, Area, Line and Scatter
　　C1OlapPage：該控件主要用于面板、表格、圖表分組，以tabbed界面形式顯示，只需要拖拉page控件和設置數(shù)據(jù)源。

ComponentOne OLAP for WinForms控件提供了強大的數(shù)據(jù)分析、報表、圖表功能，分析處理功能使用起來和Microsoft Excel Pivot Tables 以及Pivot Charts很相似，通過簡單的拖拉操作，就可以在短時間內(nèi)，得到實時的信息和處理結果。

此產(chǎn)品包含在套包ComponentOne Studio Enterprise之中。

C1OlapPage控件集合了所有控件（C1OlapPanel, C1OlapGrid, C1OlapChart,和 C1OlapPrintDocument），界面跟Microsoft Excel很相似。

C1OlapGrid控件用于顯示OLAP數(shù)據(jù)表，該控件對C1FlexGrid進行了擴展，可以自動綁定數(shù)據(jù)到C1OlapPanel，可以進行列大小調(diào)整、復制數(shù)據(jù)到剪貼板。

可以查看每個單元格背后的潛在數(shù)據(jù)，通過右鍵點擊該單元格

C1OlapChart用于顯示聯(lián)機分析圖表，該控件對C1Chart進行了擴展，提供了自動數(shù)據(jù)綁定到C1OlapPanel對象，自動地提示、圖表類型、顏色選擇

可以很容易地通過拖拉相應的字段到列表來創(chuàng)建數(shù)據(jù)視圖

支持快速地打印和郵寄報表，C1OlapPrintDocument控件用于創(chuàng)建基于OLAP視圖的報表，控件擴展了PrintDocument并且提供了屬性，為OLAP 表格、圖表、原始數(shù)據(jù)指定內(nèi)容來用于創(chuàng)建報表，可以實時地預覽數(shù)據(jù)，打印和導出為PDF格式

使用過濾功能來減少數(shù)據(jù)分析，可以進行多個字段的過濾，過濾設置，自定義過濾等

多種數(shù)據(jù)格式：小數(shù)、貨幣、百分比等，或者創(chuàng)建自定義格式

支持數(shù)據(jù)轉(zhuǎn)移到Excel：C1OlapGrid支持剪貼板操作，您可以選擇感興趣的數(shù)據(jù)，復制到Excel里

支持ReadXml和 WriteXml

支持自定義操作界面