SAP-BW数据仓库增量更新(转载)

nidr

　　1    说说假增量
　　
　　
　　我 们都知道，对于BW来说，很多ECC的标准数据源自带了增量更新功能，每天各种凭证产生的增量数据会自动堆积到增量队列里，然后BW端做一个增量信息包按 天把这些增量抽取到数据仓库里，非常轻松自然，对于客户和顾问，都是透明的自动的容易实施的，这也是上过ECC的企业数据仓库采用SAP BW的一个优势所在。
　　
　　但 是对于非ECC的一般数据库或者ECC的自定义数据源，做增量更新就苦了。对于ECC的自定义数据源，SAP给了一种标准方案，我们看看这种方法：用一个 时间字段或数字字段标记增量，当这个字段在表里的数值变化时，就认为是增量，把这条记录作为增量记录，增量信息包会挑出这些记录传送上去。这种方法的问题 是显而易见的，不管是时间还是数字字段，我们都需要ABAP工作者额外编程去控制这个字段的变化，这样才能正确让系统选择出增量（用表中的凭证创建日期等 字段作为时间字段去控制是不可行的，因为你不能保证今天不会修改昨天的数。）对于非ECC的一般数据库连接，SAP很干脆的说，不支持增量（06年是这么 讲的，以后支不支持不晓得）
　　
　　总结一下，在不同的数据源下，对增量的支持是这样的 ：
　　
　　一般来说，数据源都是先把数传递到DSO再到CUBE，每次删除重复请求感觉上也不是很安全，所以上述方法使用的不多。
　　先 到DSO再到CUBE，每一次用程序抽取最近N个月数据的这种假增量方法看似比较完美，其实背后隐藏了一个极大的问题，即用户在源系统物理删除的那部分记 录如何在BW也每天自动删除掉。原系统物理删除掉的记录，BW在抽取过程中是无法自动识别的，在DSO的更改日志里当然也体现不出来，CUBE端肯定也不 会自动删除掉，这个如何处理？放任不管是肯定不行的，在这次首钢项目的开始，项目组就提出了这个问题，要求给出合适的解决方案。
　　
　　1    让客户最偷懒的，解决物理删除问题的假增量方案
　　
　　解 决方案经过研究，可以有以下两种主要思路。第一种，由开发源系统的客户方维护人员，在视图里增加一个删除标记，每一次数据删除了，都打上这个标记，BW抽 取上来后，在报表里设置条件，凡是有这个标记的数据，就不显示出来。这种方案的问题在于客户必须要修改它那边源系统的代码，很多时候，客户想偷个懒，不太 愿意改，这种方案需要客户配合，也不是标准的解决方案。第二种方法，在BW这边识别，并在抽取时自动进行处理，这样客户什么也不需要做，相当舒服，但是 BW这边如何能尽量方便的处理，就得综合考虑一些问题了。
　　问题一：BW如何找出被物理删除的记录？
　　可以在开始例程里统一判断，即把开始例程的SOURCE_PACKAGE和DSO中相关记录进行比对，DSO中有，而SOURCE_PACKAGE找不到的记录，即可认为是删除，例程如下：
　　SELECT * FROM /bic/az3pp_o0900 INTO TABLE it_dso.
　　LOOP AT it_dso INTO st_dso.
　　READ TABLE SOURCE_PACKAGE INTO st_source WITH KEY STAT_DATE =
　　st_dso-calday.
　　IF sy-subrc <> 0.
　　“ 确认删除，此处开始处理问题二
　　ENDIF.
　　ENDLOOP.
　　
　　问题二： 找到被删除记录后，怎么能让DSO的更改日志知道这条记录被删除了？
　　我 们知道，DSO的更改日志会自动把这一次的数据和上一次的数据进行比对，把差异记录在日志表里，再传递到CUBE中，因此，我们可以考虑，手工把被删除数 据的关键值统一设置为0，这样，假设原来关键值是15的话，DSO会被覆盖成0，DSO的更改日志表会变成-15，再传到CUBE中就是15 +（-15）= 0了。这样等于针对删除记录自动产生了反冲记录，可以同时保证DSO和CUBE数据的准确性了（DSO和CUBE该记录都为0了），例程如下：
　　LOOP AT it_dso INTO st_dso.
　　READ TABLE SOURCE_PACKAGE INTO st_source WITH KEY STAT_DATE =
　　st_dso-calday.
　　IF sy-subrc <> 0.
　　st_source-STAT_DATE = st_dso-calday.
　　st_source-L4_FACILITY_ID = st_dso-plant.
　　st_source-L4_WORKCENTER_ID = st_dso-workcenter.
　　
　　st_source-EQPT_OUT =0.
　　st_source-EQPT_SCRAP =0.
　　st_source-SACRPT_HRM_INPUT =0.
　　st_source-SALE_OUT =0.
　　st_source-SALEMAT_HRM_INPU =0.
　　st_source-record = tmp_record.
　　APPEND st_source TO SOURCE_PACKAGE.
　　ENDIF.
　　ENDLOOP.
　　注意，上述例程中非关键值要设置成和原先一样，关键值都要设置成0.
　　
　　完整例程如下：
　　DATA it_dso TYPE TABLE OF /bic/az3pp_o0900.
　　DATA st_dso TYPE /bic/az3pp_o0900.
　　DATA st_source TYPE _ty_s_sc_1.
　　DATA tmp_record TYPE rsarecord.
　　
　　SELECT * FROM /bic/az3pp_o0900 INTO TABLE it_dso.
　　READ TABLE SOURCE_PACKAGE INTO st_source INDEX 1.
　　tmp_record = st_source-record.
　　CLEAR st_source.
　　
　　LOOP AT it_dso INTO st_dso.
　　READ TABLE SOURCE_PACKAGE INTO st_source WITH KEY STAT_DATE =
　　st_dso-calday.
　　IF sy-subrc <> 0.
　　st_source-STAT_DATE = st_dso-calday.
　　st_source-L4_FACILITY_ID = st_dso-plant.
　　st_source-L4_WORKCENTER_ID = st_dso-workcenter.
　　
　　st_source-EQPT_OUT = 0.
　　st_source-EQPT_SCRAP = 0.
　　st_source-SACRPT_HRM_INPUT = 0.
　　st_source-SALE_OUT = 0.
　　st_source-SALEMAT_HRM_INPU = 0.
　　st_source-record = tmp_record.
　　APPEND st_source TO SOURCE_PACKAGE.
　　ENDIF.
　　ENDLOOP.
　　
　　这样的方案，我们每一次都只需把数据源到DSO的转换增加一个类似的开始例程，所有物理删除的问题就可以得到统一的解决了。以后有少数字段调整，修改起来也比较方便。对源系统那端的开发人员，工作量=0，对BW顾问，工作量也很小：）
　　写了这么多，总结一下，用户物理删除（无删除标记的）的假增量方案，也就是如下两步而已：
　　1） 每次抽取最近几个月的数据到标准DSO再到CUBE，
　　
　　
　　2） 从数据源到DSO的转换增加一个开始例程，把每次传输源系统删除的数据找出来，以关键值为0的形式更新到后续的数据目标中。
　　这样最近两个月的数据每天抽取，每天覆盖，再利用DSO的更改日志表，就实现了“假增量”。
　　如果数据源对应的不是DSO，是CUBE，那么就无法使用更改日志表，BW也给我们一种实现假增量的方式，见下图：
　　因 此，对于不支持或不好实现增量的情况，我们比较推荐的方法是，使用带选择条件的完全抽取信息包，每一次定期抽取之前N个月的数据（前提是客户保证，不修改 N之前月的数据），然后上传到DSO中，如果这N个月的数据没有变化，则会被覆盖掉，系统当什么事都没发生；如果有变化，则会把变化部分覆盖DSO相同主 键的数据，然后记录到DSO的更改日志表，再往CUBE中传变化部分（当然：DSO到CUBE的DTP要设置成增量DTP），这样，就以比较小的抽取时间 的代价（每天只要抽最近N个月，N尽量小的数据），换来了增量抽取的几乎全部优点（每次抽取时间比较短，数据量小，传到CUBE也同样只传增量部分）。这 种做法，SAP官方教材极力推荐，见下图（取自教材350增量更新一章最后一节），BW江湖人送外号假增量即是此种方法。
　　
　　转自 http://blog.163.com/jokey_xb/blog/static/57943665201122534235542/