主数据库若干现象的解析.doc

主数据库若干现象的解析1、 数据入库后，无法找到原始数据（比如电话，地址等字段不一样了）解析：主数据库存储的数据为：更新了的、核实有效的数据。就是说，如果新数据和库中数据重复，那么数据是根据一定的条件进行更新的，选取较好一点的数据存储在库中。2、 为什么一批企业数据都有联系人，而新增企业为1000条，而新增个人为200条？解析：采用了较灵活的匹配数据方法。我们先把企业信息去重后，然后匹配个人ID，可以用多种方式匹配（在个人姓名长度1的情况下）：（1）Comp_ID+Per_name（2）per_phone+per_name（3）mobile+per_name（4）Email_ID+Per_name ，由于数据库中的个人表，有些是没有Comp_ID的，有些是个人新换了一家公司，造成以上情况。3、主数据库本来是不重复的，入库数据也没有重复的，可是入库后会有重复现象 解析：我们无法确认原始数据自然人的唯一性，仅能通过一定的规则判断。更新前库里没有满足，重新后就可能满足这种条件，比如 ：一个公司的个人原始电话为A，通过Comp_ID+per_name 重新至B，而B+Per_name 在原库中是存在的，所以原来不重复，现在重复了。4、在主库中查询，来源1的量（50条）+来源2（70条）的量不等于来源1和2的总量（100条）解析：一条数据会有多个来源和特性。但库中只会存储一条！5、数据为什么有那么多的日期列？解析：为了对数据进行细分。我们将各种数据相关的状态都做了标记，而不仅是日期时间：（1） 每个数据存储的表都会有一个In_Date，代表当前表本条数据的最后一次的更新日期。入库数据如包含这一条，那么就更新In_Date（2） 库中的重要字段都有_Updtm 字段，代表本条数据中该更的最后更新时间。入库数据包含这一条，并且含有该字段，那么更新此_ Updtm（3） 字段的_VerifyDTM 列，代表核实日期，代表该数据校验正确的时间（4） 字段的_Verify列，对应电话，因为电话的核实状态 标记拒访，占线，欠费，成功等状态6、 主数据库为什么不存储每一次的原始数据？解析：这是由我们公司的产品决定的。时效性是信息的最重要的一个特性。就是说，如果信息时间长了，就没有任何意义了。因为我们做的是数据产品。所以，我们的数据应该是更新了的并且全面的。而我们的广泛的数据来源要求我们对数据有一个相关性判断（也就是重复的确认）。所以不可能按照原始数据来存储。为了满足对原始数据的需求，我们把每次入库前已整理过的数据放入外部库方便使用。7、公司一个In_date ，个人一个In_date ，调出 数据我用哪一个？解析：B2B用公司的，B2C用个人的8、我如何得到2009-9-222009-10-30入库的数据 解析：可以选用来源表（main_source）的In_date 9、调出的数据ID 在回库的时候找不到了解析：数据库模糊去重的时候去掉了。可从表Doing_Del_Update_ID找到该数据现在的ID10、为什么外部数据有的放在保险库里解析：有些数据是为做保险采购的。而很多数据是不能入到我们的主数据库的。保险库里存放的移动数据。只是人和手机号码的对应关系。很多号码是卖号的人的信息，就是说人和号码之间并不是 人联系方式 的关系。由于一般只适合保险业务，所以就放在了保险库中。11、表SUB_27 后面的数据代表什么含义？解析：可以从表Par_Data_Type中找到对应关系。27代表车主数据12、如何查询每一批入库数据的量解析：级联表Main_R_Per_Source和Main_Source 即可。13、我想找到一条数据的原始部门职务和对应库里的部门职务怎么办？解析：使用表Main_Post14、查询A城市同一时间为什么有时会有不同的结果 解析：项目不同，使用数据的方式也不相同。如DM的要地址所在城市，SMS的查询手机所在城市，TM的查询电话所在城市。复合查询的要查多个条件。一般默认使用地址所在城市。15、是不是每次数据使用都要自身去重？解析：是。16、Alibaba 数据为什么没