摘要：基于DB和DW的中間層ODS的數(shù)據(jù)存儲技術，從應用的角度分析設計了一個商業(yè)系統(tǒng)的即時OLAP系統(tǒng)。通過使用ODS克服了利用DW進行決策過于臃腫且不適合企業(yè)即時的中層決策的問題。
關鍵詞：數(shù)據(jù)倉庫（DW），操作數(shù)據(jù)存儲(ODS)，即時聯(lián)機分析處理(OLAP)
1．問題提出
面向主題的數(shù)據(jù)倉庫（DW）概念的提出，不但為有效地支持企業(yè)經營管理決策提供了一個全局一致的數(shù)據(jù)環(huán)境，也為歷史數(shù)據(jù)，綜合數(shù)據(jù)的處理提出了一種行之有效的解決方法。數(shù)據(jù)倉庫概念的提出也清楚的把數(shù)據(jù)處理劃分為了操作型處理和分析型處理兩種不同類型，從而建立起了DB-DW的兩層體系結構。但是有很多情況，DB-DW的兩層體系結構并不能涵蓋企業(yè)所有的數(shù)據(jù)處理要求，因為企業(yè)的數(shù)據(jù)處理雖然可以較為粗略的劃分成操作型和分析型兩部分，但這兩種類型也不是涇渭分明的，它們之間也有交叉的情況，譬如，有些是操作型的，但不適合在操作型DB中進行，而又有一些是分析型處理，但不適合在DW中進行。
比如我們開發(fā)的一個醫(yī)藥銷售公司的決策系統(tǒng)，按要求公司經理要解決什么商品該進貨了，各種商品近來的贏利情況，客戶的信任情況等等。要回答這些問題，他必須首先要弄清楚藥品的存貨是否充裕，還要了解該藥品近期的銷售情況，另外還要和別的藥品的庫存和銷售情況進行比較等。如果我們把這個決策分析過程放在原有的面向應用的分散DB系統(tǒng)中去完成的話，不一定得到每個部門的準確一致的信息，而要進行各部門間的協(xié)調配合，工作量勢必會很大，但如果把其放在DW中去進行分析的話，不但費時，而且會有很多的不必要的數(shù)據(jù)檢索存在。
對于上述問題可以借助于DB-DW的中間層ODS（操作數(shù)據(jù)存儲）來解決。它象DW一樣是一種面向主題，集成的數(shù)據(jù)環(huán)境，又象操作型DB一樣包含著全局一致的，細節(jié)的當前的數(shù)據(jù)。建立基于ODS的即時OLAP應用是應中層決策分析之需要的一種解決方案，它能很好的適應企業(yè)日常頻繁的中低層次的決策分析應用。
2．ODS技術和即時OLAP
2.1 操作數(shù)據(jù)存儲（ODS）
是用于支持企業(yè)日常的全局應用的數(shù)據(jù)集合，ODS的數(shù)據(jù)具有面向主題、集成的、可變的和數(shù)據(jù)是當前的或是接近當前的4個基本特征。ODS是介于DB和DW之間的一種數(shù)據(jù)存儲技術，和原來面向應用的分散的DB相比，ODS中的數(shù)據(jù)組織方式和數(shù)據(jù)倉庫（DW）一樣也是面向主題的和集成的，所以對進入ODS的數(shù)據(jù)也象進入數(shù)據(jù)倉庫的數(shù)據(jù)一樣進行轉化和集成處理。另外ODS只是存放當前或接近當前的數(shù)據(jù)，如果需要的話還可以對ODS中的數(shù)據(jù)進行增、刪和更新等操作，雖然DW中的數(shù)據(jù)也是面向主題和集成的，但這些數(shù)據(jù)一般不進行修改，所以ODS和DW的區(qū)別主要體現(xiàn)數(shù)據(jù)的可變性和當前性上。
2.2 即時OLAP
ODS主要是適應企業(yè)級的全局應用的需要而產生的，對它的應用主要是在即時"OLAP"的數(shù)據(jù)處理上。
我們在DW上實現(xiàn)OLAP主要是為了進行長期趨勢分析，DW中是數(shù)據(jù)量很大，所以OLAP應用的運行時間都比較長。在企業(yè)日常經營中，常常要進行一些非戰(zhàn)略的中層決策以實現(xiàn)企業(yè)的日常管理和控制，譬如，醫(yī)藥銷售公司經理要每周查看藥品的銷售情況，各地區(qū)的藥品銷售情況，業(yè)務員的業(yè)績情況等等，并且這種決策過程并不需要參考太多的歷史數(shù)據(jù)，主要是參考當前的或比較當前的數(shù)據(jù)，還需要比較快的執(zhí)行速度，可以把這種分析決策稱為"即時OLAP"。顯然利用DW不但運行的效率是無法讓人忍受而且也很難準確的反映近期的真實情況，ODS的建立克服了DW系統(tǒng)過于臃腫，處理時間過長和不適應即時OLAP的情況，提供給中層決策者以快捷準確的分析信息。
2.3 從DB向ODS轉化的實現(xiàn)機制
在DB-ODS的體系結構中，ODS的實現(xiàn)機制表現(xiàn)在其記錄系統(tǒng)定義的數(shù)據(jù)傳送關系上，如圖1所示。操作型環(huán)境中各分散的DB記錄經過過濾后形成了ODS系統(tǒng)的記錄系統(tǒng)，向ODS系統(tǒng)中提供數(shù)據(jù)。記錄系統(tǒng)定義了原有分散DB中那些數(shù)據(jù)送往ODS，并指明與ODS數(shù)據(jù)相應的數(shù)據(jù)表。通過ODS的定義可以把分散于應用的DB中的數(shù)據(jù)復制到ODS中去，這樣原來的分散DB中的記錄就形成了ODS中的面向主題的記錄。ODS維護著一個分析型的環(huán)境，數(shù)據(jù)處理簡單得多，實際需要的支持技術也很少。
圖1 從DB向ODS轉化機制
上圖沒有給出從ODS向DB轉化的實現(xiàn)機制，這種情況主要用在有關企業(yè)全局操作應用的情況，可以通過在ODS系統(tǒng)中存放一些參數(shù)表，它所反應的關系是ODS全局更新時必須要反應到所有DB中的相關記錄。此時，ODS是一個操作型環(huán)境，實現(xiàn)ODS所要求的技術跟原來的面向應用的分散的數(shù)據(jù)庫系統(tǒng)一樣，包括事務管理、封鎖管理、數(shù)據(jù)恢復等等技術。
3 基于ODS的藥品銷售即時OLAP應用的設計
我們知道ODS是介于DB和DW之間的一種新的數(shù)據(jù)存儲技術，它兼有DW和DB的特點，在開發(fā)即時OLAP系統(tǒng)時，其開發(fā)方式更接近DW的開發(fā)模式。
3.1 建立ODS
該藥品銷售公司原本的一個銷售數(shù)據(jù)庫管理系統(tǒng)數(shù)據(jù)庫結構如圖2所示，是分布在
圖2 源數(shù)據(jù)庫ER模型
ACCESS97數(shù)據(jù)庫中，分屬于財務，銷售和庫存等幾個數(shù)據(jù)庫中。
根據(jù)前面的分析，優(yōu)先選擇銷售區(qū)域，客戶和藥品三個在銷售領域最關切的的主題，把事務數(shù)據(jù)庫中涉及到此領域的數(shù)據(jù)轉入到ODS中。ODS（主要對照DW）邏輯模型的類別主要有星形模型，雪花模型和混合模型等三種，我們在開發(fā)ODS邏輯模型時用了星形模型。一個簡單的星形模型由一個事實表和若干個維表組成，而復雜的的星形模型可能包括數(shù)百個維表。星形模型從支持商務決策的角度定義了數(shù)據(jù)實體，它能客觀在實體中反映商務運行的規(guī)則和屬性，與后兩種模型相比，設計相對簡單，更容易被用戶所理解和接受，圖3是本系統(tǒng)的邏輯模型。
圖3 ODS的星形模型
定義記錄系統(tǒng)時，主要考慮如何將主題域的各個屬性分配到應用系統(tǒng)中去，這里主要考慮把各主題中的屬性分配到藥品銷售的操作環(huán)境中的銷售和庫存等子系統(tǒng)中。
3.2 數(shù)據(jù)采集
數(shù)據(jù)采集過程跨越分散DB操作環(huán)境和ODS分析環(huán)境。本系統(tǒng)中數(shù)據(jù)采集過程較為簡單，只需要按照ODS記錄系統(tǒng)和ODS記錄系統(tǒng)定義兩者之間的映射關系，將DB中的數(shù)據(jù)傳送到ODS，這里我們采用了SQL SERVER 7.0的DTS數(shù)據(jù)轉換服務，SQL SERVER 7.0的DTS（Data Transformation Services）提供了數(shù)據(jù)的提取，轉換和裝載的功能。利用SQL SERVER 7。0的輸入輸出向導創(chuàng)建DTS包，在復制時使用SNAPSHOT（快照類型）對ODS中的數(shù)據(jù)進行清除和重建，由于數(shù)據(jù)量不是很大，故可以取得很好的執(zhí)行效率。
關鍵詞：數(shù)據(jù)倉庫（DW），操作數(shù)據(jù)存儲(ODS)，即時聯(lián)機分析處理(OLAP)
1．問題提出
面向主題的數(shù)據(jù)倉庫（DW）概念的提出，不但為有效地支持企業(yè)經營管理決策提供了一個全局一致的數(shù)據(jù)環(huán)境，也為歷史數(shù)據(jù)，綜合數(shù)據(jù)的處理提出了一種行之有效的解決方法。數(shù)據(jù)倉庫概念的提出也清楚的把數(shù)據(jù)處理劃分為了操作型處理和分析型處理兩種不同類型，從而建立起了DB-DW的兩層體系結構。但是有很多情況，DB-DW的兩層體系結構并不能涵蓋企業(yè)所有的數(shù)據(jù)處理要求，因為企業(yè)的數(shù)據(jù)處理雖然可以較為粗略的劃分成操作型和分析型兩部分，但這兩種類型也不是涇渭分明的，它們之間也有交叉的情況，譬如，有些是操作型的，但不適合在操作型DB中進行，而又有一些是分析型處理，但不適合在DW中進行。
比如我們開發(fā)的一個醫(yī)藥銷售公司的決策系統(tǒng)，按要求公司經理要解決什么商品該進貨了，各種商品近來的贏利情況，客戶的信任情況等等。要回答這些問題，他必須首先要弄清楚藥品的存貨是否充裕，還要了解該藥品近期的銷售情況，另外還要和別的藥品的庫存和銷售情況進行比較等。如果我們把這個決策分析過程放在原有的面向應用的分散DB系統(tǒng)中去完成的話，不一定得到每個部門的準確一致的信息，而要進行各部門間的協(xié)調配合，工作量勢必會很大，但如果把其放在DW中去進行分析的話，不但費時，而且會有很多的不必要的數(shù)據(jù)檢索存在。
對于上述問題可以借助于DB-DW的中間層ODS（操作數(shù)據(jù)存儲）來解決。它象DW一樣是一種面向主題，集成的數(shù)據(jù)環(huán)境，又象操作型DB一樣包含著全局一致的，細節(jié)的當前的數(shù)據(jù)。建立基于ODS的即時OLAP應用是應中層決策分析之需要的一種解決方案，它能很好的適應企業(yè)日常頻繁的中低層次的決策分析應用。
2．ODS技術和即時OLAP
2.1 操作數(shù)據(jù)存儲（ODS）
是用于支持企業(yè)日常的全局應用的數(shù)據(jù)集合，ODS的數(shù)據(jù)具有面向主題、集成的、可變的和數(shù)據(jù)是當前的或是接近當前的4個基本特征。ODS是介于DB和DW之間的一種數(shù)據(jù)存儲技術，和原來面向應用的分散的DB相比，ODS中的數(shù)據(jù)組織方式和數(shù)據(jù)倉庫（DW）一樣也是面向主題的和集成的，所以對進入ODS的數(shù)據(jù)也象進入數(shù)據(jù)倉庫的數(shù)據(jù)一樣進行轉化和集成處理。另外ODS只是存放當前或接近當前的數(shù)據(jù)，如果需要的話還可以對ODS中的數(shù)據(jù)進行增、刪和更新等操作，雖然DW中的數(shù)據(jù)也是面向主題和集成的，但這些數(shù)據(jù)一般不進行修改，所以ODS和DW的區(qū)別主要體現(xiàn)數(shù)據(jù)的可變性和當前性上。
2.2 即時OLAP
ODS主要是適應企業(yè)級的全局應用的需要而產生的，對它的應用主要是在即時"OLAP"的數(shù)據(jù)處理上。
我們在DW上實現(xiàn)OLAP主要是為了進行長期趨勢分析，DW中是數(shù)據(jù)量很大，所以OLAP應用的運行時間都比較長。在企業(yè)日常經營中，常常要進行一些非戰(zhàn)略的中層決策以實現(xiàn)企業(yè)的日常管理和控制，譬如，醫(yī)藥銷售公司經理要每周查看藥品的銷售情況，各地區(qū)的藥品銷售情況，業(yè)務員的業(yè)績情況等等，并且這種決策過程并不需要參考太多的歷史數(shù)據(jù)，主要是參考當前的或比較當前的數(shù)據(jù)，還需要比較快的執(zhí)行速度，可以把這種分析決策稱為"即時OLAP"。顯然利用DW不但運行的效率是無法讓人忍受而且也很難準確的反映近期的真實情況，ODS的建立克服了DW系統(tǒng)過于臃腫，處理時間過長和不適應即時OLAP的情況，提供給中層決策者以快捷準確的分析信息。
2.3 從DB向ODS轉化的實現(xiàn)機制
在DB-ODS的體系結構中，ODS的實現(xiàn)機制表現(xiàn)在其記錄系統(tǒng)定義的數(shù)據(jù)傳送關系上，如圖1所示。操作型環(huán)境中各分散的DB記錄經過過濾后形成了ODS系統(tǒng)的記錄系統(tǒng)，向ODS系統(tǒng)中提供數(shù)據(jù)。記錄系統(tǒng)定義了原有分散DB中那些數(shù)據(jù)送往ODS，并指明與ODS數(shù)據(jù)相應的數(shù)據(jù)表。通過ODS的定義可以把分散于應用的DB中的數(shù)據(jù)復制到ODS中去，這樣原來的分散DB中的記錄就形成了ODS中的面向主題的記錄。ODS維護著一個分析型的環(huán)境，數(shù)據(jù)處理簡單得多，實際需要的支持技術也很少。
圖1 從DB向ODS轉化機制
上圖沒有給出從ODS向DB轉化的實現(xiàn)機制，這種情況主要用在有關企業(yè)全局操作應用的情況，可以通過在ODS系統(tǒng)中存放一些參數(shù)表，它所反應的關系是ODS全局更新時必須要反應到所有DB中的相關記錄。此時，ODS是一個操作型環(huán)境，實現(xiàn)ODS所要求的技術跟原來的面向應用的分散的數(shù)據(jù)庫系統(tǒng)一樣，包括事務管理、封鎖管理、數(shù)據(jù)恢復等等技術。
3 基于ODS的藥品銷售即時OLAP應用的設計
我們知道ODS是介于DB和DW之間的一種新的數(shù)據(jù)存儲技術，它兼有DW和DB的特點，在開發(fā)即時OLAP系統(tǒng)時，其開發(fā)方式更接近DW的開發(fā)模式。
3.1 建立ODS
該藥品銷售公司原本的一個銷售數(shù)據(jù)庫管理系統(tǒng)數(shù)據(jù)庫結構如圖2所示，是分布在
圖2 源數(shù)據(jù)庫ER模型
ACCESS97數(shù)據(jù)庫中，分屬于財務，銷售和庫存等幾個數(shù)據(jù)庫中。
根據(jù)前面的分析，優(yōu)先選擇銷售區(qū)域，客戶和藥品三個在銷售領域最關切的的主題，把事務數(shù)據(jù)庫中涉及到此領域的數(shù)據(jù)轉入到ODS中。ODS（主要對照DW）邏輯模型的類別主要有星形模型，雪花模型和混合模型等三種，我們在開發(fā)ODS邏輯模型時用了星形模型。一個簡單的星形模型由一個事實表和若干個維表組成，而復雜的的星形模型可能包括數(shù)百個維表。星形模型從支持商務決策的角度定義了數(shù)據(jù)實體，它能客觀在實體中反映商務運行的規(guī)則和屬性，與后兩種模型相比，設計相對簡單，更容易被用戶所理解和接受，圖3是本系統(tǒng)的邏輯模型。
圖3 ODS的星形模型
定義記錄系統(tǒng)時，主要考慮如何將主題域的各個屬性分配到應用系統(tǒng)中去，這里主要考慮把各主題中的屬性分配到藥品銷售的操作環(huán)境中的銷售和庫存等子系統(tǒng)中。
3.2 數(shù)據(jù)采集
數(shù)據(jù)采集過程跨越分散DB操作環(huán)境和ODS分析環(huán)境。本系統(tǒng)中數(shù)據(jù)采集過程較為簡單，只需要按照ODS記錄系統(tǒng)和ODS記錄系統(tǒng)定義兩者之間的映射關系，將DB中的數(shù)據(jù)傳送到ODS，這里我們采用了SQL SERVER 7.0的DTS數(shù)據(jù)轉換服務，SQL SERVER 7.0的DTS（Data Transformation Services）提供了數(shù)據(jù)的提取，轉換和裝載的功能。利用SQL SERVER 7。0的輸入輸出向導創(chuàng)建DTS包，在復制時使用SNAPSHOT（快照類型）對ODS中的數(shù)據(jù)進行清除和重建，由于數(shù)據(jù)量不是很大，故可以取得很好的執(zhí)行效率。