數(shù)據(jù)倉庫中匯總表和數(shù)據(jù)立方體維護的研究

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

關(guān) 鍵 詞：數(shù)據(jù)倉庫；匯總delta表；數(shù)據(jù)立方體；OLAP

中圖分類號：TP311 文獻(xiàn)標(biāo)識碼：A

1 引言

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

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

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

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

2 匯總表和數(shù)據(jù)立方體的構(gòu)建

數(shù)據(jù)倉庫中包含從多種獨立數(shù)據(jù)源中收集而來的信息，并整合到一個公共存儲庫中用于查詢和分析。通常來說，數(shù)據(jù)倉庫的設(shè)計是用于聯(lián)機分析處理（OLAP）的，其中的查詢整合了大量數(shù)據(jù)從而去探測系統(tǒng)運行狀況，發(fā)現(xiàn)異常或趨勢，為以后業(yè)務(wù)拓展做進一步的指導(dǎo)。

2.1 匯總表的構(gòu)建

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

2.2 數(shù)據(jù)立方體的構(gòu)建

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

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

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

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

3 啟發(fā)式算例

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

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

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

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

● itemID：銷售的商品的ID

● date：商品銷售的日期

● qty：售出商品的數(shù)量

● price：售出商品的價格

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

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

stores（storied， city， regio）

items（itemID， name， category， cost）

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

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

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

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

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

4 匯總表和數(shù)據(jù)立方體的維護

4.1 匯總表的維護過程

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

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

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

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

● 增值：構(gòu)造并運算匯總delta表

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

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

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

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

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

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

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

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

通過匯總delta表的增值和更新過程，能夠?qū)崿F(xiàn)匯總表的完整維護，同時也縮短了了數(shù)據(jù)倉庫關(guān)閉的時間，大大的提高了效率。

4.2 數(shù)據(jù)立方體的維護過程

我們已經(jīng)知道OLAP的操作是以查詢?yōu)橹鳎匆許ELECT操作為主。但是查詢過程有時很復(fù)雜，比如基于關(guān)系數(shù)據(jù)庫的查詢可以多表關(guān)聯(lián)，也可以使用COUNT、SUM、AVG、MAX、MIN等聚合函數(shù)。數(shù)據(jù)立方體的構(gòu)建使得OLAP在基于多維模型定義的基礎(chǔ)上，使得一些常見的面向分析的操作更加直觀。

數(shù)據(jù)立方體常見的維護操作包括以下幾種：

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

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

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

● 切塊（Dice）：選擇維度中的特定區(qū)域數(shù)據(jù)進行分析。

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

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

5 結(jié)論

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

參考文獻(xiàn)

[1] 西爾伯沙茨， 楊冬青. 譯數(shù)據(jù)庫系統(tǒng)概念[M]. 機械工業(yè)出版社， 2006，10.

[2] W.H.Inmon， 王志海. 數(shù)據(jù)倉庫[M].機械工業(yè)出版社， 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] 李澤海. 數(shù)據(jù)倉庫中多維數(shù)據(jù)處理與查詢相關(guān)技術(shù)的研究[M]，吉林大學(xué)，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.