數據倉庫中匯總表和數據立方體維護的研究

摘 要：商務數據倉庫系統中，數據分析人員對數據倉庫的抽取查詢越來越頻繁。使用什么樣的技術來提高數據倉庫的查詢速度以及維護數據倉庫是一個重大技術問題。本文提出匯總delta表的概念，將數據的改變劃分為增值和更新兩個階段，縮短了以往在更新數據時數據倉庫鎖定的時間，提高了查詢效率。同時，通過數據立方體的構建，更直觀的呈現出數據分析模型。

關 鍵 詞：數據倉庫；匯總delta表；數據立方體；OLAP

中圖分類號：TP311 文獻標識碼：A

1 引言

隨著計算機應用技術和信息技術的不斷深入和發展，各種應用軟件的普及，應用系統中的數據也隨著日常工作而迅速增長，數據庫系統和數據倉庫系統正越來越多的走進人們的日常生活中，成為工作中不可或缺的一部分[1]。在確保查詢結果準確無誤的同時，人們更關心查詢效率和查詢維護的問題。影響查詢效率的因素有很多，諸如CPU的處理能力、計算機內存大小、I/O速度、存儲硬盤的容量、采取何種底層操作系統和數據庫管理系統等。

其中，數據庫管理系統逐漸成為管理信息系統的重要組成部分，各種基于數據庫的聯機事務處理（OLTP， On-Line Transaction Processing）和聯機分析處理（OLAP， On-Line Analysis Processing）正慢慢的轉變成為計算機應用的核心。同時，OLTP和OLAP的功能和數據倉庫系統的結合形成了一個完整的數據查詢分析以及維護的全方位系統。

數據倉庫是決策支持系統（DSS， Decision Support System）和聯機分析應用數據源的結構化數據環境，其研究和解決從數據庫中獲取信息的問題。數據倉庫之父William H. Inmon在出版的《Building the Data Warehouse》一書中指出，數據倉庫是一個面向主題的、集成的、相對穩定的、反映歷史變化的數據集合，用于支持管理決策[2]。

數據倉庫的出現，進一步拓展了數據庫系統，使得大容量的歷史數據分析成為可能。然而無論是在前期數據抽取，還是之后的轉換、加載以及維護過程中，傳統的方法都有一定的局限性，并且效率不高。因此，如何實現對數據倉庫的高效維護成為熱點問題。

2 匯總表和數據立方體的構建

數據倉庫中包含從多種獨立數據源中收集而來的信息，并整合到一個公共存儲庫中用于查詢和分析。通常來說，數據倉庫的設計是用于聯機分析處理（OLAP）的，其中的查詢整合了大量數據從而去探測系統運行狀況，發現異常或趨勢，為以后業務拓展做進一步的指導。

2.1 匯總表的構建

為了在數據倉庫環境中加速查詢速度，提高查詢效率，通常會構建大量匯總表（st， summary table）。數據倉庫中的數據是從各個基礎的數據源中抽取而來，而匯總表就是通過不同的維度來組合這些基礎數據，相當于不同的group-by屬性集合，以此代表數據源中基礎數據的聚合型物化視圖。同時，匯總表也會計算各類聚集函數，包括 。舉例來說，在數據倉庫系統中，rollup和cube運算符可以通過一條語句來定義一些諸如此類的匯總表[3]。

2.2 數據立方體的構建

由于數據倉庫是基于多維數據模型構建的，用于OLAP的數據平臺。因此，多維數據模型是數據倉庫的一大重要特點，也是數據倉庫應用和實現的一個重要方面。我們可以通過在數據組織和存儲上的優化，使其更適用于分析型的數據查詢和獲取。

多維數據模型是為了滿足用戶從多角度多層次進行數據查詢和分析的需要而建立起來的基于事實和維的數據庫模型，其應用主要還是為了實現OLAP功能。通過多維數據模型的數據展示并進一步查詢和獲取所需數據就是其作用的體現。但其真的作用的實現在于，可以根據不同的數據需求建立起各類不同的多維模型，并組成數據集市開放給不同的用戶群體使用，即根據需求進行定制[4]。

數據立方體（Data Cube）是多維模型的一個形象的說法。對于多維數據模型來說，其維度是不限的，而數據立方體僅限于三維模型，是多維數據模型的一個抽象實例。使用數據立方體一方面能夠更方便地解釋和描述；另一方面是為了更好的與傳統關系型數據庫二維表區別開來。

我們以某商貿公司為例，其代理的產品涉及很多大類，銷售市場范圍遍及全國。我們可以根據自己對數據的需要進行提取，如圖1所示，抽取數據形成一個三維數據模型，即數據立方體。通過構建數據立方體，能夠更直觀的分析銷售數據，從而通過進一步分析運算得到企業運營狀況。

3 啟發式算例

在數據倉庫中構建好匯總表和數據立方體之后，接下來重要的事情就是對他們的維護。因為數據的更新變動是收集在數據源中的，數據倉庫中的匯總表和數據立方體也必須及時更新從而反映出數據源的變化狀態。在進行更新時，匯總表作為數據倉庫中的視圖，可以從頭至尾一步步推算出來，或者運用增量維護技術計算出由于數據源變化而導致的視圖的變化。而數據立方體的維護主要用于展現不同角度的數據。

現在，我們考慮一個關于零售信息的數據倉庫，包含數百家零售商店的銷售終端（POS， Point of Sales）數據。pos數據儲存在數據倉庫中的一個大型pos表中，我們稱之為事實表(fact table)，這個表包含了在銷售交易中售出的每個商品的元組（即行數據）。每個元組表現為如下形式：

其中，元組的屬性分別是：

● storeID：銷售的商品所在商店的ID

● itemID：銷售的商品的ID

● date：商品銷售的日期

● qty：售出商品的數量

● price：售出商品的價格

需要指出的是，pos表允許包含重復的元組。比如，同一個商品在同一天的同一商店的不同交易中被售出。

另外，數據倉庫通常會儲存維表（dimension tables），維表中包含與事實表相關的信息。我們可以分別以“商店表”（stores）和“商品表”（items）表示商店的信息和商品的信息。表stores的主鍵是storeID，表items的主鍵是itemID。如下所示：

stores（storied， city， regio）

items（itemID， name， category， cost）

維表中的數據通常代表了維的層級，比如在維表stores中，city和region的包含關系。一個維層級本質上是維表屬性之間的一系列函數依賴。比如，在我們的示例的stores這個維表中，storeID在函數上決定了city，同時city在函數上決定了region。同樣在items這個維表中，itemID在函數上決定了name，category，cost。

在一個數據倉庫中，為了更快的響應聚集查詢，通常做法是把匯總表連接一個或多個維表之后，再儲存這些匯總表。這些都是物化視圖，他們聚集了基本表中的數據。

我們給出了4個基本的匯總表示例，如圖2所示。每一個都定義為物化sql視圖。我們假設這些視圖已經被選擇出來進行物化了，選擇的方法可以直接通過人工選擇，也可以通過Harinarayan等人提出的一種算法來實現[5]。

圖中視圖的名稱是用來反應group-by屬性的。比如，字母S代表storeID；字母I代表itemID，字母D代表date。記號sC代表商店所在的城市，sR代表商店所在的地區，iC代表商品的類別。舉例來說，示例中第3個視圖SiC_sales代表storeID和category是視圖在定義中的group-by屬性。

除了date作為一個維度（dimension）和度量（measure）使用外，圖2中的4個視圖能夠代表“數據立方體”的4種可能的點[5]。通常認為，數據的聚集僅僅從事實表而來，維層級信息的獲得是隱含的。然而，由于數據倉庫通常顯性地儲存維層級信息于維表中，我們在此擴展了“數據立方體”的概念，從而使其包括顯性連接維表，形式上的統一更有利于匯總表和數據立方體的維護。

4 匯總表和數據立方體的維護

4.1 匯總表的維護過程

隨著銷售交易的出現，新的pos數據會定期載入數據倉庫的大pos表中。然而，大多數的數據倉庫系統并不會馬上應用這些變動。相反，這些數據變動會被延期更新至數據倉庫中的基本表和匯總表中。更新過程是通過一個批處理窗口，每晚對數據倉庫進行更新。這種對數據變動的延遲更新可以帶來很多好處。比如，延遲變動期間允許數據分析人員查詢數據倉庫，從而能夠看到白天數據的連續快照，這樣能夠使維護更加高效。

在通常情況下，數據倉庫中涉及的變動操作僅僅是插入。但是為了結合本文中的啟發式算例，我們假定變動包括插入和刪除兩種操作。為了在“刪除”存在的情況下正確的維護一個聚集視圖，有必要在視圖中包含count(*)聚集函數。只有在count(*)函數存在的情況下，才有可能明確統計出視圖中group-by組的所有元組是否被刪除（即count(*)函數得到的結果為0）。

為了陳述的方便性，在本文中，我們假設維護僅僅針對于來自事實表的變動，而且被聚集的列不包含空值。當然，我們的算法可以輕易的擴展，從而能夠處理來自維表的變動，同樣也可以處理聚集列中的空值。

我們提出一種“匯總delta表方法”，通過它來維護圖2中的匯總表SID_sales。我們將該算法的維護過程分為兩個階段：

● 增值：構造并運算匯總delta表

● 更新：通過之前的delta表來更新匯總表

構造一個匯總delta表發生在增值功能期間，這期間不需要對匯總表進行鎖定，從而數據倉庫可以繼續被訪問查詢。待增值完成后，匯總表直到刷新功能期間才被鎖定，在此期間，匯總表通過匯總delta表進行更新[6]。

（1）增值過程：“增值”功能從延遲的一系列數據變動中新建一個匯總delta表。該匯總delta表代表了由事實表的變化導致的匯總表的凈變化。我們讓延遲的一系列待插入數據存放在表pod_ins中；延遲的一系列待刪除數據存放在表pos_del中。因此，匯總delta表就會通過下述sql語句得到，而不會訪問基本pos表。如圖3所示。

為了計算匯總delta表，我們首先對待插入的行和待刪除的行做個投影。在插入的行中，用1計數，別名為_count；用qty代表數量，別名為_quantity。反之，在刪除的行中，用相應的負數。之后，把結果加和并聚集，通過匯總表中相同的group-by屬性分組。最后，得出結果的聚集函數值表示匯總表中相應的聚集函數值的凈變動。

（2）更新過程：“更新”功能是把匯總delta表中的凈變化應用到匯總表中。更新SID_sales的方法如圖4所示。“更新”功能會輸入匯總delta表sd_SID_sales和匯總表SID_sales，并更新匯總表從而反映匯總delta表中的變化。為了簡單起見，我們假定pos表中沒有空值。

更新功能是一個快速運行的過程。除了涉及max和min的幾種個別情況，更新功能不需要訪問基本pos表。所有的聚集在“增值”功能中完成。匯總delta表給匯總表帶來單一的更新，而且匯總表中的每一行最多被更新一次。

圖4所示為一個嵌入式sql程序，用游標完成，過程如下：

一個游標c1被打開，用來遍歷匯總delta表sd_SID_sales中的每一行δt。對于每一個δt，會發出一個查詢，同時第2個游標c2被打開，用來在匯總表SID_sales中尋找一個匹配的行t（最多有一個匹配的t，因為匹配是基于group-by屬性的）。如果沒有找到一個匹配的行t，那么δt行就被插入到匯總表。否則，如果t被找到，將會使用游標c2更或者刪除它，這取決于t組中的所有行是否被刪除。

通過匯總delta表的增值和更新過程，能夠實現匯總表的完整維護，同時也縮短了了數據倉庫關閉的時間，大大的提高了效率。

4.2 數據立方體的維護過程

我們已經知道OLAP的操作是以查詢為主，即以SELECT操作為主。但是查詢過程有時很復雜，比如基于關系數據庫的查詢可以多表關聯，也可以使用COUNT、SUM、AVG、MAX、MIN等聚合函數。數據立方體的構建使得OLAP在基于多維模型定義的基礎上，使得一些常見的面向分析的操作更加直觀。

數據立方體常見的維護操作包括以下幾種：

● 鉆取（Drill-down）：是指在維的不同層次間的變化，從某一層降到下一層，將匯總數據拆分到更細節的粒度。

● 上卷（Roll-up）：鉆取的逆操作，即從較細粒度數據向更高粒度層的聚合。

● 切片（Slice）：選擇維度中的特定值進行分析。

● 切塊（Dice）：選擇維度中的特定區域數據進行分析。

● 旋轉（Pivot）：指維的位置互換，如同二維表行列轉換。

數據立方體進一步直觀化了多維數據模型，在分析處理數據的過程中，對數據立方體的維護能夠更清晰的給予數據分析人員以指導，從而更好的完成數據的抽取、轉換、裝載、分析過程。

5 結論

本文提出了在數據倉庫中構建匯總表和數據立方體的過程，同時給出了維護匯總表的匯總delta表算法，通過增值和更新兩階段的劃分，不僅有效縮短了數據倉庫在維護過程中關閉的時間，也提高了維護的效率，對特定數據倉庫的高效維護有一定指導意義。但仍存在需要進一步解決的問題，如多種匯總表混合維護的處理等，這些將是今后探索的重點。

參考文獻

[1] 西爾伯沙茨， 楊冬青. 譯數據庫系統概念[M]. 機械工業出版社， 2006，10.

[2] W.H.Inmon， 王志海. 數據倉庫[M].機械工業出版社， 2000，5.

[3] J. Gray， A. Bosworth， A. Layman， and H. Pirahesh. Data cube: A relational aggregation operator generalizing group-by， cross-tab， and sub-total. In Proceedings of the Twelfth IEEE International Conference on Data Engineering， 1996，2: 152-159.

[4] 李澤海. 數據倉庫中多維數據處理與查詢相關技術的研究[M]，吉林大學，2005.10:11-26.

[5] V. Harinarayan， A. Rajaraman， and J. Ullman. Implementing data cubes efficiently. In Jagadish and Mumick， 205-216.

[6] Inderpal Singh Mumick， Dallan Quass， Barinderpal Singh Mumick. Maintenance of data cubes and summary tables in a warehouse[J]. 1997， 26(2):100-111.