SAP中的增量機制，可以有助系統提高數據抽取效率，在初始化執行后，每天只更新新增和修改了的記錄。在我們正常的使用或開發中，這些東西并不需要知道，只要數據正常上載，就好了，此處所介紹的內容之為大家參考用。在介紹DELTA機制之前，先介紹下DSO和CUBE：DSO：一般DSO用來存儲明細數據，其結構比較簡單。對于值的轉換（決定了可用的DELTA類型），既可以使用合計，也可以使用覆蓋的方式。激活DSO后，其在后臺對應3個數據表：,A表，存放了最后激活的數據。即存放了匯總后的數據。
LOG表：存儲了數據變化的數據記錄N表，NEW表，臨時存放更新的數據，待激活后，將數據轉入A表和LOG表以上數據表，可以通過在SE11中，描述中搜索DSO技術名稱找到

CUBE：典型的星型架構。CUBE只支持數據值的合計上載。
建立了CUBE之后，可以到SE11中，通過在表名中搜索CUBE的名稱，找到對應的維表和事實表

同樣都是數據模型，而DSO更多用于存儲明細數據，星型架構的CUBE更適合作為分析數據源。關于具體的DSO和CUBE，我們以后再介紹

下面給大家介紹兩個表，是定義DELTA類型的基本表，如下：
ROOSOURCE：定義了每個數據源的屬性

RODELTAM：定義了每種增量提取方式的方法，即：DP的屬性

DP：增量處理名稱
T： 標識是否為 僅全量更NIM：標識是否為傳輸 新鏡像（即：新數據的狀態）
BIM：標識是否為傳輸 前鏡像（即：更新前的狀態）
AIM：標識是否為傳輸 后鏡像（即：更新后的狀態）
ADD：標識是否為傳輸 差額鏡像（即：更改的差額狀態）
DID：標識是否為傳輸 刪除鏡像（即：刪除狀態）
RIM：標識是否為傳輸 反轉鏡像（即：沖銷的狀態）
SER：標識為 哪種序列化方式，即：數據的排序r
1. 無所需序列化.
2. 所需的請求序列化
3. 所需的數據包序列化-
類型：DELTA處理的類型。標識何種數據抽取方式。
BW中的增量機制就是圍繞RODELTAM表設置來進行的，首先介紹增量類型的定義，我們假設有一筆業務創建100，而后更改為80，然后刪除，對于以上設置，會產生什么樣的影響：!
ORDER NO STATUS QTY RECODE TYPE
創建訂單
100000000 CREATED 100 N 將帶有記錄類型為‘’的新建記錄上載到BW，BW以N載入DSO"
更改 100->80
100000000 CHANGED -100 X 前鏡像生成
100000000 CHANGED 80 “” 后鏡像生成
100000000 CHANGED -20 A 差額鏡像生成

標志刪除-
100000000 DELETED 0 R 反轉鏡像生成
100000000 D 刪除鏡像生成

創建100的業務：此為創建操作，傳輸新鏡像，在R3端，以‘’表示新鏡像
更改100->80：
如果前鏡像設置：以X表示前鏡像傳輸。
如果后鏡像設置：以‘’表示后鏡像傳輸
如果差額鏡像設置：以A表示差額鏡像傳輸
我們下面用兩種類型來說明DELTA在R3和BW端的處理步驟：
ABR：MM中采購用到這種類型，我們可以看出ABR存在新鏡像、前鏡像、后鏡像和反轉鏡像，我們創建一采購訂單，并查看，R3數據源給BW提供的數據。


根據ABR的定義，對于采購訂單操作，應按以下順序傳輸數據：
ORDER NO STATUS QTY RECODE TYPE
創建訂單
100000000 CREATED 100 “” 將帶有記錄類型為‘’的新建記錄上載到BW，BW以N載入DSO
更改 100->80
100000000 CHANGED -100 X 前鏡像生成
100000000 CHANGED 80 “” 后鏡像生成
標志刪除
100000000 DELETED 0 R 反轉鏡像生成
通過RSA7查看統計的待傳輸數據：
首先創建采購訂單：訂單號為4510000010:
查看RSA7的統計數據：


將100改為80：
將10項目標志位刪除：

關于在BW中的數據上載步驟：
對于存在多種鏡像屬性的數據源，系統會自動為其增加ROCANCEL字段，作為傳輸鏡像屬性值用。我們這里的采購訂單數據源，就是這樣的類型。
我們知道，CUBE只能合計數據，DSO既可以做合計，也可以做覆蓋的匯總，所以，ABR的DELTA類型是既適合CUBE又適合DSO直接更新的。用上面的數據說明，訂單傳輸到合計的更新模式（CUBE或DSO），因為連帶著前鏡像一起傳輸，所以，匯總后的結果就是最后的結果0。如果為覆蓋的話（DSO），那么序列化后的最后狀態為“R”的記錄，這樣也實現數據的成功上載。這種方式需要數據源的序列化，對于ABR設置為2。
因此，這種方式既可以直接上載到DSO也可以直接上載到CUBE。但我們一般都會經過DSO，保證數據模型中，存儲了所有的明細數據。

接下來，我們再對FI的數據源和自定義的數據源做一下分析：
首先說明一下，自定義的數據源默認都是AIE的增量處理方式，即：只提供后鏡像的數據源，而且沒有提供更改增量處理的方法。與FI的數據源相似。這樣就說明，這些數據源只能首先上載到DSO，然后在進行分析。
以我們前面做的自定義的數據源為例：
AIE只支持后鏡像，即：所有的新建或修改后，都只將最后的狀態傳輸到BW，并且只支持一種傳輸方式的數據源不建立ROCANCEL字段，默認為空。
執行初始化，并將數據上載到DSO，不激活DSO數據，我們在后臺數據表中，查看DSO的數據變化：
我們通過在SE11中查詢ZRSO01的描述，找到了其3個表：
A表：/BIC/AZDSO0100
LOG表：/BIC/B0010239000
N表：/BIC/AZDSO0140
并且，可以看到每個表中，都存在RECORDMODE的字段，有系統自動生成，用來記錄RECORD TYPE。
執行到這里，只有N表內存在數據：

激活數據： H
A表：
保存了最后匯總的數據,

LOG表：
數據轉移到LOG表中，對于以前不存在的記錄，自動將RECORD TYPE置為’N’。 h

同時，N表被置為空

下面，我們將1234567890的記錄，修改為800，再次執行DELTA更新，并上載到DSO，查看在未激活之前的狀態：
這里說明一下，手工修改記錄的時間戳，需參考RSA7中的統計時間：

我們將數據修改為：

以下是未激活DSO前的狀態：
A表：

激活后：
A表：
LOG表：

從中可以看出，雖然我們只是將后鏡像數據上載，系統自動為我們建立了前鏡像，保證了DSO保存明細數據的要求。
關于更多的DELTA處理的問題，大家可以通過以上的方式跟蹤數據在系統間的傳輸來了解。$
最后還要說明一下，FI與其他模塊的數據抽取方式不太一樣。
FI是通過BW的請求，到R3中執行對應的FM，然后獲得數據，寫入DELTA隊列，這種方式叫做”PULL”。自定義數據源也是這樣的方式。
對于其他模塊，如MM，是通過將數據寫入DELTA隊列，BW請求后，并不直接讀取真實的數據源，而是讀取DETLA隊列。
FI和自定義數據源，這里就不說了，大家可以參考自定義數據源的文章來了解。
對MM，激活信息結構的時候，會讓我們選擇，更新類型：

同步更新（V1）：DELTA隊列與憑證同步更新，如果DELTA隊列寫入出現錯誤，那么憑證也被取消

異步修改（V2）：與V1相比，寫入DELTA若出現錯誤，不對憑證的保存產生影響.

異步收集更新（V3）：與做憑證沒有關系。在后臺定義一程序，定時運行，收集產生變化的數據到DELTA隊列。! 與FI的抽取方式差別太大，而且需要我們在源系統進行必要的操作。感覺好像不是一批人開發的，實現DELTA的邏輯從本質上不同，SAP的解釋是說，對于不能直接實現DELTA抽取的數據源，可以采用這種方式

轉載于:https://www.cnblogs.com/clsoho/archive/2012/10/23/2735148.html

總結

以上是生活随笔為你收集整理的BW之数据源 增量管理DELTA的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。