資料倉儲中維度變化和事實變化的處理方法

. 維度慢慢改變。

你的應用必須反映出移植到倉庫中的資料來源所發生的資料變化。維表中的資料特別容易變化。但你怎麼維護記錄的歷史變化呢?

　　第一個也是最簡單的方法是重寫現有的記錄而不跟蹤變動。幸運的是，這個方法被許多維度所接受。例如，如果一個部門名稱從“財務”變為“財務和會計”，你很可能並不需要記錄這種歷史變化。但是，從客戶和學生的角度看，常常有必要保持跟蹤姓名、婚姻狀態、教育程度和其它屬性的變化——你的應用必要能夠獲得當前的以及歷史的數值。

　　管理維度慢慢改變的第二個方法是數值發生變化時建立一個新的記錄，並將舊的記錄標記為舊記錄。

　　第三個也是最後的一個方法是維護在維表的同一行中不同列的變化域的歷史數值。

　　到此，我們已經介紹瞭如何處理資料倉儲維度中的值的變化。但是分析服務維度怎麼處理呢?要反映屬性值的變化你必須重新處理維度。但是如果你完全處理維度，你就不得不也重新處理多維資料集，如果你的多維資料集包含大量資料，那這就可能不太現實了。幸運的是你可以經常使用漸進式更新(過程更新)選項來避免重新處理多維資料集。

　　 事實變化。

通常人們認為事實表中的記錄是靜態的——一旦這條記錄錄入到了倉庫中你的工作就結束了，是嗎?不幸的是這個回答是“它取決於。”在某些情況下像在一個資料倉儲跟蹤病人的住院情況，所有的記錄通常都是靜態的。如果你從1月1日到2月5日住院，那這條記錄不太可能改變。

　　但是考慮到零售行業，所有的銷售都不是最終的——我肯定你知道有些人經常將它們購買的貨物因為各種原因而退回商店。一些公司管理這種交易為一系列信用和負債來結算每筆交易。但在其它的情況下你必須更新或刪除事實表記錄，甚至在它們新增到了資料倉儲之後。例如，如果一個股票交易記錄不正確，用一個相反的交易來結算是不能接受的。還有另一個問題要考慮：你可能不希望你的客戶知道你的交易系統中存在的問題。甚至你希望他們只在資料被修正後才看到資料。

　　處理事實變化的一個方法是將資料放在暫存區域直到它經過了質量檢查，然後將其移植到倉庫中。然而有時甚至是最全面的測試也無法捕獲資料來源中的所有錯誤，你可能需要透過處理這些包含錯誤資料的部分來更新多維資料集。這就是為什麼有必要保持你的分析服務部分儘可能的小以便處理可以相對快一些。

　　另一個處理這個挑戰的方法是採用一個回寫分割槽。採用多維資料集回寫，你沒有真的改變關係資料倉儲中的資料;而是在一個單獨的分割槽中新增了一條記錄。當使用者查詢一個特殊的測量值組時，分析服務將只讀分割槽的資料和回寫分割槽的資料結合起來，然後顯示結果。當然，執行這樣的查詢計算會額外增加分析伺服器的執行時間，並會造成效能下降。

[@more@]