当前位置: 首页 > 科技观察

主数据系统的设计与实现

时间:2023-03-16 12:15:28 科技观察

1主数据系统的必要性随着企业信息化的不断深入,越来越多的企业建立了业务系统、办公系统等信息系统。由于规划、预算、实施方案等方面的限制,各种信息系统的建设节奏不一致,规划不统一,导致一个严重的问题:一些基础数据,如商品编码,客户代码等,在不同的信息系统中取值不一致。甚至定义不一致,给各个业务系统的打通和数据中心的建设带来很大的障碍。这些基础数据统称为主数据,而主数据的标准化和整理需要构建“主数据系统”。主数据问题主要有几个方面:各个系统的基础数据定义不同,数据集中处理(如BI、大数据、机器学习等)需要经过数据清洗、格式化、一致性检查和转换,成本巨大;数据字典相互独立,甚至存在不可调和的逻辑矛盾。例如,在系统A中作为主键的字段在系统B中不允许是唯一的;有时虽然定义了统一的规范,但各个系统都是独立维护的,无法保证万能钥匙。数据一致性。因此,主数据系统的建设宜早不宜迟,尤其是对于已经使用ERP的传统企业。但由于主数据系统侧重于“技术优化”范畴,在业务上很难看到立竿见影的效果,甚至对业务人员“透明”,投资也不小,那么如何应用对于资源不清楚。建立一个项目是一个不小的挑战。但这超出了本文的范围。2、主数据系统设计的基本原则主数据系统的设计方法有很多,但大多需要对原有的信息系统进行大刀阔斧的改造。因此,所有企业在主数据系统的实施上都比较保守,宁愿花费大量的人工处理和大量的系统补丁来进行数据清理和转换。这种方案效率低下,不能解决根本问题。在结构上,由于多个应用系统之间可能存在提供数据和使用数据两种角色,因此一般采用点对点两两交互的网络结构。它提出了极高的要求,同时也带来了复杂度高、实施周期长、无法按部就班实施、容易失败等问题。图1网络结构和星型结构显然,星型结构明显是网络结构所致,对原有信息系统的修改必然较少。主数据系统设计原则的要点是:数据同步由一般的“网状结构”转变为高度稳定的“星形结构”,打破了点对点交叉的复杂结构;通过“数据代理”方式,不侵入原有信息系统,无需对原有系统进行大量改动,有计划、有步骤地实施;主数据系统为每条数据记录设置一个全域唯一的uuid记录标识码,用于主数据记录的整个生命周期。识别、映射和转换;所有数据的转换和映射均由主数据系统实现,对原有系统完全“透明”;关联记录通过uuid进行多次映射,保证任何现有系统和未来的接入系统都不需要关心源数据之间的关系,复杂度大大降低。三、主数据系统的具体实现下面结合实现方法给出完整的数据库设计和流程图。并详细说明重点。该项目已运行半年多,其可靠性和数据一致性得到了严格验证。本项目的几个前提条件如下:(1)所有业务系统数据库均为MySQL;(2)所有业务系统数据提供者的主数据表都有id主键,但字段名不一定非得是“id”,也不一定有自增属性;(3)所有业务系统数据提供者的主数据表都有最后更新时间戳,字段名也不同;(4)所有业务系统数据提供者都使用标志标记“删除”,而不对记录进行物理删除。3.1总体架构总体架构为星型结构,如图2所示:图2主数据系统总体架构其中:(1)为了简化设计,基于前提的第二点和第三点,数据代理直接采用数据库连接方式,定期轮询数据提供者的数据库表。因此,数据提供者对应的主数据表必须有读权限,数据消费者对应的主数据表必须有插入/更新权限;(2)数据代理(1~n),分别连接主数据数据库和唯一信息系统数据库。业务系统数据库中可能只有一个“数据消费者”和“数据提供者”角色。例如,办公自动化(OA)系统可能只是作为“数据提供者”的角色,提供组织结构、人员等主数据。在这种情况下,“数据代理”不需要配置和调度“数据消费者”功能。(3)MySQL数据库表结构定义可以直接从information_schema.COLUMNS中获取,其他数据库可以找到类似的系统表。如果没有,则需要单独填写字段定义。(4)数据库设计如下:tb_columns_def:表结构定义,直接从information_schema复制tb_data_role。COLUMNS:数据角色定义)通过定时调度激活(每1分钟设置一次),连接到相应的信息系统数据库,检查是否有新增或更新的记录,如果有,则进行数据拉取——从源数据数据库中拉取并存入masterData数据库,同时记录“同步轮次”。(二)一个信息系统可以提供多个“数据提供者”。在轮询和处理所有数据提供者之后,该过程结束。(3)数据库设计如下:tb_data_sync_log:同步日志表,保存同步控制数据3.3数据消费者推送功能流程如图4所示:图4数据消费者推送流程其中:(1)被定时调度激活后,查看主数据系统是否有新的“同步轮”,有则推送数据。连接数据消费者信息系统数据库,将新增或更新的数据记录从主数据数据库推送到信息系统数据库,同时记录“同步轮次”。(2)查看主数据系统的“同步周期”是否有新增,通过tb_data_sync_log.relative_cycle_no与对应主数据(main_role)中记录的最新周期进行比较。(3)一个信息系统可能需要多个“数据消费者”。所有数据消费者轮询处理后,流程结束。(4)数据库设计与数据提供者相同(见第2节)。3.4数据转换功能流程如图5所示:图5数据转换流程:(1)数据转换是不同信息系统与主数据之间字段类型、长度、格式转换的核心模块。(2)数据转换通过参数配置和附加处理功能实现了高度的灵活性。(3)数据转换首先获取源数据表和目标数据表的字段定义,其次获取对应字段的转换规则。处理定义转换规则的所有字段:A.对字段类型和长度进行通用转换;B.调用额外的处理函数(如果有的话)进行特殊的转换;C.根据关联id规则读取(如果有)主数据数据库的id映射,用于处理对应的关联id;D、循环处理所有字段。(4)数据库设计如下:tb_transfer_def:转换规则定义表tb_transfer_rule:转换规则字段映射表tb_id_mapping:id映射表4重点总结主数据系统涉及多系统数据同步。主数据系统复杂度高,成功案例不多。基于上述前提,本项目取得了良好的效果。关键点总结分享如下:1.数据提供者新增的id和更新的时间戳。对于不满足这两个条件的数据提供者,无法识别新增和更新,无法进行增量同步,必须进行修改。如果由于各种原因无法修改源数据,可以考虑变通,使用数据库自??带的同步工具(如Oracle的DGG等),将新的和更新后的标识符添加到同步副本中;2、无论是数据提供者还是数据消费者,如果无法直接连接到数据库,“数据代理”需要以插件应用的形式存在,与主数据系统的通信采用WebService方式。它会带来缓存、重试、幂等……复杂度的大大增加。3、由于不同主数据表的字段之间存在映射关系,比如一个人所属的部门,需要对id映射进行多次转换。通过uuid映射得到。4.待补充——从数据库设计上,想一想就能找到,不再赘述。