資料倉庫 - 快速指南

---

---

資料倉庫 - 概述

“資料倉庫”一詞最早由Bill Inmon於1990年提出。根據Inmon的定義，資料倉庫是面向主題的、整合的、隨時間變化的、非易失性的資料集合。這些資料幫助分析人員在組織中做出明智的決策。

運營資料庫每天都會因為發生的交易而頻繁變化。假設一位企業高管想要分析以往關於任何資料的反饋，例如產品、供應商或任何消費者資料，那麼這位高管將沒有可用的資料進行分析，因為以往的資料由於交易已被更新。

資料倉庫為我們提供多維度檢視的泛化和整合資料。除了資料的泛化和整合檢視外，資料倉庫還為我們提供聯機分析處理 (OLAP) 工具。這些工具幫助我們在多維空間中進行互動式和有效的 資料分析。這種分析導致資料泛化和資料探勘。

諸如關聯、聚類、分類、預測等資料探勘功能可以與OLAP操作整合，以增強在多個抽象層次上互動式挖掘知識的能力。這就是為什麼資料倉庫現在已成為資料分析和聯機分析處理的重要平臺。

理解資料倉庫

• 資料倉庫是一個數據庫，它與組織的運營資料庫分開存放。

• 資料倉庫不會頻繁更新。

• 它擁有整合的歷史資料，這有助於組織分析其業務。

• 資料倉庫幫助高管組織、理解和使用他們的資料以做出戰略決策。

• 資料倉庫系統有助於整合各種應用程式系統。

• 資料倉庫系統有助於整合歷史資料的分析。

為什麼資料倉庫與運營資料庫分開

資料倉庫與運營資料庫分開存放的原因如下：

• 運營資料庫是為眾所周知的任務和工作負載（例如搜尋特定記錄、索引等）而構建的。相比之下，資料倉庫查詢通常很複雜，並且它們呈現出資料的通用形式。

• 運營資料庫支援併發處理多個事務。運營資料庫需要併發控制和恢復機制來確保資料庫的健壯性和一致性。

• 運營資料庫查詢允許讀寫操作，而OLAP查詢只需要對儲存資料的**只讀**訪問。

• 運營資料庫維護當前資料。另一方面，資料倉庫維護歷史資料。

資料倉庫特性

下面討論資料倉庫的關鍵特性：

• **面向主題** - 資料倉庫面向主題，因為它提供圍繞主題的資訊，而不是組織的正在進行的運營。這些主題可以是產品、客戶、供應商、銷售、收入等。資料倉庫不關注正在進行的運營，而是關注資料的建模和分析以進行決策。

• **整合** - 資料倉庫是透過整合來自異構資料來源（例如關係資料庫、平面檔案等）的資料來構建的。這種整合增強了資料的有效分析。

• **隨時間變化** - 資料倉庫中收集的資料與特定時間段相關聯。資料倉庫中的資料提供從歷史角度來看的資訊。

• **非易失性** - 非易失性意味著在新增新資料時不會擦除以前的資料。資料倉庫與運營資料庫分開存放，因此運營資料庫中的頻繁更改不會反映在資料倉庫中。

**注意** - 資料倉庫不需要事務處理、恢復和併發控制，因為它與運營資料庫物理隔離並單獨儲存。

資料倉庫應用

如前所述，資料倉庫幫助企業高管組織、分析和使用他們的資料進行決策。資料倉庫是企業管理計劃-執行-評估“閉環”反饋系統中的一個組成部分。資料倉庫廣泛應用於以下領域：

• 金融服務
• 銀行服務
• 消費品
• 零售業
• 受控制造業

資料倉庫型別

資訊處理、分析處理和資料探勘是下面討論的三種資料倉庫應用程式型別：

• **資訊處理** - 資料倉庫允許處理其中儲存的資料。可以透過查詢、基本統計分析、使用交叉表、表格、圖表或圖形進行報告來處理資料。

• **分析處理** - 資料倉庫支援對其儲存資訊的分析處理。可以透過基本OLAP操作（包括切片和切塊、向下鑽取、向上鑽取和透視）來分析資料。

• **資料探勘** - 資料探勘透過查詢隱藏的模式和關聯、構建分析模型、執行分類和預測來支援知識發現。可以使用視覺化工具來呈現這些挖掘結果。

資料倉庫 - 概念

什麼是資料倉庫？

資料倉庫是構建和使用資料倉庫的過程。資料倉庫是透過整合來自多個異構資料來源的資料來構建的，這些資料來源支援分析報告、結構化和/或臨時查詢以及決策制定。資料倉庫涉及資料清洗、資料整合和資料整合。

使用資料倉庫資訊

有一些決策支援技術可以幫助利用資料倉庫中可用的資料。這些技術幫助高管快速有效地使用倉庫。他們可以收集資料，對其進行分析，並根據倉庫中提供的資訊做出決策。倉庫中收集的資訊可用於以下任何領域：

• **調整生產策略** - 透過比較季度或年度銷售額來重新定位產品和管理產品組合，可以很好地調整產品策略。

• **客戶分析** - 透過分析客戶的購買偏好、購買時間、預算週期等來進行客戶分析。

• **運營分析** - 資料倉庫還有助於客戶關係管理和進行環境修正。這些資訊還允許我們分析業務運營。

整合異構資料庫

為了整合異構資料庫，我們有兩種方法：

• 查詢驅動方法
• 更新驅動方法

查詢驅動方法

這是整合異構資料庫的傳統方法。這種方法用於在多個異構資料庫之上構建包裝器和整合器。這些整合器也稱為中介。

查詢驅動方法的過程

• 當向客戶端發出查詢時，元資料字典會將查詢轉換為參與的各個異構站點適用的形式。

• 現在這些查詢被對映併發送到本地查詢處理器。

• 來自異構站點的結果被整合到全域性答案集中。

缺點

• 查詢驅動方法需要複雜的整合和過濾過程。

• 這種方法非常低效。

• 對於頻繁的查詢，這種方法非常昂貴。

• 對於需要聚合的查詢，這種方法也非常昂貴。

更新驅動方法

這是對傳統方法的替代方法。當今的資料倉庫系統遵循更新驅動方法，而不是前面討論的傳統方法。在更新驅動方法中，來自多個異構源的資訊會提前整合並存儲在倉庫中。此資訊可用於直接查詢和分析。

優點

這種方法具有以下優點：

• 這種方法提供高效能。

• 資料在語義資料儲存中預先複製、處理、整合、註釋、彙總和重構。

• 查詢處理不需要介面來處理本地源的資料。

資料倉庫工具和實用程式的功能

以下是資料倉庫工具和實用程式的功能：

• **資料提取** - 涉及從多個異構源收集資料。

• **資料清洗** - 涉及查詢和糾正資料中的錯誤。

• **資料轉換** - 涉及將資料從舊格式轉換為倉庫格式。

• **資料載入** - 涉及排序、彙總、整合、檢查完整性以及構建索引和分割槽。

• **重新整理** - 涉及從資料來源到倉庫的更新。

**注意** - 資料清洗和資料轉換是提高資料質量和資料探勘結果的重要步驟。

資料倉庫 - 術語

在本章中，我們將討論資料倉庫中一些最常用的術語。

元資料

元資料簡單地定義為關於資料的資料。用於表示其他資料的那些資料被稱為元資料。例如，書籍的索引作為書籍內容的元資料。換句話說，我們可以說元資料是引導我們走向詳細資料的彙總資料。

在資料倉庫方面，我們可以如下定義元資料：

• 元資料是資料倉庫的路線圖。

• 資料倉庫中的元資料定義了倉庫物件。

• 元資料充當目錄。此目錄幫助決策支援系統定位資料倉庫的內容。

元資料倉庫

元資料倉庫是資料倉庫系統的一個組成部分。它包含以下元資料：

• 業務元資料 - 包含資料所有權資訊、業務定義和變更策略。

• 操作元資料 - 包括資料的有效性和資料血緣。資料的有效性是指資料處於活動狀態、已歸檔或已清除。資料血緣是指資料遷移的歷史記錄以及對其應用的轉換。

• 從操作環境到資料倉庫的對映資料 - 此元資料包括源資料庫及其內容、資料提取、資料分割槽、清洗、轉換規則、資料重新整理和清除規則。

• 彙總演算法 - 包括維度演算法、粒度資料、聚合、彙總等。

資料立方體

資料立方體幫助我們以多個維度表示資料。它由維度和事實定義。維度是企業儲存記錄的實體。

資料立方體的示例

假設一家公司希望藉助銷售資料倉庫跟蹤銷售記錄，這些記錄涉及時間、商品、分支機構和地點。這些維度允許跟蹤每月的銷售額以及商品在哪個分支機構銷售。每個維度都關聯一個表。此表稱為維度表。“商品”維度表可能具有商品名稱、商品型別和商品品牌等屬性。

下表顯示了公司關於時間、商品和地點維度的銷售資料的二維檢視。

但在此二維表中，我們只有關於時間和商品的記錄。新德里的銷售額按時間和商品維度顯示，根據銷售商品的型別顯示。如果我們想檢視包含另一個維度（例如地點維度）的銷售資料，則三維檢視將非常有用。下表顯示了關於時間、商品和地點的三維銷售資料檢視。

上表可以表示為如下所示的三維資料立方體：

資料市場

資料市場包含對組織中特定人群有價值的組織範圍資料的子集。換句話說，資料市場只包含特定群體的資料。例如，市場營銷資料市場可能只包含與商品、客戶和銷售相關的資料。資料市場限於主題。

關於資料市場的要點

• 使用基於 Windows 或 Unix/Linux 的伺服器來實現資料市場。它們是在低成本伺服器上實現的。

• 資料市場的實施週期以較短的時間段衡量，即以周而不是月或年來衡量。

• 從長遠來看，如果資料市場的規劃和設計不是全組織範圍的，那麼它們的生命週期可能會很複雜。

• 資料市場規模較小。

• 資料市場由部門定製。

• 資料市場的來源是部門結構化的資料倉庫。

• 資料市場靈活。

下圖顯示了資料市場的圖形表示。

虛擬倉庫

對操作資料倉庫的檢視稱為虛擬倉庫。構建虛擬倉庫很容易。構建虛擬倉庫需要操作資料庫伺服器上的額外容量。

資料倉庫 - 交付流程

資料倉庫從來都不是靜態的；它隨著業務的擴充套件而發展。隨著業務的發展，其需求不斷變化，因此必須設計資料倉庫以適應這些變化。因此，資料倉庫系統需要靈活。

理想情況下，應該有一個交付流程來交付資料倉庫。但是，資料倉庫專案通常會遇到各種問題，這些問題使得難以按照瀑布方法要求的嚴格和有序的方式完成任務和交付成果。大多數情況下，需求並不完全瞭解。只有在收集和研究所有需求後，才能完成體系結構、設計和構建元件。

交付方法

交付方法是為交付資料倉庫而採用的聯合應用程式開發方法的變體。我們已經對資料倉庫交付流程進行了分階段處理，以最大程度地降低風險。我們在這裡將討論的方法不會縮短整體交付時間，但確保透過開發流程逐步交付業務利益。

注意 - 交付流程被分成多個階段，以降低專案和交付風險。

下圖解釋了交付流程中的各個階段：

IT戰略

資料倉庫是戰略性投資，需要業務流程來產生效益。需要 IT 戰略來獲取和保留專案的資金。

商業案例

商業案例的目標是估算使用資料倉庫應獲得的業務效益。這些效益可能無法量化，但需要明確說明預計效益。如果資料倉庫沒有明確的商業案例，那麼業務在交付過程的某個階段往往會遇到信譽問題。因此，在資料倉庫專案中，我們需要了解投資的商業案例。

教育和原型設計

組織會嘗試資料分析的概念，並在確定解決方案之前瞭解擁有資料倉庫的價值。這是透過原型設計來解決的。它有助於瞭解資料倉庫的可行性和效益。只要滿足以下條件，小規模的原型設計活動就可以促進教育過程：

• 原型解決了定義的技術目標。

• 在顯示可行性概念後，可以丟棄原型。

• 該活動處理資料倉庫最終資料內容的一小部分。

• 活動時間表並不關鍵。

為了儘早釋出並交付業務利益，請記住以下幾點。

• 確定能夠發展的架構。

• 關注業務需求和技術藍圖階段。

• 將第一構建階段的範圍限制在交付業務利益的最低限度。

• 瞭解資料倉庫的短期和中期需求。

業務需求

為了提供高質量的交付成果，我們應該確保瞭解整體需求。如果我們瞭解短期和中期的業務需求，那麼我們可以設計一個解決方案來滿足短期需求。然後，短期解決方案可以發展為完整的解決方案。

在此階段確定以下方面：

• 應用於資料的業務規則。

• 資料倉庫中資訊的邏輯模型。

• 對直接需求的查詢配置檔案。

• 提供此資料的源系統。

技術藍圖

此階段需要交付滿足長期需求的整體架構。此階段還會交付必須在短期內實施才能獲得任何業務利益的元件。藍圖需要確定以下內容。

• 整體系統架構。
• 資料保留策略。
• 備份和恢復策略。
• 伺服器和資料市場架構。
• 硬體和基礎設施的容量規劃。
• 資料庫設計的元件。

構建版本

在此階段，將生成第一個生產交付成果。此生產交付成果是資料倉庫的最小元件。此最小元件增加了業務利益。

歷史載入

這是將剩餘所需歷史記錄載入到資料倉庫的階段。在此階段，我們不會新增新的實體，但可能會建立額外的物理表來儲存增加的資料量。

讓我們舉個例子。假設構建版本階段交付了一個具有兩個月曆史記錄的零售銷售分析資料倉庫。此資訊將允許使用者僅分析近期趨勢並解決短期問題。在這種情況下，使用者無法識別年度和季節性趨勢。為了幫助他做到這一點，可以從存檔中載入過去兩年的銷售歷史記錄。現在，40GB 的資料擴充套件到 400GB。

注意 - 備份和恢復過程可能會變得複雜，因此建議在單獨的階段執行此活動。

臨時查詢

在此階段，我們配置一個用於操作資料倉庫的臨時查詢工具。這些工具可以生成資料庫查詢。

注意 - 建議在資料庫正在大幅修改時不要使用這些訪問工具。

自動化

在此階段，運營管理流程將完全自動化。這些將包括：

• 將資料轉換為適合分析的形式。

• 監控查詢配置檔案並確定適當的聚合以維護系統性能。

• 從不同的源系統提取和載入資料。

• 從資料倉庫中的預定義定義生成聚合。

• 備份、還原和存檔資料。

擴充套件範圍

在此階段，資料倉庫將擴充套件以滿足一組新的業務需求。範圍可以透過兩種方式擴充套件：

• 透過將其他資料載入到資料倉庫中。

• 透過使用現有資訊引入新的資料市場。

注意 - 此階段應單獨執行，因為它涉及大量的努力和複雜性。

需求演變

從交付流程的角度來看，需求總是可變的。它們不是靜態的。交付流程必須支援這一點，並允許將這些更改反映到系統中。

這個問題是透過圍繞業務流程中資料的利用來設計資料倉庫來解決的，而不是現有查詢的資料需求。

該架構旨在根據業務需求進行更改和擴充套件，其執行過程類似於偽應用程式開發過程，不斷將新需求輸入到開發活動中，並生成部分可交付成果。這些部分可交付成果將反饋給使用者，然後進行返工，確保整個系統持續更新以滿足業務需求。

資料倉庫 - 系統流程

我們需要對操作資料庫應用固定數量的操作，並且我們有明確定義的技術，例如**使用規範化資料**、**保持表較小**等。這些技術適用於交付解決方案。但在決策支援系統的情況下，我們不知道將來需要執行哪些查詢和操作。因此，應用於操作資料庫的技術不適用於資料倉庫。

本章將討論如何在開放系統技術（如 Unix 和關係資料庫）之上構建資料倉庫解決方案。

資料倉庫中的流程

資料倉庫包含四個主要流程：

• 提取和載入資料。
• 資料清洗和轉換。
• 資料備份和歸檔。
• 管理查詢並將它們定向到相應的資料來源。

提取和載入流程

資料提取從源系統獲取資料。資料載入將提取的資料載入到資料倉庫中。

注意 - 在將資料載入到資料倉庫之前，必須重建從外部來源提取的資訊。

流程控制

流程控制包括確定何時啟動資料提取以及資料的一致性檢查。流程控制確保工具、邏輯模組和程式按正確的順序和時間執行。

何時啟動提取

提取資料時，資料需要處於一致狀態，即資料倉庫應向用戶呈現資訊的單個一致版本。

例如，在電信行業的客戶畫像資料倉庫中，將星期三晚上 8 點從客戶資料庫中獲取的客戶列表與星期二晚上 8 點之前的客戶訂閱事件合併是不合邏輯的。這意味著我們將找到沒有關聯訂閱的客戶。

資料載入

提取資料後，將其載入到臨時資料儲存區，在其中進行清理並使其保持一致。

注意 - 只在所有資料來源都已載入到臨時資料儲存區後才執行一致性檢查。

清洗和轉換流程

將資料提取並載入到臨時資料儲存區後，就可以進行清洗和轉換。以下是清洗和轉換步驟：

• 將載入的資料清洗並轉換到特定的結構
• 資料分割槽
• 資料聚合

將載入的資料清洗並轉換到特定的結構

清洗和轉換載入的資料有助於加快查詢速度。可以透過使資料保持一致來實現：

• 自身內部一致。
• 與同一資料來源中的其他資料一致。
• 與其他源系統中的資料一致。
• 與倉庫中現有的資料一致。

轉換涉及將源資料轉換為特定結構。對資料進行結構化處理可以提高查詢效能並降低運營成本。資料倉庫中包含的資料必須經過轉換才能滿足效能要求並控制持續的運營成本。

資料分割槽

這將最佳化硬體效能並簡化資料倉庫的管理。在這裡，我們將每個事實表劃分為多個單獨的分割槽。

資料聚合

需要聚合來加快常用查詢的速度。聚合依賴於這樣一個事實，即大多數常用查詢將分析詳細資料的子集或聚合。

資料備份和歸檔

為了在資料丟失、軟體故障或硬體故障的情況下恢復資料，有必要定期進行備份。歸檔涉及以允許在需要時快速恢復的格式從系統中刪除舊資料。

例如，在零售銷售分析資料倉庫中，可能需要保留 3 年的資料，其中最近 6 個月的資料線上保留。在這種情況下，通常需要能夠進行今年和去年的月度比較。在這種情況下，我們需要從存檔中恢復一些資料。

查詢管理流程

此流程執行以下功能：

• 管理查詢。

• 幫助加快查詢執行速度。

• 將查詢定向到其最有效的資料來源。

• 確保以最有效的方式使用所有系統資源。

• 監控實際查詢概要。

在此過程中生成的資訊由倉庫管理流程用於確定要生成的聚合。此流程通常不在將資訊定期載入到資料倉庫期間執行。

資料倉庫 - 架構

本章將討論資料倉庫設計和架構的業務分析框架。

業務分析框架

業務分析師從資料倉庫獲取資訊來衡量績效並進行關鍵調整，以便在市場上勝過其他業務持有者。擁有資料倉庫具有以下優勢：

• 由於資料倉庫可以快速有效地收集資訊，因此可以提高業務效率。

• 資料倉庫為我們提供了客戶和商品的一致檢視，因此有助於我們管理客戶關係。

• 資料倉庫還有助於透過長期跟蹤趨勢和模式以一致可靠的方式降低成本。

為了設計有效且高效的資料倉庫，我們需要理解和分析業務需求並構建**業務分析框架**。每個人對資料倉庫的設計都有不同的看法。這些觀點如下：

• **自頂向下檢視** - 此檢視允許選擇資料倉庫所需的相關資訊。

• **資料來源檢視** - 此檢視顯示作業系統捕獲、儲存和管理的資訊。

• **資料倉庫檢視** - 此檢視包括事實表和維度表。它表示儲存在資料倉庫中的資訊。

• **業務查詢檢視** - 這是從終端使用者的角度來看待資料的檢視。

三層資料倉庫架構

資料倉庫通常採用三層架構。以下是資料倉庫架構的三層：

• **底層** - 架構的底層是資料倉庫資料庫伺服器。它是關係資料庫系統。我們使用後端工具和實用程式將資料饋送到底層。這些後端工具和實用程式執行提取、清洗、載入和重新整理功能。

• **中間層** - 在中間層，我們有 OLAP 伺服器，可以透過以下兩種方式實現。

  • 透過關係 OLAP (ROLAP)，它是一個擴充套件的關係資料庫管理系統。ROLAP 將多維資料上的操作對映到標準關係操作。

  • 透過多維 OLAP (MOLAP) 模型，它直接實現多維資料和操作。

• **頂層** - 此層是前端客戶端層。此層包含查詢工具和報表工具、分析工具和資料探勘工具。

下圖描述了資料倉庫的三層架構。

資料倉庫模型

從資料倉庫架構的角度來看，我們有以下資料倉庫模型：

• 虛擬倉庫
• 資料市集
• 企業倉庫

虛擬倉庫

對操作資料倉庫的檢視稱為虛擬倉庫。構建虛擬倉庫很容易。構建虛擬倉庫需要操作資料庫伺服器上的額外容量。

資料市場

資料市集包含組織範圍資料的子集。此資料子集對組織的特定群體很有價值。

換句話說，我們可以說資料市集包含特定於特定群體的資料。例如，市場營銷資料市集可能包含與商品、客戶和銷售相關的資料。資料市集侷限於特定主題。

關於資料市集需要注意的幾點：

• 使用基於 Windows 或 Unix/Linux 的伺服器來實現資料市集。它們在低成本伺服器上實現。

• 資料市集的實現週期以較短的時間段來衡量，即以周而不是以月或年來衡量。

• 如果資料市集的規劃和設計不是組織範圍的，那麼從長遠來看，其生命週期可能會很複雜。

• 資料市場規模較小。

• 資料市場由部門定製。

• 資料市場的來源是部門結構化的資料倉庫。

• 資料市集很靈活。

企業倉庫

• 企業倉庫收集跨越整個組織的所有資訊和主題。

• 它為我們提供企業範圍的資料整合。

• 資料整合自作業系統和外部資訊提供商。

• 此資訊的大小可能從幾 GB 到數百 GB、TB 或更多。

載入管理器

此元件執行提取和載入過程所需的操作。

載入管理器的規模和複雜性因特定資料倉庫解決方案而異。

載入管理器架構

載入管理器執行以下功能：

• 從源系統提取資料。

• 將提取的資料快速載入到臨時資料儲存區。

• 執行簡單的轉換，使其結構類似於資料倉庫中的結構。

從源提取資料

資料從操作資料庫或外部資訊提供商提取。閘道器是用於提取資料的應用程式程式。它由底層 DBMS 支援，並允許客戶端程式生成在伺服器上執行的 SQL。開放資料庫連線 (ODBC)、Java 資料庫連線 (JDBC) 是閘道器的示例。

快速載入

• 為了最大限度地減少總載入視窗，需要以儘可能快的速度將資料載入到倉庫中。

• 轉換會影響資料處理速度。

• 在應用轉換和檢查之前，將資料載入到關係資料庫中更有效。

• 閘道器技術被證明不適用，因為當涉及大量資料時，它們的效能往往不高。

簡單的轉換

載入時可能需要執行簡單的轉換。完成後，我們就可以進行復雜的檢查。假設我們正在載入 EPOS 銷售交易，我們需要執行以下檢查

• 去除倉庫中不需要的所有列。
• 將所有值轉換為所需的資料型別。

倉庫管理器

倉庫管理器負責倉庫管理流程。它包括第三方系統軟體、C 程式和 shell 指令碼。

倉庫管理器的規模和複雜性因特定解決方案而異。

倉庫管理器架構

倉庫管理器包括以下內容：

• 控制流程
• 儲存過程或帶有 SQL 的 C 程式碼
• 備份/恢復工具
• SQL指令碼

倉庫管理員執行的操作

• 倉庫管理員分析資料以執行一致性和參照完整性檢查。

• 針對基礎資料建立索引、業務檢視、分割槽檢視。

• 生成新的聚合並更新現有的聚合。生成規範化。

• 將源資料轉換併合併到已釋出的資料倉庫中。

• 備份資料倉庫中的資料。

• 存檔已達到捕獲壽命結束的資料。

注意 − 倉庫管理員還會分析查詢配置檔案，以確定索引和聚合是否合適。

查詢管理器

• 查詢管理器負責將查詢定向到合適的表。

• 透過將查詢定向到合適的表，可以提高查詢速度和響應生成速度。

• 查詢管理器負責排程使用者提出的查詢的執行。

查詢管理器架構

以下螢幕截圖顯示了查詢管理器的架構。它包括以下內容：

• 透過C工具或RDBMS進行查詢重定向
• 儲存過程
• 查詢管理工具
• 透過C工具或RDBMS進行查詢排程
• 透過第三方軟體進行查詢排程

詳細資訊

詳細資訊不會線上儲存，而是聚合到下一個詳細級別，然後存檔到磁帶上。資料倉庫的詳細資訊部分將詳細資訊儲存在星型雪花模式中。將詳細資訊載入到資料倉庫中以補充聚合資料。

下圖顯示了詳細資訊儲存位置及其使用方法的圖示。

注意 − 如果離線儲存詳細資訊以最大限度地減少磁碟儲存空間，我們應確保資料在存檔之前已提取、清理並轉換為星型雪花模式。

彙總資訊

彙總資訊是資料倉庫的一部分，用於儲存預定義的聚合。這些聚合由倉庫管理員生成。彙總資訊必須視為瞬態的。它會隨時發生變化，以響應不斷變化的查詢配置檔案。

關於彙總資訊需要注意的幾點如下：

• 彙總資訊可以加快常用查詢的效能。

• 它會增加運營成本。

• 每當將新資料載入到資料倉庫中時，都需要更新它。

• 它可能沒有備份，因為它可以從詳細資訊中重新生成。

資料倉庫 - OLAP

聯機分析處理伺服器 (OLAP) 基於多維資料模型。它允許管理人員和分析師透過快速、一致且互動式地訪問資訊來深入瞭解資訊。本章涵蓋 OLAP 的型別、OLAP 的操作、OLAP 與統計資料庫以及 OLTP 之間的區別。

OLAP 伺服器型別

我們有四種類型的 OLAP 伺服器：

• 關係型 OLAP (ROLAP)
• 多維 OLAP (MOLAP)
• 混合 OLAP (HOLAP)
• 專用 SQL 伺服器

關係型 OLAP

ROLAP 伺服器位於關係型後端伺服器和客戶端前端工具之間。為了儲存和管理倉庫資料，ROLAP 使用關係型或擴充套件關係型 DBMS。

ROLAP 包括以下內容：

• 聚合導航邏輯的實現。
• 針對每個 DBMS 後端的最佳化。
• 其他工具和服務。

多維 OLAP

MOLAP 使用基於陣列的多維儲存引擎來實現資料的多維檢視。對於多維資料儲存，如果資料集稀疏，則儲存利用率可能較低。因此，許多 MOLAP 伺服器使用兩級資料儲存表示來處理密集型和稀疏型資料集。

混合 OLAP

混合 OLAP 是 ROLAP 和 MOLAP 的組合。它提供了 ROLAP 的更高可擴充套件性和 MOLAP 的更快計算速度。HOLAP 伺服器允許儲存大量詳細資訊。聚合分別儲存在 MOLAP 儲存中。

專用 SQL 伺服器

專用 SQL 伺服器為只讀環境中星型和雪花模式上的 SQL 查詢提供高階查詢語言和查詢處理支援。

OLAP 操作

由於 OLAP 伺服器基於資料的多維檢視，因此我們將討論多維資料中的 OLAP 操作。

以下是 OLAP 操作的列表：

• 上卷
• 下鑽
• 切片和切塊
• 透視（旋轉）

上卷

上卷以以下任何一種方式對資料立方體執行聚合：

• 透過沿著維度概念層次結構向上移動
• 透過維度縮減

下圖說明了上卷的工作原理。

• 透過沿著位置維度概念層次結構向上移動來執行上卷。

• 最初的概念層次結構是“街道 < 城市 < 省份 < 國家”。

• 在上卷時，資料透過從城市級別到國家級別上移位置層次結構來聚合。

• 資料按城市而不是國家分組。

• 執行上卷時，將從資料立方體中刪除一個或多個維度。

下鑽

下鑽是上卷的逆操作。它透過以下任何一種方式執行：

• 透過沿著維度概念層次結構向下移動
• 透過引入新維度。

下圖說明了下鑽的工作原理：

• 透過沿著時間維度概念層次結構向下移動來執行下鑽。

• 最初的概念層次結構是“天 < 月 < 季度 < 年”。

• 在下鑽時，時間維度從季度級別下降到月級別。

• 執行下鑽時，將向資料立方體中新增一個或多個維度。

• 它將資料從較少詳細的資料導航到高度詳細的資料。

切片

切片操作從給定的立方體中選擇一個特定維度並提供一個新的子立方體。考慮下圖，該圖顯示了切片的工作原理。

• 此處使用條件時間 = “Q1”對維度“時間”執行切片。

• 它將透過選擇一個或多個維度來形成一個新的子立方體。

切塊

切塊從給定的立方體中選擇兩個或多個維度並提供一個新的子立方體。考慮下圖，該圖顯示了切塊操作。

基於以下選擇條件的立方體上的切塊操作涉及三個維度。

• （位置 = “多倫多”或“溫哥華”）
• （時間 = “Q1”或“Q2”）
• （專案 =“行動電話”或“調變解調器”）

透視

透視操作也稱為旋轉。它旋轉檢視中的資料軸，以便提供資料的替代表示。考慮下圖，該圖顯示了透視操作。

OLAP 與 OLTP

資料倉庫 - 關係型 OLAP

關係型 OLAP 伺服器位於關係型後端伺服器和客戶端前端工具之間。為了儲存和管理倉庫資料，關係型 OLAP 使用關係型或擴充套件關係型 DBMS。

ROLAP 包括以下內容：

• 聚合導航邏輯的實現
• 針對每個 DBMS 後端的最佳化
• 其他工具和服務

要點

• ROLAP 伺服器高度可擴充套件。

• ROLAP 工具分析跨多個維度的大量資料。

• ROLAP 工具儲存和分析高度易變和可更改的資料。

關係型 OLAP 架構

ROLAP 包括以下元件：

• 資料庫伺服器
• ROLAP 伺服器
• 前端工具。

優點

• ROLAP 伺服器可以輕鬆地與現有的 RDBMS 一起使用。
• 可以有效地儲存資料，因為無法儲存零事實。
• ROLAP 工具不使用預先計算的資料立方體。
• MicroStrategy 的 DSS 伺服器採用 ROLAP 方法。

缺點

• 查詢效能差。

• 根據使用的技術架構，可擴充套件性存在一些限制。

資料倉庫 - 多維 OLAP

多維 OLAP (MOLAP) 使用基於陣列的多維儲存引擎來實現資料的多維檢視。對於多維資料儲存，如果資料集稀疏，則儲存利用率可能較低。因此，許多 MOLAP 伺服器使用兩級資料儲存表示來處理密集型和稀疏型資料集。

要點：

• 無論選擇的彙總或計算級別如何，MOLAP 工具都能以一致的響應時間處理資訊。

• MOLAP 工具需要避免建立關係資料庫以儲存分析資料的許多複雜性。

• MOLAP 工具需要儘可能快的效能。

• MOLAP 伺服器採用兩級儲存表示來處理密集型和稀疏型資料集。

• 識別更密集的子立方體並將其儲存為陣列結構。

• 稀疏子立方體採用壓縮技術。

MOLAP 架構

MOLAP 包括以下元件：

• 資料庫伺服器。
• MOLAP 伺服器。
• 前端工具。

優點

• MOLAP 允許對預先計算的彙總資料進行最快索引。
• 幫助需要分析更大、更不確定資料的聯網使用者。
• 易於使用，因此 MOLAP 適用於沒有經驗的使用者。

缺點

• MOLAP 無法包含詳細資訊。
• 如果資料集稀疏，則儲存利用率可能較低。

MOLAP 與 ROLAP

資料倉庫 - 模式

模式是對整個資料庫的邏輯描述。它包括所有記錄型別（包括所有關聯的資料項和聚合）的記錄名稱和描述。類似於資料庫，資料倉庫也需要維護模式。資料庫使用關係模型，而資料倉庫使用星型、雪花型和事實星座型模式。本章將討論資料倉庫中使用的模式。

星型模式

• 在星型模式中，每個維度都只用一個維度表表示。

• 該維度表包含一組屬性。

• 下圖顯示了公司關於四個維度（時間、專案、分支和位置）的銷售資料。

• 中心有一個事實表。它包含每個四個維度的鍵。

• 事實表還包含屬性，即銷售美元和銷售單位。

注意 - 每個維度只有一個維度表，每個表都儲存一組屬性。例如，位置維度表包含屬性集{location_key, street, city, province_or_state, country}。此約束可能會導致資料冗餘。例如，“溫哥華”和“維多利亞”這兩個城市都在加拿大不列顛哥倫比亞省。此類城市的條目可能會導致屬性province_or_state和country的資料冗餘。

雪花模式

• 雪花模式中的一些維度表已進行規範化。

• 規範化將資料拆分為附加表。

• 與星型模式不同，雪花模式中的維度表是規範化的。例如，星型模式中的專案維度表被規範化並拆分為兩個維度表，即專案表和供應商表。

• 現在，專案維度表包含屬性item_key、item_name、type、brand和supplier-key。

• 供應商鍵連結到供應商維度表。供應商維度表包含屬性supplier_key和supplier_type。

注意 - 由於雪花模式中的規範化，冗餘減少了，因此易於維護並節省儲存空間。

事實星座模式

• 事實星座有多個事實表。它也稱為星系模式。

• 下圖顯示了兩個事實表，即銷售和運輸。

• 銷售事實表與星型模式中的相同。

• 運輸事實表具有五個維度，即item_key、time_key、shipper_key、from_location、to_location。

• 運輸事實表還包含兩個度量，即銷售美元和銷售單位。

• 也可以在事實表之間共享維度表。例如，時間、專案和位置維度表在銷售和運輸事實表之間共享。

模式定義

使用資料探勘查詢語言 (DMQL) 定義多維模式。可以使用兩個基本元素，立方體定義和維度定義，來定義資料倉庫和資料市場。

立方體定義語法

define cube < cube_name > [ < dimension-list > }: < measure_list >

維度定義語法

define dimension < dimension_name > as ( < attribute_or_dimension_list > )

星型模式定義

我們可以使用資料探勘查詢語言 (DMQL) 定義我們討論過的星型模式，如下所示：

define cube sales star [time, item, branch, location]:   
    	   
dollars sold = sum(sales in dollars), units sold = count(*)    	  

define dimension time as (time key, day, day of week, month, quarter, year)
define dimension item as (item key, item name, brand, type, supplier type)        	
define dimension branch as (branch key, branch name, branch type)              	
define dimension location as (location key, street, city, province or state, country)

雪花模式定義

可以使用 DMQL 定義雪花模式，如下所示：

define cube sales snowflake [time, item, branch, location]:

dollars sold = sum(sales in dollars), units sold = count(*)

define dimension time as (time key, day, day of week, month, quarter, year)
define dimension item as (item key, item name, brand, type, supplier (supplier key, supplier type))
define dimension branch as (branch key, branch name, branch type)
define dimension location as (location key, street, city (city key, city, province or state, country))

事實星座模式定義

可以使用 DMQL 定義事實星座模式，如下所示：

define cube sales [time, item, branch, location]:

dollars sold = sum(sales in dollars), units sold = count(*)

define dimension time as (time key, day, day of week, month, quarter, year)
define dimension item as (item key, item name, brand, type, supplier type)
define dimension branch as (branch key, branch name, branch type)
define dimension location as (location key, street, city, province or state,country)
define cube shipping [time, item, shipper, from location, to location]:

dollars cost = sum(cost in dollars), units shipped = count(*)

define dimension time as time in cube sales
define dimension item as item in cube sales
define dimension shipper as (shipper key, shipper name, location as location in cube sales, shipper type)
define dimension from location as location in cube sales
define dimension to location as location in cube sales

資料倉庫 - 分割槽策略

進行分割槽是為了提高效能並方便資料管理。分割槽還有助於平衡系統的各種需求。它透過將每個事實表分成多個單獨的分割槽來最佳化硬體效能並簡化資料倉庫的管理。本章將討論不同的分割槽策略。

為什麼需要分割槽？

出於以下原因，分割槽非常重要：

• 易於管理；
• 輔助備份/恢復；
• 提高效能。

易於管理

資料倉庫中的事實表的大小可能會增長到數百 GB。如此巨大的事實表很難作為一個實體來管理。因此，它需要分割槽。

輔助備份/恢復

如果我們不分割槽事實表，那麼我們必須載入包含所有資料的完整事實表。分割槽允許我們僅根據需要定期載入資料。它減少了載入時間，並提高了系統的效能。

注意 - 為減少備份大小，當前分割槽以外的所有分割槽都可以標記為只讀。然後，我們可以將這些分割槽置於無法修改的狀態。然後可以備份它們。這意味著只需要備份當前分割槽。

提高效能

透過將事實表劃分為資料集，可以增強查詢過程。查詢效能得到增強，因為現在查詢只掃描相關的那些分割槽。它不必掃描整個資料。

水平分割槽

事實表有多種分割槽方式。在水平分割槽中，我們必須記住資料倉庫的可管理性要求。

按時間劃分為相等的部分

在此分割槽策略中，事實表基於時間段進行分割槽。這裡每個時間段代表業務中的一個重要保留期。例如，如果使用者查詢**月度至今資料**，則將資料劃分為月度部分是合適的。我們可以透過刪除其中的資料來重複使用分割槽表。

按時間劃分為不同大小的部分

這種分割槽是在很少訪問陳舊資料的情況下進行的。它實現為一組用於相對當前資料的小分割槽，以及用於非活動資料的大分割槽。

需要注意的幾點

• 詳細資訊線上提供。

• 物理表的數量保持相對較小，從而降低了運營成本。

• 此技術適用於需要混合使用最近歷史資料探勘和整個歷史資料探勘的情況。

• 此技術不適用於分割槽配置檔案定期更改的情況，因為重新分割槽會增加資料倉庫的運營成本。

按不同維度分割槽

事實表也可以基於時間以外的維度進行分割槽，例如產品組、區域、供應商或任何其他維度。讓我們舉個例子。

假設市場職能已細分為不同的區域部門，例如**按州**劃分。如果每個區域都希望查詢在其區域內捕獲的資訊，則將事實表劃分為區域分割槽將被證明更有效。這將導致查詢速度加快，因為它不需要掃描不相關的資訊。

需要注意的幾點

• 查詢不必掃描不相關的資料，從而加快了查詢過程。

• 此技術不適用於維度在未來不太可能發生變化的情況。因此，確定維度在未來不會發生變化是值得的。

• 如果維度發生變化，則必須重新分割槽整個事實表。

注意 - 我們建議僅基於時間維度進行分割槽，除非您確定建議的維度分組在資料倉庫的生命週期內不會發生變化。

按表大小分割槽

當沒有明確的依據可以根據任何維度對事實表進行分割槽時，我們應該**根據其大小對事實表進行分割槽**。我們可以將預定大小設定為臨界點。當表超過預定大小時，將建立一個新的表分割槽。

需要注意的幾點

• 這種分割槽難以管理。

• 它需要元資料來識別每個分割槽中儲存的資料。

分割槽維度

如果維度包含大量條目，則需要對維度進行分割槽。在這裡，我們必須檢查維度的尺寸。

考慮一個隨時間變化的大型設計。如果我們需要儲存所有變體以便進行比較，則該維度可能非常大。這肯定會影響響應時間。

迴圈分割槽

在迴圈技術中，當需要新分割槽時，舊分割槽將被存檔。它使用元資料允許使用者訪問工具引用正確的表分割槽。

此技術使在資料倉庫中輕鬆自動化表管理功能。

垂直分割槽

垂直分割槽垂直分割資料。下圖描述瞭如何進行垂直分割槽。

垂直分割槽可以透過以下兩種方式執行：

• 規範化
• 行分割

規範化

規範化是資料庫組織的標準關係方法。在這種方法中，行摺疊成單行，因此它減少了空間。請檢視以下顯示如何執行規範化的表。

規範化之前的表

規範化後的表

行分割

行分割傾向於在分割槽之間保留一對一對映。行分割的目的在於透過減小表的大小來加快對大表的訪問速度。

注意 - 使用垂直分割槽時，請確保不需要在兩個分割槽之間執行主要的連線操作。

確定分割槽的鍵

選擇正確的分割槽鍵非常關鍵。選擇錯誤的分割槽鍵會導致事實表重新組織。讓我們舉個例子。假設我們要對下表進行分割槽。

Account_Txn_Table
transaction_id
account_id
transaction_type
value
transaction_date
region
branch_name

我們可以選擇對任何鍵進行分割槽。兩個可能的鍵可能是

• 區域
• 交易日期

假設業務分佈在30個地理區域，每個區域的支行數量不同。這將給我們帶來30個分割槽，這是合理的。這種分割槽方案足夠好，因為我們的需求捕獲顯示，絕大多數查詢都限制在使用者自己的業務區域內。

如果我們按交易日期而不是區域進行分割槽，那麼每個區域的最新交易都將位於同一個分割槽中。現在，想要檢視自己區域內資料的使用者必須跨多個分割槽進行查詢。

因此，確定正確的分割槽鍵非常重要。

資料倉庫 - 元資料概念

什麼是元資料？

元資料簡單地定義為關於資料的資料。用於表示其他資料的資料被稱為元資料。例如，書籍的索引充當書籍內容的元資料。換句話說，我們可以說元資料是引導我們獲取詳細資料的彙總資料。在資料倉庫方面，我們可以將元資料定義如下：

• 元資料是資料倉庫的路線圖。

• 資料倉庫中的元資料定義了倉庫物件。

• 元資料充當目錄。此目錄幫助決策支援系統定位資料倉庫的內容。

注意 - 在資料倉庫中，我們為給定資料倉庫的資料名稱和定義建立元資料。除了這些元資料之外，還會為任何提取的資料的時間戳、提取資料的來源建立附加元資料。

元資料的類別

元資料可以大致分為三類：

• 業務元資料 - 它包含資料所有權資訊、業務定義和變更策略。

• 技術元資料 - 它包括資料庫系統名稱、表和列的名稱和大小、資料型別和允許的值。技術元資料還包括結構資訊，例如主鍵和外部索引鍵屬性以及索引。

• 操作元資料 - 它包括資料的有效性和資料血統。資料的有效性是指資料是活動狀態、已歸檔還是已清除。資料血統是指資料遷移的歷史記錄以及應用於它的轉換。

元資料的角色

元資料在資料倉庫中扮演著非常重要的角色。元資料在倉庫中的作用與倉庫資料不同，但它起著重要的作用。元資料的各種作用解釋如下：

• 元資料充當目錄。

• 此目錄幫助決策支援系統定位資料倉庫的內容。

• 當資料從操作環境轉換為資料倉庫環境時，元資料幫助決策支援系統進行資料對映。

• 元資料有助於在當前詳細資料和高度彙總的資料之間進行彙總。

• 元資料還有助於在輕度詳細資料和高度彙總的資料之間進行彙總。

• 元資料用於查詢工具。

• 元資料用於提取和清洗工具。

• 元資料用於報表工具。

• 元資料用於轉換工具。

• 元資料在載入功能中發揮著重要作用。

下圖顯示了元資料的角色。（此處應插入圖表）

元資料倉庫

元資料倉庫是資料倉庫系統不可或缺的一部分。它包含以下元資料：

• 資料倉庫的定義 - 它包括對資料倉庫結構的描述。該描述由模式、檢視、層次結構、派生資料定義以及資料市場位置和內容定義。

• 業務元資料 - 它包含資料所有權資訊、業務定義和變更策略。

• 操作元資料 - 它包括資料的有效性和資料血統。資料的有效性是指資料是活動狀態、已歸檔還是已清除。資料血統是指資料遷移的歷史記錄以及應用於它的轉換。

• 從操作環境到資料倉庫的對映資料 - 它包括源資料庫及其內容、資料提取、資料分割槽清理、轉換規則、資料重新整理和清除規則。

• 彙總演算法 - 它包括維度演算法、粒度資料、聚合、彙總等。

元資料管理的挑戰

元資料的重要性怎麼強調都不為過。元資料有助於提高報告的準確性，驗證資料轉換，並確保計算的準確性。元資料還向業務終端使用者強制執行業務術語的定義。儘管元資料有這些用途，但它也面臨挑戰。下面討論其中一些挑戰。

• 大型組織中的元資料分散在整個組織中。這些元資料分散在電子表格、資料庫和應用程式中。

• 元資料可能存在於文字檔案或多媒體檔案中。為了將這些資料用於資訊管理解決方案，必須對其進行正確的定義。

• 沒有行業通用的公認標準。資料管理解決方案供應商關注面狹窄。

• 沒有簡單易行且公認的元資料傳遞方法。

資料倉庫 - 資料市場

為什麼我們需要資料市場？

以下是建立資料市場的理由：

• 對資料進行分割槽以實施訪問控制策略。

• 透過減少要掃描的資料量來加快查詢速度。

• 將資料分割到不同的硬體平臺。

• 以適合使用者訪問工具的形式組織資料。

注意 - 不要因為其他任何原因建立資料市場，因為資料市場操作成本可能非常高。在進行資料市場之前，請確保資料市場策略適合您的特定解決方案。

經濟高效的資料市場

請遵循以下步驟，使資料市場經濟高效：

• 識別功能分割
• 識別使用者訪問工具需求
• 識別訪問控制問題

識別功能分割

在此步驟中，我們確定組織是否有自然的功能分割。我們尋找部門分割，並確定部門使用資訊的方式是否傾向於與組織的其餘部分隔離。讓我們舉個例子。

考慮一個零售組織，每個商家負責最大限度地提高一組產品的銷售額。為此，以下資訊非常有價值：

• 每日銷售交易
• 每週銷售預測
• 每日庫存狀況
• 每日庫存變動

由於商家對他們不經手的產品不感興趣，因此資料市場是與相關產品組相關的部分資料子集。下圖顯示了不同使用者的元資料。（此處應插入圖表）

以下是確定功能分割時需要考慮的問題：

• 部門的結構可能會發生變化。

• 產品可能會從一個部門轉移到另一個部門。

• 商家可以查詢其他產品的銷售趨勢，以分析銷售情況。

注意 - 我們需要確定使用資料市場的業務優勢和技術可行性。

識別使用者訪問工具需求

我們需要資料市場來支援需要內部資料結構的使用者訪問工具。此類結構中的資料不受資料倉庫的控制，但需要定期填充和更新。

有些工具可以直接從源系統填充資料，但有些工具不行。因此，需要確定未來工具範圍之外的其他需求。

注意 - 為了確保所有訪問工具之間的資料一致性，資料不應直接從資料倉庫填充，而每個工具都必須擁有自己的資料市場。

識別訪問控制問題

應該有隱私規則，以確保只有授權使用者才能訪問資料。例如，零售銀行機構的資料倉庫確保所有帳戶都屬於同一個法律實體。隱私法可能會迫使您完全阻止訪問非特定銀行擁有的資訊。

資料市場允許我們透過物理隔離資料倉庫內的部分資料來構建完整的隔離牆。為避免可能的隱私問題，可以從資料倉庫中刪除詳細資料。我們可以為每個法律實體建立資料市場，並透過資料倉庫載入它，其中包含詳細的帳戶資料。

設計資料市場

資料市場應設計為資料倉庫內星型雪花模式的較小版本，並應與資料倉庫的資料庫設計相匹配。這有助於控制資料庫例項。

摘要以與在資料倉庫內設計相同的方式進行資料市場化。彙總表有助於利用星型雪花模式中的所有維度資料。

資料市場成本

資料市場的成本度量如下：

• 硬體和軟體成本
• 網路訪問
• 時間視窗約束

硬體和軟體成本

雖然資料市場是在相同的硬體上建立的，但它們需要一些額外的硬體和軟體。為了處理使用者查詢，它需要額外的處理能力和磁碟儲存空間。如果詳細資料和資料市場存在於資料倉庫中，那麼我們將面臨儲存和管理複製資料的額外成本。

注意 - 資料市場比聚合更昂貴，因此應將其用作附加策略，而不是替代策略。

網路訪問

資料市場可能位於與資料倉庫不同的位置，因此我們應確保區域網或廣域網具有處理資料市場載入過程中傳輸的資料量的能力。

時間視窗約束

資料市場載入過程在多大程度上會佔用可用時間視窗，取決於轉換的複雜性和正在傳輸的資料量。確定有多少資料市場取決於：

• 網路容量。
• 可用時間視窗
• 正在傳輸的資料量
• 用於將資料插入資料市場的機制

資料倉庫 - 系統管理員

系統管理對於成功實施資料倉庫是強制性的。最重要的系統管理員是：

• 系統配置管理員
• 系統排程管理員
• 系統事件管理員
• 系統資料庫管理員
• 系統備份恢復管理員

系統配置管理員

• 系統配置管理員負責管理資料倉庫的安裝和配置。

• 配置管理員的結構因作業系統而異。

• 在 Unix 配置結構中，管理員因供應商而異。

• 配置管理員具有單一使用者介面。

• 配置管理員的介面允許我們控制系統的各個方面。

注意 - 最重要的配置工具是 I/O 管理器。

系統排程管理員

系統排程管理員負責資料倉庫的成功實施。其目的是排程臨時查詢。每個作業系統都有自己的排程程式，具有一定的批處理控制機制。系統排程管理員必須具備的功能列表如下：

• 跨叢集或 MPP 邊界工作
• 處理國際時差
• 處理作業失敗
• 處理多個查詢
• 支援作業優先順序
• 重新啟動或重新排隊失敗的作業
• 作業完成後通知使用者或程序
• 在系統中斷期間維護作業排程
• 將作業重新排隊到其他佇列
• 支援啟動和停止佇列
• 記錄排隊的作業
• 處理佇列間處理

注意 - 以上列表可用作評估優秀排程程式的評估引數。

排程程式必須能夠處理的一些重要作業如下：

• 每日和臨時查詢排程
• 執行定期報表需求
• 資料載入
• 資料處理
• 索引建立
• 備份
• 聚合建立
• 資料轉換

注意 − 如果資料倉庫執行在叢集或MPP架構上，則系統排程管理器必須能夠跨架構執行。

系統事件管理器

事件管理器是一種軟體。事件管理器管理在資料倉庫系統上定義的事件。由於資料倉庫的結構非常複雜，我們無法手動管理資料倉庫。因此，我們需要一個工具來自動處理所有事件，無需任何使用者干預。

注意 − 事件管理器監控事件的發生並處理它們。事件管理器還會跟蹤此複雜資料倉庫系統中可能出現的大量問題。

事件

事件是由使用者或系統本身生成的動作。需要注意的是，事件是定義動作的可測量、可觀察的發生。

以下是需要跟蹤的常見事件列表。

• 硬體故障
• 某些關鍵磁碟空間不足
• 程序終止
• 程序返回錯誤
• CPU使用率超過80%閾值
• 資料庫序列化點上的內部競爭
• 緩衝區快取命中率超過或低於閾值
• 表達到最大尺寸
• 過度記憶體交換
• 由於空間不足，表無法擴充套件
• 磁碟出現I/O瓶頸
• 臨時或排序區域的使用達到某個閾值
• 任何其他資料庫共享記憶體使用情況

事件最重要的方面是它們應該能夠自行執行。事件包定義了預定義事件的過程。與每個事件關聯的程式碼稱為事件處理程式。每當發生事件時，都會執行此程式碼。

系統和資料庫管理器

系統和資料庫管理器可能是兩塊獨立的軟體，但它們執行相同的工作。這些工具的目標是自動化某些流程並簡化其他流程的執行。選擇系統和資料庫管理器的標準如下：

• 增加使用者的配額。
• 為使用者分配和取消分配角色
• 為使用者分配和取消分配配置檔案
• 執行資料庫空間管理
• 監控和報告空間使用情況
• 整理碎片化和未使用的空間
• 新增和擴充套件空間
• 新增和刪除使用者
• 管理使用者密碼
• 管理彙總表或臨時表
• 為使用者分配或取消分配臨時空間
• 回收舊的或過時的臨時表的空間
• 管理錯誤和跟蹤日誌
• 瀏覽日誌和跟蹤檔案
• 重定向錯誤或跟蹤資訊
• 啟用和停用錯誤和跟蹤日誌記錄
• 執行系統空間管理
• 監控和報告空間使用情況
• 清理舊的和未使用的檔案目錄
• 新增或擴充套件空間。

系統備份恢復管理器

備份和恢復工具使運維和管理人員可以輕鬆備份資料。請注意，系統備份管理器必須與正在使用的排程管理器軟體整合。管理備份所需的重要功能如下：

• 排程
• 備份資料跟蹤
• 資料庫感知

僅為了防止資料丟失而進行備份。以下是需要記住的重要事項：

• 備份軟體將保留某種形式的資料庫，記錄資料片段的備份位置和時間。

• 備份恢復管理器必須具有良好的前端資料庫。

• 備份恢復軟體應該具有資料庫感知能力。

• 瞭解資料庫後，軟體就可以用資料庫術語來處理，並且不會執行不可行的備份。

資料倉庫 - 流程管理器

流程管理器負責維護資料進出資料倉庫的流程。有三種不同型別的流程管理器：

• 載入管理器
• 倉庫管理器
• 查詢管理器

資料倉庫載入管理器

載入管理器執行將資料提取並載入到資料庫中所需的運算。載入管理器的規模和複雜性因不同資料倉庫的特定解決方案而異。

載入管理器架構

載入管理器執行以下功能：

• 從源系統提取資料。

• 將提取的資料快速載入到臨時資料儲存區。

• 執行簡單的轉換，使其結構類似於資料倉庫中的結構。

從源提取資料

資料從運營資料庫或外部資訊提供者提取。閘道器是用於提取資料的應用程式程式。它由底層DBMS支援，並允許客戶端程式生成要在伺服器上執行的SQL。開放資料庫連線 (ODBC) 和 Java 資料庫連線 (JDBC) 是閘道器的示例。

快速載入

• 為了最大限度地縮短總載入時間，需要以最快速度將資料載入到倉庫中。

• 轉換會影響資料處理速度。

• 在應用轉換和檢查之前，將資料載入到關係資料庫中更有效。

• 閘道器技術不適用，因為當涉及大量資料時，它們效率低下。

簡單的轉換

載入時，可能需要執行簡單的轉換。完成簡單的轉換後，我們可以進行復雜的檢查。假設我們正在載入EPOS銷售交易，我們需要執行以下檢查：

• 去除倉庫中不需要的所有列。
• 將所有值轉換為所需的資料型別。

倉庫管理器

倉庫管理器負責倉庫管理流程。它由第三方系統軟體、C程式和shell指令碼組成。倉庫管理器的規模和複雜性因特定解決方案而異。

倉庫管理器架構

倉庫管理器包括以下內容：

• 控制流程
• 儲存過程或帶有 SQL 的 C 程式碼
• 備份/恢復工具
• SQL指令碼

倉庫管理器的功能

倉庫管理器執行以下功能：

• 分析資料以執行一致性和引用完整性檢查。

• 針對基礎資料建立索引、業務檢視、分割槽檢視。

• 生成新的聚合並更新現有的聚合。

• 生成規範化。

• 將臨時儲存區的源資料轉換併合併到已釋出的資料倉庫中。

• 備份資料倉庫中的資料。

• 存檔已達到捕獲壽命結束的資料。

注意 − 倉庫管理器分析查詢配置檔案以確定索引和聚合是否合適。

查詢管理器

查詢管理器負責將查詢定向到合適的表。透過將查詢定向到合適的表，它可以加快查詢請求和響應過程。此外，查詢管理器還負責排程使用者釋出的查詢的執行。

查詢管理器架構

查詢管理器包括以下元件：

• 透過C工具或RDBMS進行查詢重定向
• 儲存過程
• 查詢管理工具
• 透過C工具或RDBMS進行查詢排程
• 透過第三方軟體進行查詢排程

查詢管理器的功能

• 它以使用者理解的形式向用戶呈現資料。

• 它排程終端使用者釋出的查詢的執行。

• 它儲存查詢配置檔案，以允許倉庫管理器確定哪些索引和聚合是合適的。

資料倉庫 - 安全性

資料倉庫的目標是使大量資料易於使用者訪問，從而允許使用者提取有關整個業務的資訊。但我們知道，對資料可能施加某些安全限制，這可能會成為訪問資訊的障礙。如果分析師對資料的檢視受到限制，則不可能捕獲業務內趨勢的完整畫面。

可以對來自每個分析師的資料進行彙總，然後傳遞給管理層，管理層可以對不同的彙總進行聚合。由於彙總的聚合可能與整體聚合不同，因此除非有人對整體資料進行分析，否則可能會錯過資料中的一些資訊趨勢。

安全需求

新增安全功能會影響資料倉庫的效能，因此儘早確定安全需求非常重要。資料倉庫上線後很難新增安全功能。

在資料倉庫的設計階段，我們應該記住以後可能會新增哪些資料來源以及新增這些資料來源的影響。在設計階段，我們應該考慮以下可能性。

• 新的資料來源是否需要實施新的安全和/或審計限制？

• 是否添加了對現有公開可用資料具有受限訪問許可權的新使用者？

當未來的使用者和資料來源未知時，就會出現這種情況。在這種情況下，我們需要利用業務知識和資料倉庫的目標來了解可能的需求。

以下活動會受到安全措施的影響：

• 使用者訪問
• 資料載入
• 資料移動
• 查詢生成

使用者訪問

我們首先需要對資料進行分類，然後根據使用者可以訪問的資料對使用者進行分類。換句話說，使用者根據他們可以訪問的資料進行分類。

資料分類

可以使用以下兩種方法對資料進行分類：

• 可以根據資料的敏感性對資料進行分類。高度敏感的資料被歸類為高度限制，而不太敏感的資料被歸類為限制較少。

• 還可以根據職能對資料進行分類。此限制僅允許特定使用者檢視特定資料。在這裡，我們限制使用者只能檢視他們感興趣且負責的那部分資料。

第二種方法存在一些問題。為了理解這一點，讓我們舉一個例子。假設您正在為一家銀行構建資料倉庫。假設資料倉庫中儲存的資料是所有賬戶的交易資料。這裡的問題是，誰被允許檢視交易資料。解決方案在於根據職能對資料進行分類。

使用者分類

可以使用以下方法對使用者進行分類：

• 可以根據組織中使用者的層次結構對使用者進行分類，即可以按部門、科室、組等對使用者進行分類。

• 還可以根據使用者的角色對使用者進行分類，根據其角色對跨部門的人員進行分組。

基於部門的分類

讓我們以一個數據倉庫為例，其使用者來自銷售和市場部門。我們可以透過自上而下的公司檢視來實現安全性，訪問許可權集中在不同的部門。但是，不同級別的使用者可能會有一些限制。此結構如下圖所示。

但是，如果每個部門訪問不同的資料，那麼我們應該分別為每個部門設計安全訪問許可權。這可以透過部門資料市場來實現。由於這些資料市場與資料倉庫分離，因此我們可以對每個資料市場強制執行單獨的安全限制。此方法如下圖所示。

基於角色的分類

如果資料通常對所有部門可用，那麼遵循角色訪問層次結構是有用的。換句話說，如果資料通常被所有部門訪問，則根據使用者的角色應用安全限制。角色訪問層次結構如下圖所示。

審計要求

審計是安全的一個子集，是一項成本高昂的活動。審計可能會給系統帶來沉重的開銷。為了及時完成審計，我們需要更多硬體，因此，建議儘可能關閉審計。審計要求可以分類如下：

• 連線
• 斷開連線
• 資料訪問
• 資料更改

注意 - 對於上述每一類，都需要審計成功、失敗或兩者兼而有之。從安全原因的角度來看，失敗的審計非常重要。審計失敗很重要，因為它們可以突出未經授權或欺詐性的訪問。

網路要求

網路安全與其他安全一樣重要。我們不能忽視網路安全需求。我們需要考慮以下問題：

• 在將資料傳輸到資料倉庫之前，是否有必要對其進行加密？

• 對資料可以採取哪些網路路由有限制嗎？

需要仔細考慮這些限制。以下是需要記住的幾點：

• 加密和解密過程會增加開銷。這需要更多的處理能力和處理時間。

• 如果系統已經是負載較高的系統，則加密成本可能很高，因為加密是由源系統承擔的。

資料移動

移動資料時存在潛在的安全隱患。假設我們需要將一些受限資料作為平面檔案傳輸以進行載入。當資料載入到資料倉庫中時，會提出以下問題：

• 平面檔案儲存在哪裡？
• 誰有權訪問該磁碟空間？

如果我們談論這些平面檔案的備份，則會提出以下問題：

• 您是備份加密版本還是解密版本？
• 這些備份是否需要製作到單獨儲存的特殊磁帶上？
• 誰有權訪問這些磁帶？

還需要考慮其他形式的資料移動，例如查詢結果集。建立臨時表時提出的問題如下：

• 臨時表應該儲存在哪裡？
• 如何使這樣的表可見？

我們應該避免意外違反安全限制。如果具有訪問受限資料的使用者可以生成可訪問的臨時表，則未經授權的使用者可以檢視資料。我們可以透過為具有訪問受限資料的使用者提供單獨的臨時區域來克服這個問題。

文件

需要對審計和安全要求進行適當的記錄。這將被視為證明的一部分。此文件可以包含從以下方面收集的所有資訊：

• 資料分類
• 使用者分類
• 網路要求
• 資料移動和儲存要求
• 所有可審計的操作

安全對設計的影響

安全性會影響應用程式程式碼和開發時間。安全性會影響以下方面：

• 應用程式開發
• 資料庫設計
• 測試

應用程式開發

安全性會影響整體應用程式開發，還會影響資料倉庫重要元件（如載入管理器、倉庫管理器和查詢管理器）的設計。載入管理器可能需要檢查程式碼以過濾記錄並將它們放置在不同的位置。也可能需要更多轉換規則來隱藏某些資料。此外，可能需要額外的元資料來處理任何額外的物件。

為了建立和維護額外的檢視，倉庫管理器可能需要額外的程式碼來強制執行安全性。可能需要將額外的檢查編碼到資料倉庫中，以防止它被欺騙地將資料移動到不應提供資料的位置。查詢管理器需要更改以處理任何訪問限制。查詢管理器需要了解所有額外的檢視和聚合。

資料庫設計

資料庫佈局也會受到影響，因為當實施安全措施時，檢視和表的數量會增加。新增安全性會增加資料庫的大小，從而增加資料庫設計和管理的複雜性。它還會增加備份管理和恢復計劃的複雜性。

測試

測試資料倉庫是一個複雜且漫長的過程。向資料倉庫新增安全性也會影響測試時間複雜度。它會透過以下兩種方式影響測試：

• 它會增加整合和系統測試所需的時間。

• 需要測試的附加功能會增加測試套件的大小。

資料倉庫 - 備份

資料倉庫是一個複雜的系統，它包含大量資料。因此，重要的是要備份所有資料，以便根據需要在將來將其用於恢復。在本章中，我們將討論設計備份策略中的問題。

備份術語

在繼續之前，您應該瞭解下面討論的一些備份術語。

• 完整備份 - 它同時備份整個資料庫。此備份包括所有資料庫檔案、控制檔案和日誌檔案。

• 部分備份 - 顧名思義，它不會建立資料庫的完整備份。部分備份在大型資料庫中非常有用，因為它們允許一種策略，即資料庫的各個部分每天以迴圈方式進行備份，以便每週有效地備份整個資料庫一次。

• 冷備份 - 冷備份是在資料庫完全關閉時進行的。在多例項環境中，所有例項都應關閉。

• 熱備份 - 熱備份是在資料庫引擎執行時進行的。熱備份的要求因 RDBMS 而異。

• 線上備份 - 它與熱備份非常相似。

硬體備份

確定使用哪種硬體進行備份非常重要。處理備份和恢復的速度取決於使用的硬體、硬體的連線方式、網路頻寬、備份軟體和伺服器 I/O 系統的速度。在這裡，我們將討論一些可用的硬體選擇及其優缺點。這些選擇如下：

• 磁帶技術
• 磁碟備份

磁帶技術

磁帶選擇可以分類如下：

• 磁帶介質
• 獨立磁帶驅動器
• 磁帶堆疊器
• 磁帶庫

磁帶介質

存在多種磁帶介質。下表列出了一些磁帶介質標準：

其他需要考慮的因素如下：

• 磁帶介質的可靠性
• 每單位磁帶介質的成本
• 可擴充套件性
• 磁帶系統升級成本
• 每單位磁帶介質的成本
• 磁帶介質的儲存期限

獨立磁帶驅動器

磁帶驅動器可以透過以下方式連線：

• 直接連線到伺服器
• 作為網路可用裝置
• 遠端連線到其他機器

將磁帶驅動器連線到資料倉庫可能會出現問題。

• 假設伺服器是 48 節點 MPP 機器。我們不知道連線磁帶驅動器的節點，也不知道如何將它們分佈在伺服器節點上以獲得最佳效能，同時最大限度地減少伺服器中斷和內部 I/O 延遲。

• 將磁帶驅動器連線為網路可用裝置需要網路能夠處理巨大的資料傳輸速率。確保在您需要時有足夠的頻寬可用。

• 遠端連線磁帶驅動器也需要高頻寬。

磁帶堆疊器

將多個磁帶載入到單個磁帶驅動器中的方法稱為磁帶堆疊器。堆疊器在完成當前磁帶後解除安裝它並載入下一盤磁帶，因此一次只能訪問一盤磁帶。價格和功能可能會有所不同，但常見的功能是它們可以執行無人值守的備份。

磁帶庫

磁帶庫提供大型儲存容量。磁帶庫可以儲存和管理數千盤磁帶。它們可以整合多個磁帶驅動器。它們具有標記和儲存所儲存磁帶的軟體和硬體。磁帶庫通常透過網路或專用鏈路遠端連線。我們應該確保連線的頻寬能夠勝任這項工作。

磁碟備份

磁碟備份的方法是：

• 磁碟到磁碟備份
• 映象中斷

這些方法用於 OLTP 系統。這些方法最大限度地減少資料庫停機時間並最大限度地提高可用性。

磁碟到磁碟備份

這裡備份是在磁碟上而不是磁帶上進行的。磁碟到磁碟備份的原因如下：

• 初始備份速度
• 恢復速度

從磁碟到磁碟備份資料比到磁帶快得多。然而，這是備份的中間步驟。之後，資料將備份到磁帶上。磁碟到磁碟備份的另一個優點是它為您提供了最新備份的線上副本。

映象中斷

我們的目標是將磁碟映象，以提高工作日的資料恢復能力。當需要備份時，可以將其中一個映象集分離出來。此技術是磁碟到磁碟備份的一種變體。

注意 − 為保證備份的一致性，可能需要關閉資料庫。

光碟庫

光碟庫允許資料進行近線儲存。這項技術允許以與磁帶機或磁帶庫相同的方式管理大量光碟。這項技術的缺點是寫入速度比磁碟慢。但光學介質具有長壽命和可靠性，使其成為歸檔的良好介質選擇。

軟體備份

有一些可用的軟體工具可以幫助進行備份過程。這些軟體工具作為一個軟體包提供。這些工具不僅可以進行備份，還可以有效地管理和控制備份策略。市場上有很多可用的軟體包。其中一些列在下面的表格中：

選擇軟體包的標準

選擇最佳軟體包的標準列在下面：

• 隨著磁帶驅動器的增加，產品的可擴充套件性如何？
• 該軟體包是否具有客戶端-伺服器選項，或者它必須在資料庫伺服器本身上執行？
• 它是否可以在叢集和MPP環境中工作？
• 需要多少程度的並行性？
• 該軟體包支援哪些平臺？
• 該軟體包是否支援輕鬆訪問有關磁帶內容的資訊？
• 該軟體包是否瞭解資料庫？
• 該軟體包支援哪些磁帶驅動器和磁帶介質？

資料倉庫 - 調優

資料倉庫不斷發展，使用者將來要釋出什麼查詢是不可預測的。因此，調整資料倉庫系統變得更加困難。在本章中，我們將討論如何調整資料倉庫的不同方面，例如效能、資料載入、查詢等。

資料倉庫調優的難點

由於以下原因，調整資料倉庫是一個困難的過程：

• 資料倉庫是動態的；它永遠不會保持不變。

• 很難預測使用者將來要釋出什麼查詢。

• 業務需求會隨著時間而變化。

• 使用者及其配置檔案不斷變化。

• 使用者可以從一個組切換到另一個組。

• 倉庫上的資料負載也會隨著時間而變化。

注意 − 掌握資料倉庫的完整知識非常重要。

效能評估

以下是效能的客觀衡量指標列表：

• 平均查詢響應時間
• 掃描速率
• 每天查詢所用的時間
• 每個程序的記憶體使用量
• I/O吞吐率

以下是需要記住的幾點。

• 有必要在服務級別協議 (SLA) 中指定這些指標。

• 如果響應時間已經優於所需時間，則嘗試調整響應時間是沒有用的。

• 進行效能評估時，必須要有現實的期望。

• 使用者也必須要有可行的期望。

• 為了向用戶隱藏系統的複雜性，應使用聚合和檢視。

• 使用者也可能編寫您尚未對其進行調優的查詢。

資料載入調優

資料載入是夜間處理的關鍵部分。在資料載入完成之前，其他任何操作都不能執行。這是進入系統的入口點。

注意 − 如果資料傳輸或資料到達出現延遲，則整個系統將受到嚴重影響。因此，首先調整資料載入非常重要。

下面將討論各種資料載入調優方法：

• 非常常見的方法是使用SQL層插入資料。在這種方法中，需要執行正常的檢查和約束。當資料插入表中時，程式碼將執行以檢查是否有足夠的儲存空間來插入資料。如果可用空間不足，則可能需要為這些表分配更多空間。這些檢查需要時間來執行，並且對CPU的消耗很大。

• 第二種方法是繞過所有這些檢查和約束，並將資料直接放置到預格式化的塊中。這些塊稍後寫入資料庫。它比第一種方法快，但它只能與整個資料塊一起工作。這可能會導致一些空間浪費。

• 第三種方法是在將資料載入到已包含資料的表中時，我們可以維護索引。

• 第四種方法是，要將資料載入到已經包含資料的表中，則在資料載入完成後刪除索引並重新建立它們。第三種方法和第四種方法之間的選擇取決於已經載入了多少資料以及需要重建多少索引。

完整性檢查

完整性檢查會嚴重影響載入的效能。以下是需要記住的幾點：

• 需要限制完整性檢查，因為它們需要大量的處理能力。

• 應在源系統上應用完整性檢查，以避免資料載入效能下降。

查詢調優

資料倉庫中有兩種查詢：

• 固定查詢
• 臨時查詢

固定查詢

固定查詢定義明確。以下是固定查詢的示例：

• 定期報表
• 預定義查詢
• 常用聚合

資料倉庫中固定查詢的調優與關係資料庫系統中的調優相同。唯一的區別是需要查詢的資料量可能不同。在測試固定查詢時，最好儲存最成功的執行計劃。儲存這些執行計劃將使我們能夠發現變化的資料大小和資料傾斜，因為它會導致執行計劃發生變化。

注意 − 我們不能對事實表做更多的事情，但在處理維度表或聚合時，可以使用通常的SQL調整、儲存機制和訪問方法集合來調整這些查詢。

臨時查詢

要了解臨時查詢，重要的是要知道資料倉庫的臨時使用者。對於每個使用者或使用者組，您需要了解以下內容：

• 組中使用者的數量
• 他們是否定期使用臨時查詢
• 他們是否經常使用臨時查詢
• 他們是否偶爾在未知的時間間隔內使用臨時查詢。
• 他們傾向於執行的查詢的最大大小
• 他們傾向於執行的查詢的平均大小
• 他們是否需要對基礎資料的向下鑽取訪問
• 每天經過的登入時間
• 每日使用高峰時間
• 他們每小時高峰期執行的查詢數量

需要注意的幾點

• 重要的是跟蹤使用者的配置檔案並識別定期執行的查詢。

• 同樣重要的是，所執行的調優不會影響效能。

• 識別經常執行的相似和臨時查詢。

• 如果識別出這些查詢，則資料庫將發生更改，並且可以為這些查詢新增新索引。

• 如果識別出這些查詢，則可以專門為這些查詢建立新的聚合，這將導致其高效執行。

資料倉庫 - 測試

測試對於資料倉庫系統至關重要，以確保其正確有效地工作。資料倉庫上執行了三個基本的測試級別：

• 單元測試
• 整合測試
• 系統測試

單元測試

• 在單元測試中，每個元件都會單獨進行測試。

• 每個模組，即過程、程式、SQL指令碼、Unix shell 都將進行測試。

• 此測試由開發人員執行。

整合測試

• 在整合測試中，應用程式的各個模組將組合在一起，然後針對多個輸入進行測試。

• 它用於測試各個元件在整合後是否執行良好。

系統測試

• 在系統測試中，整個資料倉庫應用程式將一起進行測試。

• 系統測試的目的是檢查整個系統是否一起正常工作。

• 系統測試由測試團隊執行。

• 由於整個資料倉庫的規模非常大，通常在測試計劃可以執行之前，只能執行最少的系統測試。

測試計劃

首先，在開發測試計劃的過程中建立測試計劃。在此計劃中，我們預測整個資料倉庫系統測試所需的估計時間。

有不同的方法可用於建立測試計劃，但沒有一種是完美的，因為資料倉庫非常複雜且規模龐大。此外，資料倉庫系統本身也在不斷發展。在建立測試計劃時，可能會遇到以下問題：

• 一個簡單的問題可能會有一個很大的查詢，可能需要一天或更長時間才能完成，即查詢沒有在期望的時間範圍內完成。

• 可能出現硬體故障，例如丟失磁碟或人為錯誤，例如意外刪除表或覆蓋大型表。

注意 − 由於上述困難，建議始終將您通常允許的測試時間加倍。

測試備份恢復

測試備份恢復策略極其重要。以下是需要此測試的場景列表：

• 介質故障
• 表空間或資料檔案丟失或損壞
• 重做日誌檔案丟失或損壞
• 控制檔案丟失或損壞
• 例項故障
• 歸檔檔案丟失或損壞
• 表丟失或損壞
• 資料故障期間發生故障

測試操作環境

需要測試許多方面。這些方面列在下面。

• 安全性 − 需要單獨的安全文件進行安全測試。此文件包含不允許的操作列表以及為每個操作設計測試。

• 排程程式 − 需要排程軟體來控制資料倉庫的日常操作。它需要在系統測試期間進行測試。排程軟體需要與資料倉庫介面，這需要排程程式來控制夜間處理和聚合的管理。

• 磁碟配置。 − 還需要測試磁碟配置以識別I/O瓶頸。應使用不同的設定多次執行測試。

• 管理工具。 − 需要在系統測試期間測試所有管理工具。以下是需要測試的工具列表。

  • 事件管理器
  • 系統管理器
  • 資料庫管理器
  • 配置管理器
  • 備份恢復管理器

測試資料庫

資料庫以以下三種方式進行測試：

• 資料庫管理器和監控工具測試 − 要測試資料庫管理器和監控工具，應將其用於測試資料庫的建立、執行和管理。

• 資料庫功能測試 − 以下是我們必須測試的功能列表：

  • 並行查詢

  • 並行建立索引

  • 並行資料載入

• 資料庫效能測試 − 查詢執行在資料倉庫效能指標中扮演著非常重要的角色。需要定期執行一組固定的查詢，並且應該對其進行測試。為了測試臨時查詢，應該仔細閱讀使用者需求文件並完全理解業務。需要花時間測試業務可能針對不同索引和聚合策略提出的最棘手的查詢。

應用程式測試

• 所有管理器都應正確整合並協同工作，以確保端到端的載入、索引、聚合和查詢能夠按預期工作。

• 每個管理器的每個功能都應正常工作。

• 還需要對應用程式進行一段時間內的測試。

• 還應測試周末和月末任務。

測試的邏輯

系統測試的目的是測試所有以下領域：

• 排程軟體
• 日常操作程式
• 備份恢復策略
• 管理和排程工具
• 夜間處理
• 查詢效能

注意 − 最重要的點是測試可擴充套件性。未能做到這一點將導致我們設計的系統在系統增長時無法工作。

資料倉庫 - 未來展望

以下是資料倉庫的未來展望。

• 正如我們所看到的，開放式資料庫的大小在過去幾年中增長了大約兩倍，這表明它包含著巨大的價值。

• 隨著資料庫規模的增長，構成超大型資料庫的估算值也在不斷增長。

• 當今可用的硬體和軟體不允許保留大量線上資料。例如，電信呼叫記錄需要保留 10TB 的線上資料，這僅僅是一個月記錄的大小。如果需要保留銷售、市場營銷客戶、員工等記錄，那麼大小將超過 100TB。

• 記錄包含文字資訊和一些多媒體資料。多媒體資料不像文字資料那樣容易操作。搜尋多媒體資料並非易事，而文字資訊可以通過當今可用的關係軟體檢索。

• 除了規模規劃外，構建和執行規模不斷增長的資料倉庫系統也很複雜。隨著使用者數量的增加，資料倉庫的大小也會增加。這些使用者也將需要訪問系統。

• 隨著網際網路的發展，使用者需要線上訪問資料。

因此，資料倉庫的未來形態將與今天正在建立的形態大相徑庭。