OLTP(On Line Transaction Process) Technology Considerations 联机事务处理的技术考虑事项
这一部分主要讲述了联机事务处理的系统中涉及到的数据存储方式（包括写入和读取数据库）。
物理更新，数据在R/3系统中进行更新的时候通常有两种形式，同步和不同步的。同步更新都有程序执行，用户需要等待确认完成。而不同步更新则通常是接近实时地完成，用户无需等待业务操作执行结束。按照周期的长短，不同步更新又被分为了V1和V2两种更新方式。V1是时间要求相对严格的更新，它的更新进度完全取决于交易表所限定的进度。而V2则是时间要求不严格的，它通常用来更新一些不需要经常变化的和交易相关的统计数据。一般来说，任务队列越长，更新的速度就越慢，这个基本上是要取决于系统负荷的。
从数据仓库的角度出发，在运作系统中数据的写入有两种基本方法，使用增量变化捕获机制和不使用这一机制的。目前，SAP BW中的增量捕获机制正在发展中，R/3中已经实现了增量捕获机制。
在SAP BW出现之前，就有趋势将R/3分为几个分开的实例，并在其间仍然进行数据流通，这个时候业务框架的概念得以发展，而原先版本的应用程序渐渐淡化，并让它们都通过ALE进行交互。工作流包括在供应链中的预警和通知等，也渐渐的从中清除。在ALE出现之前，其实也已经有一种用于审计的变化日志的存在来实现类似的功能。也有部分主数据增量抽取器使用ALE作为更新检查工具过，不过最近来讲，最牛的还是增量队列法。
另外还有一种增量检验机制的方法，是由BADI提供的。在此不做赘述。
不稳定文档，SAP BW中的每一项事务，都有一个过程——生命周期，它也有两种不同的状态，活动和不活动状态。属于活动状态的事务，相关的描述文档可以是连续更新的，比较常见的就是一个交易（order）追踪文档的状态有好多种，它本身的内容，就包括了它的当前状态，而且这也是非常重要的。
相似地，一些后发的数据流。也会跟随这商务的进行而与之联系在一起。
理解数据的不稳定性，对于理解BW的信息模型是大有好处的，在R/3当中何时需要更新和重新获取数据，在一个商务文档变得不再活动的时候把它放到另外一种类型的文档中去。在BW中，有关不活动文档的数据通常只需要加载一次即可。因为它们不会发生变化。（这句是废话-。-）
读取数据，经常会发生第三方的产品想要连接到SAP BW中进行数据读取而脱离开SAP的应用层的事例，尽管SAP R/3中的许多数据都是直接可调用的，但是仍然有一些复杂的地方，首先，需要过滤掉商业逻辑后将这些数据表全部得到，其次，你可能会遇到技术上的困难，比如应用服务器缓冲的数据和锁定的数据等等。处理这些问题需要对业务逻辑的技术细节极其熟悉才行。即使当数据提交给数据库的时候，它也未必在一个很容易读取访问的地方。SAP将它的数据表们分成了几种不同的类型，以进行技术上的区别。
它们分别是：
l 简单表（Transparent Tables）：简单表就是简单表，你最开始接触的那种表就是了。
l 数据库视图：就是你知道的那种视图的定义，呵呵，这个没有做进一步的细分。
l 池状表（Pooled Tables）这个在SAP发展R/3的初期出现，早期的时候，数据表的数量有限制，这个时候随着SAP BW中对数据量的增加，人们开始将许多的表放到一个表里面，这个原先的作为母体的表，就被称为Pooled Table.这些表把子表的表明作为主键，数据则以一种很长的row string 来表示。
l 群状表，和Pooled Tables差不多吧，主要区别就是Cluster tables里面会有一些复杂的存在于程序内存中的数据对象可以直接存在其中而不需要任何其他的操作。
l 逻辑数据库，这一层次可以表现实际上的表，也可以不表示，它流行于报表制作的阶段，因为用户无需考试实际数据的问题而进行报表的构思。