分布式企业建模中的同构模型合并方法

摘要

分布式企业建模中的同构模型合并方法属于分布式环境下的企业建模领域，其特征在于，在服务器端，设有依次正向连接的模型接收模块、模型缓冲数据库、模型合并模块和模型主数据库，在客户端，设有依次正向连接的集成化企业建模模块，模型分数据库和模型上传模块，该模型上传模块把集成化企业建模形成的组织模型、资源模型和过程模型通过局域网或互联网传到模型接收模块，在模型合并模块中，组织模型根据模型主码合并，资源模型以组织模型的主码作外码，再根据资源模型主码进行合并，过程模型除主码外，还根据作为其外码的组织模型和资源模型的主码进行合并，形成完整企业模型后输入到模型主数据库。本发明具有安全度高、成本低、适用面广的优点。

说明书

技术领域

本发明属于企业建模技术领域，特别涉及一种分布式环境下的同构模型合并的方法和系统。

背景技术

企业模型是人们为了了解企业而经过抽象得到的对于企业某个或者某些方面进行的描述，而企业建模是先进制造战略和企业经营过程重组对现代企业提出的新的要求。

目前国内外提出了许多企业建模的方法和框架，也得到了很多的相关应用。其中，由清华大学CIMS工程研究中心研究开发的集成化企业建模框架(范玉顺，王刚，高展.企业建模理论与方法学导论.北京：清华大学出版社，施普林格出版社，2001.PP.1-67)因其完整地描述企业的各方面，并有相应的软件做支持，在国内的得到了广泛的应用。集成化企业模型主要包括组织、资源和过程三个模型。其中组织模型主要描述了企业的组织结构信息，包括企业的部门、员工、角色和岗位等；资源模型主要描述了企业业务活动中使用到各种资源，包括计算机等设备或者其他生产资料和耗材等，以及资源所属部门；过程模型是集成化企业模型中的核心部分，它描述了企业中业务流程的信息，包括业务流程包含的活动，执行顺序，涉及到的部门，使用到的资源等等。因为在资源模型中需要包括资源所属部门的属性，因此在资源模型中会引用组织模型的信息；过程模型中包括过程涉及到部门和使用到的资源，因此在过程模型中需要引用到组织模型和资源模型的信息。

集成化企业模型在实际软件实现时存储在关系数据库中的数据表中，对于不同的模型类别，数据表有不同的属性。例如，对于组织模型，典型的数据表如表1所示。

表1组织模型数据表示例

    部门编号  部门名称    电话号码    地址    1  计划部    xxxxxxxx    C区502室    2  生产部    xxxxxxxx    C区505室    3  设计部    xxxxxxxx    D区302室

其中，部门编号是该组织模型数据表的主码(PrimaryKey)，用于唯一标识该表中的每一条数据。该主码可以记为Org_Key，而组织模型可以形式化地记为ORG(Org_Key)。

对于资源模型，它的典型数据表如表2所示。

表2资源模型数据表示例

    资源编号    资源名称    数量    所属部门    1    计算机    4    1    2    打印机    3    1    3    车床    5    2

其中，资源编号是该资源模型数据表的主码，用于唯一标识该表中的每一条数据。该主码可以记为Res_Key。由于在资源模型中需要指定每一个资源属于企业中的哪个部门，因此在资源模型中需要引用到组织模型中的信息，即数据表中“所属部门”属性。对于一条资源记录，需要在此字段中填入其所属部门在组织模型中的部门编号，即主码Org_Key，这样就能唯一指定一个所属部门。表2中的数据表示，资源“计算机”和“打印机”属于部门1，即“计划部”，而“车床”则属于“生产部”。在一个数据表中引用了另一个数据表的主码以表示关联关系，这样的字段叫做外码(ForeignKey)，资源模型数据表中的“所属部门”引用了组织模型数据表的主码Org_Key，因此它就是资源模型数据表的外码，可以记为F_Org_Key。而资源模型可以形式化地记为RES(Res_Key，F_Org_Key)。

同理，对于过程模型的每个活动，过程模型数据表中有对应的一条记录，用“活动编号”作为主码来唯一标识，可以记为Proc_Key。而由于在过程模型中需要指出每个活动属于哪个部门，使用到哪个资源，因此需要引用到组织模型和资源模型的主码作为外码，分别记为F_Org_Key，F_Res_Key。因此，过程模型可以形式化地记为PROC(Proc_Key，F_Org_Key，F_Res_Key)。

综上所述，组织模型，资源模型和过程模型三者的引用关系如图1所示。

在数据库理论中，对于数据表的主码和外码是有严格要求的。首先，主码必须是唯一的。即在同一张数据表中，不能有两条记录有相同的主码，这样主码才能起到唯一标识的作用；其次，数据表中某条记录的外码必须与其引用的那张数据表对应记录的主码保持一致，这样才能表示正确的引用或者隶属关系。

有了成熟的建模理论和数据库系统的支持，企业建模软件能够建立很完善的企业模型，来指导企业的经营和生产。但是由于企业规模的不断扩大和现代企业的实际需要，为了实现并行建模，提高建模的效率，单纯的单机本地建模已经无法满足需要，而在分布式环境下的如何建立完整和一致的企业模型是一个需要重点研究的问题。

针对分布式环境下的集成化企业建模，出于模型完整性和一致性的考虑，最理想的方法应该是远程的协同建模。即只有一个完整的中心数据库，所有建模人员都通过网络直接操作此中心数据库。如浙江大学战洪飞等提出的一种基于Internet/Intranet的企业协同建模系统(战洪飞、祁连、金勇华、顾新建、吴昭同，适应网络化生产的企业建模方法及系统，机电工程，Vol.17，No.1，2000，pp.21-24)。但是此类方法在实际应用中却存在一些的问题。

·集成化企业建模是一个极其复杂的过程，其中涉及到收集、组织、存储和处理企业的组织、资源、过程、功能和产品等各方面信息。正是由于集成化企业建模的信息量非常大，建模过程涉及到的操作也非常复杂，如果要实现实时的远程协同建模，对网络的带宽和稳定性要求非常高，因此成本也会很高。

·集成化企业建模是一个多用户同时操作的并行过程，涉及到的用户权限管理和版本管理将会非常繁杂。如果多用户同时对一个中心数据库进行操作，很容易因为各用户间的不协调而出现误操作。

·远程协同建模要求整个建模过程都有互联网的环境，这在有些企业中是无法满足的。比如一些制造型企业的生产车间中就没有连入网络的计算机，如果用远程协同建模的方法对这样的车间进行建模则会比较困难。

发明内容

针对现有技术中存在的问题，本发明的目的是以一种更加灵活简便的方式解决分布式环境下的集成化企业建模问题，保证企业模型的整体性和一致性。

本发明的特征在于，在分布式企业环境下，所述方法是依次按以下步骤实现的：

步骤(1)，初始化

一个服务器端设有：模型主数据库，模型合并模块，模型缓冲数据库，以及模型接收模块，其中：

模型主数据库，存有企业各分部分模型合并完成以后的完整的模型；

模型合并模块，输入端与所述模型缓冲数据库的输出端相连，以输入要存储在所述模型缓冲数据库的企业各分部分模型；模型合并模块的输出端与所述模型主数据库的输入端相连，以输出合并后的企业完整模型；

模型缓冲数据库，输入端与所述模型接收模块的输出端相连，以存储客户端上传的企业模型；另外，还设有缓冲信息数据表，记录了上传到所述模型缓冲数据库的各分部分模型的基本信息；

模型接收模块，通过互联网或局域网接收客户端输出上传的企业模型；

多个客户端，在每个客户端设有：集成化企业建模模块，模型分数据库，以及模型上传模块，其中：

集成化企业建模模块，用于构建集成化企业模型，所述建模模块的输入是客户端用户根据企业情况进行的一系列建模操作，输出是包括过程模型、组织模型和资源模型三个部分的集成化企业模型，其中：

组织模型ORG(Org_Key)，Org_Key是组织模型的主码；

资源模型RES(Res_Key，F_Org_Key)，Res_Key是资源模型的主码，F_Org_Key表示引用所述组织模型的主码作为外码；

过程模型PROC(Proc_Key，F_Org_Key，F_Res_Key)，Proc_Key是过程模型的主码，F_Res_Key表示引用资源模型的主码作为外码；

模型分数据库，输入端与所述集成化企业建模模块的输出端相连，用于存储所属客户端用户编制的各分部分企业模型；

模型上传模块，输入端与所述模型分数据库的输出端相连，用以接收各部分企业模型，再通过互联网/局域网发往服务器端的模型接收模块；

步骤(2)，依次按以下步骤执行同构模型的合并：

步骤(2.1)，服务器端的用户通过所属模型合并模块浏览建模客户端上传的所有模型信息，并选择需要合并到模型主数据库的企业模型；

步骤(2.2)，服务器端用户通过所属模型合并模块依次按以下步骤对各分部分企业模型进行合并：

步骤(2.2.1)，服务器端用户通过界面选择所述过程模型中需要合并到模型主数据库的过程或子过程；

步骤(2.2.2)，服务器端用户通过界面选择所述资源模型中需要合并到模型主数据库的资源类型和资源实体；

步骤(2.2.3)，服务器端用户通过界面选择所述组织模型中需要合并到模型主数据库的人员、岗位和角色；

步骤(2.3)，模型合并模块根据服务器端用户的选择确定并筛选出所述模型缓冲数据库中各模型数据表中需要合并的记录；

步骤(2.4)，合并组织模型ORG(Org_Key)：

步骤(2.4.1)，把模型缓冲数据库中需要合并的组织模型数据表中的数据记录复制到模型主数据库中的对应模型数据表中；

步骤(2.4.2)，重排模型主数据库组织模型数据表中新增记录的主码Org_Key，重排后的主码为Org_Key_New，重排方法为：第n条新记录的主码为模型主数据库中原有组织模型数据表中的主码最大值加n；

步骤(2.4.3)，建立Org_Key与Org_Key_New一一对应的映射表；

步骤(2.5)，合并资源模型RES(Res_Key，F_Org_Key)

步骤(2.5.1)，把模型缓冲数据库中需要合并的资源模型数据表内的数据记录复制到模型主数据库中的相应模型数据表中；

步骤(2.5.2)，重排模型主数据库资源模型数据表中新增记录的主码Res_Key，重排后主码为Res_Key_New，其重排方法为：第n条新增记录的主码为模型主数据库中原有资源模型数据表中主码最大值加n；

步骤(2.5.3)，建立Res_Key和Res_Key_New的一一对应的映射表；

步骤(2.5.4)，处理资源模型中的外码F_Org_Key，其处理方法为：在步骤(2.4.3)中建立的映射表中查找与F_Org_Key对应的重排后的值F_Org_Key_New，并以此替代资源模型的外码F_Org_Key；

步骤(2.6)，合并过程模型PROC(Proc_Key，F_Org_Key，F_Res_Key)：

步骤(2.6.1)，把模型缓冲数据库中需要合并的过程模型数据表中的数据记录复制到模型主数据库中的相应模型数据表中；

步骤(2.6.2)，重排模型主数据库过程模型数据表中新增记录的主码Proc_Key，重排后的主码为Proc_Key_New，其重排方法为：第n条新增记录的主码为模型主数据库中原有过程模型数据表中主码最大值加n；

步骤(2.6.3)，建立Proc_Key和Proc_Key_New一一对应的映射表；

步骤(2.6.4)，处理过程模型中的外码F_Org_Key，其处理方法为：在步骤(2.4.3)中建立的映射表中查找与F_Org_Key对应的重排后的值F_Org_Key_New，并以此替代过程模型的外码F_Org_Key；

步骤(2.6.5)，处理过程模型中的外码F_Res_Key，其处理方法为：在步骤(2.5.3)中建立的映射表中查找与F_Res_Key对应的重排后的值F_Res_Key_New，并以此替代过程模型的外码F_Res_Key。

本发明与远程协同建模技术相比，具有安全度高、成本低、适用面广等优点。

附图说明

图1是一个描述了集成化企业模型各部分模型见引用关系的图；

图2是一个描述了分布式环境下同构模型合并系统的详细结构图；

图3是一个描述了同构模型合并方法具体步骤的图。

具体实施方式

为了实现上述目的，本发明所采用的技术方案如下：

1.一套完整的分布式工作环境和数据库系统，参阅图1，该系统包括如下的主要构成部分：

(1)服务器端：一套分布式工作环境有一个服务器端，安装有基本的操作系统和数据库系统，其中操作系统应选用微软公司的视窗(Windows)系列操作系统中Win98及以上版本，数据库软件应当支持BLOB类型数据的关系数据库软件，例如微软公司的SQLServer等；

(2)客户端：一套分布式工作环境有多个客户端，安装有基本的操作系统和数据库系统，其中操作系统应选用微软公司的视窗(Windows)系列操作系统中Win98及以上版本，数据库软件应当与服务器端的一样；

(3)模型主数据库：该数据库安装在服务器端，存储的是模型合并完成以后的完整模型。

(4)模型缓冲数据库：该数据库安装在服务器端，用于存储服务器端接收的客户端上传模型。其结构与服务器端数据库一致(同构)，但是多一张数据表BUFFER_FOR_MERGE，用于记录上传至缓冲数据库中的各个模型的一些基本信息，便于服务器操作者实时监控模型上传的进程，并选择合适的模型进行合并。该表的结构如下：

表3 BUFFER_FOR_MERGE数据表结构

    字段名称 数据类型说明    record_id IntPK，自动增加型的数据    model_id Int在缓冲数据库中的模型号    is_merged smallint记录是否已经被服务器进行合并操作过0：没有本合并；1：已经合并。    model_name varchar(50)模型的名称    version varchar(20)模型的版本号    client_ip varchar(30)上传模型的客户端机器的ip    user_name varchar(30)客户端上传时使用的用户名(此属性暂时保留)    upload_time varchar(50)模型上传的时间    merged_time varchar(50)模型被合并的时间    description text上传者的说明

(5)模型分数据库：该数据库安装在各个客户端上，用于存储客户端用户所编制的各分部分企业模型。其结构与主数据库一致(同构)。

2.一套分布式环境下的模型流转与合并系统，参阅图2，该系统包括如下的主要构成部分：

(1)集成化企业建模模块：安装在客户端，用于构建集成化企业模型。该模块的输入是客户端用户根据企业情况进行的一系列建模操作，输出是包括过程模型、组织模型和资源模型三个部分的集成化企业模型。这些模型可以形式化地表示为：

·组织模型ORG(Org_Key)，其中Org_Key表示组织模型的主码；

·资源模型RES(Res_Key，F_Org_Key)，其中Res_Key表示资源模型的主码，F_Org_Key表示引用组织模型的主码作为外码；

·过程模型PROC(Proc_Key，F_Org_Key，F_Res_Key)，其中Proc_Key表示过程模型的主码，F_Org_Key表示引用组织模型的主码作为外码，F_Res_Key表示引用资源模型的主码作为外码；

此模块的功能可以用现在较成熟的企业建模软件“企管全掌控”(All In Hand)来实现。

(2)模型上传和接收模块：分别安装在客户端和服务器端，用于将存储在客户端分数据库中的模型上传至服务器端的缓冲数据库。该模块可以利用本发明中开发的软件ModelingClient(安装在客户端)和ModelingServer(安装在服务器端)来实现。

(3)模型合并模块：安装在服务器端，用于将接收到的各客户端的模型合并成一个完整的模型，这是本发明的核心部分。其输入是存储在缓冲数据库中的各分部分模型，输出是存储在主数据库中的完整模型。

3.一种能够保证企业模型一致性和完整性的方法，该方法采用的具体方案参阅图5，运行过程包括如下的步骤：

步骤1：服务器端用户通过模型合并模块浏览建模客户端上传的所有模型信息，并选择需要合并至主数据库的模型；

步骤2：服务器端用户通过模型合并模块按以下步骤把个部分模型进行合并：

步骤2.1：用户通过界面选择过程模型中需要合并至主数据库的过程或者子过程；

步骤2.2：用户通过界面选择资源模型中需要合并至主数据库的资源类型和资源实体；

步骤2.3：用户通过界面选择组织模型中需要合并至主数据库的人员、岗位和角色；

步骤3：模型合并模块根据步骤2用户的选择确定并筛选出模型缓冲数据库中各模型数据表中需要合并的记录；

步骤4：合并组织模型ORG(Org_Key)；

步骤4.1：把模型缓冲数据库中需要合并的组织模型数据表中的数据记录复制到模型主数据库中的对应模型数据表中；

步骤4.2：重排模型主数据库组织模型数据表中新增记录的主码Org_Key，重排后的主码为Org_Key_New，重排方法为：第n条新记录的主码为模型主数据库中原有组织模型数据表中的主码最大值加n；

步骤4.3：建立Org_Key与Org_Key_New一一对应的映射表；

步骤.5：合并资源模型RES(Res_Key，F_Org_Key)

步骤5.1：把模型缓冲数据库中需要合并的资源模型数据表内的数据记录复制到模型主数据库中的相应模型数据表中；

步骤5.2：重排模型主数据库资源模型数据表中新增记录的主码Res_Key，重排后主码为Res_Key_New，其重排方法为：第n条新增记录的主码为模型主数据库中原有资源模型数据表中主码最大值加n；

步骤5.3：建立Res_Key和Res_Key_New的一一对应的映射表；

步骤5.4：处理资源模型中的外码F_Org_Key，其处理方法为：在步骤4.3中建立的映射表中查找与F_Org_Key对应的重排后的值F_Org_Key_New，并以此替代资源模型的外码F_Org_Key；

步骤6：合并过程模型PROC(Proc_Key，F_Org_Key，F_Res_Key)

步骤6.1：把模型缓冲数据库中需要合并的过程模型数据表中的数据记录复制到模型主数据库中的相应模型数据表中；

步骤6.2：重排模型主数据库过程模型数据表中新增记录的主码Proc_Key，重排后的主码为Proc_Key_New，其重排方法为：第n条新增记录的主码为模型主数据库中原有过程模型数据表中主码最大值加n；

步骤6.3：建立Proc_Key和Proc_Key_New一一对应的映射表；

步骤6.4：处理过程模型中的外码F_Org_Key，其处理方法为：在步骤4.3中建立的映射表中查找与F_Org_Key对应的重排后的值F_Org_Key_New，并以此替代过程模型的外码F_Org_Key；

步骤6.5：处理过程模型中的外码F_Res_Key，其处理方法为：在步骤5.3中建立的映射表中查找与F_Res_Key对应的重排后的值F_Res_Key_New，并以此替代过程模型的外码F_Res_Key。