基于数据一体化管理模式的高校学生信息共享平台

张天文

（长春工程学院学生工作处，长春130012）

0 引言

近年来高校不断扩招，各学校的在校生人数大幅度增加。高校的教学、学生管理工作量也随之增加。在21世纪初期，许多高校开展了信息化的建设，如学籍管理系统、教务管理系统、成绩管理系统、宿舍管理系统等，这些信息系统有个共同的特点是均以“学生基础信息”为基础。由于高校信息化建设多数是逐步推进的，未能做到统筹规划，各系统在不同时期建成，数据格式不一、技术架构不同，形成信息孤岛，相互之间不能联通［1］。一方面导致各部门重复录入学生信息，另一方面导致学生信息在各部门信息系统中不一致的问题，给高校的日常管理工作带来很多困难。迫切需要进行改造升级，实现各信息系统的“学生基础数据一体化”管理。

近年来，对高校信息共享平台进行了有一些相关研究。例如从学生信息共享的安全角度出发，利用.NET和XML实现高校多层次数据信息的数据交换［2］。利用.NET和Web Services技术将教务信息管理、财务信息管理和学生信息管理功能模块进行了整合，实现校务信息跨部门共享［3］。利用可配置规则实现学生住宿信息与教学、资产、收费等系统的同步［4］。这些研究在一定程度上实现了高校信息共享，但没有发挥学生信息作为基础资源信息的导引性和关联性。针对异构系统的数据共享也是近年的研究热点，如SOA（面向服务架构）和ESB（企业服务总线）是通过简单的标准接口实现异构系统间的通讯与协作的有效方案［5］，或采用基于JMS（Java Message Service）规范的ActiveMQ消息系统为支撑平台实现数据交换和共享模式［6］。

本文将采用SOA架构模式设计开发“学生基础信息一体化共享平台SISSP”（Student Information Integration Sharing Support Platform）（以下简称“一体化平台”），共享平台中增删改查等业务处理均包装成服务，服务的接口依据统一的XML和Web Services标准，确保异构系统能够实现交互和整合。未来开发的新的高校管理系统只要采用同样的数据和接口标准，就确保能够快速地接入平台并共享数据。

1 一体化平台设计的思路和目标

针对高校信息化建设业务类型多、独立性强、关联度差，加之有多个信息系统并行，条块分割导致的管理难题。本平台梳理了高校的各项业务，规范整理并统一了基础数据，确保各业务统一标准，统一接口。继而对各项工作的流程进行重新梳理和整合，建立起优化并能够有效支撑高校人才培养目标的信息化流程；然后在此基础上进行各分项工作的信息化的规划设计。横向上实现各业务子系统间的信息资源共享，减少各部门基础信息的重复采集录入，纵向上为基于海量数据的数据挖掘、深入分析决策提供支持。

平台的主要设计思路包括：

1）建基础。一体化管理首先要实现数据层面的一体化，要建立全校统一的学生基础信息库，为各部门提供信息共享和数据支持。

2）建协同。做好高校内各部门学生相关工作的协同，涵盖学生管理、教学、科研、档案各部门，建立起能够实现业务关联的一体化信息平台，实现高校各项业务数据和业务层面的整合。

信息平台的实现目标是建成数据大集中模式的基础数据共享平台，平台以“学生个案信息”为基础，满足高校教务、学生、档案等各业务管理，统计汇总和分析决策需求。使各种信息高度集成、完全共享，而不是人为割裂，彼此隔离。各项业务基于信息技术实现集成，实现了统一平台、统一基础架构、统一用户角色管理、统一安全认证。杜绝了多个平台管理下各自为政的现象。

2 平台的总体架构

一体化共享平台在高校各信息平台中处于基础支撑平台的地位，可以为上层的应用系统提供数据交换和业务关联共享的集成环境，实现高校各类管理业务的一体化联动管理。其总体架构如图1所示。

图1 一体化平台的总体架构

架构中包括学生基础数据共享库、管理模块、开发模块、接口模块4大部分。

学生基础数据共享库是独立于现有各应用系统之外的独立数据库，主要存储学生的基础信息，还进行各应用系统数据交换的信息的备份，是高校各类应用系统实现数据交换和业务关联的基础资源。

接口模块主要实现与现有应用系统的对接，提供Web Services标准接口，支持批量数据交换和实时数据对接，满足各应用系统与一体化平台的数据交换需求。另外，接口系统内置ESB数据交换总线，支持通过消息机制实现各应用系统之间的数据交换。

管理模块实现各应用系统的远端接口子系统的接入、配置，并提供了一套完整的用户管理系统，通过信任机制与各应用系统的用户系统进行关联，实现整个一体化平台体系内的用户的管理、角色授权、访问控制。

开发模块提供了一个快速定制开发的可配置框架，框架已实现了与数据共享库的绑定，可以通过手写SQL快速配置，实现对学生基础信息的访问和管理，方便更灵活地运用海量学生基础信息。

总体架构中，数据共享库是基础资源，接口模块是外部通道，管理模块实现配置和部署，开发模块提供快速二次开发的环境。各部门共同完成基于学生基础信息的各应用系统信息资源共享和业务关联。

3 平台基础数据共享库的设计

一体化平台的出发点是实现学生基础数据的共享，因此需要搭建基础数据共享库。数据库体系的基础是学生基础信息库，并依此划分为基础层、应用层和决策层3个层面，如图2所示。

图2 一体化平台数据库体系

1）基础层：设计实现学生基础信息库，主要包括高校各管理部门需要的学生的基本信息，根据各部门的需求出发，确定如下字段：姓名、性别、民族、出生日期、户籍地、学籍编号、身份证号、入学年月、专业、班级编号、人员类型（博士、硕士、本科、专科）、联系方式等12个数据项。

该数据库存储学生基础信息数据和统计数据，是其他业务系统和决策系统的基础，并满足与各部门学生信息交换的需要。其数据格式严格依据国家人口、教育部门相关标准规范。

学生基础数据库的数据来源包括数据导入、填报录入和对接交换3种途径。数据导入适用于大批量学生的新增管理，例如对于新生数据可以通过招生部门提供的Excel格式的学生信息表批量导入，一体化平台提供批量导入接口。填报录入适用于少数学生信息的补充，高校各系部学院或职能部门可以通过填报系统逐个录入学生信息。对接交换适用于在常态运行时，定期将各部门的应用系统数据导入一体化平台数据库，继而实现信息的共享。

为了实现数据共享，需制定《学生基础数据共享规范》，确定各部门共享的数据内容、格式和交换频率。各部门需依据规范和要求提供基础库中需要的其他部门业务数据。

2）应用层：包括学籍管理数据库、成绩数据库、档案数据库、招生数据库、就业数据库、宿管数据库、奖惩数据库等。各部门信息系统的数据库均属于本层面。依托基础信息数据库实现各类业务信息的采集、变更、维护、共享等管理需求。

3）分析决策库：包括统计分析数据库和决策用数据仓库。数据仓库中的数据是学生数据库和应用层数据库中的数据长期积累下来的，通过数据挖掘工具有选择地提取形成的，供对学生进行各类统计分析决策系统使用。

4 平台数据交换的设计

4.1 平台数据交换机制的设计

一体化平台通过接口模块发布Web Services服务，交换发起方实时调用一体化平台的服务来发起交换。交换报文选择XML格式，系统提供了批量数据交换和实时数据交换2种模式。

4.1.1 批量数据交换方式

批量数据交换方式是以FTP进行文件交换。将数据文件以.zip格式压缩，并使用专用加密工具，加密压缩后形成交换文件进行交换。应用系统可以根据需要向一体化平台集中上传交换文件，例如新生入学、毕业生离校时。所有交换文件采用GBK编码。

4.1.2 实时数据交换

平台提供基于Web Services服务的实时数据接口，实现系统运行中的实时服务调用。针对各部门应用系统间的相互访问需求，我们定义为协查访问请求，提供了专门的协查服务接口。

4.2 平台接口设计及处理流程

要实现依托一体化平台的异构系统数据共享，必须要确定数据在各业务系统之间的流转、交流，学校自编代码的制定和流转策略［7］。下面说明本平台的接口及流转机制。

4.2.1 平台提供的接口

各部门应用系统在工作中与学生基础数据库有数据交换的需求，我们提供了学生基础信息查询接口。各部门之间会存在相互查询信息的需求，例如教务部门评选优秀毕业生时需要查询学生管理部门的奖惩信息数据库。针对系统间的协查请求，平台设计了协查信息接受接口和协查回执信息接收接口。

表1 平台接口

4.2.2 各应用系统需要提供的接口

平台基于SOA模式构建，需要接入的各应用系统进行服务化封装，为了简化原系统的改造，平台提供Web Services服务的接入，需要各应用系统实现表2中的服务接口。

表2 应用系统接口

各应用系统利用一体化平台提供的学生基础信息查询接口可查询学生的个案基础信息。其流程为：1）应用系统向一体化平台发送个案信息查询请求；2）一体化平台将符合条件的个案信息返回给应用系统。

应用系统利用一体化平台提供的信息协查接口进行信息协查的流程为：1）应用系统向一体化平台发送信息协查请求；2）一体化平台向应用系统返回应答信息（只返回协查编号）；3）一体化平台经审查后，通过应用系统提供的协查回执接口向应用系统发送协查回执请求；4）应用系统接到请求后向一体化平台发送协查回执应答。

4.3 平台数据交换流程

高校各部门可以直接登录一体化平台，利用各应用系统提供的个案查询接口查询学生基础信息。具体流程为：1）一体化平台向各应用系统发送学生基础信息查询请求；2）各应用系统将符合条件的个案信息返回给一体化平台。

各部门也可以通过已接入一体化平台的本部门应用系统，利用各应用系统提供的信息协查接口进行信息协查。协查管理分为接受协查管理和发送协查管理［8］。各应用系统通过“接受协查管理”功能可以查看其他部门应用系统发送给本部门的协查信息。系统提供多种协查筛选条件，可以依据“发送系统”筛选，依据“专业”“班级”等筛选，依据“接收地未接收”“接收地已接收”“接收地未反馈”“接收地已反馈”筛选。系统还可将协查信息设置为“紧急”“急”“一般”3个级别，便于接收系统快速检索。发送协查时可以将所有信息均发回协查，也可仅将发生变更的信息发回协查，系统提供发送信息类别的选择功能。

具体流程为：1）一体化平台向各应用系统发送信息协查请求；2）各应用系统向一体化平台返回应答信息（只返回协查编号）；3）各应用系统经审查后，通过一体化平台提供的协查回执接口向一体化平台发送协查回执请求；4）一体化平台接到请求后向各应用系统发送协查回执应答。详细流程如图3所示。

图3 平台数据交互流程

对各应用系统在当月新增或修改的学生基础信息，平台均自动将其列入“应发送协查”信息列表中。操作员可以在其中选择发送。通过“已发送协查”可以发送出的协查信息状态，提供“接收地未接收”“接收地已接收”“接收地未反馈”“接收地已反馈”4种筛选类型，可以依据“专业”“班级”和“紧急”“急”“一般”检索已发送协查信息。

5 结语

本文研究实现的平台在长春某高校开发成功后进行试点应用，取得了显著的效果。平台实现学生基础信息的统一管理，将各业务相关学生的基础信息从各部门业务系统导入到一体化平台，由各业务部门进行增量维护，信息量少而精。各业务部门共享基础数据，可以随时调阅查询。避免了以往各部门由于信息互通不及时导致的学生管理、教学管理制度执行不力的情况。平台在设计时对高校的各项业务进行了系统的流程梳理和分析，主体流程结构合理、完全实现了基层业务的自动化、流程化操作，最大限度地减少了基层工作量，提高了业务管理的精细度、准确度。同时依托大量业务基础数据，可以随时给学校各部门提供各类的汇总信息、分析信息、预测决策信息。

平台各业务模块基于统一框架的模块化技术开发，未来能够适应高校业务流程的变化要求，满足功能和内容的扩充、完善。集成系统各业务的标准接口统一，能够实现数据共享、跨部门的业务集成。

［1］Whiteaker Jon，Schneider Fabian，Teixeira Renata.Explaining packet delays under virtualization［J］.ACM SIGCOMM Computer Communication Review，2011（1）：132－145.

［2］胡宁.XML在高校数据资源库共享平台的应用［J］.现代电子技术，2011，34（9）：99－101.

［3］胡晓燕.基于SOA技术的校务信息共享平台的研究与设计［D］.成都：电子科技大学，2013.

［4］杨晓雪，李刚，胡庆亮.基于数据共享和规则可配置的高校学生住宿管理平台［J］.中国教育信息化：基础教育，2013（2）：75－77.

［5］徐学东，孙巍，季才伟.以ESB为中介的公共卫生应急支撑平台研究［J］.计算机与现代化，2010（8）：167－171.

［6］郭智敏，魏红宁，邓碧敏.基于JMS的高校信息互操作平台数据共享的研究与实现［J］.实验技术与管理，2011，28（5）：268－271.

［7］罗雅过，赵宁社.高校数字化校园数据中心平台的研究与设计［J］.计算机技术与发展，2014，24（9）：217－221.

［8］Simitsis Alkis，Skoutas Dimitrios，Castellanos Malú.Representation of conceptual ETL designs in natural language using Semantic Web technology［J］.Data ＆Knowledge Engineering，2009，69（1）：96－115.