集結區
準備數據，通常也叫做數據管理，是指獲取數據並將數據轉化成信息，最終將這些信息提交到前端的查詢界面。後臺不提供查詢服務，數據倉庫方法論假設在後臺數據訪問是被嚴格禁止的，這是前臺的唯一目的。 數據倉庫的後臺部分經常被稱爲：集結區（StagingArea）。數據集結主要是指寫入磁盤，ETL的四個主要步驟都要有數據集結。下圖爲數據倉庫組件架構圖
集結區的意義
是將數據存儲在物理集結區還是在內存中直接處理？這個問題是ETL架構中最根本的選擇之一。開發的ETL處理的效率很大程度上取決於能否很好地均衡物理I/O 與內存處理。 能夠在將數據寫入集結表和保持在內存兩種方法間取得理想的均衡是個很大的挑戰，也是優化處理過程中必需考慮的問題。最終的決定取決於下面的兩個彼此矛盾的目標：
將數據以最快的速度從數據源獲取到最終目標
在處理過程發生錯誤時，能夠進行恢復而無需從頭開始
根據環境和業務需求的不同，數據集結的策略會有很大的不同。如果計劃在內存中處理所有的ETL數據處理，不要忘記任何一種數據倉庫，無論其架構和運行環境如何，都包含了一個某種形式的集結區。之所以要在加載到數據倉庫之前集結數據，主要是基於如下的考慮：
可恢復
在大多數的企業環境中，數據從源系統中抽取出來後，會進行一系列的重要的轉換，假設對於某張表，其轉換的工作量很大，那麼根據我們的最佳實踐，應該在數據一抽取完馬上就進行集結。這些集結表（在數據庫或者文件系統）可以作爲恢復點。一旦轉換過程發生錯誤，利用這些表，處理過程就無需再次訪問源系統。同樣的道理，如果加載過程失敗，也無須重新進行轉換。如果集結數據純是爲了恢復的目的，那麼數據應該存儲在文件系統中的順序文件中，而不是數據庫。以恢復爲目的的數據集結對於從業務系統中抽取數據尤其重要，因爲業務系統中的數據會被覆蓋和修改。
備份
通常，巨大的數據量使得在數據庫級別上進行可靠的數據倉庫備份變得不可行。只要加載文件已經進行了保存、壓縮和歸檔，那麼我們就可以避免數據庫故障所帶來的災難。如果集結表存儲在文件系統，那麼就可以被壓縮成非常小的文件並存儲在網絡上。當需要重新向數據倉庫中加載數據時，僅需要對加載文件解壓縮並重新加載。
審計
很多時候，源系統和目標系統之間的數據沿襲在ETL代碼中丟失，當審計ETL流程時，數據集結區的存在使得對ETL流程中的不同階段的直接比較成爲可能，因爲這時候審計人員（或者程序員）可以簡單的比較原始的輸入文件和輸出文件來檢查邏輯轉換規則。當源系統覆蓋了歷史數據時，集結數據特別有用。當一個事件發生後，你可能對於數據倉庫中幾天甚至幾周的數據信息的完整性產生了疑問，這時候對相應時段的集結區的抽取數據進行檢查將能夠幫助你恢複對數據倉庫的數據準確性的信心。
最終目標：將數據以最快的速度從數據源獲取到最終目標；在處理的過程發生錯誤的時候，能夠進行恢復而無需從頭開始。
設計集結區
集結區按照自己的方式，爲最終的數據倉庫展示區來存儲數據。有時候，保存集結區數據是爲了支持那些需要歷史數據才能完成的功能，而其它時候，集結區數據會在每個處理流程完成後就被刪除。爲維護歷史信息而使用的集結區通常稱爲持久集結區（persistent staging area）。而臨時集結區中的數據則在每次加載過程後被刪除。大多數的數據集結區都使用混合模式，即同時使用臨時和持久的集結表。
在設計集結區規模時，可以如下估算表進行估算：表名，更新策略（Truncate/insert/update），加載頻率，ETL作業(操作集結區表或者文件的作業或者程序。當多個作業操作單個的表的時候，在估算表的這個字段中列出所有的作業)，初始行數，平均行長，增長情況，每月行數，初始大小等
上述這個是假設在DBMS系統創建的集結表，實際上，集結區通常會使用DBMS和文件系統的文本文件。大多數情況下，需要使用DBMS之外的平文件來集結數據以獲得更高速的連續處理性能。這種情況下，需要使用文件系統規模估算表。通常的方式是在開發區中放置文件，然後記錄所佔用的空間，作爲正式空間分配時候的估計值。
ETL系統中的數據結構
平面文件
平面文件：如果沒用專門的ETL工具，而是在數據庫中使用SQL完成所有的etl任務，那麼就需要創建DBMS表來存儲所有的集結數據。如果是用的ETL工具，那麼可以在文件系統中使用簡單的文件來存儲集結數據。當集結數據像數據庫表那樣按照行和列存儲在文件系統中的時候，我們稱之爲平面文件或者順序文件，ETL工具或者腳本語言可以像是操作數據庫表一樣方便的操作ASCII平面文件，而且某些情況下處理速度更快。
DBMS需要很高的代價來維護要處理數據的源數據，這在一些簡單的數據集結區環境下並不真正重要，而且根據經驗，諸如排序，合併，刪除，替換以及其他的一些數據遷移功能，在DBMS之外進行操作要快的多。有很多專門的程序工具用來處理文本文件。
如果是腳本語言操作平面文件的時候 ，你有義務爲所做的轉換提供元數據追蹤表。
平面文件的劣勢：平面文件不能爲快速查找建立索引。對數據的截斷或者插入操作，關係表要比平面文件快一些，對ETL系統中的集結區表讀數據的時候，如果需要進行篩選或者需要在不同的表之間 進行連接的時候，使用數據庫存儲是更好的選擇
當基本需求是以下方面的時候，ETL過程使用平面文件更加實際：
1、出於保護和恢復的目的進行的源數據的集結。如果數據抽取出來之後，後面的ETL發生錯誤，必須能夠重新執行ETL過程而不需要再次訪問源系統，確保能夠進行恢復而不用頻繁的訪問源系統的最好方法就是把抽取出來的數據在平面文件內部保存
2、數據排序。文件系統中的排序比order by效率更高。
3、過濾。grep比建立索引之後where語句效率高
4、替換/部分替換文本串，操作系統級別比數據庫高效的多
5、聚合。在將數據加載到數據庫之前的ETL數據流中；或者，如果聚合數據只用通過數據庫篩選來獲得，就在數據庫中完成。如果在數據庫外完成聚合，往往需要專門的排序軟件包。如果是在數據庫中完成，將會大量地使用數據庫的排序功能，雖然偶爾也會將大量的數據導出，使用排序軟件包
6、源數據的引用。在規範化的事務處理系統中，通常會有一個唯一的參照表來支持其他的表。例如，一個通用狀態表可以支持訂單的狀態、發貨狀態和付款狀態。除了在源數據中反覆地查詢同一張參照表之外，更爲
高效的一種方法是一次性地將參照表抽取到數據集結區。ETL 工具將從集結區中查找所參照的數據。大多數的ETL工具可以將參照表加載到內存中，並使其在ETL整個處理過程中有效。從內存中訪問參照錶速度極快。另外，使用集結區中的參照表可以使源系統中的很多表聯接可以被省略，這樣對源系統的查詢將更加的簡單和高效。
XML數據集
XML數據集在ETL系統中通常不用於永久存儲集結區數據，他們更適合作爲ETL系統的輸入和輸出的標準格式。
XML和HTML區別：XML利用普通文本文檔的形式來存儲數據以及元數據，但是不包含格式信息。HTML中包含了數據和格式化的信息，但是不包含元數據。
如果不考慮XML層系統結構的複雜性，XML是目前在不兼容系統中轉移數據的最有效的中間層，因爲XML提供了足夠多的信息，可以爲關係型數據庫生成完全的CREATE TABLE語句，並按照正確的列類型提供數據。XML定義了數據共享的通用語言，這是他的優勢。對大數據量的傳輸而言，XML的劣勢在於XML文檔結構的冗餘。 使用XML需要雙方通過交換特定的類型定義文檔（DTD）來識別可能的標籤。DTD爲雙方交換XML建立了元數據理解的基礎。
關係表
集結區數據可以存儲在關係型DBMS中。尤其是沒有使用專門的ETL工具時，使用數據庫表就最合適。使用數據庫存儲集結區表有下列的優點：
直觀的元數據。使用平文件的主要缺陷是缺乏直觀的元數據。使用關係表存儲數據，DBMS自動的維護技術元數據，業務元數據可以很容易的附加在數據庫表上。列名稱、數據類型和長度以及基數的信息可以從數據庫系統繼承。表和列的業務描述通常作爲元素加在DBMS數據目錄中。
關係能力。實體之間的強制的數據完整性或參照完整性可以在關係數據庫環境中很容易的維護。如果接收來自非關係型系統中的數據，在轉換爲維度模型之前，將數據集結在一個規範模型中就很有必要。
開放的資料庫。一旦數據進入DBMS，那麼數據可以很容易的通過任何支持SQL的工具來訪問（如果賦予了相應的權限）。進行質量保證測試和審計時，確保對數據的訪問至關重要。
DBA支持。在很多企業環境中，DBA小組僅對DBMS中的數據負責。數據庫外的數據，如文件系統通常不由DBA維護。如果集結區數據不在DBMS中，那麼ETL小組必須承擔空間分配、備份和恢復、歸檔以及安全等任務。
SQL接口。很多的時候我們需要寫SQL來操作數據，按照正確的格式獲得數據。大家都知道SQL是標準語言，易於書寫且功能強大。在IT 領域，恐怕SQL是被最廣泛掌握的程序語言了。大多數的數據庫系統都提供了強大的SQL 函數，幫助用戶節省手工編程的時間。除了強制參照完整性檢查，能夠使用自帶的SQL是在數據庫環境中存儲集結區數據的主要原因。
獨立的DBMS工作表
事務處理數據庫爲數據進入進行設計，維度模型爲數據輸出進行設計，而集結區設計則同時包含兩者。採用獨立表的原因是：簡單的就是最好的。之所以被稱爲“獨立表”，是因爲這些表與數據庫中的其他表沒有任何依賴性。在事務處理環境，這些表被稱作孤表，因爲它和模型中的其他表沒有任何關係。因爲獨立集結表沒有任何關聯關係，因此獨立表是在關係型數據庫外建立存儲的主要候選方式。
大多數時候，創建集結表目的是爲了存儲數據以便於能夠使用SQL或腳本語言再次操作數據。很多情況下，尤其是小型數據倉庫項目，獨立表可以滿足全部的數據集結區要求。由於獨立表不需要規範化，因此不能視作轉儲文件。轉儲文件通常任意的創建，無須考慮磁盤空間或者查詢效率。獨立文件或獨立表的每個字段必須有主題和邏輯定義。多餘的列會在任何獨立表的設計中被忽略。
對於數據庫表，需要在所有的獨立表上建立並實現一個合理的索引規劃。由於訪問獨立表的進程只有大多數時候，ETL過程，這裏沒有必要建立在展示區中纔用到的位圖索引，位圖索引是爲最終
用戶工具和即席查詢所用的。在ETL系統中，會更多地在單列或複合列使用B樹
索引。
三範式實體/關係模型
事實上，我們很少將數據集結區建成第三範式模型。在很多案例中，一個層系中的數據元素來自多個不同的數據源，具有不同的粒度，還包括很多來自非關係型數據源的外部數據。這種情況下，通常是在加載到維度數據模型之前，消除數據冗餘和強制完整性。理想的處理方式是集中處理獨立的“問題維表”，對它進行徹底檢查以確保原先的髒數據已經被正確地清洗。記住規範化的主要結果是強制明確的多對一關係，除非需要人工檢查模型的圖形描述，否則，實體關係圖的註釋既不強求也無須解釋。建模的時候應該具體情況具體考慮，只有在必要的時候才進行實體規範化。
一般情況下不要假定數據集結區必須作規範化。設計ETL處理應依據兩個基本目標：快速和可恢復。如果ETL過程中所作的集結既沒有物理的數據操作，也不能加快速度或支持恢復，那麼它就應該被移除。
非關係數據源
通常建立集結區環境的一個重要的原因是爲了集成非關係型數據。集成非關係數據通常需要作一些完整性檢查，數據完整性的保證不是沒有代價的，通常需要在數據集結區中的實際的存儲，並且需要對ETL過程進行客戶化以保證業務規則的正確，而這些業務規則在源系統的關係型數據庫中是自動維護的。這意味着表之間有聯繫，通常爲父子關係。孤兒記錄的出現是參照完整性被破壞的標誌。例如，如果一個訂單表中有一個狀態列，具體的值如果在一個獨立的狀態參照表中不存在就不能夠錄入。在這個場景中，狀態表是訂單表中對應列的父。狀態表中的父不能隨便地刪除，除非所有的子已被刪除，否則它的子就變成了孤兒記錄。孤兒記錄指的是任何沒有父的子記錄。同樣，如果狀態表中有外鍵引用到訂單，那麼任何的訂單的主鍵也不能刪除。孤兒記錄的出現是參照完整性被破壞的標誌。
非關係數據源不能保證參照完整性，非關係系統本質上是無關的表的集合。在很多遺留的事務系統中，父子關係只能通過前置應用來保證。不幸的是，經過多年運行，由於不可避免的腳本操作或者應用之外的數據操作，導致數據庫系統中的任何數據完整性都已不能保證。可以肯定非關係數據源中多多少少都會有數據質量問題。
與事務系統不同，設計數據集結區的最佳實踐是在ETL過程而不是在數據庫中進行完整性檢查。其中的區別在於，事務系統期望數據輸入是正確的，並且人爲的輸入錯誤將導致錯誤拋出，提示重新輸入正確的值。與此相反，ETL過程則必須知道如何自動地處理數據異常。ETL過程不能簡單地拒絕所有的數據完整性錯誤，因爲現在沒有人會及時地重新輸入正確的數據。我們需要爲不同的數據質量錯誤場景定義不同的業務規則，並在ETL過程中實現這些規則。當錯誤的數據通過ETL流程時，有時你希望直接轉換；有時不作修改直接加載；有時需要追加相關的代碼或者追加一些對於影響及環境的描述，然後進行加載；或者如果數據不可接受，那就完全拒絕數據，並將其寫入拒絕文件供進一步的調查。記住不要過度使用拒絕文件！拒絕文件用於那些我們需要後續專門處理的轉儲數據。當記錄進入拒絕文件後，除非在下一個主要加載步驟開始運行前完成對其處理，否則數據倉庫和生產系統之間的同步就被破壞了。
基本的數據庫參照完整性並不能完全處理上述的每一種情景。ETL 過程通常都需要手工編碼邏輯，來保證成功集成非關係數據源。
代理鍵映射表
代理鍵映射表示用來建立各個源系統的自然鍵到主數據倉庫代理鍵之間的映射，映射表是維護數據倉庫代理鍵的一種非常有效的方法。這些表結構緊湊，專門用於爲高速處理。映射表中僅僅包含那些最近期要訪問的代理鍵值及其對應的源系統中的自然鍵值。由於同一個維度可以有不同的源，因此映射表中要爲每個源的自然鍵創建單獨的列。
映射表無論是存儲在數據庫還是文件系統中都可以有同樣的高效率。如果使用數據庫，可以利用數據庫順序號生成器來創建代理鍵，如果索引使用恰當，鍵值的查找會非常得高效。
由於鍵映射表並沒有分析價值，因此，不能將其建在數據倉庫的展示層，也不能暴露給最終用戶。
影響分析
影響分析的作用在於檢查與對象（這裏指的是表或者列）關聯的元數據，並判斷對象的變化對其內容和結構有何影響。對數據集結區對象的更改可能會破壞數據倉庫的加載流程。允許任意修改數據集結區對象會對項目的成功造成危害。 一旦在數據集結區中創建了表，在做任何修改之前，都必須進行影響分析。
元數據捕獲
設計集結區數據庫的時候使用的數據建模工具可以可視化的展示元數據，數據建模工具在他的字跡的資料庫中存儲這些可用的元數據。另外使用ETL工具會生成關於過程的元數據，並能夠對其中的所有的轉換過程進行展示。從集結區衍生出來的元數據類型包括：
數據譜系：所有數據倉庫元數據庫中最有趣的元數據可能就是數據譜系，或者稱爲邏輯數據映射，闡述了數據元素從原始數據源到最終數據倉庫目標之間是如何轉換的。
業務定義：數據集結區中創建的所有表都是從業務定義中衍生出來的。業務定義可以從很多地方獲得，包括數據建模工具、ETL 工具、數據庫自身或者電子表格和Word文檔。無論如何，需要使用在數據倉庫展示層上獲取業務定義來維持其一致性。
技術定義：尤其對於數據集結區，技術定義要比業務定義更加的普遍。要記住，如果沒有文檔記錄，那麼就意味着技術定義不存在！如果數據集結區中表的技術定義沒有詳細的文檔，那麼這張表將可能被一次次的
重建，會在數據集結區中產生大量的數據重複，導致數據爆炸。技術定義應該描述數據元素的所有物理屬性，包括結構、格式和位置。對集結區中所有表進行技術元數據文檔化記錄可以將不確定性降至最低，並提
高重用性。
過程元數據：數據集結區表的加載過程的統計必須和數據倉庫表加載的統計一起記錄。儘管數據集結區加載過程的信息不需要展示給最終用戶，但是ETL小組需要知道每個表中加載了多少記錄，每個過程成功或失敗
的統計結果。而數據刷新頻度方面的信息對ETL管理員和最終用戶都是有用的。