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抽取的数据源，可以采用这种方式
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抽取的数据源，可以采用这种方式
