核心公式：DB --> ETL --> DW vs REF file
错误产生原因：
1， DB/DW Connection Issue
2， SQL Issue
3， Product Bug
4， REF file not updated
物理需求分析：
1， Source DB: EBS, PSFT, Fusion…DB Instance
2， DW: 忽略数据源的存储形式，将数据以同一的形式存储。
逻辑需求分析：
1， ETL过程：The data stored in Source DB will be extracted, transformed, andloaded to DW.
关键点：
1， Each record in DW can be found in Source DB tables. No matter it isoriginal data or derived data.
2， If it is original data, we need to know which table and which columnin Source DB it comes from.
3， If it is derived data, we need to know the associated record with itin Source DB. In another words, how does this data derive from Source DB byETL.
错误分析：
1， DB/DW Connection Issue: (略);
2， SQL Issue: (略);
3， Product Bug: (分两种类型)
类型一：当OUT file输出的行数和 REF file显示的行数相等（num (out)==num (ref)），但某些字段不同
定义：无论该字段是originaldata 还是 derived data，凡是由Source DB经过ETL过程转化到DW里的，并且转化后的数据与DB中的数据不相等，但是DB中的数据与REF file相等，那么这就是一个Product Bug。
举例： 1. original data：
如果DW中某一个字段值为0，而REF file 中显示为null，通过ETLMAPPING查看到DB中相应的字段为null。这种情况通过核心公式表示为：
null --> ETL --> 0 vs null. 显而易见，这是ETL发生了错误，也就是ProductBug。
2. derived data：
如果DW中某一个字段值为45.2，而REF file中显示为45.3，通过ETLMAPPING查看到这个字段的值是通过两条Source DB中的值相加得到的，i.e. (20.1+25.2), 进过计算，DB中显示的值为45.3。这种情况通过核心公式表示为：
45.3 --> ETL --> 45.2 vs 45.3. 显而易见，这也是ETL发生了错误，也就是ProductBug。
类型二：当OUT file 输出的行数和REF file显示的行数不相等，并且OUTfile输出的行数小于REF file 显示的行数（num (out)<num (ref)），并且OUT file输出的行在REF file中可以找到
定义：如果ETL Load Plan 没有执行成功，就会出现转化到DW里面的记录缺失，这就是一个Product Bug。
举例：如果DW输出的行数为4，而REF file显示的行数为8，并且DW中输出的这4条记录可以在REFfile这8条记录中找到，那么这就符合num(out)<num(ref)，是ETL Load Plan没有执行成功，因此是一个Product Bug。
4， REF file not updated: (分两种类型)
类型一：当OUT file输出的行数和 REF file显示的行数相等（num (out)==num (ref)），但某些字段不同
定义：无论该字段是originaldata 还是 derived data，凡是由Source DB经过ETL过程转化到DW里的，并且转化后的数据与DB中的数据想等，但是DB/DW中的数据与REF file不相等，那么这就属于REF file not updated的问题。
举例：1. original data：
如果DW中某一个字段值为0，而REF file 中显示为null，通过ETLMAPPING查看到DB中相应的字段为0。这种情况通过核心公式表示为：
0 --> ETL --> 0 vs null. 这说明ETL是没有问题的，也就是DBUpdated or REF file not updated。
2. derived data：
如果DW中某一个字段值为45.2，而REF file中显示为45.3，通过ETLMAPPING查看到这个字段的值是通过两条Source DB中的值相加得到的，i.e. (20.1+25.1), 进过计算，DB中显示的值为45.2。这种情况通过核心公式表示为：
45.2 --> ETL --> 45.2 vs 45.3. 这说明ETL是没有问题的， REF file not updated。
类型二：当OUT file 输出的行数和REF file显示的行数不相等，并且OUTfile输出的行数大于REF file 显示的行数（num (out)>num (ref)），并且REF file显示的行在OUT file中可以找到（只适用于INCR，如果FULL中出现这种类型，同样归纳到product
bug）
定义：如果OUT file
输出的行数大于 REF File显示的行数，只有在增量的情况下可能出现REF更新的滞后性，因此是REF的问题，而FULL不存在此问题，如出现则是Product
Bug。
举例： INCR中，如果DW输出的行数为10，而REF
file显示的行数为3，并且REF file中这3条可以在OUT
file 10条中找到，那么就是REF更新的滞后性问题。
分析疑难点：
1， 没有ETL MAPPING， 无法确定DW中的data是从Source DB中哪些记录中得到的。