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：定义了每个数据源的属性，大部分属性我们在创建自定义数据源时已介绍，请参考http://community.kingdee.com/pages/chunguangz/blog/archive/2010/03/18/401671.aspx，其中，DP列定义了增量类型。
RODELTAM：定义了每种增量提取方式的方法，即：DP的属性
DP：增量处理名称
T： 标识是否为 仅全量更新
NIM：标识是否为传输 新镜像（即：新数据的状态）
BIM：标识是否为传输 前镜像（即：更新前的状态）
AIM：标识是否为传输 后镜像（即：更新后的状态）
ADD：标识是否为传输 差额镜像（即：更改的差额状态）
DID：标识是否为传输 删除镜像（即：删除状态）
RIM：标识是否为传输 反转镜像（即：冲销的状态）
SER：标识为 哪种序列化方式，即：数据的排序
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查看统计的待传输数据：
首先创建采购订单：订单号为4510000008
查看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表内存在数据：
激活数据：
A表：
保存了最后汇总的数据
LOG表：
数据转移到LOG表中，对于以前不存在的记录，自动将RECORD TYPE置为’N’。
同时，N表被置为空
下面，我们将1234567890的记录，修改为800，再次执行DELTA更新，并上载到DSO，查看在未激活之前的状态：
这里说明一下，手工修改记录的时间戳，需参考RSA7中的统计时间：
我们将数据修改为：
以下是未激活DSO前的状态：
A表：
激活后：
A表：
LOG表：
从中可以看出，虽然我们只是将后镜像数据上载，系统自动为我们建立了前镜像，保证了DSO保存明细数据的要求。
关于更多的DELTA处理的问题，大家可以通过以上的方式跟踪数据在系统间的传输来了解。
最后还要说明一下，FI与其他模块的数据抽取方式不太一样。
FI是通过BW的请求，到R3中执行对应的FM，然后获得数据，写入DELTA队列，这种方式叫做”PULL”。自定义数据源也是这样的方式。
在介绍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：定义了每个数据源的属性，大部分属性我们在创建自定义数据源时已介绍，请参考http://community.kingdee.com/pages/chunguangz/blog/archive/2010/03/18/401671.aspx，其中，DP列定义了增量类型。
RODELTAM：定义了每种增量提取方式的方法，即：DP的属性
DP：增量处理名称
T： 标识是否为 仅全量更新
NIM：标识是否为传输 新镜像（即：新数据的状态）
BIM：标识是否为传输 前镜像（即：更新前的状态）
AIM：标识是否为传输 后镜像（即：更新后的状态）
ADD：标识是否为传输 差额镜像（即：更改的差额状态）
DID：标识是否为传输 删除镜像（即：删除状态）
RIM：标识是否为传输 反转镜像（即：冲销的状态）
SER：标识为 哪种序列化方式，即：数据的排序
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查看统计的待传输数据：
首先创建采购订单：订单号为4510000008
查看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表内存在数据：
激活数据：
A表：
保存了最后汇总的数据
LOG表：
数据转移到LOG表中，对于以前不存在的记录，自动将RECORD TYPE置为’N’。
同时，N表被置为空
下面，我们将1234567890的记录，修改为800，再次执行DELTA更新，并上载到DSO，查看在未激活之前的状态：
这里说明一下，手工修改记录的时间戳，需参考RSA7中的统计时间：
我们将数据修改为：
以下是未激活DSO前的状态：
A表：
激活后：
A表：
LOG表：
从中可以看出，虽然我们只是将后镜像数据上载，系统自动为我们建立了前镜像，保证了DSO保存明细数据的要求。
关于更多的DELTA处理的问题，大家可以通过以上的方式跟踪数据在系统间的传输来了解。
最后还要说明一下，FI与其他模块的数据抽取方式不太一样。
FI是通过BW的请求，到R3中执行对应的FM，然后获得数据，写入DELTA队列，这种方式叫做”PULL”。自定义数据源也是这样的方式。
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
