该篇主要描述已实现的一种ETL过程：
环境描述：
由于源端的表结构和正式库的表结构大部分是一一对应的，所以对于这大部分表进行设计了一套通用的过程进行转换。现在先来描述该套设计，对于一对多和多对一的过程下章进行描述。
设计概述：
主要需要设计几个所需的表，TB_MAPPING TB_TRANSCONF TB_ETL_ERROR_LOG
n 第一个表：该表是用来配置源端表结构与目的端表结构中字段的对应关系，该表中主要记录以下字段：源端库名、源端表名、源表该表的字段名或表达式、目的端库名、目的端表名、目的端该表的字段名、是否为主键。根据这些信息可以动态拼接出以下语句：
INSERT INTO TARGETDB.TARGETTB(CL1,CL2…CLN) SELECT CL1,CL2…CLN FROM SOURCEDB.SOURCETB;
该条语句则可以直接将源端的数据进行转换。
而是否为主键字段，这里主要是用于对数据进行装载时。这里在装载时是用先DELETE后INSERT的方式进行装载的；
n 第二个表：该表是用来配置整个ETL流程的表。其中主要记录有以下信息：源端库名和表名、目的端库名和表名、Job组号、源端增量上次时间戳点、源端当前最大时间戳、转换临时库上次装载时间戳点、转换临时库当前最大时间戳点、每次运行数据量、每次循环次数、转换发生时间、装载发生时间；
n 第三个表：该表是用来记录每个环节的错误日志信息：其中主要记录以下信息：源端表名、目的端表名、起止时间、job组号、错误类型、处理状态和错误详细日志。
设计详细描述：
通过以上三个表大致可以将一对一的ETL整个过程实现，并且可以做到监控等。
一、获取增量，并且进行不同表的不同业务逻辑的转换，将转换后的记录存到一个临时库中。
1.1主程序（详情请见其中的注释）
1.2每个表的详细流程图
该图是通过分页的方式对找到的增量进行分页处理，每次处理配置表中定义的数量，循环次数也在配置表中进行了定义。每个步骤发生了错误都将会进行记录到错误日志表中。执行完该步骤后，就已将增量数据转换到临时库中。下一步就是将该部分数据装载到正式环境中。
二、装载临时库中的数据到正式环境中
2.1 主程序 跟上面的主程序一样
略
2.2 每个表的流程图
该图中表述了两步，第一步是装载到LoadData库中，第二步是装载到产品库中。有人会问为什么不直接装载到产品库中呢？因为发生业务逻辑转换的库跟正式环境产品库是物理隔离的，即在两台不同的服务器上。而为了使先DELETE后INSERT这两个操作放在一个事务中，我们将装载过程用存储过程来完成。有人又要问了，数据库中DBLink不是也可以吗？经过测试，如果使用DBLink的话，则会发生一个错误：当由于网络等原因导致Session中断，而没有装载成功时，这时DBLink并不会返回错误值，而是一直卡在进程中。而当遇到表中有附件的情况时，这种情况发生的频率会更高。所以现在在产品库端也使用了临时库来完成该操作。
2.3 2.2步骤中的“装载到LoadData”步骤图
2.4 2.2步骤中的“装载到产品库”步骤图
