约束因素下高校学籍自适应生成模块设计

（武汉工程科技学院信息工程学院，湖北武汉 430200）

0 引言

教务管理系统（以下简称教务系统）是目前几乎所有高校都在使用的一种管理信息系统，作为数字化校园中最重要的核心系统之一，教务系统与其它系统之间通常都存在不同程度上的联系［1-7］。其中，教务系统中学籍信息的基础数据来源通常都是招生管理系统（以下简称招生系统），一般由招生系统提供当年招生录取数据，教务系统在此基础上生成学籍信息［8-20］。在常见设计方案中，教务系统与招生系统对接模块的数据结构通常被设置成固定的，学籍生成模块通常只是根据新生专业分配学籍［21-26］。随着时代发展，招生工作模式在不断发生变化，各高校招生部门纷纷为新生提供各种便利化服务，使得有些原本在新生获得学籍后才安排的工作被提前到招生录取工作中，从而导致招生部门最终提交给教务处的新生基础数据常包含一些约束性因素，这给教务学籍管理工作带来了新的挑战，传统教务管理系统学籍生成模块已难以适用于这类数据结构。因此，设计一种能够适应新形势下需求的学籍自适应生成模块成为教务系统开发的重要内容。

本文通过分析招生数据中与专业字段组合后对学籍分配构成约束性影响的字段特性，提出以专业为单位构建学生与约束因素组合数据集，将约束因素值排序后以连续首尾取值方式为学生分配学籍，从而实现约束因素下的学籍自适应生成。

1 传统教务管理系统学籍生成模块中的问题

目前，高校教务管理系统中常见的学籍生成模块通常是通过统计各专业新生人数并根据预设的班级人数上限，自动生成各专业班级信息和各班学生信息，从而生成学籍数据。该模式在基于传统仅以专业为学籍分配要素的招生数据环境下能够高效运作。

然而，在笔者主持的一个教务系统开发项目中，遇到了一个新问题。学校原本招生处向教务处提供的数据只包含学生基本信息和录取专业，教务处根据该数据设置班级并为学生分配学号和所属班级，以生成学籍信息，再由后勤部门根据学生分班情况分配宿舍，宿舍分配遵循“同班新生尽量集中”原则，以便于日后管理。此时，教务处在分配学籍时相对简单，只需考虑同专业的各班级人数和男、女生比例尽量均衡即可。但由于招生处又为新生提供了一项新服务——新生来校之前即可在网上自行选择并确认宿舍，由此带来的改变是新生在还未获得学籍的情况下就已确定了宿舍。考虑到“同班新生宿舍尽量集中”原则，此时教务处在分配学籍时必须考虑两个要素：①同专业的各班级人数和男、女生比例尽量均衡；②同宿舍同专业的新生尽量安排在一个班，以便于管理。该校原有教务系统仅根据新生专业分配学籍的模式已无法生成符合要求的学籍信息，教务处不得不依靠人工方式分配学籍后再导入系统，效率极大降低。为此，学校教务处希望新教务系统的学籍生成模块能够基于新的招生数据结构自适应生成学籍和班级信息。

2 约束因素下学籍自适应生成模块设计

通过分析不难发现，学籍分配是以专业为中心点展开，因此应考察招生数据中其它相应字段与专业字段组合后是否对学籍分配产生影响，如果产生了影响，则说明该字段是影响学籍分配的一个约束因素，这样的约束因素可能有若干个。在项目需求中，要求同专业同宿舍的新生尽量分配到一个班，故该约束因素就是新生宿舍。本文以宿舍要素为例，阐述主要设计思路。

提取招生数据中部分字段加以说明，其结构如表1 所示。

Table 1 Some fields in enrollment data表1 招生数据中部分字段

在设计时，可按以下步骤进行：

（1）预设班级年份（入学年份，例如20 级）以及各专业班级人数上限（不同专业的班级人数上限可能不同）。

（2）统计表1 中所有专业及各专业男、女生人数和总人数等数据，生成按专业进行统计的数据集，其中逻辑数据表结构如表2 所示。

Table 2 Structure of professional statistical data table表2 专业统计数据表结构

表2 中的“学生组合x”和“宿舍组合x”均为字符串形式，分别表示该专业具体的学生数据和与学生数据对应的宿舍数据，结构分别为“学生1；学生2；学生3；……；学生n”和“宿舍1；宿舍2；宿舍3；……；宿舍n”，宿舍与学生数据之间是一一对应关系（学生1 对应宿舍1，学生2 对应宿舍2，其它依此类推）。以C#语言（下同）描述此算法：首先创建数据集DataSet 对象ds_zy，并增加数据表和表中字段列，用于存储按专业进行统计后的数据，代码如下：

读取表1，逐行扫描每行记录，取出“专业”字段的值zy，判断在ds_zy.Tables［0］中是否存在“专业”字段的值为zy 的记录，如果不存在，则新增一条记录将当前学生的相关信息录入ds_zy.Tables［0］，各字段的值分别为：zy、0 或1（取决于性别）、0 或1（取决于性别）、当前学生（姓名—性别—身份证号）、对应宿舍（楼栋—宿舍）、当前专业层次、当前专业所属学院；若存在，则修改ds_zy.Tables［0］中该专业记录，此处算法如下：

Step1：判断当前学生性别，若为男，则将该记录“男生人数”和“总人数”字段的数字分别加1，否则将“女生人数”和“总人数”字段的数字分别加1。代码如下：

Step2：在“学生”字段中的字符串末尾追加当前学生信息，追加的字符串格式为“；姓名—性别—身份证号”。代码如下：

Step3：在“宿舍”字段中的字符串末尾追加当前学生所在宿舍，追加的字符串格式为“；楼栋—宿舍”。代码如下：

（3）根据表2 和系统中已存在的专业信息（编号、名称）以及（1）设置，生成按班级统计的数据集，其中数据表结构如表3 所示。

Table 3 Structure of class statistical data table表3 班级统计数据表结构

表3 学生字段的值“学生组合x”表示该班级的学生数据，其字符串结构为“学生1、学生2、学生3、……、学生n”。为达到此设计目标，可按如下算法进行：

Step1：创建数据集DataSet 对象ds_bj，并增加数据表和表中字段列，用于存储按班级进行统计后的数据，代码如下：

Step2：遍历ds_zy.Tables［0］中的所有记录，根据（1）中设置的当前专业班级人数上限确定该专业班级数量以及每个班的男、女生人数和总人数。根据系统中已存在的专业信息（编号、名称）和已设置好的年份生成班级编号、名称和所属专业（专业编号）。

Step3：以表2 中的学生和宿舍字段为基础，将男、女生分组并进行如下操作：查找当前专业每个宿舍中的学生，并按学生人数由多到少对宿舍进行排序。例如：宿舍1（5人），宿舍2（3 人），宿舍3（4 人），宿舍4（3 人），宿舍5（5人），宿舍6（2 人），宿舍7（2 人），宿舍8（1 人）。因此，按顺序可生成宿舍序列：

宿舍1；宿舍5；宿舍3；宿舍4；宿舍2；宿舍6；宿舍7；宿舍8

在该序列中，将各宿舍内的本专业学生之间以“、”作为间隔符，可生成如下结构的字符串（以下称为“学生&宿舍字符串”）：

学生1、学生2、学生3、学 生4、学生5；学生6、学 生7、……；学生n

Step4：在该字符串中，以宿舍为单位按其顺序采取首尾结合的方式生成各班学生。当人数达到当前班级上限时，若当前宿舍的学生未分配完，则将剩下的学生分配到下一个班。例如当前专业总人数为25 人，若班级人数上限为10 人，则分成3 个班，人数分别为9 人、8 人、8 人。因此，一班学生包括：宿舍1、宿舍8 中的9 人和宿舍5 中的3 人，二班学生包括：宿舍5 中剩下的2 人和宿舍7、宿舍3 中的6人，三班学生包括：宿舍4、宿舍6、宿舍2 中的8 人。按此方法分别生成各班男生组和女生组的数据，再将各班男、女生组合生成各班所包含的学生。以男生组为例，在确定“学生&宿舍字符串”和当前班级男生人数的前提下，生成本班男生数据的算法代码如下：

生成该班男生数据后，按照“学生&宿舍字符串”的结构将剩余未分配班级的男生数据重新组合，以便生成该专业下一个班的男生数据。重复该操作，直到该专业所有班级都分配完毕。

Step5：完成ds_bj.Tables［0］中所有数据生成后，将其中数据绑定到视图层供用户查看和微调，并将最终确定的班级和该班学生数据存储于数据库中。

通过上述算法，成功实现了教务系统在入住宿舍约束因素下的新生学籍自适应生成。

3 结语

通过在项目中实施该方案，较好地解决了含约束因素的学籍自适应生成问题，之前依靠人工需要约一周时间完成学籍分配工作，现在只需几分钟即可实现，极大地提高了工作效率。随着高校信息化建设推进及招生工作流程变更，各高校教务系统都可能面临同类问题，本文研究成果具有较好的应用推广意义。同时，研究成果还可应用于其它具有类似需求的模块或系统，具有较好的通用性，在实施这类项目时可作为参考，并以此为基础，根据自身实际情况作进一步扩展。