基于异构数据库的高校数据集成设计与实现

周晓玮

(大连海事大学 网络信息与综合服务中心，辽宁 大连 116026)

一、高校数据集成工作现状

随着信息时代的来临，我国教育信息化已经上升到国家战略层次，高校信息化已经成为衡量学校办学水平的重要指标。在信息化建设过程中，业务系统越来越多，由于各系统功能不同，建设时期不同，没有统一的数据标准，缺乏数据校验，使用不同的数据存储方式和数据结构，彼此之间相互独立，形成数据孤岛，为数据共享增加难度[1]。

当前，国内高校已经完成了以人、财、物为核心的业务系统建设，从数字化校园逐步向智慧校园转变。智慧校园建设的主要任务是以各种业务系统为载体，将教学、科研、管理和校园生活进行充分融合，因此国内高校积极推进数据集成和数据交换工作，并取得了显著成就。其中具有代表性的研究成果主要包括以下几种：四川大学李帅等[2]提出的基于Neo4j的多源异构数据库集成方式，以图结构的形式集成异构数据库，不受数据格式影响，但Neo4j本身需要很高的开发和维护成本，操作复杂，学习成本较高，而且插入速度很慢，影响操作性能；北京理工大学周肖树等[3]提出了基于XSL语言转换的异构数据集成方法，集成速度快，但需要大量XSL转换工作，人力成本偏高；辽宁大学冯勇等[4]提出的元数据集成方法，采用先局部后整体的方式集成异构数据避免大量数据的存储和传输，但该方法缺乏对数据标准和规范的研究；内蒙古农业大学的程显生等[5]提出的基于主题映射元数据的异构数据库集成方式，该方法相比传统方法对综合性能有一定提升，但欠缺关于元数据删除方面的研究。

二、高校数据集成工作建设思路

从上述研究成果中可以看出，基于异构数据库的数据集成工作主要集中在两种方式：利用现有技术工具开发方式和基于元数据的数据交换方式。利用现有技术工具开发方式存在开发维护成本和人力成本较高、操作性能较低、对相关人员技术要求较高等问题；基于元数据的数据交换方式，存在缺乏数据标准和数据删除方面的研究不足等问题[6]。针对上述问题，本文以大连海事大学为例，提出了一种符合学校实际情况的基于异构数据库的数据集成方案，既避免过高的开发成本，又解决了元数据缺乏数据标准和数据删除能力不足的问题。方案系统架构如图1所示。

图1 基于异构数据库的数据集成系统总体架构

建设思路分以下几步：

第一步：统一数据标准，建设数据模型。在前期数字化校园建设时期，学校已建成众多业务系统，如人事系统、教务系统、研究生系统、学工系统、科研系统等。这些单独的系统已经投入使用了一段时间，非常成熟，但各自有自己的数据标准和数据结构，集成时标准不统一，数据交换难度大。为保证数据在采集、处理、交换、传输的过程中有科学、统一、规范的分类和描述，首先进行数据标准建设工作，再根据数据标准创建数据模型。这是数据集成和共享的基础。

第二步：梳理各类数据产生的权威数据源，确保一数一源。例如人事人员基本信息数据来源于人事系统，本科学生基本数据来源于教务系统等，遵守“谁生成谁负责”的基本原则，责权到位，确保每条数据和字段都能找到生产者和所有者。

第三步：明确哪些数据需要集成到数据中心。每个业务系统都有大量的数据，其中大部分是业务系统内部流程产生的过程数据，对其他业务系统没有价值，有价值的是各个流程产生的结果数据，数据集成工作只针对这部分结果数据。第二、三步和第一步工作实际上要同时进行，制定标准的同时要梳理出源头，并将需要集成的数据确认工作详细到字段信息，作为数据标准的制定依据。

第四步：数据抽取、转换、清洗和加载。数据在抽取过程中，要根据数据标准对不规范数据进行转换、清洗，去除冗余数据，然后加载到数据中心，作为数据共享和数据沉淀的基础。在数据进行转换时，创建删除标记字段和时间戳字段方法，解决元数据删除和业务系统共享数据时同步全量数据时间过长的问题。

第五步：对外提供共享数据。数据中心以服务接口的方式，实时提供共享数据[3]，并以数据为基础，根据学校教职工的任职生涯和学生的学习生涯，提出全生命周期数据管理概念：即以身份证件号为基准，对教职工的报到、入职、在职、离退休或离职等阶段，以及学生的本科生、硕士生、博士生、留校成为教职工或毕业后成为校友的各个阶段，进行全生命周期数据管理。

三、高校数据集成工作建设方案

(一)统一数据标准

制定并创建合理的数据标准，需要综合考虑国家、行业的标准规范，并结合学校实际业务情况。经过持续的研究分析，从编制、查询、实施和维护角度考虑，并多次与数据源部门进行沟通和确认后，学校将数据标准建设分为两部分：代码标准和元数据标准。

1.代码标准

代码是各业务系统都需要用到的代码类数据，例如政治面貌代码、籍贯代码等。基于国家教育部发布的《中华人民共和国教育行业标准JY/T 1001-2012标准》，参考国际上通行的软件开发标准和规范，同时结合学校实际情况，制定代码标准，并保证代码标准符合规范性、全面性、可扩展性、简单性的要求。

代码标准分为代码参考标准和代码执行标准。代码参考标准主要构建各种二类代码，制定标准代码需要参考的现行标准包括国标、行标和校标。

(1)国标：政治面貌代码、籍贯代码、专业技术职务代码、干部职务职级代码等一系列国家标准代码集。

(2)行标：培养方式代码、二级学科代码等一系列行业标准代码集。

(3)校标：根据学校情况，自定义的校内相关标准代码，如校区代码、教学楼代码等。校标的制定要以源头部门代码作为基准，以人事人员状态代码为例：该代码的唯一产生源头是人事系统，其他业务系统只使用不更改。为了保证代码建设的时效性，直接使用人事系统中人员状态代码作为校标代码。

代码执行标准是根据代码参考标准按照学校实际数据形成的，用于业务系统设计代码时的参考依据，以及数据集成时的转码依据。根据应用场景和业务分类，将代码执行标准划分见表1。

表1 代码执行标准

2.元数据标准

元数据是对数据特征、彼此关系、有关操作进行描述与规定的一种数据集合，是关于数据的数据，是数据管理活动的基础，用于记录数据库中数据的分布情况[4]。制定元数据标准，用于对异构数据源进行统一的逻辑表示，为数据集成提供统一基础结构，描述集成数据及数据来源[4]。

元数据标准要遵循严谨性和规范性，即元数据的互操作性和易转换性，以减少操作过程中的信息损失。制定元数据标准之前，首先要明确每条元数据的来源，确定元数据的具体属性。本文依据国家教育部发布的《高等学校管理信息标准》(以下简称《信息标准》)，结合学校实际业务情况，制定并建立学校的元数据标准。《信息标准》中涵盖了通用性的元数据标准，在此基础上，扩展了符合学校具体资源特性部分。

以人事人员基本信息的元数据标准为例，《信息标准》定义了大部分具有普遍适用性的元数据标准，如ZGH(职工号)、XM(姓名)、XB(性别)等。结合学校实际情况，在该项元数据标准中增加了SFHHJS(是否航海教师)等，其中代码字段直接映射到执行代码表，见表2。

表2 人事人员基本信息元素据标准

此外，元数据标准中还定义了数据表命名规范、字段命名规范、字段属性定义规范、编码规范、字段关联代码表，还需要制定合理的字段类型及长度。各类元数据表间有一定的逻辑数据独立性，减少连接运算。同时还要避免命名冲突、概念冲突、域冲突等，并识别出实体、原子属性及实体之间的联系，根据需要定义必要的索引，包括字段索引、多字段索引、簇集索引等，用于提高检索效率。

在数据集成建设中，以代码标准和元数据标准为基础，要求对于已经存在系统的非标准数据资源，根据数据标准进行转换后集成到数据中心作为标准的信息资源；对于新开发的业务系统，在整个建设过程中，要遵循学校的数据标准。

(二)建设数据中心

依据代码标准和元数据标准，创建出标准代码数据模型和元数据模型后，开始数据抽取、清洗和加载工作。本文以学校人事系统中教职工基本数据为例，数据集成过程如图2所示。

图2 教职工基本信息数据集成过程

1.数据抽取

由于不同业务系统使用异构数据库，甚至某些老旧业务系统已经没有技术维护人员，因此在进行数据抽取工作时，采取两种方式进行。

(1)使用接口

优点：不用直接访问数据库，安全性高；在开发接口时，可以提前完成数据清洗和格式、代码转换工作，也可以在数据转换和清洗过程中完成。

缺点：需要业务系统技术维护人员进行开发；当字段发生变化时，需要维护人员进行额外开发工作更新接口。

适用于仍在维护，可以快速提供或更新接口的业务系统。

(2)直接访问数据库

优点：访问数据库直接读取数据表或视图，没有中间过程，不需要进行额外开发工作。

缺点：直接访问数据库安全性低；当字段属性发生变化时，会导致视图失效，需要数据库管理员进行干预。

适用于无技术人员维护的老旧业务系统。

图2教职工基本信息使用接口方式抽取数据。

2.数据转换和清洗

在进行数据抽取过程中，发现很多数据存在质量问题，主要是残缺数据、错误数据、重复数据等。这部分数据需要进行转换和清洗，基本方法有：非空检查、主键重复、代码转换、格式内容清洗、逻辑错误清洗。图2教职工基本信息进行数据转换时，因为数据源中存在代码不符合标准问题，需要进行职务级别码、当前状态码、健康状况码、婚姻状态码和国籍地区码的转码操作。

3.数据加载

数据转换清洗结束之后，经过字段选择和排序，将源头数据和数据中心进行对比。如果数据源里有某条记录，而数据中心没有，进行新增操作；如果数据源和数据中心都有某条记录，并且数据不一致，则进行更新操作[7]。

4.元数据删除及超长同步时间解决方案

基于数据完整性考虑，数据中心的数据不会进行删除操作。那么当数据源记录删除时，数据中心该如何与数据源保持一致呢？为此本文提出逻辑删除方案，即在每个数据表中增设逻辑删除(SCBJ)字段。当检测到某条记录在数据源被删除时，加载数据时将该条记录逻辑删除字段设置为1，其他记录逻辑删除字段默认为0。对外提供同步服务接口时，通过该字段值进行过滤，防止已删除记录进入其他业务系统。同时这种方案解决了数据源删除记录后，很多历史数据出现字段值无效导致记录显示错误的问题。

某些业务系统的数据量非常大，导致其他业务系统共享时同步时间过长。例如40多万条记录如果全量同步，耗时100分钟以上，同时非常消耗服务器性能，导致用户操作体验差。为解决这个问题，本文提出时间戳字段方案，即在每个数据表中增设一个时间戳(SJC)字段。每条记录加载到数据中心时，如果监测到变化，就将当前时间赋予时间戳字段。业务系统在同步数据时，只需在初始化阶段进行一次全量同步，此后每次同步，通过对比当前记录和历史记录时间戳字段值的方法，判断是否需要同步该条记录，实现增量同步。在具体实践中，以数据量最大的门户系统为例，使用时间戳字段后，最长同步时长从112分钟缩短为43秒，极大节省了同步时间，提高系统运行效率。

逻辑删除字段和时间戳字段结合起来，还可以解决历史数据存储问题。每条记录都保存在数据中心，不会被删除；同时根据时间戳字段，可以判断该条记录的最后更新时间，方便业务系统查询历史数据。

5.全生命周期概念

完成数据集成的数据中心，涵盖了学校教职工从入职开始，经历调换部门、职务升迁、职称评审、退休离职等各个阶段的数据，还涵盖了学生从本科生入学、经历转专业、学籍变动、毕业答辩及离校到升级成硕士生、本科生，最后变成本校教职工或离校成为校友等阶段的所有数据。以此为基础，本文提出全生命周期概念。无论人员信息如何变化，通过唯一的身份证件号，都能智能识别用户当前状态和身份。由于历史记录不会被删除，教职工和学生入校后所有身份和变动过程都可以追溯，由此对所有在校人员进行全生命周期管理。同时根据每个用户对应的不同状态和身份，在学校身份平台管理系统中设置不同的权限范围，实现对业务系统的精准访问权限和角色权限控制。

四、结语

本文主要讨论了不同业务系统异构数据库之间的数据集成工作，包括数据标准建设，数据抽取、转换、清洗和加载工作，解决元数据删除问题和数据共享全量同步时间长的问题，提出全生命周期概念，精准控制用户对业务系统的访问权限。目前共集成学校6个主要业务系统的重要数据，同时为其他业务系统提供服务接口实现数据共享，已创建接口76个，包括通用接口48个，个性化接口28个。下一步工作，需要在此基础上进行数据治理，保证数据的可用性和完整性，同时注重数据安全管理，实现对隐私数据的加密、脱敏、模糊化处理，全方位保障数据的安全运作。