ITPub博客

首页 > Linux操作系统 > Linux操作系统 > BW之数据源 增量管理DELTA

BW之数据源 增量管理DELTA

原创 Linux操作系统 作者:KarenChiang 时间:2011-04-25 15:59:57 0 删除 编辑
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查看统计的待传输数据:
首先创建采购订单:订单号为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表内存在数据:

激活数据:
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”。自定义数据源也是这样的方式。
对于其他模块,如MM,是通过将数据写入DELTA队列,BW请求后,并不直接读取真实的数据源,而是读取DETLA队列。
FI和自定义数据源,这里就不说了,大家可以参考自定义数据源的文章来了解。
对MM,激活信息结构的时候,会让我们选择,更新类型:

同步更新(V1):DELTA队列与凭证同步更新,如果DELTA队列写入出现错误,那么凭证也被取消
异步修改(V2):与V1相比,写入DELTA若出现错误,不对凭证的保存产生影响
异步收集更新(V3):与做凭证没有关系。在后台定义一程序,定时运行,收集产生变化的数据到DELTA队列。
与FI的抽取方式差别太大,而且需要我们在源系统进行必要的操作。感觉好像不是一批人开发的,实现DELTA的逻辑从本质上不同,SAP的解释是说,对于不能直接实现DELTA抽取的数据源,可以采用这种方式。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/25433510/viewspace-693676/,如需转载,请注明出处,否则将追究法律责任。

上一篇: BW DSO基本概念
请登录后发表评论 登录
全部评论

注册时间:2011-03-17

  • 博文量
    57
  • 访问量
    79858