摘要

資料倉庫和聯機分析處理（OLAP）是決策支援基本要素，已經日益成為資料庫行業的重點。許多商業產品和服務現已推出，並且所有主要的資料庫管理系統供應商現在已經在這些領域提供產品。決策支援，相比於傳統的聯機事務處理應用程式，會有些不同的要求資料庫技術。本文提供的資料概述資料倉庫和OLAP技術，著眼於他們的新的要求。我們描述後端工具來提取，清潔和資料載入到資料倉庫;典型OLAP的多維資料模型;前端客戶端工具用於查詢和資料分析;伺服器擴充套件來高效的查詢處理;用來管理元資料和倉庫工具。此外，勘測技術現狀，本文還指出了一些有前景的研究問題，其中一些涉及資料庫研究界合作多年的研究的問題，但其他一些問題只是剛剛開始被解決。本概述是基於一個教程，有作者們在會議VLDB 1996年提出。

1. 介紹

資料倉庫是決策支援技術的集合，旨在使知識工作者（總裁，經理，分析師）做出更快更好的決策。過去三年已經看到的爆炸性的增長，無論是在所提供的產品和服務的數量，還是在採用這些技術的工業領域。按照META集團說法，資料倉庫市場，包括硬體，資料庫軟體和工具，預計是由1995年的20億美金增長到1998年分80億美金。資料倉庫技術已經成功部署在許多行業：製造業（訂單運輸和客戶支援），零售（用於使用者分析和庫存管理），金融服務（理賠分析，風險分析，信用卡分析和欺詐檢測），交通（車隊管理），電信（呼叫分析和欺詐檢測），公用事業（電力使用分析）和醫療保健（對於結果的分析）。本文介紹了資料倉庫技術的路線圖，著重於有特殊需求的資料倉庫資料庫管理系統（DBMS）。

資料倉庫是一個“面向主題的，整合的，隨時間變化的，非易失性的，主要用於組織決策的資料集合。 ”通常情況下，資料倉庫用來分別維護組織的不同業務的資料庫。有很多原因來這麼做。資料倉庫支援線上分析處理（OLAP ），它的功能和效能要求完全不同於由業務資料庫所支援的聯機事務處理（ OLTP）應用程式。

OLTP應用程式通常使得文書資料處理任務自動化，如訂單錄入和銀行交易等一些組織的日常運作。這些任務是結構化和重複性，以及由短的，原子，孤立的交易。該交易需要詳細，最新的資料，通常通常訪問他們的主鍵來讀取或更新少數（幾十）記錄。操作資料庫往往是百兆到千兆位元組。資料庫的一致性和可恢復性是至關重要的，最大化事務吞吐量是關鍵效能指標。因此，資料庫被設計為反映已知的應用，特別是的操作語義，以儘量減少併發衝突。

資料倉庫，相反的，是有針對性的決策支援。歷史，總結和整合的資料比詳細的，個人記錄更重要。由於資料倉庫包含合併資料，或許可以從幾個業務資料庫，在一段時間可能很長的時期，他們往往要比業務資料庫較大的訂單;企業資料倉庫預計為數百GB到TB級大小。工作負載大多是查詢密集型與臨時性的，複雜查詢可以訪問數以百萬計的記錄，並進行了大量的掃描，聯接和聚合。查詢吞吐量和響應時間比事務吞吐量更重要。

促進複雜的分析和視覺化、資料倉庫通常多維建模。例如,在一個銷售資料倉庫,銷售,銷售區域、銷售人員和產品可能是一些感興趣的維度。通常,這些維度是分層次的;銷售時間可能是組織為day-month-quarter-year的層次結構,產品作為product-category-industry的層次結構。典型的OLAP操作包括上鑽(增加聚合的水平)和下鑽(減少聚合的水平或增加細節)以及一個或多個維度層次結構切割(選擇和投影),軸轉(調整的多維檢視的資料)。

由於已有的業務資料庫已經很好的支援已知的OLTP工作負載，所以試圖對業務資料庫執行復雜的OLAP查詢，將導致不可接受的效能。此外，決策支援需求的資料可能從業務資料庫中丟失;例如，瞭解趨勢或進行預測所需要歷史資料，而業務資料庫只儲存當前的資料。決策支援一般需要從多個不同來源的資料進行整合：這可能包括外部資源，如股票的市場反饋需要額外的幾個業務資料庫。不同的來源可能含有不同質量的資料，或使用不一致的陳述，程式碼和格式，需要協調。最後，支援多維資料模型和操作的典型OLAP需要特殊的資料組織，訪問方式和實現方法，不是如一般的商業資料庫管理系統用來針對OLTP。由於這些原因，資料倉庫的實現有別於業務資料庫。

資料倉庫可能會實施在標準的或擴充套件的關係DBMS 上，就是所謂關係型OLAP（ROLAP ）伺服器。這些伺服器假設資料儲存在關係資料庫，並且支援擴充套件SQL和特殊訪問及實施方法來有效實現多維資料模型和操作。相比之下，多維OLAP （ MOLAP）伺服器直接把多維資料儲存在特定的資料結構（例如，陣列），並實現了OLAP在這些特點的資料結構的操作。

這不僅僅是建設和維護一個數據倉庫，還需要選擇一個OLAP伺服器併為倉庫明確模式和一些複雜的查詢。存在著不同結構的替代品。許多組織希望實施綜合性企業的倉庫，收集跨越整個組織的所有科目（例如，客戶，產品資訊，銷售，資產，人員）。然而，構建企業級資料倉庫是一個漫長而複雜的過程，需要廣泛的業務建模，可能需要多年才能成功。相反的，一些組織滿足於資料集市，它是針對選定的科目的子集（例如，營銷資料可能包括客戶，產品和銷售資訊） 。這些資料集市實現更快的推算，因為它們不需要企業廣泛的共識，但如果一個完整的商業模式並不發達的話，從長遠來看，它們可能會導致複雜的整合問題。

在第2節，我們描述了一個典型的資料倉庫體系結構，和設計和操作資料倉庫的過程。在3-7節，我們回顧了在資料載入相關技術和重新整理資料倉庫，倉庫伺服器，前端工具和倉庫管理工具。在每一種情況下，我們指出什麼是傳統的資料庫技術不同的，我們會提到有代表性的產品。在本文中，我們不打算提供每個類別的所有產品的綜合描述。我們鼓勵有興趣的讀者看看在最近的商業雜誌，如Databased Advisor, Database Programming，Design, Datamation，DBMS Magazine, vendors’ Web sites來獲取商業產品，白皮書和案例研究的更多細節。OLAP Council是在整個行業的標準化工作上一個很好的資訊源。還有科德等人的論文定義了OLAP產品的12條規則。還有，Data Warehousing Information Center是資料倉庫和OLAP良好的資源。

資料倉庫的研究是相當新的，並一直專注的主要是查詢處理和檢視維護問題。還有很多開放性的研究問題，在第8節，我們會簡要提及的這些問題並得出結論。

2. 架構與端到端流程

圖1是一個典型的資料倉庫架構。

它包括一些工具。這些工具可以用來從多種操作資料庫和外部源中提取資料，並清洗、轉換和整合這些資料，然後把資料載入到資料倉庫;定期重新整理倉庫來更新的源和清除倉庫的資料,或者是慢歸檔儲存。除了主倉庫,可能會有好幾個部門資料集市。儲存在資料倉庫和資料集市的資料，由一個或多個倉庫伺服器管理，並呈現資料的多維檢視給不同的前端工具，如:查詢工具、報告作者、分析工具和資料探勘工具。最後,還有一個儲存庫,用於儲存和管理元資料,併為監測和管理倉儲系統。

倉庫可能被設計成分散式，以來得到負載均衡,可伸縮性和高可用性。在這樣一個分散式體系結構，元資料儲存庫通常是在每個節點的倉庫都進行備份的,整個倉庫集中管理的。另一個體繫結構,是倉庫或資料集市的聯合，每個倉庫或者資料集市都有自己的貯存和分級管理。該設計實現力求使用方便，所以可能花費過於昂貴的代價來構造一個邏輯整合的企業倉庫。

設計和推出一個數據倉庫是一個複雜的過程,包括以下活動：

• 定義體系結構,容量規劃,並選擇儲存伺服器、資料庫和OLAP伺服器和工具。
• 整合伺服器、儲存和客戶端工具。
• 設計倉庫表和檢視。
• 定義物理倉庫組織，資料佈局、分割槽和訪問方法。
• 使用閘道器、ODBC驅動程式,或其他的包裝器連線資料來源,。
• 設計和實現資料提取、清洗、轉換、載入和重新整理的指令碼。
• 貯存表和檢視的定義、指令碼和其他元資料。
• 設計和實現終端使用者應用程式。
• 推出倉庫和應用程式。

3. 後端工具和實用程式

資料倉庫系統使用各種資料提取和清洗工具,錄入倉庫的載入和更新的實用程式。通常外來源的資料提取的實現需要通過閘道器和標準介面(如Information Builders EDA/SQL, ODBC, Oracle Open Connect, Sybase Enterprise Connect, Informix Enterprise Gateway)。

資料清洗

由於資料倉庫是用於決策,資料倉庫中的資料正確性的非常重要的。然而,因為大量的資料來自多個參與的資料來源,資料中出現錯誤和異常的概率很高。因此,幫助檢測資料的異常和對其改正的工具，可以帶來很高高效益。在一些情況下，資料清洗顯得非常有必要:欄位長度不一致,不一致的描述,不一致的價值分配,缺失的條目和違背完整性約束。可想而知,資料錄入表中的可選欄位是不一致資料的重要來源。

有三個相關,但不同的類資料清理工具。資料遷移工具可以制定簡單轉換規則,例如,用性別種類來替換性別字串。Prism的Warehouse Manager是這種型別的工具中比較流行的一個。資料清理工具使用特定領域的知識(如郵政地址)來對資料進行清理。他們經常利用解析和模糊匹配技術來完成來著多個源的清洗。一些工具可以指定源的“相對清洗”。 Integrity和Trillum等工具屬於此類。資料審計工具可以通過掃描資料從而發現規則和關係(或提醒違背了規定的規則)。因此,這樣的工具可以認為是資料探勘工具的變體。這樣的工具可能會發現一個可疑的樣本(基於統計分析)，例如，某汽車經銷商從未收到任何投訴。

載入

提取、清洗和轉換後,資料必須被載入到倉庫。額外的預處理可能仍然被需要:檢查完整性約束;排序;通過總結、聚合和其他計算來建立儲存在倉庫中的派生表;建立目錄和其他訪問路徑;分割槽實現多個目標儲存區域。通常情況下,批量裝載工具可以用來做這件事。除了填充倉庫,一個負載工具必須允許系統管理員監控狀態,取消、掛起和恢復一個負載,失敗後重啟而沒有損失資料的完整性。

資料倉庫的載入工具必須處理比操作資料庫更大規模的資料量。只有一個小時間視窗中(通常在晚上)，倉庫可以離線重新整理它。連續載入會花費很長的時間,例如。,可以載入TB級的資料會花幾周和幾個月時間！因此,通常需要利用管線式和分割槽式的並行性。進行一個滿載的優勢在於它可以被視為一個長的批處理事務，來建立一個新的資料庫。雖然在執行中,但是當前資料庫仍然可以支援查詢;當負載事務提交時,當前資料庫被新的資料庫所取代。使用週期檢查點保證，如果載入過程中發生了失敗,這個程序可以從上個檢查點重啟。

然而,即使使用並行性,一個滿載可能仍然需要太長的時間。大多數商業工具(如,RedBrick Table Management Utility)在重新整理過程中使用增量載入，來降低必須被納入倉庫的資料規模。只插入更新的元組。然而,這樣的載入過程更加難以管理了。增量載入會與正在進行的查詢起衝突,所以它被作為一個短事務(定期提交，如，每隔1000個記錄或每隔幾秒),但這樣一來這個事務的序列必須被設計，來確保匯出資料與基礎資料的索引的一致性。