資料倉儲設計指南(ZT)

資料倉儲設計指南

　　在資料倉儲的設計指導思想中，資料倉儲的概念定義是非常重要的，資料倉儲概念規定了資料倉儲所具有的幾個基本特性，這些特性也正是對資料倉儲設計結果進行檢驗的重要依據。

[@more@]

在一般的資料倉儲應用系統中，根據系統體系結構的不同，資料倉儲設計的內容和範圍不盡相同，並且設計方法也不盡相同，下面的兩幅圖示分別表示帶有ODS的資料倉儲應用系統體系結構和不帶ODS的資料倉儲應用系統體系結構。本文將說明兩個體系結構上的差異以及這種差異造成的設計方法的不同，並且重點介紹帶有ODS的體系結構中資料倉儲的設計方法。

在資料倉儲的設計指導思想中，資料倉儲的概念定義是非常重要的，資料倉儲概念規定了資料倉儲所具有的幾個基本特性，這些特性也正是對資料倉儲設計結果進行檢驗的重要依據。

根據Bill.Inmon的定義，“資料倉儲是面向主題的、整合的、穩定的、隨時間變化的，主要用於決策支援的資料庫系統”。

ODS（Operational Data Store）是資料倉儲體系結構中的一個可選部分，ODS具備資料倉儲的部分特徵和OLTP系統的部分特徵，它是“面向主題的、整合的、當前或接近當前的、不斷變化的”資料。

一般在帶有ODS的系統體系結構中，ODS都設計為如下幾個作用：

1） 在業務系統和資料倉儲之間形成一個隔離層。

一般的資料倉儲應用系統都具有非常複雜的資料來源，這些資料存放在不同的地理位置、不同的資料庫、不同的應用之中，從這些業務系統對資料進行抽取並不是一件容易的事。因此，ODS用於存放從業務系統直接抽取出來的資料，這些資料從資料結構、資料之間的邏輯關係上都與業務系統基本保持一致，因此在抽取過程中極大降低了資料轉化的複雜性，而主要關注資料抽取的介面、資料量大小、抽取方式等方面的問題。

2） 轉移一部分業務系統細節查詢的功能

在資料倉儲建立之前，大量的報表、分析是由業務系統直接支援的，在一些比較複雜的報表生成過程中，對業務系統的執行產生相當大的壓力。ODS的資料從粒度、組織方式等各個方面都保持了與業務系統的一致，那麼原來由業務系統產生的報表、細節資料的查詢自然能夠從ODS中進行，從而降低業務系統的查詢壓力。

3） 完成資料倉儲中不能完成的一些功能。

一般來說，帶有ODS的資料倉儲體系結構中，DW層所儲存的資料都是進行彙總過的資料，並不儲存每筆交易產生的細節資料，但是在某些特殊的應用中，可能需要對交易細節資料進行查詢，這時就需要把細節資料查詢的功能轉移到ODS來完成，而且ODS的資料模型按照面向主題的方式進行儲存，可以方便地支援多維分析等查詢功能。

在一個沒有ODS層的資料倉儲應用系統體系結構中，資料倉儲中儲存的資料粒度是根據需要而確定的，但一般來說，最為細節的業務資料也是需要保留的，實際上也就相當於ODS，但與ODS所不同的是，這時的細節資料不是“當前、不斷變化的”資料，而是“歷史的，不再變化的”資料。

設計方法

在資料倉儲設計方法和資訊模型建模方法中，前人的著作對各種思路和方法都做過大量的研究和對比，重點集中在ER模型和維模型的比較和應用上。根據我們的實踐經驗，ER模型和維模型在資料倉儲設計中並非絕對對立，尤其在ODS設計上，從宏觀的角度來看資料之間的關係，以ER模型最為清晰，但從實現出來的資料結構上看，用維模型更加符合實際的需要。因此孤立地看ER模型或者維模型都缺乏科學客觀的精神，需要從具體應用上去考慮如何應用不同的設計方法，但目標是一定的，就是要能夠把企業的資料從宏觀到微觀能夠清晰表達，並且能夠實現出來。

本文中重點介紹維模型的應用。

ODS設計指南

在ODS的概念定義中，已經描述了ODS的功能和特點，實際上ODS設計的目標就是以這些特點作為依據的。ODS設計與DW設計在著眼點上有所不同，ODS重點考慮業務系統資料是什麼樣子的，關係如何，在業務流程處理的哪個環節，以及資料抽取介面等問題。

第零步：資料調研

有關資料調研的內容和要求，在《調研規範》文件中做了詳細定義，此處不再重複。

第一步：確定資料範圍

確定資料範圍實際上是對ODS進行主題劃分的過程，這種劃分是基於對業務系統的調研的基礎上而進行的，並不十分關心整個資料倉儲系統上端應用需求，但是需要把上端應用需求與ODS資料範圍進行驗證，以確保應用所需的資料都已經從業務系統中抽取出來，並且得到了很好的組織。一般來講，主題的劃分是以業務系統的資訊模型為依據的，設計者需要綜合各種業務系統的資訊模型，並進行宏觀的歸併，得到企業範圍內的高層資料檢視，並加以抽象，劃定幾個邏輯的資料主題範圍。在這個階段，以ER模型表示資料主題關係最為恰當。

第二步：根據資料範圍進行進一步的資料分析和主題定義

在第一步中定義出來了企業範圍內的高層資料檢視，以及所收集到的各種業務系統的資料，在這一步中，需要對大的資料主題進行分解，並進行主題定義，直到每個主題能夠直接對應一個主題資料模型為止。在這個階段，將把第一步生成的每個ER圖中的實體進行分解，分解的結果仍以ER表示為佳。

第三步：定義主題元素

定義維、度量、主題、粒度、儲存期限

定義維的概念特性：

維名稱，名稱應該能夠清晰表示出這個維的業務含義。

維成員，也就是這個維所代表的具體的資料，

維層次，維成員之間的隸屬與包含的層次關係，每個層次需要定義名稱

定義度量的概念特性：

度量名稱，名稱應該能夠清晰標書這個度量的業務含義

定義主題的概念特性：

主題名稱和含義，說明該主題主要包含哪些資料，用於什麼分析；

主題所包含的維和度量；

主題的事實表，以及事實表的資料。

定義粒度：

主題中事實表的資料粒度說明，這種粒度可以透過對維的層次限制加以說明，也可以透過對事實表資料的業務細節程度進行說明。

定義儲存期限：

主題中事實表中的資料儲存週期。

第四步：迭代，歸併維、度量的定義

在ODS中，因資料來自於多個系統，資料主題劃分時雖然對資料概念進行了一定程度上的歸併，但具體的業務程式碼所形成的各個維、以及維成員等還需要進一步進行歸併，把概念統一的維定義成一個維，不允許同一個維存在不同的實體表示（象不同的業務系統中一樣）。

第五步：物理實現

定義每個主題的資料抽取週期、抽取時間、抽取方式、資料介面，抽取流程和規則。

物理設計不僅僅是ODS部分的資料庫物理實現，設計資料庫引數、作業系統引數、資料儲存設計之外，有關資料抽取介面等問題必須清晰定義。

DW設計指南

儘管我們看到過很多關於“不考慮應用，先建立資料平臺”的說法，但建立一個“萬能的”東西是不可能的，所以資料倉儲的設計必須參照應用範圍、應用型別，例如要考慮到系統用於報表、OLAP、資料探勘的哪些模型等等，不同的應用對資料倉儲的設計有不同的要求。

資料倉儲是面向主題的、整合的、穩定的、隨時間變化的資料，資料倉儲的這幾個特徵的含義在這裡不具體多介紹，但本人要說明如何實現這些特性。

在資料倉儲的設計中時刻不能忘記的幾個問題列舉如下：

1、 資料粒度和資料組織

在資料倉儲的每個主題，都必須知道這個主題所限定的維的層次、事實資料的粒度；事實資料儲存的期限，“過期”的資料的處理方法。

2、 維和度量的唯一性和公用性

千萬不要在不同的主題中定義多個表示同一內容的維，尤其對於業務程式碼型別的維，如果一個業務程式碼形成了多個維表，那麼在後設資料維護過程中將困難重重。在整個系統範圍內，要不斷檢視維定義是否唯一，如果有可能，一個維表要儘量被多個主題引用。

3、 資料粒度一旦變粗，就要考慮多個主題的融合彙總

在資料倉儲中，我們出於資料組織的規則、業務的要求、效能的要求，都可能對一個主題的事實資料進行彙總，形成粒度較粗的事實資料，但這時候我們往往忘記了粒度變粗的事實資料為最終的使用者提供了更宏觀的資料檢視，這種宏觀的資料檢視當然需要進行跨主題的資料融合才能更加具有應用的價值。

4、 不論如何歸併，需要保持資料之間的聯絡

在資料倉儲中，不同主題的資料之間的物理約束或許不再存在，但無論這些資料如何變化，要知道必須有一些“鍵”在邏輯上保持著不同資料之間的聯絡，這樣就可以保證有聯絡的主題資料之間可以進行彙總以支援未知的應用，否則資料倉儲的資料是一潭死水，不可能靈活支援各種應用的。

資料倉儲設計可以自底向上地進行，也就是說從彙總ODS資料入手，逐漸過渡到應用主題上面去（也就是說，ODS裡面的資料主題域與DW中的分析主題完全不是一回事）。我們仍然按部就班地逐項設計，這樣並不是完全限定設計思路和步驟，但可以有效地提醒設計者有哪些事情要做。

第一步：對ODS中的各個主題的事實資料進行時間上的彙總

ODS的事實資料是純細節的交易資料，進入ODS的第一步就是要按照時間維進行彙總，以實現初步的資訊沉澱。這種彙總不是隻進行一次，而是要制定下來彙總的級別，比如日彙總資訊保留3個月，月彙總資訊保留2年，年彙總資訊長期儲存（當然在時間粒度變粗的同時一般都伴隨著其他維粒度的變粗或者捨棄），我們最終一定要定義到何種程度的資料可以在資料倉儲中永久儲存為止的地步。

第二步：按照業務邏輯的規則，對資料進行歸併

把ODS中不同主題中的表示相同業務的資料（來自不同的業務系統）進行歸併，例如一般企業的客服系統（Call Center）都受理一部分業務，而這些業務受理與在營業廳或銷售店的受理是一樣的，因此這類資料要歸併到一起。

第三步：把包含細節過多的交易記錄進行拆分

事實上，一個交易記錄所包含的資訊內容非常豐富，往往超越了某個人或部門的分析需求，但不同的人有不同的關注點，因此為提高效能起見，我們需要把一個長記錄包含的資訊進行分析、分解、彙總。例如在電信企業中，經過二次批價後的通話詳單包含多種資訊，經過分析，它包括網路資訊、業務型別資訊、時間資訊、地理資訊、費用資訊這樣幾個類別的資訊，而每一類資訊都由幾個欄位來進行記錄。這些不同類別的資訊是很少有人都同時關心的，一般來說網管部門關心網路資訊，市場部門關心業務型別資訊，而時間資訊和地理資訊恰是所有部門都需要的。按照這樣的情況，我們把一條話單按照資訊內容進行拆分，拆分後進行彙總歸併，以支援不同部門的分析要求。當然，對於資料探勘應用，可能同時關心所有的資訊以發掘不同資訊之間的關係，但這種情況一則很少，二則真正的資料探勘更多的時候依賴於交易細節資料，也就是說，對於專題問題的研究可以從ODS中進行資料的再次處理。

第四步：彙總、再彙總

彙總的問題決不僅僅是為了提高效能而做的事情（當然彙總能夠有效提高效能），但彙總同時意味著更高程度的綜合，在這個過程中，我們會發現與ODS系統設計過程相反，我們從細節走向了宏觀，在ODS中我們初步確定了企業資訊模型，對企業資訊模型進行初步分解，再分解、再分解，得到了一個個的主題；在資料倉儲中，我們從一個個的主題開始，綜合、再綜合，我們沿著與ODS相反的方向，走向了企業的宏觀資料檢視。事實上在DW設計中，彙總、綜合的終極目標，是要在最後把多個主題彙總成為一個大的主題，而這個主題所包含的維度和度量就是這個企業執行的命脈指標，是企業老闆所最為關注的那幾個指標。

原文連結：http://blogger.org.cn/blog/more.asp?name=xueflhg&id=3849