本发明涉及信息管理
技术领域：
：，具体涉及一种改进型中心锚链模型的描述方法。
背景技术：
：：传统的信息管理系统是一类典型的数据库应用，它们大都基于成熟的实体关系模型(entity-relationmodel,erm)数据库进行设计和实现。实体关系模型描述了实体、属性以及实体间的关系。然而，实体关系模型在描述实体、实体的属性和关系的属性时，没有提供对属性在时间轴上变化的直接支持。进一步来讲，实体关系模型没有提供对实体、实体的属性和关系的属性的元层描述的直接支持。前一个不足使得erm只描述了问题域中实体关系在时间轴上的一个快照，这不利于存储在信息管理系统生命周期中动态变化的实体和关系等的信息。后一个不足要求通过调整数据库结构来反映实体及其属性、关系的变化，不利于上层使用数据库功能的模块进行增量式更新与演进。为此，研究人员提出了所谓的中心锚链模型(anchormodeling,am)。该模型强调时间这一元信息在实体、实体的属性以及实体间关系中的表达和运用。通过在理论上为实体、属性、关系添加时间元信息，使得数据模型能够轻松的表达和处理随时间增量变化的信息；通过将am表示为传统的关系数据库形式，可以迅速地改造原有基于erm模型的应用，为新的应用提供更为强大的数据持久功能。但是，现有的am模型仅支持时间元信息，描述较为单一，无法广泛应用到各类复杂场景中。其次，现有的am建模工具为字符型工具，操作复杂；am模型的访问接口无法兼容原有基于erm的上层应用，无法完整体现am模型的特征，这些缺陷使其在信息管理系统中的应用受到限制。技术实现要素：本发明的目的在于克服现有技术中的缺陷，基于中心锚链模型对实体关系模型的扩展，从元模型层给出对中心锚链模型的扩展，使之能够描述包括时间在内的更为广泛元信息，设计出一种改进型中心锚链模型的描述方法。一种改进型中心锚链模型的描述方法，所述方法至少包括将实体关系模型中的实体概念拆分为锚元素和属性元素，同时将关系概念拆分为tie元素和knot元素，同时让所述属性元素和tie元素赋予时间相关的元信息；将各元素分别映射到数据库表的设计上；数据库的每个表中每一项拆成一个子表，子表根据映射规则进行组合和扩展。本发明通过引入架构来描述中心锚链模型，为了更为灵活地进行处理，通过将可视化建模工具中的模型图元将导出生成称作schema的xml文本文件中。数据访问层读入架构后，自动检测并补全对应的子表和各类约束、关系。这使得软件能够适应更复杂的情况。进一步还提供对中心锚链模型中各个子表的访问接口。实现提供对子表中数据的访问功能，以及为后续的实体关系模型兼容与同步提供基础支持。更一步的方案中，提供实体关系模型兼容与同步访问功能。前者使得用户能够像访问以往实体关系模型数据库那样访问新的中心锚链模型数据，后者则用来同步基于实体关系模型和中心锚链模型建立的数据库，确保使用这两类数据库的软件能够自动实现数据同步。在又一个改进方案中，提供一个简单数据表crud图形界面和一个简单的界面自动生成模块，帮助用户快速建立数据交互界面。本发明以中心锚链模型为基础，从人员信息管理系统的改造需求出发，实现下述技术效果：1)在am模型的基础上，进一步扩展以支持除时间之外的各类元信息，增强了am的描述能力，从而能够更为广泛的应用到各类复杂场景中。2)提供了am模型的参考实现，该实现主要应包括三个方面的功能支持，即对模型信息的访问、对am数据表的访问(类似hibernate的dao访问接口)、兼容于原有erm(实体、属性和关系)的支持。3)提供了am模型的可视化，基于gme元建模工具，建立了am的元模型，开发了模型导出插件，以支持对am模型的数据库schema定义和编辑。4)对新的模型进行实证检验，通过将扩展后的中心锚链模型应用到一个典型的人员信息管理系统中，一方面研究重构该管理系统以获得更好的软件开发和用户体验，另一方面验证新模型和工具的有效性。附图说明图1为改进型中心锚链模型的uml元模型示意图；图2为现有实体关系模型的实体关系描述的实体关系图；图3为改进型中心锚链模型扩展元信息后的元模型示意图；图4为数据库访问层的四个访问接口结构示意图；图5为架构内容类图；图6为改进型中心锚链模型访问接口的类图；图7为定义实体关系模型快照的类图；图8为定义的三类实体关系模型快照示例图；图9为实体关系模型快照的dao访问框架图；图10为h2数据库中创建tirrger的语法描述图；图11为改进型中心锚链模型的gme元模型的部分示意图。具体实施方式下面结合附图和实施例，对本发明的具体实施方式作进一步描述。以下实施例仅用于更加清楚地说明本发明的技术方案，而不能以此来限制本发明的保护范围。本发明的一种改进型中心锚链模型(下文简称am)的描述方法，从元模型层对am模型扩展，使其能够描述包括时间在内的更为广泛元信息。所述方法包括am对实体关系模型(下文简称erm)的改进与扩展，以及进一步对am的扩展。(1)am对erm的改进与扩展为在erm的属性和关系上扩展时间等元信息，am从元层入手，对erm的元模型做了扩展。图1以uml类图的形式给出了中心锚链模型的元层描述。am在元层使用anchor替代了erm的entity，tie替代了relation，并且对属性attribute进行了扩展(继承)，得到了四类属性。同样的，将tie扩展为四类。扩展的属性(attribute)和关系(tie)都能够具备时间这一元信息。以图2中教师的姓名属性为例。在erm中，如果教师更名，则原有的数据库无法保留这一信息；或者必须对数据库结构进行调整才能记录(相应的，需要在教师表中增加“曾用名”及“当前姓名时间”等字段)。而在改进的am中，姓名可以直接作为带时间元信息的historizedattribute，仅需向该属性对应的子表中添加新的姓名记录(<姓名,时间>)即可。关于am对erm的扩展，am通过将erm中entity的概念拆分为anchor和attribute来描述，relation的概念也拆分为tie和knot来描述，并使得attribute和tie能够附带时间(timetype)这一元信息，从而能够描述实体随时间变化产生的历史信息。换言之，erm所描述的信息是am描述的信息在某个时间切片上的快照(snapshot)。(2)本发明进一步的改进方案中，还实现了对am的进一步扩展am模型仅扩展了时间这一元信息，因而在复杂的应用中仍然存在一定的限制。继续考虑曾用名的例子，如果需要记录教师变更姓名时的证明人等信息时，前面的am模型就难以胜任。为此，在am的uml元模型图1中，对timetype进行推广。增加metadatatype作为timetype的父类，添加attibute和tie到metadatatype的关联关系。扩展元信息后的am元模型如图3所示。在图3中，新的metadatatype作为各类元信息，通过新增的关联关系，可以被引入到attribute和tie(甚至anchor、knot)中。这样，就可以表达时间之外的如证明人等数据的元信息了。上述改进由erm模式迁移到am模式，在实现过程中还需要考虑上层应用软件的兼容性和两者信息的同步。为此，在am的基础上，扩展出anchorentity、attributeentity和tieentity的概念。anchorentity用于描述某个时间截面(snapshot)上，实体的当前状态。即由am引出一个实体和它的属性在某个时间断面的取值。当am数据库必须与erm数据库同时工作时，可能需要同步两个数据库中的数据。为此，引入portentity的概念，用以同步两者存储的数据。注意，portentity在实现上多半会使用触发器和存储过程，因而效率不高，且大都与底层所采用的数据库相关。为了在实际的软件开发中应用扩展后的am模型，下面从数据访问层的设计与实现介绍其参考实现。am模型最基本的思想就是将erm中的entity和tie拆分为粒度更小的anchor、tie和attribute、knot，赋予它们时间等元信息。映射到数据库表的设计上，am将erm中每个表中的每一项都拆成一个子表，利用子表可根据需要来进行组合和扩展。因此，整个数据访问层的核心就是如何组织和使用这些子表。首先，需要引入一个schema来描述am模型。在erm中，描述数据逻辑关系的实体关系图最终将导出为sql语句，以描述它在数据库中的数据模型。而在am模型中，为了更为灵活地进行处理，可视化建模工具中的模型图元将被导出生成称作schema的xml文本文件中。数据访问层读入schema后，自动检测并补全对应的子表和各类约束、关系。这使得软件能够适应更复杂的情况。以两个子模块的自动合并为例，对这两个子模块的数据库需求，可以通过合并它们的schema文件来融合。通过schema的合并，可以合并所需的子表，检测潜在的冲突，检查数据库中缺失的表和字段。其次，提供对am中各个子表的访问接口。为了提供对子表中数据的访问功能，以及为后续的erm兼容与同步提供基础支持，需要给出子表数据访问功能。即典型的数据库表的crud功能。本发明可以通过一种类似hibernate的数据访问形式来提供子表以及后面erm兼容表的访问。然后，提供erm兼容与同步访问功能。前者使得用户能够像访问以往erm数据库那样访问新的am数据，后者则用来同步基于erm和am模型建立的数据库，确保使用这两类数据库的软件能够自动实现数据同步。最后是提供一个简单数据表crud图形界面和一个简单的界面自动生成模块，帮助用户快速建立数据交互界面。下面首先介绍实现数据访问的访问接口：在图4中，给出了访问am模型数据库的四类接口，其中olap接口通常由olap工具直接从底层数据库am子表中提取数据，因此不需要做具体实现。下面介绍其他三类接口的设计与实现。第一类接口：schema访问接口schema描述了am模式数据库的结构，包含了anchor、attribute、tie、knot和其他扩展信息；并通过将anchor和attribute等都使用数据库中较小(字段数目较少)的子表来存储。因此，对于schema的设计，可用图5的类图来概括表示。每个schema对象会聚合多个anchor、tie和knot，每个anchor包含多个attribute，每个tie包含一些分别由anchor和knot充当的anchorrole和knotrole以描述anchor之间的关系。这些都是典型am模型的要求。在扩展后的am模型中，如图5所示，将metatable作为anchor、attribute、tie和knot等将会被映射为子表的类的父类。由于metatable可以包含不同的metafield，因此可用这些metafield来描述包括数据、时间和其他所需的元信息。当然，schema中还可以包含描述erm兼容与同步所需的信息等；下文中讨论。在具体的实施例中，schema的访问接口包括两类：1)对schema中各类信息的增删查改操作，2)对schema的存储、加载和合并等操作。一般地，schema有下列几种存在形式：1)程序中的对象，2)xml文本文件，3)可视化建模工具中的图元集合。当然，还可以根据需要构造其他形式，但它们所描述的语义是相同的，只是为了不同的目的和功能，以不同的形式出现；本申请不对其具体限定，而将根据需要采用其中最为合适的形式来表达。对于schema中各类信息的增删查改，是在schema类中提供相应的add、remove、getxxx等方法。以对anchor的增删查改为例，提供下述函数：下面列出的是这些函数的详细说明。相应地，为schema直接包含的tie、knot、anchorentity、attributeentity、tieentity、portout、portin、portsync等提供了类似的增删查改函数。而对于像attribute属于anchor这样的聚合关系，也在anchor中提供了相应的增删查改函数，如下：综上可知，schema所包含的信息可以想象为一颗以schema对象为根的树或有向图。通过对树或有向图中各个节点下子节点的增删查改操作，即可完成对schema内容的访问和修改。基于树或有向图这一视角，可以定义两个schema的合并和冲突检测算法。算法的思路是：1)从根节点schema开始，分别逐个检测它所包含的同名的anchor、tie、knot等。2)对于同名的anchor，检测它们的id字段定义(如类型和长度)，不兼容(如类型不一致，nullable不同)则判定为冲突。然后检测它们所包含的同名的attribute，不同名的attribute则直接合并到一个列表中。3)同样的方式检测tie和knot等元素。最后，是schema的存储和读取功能。这两个功能实现了运行时对象与xml文本文件之间的双向转换。借助schema的存储功能，可视化建模工具实现了图元到xml文件的转换功能。最终，实现了可视图元、xml文本和内存对象三种形式的转换，如图6所示。图中可视图元到xml文本的转换，实现上是先将可视图元转换为内存对象，再存储为xml文本的。由于可视化建模工具在显示可视图元时，还需要确定图元的位置等信息，而这在schema中不是必须的。这意味着xml文本和内存对象形式的schema不能完全涵盖可视图元形式schema的信息，也就不能直接完成转换。实际上，本文采用的是gme原生的可视图元格式mga或xme文件，后者也是一个xml文件。实现上，可采用了开源软件库xstream来实现java内存对象和xml文件的双向自动转换。第二类接口：am子表访问接口am子表访问接口为上层提供存储anchor和attribute等信息的子表的访问，本申请提供了一个类似hibernate的数据库对象访问(dao)接口，所不同的是访问时不需要提供具体的实体对象。当然，为了访问这些子表，还需要将schema描述的信息转换为实际的数据库表格等。为了schema中的信息映射为数据库中的表格(即前述的子表)，需要定义anchor、attribute等各个am模型元素的映射规则；该部分的定义在现有文献中有相关详细说明。而本申请中的方法需要增加的是对元信息字段的处理。元信息字段的处理方式和时间元信息相同，即在对应的子表中增加一个字段来表示该元信息。以历史属性姓名为例，在原来的am模型中，映射为下述子表1：ac_nam_actor_name假设添加审核人(auditor)这个元信息用来证明该姓名的有效性。那么，新的am模型在nam属性上增加有auditor元信息，最终映射的子表2如下：ac_nam_actor_name上述字段ac_nam_auditor的类型、长度和可否为空等信息都可以在元信息中加以描述，从而转换为相应的sql定义和约束。为进一步方便对各个子表中的数据访问，本申请am还构造了如图6所示的类及其相互关系。见图6，上半部分是管理性质的类，提供数据仓库的访问功能。下半部分是数据访问性质的类，提供表、记录和字段的数据访问功能。其方法是：利用管理类，找到需要访问的子表对象；使用子表访问类，操作表中数据。在一个具体的实施例上，schema中信息映射到数据库中子表的操作通常包含两个步骤：1)利用jdbc提供的databasemetadata类检测数据库中所需的子表等数据库元素是否存在；2)利用jdbc提供的sql执行接口构造sql语句来创建缺失的子表等数据库元素。通过调用databasemetadata的各种方法，程序可以动态的了解一个数据库。例如，通过gettables()、getcolumns()、getprimarykeys()等就可以获取数据库中所有表及其信息，主要步骤如下：1、通过gettables()获得数据库中表的信息。2、对于每个表使用，getcolumns(),getprimarykeys()获得相应的列名，类型，限制条件，关键字等。3、通过步骤1，2获得信息可以生成所有表的描述信息。以下述anchor对应子表的检测与生成过程为例，其实施方法首先调用checkinitmetatable方法来检测和初始化anchor中公共部分的内容。然后添加id字段为主键，即检测和设定自身特有的内容。最后调用checkinitattribute方法来检测和初始化它所包含的attribute。事实上，几乎所有其它tie、knot等的检测和初始化都遵循这一流程。图8所示，作为公共类metatable的检测和初始化方法checkinitmetatable。它首先获取databasemetadata对象，从而访问数据库中的表和字段的信息。如果数据库中没有对应的子表，则构造sql语句并执行；否则逐个检查表中字段是否兼容(数据类型、长度和空值许可等内容)，不兼容则报错。对应anchoractor及其属性name的子表生成后，由其代码自动生成sql语句，该sql语句将按照schema的定义生成类似子表2的子表。为了访问这些子表中的数据，首先要获得这些子表，其次是利用类似hibernate的dao框架进行访问。本发明的am访问接口的类图架构中，见图6，以amdataware作为最高层的管理器，包含了软件中所有的databank。amdataware是一个单例类，因此可以随时访问它。它内部记录了一个databank的名—值表，因此可以根据名称注册和获得databank对象。每个databank都包含一个am数据库所必须的两个对象：schema对象和amdatabase对象。amdatabase提供了对am子表的访问功能。其中，以anchor对应子表为例，getamanchortable将返回指定名称的anchor对应的子表对象amtable。amtable是一个dao对象，支持对子表中的记录进行crud操作。amtable中的crud操作函数给出了amtable用于支持子表crud操作的函数，这些函数的实现在众多dao框架中都有，这里不再深入介绍其数据结构和算法。第三类接口：erm兼容与同步接口schema接口只能访问am数据库的描述信息，而am子表访问接口只提供了简单的子表数据crud操作。另一方面，上层用户还是希望按照以往的erm模型的样式来访问数据库中数据。为此，需提供了一个面向erm数据兼容性访问的dao框架。进一步的，为了同步am和erm两种数据库中的数据，提供了所谓的数据同步接口。对于erm数据兼容性访问接口，通过提供类似hibernate的dao访问框架，自动地将用户对数据的操作映射到子表的操作上，实现数据的crud。前面指出，erm描述的数据实际上是am在某个时间切片上的快照(snapshot)。而在什么时间、圈定什么范围形成快照，则需要进行定义和说明。这就导出了anchorentity、attributeentity和tieentity的概念，以及它们对应的ermanchortable、armattributetable和ermtietable等dao类。图8示出了定义erm快照所需的类，以及它们与schema中已有元素之间的关系。其中，anchorentity实际上就是erm中entity的概念，不同的是它是由指定的anchor、anchor中的attribute以及切片时间等信息来共同定义的。attributeentity类似anchorentity，也是由anchor和它的一个attribute来定义，不同的是它定义了该attribute的起止时间，从而列出这个时间段内属性的多条记录(包含属性的取值、时间、元信息等)。tieentity则类似erm中的relation概念。图9示出了基于actor的schema，定义的三类erm快照的示例。而要访问所定义的这些快照中数据，还需要仿照图6定义相应的dao框架；如图10所示，定义了对应的table、record和field对象；同时还包括一个缺省值提供器，用来在插入nullable为false的字段时，自动生成相应的值。用户应该根据快照的内容来定义和生成idefaultvalueprovider对象，为没有设定值的非空字段提供缺省数据。同样的，这些table中都提供了crud操作所需的函数。对于erm快照的底层实现至少有两种方式：1)建立物理数据表，通过子表与数据表的同步来保持一致性；2)使用数据库中视图(view)的概念。前者比较适合频繁执行查询操作和几乎不修改数据的场合，后者适合数据量少但经常执行修改操作的场合。后续实施方法将介绍后一种实现。当然，利用下面介绍的同步接口，也能实现第一种方式。同步接口需要提供的功能包括：1)从不同的erm数据库表中获取数据并存储到am数据库子表中，即静态同步；2)运行时保证erm数据表和am子表的数据同步，即动态同步。两种同步都需要对待同步的信息进行定义。静态同步需要定义如何从erm数据库表中获取数据，动态同步需要定义如何发送和接收数据变化。给出了实现两种同步需要的主要类及其关系。从信息定义上，schema中引入了portsync、portin和portoutamattribute(简称portout)。portsync用于定义静态同步需要的信息，包括从哪些erm表(portsuncjointabe)的哪些字段(portsyncjoinfield)获取数据后存放到哪里(anchorentity对应的ermanchorentity)。portout用来描述如何通知其它数据库am数据子表(主要是属性)发生的变化。同时给出的trigger结构描述了为数据子表添加触发器来检测属性变化的机制。触发器在属性子表发生变化时被执行，然后根据portout的信息产生相应的事件。这些事件将被一个基于xml和zeromq的消息机制传导给其它数据库，相应的，am数据库也能收到其他数据库传来的数据变化事件。portin用来描述如何处理接收到的数据变化事件。从事件的键值对中取出数据，然后应用到对应的字段中。基于xml和zeromq的消息机制简单设计如下：1)传输的消息以xml格式存在，利用xstream可以自动完成消息对象和xml消息文本的转换；2)使用zeromq作为消息传输层。zeromq是一种基于消息队列的多线程网络库，它对套接字类型、连接处理、帧、甚至路由的底层细节进行抽象，提供跨越多种传输协议的套接字。zeromq是网络通信中新的一层，介于应用层和传输层之间(按照tcp/ip划分)，是一个可伸缩层，可并行运行，分散在分布式系统间。在一个具体的实施例中，图9中定义了actorentity，它与下面代码生成的对象等价：为了从关系数据库的子表中，选出actorentity所定义的数据，需要使用的sql语句中，根据actorentity的所含属性参数定义ermentitytable中的数据字段。根据actorentity的字段映射关系参数和所含属性参数中的属性过滤条件，使用join和leftjoin定义了子表的连接方式。因此，将sql语句中选出的内容固化为一个视图(view)或者物化视图(materialview)，即可在其基础上进行各种查询排序操作。这正是ermanchortable中crud的retrieve操作的基础。而对于update和delete操作，则需要根据entitytable的字段和am中子表(及其字段)的映射关系，逐个子表进行update和delete操作。create操作类似，不同的是需要利用idefaultvalueprovider来填充一些字段值。对于ermattributeentity和ermtieentity，其实现方式相同同步接口的实现需要从portsync、portin和portout三个方面进行。对于portsync，需要在数据库建立时从erm表中获取所定义的表和字段的数据，连接后存储到指定的ermanchorentity中。实现时，首先创建一个临时数据库，将不同erm数据库中的表(和所需字段)的数据存储到临时数据库的临时表中，然后再临时数据库中完成多个临时表的连接，最后将连接得到的数据复制到am数据库的各个子表中。对于portout，由于各种数据库实现触发器的方式不同，以h2数据库的情况来说明，创建trigger的语法描述。对于portin，则相对简单。它在收到数据库表变动事件后，根据自身的定义去更新am中子表数据即可。需要注意的是，一般am子表都是通过插入新的数据记录来完成信息更新的。本发明方法中数据操作实现可视化操作支持，可视化操作界面包括半自动的界面显示和自动化界面生成；前者通过给出显示方式的描述信息，由程序读取并生成数据显示和操作界面；后者则直接根据数据信息生成显示和操作界面。对于半自动的界面显示，通过提供界面描述自动生成图形界面，其中界面的描述信息给出显示各个字段所用的可视化控件，实现上就是给出这些控件并根据描述信息生成和组装控件，同时将对数据记录和字段的操作转换为对ermanchorentity的操作即可。对于全自动的界面生成，则依赖于一个针对简单用户交互需求提出的所谓type模型：首先预定义并使用数据类型来描述交互内容，然后依次利用描述设备中ui系统的profile变换和描述用户偏好的preference变换对交互内容进行变换，结果交由ui系统进行“渲染”和执行，最后利用数据更新的请求/通告机制完成交互。为了利用type模型，首先需要根据schema来提取数据，然后交由type模型自动生成界面以进行显示和修改。另一方面，本发明扩展后的am模型在基于gme(genericmodelingenvironment，通用建模环境)设计并实现了一个可视化的anchormodeling建模工具。在遵循gme的方式下，根据图3及其他扩展建立了如图11所示的gme元模型。建立了元模型，gme就可以自动生成相应的建模环境；gme提供了一个称作bon(builderobjectnetwork)的模型访问接口，通过bon接口可以访问建模环境中用户生成和设定的所有图形元素。结合前面利用xstream实现对schema的存取功能，只需要在插件中利用bon接口遍历所有图形元素，逐个生成对应的schema和下辖的anchor等对象，即可将图形元素转换为xml文本。在本发明研究改造的人员信息系统的是一个典型的mis系统，它主要管理人员、单位及其周边的信息。下面将给出四个典型实施例场景，以对比现有erm的实现形式，具体说明本发明改进型erm系统的改造方案。(一)数据采集与校正技术问题：传统的数据采集有下列形式：1)纸质表格；2)excel等电子表格。在信息管理系统出现后，可以基于该系统进行采集。但是，这些方式的缺点也是显而易见的。以信息管理系统为例，一方面要求用户安装该系统(不可避免的带来系统和数据的泄露)，另一方面用户难以从总多模块和界面中找到录入和校对功能。解决技术问题的现有技术：erm需要设计数据采集表，编程实现数据采集界面。为了保存数据的变化和认证信息，还需要设计或修改原有的数据库结构。改进型erm的解决方案：只需要利用可视化建模工具定义schema(主要是涉及的anchor、attribute和anchorentity等)，然后利用数据可视化操作模块，即可提供基本的数据采集和校对工作。以前面actor的姓名、性别和等级为例，从实现上，只需要：1)在可视化建模工具中构建好元模型，导出为xml格式的schema。2)为界面设计好描述文件。完成上述操作后，只需简单几行代码(甚至可以利用脚本或者直接作为一个程序，读取schema和描述文件，生成crud界面)即可得到采集和校正工具。除了界面生成上的优点外，扩展后的am数据库能够存储时间之外的元信息，也是的数据的采集和校正更加全面。例如在需要采集的姓名属性上添加“填表人”和“审核人”两个元信息。则在采集时，填表人可以将自己的id或姓名填入，审核人也能在审核时填写自己的id或姓名。这些信息(连同填表和审核时间)都将存储在数据库中，以供后续使用。这在erm设计中，需要对原有的数据库结构进行调整，还要增加大量的交互代码等。可见，引入扩展后的am数据库技术，不仅能简化采集和校正工具的设计和实现，还能尽可能的保存原始信息。即保证了底层数据的可信性，又能简化上层应用的设计和实现。(二)人员履历简介技术问题：以人员(person)、单位(department)构成的任职简历为例，希望获得以下信息：1)人员的任职经历；2)指定人员在某个时间段的同事，或者说他的同事圈变化情况。解决技术问题的现有技术：在原有的信息系统中，由于采用的是erm模型，只能记录当前的任职情况。为了记录任职经历，设计了任职简历表，用以记录person在什么时间任什么职务。当人员的任职岗位发生变化时，修改person和department的关联关系，同时在任职简历表中添加新的记录。由于关联关系表中没有记录department的主键，因此对于获得某个时间段的同事这种需求需要采用人工主导的方式来完成，不能实现自动化。改进型erm的解决方案：下面以三个典型的员工和部门来说明如何利用am获得同事关系。假设公司有三个部门export(出口部，成立于1992-08-20)、sales(销售部，同样成立于1992-08-20)、personnel(人事部，成立于1993年)，其中personnel于1998年更名为humanresources(人力资源部)。这些信息可以由下面的depart_name子表来记录。其中，加粗的时间列记录了公司名称的变更历史。depart_name公司中有三位员工，tom、jack和mary，如下面的person_name子表所示。person_name最后是人员与单位的任职关系(实际使用时，人员是担任部门的某个职务，这里作了简化)。以tom为例，他从92年在出口部，96年调到人事部，人事部于98年更名人力资源部，02年调到销售部。而jack和mary都是97年分别入职出口部和人力资源部的。如下面的tie子表所示。person_in_depart上述的信息如果在人员信息系统中表述，则任职表会有如下记录：任职表从上面的表来看，tom和jack都在出口部工作过，但时间上不重叠，因此不是同事关系。tom由于98年没有进行工作变动，因此任职表中他没有在人力在资源部的任职经历，这就不能得出他和mary曾是同事的事实(由于tom已经在02年离开人力资源部，因此他当前已经在销售部，和mary不在同一部门)。出现这一问题的根源在于erm模型的数据表没有记录信息变化的所有事实，导致出现信息的缺失。当然，更不要说对任职经历的证明(tie子表中的record_no元信息字段)信息的保存了。在am数据库子表中，要判断同事关系，则相对简单、精确。首先从tie子表中选出tom如下的任职子表。person_in_depart_of_tom然后对所有其他tie子表中的记录，逐个判断：若depart_identity与person_in_depart_of_tom中某条记录相同，且起始时间在该记录的timerange～endtime之间，则表明曾是同事。当然，上面仅仅是判断的逻辑过程，真实的实现可用sql语句、etl工具或程序代码来完成。进一步的，还可以指定tom在某个时间段的工作同事，并说明如何查证这些同事关系的原始证明材料(利用tie子表中的record_no字段数据)。有了这些历史数据和元信息类的数据，am数据库能够完整的记录人员管理系统所需要的所有信息，从而支持外部工具或上层应用按需提取和挖掘数据(一个典型的应用是直观地展示个人或机构随时间推移而产生的各种变动，如个人的职务变化、同事同学转换等。)。这正是am模型对erm模型的核心改进之一——数据在时间维度上的全面性和可回溯性。(三)档案电子化技术问题：以纸质形式存在的档案，技术上存在较大的风险：1)人为涂改和替换档案内容，2)人为加塞或隐匿档案内容。解决技术问题的现有技术：在erm实现的档案管理系统中，通常只实现了第一个目的，即确保了电子信息和纸质信息的同步性，很难达到第二个目的。且在当前的人员管理系统中，档案是由纸质扫描为电子形式保存的，这就增加了额外的工作。改进型erm的解决方案：利用扩展后的am模型，比较容易完成第二个目的。以保存档案影像的子表为例，可以设计如下。档案_影像以档案f01_51(假定采用类似f01号档案第51页的编号方式)为例，它在2015年被作了订正，责任人的编号为#p01，新的文件扫描后存档的md5码之类的签名值为“982f…ee21”。有了上面的影像子表，就可以随时查阅每一页档案的历史信息，同时还能准确知道责任人等信息。如果上层应用禁止存入责任人为空或隐式地将责任人填写为当前登录的用户，则可以从技术层面记录档案的可信性。例如，某用户存在可以的档案操作，那么就可以从影像子表中查出他所操作的所有影像记录，这为对比分析提供了可靠的原始证据。推而广之，am模型的数据库可以为每一条信息添加责任人和相关证明信息，从而增强数据的可信性和可追溯性。进一步的，再加上am模型能够全面描述人员信息系统涉及的所有历史数据，可以改变以往信息从纸质档案流向信息系统的方式，变为由信息系统流出到纸质系统的方式。变纸质档案为准绳到以信息系统为准绳，将纸质档案作为信息的备份。(四)多子系统单点登录技术问题：假设主机中安装了人员管理系统、实时通信系统rtc和电子白板wiki。希望能够在任一系统中登录后，就可以直接打开其他的系统，即所谓的单点登录问题。这里不讨论单点登录协议及其安全等问题，只需要利用am模型来提供底层的数据支持。现有技术的解决方案：erm可以实现单点登录功能，但需要对原有数据库系统作出修改(如果该系统设计时并未考虑单点登录支持)。同时，新的系统加入时，往往需要进行扩展修改。改进型erm的解决方案：在am数据库中，只需要利用erm兼容与同步接口即可实现：1)单点登录服务器启动时，通过portsync获取所有系统中有效的用户，存放到ssoentity这个ermanchorentity中。2)运行时，一旦用户登入某个系统即在ssoentity中记录其登录状态。3)运行时，portin和portout持续地确保各个系统中用户信息的一致性。以上所述仅是本发明的优选实施方式，应当指出，对于本
技术领域：
：的普通技术人员来说，在不脱离本发明技术原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。当前第1页12当前第1页12