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 類接口實現方案，其完備性和可靠性仍有待提升，尤其是同步接口尚需針對不同數據庫實現相應的觸發監聽功能。