| OLAP：聯機分析處理 | |
| （OLAP：Online Analytical Processing） |
|
聯機分析處理（OLAP）指的是對存儲在數據庫或數據倉庫中的數據提供分析的一種軟件。OLAP 工具能快速提供複雜數據庫查詢的答案，並幫助用戶分析多維數據中的各維情況。通常 OLAP 應用於數據倉庫中的數據處理過程，即所謂的“數據挖掘”（Data Mining）。 關係數據庫中，是將經過規範化的實體存放在分散的表格中。該結構非常適用於操作型數據庫，但該結構對於複雜的、包含多個表的查詢，速度相對較慢。多維數據庫是一種更好的查詢模式，但其操作性能較差。 OLAP 的主要組成部件是 OLAP 服務器，它位於客戶機和數據庫管理系統（DBMS）之間。OLAP 服務器清楚數據如何被組織成數據庫，並具有關於數據分析的特定功能。例如，OLAP 軟件獲取關係數據庫的一個映像後，重新構建一個多維數據，然後便可重新對此查詢。 由操作型數據創建而來的 OLAP 結構被稱之爲 OLAP 數據集（OLAP cube）。OLAP 數據集中可能包含每個查詢的所有答覆。OLAP 數據集採用的星型模式指：事實表列出關鍵事實，然後由中心進行查詢的一種方式。大量的維度表與事實表相鏈接。爲避免計算所有可能的數集，所以只對預先確定的數進行完全的計算，其它的作爲備用。 OLAP 具有三種類型：
實現 OLAP 的主要難點是查詢構成、基本數據選擇和模式開發。這使得大多數現代 OLAP 產品與大型預置查詢庫結合使用。另一個問題是基本數據必須完全一致。 |
|
OLAP：聯機分析處理 |
應用OLAP,你可以向數據倉庫提問,"如果糖漿價格每加侖上升0.10美元,而運輸費用每英
裏下降0.05美元,那麼對軟飲料分銷商有什麼影響?"
OLAP和數據倉庫是互爲補充的。OLAP系統不但可以回答"是誰"、"是什麼"等問題,還可
以回答"如果...是什麼"、"爲什麼"等問題,這正是它強於數據倉庫的地方。數據倉庫存儲和
管理數據,OLAP則把數據倉庫裏的數據轉換爲策略性的信息。
在這篇文章裏,我們要定義什麼是聯機分析處理(OLAP,On-Line Analytical Processig
),講述誰需要用聯機分析處理和爲什麼要用聯機分析處理。
什麼是OLAP
在過去十年中,有相當大比例的公共數據已經轉向用關係數據庫管理。關係數據庫在操
作和控制領域用得尤其廣泛,如製造過程控制、代理貿易,這些領域特別強調事務處理。爲了
使關係數據庫成功地用於這些領域,數據庫廠商們花費了很多精力使關係數據庫能夠高效處
理大量事務,並且有很強的數據容錯能力。
最近以來,關係數據庫廠商們已經開始把他們的數據庫當作建造數據倉庫的工具來銷售
。數據倉庫策略性地存儲信息,可以回答有關過去事件的"誰"和"什麼"等問題,如提交給數據
倉庫的一個典型查詢是:"在第三季度東部區域的總收入是多少?"
把數據倉庫的功能和OLAP系統的功能區分開來是很重要的。數據倉庫一般建立在關係數
據模型的基礎上,而OLAP則是從多角度、多方面來觀察、處理作爲一個整體存在的數據,爲進
一步的分析迅速提供所需的信息。
OLAP要對原始的數據進行轉換,使數據以人們易於理解的形式真實地反映事物本身。通
過OLAP,分析人員、管理人員和執行人員可以從廣泛的角度快捷、緊湊地交互訪問各自所需
的信息,有利於對未來的行動作出決定。
OLAP的功能很廣,有基本的導航和瀏覽功能,有計算功能,還有更爲重要的分析功能,如時
間安排和複雜建模等。決策者要利用OLAP高級功能,他們要求的東西不僅僅是數據訪問,而是
更爲高級的策略性信息和知識。一個典型的OLAP計算比簡單的數據累加要複雜得多,如
"如果糖漿價格每加侖上升0.10美元而運輸費用每英里下降0.05美元,那麼對軟飲料分銷
商有什麼影響?"
誰需要OLAP
OLAP應用適用於不同的部門。財政部門可以利用OLAP進行預算、行動花費(調撥)、財政
性能分析和財政建模等;銷售部門可以利用OLAP進行銷售分析和預測;市場部門可以利用OLA
P進行市場調查分析、銷售預測、促銷分析、顧客分析和市場/顧客羣體劃分等。製造部門利
用OLAP的典型例子是產品計劃和故障分析。
在上面所有OLAP應用中,最重要的一點就是在管理人員作出決策時向他們提供所需的信
息,因此判斷一個OLAP應用是否成功的關鍵一點就是其提供所需信息的能力,如它爲決策提供
實時信息的能力。要做到這一點,就不可能只是簡單地提供一些數據。
實時信息是反映複雜關係的計算後數據,如計算飛機飛行時的參數得到的數據。一般情
況下,只有計算反應時間相當短時,對複雜關係的分析與建模纔有實際意義。另外,由於對數
據關係的特性事先可能並不知道,因此還要求數據模型有改變的靈活性。一種真正靈活的數
據模型使OLAP系統能夠對變化的業務要求作出反應,以滿足決策的需要。
雖然OLAP應用能夠用於各式各樣的場合,但它們都有下面幾個關鍵特性:對數據的多維觀
察、密集型計算能力和時間智能。
對數據的多維觀察
多維觀察是實際業務模型固有的要求,很少有少於三維的業務模型。例如,管理人員在查
看財務數據時,他會看總表(如實際支出與預算的比較)、分類表、單獨執行項目和時間等
查看銷售數據時,會看產品情況、地理分佈、銷售渠道和時間等數據。通過對數據的多
維觀察,OLAP應用能夠更靈活地訪問數據,爲對事情的分析處理提供良好的基礎。設計數據庫
時不再需要事先考慮可以對哪些數據進行哪些操作,這些操作速度如何等等問題。管理人員
可以從任何角度、對任何集合的數據進行分析,並且這些分析操作的功能和使用方便程度都
一樣。
OLAP軟件從一種自然的、合乎人的思維心理的角度來觀察數據,用戶不必考慮那些復
雜的查詢語法。畢竟,管理者們沒有必要去理解複雜的表格安排、精巧的表連接和概括
表等技術問題。
某種產品在所有地理區域各周的銷售情況如何?特定產品在某個城市每天銷售情況如何
?對類似上面這樣的查詢,OLAP必須有固定的反應時間。下面這些情況是不可接受的:管理者
們爲了提交複雜的查詢,必須要費大力編寫查詢命令;或者提交複雜查詢後,要等很長時間才
有答覆。
複雜計算
對OLAP數據庫的真正考驗是其提供複雜計算的能力,OLAP數據庫要做的決不僅僅是對數
據簡單歸併。對分析過程來說,常需要對數據進行深入的加工,把數據簡單陳列給管理人員是
不夠的。複雜計算的例子有份額計算(佔總數的百分之多少)、分配(要用到從頂端往下層的
等級結構圖)等。
關鍵的行爲指示因子常常要用到代數方程。銷售預測要用到趨勢代數式子,如移動平均
線、百分比增長等。分析一個特定公司與其競爭對手的銷售和促銷情況需要對各公司的複雜
關係建立模型。真實的世界是複雜的——在分析處理應用程序中,對複雜關係的建模是關鍵
所在。
OLAP軟件應該提供豐富多樣、功能強大的分析工具,但同時計算方法又應該簡單明瞭。
爲了使開發者能高效地進行開發,使商業用戶能積極主動使用OLAP軟件滿足自己的要求,計算
方法應該清楚,並且是非過程(nonprocedural)的。如果產生計算結果的方法不清楚,那麼開
發和使用都將是一件受折磨的事情。如果計算方法是過程化的,那麼對系統的改變將不能及
時完成,並且也不能訪問即時信息。
評價事務處理系統好壞的標準是其收集和管理數據的能力,而評價分析處理系統好壞的
標準則是其從數據得出信息的能力。
時間智能
對任何分析應用程序來說,時間都是不可缺少的一個因素。時間只有一維,因爲它只能從
前往後延伸。那些真正的OLAP系統應該理解時間的這種序列特性。商業行爲幾乎肯定要根據
時間來作出判斷。
時間數量和其他因素的數量在使用上並不會是一樣的。例如,一個管理人員可能會要求
看五月份的銷售情況,或者看1995年頭五個月的銷售情況;他還可能會看藍襯衫的銷售情況但
他幾乎不可能會要求看頭五件襯衫的銷售情況。在OLAP系統中,不同年份的同期比較和同一
年份的期間比較應該很容易定義。
另外,OLAP系統還必須理解時間平衡這個概念。例如,一個公司賣襯衫,一月份賣了10件
,二月份賣了5件,而三月份又賣了10件,那麼這個季度總的平衡銷售量是25件襯衫。另一方面
,一個公司一月份招進了10名員工,二月份只招進了5名,三月份又招進了10名,那麼這個季度
員工增加量是多少呢?大多數公司都會用平均平衡量。在資金方面,大多數公司都用最後平衡
量。
OLAP的好處
成功的OLAP應用程序會提高商業管理人員、開發人員和整個公司的生產效率。OLAP系統
與生俱來的靈活性意味着OLAP應用程序的用戶能夠更加積極主動地利用系統滿足自己的要求
。管理人員不必再依靠IT人員來改變自己的業務綱要,來創立連接,或者來滿足自己的其他要
求。
OLAP使得管理人員可以對一些問題建立模型,對那些策略性的信息更有效、更及時的訪
問也就等於更有效的決策。而那些缺乏靈活性的系統由於有漫長並且不固定的反應時間,因
而無法用於這一方面。
IT開發人員也可以從合適的OLAP軟件中得到好處。如果使用專門爲OLAP設計的軟件,那
麼開發人員可以更快地向商業用戶發佈應用程序,可以更好地提供服務。
OLAP可以使商業用戶建立他們自己的業務模型,這可以進一步減少應用程序積壓未交付
量。
不過,不像PC網絡上運行的獨立的部門應用程序,OLAP應用程序要依靠數據倉庫和事務處
理系統來刷新原始數據。結果是,IT部門得到了更爲積極主動的用戶,使得對用戶的支持工作
負擔大爲減少,但同時又沒有放棄對數據完整性的控制。
通過OLAP,IT部門還可以實現更有效率的操作。應用爲OLAP設計的軟件,IT部門減少了對
事務系統或數據倉庫的查詢和網絡流量。
最後,通過提供對實際商業問題建立模型的能力和對人力資源更有效的使用,OLAP還可以
使公司作爲一個整體對市場需求更快地作出反應。(編寫 正一)
|
聯機分析處理 (OLAP) 的概念最早是由關係數據庫之父E.F.Codd於1993年提出的，他同時提出了關於OLAP的12條準則。OLAP的提出引起了很大的反響，OLAP作爲一類產品同聯機事務處理 (OLTP) 明顯區分開來。
當今的數據處理大致可以分成兩大類： 聯機事務處理OLTP（On-Line Transaction Processing） 聯機分析處理OLAP（On-Line Analytical Processing） OLTP是傳統的關係型數據庫的主要應用，主要是基本的、日常的事務處理，例如銀行交易。 OLAP是數據倉庫系統的主要應用，支持複雜的分析操作，側重決策支持，並且提供直觀易懂的查詢結果。下表列出了OLTP與OLAP之間的比較。
OLAP是使分析人員、管理人員或執行人員能夠從多角度對信息進行快速、一致、交互地存取,從而獲得對數據的更深入瞭解的一類軟件技術。OLAP的目標是滿足決策支持或者滿足在多維環境下特定的查詢和報表需求,它的技術核心是"維"這個概念。 “維”是人們觀察客觀世界的角度,是一種高層次的類型劃分。“維”一般包含着層次關係,這種層次關係有時會相當複雜。通過把一個實體的多項重要的屬性定義爲多個維(dimension)，使用戶能對不同維上的數據進行比較。因此OLAP也可以說是多維數據分析工具的集合。 OLAP的基本多維分析操作有鑽取（roll up和drill down）、切片（slice）和切塊（dice）、以及旋轉（pivot）、drill across、drill through等。 ·鑽取是改變維的層次，變換分析的粒度。它包括向上鑽取（roll up）和向下鑽取（drill down）。roll up是在某一維上將低層次的細節數據概括到高層次的彙總數據，或者減少維數；而drill down則相反，它從彙總數據深入到細節數據進行觀察或增加新維。 ·切片和切塊是在一部分維上選定值後，關心度量數據在剩餘維上的分佈。如果剩餘的維只有兩個，則是切片；如果有三個，則是切塊。 ·旋轉是變換維的方向，即在表格中重新安排維的放置（例如行列互換）。 OLAP有多種實現方法，根據存儲數據的方式不同可以分爲ROLAP、MOLAP、HOLAP。 ROLAP表示基於關係數據庫的OLAP實現（Relational OLAP）。以關係數據庫爲核心,以關係型結構進行多維數據的表示和存儲。ROLAP將多維數據庫的多維結構劃分爲兩類表:一類是事實表,用來存儲數據和 維關鍵字;另一類是維表,即對每個維至少使用一個表來存放維的層次、成員類別等維的描述信息。維表和事實表通過主關鍵字和外關鍵字聯繫在一起,形成了"星 型模式"。對於層次複雜的維,爲避免冗餘數據佔用過大的存儲空間,可以使用多個表來描述,這種星型模式的擴展稱爲"雪花模式"。 MOLAP表示基於多維數據組織的OLAP實現（Multidimensional OLAP）。以多維數據組織方式爲核心,也就是說,MOLAP使用多維數組存儲數據。多維數據在存儲中將形成"立方塊（Cube）"的結構,在MOLAP 中對"立方塊"的"旋轉"、"切塊"、"切片"是產生多維數據報表的主要技術。 HOLAP表示基於混合數據組織的OLAP實現（Hybrid OLAP）。如低層是關係型的，高層是多維矩陣型的。這種方式具有更好的靈活性。 還有其他的一些實現OLAP的方法，如提供一個專用的SQL Server，對某些存儲模式（如星型、雪片型）提供對SQL查詢的特殊支持。 OLAP將數據分爲兩種特徵，一種爲表現特徵，比如一個銷售分析模型中的銷售額、毛利等；還有一種爲角度特徵，比如銷售分析中的時間週期、產品類型、銷 售模式、銷售區域等。前者是被觀察的對象，OLAP術語稱之爲“度量數據”，後者爲觀察視角，OLAP術語稱之爲“維數據”。 |
 聯機分析處理，英文名稱爲On-Line Analysis Processing，簡寫爲OLAP。隨着數據庫技術的發展和應用，數據庫存儲的數據量從20世紀80年代的兆（M）字節及千兆（G）字節過渡到現在的兆兆（T）字節和千兆兆（P）字節，同時，用戶的查詢需求也越來越複雜，涉及的已不僅是查詢或操縱一張關係表中的一條或幾條記錄，而且要對多張表中千萬條記錄的數據進行數據分析和信息綜合，關係數據庫系統已不能全部滿足這一要求。操作型應用和分析型應用，特別是在性能上難以兩全，人們常常在關係數據庫中放寬了對冗餘的限制，引入了統計及綜合數據，但這些統計綜合數據的應用邏輯是分散而雜亂的、非系統化的，因此分析功能有限，不靈活，維護困難。在國外，不少軟件廠商採取了發展其前端產品來彌補關係數據庫管理系統支持的不足，他們通過專門的數據綜合引擎，輔之以更加直觀的數據訪問界面，力圖統一分散的公共應用邏輯，在短時間內響應非數據處理專業人員的複雜查詢要求。1993年，E.F.Codd（關係數據庫之父）將這類技術定義爲“聯機分析處理”。 聯機分析處理是共享多維信息的、針對特定問題的聯機數據訪問和分析的快速軟件技術。它通過對信息的多種可能的觀察形式進行快速、穩定一致和交互性的存取，允許管理決策人員對數據進行深入觀察。決策數據是多維數據，多維數據就是決策的主要內容。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 一、OLAP的發展背景 隨着數據庫技術的廣泛應用，企業信息系統產生了大量的數據，如何從這些海量數據中提取對企業決策分析有用的信息成爲企業決策管理人員所面臨的重要難題。傳統的企業數據庫系統（管理信息系統）即聯機事務處理系統（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人員的工作量相當大，而且往往難以跟上管理決策人員思考的步伐。 聯機分析處理的主要特點，是直接仿照用戶的多角度思考模式，預先爲用戶組建多維的數據模型，在這裏，維指的是用戶的分析角度。例如對銷售數據的分析，時間週期是一個維度，產品類別、分銷渠道、地理分佈、客戶羣類也分別是一個維度。一旦多維數據模型建立完成，用戶可以快速地從各個分析角度獲取數據，也能動態的在各個角度之間切換或者進行多角度綜合分析，具有極大的分析靈活性。這也是聯機分析處理在近年來被廣泛關注的根本原因，它從設計理念和真正實現上都與舊有的管理信息系統有着本質的區別。 事實上，隨着數據倉庫理論的發展，數據倉庫系統已逐步成爲新型的決策管理信息系統的解決方案。數據倉庫系統的核心是聯機分析處理，但數據倉庫包括更爲廣泛的內容。 -概括來說，數據倉庫系統是指具有綜合企業數據的能力，能夠對大量企業數據進行快速和準確分析，輔助做出更好的商業決策的系統。它本身包括三部分內容： 數據層。實現對企業操作數據的抽取、轉換、清洗和彙總，形成信息數據，並存儲在企業級的中心信息數據庫中。 應用層。通過聯機分析處理，甚至是數據挖掘等應用處理，實現對信息數據的分析。 表現層。通過前臺分析工具，將查詢報表、統計分析、多維聯機分析和數據發掘的結論展現在用戶面前。 從應用角度來說，數據倉庫系統除了聯機分析處理外，還可以採用傳統的報表，或者採用數理統計和人工智能等數據挖掘手段，涵蓋的範圍更廣；就應用範圍而言，聯機分析處理往往根據用戶分析的主題進行應用分割，例如：銷售分析、市場推廣分析、客戶利潤率分析等等，每一個分析的主題形成一個OLAP應用，而所有的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系統按照其存儲器的數據存儲格式可以分爲關係OLAP（RelationalOLAP，簡稱ROLAP）、多維OLAP（MultidimensionalOLAP，簡稱MOLAP）和混合型OLAP（HybridOLAP，簡稱HOLAP）三種類型。 1.ROLAP ROLAP將分析用的多維數據存儲在關係數據庫中並根據應用的需要有選擇的定義一批實視圖作爲表也存儲在關係數據庫中。不必要將每一個SQL查詢都作爲實視圖保存，只定義那些應用頻率比較高、計算工作量比較大的查詢作爲實視圖。對每個針對OLAP服務器的查詢，優先利用已經計算好的實視圖來生成查詢結果以提高查詢效率。同時用作ROLAP存儲器的RDBMS也針對OLAP作相應的優化，比如並行存儲、並行查詢、並行數據管理、基於成本的查詢優化、位圖索引、SQL的OLAP擴展(cube,rollup)等等。 2.MOLAP MOLAP將OLAP分析所用到的多維數據物理上存儲爲多維數組的形式，形成“立方體”的結構。維的屬性值被映射成多維數組的下標值或下標的範圍，而總結數據作爲多維數組的值存儲在數組的單元中。由於MOLAP採用了新的存儲結構，從物理層實現起，因此又稱爲物理OLAP（PhysicalOLAP）；而ROLAP主要通過一些軟件工具或中間軟件實現，物理層仍採用關係數據庫的存儲結構，因此稱爲虛擬OLAP（VirtualOLAP）。 3.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的具體實施方法進行討論： 1、關係型聯機分析處理的具體實施方法： 顧名思義，關係型聯機分析處理是以關係型數據庫爲基礎的。唯一特別之處在於聯機分析處理中的數據結構組織的方式。 讓我們考察一個例子，假設我們要進行產品銷售的財務分析，分析的角度包括時間、產品類別、市場分佈、實際發生與預算四方面內容，分析的財務指標包括：銷售額、銷售支出、毛利(=銷售額-銷售支出)、費用、純利(=毛利-費用)等內容，則我們可以建立如下的數據結構： 該數據結構的中心是主表，裏面包含了所有分析維度的外鍵，以及所有的財務指標，可計算推導的財務指標不計在內，我們稱之爲事實表(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 操作，這樣來取得性能和管理複雜度之間的均衡。 2、多維聯機分析處理的具體實施方法： 多維聯機分析處理實際上是用多維數組的方式對關係型數據表進行處理。下圖是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多數用於部門級的主題分析應用。 3、其它考慮因素 聯機分析處理其他要素包括假設分析(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系統時，既要考慮產品內部的實現機制，同時也應考慮假設分析，複雜計算，數據評估方面的功能，爲實現決策管理信息系統打下堅實的基礎。 六、主要OLAP廠商產品介紹 Hyperion HyperionEssbaseOLAPServer，在上面有超過100個的應用程序，有300多個用Essbase作爲平臺的開發商。具有幾百個計算公式，支持過程的腳本預言，及統計和基於維的計算。 強大的OLAP查詢能力，利用EssbaseQueryDesigner，商業用戶可以不用IT人員的幫助自己構件複雜的查詢。 廣泛的應用支持，可以擴展數據倉庫和ERP系統的價值，建立對電子商務、CRM、金融、製造業、零售和CPG（consumerpackagedgoods）等應用的分析程序。 Speed-of-Thought的響應時間，支持多用戶同時讀寫 Web-Enabled的，以服務器爲中心的體系結構，支持SMP 強大的合作伙伴提供完整的解決方案，60多個包裝好的解決方案，300多個諮詢和實施公司。 豐富的前端工具，有30多個前端工具可供選擇，其中包括Hyperion自己的WiredforOLAP、Spider-ManWebApplication、Objects、EssbaseSpreadsheetAdd-In、WebGateway、Reporting。 HyperionEnterprise，爲跨國公司提供的財務整合、報告和分析的解決方案。有3000多家組織在使用此套系統。 功能豐富：支持多種財務標準USGAAP，CanadianGAAP，UKGAAP，國際會計標準（ISA），FASB，HGB。分公司間交易的自動平帳。FAS52貨幣轉換。FAS94。 易用：可通過Excel，Lotus1-2-3和各種瀏覽器訪問系統。 支持公司結構的調整。 跨國公司的支持：同時支持6種語言及各個不同國家的法律和稅收要求。 完整的過程控制和審計跟蹤，及安全等級的設置。 能與ERP或其他數據源集成 HyperionPillar，預算和計劃工具。全球用戶超過1500家，提供基於活動的預算，基於項目的計劃，集中式計劃，銷售預測和綜合計劃。 分佈式體系結構 詳細計劃的制訂：允許一線經理制訂詳細的計劃 複雜的建模和分析能力 Oracle ExpressServer提供全面的OLAP能力，有全球超過3000家用戶 用戶可通過Web和電子表格使用 靈活的數據組織方式，數據可以存放在ExpressServer內，也可直接在RDB上使用 有內建的分析函數和4GL來用戶自己定製查詢 Cognos PowerPlay，爲商務效率評價BPM（BusinessPerformanceMeasurement）提供全面的報告和分析環境。向決策者提供企業運行效率的各種關鍵數據，進行各種各樣的分析。 只用鼠標點擊、拖拉就可以瀏覽多維數據 自動利用Web發佈得到的分析報告 支持多種OLAPServer：MicrosoftOLAPServices、HyperionEssbase、SAPBW、IBMOLAPforDB2 完備的授權和安全體系 NovaView，是MicrosoftSQLServer7.0OLAPServices的客戶端應用程序。 MicroStrategy MicroStrategy7，是新一代的智能平臺（IntelligencePlatform）面向電子商務應用e-business和電子客戶關係管理eCRM。 具有強大的分析能力 以Web爲中心的界面 支持上百萬的用戶和TB的數據 快速開發能力，可直接利用已有的數據模式 IntelligenceServer，Oneforallanalyticapplications Microsoft SQLServer7.0OLAPServices，是SQLServer7.0的OLAP模塊，可以使用任何關係數據庫或平面文件作爲數據源，其中的PivotTableService提供了客戶端的數據緩存和計算能力。 智能的Client/Server數據管理，提高響應速度，降低網絡流量 通過OLEDBforOLAP，允許不同的客戶端訪問 BusinessObjects BusinessObjects，是易用的BI工具，允許用戶存取、分析和共享數據。 可應用多種數據源：RDB，ERP，OLAP，Excel等 可應用VBA和開放式對象模型來進行開發定製 IBM DB2OLAPServer，是強大的多維分析工具，把HyperionEssbase的OLAP引擎和DB2的關係數據庫集成在一起。 與EssbaseAPI完全兼容 數據用星型模型存放在關係數據庫DB2中 Brio Brio.Enterprise，是強大的易用的BI工具，提供查詢，OLAP分析和報告的能力 支持多種語言，包括中文 Brio.Report，強大的企業級報告工具 OLAP相關標準 APB-1OLAPBenchmarkReleaseII(SPONSOREDBYOLAPCOUNCIL) |