锚表里面存在有UNIQUE_ID_IN_SOURCE_SYSTEM,只是这个字段没有用到。
模型:全球200多家保险公司共同制订的一套通用系统,相当于一套规则。类似于石油欧配克组织。
在保险系统里面,有一种表关系,这种关系是:一张表的记录,对应多张表的记录(1:N),处于N那边的表是对处于1那边的表的一个修改版本。这两种表,都存在UID与HASHCODE字段。具有关系的两张表记录,其UID号是一样的。如果存在一张处于N那边的表记录,用它的UID匹配不到一张处于1的表记录,那么这张表是无效的表记录。保单表与批单表就是这种关系的一个实例。
保单表的记录,可能会经过多次修改,而且每次修改的记录都需要记录到数据库里。为了识别某条记录是某一条记录的修改版本,就产生了UID这个字段。凡是在从表里的记录的UID与主表某一条记录的UID相等,则认为这是主表记录的修改版本。当通过关联知道UID相同的两条记录,就把这两条记录的HASHCODE作比较。如果HASHCODE字段相等,则证明过来的数据是一条老记录;如果HASHCODE字段不相等,则说明过来的记录是条新记录。
增量:时间刻2相对于时间刻1(时间刻2>时间刻1)数据有差异的部分是增量数据部分。
存量:存量是第一入库的数据。
存增量模式:客户提供的数据是以系统为单位,如果来自A表的任何一条记录,都能在B表中找到关联的记录,这种模式就是存增量模式。
首先,客户抽取的数据是随机抽取的,会有出现A表中某些记录,在B表中是找不到关联记录的情况。如果要保证记录是全增量的模式,就必须在客户得到提供的A表的记录后,把B表中的记录全部抽取出来,相当于为B表做一个副本,从而把所有在B表中与A表所有记录相关联的记录都找出来。这里涉及一个问题,就是B表的数据一定要抽取出来!因为客户的表都是生产表,只能采取读取副本的方式获取B表记录。如果直接用A表左联B表,会造成生产表响应慢,这样后果很严重。
存增量的工作过程是:客户提供来自A表的数据,从B表中读取副本数据,用A表左联B表,把得出的结果放到目标表里。
在这个项目中,目标表数据的作用还未明确。
案例:
A(UID,HASHCODE,DLDDM)
--A(业务号,哈希号,代理点代码)
B(UID,HASHCODE,DLDMC)
--B(业务号,哈希号,代理点名称)
A表有记录:
A.UID A.HASHCODE A.DLDDM
A 1 SH001
B 2 SH
002
C 3 SH003
D 4 SH004
从B表中抽取数据副本:
SELECT UID,HASHCODE,DLDMC,[MACK] = “9999” INTO TMP_B FROM B
--MACK的作用!
比如查询得到的记录为:
B.UID B.HASHCODE B.DLDMC
A
1
上海
A 3 广州
C 5 深圳
E 7 北京
用A表左联B表的副本:
SELECT A.UID,A.HASHCODE,A.DLDDM,B.UID,B.HASHCODE,B.DLDMC,B.MACK FROM A LEFT JOIN TMP_B B ON A.UID = B.UID
根据左联的工作原理,A表的所有记录必然会出现结果集左集合中,B表的能与A关联的记录会出现在结果集右集合中,B表与A表关联不上的就会在结果集右集合中填充HULL。故上面SELECT的结果集体为:
A.UID A.HASHCODE A.DLDDM B.UID B.HASHCODE B.DLDMC B.MACK
A 1 SH001 A 1 上海 9999
A 1 SH001 A 3 广州 9999
B 2 SH002 NULL NULL NULL NULL
C 3 SH003 C 5 深圳 9999
D 4 SH004 NULL NULL NULL NULL
判断是否新增记录(UID是否相等):由于在抽取B表时所使用的SQL语句里同时包含了一个附加的常量字段MACK,其值为9999。故在结果集中,检索MACK字段是否为空,就可以知道结果集中哪些是关联得上的,那些是关联不上的记录了,如上面结果集中第三与第五行记录就是那些在B表中关联不上而得出的记录。
判断是否增量数据:既是增量数据,其UID是一样的。经过上面的数据筛选,已经把没有关联(MACK IS NULL)的记录过滤了,剩下的都是能关联的记录,即第一,第二与第四行的记录。然后再判断A.HASHCODE与B.HASHCODE两个字段是否相等,相等的就证明过来的记录是老记录,如第一行的记录即使一条老记录关联得到的结果记录;如不相等,则说明过来的记录是新记录,如第二行与第四行的记录都是新记录关联得到的记过。
通过上述的工作逻辑,就可以判断客户所提供的所有数据的类型:是否新业务数据,是否是老业务数据,是否是老业务数据的增量数据。从而分别处理不同类型的数据。