設查詢信息源并包裝所有數(shù)據(jù)成公共類型數(shù)據(jù)塊的時間代價為Cost(Q)，傳輸放入文件中的所有數(shù)據(jù)塊到集成端的時間為Cost(T)，集成端將傳輸過來的數(shù)據(jù)解析并初始化到數(shù)據(jù)倉庫的時間為Cost(P)，則基于同步方法的時間代價為：Cost(Q)+Cost(T)+Cost(P)。

設查詢信息源并包裝查詢的數(shù)據(jù)成公共類型數(shù)據(jù)塊為一塊的時間代價為：Cost(Q1)，傳輸其中一塊數(shù)據(jù)塊到集成端的時間為Cost(T1)，集成端將傳輸過來的一塊數(shù)據(jù)塊解析并初始化到數(shù)據(jù)倉庫的時間為Cost(P1)，因為這里數(shù)據(jù)塊是個固定的常數(shù)，則基于本文的算法的時間代價為：Cost(Q1)+Cost(T1)+Cost(P1)+max(Cost(Q)-Cost(Q1)，Cost(T)-Cost(T1)，Cost(P)-Cost(P1))，其中max為各處理邏輯減去初始處理的最大時間。

從上面理論上可以分析得出，基于內(nèi)存控制的流水線處理技術較同步技術可以更好地提高效率。同時還存在幾個問題：

(1)當集成端需要OLAP查詢或?qū)嵒晥D初始化比較多時，仍然會出現(xiàn)內(nèi)存溢出的問題，這時可以應用線程池技術[4]，有效控制這類線程運行的數(shù)量，同樣，監(jiān)視器端也使用這種方案。

(2)當集成端與監(jiān)視器端進行流水線處理時，如果監(jiān)視器端與集成端出現(xiàn)網(wǎng)絡中斷，或者其中一個出現(xiàn)突發(fā)事件（如斷電）時，之前的一些過程就需要重做，并回滾。特別是針對網(wǎng)絡中斷的情況，容易造成監(jiān)視器端查詢線程的線程泄漏，即集成端認為之前的操作沒成功，然后重新進行操作，然而監(jiān)視器端的處理線程卻還沒完。避免這些情況出現(xiàn)的解決方案為：設置一個超時，當達到設定時間而這一流水處理過程未進行時，自動中斷這些處理流程，或者可以在監(jiān)視器端對查詢組裝后數(shù)據(jù)塊分塊存儲在硬盤上，然后進行文件數(shù)據(jù)塊的發(fā)送，這樣減少了塊之間的命令的交互邏輯，而且有效地控制了線程泄漏，但是也增加了文件的讀寫與控制，增加了I/O開銷。

數(shù)據(jù)集成仍然是一個比較熱門的研究點，在基于數(shù)據(jù)倉庫方法的數(shù)據(jù)集成中，分析了實化視圖初始化以及OLAP查詢中面對大數(shù)據(jù)量處理的問題，應用了基于內(nèi)存控制的流水線處理方法，充分利用了Java的多線程處理技術，并從實驗和理論上分析了該方法較同步方法的優(yōu)點。