結合我實際工作中的數據倉庫邏輯區域劃分
客戶提供的txt文件為source
數據庫中raw，cvt表為staging
fact表和dimension表為ODS(Operational Data Store)
MSOLAP中建立好的cube和dimension以後為BaseLine或者DataMart

數據倉庫邏輯區域

***Source System（源業務系統） -- Staging Area（暫存區） -- Operational Data Store（ODS，數據存儲區）-- Baseline（中央數據倉庫）/Datamart(數據集市)***

Staging Area：

主要是為了保證數據移動的順序進行而開設的增量性的數據存儲空間，它是源系統業務數據進入數據倉庫的緩存區。從業務系統到Staging的數據傳輸，應該避免復雜的數據處理，以保證數據的快速導入而盡量減少對業務系統的壓力。需要進入數據倉庫主題系統的數據首先快速傳輸到Staging Area，通過Staging Area再轉移到目標數據倉庫中。從業務系統（如ERP，PSP,NOTES）到Staging Area的數據傳輸，應該避免復雜的數據處理，以保證數據的快速導入而盡量避免對業務系統的壓力。一般，可以創建與OLTP交易系統結構相同的屬性，同時在Staging區域需要增加兩個屬性。

 1.Source Code  用來表示源系統

 2.Last Modification Date  用來獲得數據處理的時間

如果原來的數據中已有上述兩個屬性，則需要在新屬性中增加DW後綴進行標識。數據成功導入數據倉庫之後，應清空Staging Area中的數據。

Staging區域只是為了簡化或者使ETL過程，結構更合理，更利於管理等設置的中間存儲層，Staging層裏的數據理論上是可以對用戶不可見的，或者說更像一個技術策略，所以Staging層只是數據倉庫中的一個很小的技術模塊。

Staging層一般可以理解為數據緩沖層，用來接收源數據，在一定時間裏Hold住源數據，一邊後續處理，甚至重復處理，這些處理可以完全獨立於源系統。
 

Operational Data Store（ODS）:

ODS的數據作為數據倉庫系統數據存儲。ODS區域可以從系統上分為兩個部分：

 1.存放OLTP系統的歷史數據

    這部分數據需要考慮是否需要對OLTP中的數據進行LIFE CYCLE的記錄（包括交易數據 fact data和基礎數據 dimension data，即緩慢變化的處理 SCD）

 2.存放數據倉庫部分加工信息

    即通過ODS歷史數據經過整合後的信息，這些信息更加全面的反映出主題中某件事務的全貌。

ODS一般可以講是大型數據倉庫中一個獨立的系統或環境，是否需要ODS取決於業務需求，通常情況下，如果建立了ODS，那個ODS就要承擔較大的數據整合的任務，一邊數據倉庫主要集中於解決數據應用層面的需求，另外一般如果有ODS的話，ODS也會向外提供一定的應用，所以ODS是對用戶可見的，而不死附屬於數據倉庫的。

數據模型的建立要看系統更側重於解決什麽樣的業務問題，ODS理論上是一個兼具生產系統和分析系統特性的系統，所以要看建設ODS到底是為了解決分析系統多一些，還是為了解決生產系統問題多一些如果兩者兼顧，那麽對數據模型要求多層設計，分別滿足不同需求。
 

Baseline（中央數據倉庫）:

它是真正具有星型結構的多維數據存儲區，這個部分包括兩種實體（FACT ENTITY和DIMENSION ENTITY）。Baseline部分需要支持最細粒度級別，保證可以在最細粒度級別實現多維的分析。即能夠支持匯總數據以及明細數據的多維查詢。

FACT ENTITY:

   它是對某個事物（可能是某一筆交易，某一個項目，如一筆到貨明細，某一個任務令）的各方面信息的描述，描述行的屬性包括：該事物各方面的度量信息，相關度量信息的維度信息

DIMENSION ENTITY:

   此處的維度信息是與FACT ENTITY相關的維信息，包括很多FACT ENTITY共有的維度信息，比如時間維度等。以及某個FACT ENTITY需要的專有的維信息。Baseline部分需要能否支持最細粒度級別，可以保證最細粒度級別實現多維的分析。

Data Mart（數據集市）：

它是某個主題領域的專業的多維數據區。實現某一特定主題領域的多維查詢需求。這個部分也包括兩個實體（FACT ENTITY和DIMENSION ENTITY）兩部分，但是與Baseline不同的是這部分的FACT ENTITY和DIMENSION ENTITY都是為某一主題服務的。

數據倉庫邏輯區域及各區域的功能和特點