CN115543960B - 一种业务对象的动态建模方法和系统 - Google Patents

Abstract

本发明公开了一种业务对象的动态建模方法和系统，系统包括服务端和客户端，其中服务端将发布态的基本模型发送到客户端；客户端基于基本模型生成包括对象操纵组件的数据系统；服务端基于客户端发送的扩展需求定义扩展模型；服务端将基于扩展模型生成的变更指令发送到数据库，以使数据库基于变更指令调整数据库中基本模型对应的库表；当服务端接收到数据库反馈的变更成功消息时，发布扩展模型，并将扩展模型发送到客户端；客户端基于扩展模型调整数据系统。本发明提供的技术方案，满足系统在运行过程中动态提高业务系统适应需求变化的能力，简化业务系统开发与定制，屏蔽了数据库的差异，增强了系统的可移植性。

Description

一种业务对象的动态建模方法和系统

技术领域

本发明涉及系统应用领域，具体涉及一种业务对象的动态建模方法和系统。

背景技术

数据库模型，用于描述数据库的数据组织和操纵数据的方法，模型的结构部分规定了数据如何被描述(例如树、表等)。模型的操纵部分规定了数据的添加、删除、显示、维护、打印、查找、选择、排序和更新等操作，它强调从业务、数据存取和使用角度合理存储数据。而企业常常使用的各种数据系统，就是基于数据库模型构建的，例如各种产品管理系统、办公系统、客户管理系统等等。软件研发过程中，软件开发人员通常希望业务对象模型可以在一定的业务范围内适配多种场景，使业务系统具备扩展或调整的能力，例如，产品数据管理系统，以实现通用产品的管理为目标，从而适配多个企业。但是各企业间由于产品类型不同，产品结构、配置信息和物料清单也各不相同，即使在同一企业内，随着产品的不断演进，产品结构、配置信息和物流清单也会不断的调整。这就使得企业需要根据实际需求不断更新数据库模型，从而调整数据系统。

目前，开发人员构建数据库模型时，需要先定义数据库模型，然后在数据库中生成与数据库模型相对应的库表，之后开发人员按照顺序开发DAO层(Data Access Object，数据访问对象)、service层、Controller层和view层，从而生成企业的数据系统。如果企业需要对数据系统进行调整，则开发人员需要重新定义数据库模型，并重新进行DAO层、service层、Controller层和view层的步骤。这种模建模方法使得数据系统的开发周期长，需要多次反复，业务系统动态调整、快速响应需求变化的能力不强。

发明内容

有鉴于此，本发明实施方式提供了一种业务对象的动态建模方法和系统，可在一定程度上解决系统动态扩展的问题，增强系统响应需求变化的速度。

根据第一方面，本发明实施例提供了一种业务对象的动态建模方法，应用于服务端，所述方法包括：将发布态的基本模型发送到客户端，以使客户端基于所述基本模型在客户端中生成对应的数据系统，所述基本模型是预先定义的通用数据库模型，所述发布态用于表征模型处于生效的状态，所述数据系统中包括对象操纵组件，所述对象操纵组件用于调整数据库中所述基本模型对应库表的具体数据；接收所述客户端发送的扩展需求，并基于所述扩展需求定义扩展模型，所述扩展模型与所述基本模型具有继承关系；将基于所述扩展模型生成的变更指令发送到数据库，以使所述数据库基于所述变更指令调整数据库中所述基本模型对应的库表；当接收到所述数据库反馈的变更成功消息时，发布所述扩展模型，并将所述扩展模型发送到所述客户端，以使所述客户端基于所述扩展模型调整所述数据系统。

可选地，所述将基于所述扩展模型生成的变更指令发送到数据库，包括：将所述基本模型和所述扩展模型进行比对，基于比对差异生成发布队列；基于所述发布队列进行模型的冲突校验，并根据校验结果更新所述发布队列；将所述发布队列发送至所述客户端，以使所述客户端基于所述发布队列拼接SQL指令，并将所述SQL指令作为所述变更指令发送至所述数据库。

可选地，所述基于比对差异生成发布队列，包括：基于比对差异至少生成新增模型队列、修改模型队列、删除模型队列、新增属性队列、修改属性队列和删除属性队列中的一种作为所述发布队列。

可选地，所述基于所述发布队列进行模型的冲突校验，包括：检测所述新增模型队列、修改模型队列、删除模型队列、新增属性队列、修改属性队列和删除属性队列中的冲突操作，并校验各个队列中的操作是否符合数据库中的库表的操作权限；基于所述冲突操作和所述操作权限更新对应的新增模型队列、修改模型队列、删除模型队列、新增属性队列、修改属性队列和删除属性队列。

可选地，所述服务端通过如下方式定义所述基本模型或所述扩展模型：通过模型基本信息表定义当前模型的模型类型，所述模型类型包括普通模型和关系模型，所述普通模型用于表征现实的业务对象对应的模型，所述关系模型用于表达两个模型间的业务关系；通过模型属性管理表定义当前模型的支持的模型属性，所述模型属性包括普通属性和引用属性，所述普通属性用于表征业务对象的普通特征信息，所述引用属性用于表征当前模型对应的业务对象对其他业务对象的依赖关系；通过模型关系管理表定义当前模型的模型关系，所述模型关系包括关联关系，所述关联关系用于表征当前模型对应的业务对象与其他业务对象之间的多对多关系。

可选地，所述方法还包括：接收客户端发送的类文件，所述类文件中包括注释；扫描所述类文件，并基于所述类文件中的注释生成对应的基本模型。

根据第二方面，本发明实施例提供了一种业务对象的动态建模方法，应用于客户端，所述方法包括：接收服务端发送的发布态的基本模型，并基于所述基本模型生成对应的数据系统，所述基本模型是所述服务端预先定义的通用数据库模型，所述发布态用于表征模型处于生效的状态，所述数据系统中包括对象操纵组件，所述对象操纵组件用于调整数据库中所述基本模型对应库表的具体数据；发送扩展需求到所述服务端，以使所述服务端基于所述扩展需求定义扩展模型，并将基于所述扩展模型生成的变更指令发送到数据库，以使所述数据库基于所述变更指令调整数据库中所述基本模型对应的库表，并使所述服务端在接收到所述数据库反馈的变更成功消息时，发布所述扩展模型，所述扩展模型在现实中对应的业务对象归属于所述基本模型在现实中对应的业务对象；接收所述服务端发送的发布态的扩展模型，并基于所述扩展模型调整所述数据系统。

可选地，所述客户端通过所述对象操纵组件调整数据库中所述基本模型对应库表的具体数据的步骤包括：通过所述对象操纵组件获取待修改的实体对象；通过所述实体对象对应的模型标识从所述数据库中获取所述实体对象对应的库表以及属性信息；通过实体对象对应的唯一标识从库表中确定待修改的实体对象数据；根据所述属性信息拼接属性调整SQL指令；将所述属性调整SQL指令发送至所述数据库对所述待修改的实体对象数据进行数据修改。

可选地，所述客户端上部署有模型管理操作接口，用于使客户端通过所述模型管理操作接口在所述服务端中定义扩展模型。

可选地，操纵实体对象时，通过所述对象操纵组件屏蔽数据库类型的差异，并通过ORM模块动态转换数据库可执行脚本；由模型发布、模型管理接口及对象操纵组件适配新数据库类型。

根据第三方面，本发明实施例提供了一种业务对象的动态建模系统，包括服务端和客户端，其中，所述服务端将发布态的基本模型发送到客户端，所述基本模型是预先定义的通用数据库模型，所述发布态用于表征模型处于生效的状态；所述客户端接收所述服务端发送的发布态的基本模型，并基于所述基本模型生成对应的数据系统，所述数据系统中包括对象操纵组件，所述对象操纵组件用于调整数据库中所述基本模型对应库表的具体数据；所述客户端发送扩展需求到所述服务端；所述服务端接收所述客户端发送的扩展需求，并基于所述扩展需求定义扩展模型，所述扩展模型在现实中对应的业务对象归属于所述基本模型在现实中对应的业务对象；所述服务端将基于所述扩展模型生成的变更指令发送到数据库，以使所述数据库基于所述变更指令调整数据库中所述基本模型对应的库表；当所述服务端接收到所述数据库反馈的变更成功消息时，发布所述扩展模型，并将所述扩展模型发送到所述客户端；所述客户端接收所述扩展模型，并基于所述扩展模型调整所述数据系统。

本申请提供的技术方案，具有如下优点：

本申请提供的技术方案，通过元数据驱动引擎，实现系统中类型、关系、属性等元数据的统一描述及管理能力，提供基本模型及扩展模型的统一定义及查询，结合对象操纵组件提供的实例对象通用ORM接口，实现基本模型实例对象及扩展模型实例对象的无差别处理。

具体先通过服务端预先定义基本模型，该基本模型在数据库中生成了对应的库表，服务端中定义的模型分为编辑态和发布态，只有定义的模型发布后才生效。基于上述机制，将服务端的基本模型同步到企业所使用的客户端生成对应的数据系统，企业通过该数据系统即可操作数据库中的库表。当企业具有个性化需求时，通过客户端发送扩展需求到服务端，从而服务端基于扩展需求定义扩展模型，服务端再根据定义的扩展模型发送变更指令到数据库，使得数据库基于变更指令调整库表结构，当数据库库表调整成功时，返回变更成功消息，此时服务端才将扩展模型发布生效，从而将发布态的扩展模型同步到客户端，使客户端的数据系统进行相应的调整，从而保持对数据库中的库表的业务一致性。其中，基本模型与扩展模型之间具有继承关系，扩展模型在现实中对应的业务对象归属于基本模型在现实中对应的业务对象。特别地，客户端生成的数据系统中配置有对象操纵组件，用于调整数据库中基本模型对应库表的具体实例数据。通过上述步骤，当企业的业务发生改变需要调整模型时，只需要根据客户端的扩展需求定义扩展模型，并将扩展模型重新发布即可，从而对应调整数据库中的库表结构和数据系统结构，使数据系统与库表保持一致。并且本发明实施例在客户端数据系统中设置了对象操纵组件，可直接用于调整数据库中模型对应库表的具体数据，因此无需写DAO层，从而service层、controller层在第一次配置之后无需更改。综合上述步骤，当一个企业产生个性化需求变更时，或者不同企业之间的个性化需求不同时，考虑到它们大多数业务场景的相似性，其数据系统均可采用同一基本模型，只需要在服务端定义扩展模型重新发布即可，并且无需重写DAO层、service层和controller层，从而增强了系统动态调整、快速响应需求变化的能力，简化业务系统开发与定制，显著提高了对数据库建模的效率。

附图说明

通过参考附图会更加清楚的理解本发明的特征和优点，附图是示意性的而不应理解为对本发明进行任何限制，在附图中：

图1示出了本发明一个实施方式中一种业务对象的动态建模系统的结构示意图；

图2示出了本发明一个实施方式中一种业务对象的动态建模系统的另一结构示意图；

图3示出了本发明一个实施方式中一种业务对象的动态建模方法的步骤示意图；

图4示出了本发明一个实施方式中一种业务对象的动态建模方法的流程示意图。

具体实施方式

为使本发明实施方式的目的、技术方案和优点更加清楚，下面将结合本发明实施方式中的附图，对本发明实施方式中的技术方案进行清楚、完整地描述，显然，所描述的实施方式是本发明一部分实施方式，而不是全部的实施方式。基于本发明中的实施方式，本领域技术人员在没有作出创造性劳动前提下所获得的所有其他实施方式，都属于本发明保护的范围。

请参阅图1，在一个实施方式中，一种业务对象的动态建模系统，包括服务端1和客户端2，其中：

服务端1将发布态的基本模型发送到客户端2；

客户端2接收服务端1发送的发布态的基本模型，并基于基本模型生成对应的数据系统；

客户端2发送扩展需求到服务端1；

服务端1接收客户端2发送的扩展需求，并基于扩展需求定义扩展模型；

服务端1将基于扩展模型生成的变更指令发送到数据库，以使数据库基于变更指令调整数据库中基本模型对应的库表；

当服务端1接收到数据库反馈的变更成功消息时，发布扩展模型，并将扩展模型发送到客户端2；

客户端2接收扩展模型，并基于扩展模型调整数据系统。

其中，基本模型是预先定义的通用数据库模型，发布态用于表征模型处于生效的状态；数据系统中包括对象操纵组件，对象操纵组件用于调整数据库中基本模型对应库表的具体数据；扩展模型在现实中对应的业务对象归属于基本模型在现实中对应的业务对象。

具体地，在本实施例中，数据库建模主要通过两种设备实现，分别是服务端1和客户端2，客户端2则是企业、用户侧安装数据系统所用的服务器设备，服务端1是开发人员进行建模、提供数据库模型的服务器设备。为了提高数据库模型的多场景适配能力，同时提高数据库建模的效率。本实施例使开发人员通过服务端1预先开发适用于多种场景的基本模型，例如零部件管理系统，该系统在汽车、飞机、火车等制造企业均有用处，且各个企业的零部件有共通性，基本模型则是能够适用于上述场景大部分业务的通用数据库模型。当某个企业的客户端2需要创建数据系统时，服务端1首先发送基本模型到客户端2，生成对应的数据系统，企业则可以在客户端2上利用数据系统与数据库中当前模型对应的库表对接，从而对库表中的内容进行操作。当企业具有个性化需求时，发送扩展需求到服务端1，从而服务端1基于扩展需求定义扩展模型，本实施例动态构建数据库模型的方法基于面向对象的编程思想，基本模型与扩展模型之间具有继承关系，扩展模型在现实中对应的业务对象归属于基本模型在现实中对应的业务对象，扩展模型可以继承基本模型的所有属性。扩展模型定义完成后，服务端1再根据定义的扩展模型发送变更指令到数据库，使得数据库基于变更指令对当前模型对应的库表进行调整，包括结构、属性等，调整方式包括在原表上调整或新建子表。当数据库库表调整成功时，返回变更成功消息，此时服务端1才将扩展模型发布生效，从而将发布态的扩展模型同步到客户端2，使客户端2的数据系统进行相应的调整，从而保持对数据库中的库表的操作性。特别地，客户端2生成的数据系统中配置有对象操纵组件，用于调整数据库中模型对应库表中的具体数据。

基于此，当企业的业务发生改变需要调整模型时，只需要根据客户端2的扩展需求定义扩展模型，并将扩展模型重新发布即可，从而对应调整数据库中的库表结构和数据系统结构，使数据系统与库表保持一致。并且本发明实施例的客户端2直接通过对象操纵组件调整数据库中基本模型对应库表的具体数据，因此无需再写DAO层，从而service层、controller层在第一次配置之后无需更改。综合上述步骤，当一个企业需要布置数据系统时，考虑到当前企业与其他企业大多数业务场景的相似性，数据系统均可采用基本模型进行快速部署，然后再根据当前企业的个性化需求，只需要在服务端1定义扩展模型重新发布即可，并且因为对象操纵组件的存在，无需重写DAO层、service层和controller层，若企业的需求发生变更，只需再次定义扩展模型并发布，从而显著提高了系统适应需求变化的能力。

具体地，如图2所示，本发明实施例还提供了一种业务对象的动态建模方法，其中服务端用于执行步骤S101～S104，客户端用于执行步骤S201～S203，具体步骤如下：

步骤S101：将发布态的基本模型发送到客户端，基本模型是预先定义的通用数据库模型，发布态用于表征模型处于生效的状态。

步骤S201：接收服务端发送的发布态的基本模型，并基于基本模型生成对应的数据系统，数据系统中包括对象操纵组件，对象操纵组件用于调整数据库中基本模型对应库表的具体数据。

步骤S202：发送扩展需求到服务端。

步骤S102：接收客户端发送的扩展需求，并基于扩展需求定义扩展模型，扩展模型与基本模型具有继承关系。

步骤S103：将基于扩展模型生成的变更指令发送到数据库，以使数据库基于变更指令调整数据库中基本模型对应的库表。

步骤S104：当接收到数据库反馈的变更成功消息时，发布扩展模型，并将扩展模型发送到客户端。

步骤S203：接收服务端发送的发布态的扩展模型，并基于扩展模型调整数据系统。

具体地，本发明实施例步骤的实现原理可参考上述系统实施例的相关描述，在此不再赘述。

具体地，如图3所示，上述步骤S103，具体包括如下步骤：

步骤一：将基本模型和扩展模型进行比对，基于比对差异生成发布队列。

步骤二：基于发布队列进行模型的冲突校验，并根据校验结果更新发布队列。

步骤三：将发布队列发送至客户端，以使客户端基于发布队列拼接SQL指令，并将SQL指令作为变更指令发送至数据库。

具体地，当扩展模型定义完成后，本发明实施例进入发布流程，以模型为单位，可选择一个或多个模型进行发布，模型发布时涉及到模型属性的修改，需要库表结构对应进行动态变更，从而在库表调整完成后将扩展模型从编辑态转换为发布态使之生效，所谓生效即是指在业务系统进行业务处理时所需要的模型信息是否能够获取到以及所定义的模型信息是否已经影响到了对应的业务对象或业务处理。

进入发布流程时，首先执行模型比对和冲突校验两个步骤。服务端根据接收到的待发布的模型(例如当前的扩展模型)，根据发布标识和应用标识进行筛选，获取与当前模型相对应的已发布模型和未发布模型及相应的模型属性(本实施例限定的场景是第一次扩展，因此将基本模型与扩展模型进行比对，若本次发布不是第一次扩展，则还需将当前的扩展模型与基本模型、服务端内部对应的其他扩展模型均进行比对)，比对模型及属性间的差异。对于新增和删除的模型，记录新增或删除的模型上有哪些模型属性。对于修改的模型，记录模型属性的修改信息，对新增或删除的属性，记录到属性及其上的内容。根据比对差异形成对应的模型发布队列、属性发布队列，根据具体要执行的动作进一步细分为新增模型队列、修改模型队列、删除模型队列、新增属性队列、修改属性队列和删除属性队列。

这样做的目的是考虑到实际应用时每种数据库的DDL语句(数据定义语言，这些语句定义了不同的数据段、数据库、表、列、索引等数据库对象的定义)存在差异，需要客户端根据实际采用的数据库类型拼接成对应的SQL语句，连接到数据库执行。因此本实施例不通过服务端直接与数据库对接，而是基于比对差异生成通用的发布队列，再将发布队列发送给客户端，模型发布时，基于应用系统数据库类型的差异，使客户端解析出发布队列中的调整操作，动态生成数据库表结构变更的SQL语句，即根据实际采用的数据库情况灵活拼接SQL语句，实现适配多种数据库的功能。

在生成最终的发布队列之前，本发明实施例还对发布队列进行模型的冲突校验，具体包括如下步骤：

1.检测新增模型队列、修改模型队列、删除模型队列、新增属性队列、修改属性队列和删除属性队列中的冲突操作，并校验各个队列中的操作是否符合数据库中的库表的操作权限。

2.基于冲突操作和操作权限更新对应的新增模型队列、修改模型队列、删除模型队列、新增属性队列、修改属性队列和删除属性队列。

具体地，针对需要修改的模型和属性，遍历模型队列和属性队列，执行模型冲突的变更校验，如库表或者列是否允许或重复新增、是否允许删除等。例如：当前新建了扩展模型，具体为新建父模型同时新建子模型，在数据库中对应了1张库表，父模型上去掉了某属性，而某个子模型上新建了该属性，那么该属性在库表中对应的字段就会删除再添加，这种操作即为冲突操作，为了提高发布效率，该字段不需要删除后再添加，从而更新发布队列。操作权限用于表征库表不允许的操作却在发布队列中出现，那么该操作应当舍弃，冲突校验之后，形成最终的发布队列。服务端将发布队列同步至其数据系统所在服务上的客户端，客户端根据数据库类型，按照发布队列分别拼接“create table”、“alter table”、“deletetable”等SQL语句，形成待执行的SQL语句，之后客户端连接数据库，执行该SQL语句，并将数据库的执行结果返回服务端，若数据库反馈的是变更成功消息，则服务端发布当前模型使之生效。此外，在本实施例中，服务端同时记录模型发布的历史记录及发布过程的SQL语句，便于回溯模型变更过程。

具体地，在一实施例中，服务端通过如下方式定义基本模型或扩展模型：

步骤四：通过模型基本信息表定义当前模型的模型类型，模型类型包括普通模型和关系模型，普通模型用于表征现实的业务对象对应的模型，关系模型用于表达两个模型间的业务关系。

步骤五：通过模型属性管理表定义当前模型的支持的模型属性，模型属性包括普通属性和引用属性，普通属性用于表征业务对象的普通特征信息，引用属性用于表征当前模型对应的业务对象对其他业务对象的依赖关系。

步骤六：通过模型关系管理表定义当前模型的模型关系，模型关系包括继承关系和关联关系，继承关系用于表征当前模型对应的业务对象与其他业务对象之间的父子关系，关联关系用于表征当前模型对应的业务对象与其他业务对象之间的多对多关系。

具体地，本发明实施例定义模型主要分为三部分，第一部分定义当前模型的基本信息，主要用于表述当前模型的模型类型；第二部分定义管理当前模型的属性信息，用于维护当前模型对应的业务对象或关系对象所具有的属性列表；第三部分定义模型关系信息，基于UML类图规范，提供对模型间常见的关系的处理能力，涵盖引用、继承和关联。此外，模型信息包括基本信息和扩展信息，在模型信息的管理表中通过标志位flag进行区分，并在系统运行中保障基本信息不被删除或调整。从而通过上述定义步骤，即可基于任意的场景和用户需求对基本模型和扩展模型完成准确的模型构建。

第一部分：定义模型类型用于进行系统中模型的维护，通过对现实中常见的模型抽象，包括普通模型和关系模型两种。服务端提供普通模型和关系两个菜单，可直接新建、编辑、删除普通模型和关系模型。普通模型指现实中某一类业务对象对应的模型，例如：学生(Student)、产品(Product)等。关系模型用于表达两个模型间的某类业务关系，可具有或不具有属性，如成绩表(Score)用于表达学生与课程间的成绩关系，其上有score(考试分数)属性。服务端提供普通模型和关系两个菜单，可直接新建、编辑、删除普通模型和关系模型。模型基本信息的主要数据结构如表1所示。

表1模型基本信息表

表中，模型标识(classid)用于区分当前模型是普通模型还是关系模型，PTDBType为普通模型，PTDBRelation为关系模型。模型标识带有业务含义，比如产品结构管理系统中需要对产品(product)和文档(doc)进行管理，需要对product类型的对象提供新增、修改、删除等操作，doc类型的对外可以进行上传、下载等操作，从而根据不同的模型标识提供不同的操作。唯一标识(innerid)是当前模型的唯一标识，可用于查找和检索，表征当前模型的身份。模型业务标识(id)，具有一定的规范和业务含义，主要用于描述，如产品、文档等；表名(tablename)表征的是业务对象或关系对象数据在数据库中库表的名称。父模型(parent)对应两个字段：parentInnerd为父模型信息的innerid，parentClassid为父模型信息的classid，表征了当前模型与其他模型的继承关系，从而定义当前模型是父模型还是子模型，本发明实施例中扩展模型在现实中对应的业务对象归属于基本模型在现实中对应的业务对象，即通过继承关系的字段进行定义。

第二部分：模型属性管理，用于维护模型对应的业务对象或关系对象所具有的属性列表，用属性描述模型或关系的特征。如入库单的入库单号、入库日期等；部件的编号、名称、创建人等；以及PDM(产品数据管理)中的部件使用关系在描述了部件组成的同时也数量等属性信息。每个模型可以由一个或若干个自定义属性。模型属性包括普通属性、引用属性两种。普通属性用于表达业务对象上的普通特征信息，例如产品(Product)模型包括名称(name)、编号(number)等属性。只需要一个字段就能描述相应的属性值。每个属性包含标识、名称、属性类型、属性长度等信息。引用属性用于表达业务对象对其他业务对象的依赖关系。例如，产品(Product)模型拥有创建人属性，该属性对应了用户(User)模型。每个属性包含标识、名称、引用的模型等信息，模型属性的表结构信息如表2所示。

表2模型属性管理表

其中，唯一标识(innerId)是当前模型的唯一标识，与表1同理，不再赘述。模型标识(classId)用于区分属性的类型，PTCommModelAttr为普通属性，PTRefModelAttr为引用属性；隶属的模型(model)表明属性所属的模型，由2列组成，modelInnerId为隶属模型的唯一标识，modelClassId为隶属模型的模型标识；当属性为普通属性的时候，属性类型(attrDataType)和属性长度(attrLength)不为空。属性类型支持字符串、字符型、整形、实型、日期时间型等场景的数据类型；当属性为引用属性时，属性关联模型(refModel)不为空，表明该引用属性对应的模型信息，由引用属性关联模型的唯一标识(refModelInnerId)和模型标识(refModelClassId)两个字段组成，分别用于获取数据实例和数据库表。服务端提供了普通属性、引用属性的维护菜单，维护普通属性时，输入属性标识、属性名称、属性的数据类型和属性长度即可，维护引用属性时，除属性标识和属性名称外，在弹出的模型选择树中选择某模型后，将所选模型的innerId和classId的值分别设置为该属性上对应的refModelInnerId和refModelClassId的值，从而将选择的模型设置为该引用属性引用的模型。在新建普通模型时，将为该模型自动添加唯一标识(innerId)、模型标识(classId)两个普通属性。新建关系模型时，将为该模型自动添加唯一标识(innerId)、模型标识(classId)两个普通属性，以及起始端对象(fromObject)、终止端对象(toObject)两个引用属性。

第三部分：模型关系管理，基于UML类图规范，提供对模型间常见的关系的处理能力，涵盖引用、继承和关联。具体包括引用关系、继承关系和关联关系。引用关系是指一个业务对象对另外一个业务对象的引用，通常用来表达对象之间的一对一、一对多的关系。引用关系在前述模型属性管理的引用属性中已经进行相应的描述，在此不再赘述。继承关系主要表达业务对象间的父子关系，子对象可以继承父对象的一些特征，例如，部件(Part)进一步细分，可包括机械部件(MechanicalPart)和电子元器件(ElectronicComponent)。机械部件和电子元器件从部件上继承了部件的公共属性，同时还具有自己的属性。继承关系在前述类型管理已经描述，在此不再赘述。需要注意的是，具有继承关系的父子模型，子模型会自动继承父模型的属性。查询模型属性的时候，如果模型有父模型，则从父模型开始查询，向上逆向查询父模型的父模型，直至某模型没有父模型，将查询到的所有模型作为一个集合，查询该模型集合中非私有化的属性信息，并与当前模型上定义的属性合并后作为当前模型的属性列表返回。

关联关系一般指对象之间多对多的关系。例如产品管理系统中的部件使用关系(PartUsageLink)描述部件组成结构，一个部件对象可以使用多个其他部件对象，一个部件对象也可以被多个部件对象使用。每个关系上可具有多条关联，描述该关系上可建立关联关系的两端模型。关联关系的表结构如表3所示。

表3.模型关系管理表

其中，关联关系的模型标识(classId)的值为PTAssociation；所属关系(relation)、起始端模型(from)、终止端(to)为3个引用了模型信息的引用属性，各由2个字段构成，分别对应模型信息的唯一标识和模型标识。维护关联关系时，选择起始端模型和终止端模型，所选择的起始端和终止端模型的inenrId、classId将分别设置为fromInnerId、fromClassId、toInnerId、toClassId的值即可。在业务系统运行过程中，可在一定的范围内进行关联关系的动态调整。当前模型唯一标识(innerId)与表1同理，不再赘述。基于上述预置的属性，持久化引擎才能够实现对业务对象或关系对象的处理。

具体地，在一实施例中，服务端执行的动态建模方法，还包括如下步骤：

步骤七：接收客户端发送的类文件，类文件中包括注释。

步骤八：扫描类文件，并基于类文件中的注释生成对应的基本模型。

具体地，为了满足部分开发人员不习惯在服务端页面上定义模型，而习惯自己写模型类文件的需求，本实施例使开发人员可以直接在类文件上添加注释，服务端提供了类扫描器，在应用系统服务启动的时候自动加载类扫描器，由其扫描注释，根据注释内容自动将类文件设置为注解模型(注解模型为基本模型)，从而提升用户创建模型的使用体验。

具体地，在本实施例中，服务端还支持逆向建模，针对数据库中库表已经存在的情况，可以将数据库表逆向为模型，具体步骤通过对象操纵组件实现。

具体地，在一实施例中，客户端上部署有模型管理操作接口，用于使客户端通过模型管理操作接口在服务端中定义扩展模型。

具体地，为了进一步便于定义扩展模型，在客户端的数据系统中还部署了模型管理操作接口，如图3所示，该接口用于对接服务端中的模型管理操作，开发人员为企业部署数据系统时，可以直接通过模型管理操作接口远程在服务端中定义扩展模型，进行模型的新增、删除、修改、发布的操作，从而进一步提高了动态建模的效率。

模型管理操作接口支持的主要功能有：

·模型管理，包括新建模型、修改模型、删除模型、查询模型信息。

·模型属性管理，包括新建属性、修改属性、删除属性、获取模型属性、获取所有模型属性。

·关联关系管理，包括新建关联关系、修改关联关系、删除关联关系、查询关联关系、获取起始端模型、获取终止端模型。

·模型发布，包括发布前的比较、模型发布、获取发布记录。

模型管理操作实现的接口如表4所示。

表4.模型管理操作接口配置表

具体地，在一实施例中，客户端通过对象操纵组件调整数据库中基本模型对应库表的具体数据的步骤包括：

步骤九：通过对象操纵组件获取待修改的实体对象。

步骤十：通过实体对象对应的模型标识从数据库中获取实体对象对应的库表以及属性信息。

步骤十一：通过实体对象对应的唯一标识从库表中确定待修改的实体对象数据。

步骤十二：根据属性信息拼接属性调整SQL指令。

步骤十三：将属性调整SQL指令发送至数据库对待修改的实体对象数据进行数据修改。

具体地，对象操纵组件，用于帮助构建任意形态、面向对象的业务数据管理，提供通用的对象PtObject，数据库库表中的每条实例数据都统一映射为ptObject对象，基于该对象提供了通用的对象操纵组件，主要包括对象操作、属性操作和关系操作，其中对象操作包括新增对象、修改对象、删除对象、查询对象、查询被使用的对象；属性操作包括获取对象中的属性值、设置属性值；关系操作包括获取终止端对象、获取起始端对象、获取所有的关联对象。对象操纵组件的具体接口配置如表5所示。

表5.对象操纵组件配置表

具体操作流程为：通过对象操纵组件参数获取待调整的实体对象(实体对象即ptObject对象)；然后利用实体对象内置的获取业务对象(业务对象即现实中模型对应的对象，例如学生、部件、产品等)模型标识的接口，得到实体对象内的模型标识；利用该模型标识获取实体对象对应的数据在数据库中所存储的库表信息；利用该模型标识获取属性列表的接口，获取该模型对应的属性信息；利用实体对象内置的获取业务对象唯一标识的接口，获取实体对象的唯一标识，通过该唯一标识从获取的库表中找到需要调整的实体对象的数据；客户端基于不同的数据库类型，按照新增、更新、删除或查询等分类，拼接insert、update、delete或select等数据库SQL语句，利用除innerid、classid外的属性信息继续拼接SQL语句，之后客户端连接数据库执行相应的SQL语句，对数据库中对应的实体数据进行调整；如果为查询接口，将获取的结果根据模型上的属性转换为通用实体对象，并返回调用方。

通过上述步骤，开发人员无需关注是基本模型，还是现场动态添加的扩展模型，只需要按照模型管理操作和对象操纵组件提供的API接口编写即可满足模型本身和模型属性的动态调整，提高建模效率。

具体地，在一实施例中，本发明实施例提供的数据操纵组件同样支持不同数据库类型，在用户操纵实体对象数据时，还通过对象操纵组件屏蔽数据库类型的差异，并通过ORM(Object Relational Mapping，对象关系映射)模块动态转换数据库可执行脚本。当设置新的数据库时，本发明实施例由模型发布、模型管理接口及对象操纵组件适配新数据库类型，使客户端的数据系统无感知。通过上述机制，进一步体现了建模方法的动态特点，针对用户所使用的不同数据库场景均可快速适配，减少开发人员的配置操作，增强了系统适应需求变化的能力，显著提升开发人员建模的便利性和使用体验，提高建模效率。

通过上述步骤，本申请提供的技术方案，先通过服务端预先定义基本模型，并且该基本模型在数据库中生成了对应的库表，服务端中定义的模型分为编辑态和发布态，只有定义的模型发布后才生效。基于上述机制，将服务端的基本模型同步到企业所使用的客户端生成对应的数据系统，企业通过该数据系统即可操作数据库中的库表。当企业具有个性化需求时发送扩展需求到服务端，从而服务端基于扩展需求定义扩展模型，服务端再根据定义的扩展模型发送变更指令到数据库，使得数据库基于变更指令调整库表结构，当数据库库表调整成功时，返回变更成功消息，此时服务端才将扩展模型发布生效，从而将发布态的扩展模型同步到客户端，使客户端的数据系统进行相应的调整，从而保持对数据库中的库表的操作性。其中，基本模型与扩展模型之间具有父子关系，扩展模型在现实中对应的业务对象归属于基本模型在现实中对应的业务对象。特别地，客户端生成的数据系统中配置有对象操纵组件，用于调整数据库中基本模型对应库表的具体数据。通过上述步骤，当企业的业务发生改变需要调整模型时，只需要根据客户端的扩展需求定义扩展模型，并将扩展模型重新发布即可，从而对应调整数据库中的库表结构和数据系统结构，使数据系统与库表保持一致。并且本发明实施例在客户端数据系统中设置了对象操纵组件，可直接用于调整数据库中基本模型对应库表的具体数据，因此无需写DAO层，从而service层、controller层在第一次配置之后无需更改。综合上述步骤，当一个企业产生个性化需求变更时，或者不同企业之间的个性化需求不同时，考虑到它们大多数业务场景的相似性，其数据系统均可采用同一基本模型，只需要在服务端定义扩展模型重新发布即可，并且无需重写DAO层、service层和controller层，从而增强了系统适应需求变化的能力，显著提高了数据库建模的效率。

虽然结合附图描述了本发明的实施例，但是本领域技术人员可以在不脱离本发明的精神和范围的情况下作出各种修改和变型，这样的修改和变型均落入由所附权利要求所限定的范围之内。

Claims (10)

1.一种业务对象的动态建模方法，其特征在于，应用于服务端，所述方法包括：

将发布态的基本模型发送到客户端，以使客户端基于所述基本模型在客户端中生成对应的数据系统，所述基本模型是预先定义的通用数据库模型，所述发布态用于表征模型处于生效的状态，所述数据系统中包括对象操纵组件，所述对象操纵组件用于调整数据库中所述基本模型对应库表的具体数据；

接收所述客户端发送的扩展需求，并基于所述扩展需求定义扩展模型，所述扩展模型与所述基本模型具有继承关系；

将基于所述扩展模型生成的变更指令发送到数据库，以使所述数据库基于所述变更指令调整数据库中所述基本模型对应的库表；

当接收到所述数据库反馈的变更成功消息时，发布所述扩展模型，并将所述扩展模型发送到所述客户端，以使所述客户端基于所述扩展模型调整所述数据系统；

所述基本模型或所述扩展模型通过如下方式定义：

通过模型基本信息表定义当前模型的模型类型，所述模型类型包括普通模型和关系模型，所述普通模型用于表征现实的业务对象对应的模型，所述关系模型用于表达两个模型间的业务关系；通过模型属性管理表定义当前模型的支持的模型属性，所述模型属性包括普通属性和引用属性，所述普通属性用于表征业务对象的普通特征信息，所述引用属性用于表征当前模型对应的业务对象对其他业务对象的依赖关系；通过模型关系管理表定义当前模型的模型关系，所述模型关系包括关联关系，所述关联关系用于表征当前模型对应的业务对象与其他业务对象之间的多对多关系。

2.根据权利要求1所述的方法，其特征在于，所述将基于所述扩展模型生成的变更指令发送到数据库，包括：

将所述基本模型和所述扩展模型进行比对，基于比对差异生成发布队列；

基于所述发布队列进行模型的冲突校验，并根据校验结果更新所述发布队列；

将所述发布队列发送至所述客户端，以使所述客户端基于所述发布队列拼接SQL指令，并将所述SQL指令作为所述变更指令发送至所述数据库。

3.根据权利要求2所述的方法，其特征在于，所述基于比对差异生成发布队列，包括：

基于比对差异至少生成新增模型队列、修改模型队列、删除模型队列、新增属性队列、修改属性队列和删除属性队列中的一种作为所述发布队列。

4.根据权利要求3所述的方法，其特征在于，所述基于所述发布队列进行模型的冲突校验，包括：

检测所述新增模型队列、修改模型队列、删除模型队列、新增属性队列、修改属性队列和删除属性队列中的冲突操作，并校验各个队列中的操作是否符合数据库中的库表的操作权限；

基于所述冲突操作和所述操作权限更新对应的新增模型队列、修改模型队列、删除模型队列、新增属性队列、修改属性队列和删除属性队列。

5.根据权利要求1所述的方法，其特征在于，所述方法还包括：

接收客户端发送的类文件，所述类文件中包括注释；

扫描所述类文件，并基于所述类文件中的注释生成对应的基本模型。

6.一种业务对象的动态建模方法，其特征在于，应用于客户端，所述方法包括：

接收服务端发送的发布态的基本模型，并基于所述基本模型生成对应的数据系统，所述基本模型是所述服务端预先定义的通用数据库模型，所述发布态用于表征模型处于生效的状态，所述数据系统中包括对象操纵组件，所述对象操纵组件用于调整数据库中所述基本模型对应库表的具体数据；

发送扩展需求到所述服务端，以使所述服务端基于所述扩展需求定义扩展模型，并将基于所述扩展模型生成的变更指令发送到数据库，以使所述数据库基于所述变更指令调整数据库中所述基本模型对应的库表，并使所述服务端在接收到所述数据库反馈的变更成功消息时，发布所述扩展模型，所述扩展模型在现实中对应的业务对象归属于所述基本模型在现实中对应的业务对象；

接收所述服务端发送的发布态的扩展模型，并基于所述扩展模型调整所述数据系统；

所述基本模型或所述扩展模型通过如下方式定义：

通过模型基本信息表定义当前模型的模型类型，所述模型类型包括普通模型和关系模型，所述普通模型用于表征现实的业务对象对应的模型，所述关系模型用于表达两个模型间的业务关系；通过模型属性管理表定义当前模型的支持的模型属性，所述模型属性包括普通属性和引用属性，所述普通属性用于表征业务对象的普通特征信息，所述引用属性用于表征当前模型对应的业务对象对其他业务对象的依赖关系；通过模型关系管理表定义当前模型的模型关系，所述模型关系包括关联关系，所述关联关系用于表征当前模型对应的业务对象与其他业务对象之间的多对多关系。

7.根据权利要求6所述的方法，其特征在于，所述客户端通过所述对象操纵组件调整数据库中所述基本模型对应库表的具体数据的步骤包括：

通过所述对象操纵组件获取待修改的实体对象；

通过所述实体对象对应的模型标识从所述数据库中获取所述实体对象对应的库表以及属性信息；

通过实体对象对应的唯一标识从库表中确定待修改的实体对象数据；

根据所述属性信息拼接属性调整SQL指令；

将所述属性调整SQL指令发送至所述数据库对所述待修改的实体对象数据进行数据修改。

8.根据权利要求6所述的方法，其特征在于，所述客户端上部署有模型管理操作接口，用于使客户端通过所述模型管理操作接口在所述服务端中定义扩展模型。

9.根据权利要求7所述的方法，其特征在于，所述方法还包括：

操纵实体对象时，通过所述对象操纵组件屏蔽数据库类型的差异，并通过ORM模块动态转换数据库可执行脚本；

由模型发布、模型管理接口及对象操纵组件适配新数据库类型。

10.一种业务对象的动态建模系统，其特征在于，包括服务端和客户端，其中，

所述服务端将发布态的基本模型发送到客户端，所述基本模型是预先定义的通用数据库模型，所述发布态用于表征模型处于生效的状态；

所述客户端接收所述服务端发送的发布态的基本模型，并基于所述基本模型生成对应的数据系统，所述数据系统中包括对象操纵组件，所述对象操纵组件用于调整数据库中所述基本模型对应库表的具体数据；

所述客户端发送扩展需求到所述服务端；

所述服务端接收所述客户端发送的扩展需求，并基于所述扩展需求定义扩展模型，所述扩展模型在现实中对应的业务对象归属于所述基本模型在现实中对应的业务对象；

所述服务端将基于所述扩展模型生成的变更指令发送到数据库，以使所述数据库基于所述变更指令调整数据库中所述基本模型对应的库表；

当所述服务端接收到所述数据库反馈的变更成功消息时，发布所述扩展模型，并将所述扩展模型发送到所述客户端；

所述客户端接收所述扩展模型，并基于所述扩展模型调整所述数据系统；

所述基本模型或所述扩展模型通过如下方式定义：

通过模型基本信息表定义当前模型的模型类型，所述模型类型包括普通模型和关系模型，所述普通模型用于表征现实的业务对象对应的模型，所述关系模型用于表达两个模型间的业务关系；通过模型属性管理表定义当前模型的支持的模型属性，所述模型属性包括普通属性和引用属性，所述普通属性用于表征业务对象的普通特征信息，所述引用属性用于表征当前模型对应的业务对象对其他业务对象的依赖关系；通过模型关系管理表定义当前模型的模型关系，所述模型关系包括关联关系，所述关联关系用于表征当前模型对应的业务对象与其他业务对象之间的多对多关系。