AM在人力资源管理系统升级中的应用研究

周雯雯，杨永志，王杰娟，程 斌

（1.航天工程大学航天XX学院；2.航天工程大学教研保障中心；3.航天工程大学政治工作处，北京 101416）

0 引言

传统的信息管理系统是一类典型的数据库应用，主要基于成熟的实体关系模型（Entity-Relation Model，ERM）进行设计与实现。ERM 由华裔科学家陈品山（Peter Chen）于20 世纪70 年代提出并完善［1-3］，后被广泛应用于数据库相关应用的设计与实现中。ERM 描述了实体、属性以及实体间的关系，但没有提供对属性在时间轴上变化的直接支持［4］，即没有提供对实体、实体属性和关系属性元层描述的直接支持，这使得ERM 只描述了问题域中实体关系在时间轴上的一个快照（Snapshot），不利于存储在信息管理系统生命周期中动态变化的实体及其关系等信息，也不利于上层使用数据库功能模块进行增量式更新与演进［5］。

为加快大数据建设进程，融合相关信息，亟需对人力资源信息管理系统进行升级改造，在此过程中发现了一些问题，如数据采集与校正过程中只能记录最新数据、人员履历简介中缺少时间相关信息、多子系统单点登录功能有待完善等［6-9］。这些问题正是由于ERM 缺乏对属性在时间轴上变化的支持，同时缺乏对属性的元层描述支持导致。为此，本文采用中心锚链模型（Anchor Modeling，AM）［10-11］，强调时间这一元信息在实体、实体属性以及实体间关系中的表达和运用，通过在理论上为实体、属性和关系添加时间元信息，使数据模型能轻松表达和处理随时间增量变化的信息；然后通过将AM 表示为传统的关系数据库形式，迅速改造基于ERM 的人力资源信息管理系统，为新系统提供更为强大的数据持久化功能。

1 现有系统存在的主要问题

1.1 数据采集与校正繁琐

人力资源信息管理系统的运行离不开各类信息的采集和录入。现有信息管理系统的数据采集方式主要包括：①纸质表格；②Excel 等电子表格；③由人工编码数据采集界面程序供用户填写。以上方式费时费力，容易出错。此外，在采集数据用于校正时，现有的ERM 往往只能记录最新校正后的数据，而难以保留原始信息，更不用说采集校正的审核人员等证明性元信息。

1.2 时间信息难体现

人力资源信息管理系统经常需要根据定义对人员的指定属性、关联关系等进行收集汇总，以生成履历简介。传统的ERM 实现存在以下3种难以处理的情况：①ERM 中的一些属性没有明确的时间信息［12-15］，例如曾用名，因而无法表达“于xx 时间改名为yyy”这样的信息；②ERM 中一些关联关系没有时间信息，例如夫妻关系，因而无法表达“于xx 时间离婚……于yy 时间再婚”这样的信息；③无法记录人员的评语信息，包括年度自评、调整任用时的德才表现等。在AM 的支持下，所有这些与时间相关的信息都能够被方便地记录，从而按需导出并可按时间顺序整理生成。

1.3 系统融合有待完善

人力资源信息管理工作中涉及的软件系统往往不止一个，例如信息管理系统需要与办公系统协同工作。因此，信息管理系统必然会与越来越多的信息系统共存融合，从而提供更加综合性的服务。信息系统之间的融合不仅需要做到业务逻辑的融合，还要做到底层数据库的融合。目前人力资源信息管理系统的该项功能还有待完善。

2 AM模型的扩展设计与实现

针对以上问题，本文将AM 应用于实际的信息管理系统升级中，利用其对ERM 进行扩展设计，并从元模型层作出对AM 的扩展，使之能够描述包括时间在内的更为广泛的元信息。

2.1 AM对ERM的扩展

传统的ERM 包含实体、属性和关系3 类元素。图1 给出了一个采用实体关系图（Entity Relationship Diagram，ERD）描述的教师、学生和课程之间的关系模型。

Fig.1 Entity relationship model described by ERD图1 ERD图描述的ERM

AM 在元层对ERM 进行了改造。ERM 的元模型可使用图2所示的简单模型描述。

Fig.2 Simplified ERM meta model图2 简化的ERM元模型

为了在ERM 的属性和关系上扩展时间等元信息，AM从元层入手对ERM 的元模型进行了扩展。图3 以UML（Unified Modeling Language）类图［16-19］的形式给出了AM 的元层描述。事实上，AM 在元层使用Anchor 替代了ERM 的Entity，Tie 替代了Relation，并且对属性Attribute 进行了扩展（继承），得到了4 类属性。同样的，可将Tie 扩展为4类［20］。扩展的属性（Attribute）和关系（Tie）均具备时间这一元信息。

在ERM 中，如果教师更名，则原有的数据库无法保存这一信息，或者必须对数据库结构进行调整才能记录（需要在教师表中增加曾用名、当前姓名时间等字段）。而在AM 中，姓名可以直接作为带时间元信息的Historized Attribute，仅需向该属性对应的子表中添加新的姓名记录（＜ID，姓名，时间＞）即可。总体来讲，AM 通过将ERM 中Entity 的概念拆分为Anchor 和Attribute 来描述，Relation 的概念拆分为Tie 和Knot 来描述，并使得Attribute 和Tie 能够附带时间（Time Type）这一元信息，从而描述实体随时间变化产生的历史信息。换言之，ERM 所描述的信息是AM 描述的信息在某个时间切片上的快照（SnapShot）。

Fig.3 UML meta model of AM图3 AM的UML元模型

2.2 对AM的进一步扩展

2.2.1 时间之外的元信息

AM 仅扩展了时间这一元信息，因而在复杂应用中仍然存在一定限制。如果需要记录教师变更姓名时的证明人等信息，上述的AM 便难以胜任，而这类数据的认证、审核等元信息在人员管理系统中是较为常见的。

为此，在图2 中对Time Type 进行推广，增加Meta Data Type 作为Time Type 的父类，添加Attibute 和Tie 到Meta Data Type 的关联关系中，扩展元信息后的AM 元模型如图4所示。可以看出，新的Meta Data Type 作为各类元信息，可以通过新增的关联关系被引入到Attribute 和Tie（甚至Anchor、Knot）中，如此以来便可以表达除时间之外的其他数据元信息。

2.2.2 ERM访问兼容性

数据库的设计与实现从ERM 模式迁移到AM 模式后，还需要考虑上层应用软件的兼容性。为此，在AM 的基础上扩展出AnchorEntity、AttributeEntity 和TieEntity 的概念，其中AnchorEntity 用于描述某个时间截面上实体的当前状态，即由AM 引出一个实体及其属性在某个时间截面的取值。从实现上来看，类似于构造了该实体对应的ERM表格。

2.2.3 ERM信息同步

当AM 数据库必须与ERM 数据库同时工作时，可能需要同步两个数据库中的数据。为此，引入PortEntity 的概念用于同步两者存储的数据。需要注意的是，PortEntity 在实现上通常会使用触发器和存储过程，因而效率不高，且通常与底层所采用的数据库相关。

2.3 AM的参考实现

AM 最基本的思想将ERM 中的Entity 和Tie 拆分为粒度更小的Anchor、Tie 和Attribute、Knot，赋予它们时间等元信息［21-22］，然后映射到数据库表的设计上。AM 将ERM 中每个表中的每一项都拆分成一个子表，可根据需要利用子表进行组合和扩展。因此，整个数据访问层的核心即为如何组织和使用这些子表。

Fig.4 Extending meta information for AM图4 AM扩展元信息

首先，需要引入一个Schema 描述AM。在ERM 中，描述数据逻辑关系的实体关系图最终将导出为SQL 语句，以描述其在数据库中的数据模型。而在AM 中，为了更为灵活地进行处理，可视化建模工具中的模型图元将被导出生成名为Schema 的XML 文本文件。数据访问层读入Schema后自动检测并补全对应的子表和各类约束、关系，以使软件能够适应更复杂的情况。例如，对两个子模块的数据库需求可以通过合并它们的Schema 文件来融合，通过Schema 的融合可以合并所需子表、检测潜在冲突、检查数据库中缺失的表和字段；其次，提供对AM 中各个子表的访问接口。如此以来既能提供对子表中数据的访问功能，也为后续ERM 的兼容与同步提供了基础支持，因此需要给出子表数据的访问功能，即典型数据库表的增删改查（Create-Retrieve-Update-Delete，CRUD）功能［23］。本文将以一种类似Hibernate 的数据访问形式提供子表以及后续ERM 兼容表的访问功能；然后，提供ERM 兼容与同步访问功能。前者使用户能够像访问以往ERM 数据库那样访问新的AM数据，后者则用于同步基于ERM 和AM 建立的数据库，确保使用这两类数据库的软件能够自动实现数据同步；最后，提供一个简单数据表CRUD 图形界面和一个简单界面自动生成模块，以帮助用户快速建立数据交互界面。

3 基于AM的解决方案

3.1 数据采集与校正改进

AM 中只需利用可视化建模工具定义Schema（主要涉及Anchor、Attribute 和AnchorEntity 等）［24-25］和数据可视化操作模块，便可提供基本的数据采集和校对工作。

以实体Actor 的姓名、性别和等级为例，从实现上只需要：①在AM 可视化建模工具中构建元模型，导出XML 格式的Schema；②为界面设计好描述文件。完成上述操作后，只需要简单几行代码，甚至可以利用脚本或直接作为一个程序读取Schema 和描述文件，然后生成CRUD 界面，即可得到采集和校正工具。

以下基于JavaFX 小程序的主体代码构造AM 的数据仓库，并显示ActorEntity 的数据操作界面，代码表示为：

除了界面生成上的优点外，扩展后的AM 数据库能够存储时间之外的元信息，使得数据采集和校正更加全面。假设在需要采集的姓名属性上添加填表人和审核人两个元信息，那么在采集数据时，填表人可将自己的ID 或姓名填入，审核人也能在审核时填写自己的ID 或姓名。这些信息（连同填表和审核时间）都将被存储在数据库中，以供后续使用。然而，这在ERM 设计中需要对原有数据库结构进行调整，还要增加大量交互代码等。可见，引入扩展后的AM 数据库技术不仅能简化采集和校正工具的设计与实现步骤，还能尽可能地保存原始信息，这样既保证了底层数据的可信性，又简化了上层应用的设计与实现。

3.2 人员履历管理改进

以3 个典型的员工和部门信息为例说明如何利用AM获得同事关系。假设公司有3 个部门Export（出口部，成立于1992-08-20）、Sales（销售部，同样成立于1992-08-20）、Personnel（人事部，成立于1993-09-19），其中Personnel 于1998-09-19 更名为Human Resources（人力资源部）。这些信息可以由表1 进行记录，其中加粗的时间列记录了公司部门名称的变更历史。

Table 1 Sub table of department names表1 各部门名称子表

公司中有3 位员工，分别为Zhang、Yang 和Liu，信息如表2 所示。然后是人员与单位的任职关系（实际使用时，人员是担任部门的某个职务，这里作了简化）。以Zhang 为例，其从1992 年开始在出口部工作，1996 年调到人事部，2002年调到销售部；而Yang和Liu均于1997年分别入职出口部和人力资源部。具体信息如表3所示。

Table 2 Sub table of personnel names表2 人员姓名子表

Table 3 TIE sub table of employment relationship表3 人员任职关系TIE子表

上述信息如果在基于ERM 的人员信息管理系统中表述，则任职表会有如下记录，具体如表4 所示。可以看出，Zhang 和Yang 都曾在出口部工作，但时间上不重叠，因此不是同事关系。Zhang 由于1998 年没有进行工作变动，因此任职表中没有在人力资源部的任职经历，不能得出他和Liu 曾是同事的事实（由于Zhang 已经在2002 年离开人力资源部，因此他当前已经在销售部，与Liu 不在同一部门）。出现这一问题的根源在于ERM 的数据表没有记录信息变化的所有事实，导致信息出现缺失，更不用考虑保存任职经历的证明信息（Tie子表中的record_no 元信息字段）。

Table 4 Personnel employment information under ERM-based information management system表4 基于ERM的信息管理系统中人员任职情况

在AM 数据库子表中，要判断同事关系则相对简单、准确。首先从Tie 子表（如表3 所示）中选出Zhang 的任职子表，如表5 所示；然后对所有其他Tie 子表中的记录逐个判断：若depart_identity 与PERSON_in_DEPART_of_ZHANG中某条记录相同，且起始时间在该记录的timeRange～end-Time 之间，则表明二人曾是同事。当然，上面仅是判断的逻辑过程，真实的实现可采用SQL 语句、ETL 工具或程序代码完成，还可以指定Zhang 在某个时间段的工作同事，并说明如何查证这些同事关系的原始证明材料（利用Tie 子表中的record_no 字段数据）。有了这些历史数据和元信息类数据，AM 数据库能够完整地记录人员信息管理系统所需所有信息，从而支持外部工具或上层应用按需提取和挖掘数据（一个典型的应用可直观地展示个人或机构随时间推移而产生的各种变动，如个人职务变化、同事关系转换等），这正是AM 对ERM 的核心改进之一，即数据在时间维度上的全面性和可回溯性。

Table 5 Sub table record of Zhang's employment表5 Zhang的任职子表记录

3.3 多子系统单点登录改进

单点登录即用户在人员信息管理系统中登录后，打开办公系统时就无需再次登录。为此需要引入新的单点登录服务器，核心在于同步不同子系统中的用户信息，尤其是当各类信息管理子系统不断集成到整个系统中时，单点登录系统也需要动态演进。在AM 数据库中，只需要利用ERM 兼容与同步接口即可实现多子系统单点登录，具体操作为：①单点登录服务器启动时，通过PortSync 获取所有系统中有效的用户，存放到SSOEntity 这个ERM Anchor Entity中；②运行时，一旦用户登入某个系统便立即在SSOEntity中记录其登录状态。同时，PortIn 和PortOut 持续确保各个系统中用户信息的一致性。

以下简单示例如何利用PortSync 从人员信息管理系统（Gbzhmis）、实时通信系统RTC（Openfire）中获取初始用户数据，从而构造一个简单的单点登录服务，代码表示为：

以上AMIdentityService 可以作为WebService 发布，供各个系统进行访问。忽略其中单点登录的逻辑实现部分，这里主要关注数据持久部分，即main 方法中创建的Schema。该Schema 由以下代码直接生成，也可以保存为XML文本，以便后续读取和扩展，代码表示为：

以上是一个比较简单的Schema 定义，创建了Anchor、Attribute 和AnchorENtity、PortSync 等对象，用于从ERM 表中抽取数据，组成新的AM 对象，从而为上层提供数据访问功能。当需要加入Wiki系统到单点登录系统时，仅需要在导出为XML 格式的Schema 中添加相应的配置信息即可。这种增量式的演化方式大大简化了软件的开发和集成工作。

以下采用main 函数对单点登录功能进行测试，代码表示为：

采用main 方法模拟人员信息管理系统的登入、登出和实时通信系统的登录情况，输出结果为：

gbzhmis client get ticket（null）：null

openfire client get ticket（！null）：Zhang@openfire

openfire server check ticket，result is（online）Zhang

gbzhmis client get ticket（！null）：Zhang@gbzhmis

gbzhmis client get ticket（null）：null

可以看出，与ERM 相比，AM 提供了更为简单和灵活的实现方式，使得用户仅需通过配置文件即可加入新的系统，不需要修改已有系统的代码和数据库结构。

4 结语

本文介绍了如何将AM 应用到一个典型的人力资源信息管理系统升级改进中，以几个具有代表性的场景展现了AM 的优势，包括增强底层数据可信性、支持数据在时间维度上的全面性和可回溯性、支持上层应用的增量式开发等，扩展实现了AM 及其必需的工具和支持，为人力资源信息管理系统的改造升级提供了有益参考。然而，在AM 参与实现的访问接口方面，本文仅提供了初步的4 类接口实现方案，其完备性和可靠性仍有待提升，尤其是同步接口尚需针对不同数据库实现相应的触发监听功能。