refer to http://blog.vsharing.com/WKingChen/A1157147.html
DataSource是BW中非常重要的部分，一个合格的BW顾问应该对BW DataSource有深入的理解，网上这方面的文章也非常多。我大概总结一下，如有错误，欢迎指正。
标准数据源的Delta机制概述
1. 所有的Delta数据，在传输到BW之前，都会先到Delta Q， 再到BW。Delta Q可以通过RSA7进行管理和观察。Delta Q的一个重要作用是保证记录的顺序。
2. Delta数据从原始表到Delta Q，有两种情况：对于LO的数据源，是系统将Delta数据push到Delta Q的，然后在InfoPackage执行的时候，再把数据从Delta Q搬到BW。 对于非LO的数据源，大部分采用time stamp的方式，在InfoPackage执行的时候，系统根据time stamp去源数据表获得delta数据，这些数据被送往Delta Q之后，紧接着就被搬到BW了。所以，对于非LO的数据源，你很难在Delta Q里看到他们的Delta 数据。
3. 对于time stamp的delta 方式，大部分数据源（全部？）的time stamp 记录在表BWOM2_TIMEST中。
4. 对于LO数据源，其Delta数据流根据选择的_updatemode不同会有所区别，后面详述。
5. 系统如何获取Delta 数据，跟数据源的delta process 有关，后面详述。
关于Delta Process
每一个数据源，都有一个很重要的属性：Delta Process . 在RSA2中可以看到：
此外，你也可以在表ROOSOURCE中找到该信息。
Delta Process 告诉我们系统是如何捕获delta 数据的。一般来说，delta数据有新增，修改和删除几种情况。新增就是直接把这条数据作为delta数据，删除一般是生成一条方向数据(Reserve Image)。修改，就有点复杂了，大概有几种不同的处理方式：
After image 即只捕获修改后的数据作为delta数据。
Add Image 则是捕获修改之后的数据与源数据之间的差。
Before image则生成一条原来的数据的反向数据，用来冲销原先的数据。
BW数据源，大概有有以下的Delta Process:
这 些delta process都是如何捕获delta数据的呢？表RODELTAM可以告诉我们其中的奥秘。这张表记录了每个delta process 是采用何种镜像去捕获delta数据的，是否对保持记录的顺序有要求。不同的镜像方式，对BW的建模和数据流是有很大影响的：
若 采用before image, after image, reserve image的方式，例如：ABR（DSO的change log也是这种方式），则数据既能覆盖（覆盖的时候after image覆盖掉了之前的before image），又能累加（累加的时候，before image冲销原来的记录，after image则是修改后记录），可以增量更新到DSO和InfoCube。
若只支持after image, 则数据只能覆盖，不能累加，例如：AIE，则只能先增量更新到DSO，再更新到InfoCube。这种情况，一定要在DataSource 和 Cube之间有一层DSO.
若只支持add image,例如:ADD，则数据只能累加不能覆盖。这种情况下，通常没有DSO层，如果需要DSO层，则注意要将Transformation设置为累加模式。
若是full only, 要实现delta必须通过infopackage的设置来近似实现。