与合同支付流程的系统集成
工作内容：将原OA系统中合同支付流程所需要用到的合同基本信息和供应商基本信息改为从采购管理软件里读取
数据集成之前
OA合同支付模块（以下简称OA）：需要合同信息，供应商基本信息，供应商银行账户信息，OA上开了输入界面，数据（以下称为DB1）存储在OA系统数据库。
采购管理软件（以下简称PROC）：合同管理模块可以输入合同基本信息，供应商管理模块输入供应商基本信息，银行账户信息作为供应商的属性，一起输入。数据（以下称为DB2）存储在采购管理软件的数据库里。
从功能来看就能明显发现两个系统在业务层存在重叠，同样的合同信息和供应商数据存在两个不同的地方，各自引用，互不同步，这就是标准的信息孤岛。
为什么要集成
消除信息孤岛。当然不止这点作用，但是对于我们来说消除信息孤岛是最具有现实意义的目标，也是系统集成的第一步，在没有信息孤岛的前提下系统集成的更多优势才能显现，否则都是空中楼阁。
集成方案
专(zuo)业(fang)的(shi)系统集成一般包括两个工作内容：功能集成、数据迁移。功能集成是为了将数据的入口统一，数据迁移是为了保证工作的延续性，使业务不因系统集成而中断，最大限度的保护数据的价值。
功能集成并没有太多困难，OA把基础信息输入功能砍掉，合同信息和供应商信息从PROC中输入，通过接口供OA调用，WCF、WebService、RestfulAPI一堆东西招呼过去，把功能跑通基本没有问题。
然而数据迁移则遭遇了非常大的困难。DB1数据根本无法迁移到DB2中。DB1和DB2的数据结构不一致，DB2有不少必填项在DB1中缺失，而且DB1的数据存在一个致命问题就是“供应商名称”这个从逻辑层面本该作为key的数据不具有唯一性，我的理解是不满足2范式。难题摆在这里，DB1的数据必须要合并到DB2中，否则之前的输入的数据将无法被使用，合同付款流程无法找到目标合同并执行后续动作。但是合并又会对DB2数据造成破坏，让合并后的数据丧失唯一性约束条件。
问题的分析和解决
1.数据结构不一致，DB2部分关键信息在DB1中缺失
对DB1的数据按照DB2的要求进行数据清洗，例如DB1中的合同没有所属专业信息，我们对合同号进行解析，拿到采购包号（约60%可以解析出正确的采购包号），在公司级采购分包表中找到对应的专业，在对剩下的40%的合同，根据填写人所属部门，找到对应的专业（约50%可以找到精确的专业），经过两遍清洗，大部分合同都找到了对应的专业信息，剩余合同再根据DB1中的可用信息抽丝剥茧，经过数遍算法解析加人工查找最后完成全部（客观说达到了99%）的数据的清洗，将DB1和DB2的数据对齐。
2.数据唯一性遭破坏
DB1的合同数据和供应商数据因为从逻辑层面没有保证唯一性，都存在重复登记的情况，供应商信息尤其严重，如果这样的数据直接写入DB2，就会导致DB2的数据也丧失唯一性，我们称这种现象叫数据入侵，入侵的结果是对数据价值产生了破坏。
为了确保DB1和DB2的数据都能用，我们想了很多办法，尝试对DB1的数据进行清洗，但是并不能有效地恢复数据唯一性。最后换了思路顺利地解决了，概括一下：造一个数据断崖，DB1放在断崖下面，DB2放在断崖上面，取数据的时候采用俯视视角获取的投影面积是DB1 DB2一个完整的饼，实际上两个是完全隔开的，DB1封存在断崖下，不管供应商名称是否有重复或者相近，每一条数据都按照DB2的规范设置主键key，成为唯一的数据，供查询调用；后续所有新产生的数据都按照规范的约束条件进入断崖上的DB2里。
后续跟进
差不多三周时间稳定下来，与我预想的一致，陆续补充了供应商名称修改、银行账号修改、地址修改等小功能，整个集成工作告一段落。
总结
这次集成虽然事情不大，但是学问不小，经验更是宝贵。大概有以下几点：
（1）信息系统的功能设计应该遵循计算机学科的基本原理，比如数据库设计必须要遵循三范式，不能为了录入方便就让用户随便输入，数据库随便存储，有时候并不是软件开发人员考虑不到，而是用户为了方便要求我们非要这样做，我觉得合理的解释和拒绝是必要的，否则方便只是一时的，留下的却是巨大的隐患。
（2）数据清洗、数据断崖有用但不是万能的。这些方法或技巧是我们做系统集成时可以使用的有效武器，但是这些手段基本都属于比较末端的武器，一旦达不到预期效果，恐怕找不出更好的办法了，届时系统集成将面临巨大的困难，因此前期做好规划，从源头降低集成的难度才是正确的选择。
（3）信息系统建设试错的成本非常高。从这次实战可以看到，前期数据的质量如果没有控制到位，后期做系统集成的时候数据清理的成本要远远高于当初加强数据质量控制的成本。
（4）尽早启动主数据建设可能也是一个办法，将系统之间有耦合的数据向上提一层，核心作用是消除信息孤岛，但是需要非常精密和前瞻性的规划设计，这是一个巨大挑战。
原创文章引用请保留出处
