在數據倉庫技術以前，只存在事務處理，DBMS系統為這種處理類型的需要提供支持。但是，在數據倉庫中的處理是截然不同的。數據倉庫環境中的處理類型可以概括為裝載和訪問過程。數據從原來操作型數據環境和ODS中集成、轉換和裝載到數據倉庫中去。一旦進入數據倉庫，集成的數據就在那里訪問和分析。在數據倉庫中，數據一旦被裝載，通常是不更新的。如果需要對數據倉庫更正和調整的話，也是在對數據倉庫數據沒有分析操作的空閑時間進行。而且，這些改變也是通過加入一個當前的數據快照來完成。

傳統的事務處理數據庫環境和數據倉庫環境的另一個重要的區別在于，數據倉庫環境中有很多的數據，比一般的操作型環境中要多得多，以萬億或千萬億計，而一個通用的DBMS通常管理下的傳統事務處理數據庫中的數據要少得多。數據倉庫要管理大量的數據，是因為它們包括如下內容：

• 粒化的原子細節。
• 歷史信息。
• 細節和匯總數據。

談到基本的數據管理功能，數據倉庫用與標準的操作型DBMS非常不同的一組參數進行優化。

傳統的通用DBMS和數據倉庫專用DBMS的第一個也是最重要的區別在于數據更新是如何進行的。傳統的通用DBMS必須將記錄級的、基于事務的更新作為一個正常的操作部分。由于記錄級、基于事務的數據更新是通用DBMS的一般特征，所以它必須提供以下功能：

• 鎖定。
• 提交。
• 檢查點。
• 日志磁帶處理。
• 死鎖。
• 逆向恢復。

不僅這些特征確實已成為DBMS一個常規部分，它們的開銷也是巨大的。有趣的是，當DBMS不使用時也要耗費這筆開銷。換句話說，當通用DBMS僅執行只讀操作時，DBMS也至少要提供更新和鎖定的開銷（取決于DBMS）。根據不同的通用DBMS，更新所需的開銷能不同程度地最小化，但不能完全沒有。而對于一個數據倉庫專用的DBMS來說，不用支付任何更新所需的開銷。

通用DBMS和數據倉庫專用DBMS之間的第二個主要區別是對基本數據的管理的不同。對于通用的DBMS來說，對數據在塊級上的管理要包括一些附加的空間，這些空間是用于以后更新和插入數據時塊的擴展。一般情況下，這些空間是自由空間。對于通用DBMS，自由空間可能占到50%。對于數據倉庫專用的DBMS，根本就不需要自由空間，因為數據一旦裝入到數據倉庫后是不需要更新的，也就沒有物理塊擴展的需要。事實上，給定了數據倉庫中要管理的數據量后，留下以后將永遠不會用到的大量空間是沒有任何意義的。

數據倉庫和通用環境之間的另一個相關的區別反映在不同類型的DBMS上，是索引的區別。通用DBMS環境限制在有限數量的索引，這個限制是因為當有數據的更新和插入時，索引本身需要空間和數據管理。然而，在數據倉庫環境中沒有數據的更新，卻有必要對數據的訪問進行優化，也有多種索引的必要(和機會)。事實上，數據倉庫相對于操作型的、面向更新的數據庫來說，能夠應用更穩健和更完善的索引結構。

除了索引、更新和物理塊級上的基本數據管理以外，在數據管理能力和策略上，通用DBMS和數據倉庫專用DBMS之間還存在其他一些基本區別。其中，這兩種類型的DBMS最基本的區別可能是在物理上以優化方式組織數據以適應不同類型訪問的能力。通用DBMS在物理上組織數據是為了優化事務的訪問和處理。以這種方式進行的組織使得許多不同類型的數據可以根據一個公共關鍵字聚集起來，并能有效地通過1次或2次I/O訪問。最適合于信息型訪問的數據通常具有一個區別很大的物理描述。最適合于信息型訪問的數據是經過組織的，可以使對同一類型數據的許多不同值能夠通過1次或2次物理I/O高效地進行訪問。

數據能夠在物理上得到優化以便于事務訪問或DSS訪問，但無法同時做到這兩點。通用的、基于事務的DBMS只針對事務訪問對數據進行優化，而數據倉庫專用的DBMS則針對DSS訪問和分析在物理上對數據進行優化。

1.改變DBMS技術

信息倉庫需要考慮的一個有趣的因素是，在數據倉庫數據已經載入以后， DBMS技術發生變化。有以下幾個原因說明進行這種改變：

• 當今可用的DBMS技術，在數據倉庫首次載入數據時并不一定適合。
• 數據倉庫大小已經增長到一定的程度，要求提出新的技術方法。
• 對數據倉庫的使用逐步增加，也發生了很多變化，使得當前的數據倉庫的DBMS技術不滿足要求了。
• 需要不時地對基本的DBMS選擇進行審查。

是否應考慮找一種新的DBMS技術？要考慮的因素是什么？以下的幾點非常重要：

• 新的DBMS技術是否滿足可預知的需求？
• 從舊的DBMS技術向新的DBMS技術的轉換應該怎樣去做？
• 轉換的程序應該怎樣改變？

所有的這些考慮因素中，最后一個是最令人頭痛的。即使在最好的情況下，試圖去改變轉換程序也是一項很復雜的工作。

事實上，一旦數據倉庫已經采用了一個DBMS，在以后某個時間進行更改是可能的。但這種情況在事務處理的過程中是永遠不可能的，因為一旦采用了一個DBMS，只要事務處理系統仍在運行當中，這個DBMS就必須保持不動。

2.多維DBMS和數據倉庫

一項在數據倉庫中經常討論的技術是多維數據庫管理系統處理（有時稱為OLAP處理）。多維數據庫管理系統或者數據集市提供了一種信息系統結構，這種結構可以使企業靈活地對數據進行訪問，可以用多種方法對數據進行切片、分塊，動態地考察匯總數據和細節數據之間的關系。多維DBMS為最終用戶提供了靈活性和控制功能。為此，它非常適合于DSS環境。如圖1所示，多維DBMS和數據倉庫之間存在著非常有趣和互補的關系。

圖1  數據倉庫的傳統結構以及當前細節數據是如何同部門數據（或多維DBMS，數據集市）結合起來的

數據倉庫中的細節數據為多維DBMS提供了非常穩健和方便的數據源。因為多維DBMS需要定期地刷新，為此，數據要定期從數據倉庫中導入到多維DBMS中。由于歷史應用數據在進入數據倉庫時被集成，多維DBMS就不再需要從操作型環境中抽取與集成它所需要的數據。另外，數據倉庫在最低級別上保存了數據，這樣就能為那些使用多維DBMS的用戶在需要的時候進行的低級別分析提供“基礎”數據。

可能有人會認為多維DBMS技術應該是用于數據倉庫的數據庫技術，事實上除一些非常特殊的情況外，這種想法是不正確的。那些為了多維DBMS技術的功能而對其進行優化的性質并不是數據倉庫的最基本的重要特性。數據倉庫中最重要的特性也不是多維DBMS技術的特性。

看一下數據倉庫和多維DBMS的區別：

• 數據倉庫有大量的數據；多維DBMS中的數據至少要少一個數量級。
• 數據倉庫只適于少量的靈活訪問；而多維DBMS適合大量的不可預知的數據訪問和分析。
• 數據倉庫內存儲了很長時間范圍內的數據（從5年到10年）；而多維DBMS中只存儲較短時間范圍內的數據。
• 數據倉庫只允許分析人員以受限的形式訪問數據，而多維DBMS允許自由的訪問。
• 多維DBMS和數據倉庫有著互補的關系，而并不是數據倉庫建立在多維DBMS之上的關系。

數據倉庫和多維DBMS關系中有趣的一點是，數據倉庫可以為非常細節的數據提供基礎，而這些數據在多維DBMS中通常是看不到的。數據倉庫能容納非常詳細的數據，這些數據在導入多維DBMS時被輕度綜合了。而導入到多維DBMS之后，數據會被進一步地匯總。在這種模式下，多維DBMS可以包含除了非常細節以外的所有數據。使用多維DBMS的分析者可以以一種靈活而高效的方法來對多維DBMS中所有不同層次的數據進行鉆取。如果需要，分析者還可以向下鉆取到數據倉庫。通過這種方式將數據倉庫和多維DBMS相結合，DSS分析者可以得到這二者的好處，在大部分時間里在多維DBMS中享受操作高效的優點。同時，還可以向下鉆取到最低層次的細節數據。

另一個優勢是匯總的信息在多維DBMS中計算和聚集后存儲在數據倉庫中。這樣，匯總數據在數據倉庫中能比在多維DBMS中存儲更長的時間。

數據倉庫和多維DBMS還有一個方面也是互補的。多維DBMS存放中等時間長度的數據，根據應用的不同從12個月到15個月。而數據倉庫存放數據的時間跨度要大得多—從5年到10年。基于這一點，數據倉庫就成為多維DBMS分析者進行研究的數據源。如果需要，多維DBMS分析者可以高興地知道有大量的可用數據，而不用為在他們的環境中存儲所有這些數據而進行花費。

多維DBMS有不同的特色。一些多維DBMS建立在關系模型基礎上，而另一些多維DBMS建立在能優化“切片和分塊”數據的基礎上，在這里數據可以認為存儲在多維立方體內。后者的技術基礎可以稱為立方體基礎或OLAP基礎。

兩種技術基礎都支持多維DBMS數據集市。但在這兩種技術基礎之間存在著一些差異。

多維DBMS數據集市的關系型基礎如下：

• 優點：

能支持大量數據。

能支持數據的動態連接。

已被證實是有效的技術。

能夠支持通用的數據更新處理。

如果對數據的使用模式不清楚，關系型結構與其他結構一樣好。

• 弱點：

性能上不是最佳的。

不能夠對訪問處理進行優化。

多維DBMS數據集市的立方體基礎如下：

• 優點：

對DSS處理在性能上是優化的。

能夠對數據的非常快的訪問進行優化。

如果已知數據訪問的模式，則數據的結構可以優化。

能夠很輕松地進行切片和分塊。

可以用許多途徑進行檢測。

• 弱點：

無法處理像標準關系模式那么多的數據。

不支持通用更新處理。

裝載的時間很長。

如果想選取的訪問路徑不被數據設計所支持，這種結構就顯得不靈活。

對數據的動態連接的支持是有問題的。

多維DBMS(OLAP)是一種技術，而數據倉庫是一種體系結構基礎。這兩者之間存在著依存的關系。在通常情況下，數據倉庫是作為需要流入多維DBMS的數據的基礎，將選出的細節數據的子集轉入多維DBMS，在那里對數據進行匯總或聚集。但在某些范圍內，有一種觀點是多維DBMS并不需要數據倉庫作為它的數據的基礎。

如果沒有數據倉庫作為多維DBMS的基礎，那么裝入多維DBMS中的數據就是直接從舊的、歷史應用環境中得到的。圖2展示了數據直接從歷史環境中裝入多維DBMS中的情形。由于它很直接，并且很容易實現，所以這種方法很吸引人。一個程序員能立刻開始工作來建造它。

圖2  從沒有當前細節數據的應用建立多維DBMS數據集市

不幸的是，圖2所示的體系結構中有一些并不是那么明顯的主要缺陷。由于各種各樣的原因，將數據倉庫中的當前細節級的數據裝入多維DBMS環境提供數據比將歷史應用的操作型環境中的數據裝入其中更具意義。

圖3展示了將數據倉庫的當前細節級的數據裝入多維DBMS環境中。在導入數據倉庫的過程中，對舊的、歷史的操作型數據進行了集成和轉換。

圖3   從應用環境流入當前細節級再到多維DBMS數據集市的數據流

一旦到了數據倉庫以后，被集成的數據就以當前細節數據的級別存儲。多維DBMS就是要載入數據倉庫中這一級別的數據。

初看起來，圖2和圖3所示的兩種結構之間似乎并沒有本質上的區別。事實上，將數據首先裝入到數據倉庫中似乎是浪費精力。但是，有一個非常好的理由說明為什么創建多維DBMS的第一步是將數據集成到數據倉庫中。

考慮一下在通常情況下，一個公司需要建立多個多維DBMS。金融部門需要自己的多維DBMS，財務部門也需要。市場部、銷售部和其他部門也都需要自己的多維DBMS。因為在公司里會有眾多的多維DBMS，所以圖2所示的情形會變得非常復雜。在圖4中，將圖2擴展成了一個實際的情形。眾多的多維DBMS直接而獨立地從歷史系統環境中獲得數據。

圖4   有許多的應用和許多的數據集市，每對之間都需要一個接口。回避細節數據的當前級的后果是產生一個無法管理的“蜘蛛網”

圖4表明，眾多的多維DBMS直接從相同的歷史應用中獲得數據。那么，這種結構有什么問題呢？問題如下：

• 抽取數據所需進行的開發量是巨大的。每一個不同的部門多維DBMS都需要定制開發一套適合自己的抽取程序。抽取處理過程有大量的重疊。這樣，浪費的開發工作量很大。當多維DBMS是從數據倉庫中抽取數據時，它只需要一套集成和轉換的程序。
• 當多維DBMS是從歷史系統環境中直接抽取數據時，并沒有數據的集成基礎。每個部門的多維DBMS對于怎樣從不同的應用中集成數據都有自己的解釋。不幸的是，通常一個部門集成數據的方法和其他部門對相同數據的集成方法是不同的。結果導致最終沒有單一集成的、確定的數據源。相反地，在建造數據倉庫時，有一個能夠作為構造基礎的單一的、集成的、確定的數據源。
• 維護所進行的開發工作量是巨大的。在舊的傳統應用中，僅僅一個改變就會影響許多抽取程序。有抽取程序的地方由于這個改變而做一些改動，而且這種改動會很多。當有了數據倉庫后，由于只需要寫很少的程序來處理歷史環境和數據倉庫的接口，所以應用中的改變所產生的影響也是最小的。
• 需要消耗的硬件資源的數量是很大的。對于每一個部門的每一個抽取處理，同樣的歷史數據都要順序地重復傳送。而在數據倉庫中，歷史數據只需要傳送一次來刷新數據倉庫中的數據。
• 從歷史環境中將數據直接導入多維DBMS環境中的復雜性無法對元數據進行有效的管理和控制。在數據倉庫中，捕獲和管理元數據可以直接進行。
• 缺乏數據的一致性。當不同的部門之間存在意見分歧時，各自都有自己的多維DBMS，很難解決。但用數據倉庫后，沖突的解決是很自然并且很容易的。
• 每次必須構建一個新的多維DBMS環境，而且必須根據歷史環境建立，所需要的工作量是相當可觀的。然而，如果數據基礎是在一個數據倉庫中，建造一個新的多維DBMS環境將快速而容易。

如果一個企業考慮的是一種短期的方法，那么數據倉庫代價的合理性分析將很難進行。如果從長期來看，構建許多多維數據庫環境所需的費用是非常高的。而當一個企業從長期的觀點出發建立一個數據倉庫時，則數據倉庫和數據集市所需的長期總費用將會顯著降低。

作者簡介：William H.Inmon，世界公認的“數據倉庫之父”，企業信息工廠創造者之一。