用于计算机系统的业务建模方法、装置、系统和介质与流程

文档序号:21545909发布日期:2020-07-17 17:55阅读:147来源:国知局
本公开涉及计算机
技术领域
:,更具体地,涉及一种用于计算机系统的业务建模方法、装置、计算机系统和介质。
背景技术
::随着数字银行信息化的发展,商业银行需要了解各行各业的科技发展和业务需求,获取大量的业务数据,设计各种各样的业务场景和应用系统架构,来为企业、个人等客户提供更好的服务。例如,建立架构管控平台系统,通过在架构管理平台系统中管理和分析业务流程和应用系统架构的设计,在不同的业务或it服务之间建立关联关系来指导工作,确保完整的业务流程或者系统建设具有整体性和协调性。具体地,可以通过在系统中针对各种业务场景和应用系统架构进行建模,随着业务的动态扩增或变化不断建模并调整数据模型之间的关联关系,来满足越来越多的业务服务场景和新的应用系统的规划设计需求。技术实现要素:本公开的一个方面提供了一种用于计算机系统的业务建模方法,包括:配置元模型文件,该元模型文件包括:预设关联关系属性的信息。基于元模型文件,在数据库中构建针对业务对象的第一数据模型,第一数据模型包括:预设关联关系属性。获取第一数据模型中的预设关联关系属性的赋值对象。当数据库中存在针对该赋值对象的第二数据模型时,建立第一数据模型和第二数据模型之间的关联关系,以使第一数据模型的业务数据和第二数据模型的业务数据之间关联存储。可选地,上述方法还包括:当数据库中不存在针对赋值对象的第二数据模型时,对数据库进行监测。当监测到数据库的存储内容发生变化时,确定数据库中是否增加针对上述赋值对象的第二数据模型。如果是,则建立第一数据模型和第二数据模型之间的关联关系。可选地,上述业务对象属于第一类型,上述赋值对象属于第二类型。元模型文件还包括:关联属性的信息。在上述获取预设关联关系属性的赋值对象之后,上述方法还包括:确定元模型文件中是否存在第一关联属性的信息,第一关联属性用于表征第一类型相对于第二类型存在关联关系。如果是,则在数据库中查找针对上述赋值对象的第二数据模型。可选地,第一数据模型还包括:第一关联属性和第一关联属性的取值内容。第二数据模型还包括:第二关联属性和第二关联属性的取值内容,第二关联属性用于表征第二类型相对于所述第一类型存在关联关系。上述建立第一数据模型和第二数据模型之间的关联关系包括:将上述赋值对象添加至第一数据模型的第一关联属性的取值内容中,并且将上述业务对象添加至第二数据模型的第二关联属性的取值内容中。可选地,上述在数据库中查找针对上述赋值对象的第二数据模型包括:对于数据库中的每个数据模型,利用模糊匹配或正则表达式对上述赋值对象和上述数据模型的名称属性进行匹配。如果匹配成功,则确定该数据模型为第二数据模型。可选地,上述方法还包括:在上述建立第一数据模型和第二数据模型之间的关联关系之后,将第一数据模型中的预设关联关系属性的取值内容置为空。可选地,上述获取第一数据模型中的预设关联关系属性的赋值对象包括:监测针对第一数据模型中的预设关联关系属性的赋值操作。并且基于该赋值操作,获取赋值对象。可选地,上述配置元模型文件包括:在已有元模型文件的基础上,增加预设关联关系属性的信息。本公开的另一方面提供了一种用于计算机系统的业务建模方法,包括:配置模块、建模模块、赋值模块和关联模块。配置模块用于配置元模型文件,其中元模型文件包括:预设关联关系属性的信息。建模模块用于基于所述元模型文件,在数据库中构建针对业务对象的第一数据模型,第一数据模型包括:预设关联关系属性。赋值模块用于获取第一数据模型中的预设关联关系属性的赋值对象。关联模块用于当数据库中存在针对赋值对象的第二数据模型时,建立第一数据模型和第二数据模型之间的关联关系,以使第一数据模型的业务数据和第二数据模型的业务数据之间关联存储。本公开的另一方面提供了一种计算机系统,包括:存储器、至少一个处理器及存储在存储器上并可在处理器上运行的计算机程序,处理器执行计算机程序时用于实现如上所述的方法。本公开的另一方面提供了一种计算机可读存储介质,存储有计算机可执行指令,该指令在被执行时用于实现如上所述的方法。本公开的另一方面提供了一种计算机程序,所述计算机程序包括计算机可执行指令,该指令在被执行时用于实现如上所述的方法。根据本公开的实施例,通过在配置元模型文件时增加预设关联关系属性的信息,使得基于元模型文件所构建的第一数据模型可以具有预设关联关系属性。在获取到符合模型关联期望的针对该预设关联关系属性的赋值对象后,自动化地基于该赋值对象在数据库中查找相应的第二数据模型,从而建立第一数据模型和第二数据模型之间的关联关系。针对模型之间的关联期望可以根据实际业务场景和应用系统架构的变化而随时动态变化,发生变化时也无需对已配置好的元模型文件进行更改,可以便捷高效地进行模型之间的关联,无需建模人员人为地进行监测和配置,提高效率和准确率。附图说明为了更完整地理解本公开及其优势,现在将参考结合附图的以下描述,其中:图1示意性示出了根据本公开实施例的应用业务建模方法和装置的示例性系统架构;图2示意性示出了根据本公开实施例的用于计算机系统的业务建模方法的流程图;图3示意性示出了根据本公开实施例的业务领域类型的数据模型的示例图;图4示意性示出了根据本公开实施例的实体类型的数据模型的示例图;图5示意性示出了根据本公开另一实施例的业务领域类型的数据模型的示例图;图6示意性示出了根据本公开另一实施例的实体类型的数据模型的示例图;图7示意性示出了根据本公开实施例的业务领域类型的具体数据模型的示例图;图8示意性示出了根据本公开实施例的实体类型的具体数据模型的示例图;图9示意性示出了根据本公开另一实施例的业务领域类型的具体数据模型的示例图;图10示意性示出了根据本公开另一实施例的实体类型的具体数据模型的示例图;图11根据本公开另一实施例的用于计算机系统的业务建模方法的示例流程图;图12示意性示出了根据本公开另一实施例的业务领域类型的具体数据模型的示例图;图13示意性示出了根据本公开另一实施例的业务领域类型的具体数据模型的示例图;图14示意性示出了根据本公开另一实施例的实体类型的具体数据模型的示例图;图15示意性示出了根据本公开实施例的用于计算机系统的业务建模装置的框图;以及图16示意性示出了根据本公开实施例的计算机系统的框图。具体实施方式以下,将参照附图来描述本公开的实施例。但是应该理解,这些描述只是示例性的,而并非要限制本公开的范围。在下面的详细描述中,为便于解释,阐述了许多具体的细节以提供对本公开实施例的全面理解。然而,明显地,一个或多个实施例在没有这些具体细节的情况下也可以被实施。此外,在以下说明中,省略了对公知结构和技术的描述,以避免不必要地混淆本公开的概念。在此使用的术语仅仅是为了描述具体实施例,而并非意在限制本公开。在此使用的术语“包括”、“包含”等表明了所述特征、步骤、操作和/或部件的存在,但是并不排除存在或添加一个或多个其他特征、步骤、操作或部件。在此使用的所有术语(包括技术和科学术语)具有本领域技术人员通常所理解的含义,除非另外定义。应注意,这里使用的术语应解释为具有与本说明书的上下文相一致的含义,而不应以理想化或过于刻板的方式来解释。在使用类似于“a、b和c等中至少一个”这样的表述的情况下,一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如,“具有a、b和c中至少一个的系统”应包括但不限于单独具有a、单独具有b、单独具有c、具有a和b、具有a和c、具有b和c、和/或具有a、b、c的系统等)。在使用类似于“a、b或c等中至少一个”这样的表述的情况下,一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如,“具有a、b或c中至少一个的系统”应包括但不限于单独具有a、单独具有b、单独具有c、具有a和b、具有a和c、具有b和c、和/或具有a、b、c的系统等)。本公开的实施例提供了一种用于计算机系统的业务建模方法、装置、计算机系统以及介质。该方法可以包括元模型配置过程、模型构建过程、赋值获取过程和查找关联过程。在元模型配置过程中,配置元模型文件,该元模型文件可以包括预设关联关系属性的信息。在模型构建过程,基于元模型文件,在数据库中构建针对业务对象的第一数据模型,第一数据模型可以包括上述预设关联关系属性。在赋值获取过程来获取期望与第一数据模型建立关联的信息,即获取第一数据模型中的预设关联关系属性的赋值对象。从而在数据库中可以查找针对该赋值对象的第二数据模型,当数据库中存在针对该赋值对象的第二数据模型时,建立第一数据模型和第二数据模型之间的关联关系,以使第一数据模型的业务数据和第二数据模型的业务数据之间关联存储。图1示意性示出了根据本公开实施例的可以应用业务建模方法和装置的示例性系统架构100。需要注意的是,图1所示仅为可以应用本公开实施例的系统架构的示例,以帮助本领域技术人员理解本公开的技术内容,但并不意味着本公开实施例不可以用于其他设备、系统、环境或场景。如图1所示,根据该实施例的系统架构100可以包括终端设备101、102、103,网络104和服务器/服务器集群105。网络104用以在终端设备101、102、103和服务器/服务器集群105之间提供通信链路的介质。网络104可以包括各种连接类型,例如有线、无线通信链路或者光纤电缆等等。终端设备101、102、103上可以安装有各种客户端应用,例如业务建模工具(仅为示例)。终端设备101、102、103可以通过各种客户端应用与服务器/服务器集群105进行交互,以向服务器/服务器集群105发送各种请求或接收服务器/服务器集群105返回的结果。终端设备101、102、103可以是各种电子设备,包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。服务器服务器/服务器集群105是可以提供各种服务支持的后台管理服务器或服务器集群(仅为示例)。后台管理服务器可以对接收到的用户请求等数据进行分析等处理,并将处理结果(例如根据用户请求获取或生成的网页、信息、或数据等)反馈给终端设备。需要说明的是,本公开实施例所提供的业务建模方法一般可以由服务器/服务器集群105执行。相应地,本公开实施例所提供的业务建模装置一般可以设置于服务器/服务器集群105中。本公开实施例所提供的业务建模方法也可以由不同于服务器/服务器集群105且能够与终端设备101、102、103和/或服务器/服务器集群105通信的服务器或服务器集群执行。相应地,本公开实施例所提供的业务建模装置也可以设置于不同于服务器/服务器集群105且能够与终端设备101、102、103和/或服务器/服务器集群105通信的服务器或服务器集群中。应该理解,图1中的终端设备、网络和服务器/服务器集群的数目仅仅是示意性的。根据实际需要,可以具有任意数目的终端设备、网络和服务器/服务器集群。随着数字银行信息化的发展,商业银行需要了解各行各业的科技发展和业务需求,获取大量的业务数据,设计各种各样的业务场景和应用系统架构,来为企业、个人等客户提供更好的服务。例如,建立架构管控平台系统,通过在架构管理平台系统中管理和分析业务流程和应用系统架构的设计,在不同的业务或it服务之间建立关联关系来指导工作,确保完整的业务流程或者系统建设具有整体性和协调性。具体地,可以通过在系统中针对各种业务场景和应用系统架构进行建模,随着业务的动态扩增或变化不断建模并调整数据模型之间的关联关系,来满足越来越多的业务服务场景和新的应用系统的规划设计需求。目前,无论是业务研发人员还是软件开发人员均在架构管理平台系统中进行数据建模。当需要建立不同数据模型之间的关联关系时,通常通过人工查找需要进行关联的数据模型并手动进行配置。在数据量庞大以及数据模型之间的关联关系比较复杂的情况下,上述方式不仅工作效率低下,而且可能会出现遗漏或者出错的情况,从而影响了整体建模的成果。本公开实施例提供了一种用于计算机系统的业务建模方法,以实现架构管理平台系统中数据模型(model)的自动化构建和关联。下面对该方法的实施过程进行说明,应注意,以下方法中各个操作的序号仅作为该操作的表示以便描述,而不应被看作表示该各个操作的执行顺序。除非明确指出,否则该方法不需要完全按照所示顺序来执行。图2示意性示出了根据本公开实施例的用于计算机系统的业务建模方法的流程图。其中计算机系统可以是上文提到的架构管理平台系统,图2所示的方法可以应用于该计算机系统的各种计算设备。如图2所示,该方法可以包括以下操作s201~s204。在操作s201,配置元模型(metamodel)文件。其中,所配置的元模型文件可以包括:预设关联关系属性的信息。除预设关联关系属性的信息之外,所配置的元模型文件根据需要还可以包括一个或多个其他属性的信息。示例性地,在架构管理平台系统中,建模人员可以基于元模型技术进行数据建模。元模型的定义,即模型的模型,对一个模型的属性进行初始化定义。如上文中的预设关联关系属性的信息是对预设关联关系属性的初始化定义。通常情况下,在进行元模型文件的配置时,例如可以在eclipse框架平台上安装amaterasuml插件,通过绘图的方式来进行绘制技术元模型。技术元模型的内容主要是各字段名称以及相对应的功能,供后端逻辑判断,请参阅表1。表1表1仅示例性地列出了几个字段名称,在其他例子中可以根据需要对上述字段名称进行扩展或删减,这些字段名称用于从不同维度反映元模型针对属性初始化定义的信息。根据实际业务场景或应用系统架构中各种业务对象的各种属性的信息,完成上述各种字段名称的配置和设定,然后生成元模型文件,例如可表示为后缀为.ecore的文件。配置生成的元模型文件可以用于进行后续的数据模型的构建、升级等。为方便说明,元模型文件定义的内容可以转换成表格的形式来呈现,如表2。表2表2示例性地展示了元模型文件所包括的多个属性的信息。例如包括:数据名称(name)、目的(aimdesc)、定义(defdesc)、范围(scaledesc)、业务领域关联的价值流(businessdomainrvalueflow)和业务领域关联的实体(businessdomainrentity)等属性。每个属性的信息包括class_name字段信息、attr_name字段信息、ch_name字段信息、attr_seq字段信息、editable字段信息、visible字段信息、others字段信息等。每个属性通过class_name字段的取值来定义所属的数据模型类型,本例中多个属性均属于业务领域(businessdomain)这一数据模型类型。多个属性之间通过attr_seq字段的取值进行大小比较来排序。每个属性通过editable字段的取值定义属性是否可编辑,通过visible字段的取值定义属性是否可见、以及通过others字段的取值定义属性可存储内容的最大长度等。根据本公开的实施例,在配置元模型文件时,可以根据需要随时在元模型文件中配置预设关联关系属性的信息。例如,在如表2所示的元模型文件基础上增加多一行预设关联关系属性,该预设关联关系属性的信息可以包括:class_name字段信息、attr_name字段信息、ch_name字段信息、attr_seq字段信息、editable字段信息、visible字段信息、others字段信息等。元模型文件中的预设关联关系属性的信息如表3所示。表3如表3所示,示例性地,该预设关联关系属性通过class_name字段的取值来控制所属的数据模型类型,本例中多个属性均属于实体(entity)这一数据模型类型。该预设关联关系属性通过attr_name字段的取值定义英文名称为prereference。该预设关联关系属性通过attr_seq字段的取值定义优先级为9。该预设关联关系属性通过attr_seq字段的取值定义优先级为9。该预设关联关系属性通过editable字段的取值定义其可编辑。该预设关联关系属性通过visible字段的取值定义其可见。继续参考图2,在操作s202,基于元模型文件,在数据库中构建针对业务对象的第一数据模型。示例性地,基于上文所说明的元模型文件中的属性信息,可以构建各种类型的数据模型。在期望构建针对业务对象的第一数据模型时,需要确定业务对象所属的类型,在元模型文件中查找数据模型类型与该类型相匹配的属性,基于所查找到的属性的信息来构建针对该业务对象的第一数据模型。例如,当业务对象为a,a所属的类型为业务领域时,在元模型文件中查找class_name字段的取值为“businessdomain”的属性,并基于业务对象a的相关业务数据对所查找到的属性进行赋值,从而根据各属性的取值内容和信息构建针对该业务对象a的第一数据模型。如果查找到的属性中包括预设关联关系属性,则所构建的第一数据模型中也包括该预设关联关系属性。由于预设关联关系属性是根据需要动态配置的,其所表征的关联关系会根据需要动态变化,可以设置预设关联关系属性的初始取值内容为空。接着,在操作s203,获取第一数据模型中的预设关联关系属性的赋值对象。在操作s204,当数据库中存在针对该赋值对象的第二数据模型时,建立第一数据模型和第二数据模型之间的关联关系,以使第一数据模型的业务数据和第二数据模型的业务数据之间关联存储。在操作s203~s204中,例如,当期望建立针对b的数据模型与上文中针对业务对象a之间的关联时,建模人员可以对第一数据模型中的预设关联关系属性进行赋值,预设关联关系属性的赋值对象为b。在数据库中查找针对赋值对象b的第二数据模型。如果存在,则可以建立针对业务对象a的第一数据模型和针对赋值对象b的第二数据模型之间的关联关系,以使这两个数据模型中的业务数据能够关联地进行存储、变化,无需建模人员手动进行关联配置。其中,第二数据模型的构建过程与上文中第一数据模型的构建过程同理,在此不再赘述。本领域技术人员可以理解,通过在配置元模型文件时增加预设关联关系属性的信息,使得基于元模型文件所构建的第一数据模型可以具有预设关联关系属性。在获取到符合模型关联期望的针对该预设关联关系属性的赋值对象后,自动化地基于该赋值对象在数据库中查找相应的第二数据模型,从而建立第一数据模型和第二数据模型之间的关联关系。针对模型之间的关联期望可以根据实际业务场景和应用系统架构的变化而随时动态变化,发生变化时也无需对已配置好的元模型文件进行更改,可以便捷高效地进行模型之间的关联,无需建模人员人为地进行监测和配置,提高效率和准确率。图3示意性示出了根据本公开实施例的业务领域类型的数据模型的示例图。如图3所示,本例中业务对象所属的类型为业务领域类型,从元模型文件中获取class_name字段的取值为“businessdomain”的属性信息并进行具体建模。一个初始完整的业务领域类型的数据模型具有以下属性:目的、定义、范围、关联的价值流以及关联的实体。其中,目的、定义和范围均属于普通属性,关联的价值流和关联的实体属于关联属性。图4示意性示出了根据本公开实施例的实体类型的数据模型的示例图。如图4所示,本例中业务对象所述的类型为实体类型,从元模型文件中获取class_name字段的取值为“entity”的属性信息并进行具体建模。一个初始完整的实体类型的数据模型具有以下属性:目的、定义、范围、关联的业务对象和关联的业务领域。其中,目的、定义和范围均属于普通属性,关联的业务对象和关联的业务领域属于关联属性。可以理解,在构建上述图3和图4所示的数据模型时,元模型文件中未包含属于业务领域类型的预设关联关系属性和属于实体类型的预设关联关系属性,故图3和图4所示的数据模型均未包括预设关联关系属性。示例性地,当在元模型文件中配置属于业务领域类型的预设关联关系属性后,基于元模型文件所构建的数据模型如图5所示。与图3所示的数据模型相比,图5所示的数据模型增加了预设关联关系属性,该属性为普通属性。示例性地,当在元模型文件中配置属于实体类型的预设关联关系属性(例如上文中表3所示的预设关联关系属性)后,基于元模型文件所构建的数据模型如图6所示。与图4所示的数据模型相比,图6所示的数据模型增加了预设关联关系属性,该属性为普通属性。根据本公开的实施例,例如可以将图5或图6所示的数据模型作为操作s220所构建的第一数据模型。本领域技术人员可以理解,根据实际情况的不同,业务对象可以有多种,业务对象所属的类型可以有多种,不仅限于上文举例说明的业务领域类型和实体类型。其他各种类型的数据模型的构建过程与上述同理,第一数据模型可以是各种类型的数据模型,在此不做限制。进一步地,在构建数据模型的过程中,可以根据实际业务数据对数据模型中的属性进行赋值,以得到具体的数据模型。图7示意性示出了根据本公开实施例的业务领域类型的具体数据模型的示例图。如图7所示,本例中业务对象为个人存款,该业务对象所属的类型为业务领域类型。与图3所示的数据模型相比,对目的、定义、范围、关联的价值流以及关联的实体这些属性均根据实际业务数据进行赋值。例如,目的属性的取值内容为“通过银行信用获取客户资金,并以此作为营运的基础,实现筹集资金、扩大盈利能力的经营目标”。定义属性的取值内容为“个人客户在保留所有权条件下把资金或货币暂时转让与银行,并可以随时或按约定时间支取款项并获得利息收益的一种金融行为或活动”。范围属性的取值内容为“涉及的客户:个人客户”。关联的价值流属性的取值内容包括:“制定个人存款制度”、“制定个人存款计划”和“提供资金服务”。关联的实体属性的取值内容包括:“账户”、“余额”和“币种”。图8示意性示出了根据本公开实施例的实体类型的具体数据模型的示例图。如图8所示,本例中业务对象为协议条件,该业务对象所属的类型为实体类型。与图4所示的数据模型相比,对目的、定义、范围、关联的业务对象以及关联的业务领域这些属性均根据实际业务数据进行赋值。例如,目的属性的取值内容为“对业务流程进行控制,提供差异化的客户服务”。定义属性的取值内容为“可售产品销售给客户后,银行与客户约定的,关于使用产品过程中流程与控制的相关协议条款”。范围属性的取值内容为“包含可协商的产品条件:不包含不可协商的产品条件(在产品条件中体现)”。关联的业务对象属性的取值内容为“产品协议”。关联的业务领域属性的取值内容包括:“理财产品”、“信用卡”和“个人账户”。示例性地,当在元模型文件中配置属于业务领域类型的预设关联关系属性后,基于元模型文件所构建的具体数据模型如图9所示。与图7所示的具体数据模型相比,图9所示的具体数据模型增加了预设关联关系属性,该属性的初始取值内容为空。示例性地,当在元模型文件中配置属于实体类型的预设关联关系属性(例如上文中表3所示的预设关联关系属性)后,基于元模型文件所构建的具体数据模型如图10所示。与图8所示的具体数据模型相比,图10所示的具体数据模型增加了预设关联关系属性,该属性的初始取值内容为空。图11根据本公开另一实施例的用于计算机系统的业务建模方法的示例流程图。如图11所示,该方法可以包括操作s1101~操作s1108。在操作s1101,配置元模型文件,以使元模型文件包括预设关联关系属性的信息。示例性地,本操作s1101可以在已有元模型文件的基础上,增加预设关联关系属性的信息。例如在如上文中表2所示的元模型文件的基础上增加如上文中表3所示的预设关联关系属性的信息。在操作s1102,基于元模型文件构建针对业务对象的第一数据模型。由于元模型文件中包括与业务对象所属的类型对应的预设关联关系属性的信息,因此所构建业务对象的第一数据模型包括预设关联关系属性。模型构建过程与上文中图3~图10所示模型的构建过程同理,重复的部分不再赘述。示例性地,元模型的配置后可支持关系型数据库(例如mysql数据库)和非关系型数据库(例如mongodb)进行数据模型的构建。下面以mongodb数据库存储进行示例性说明。mongodb数据库本身是属于面向集合存储,可以按照集合(collection)存储文件内容,并且可以对任意的数据格式,如json、txt或二进制流文件等进行存储。例如如图3~图10所示的任一数据模型中各属性以及各属性的取值内容可以通过键-值(key-value)对的形式存储在一个集合中。在操作s1103,获取针对第一数据模型中预设关联关系属性的赋值对象。例如,经过模型构建过程,例如第一数据模型如图9所示,预设关联关系属性的初始取值内容为空。根据本公开的实施例,可以监测针对第一数据模型中的预设关联关系属性的赋值操作。当监测到发生针对第一数据模型中的预设关联关系属性的赋值操作时,基于该赋值操作,获取赋值对象。针对图9所示的第一数据模型中的预设关联关系属性进行赋值后,得到如图12所示的第一数据模型,其中预设关联关系属性的赋值对象为:“预设实体:协议条件”,协议条件所属的类型为实体。本例中,当期望建立图8或图10所示的针对协议条件的第二数据模型与图9所示的针对个人存款的第一数据模型之间的关联关系时,可以对第一数据模型的预设关联关系属性进行赋值操作。可以理解,在期望建立任意两个数据模型之间的关联关系时,均可按照上述原理对其中一个数据模型的预设关联关系属性进行相应的赋值操作。在操作s1104,对所获取的赋值对象进行校验,当校验通过时执行操作s1105。示例性地,上述业务对象属于第一类型,上述赋值对象属于第二类型。元模型文件还包括:关联属性的信息。在上述获取预设关联关系属性的赋值对象之后,根据本公开实施例的业务建模方法还可以包括:确定元模型文件中是否存在第一关联属性的信息,第一关联属性用于表征第一类型相对于第二类型存在关联关系。如果是,则在数据库中查找针对上述赋值对象的第二数据模型。例如,在表2所示的元模型文件中,业务领域关联的价值流为关联属性,业务领域关联的实体为关联属性。沿用上文的例子,业务对象为个人存款,属于业务领域类型。赋值对象为协议条件,属于实体类型。故在元模型文件中查找业务领域类型相对于实体类型的第一关联属性的信息,即业务领域关联的实体。如果查找到,则表示业务领域类型与实体类型之间可以进行关联,校验通过。如果未查找到,则表示业务领域类型与实体类型之间不可以进行关联,校验不通过。在操作s1105,确定数据库中是否存在针对赋值对象的第二数据模型。如果是,则执行操作s1106,如果否,则执行操作s1107。其中,查询匹配的方式有很多种,示例性地,上述在数据库中查找针对上述赋值对象的第二数据模型的过程可以包括:对于数据库中的每个数据模型,利用模糊匹配或正则表达式对上述赋值对象和上述数据模型的名称属性进行匹配。如果匹配成功,则确定该数据模型为第二数据模型。上述操作s1103~s1105涉及对于第一数据模型的监测解析过程。例如可以包括:每次在数据变化保存的时候,可以监控“prereference”这个字段是否发生了变更。如图12所示的例子中在保存数据信息时,系统通过前后数据对比发现多了新的一行,内容为“prereference”:[“entity”:“协议条件”],搜索到键值对的键是entity,表示赋值对象所属的类型为实体类型。然后对所配置的元模型文件进行核实,发现存在“businessdomainrentity”字段(相当于上文所述的第一关联属性),即该属性确实定义了业务领域类型数据模型能够关联了实体类型数据模型,则校验通过。接着,根据键值对的值是协议条件,然后开始去数据库中进行查询匹配,在mongodb中可以通过模糊匹配或者正则表达式的方式很快就能查到数据库是否存在协议条件这个实体模型具体数据。在操作s1106,建立第一数据模型和第二数据模型之间的关联关系。示例性地,第一数据模型还可以包括:第一关联属性和第一关联属性的取值内容。第二数据模型还可以包括:第二关联属性和第二关联属性的取值内容,第二关联属性用于表征第二类型相对于所述第一类型存在关联关系。上述建立第一数据模型和第二数据模型之间的关联关系的过程可以包括:将赋值对象添加至第一数据模型的第一关联属性的取值内容中,并且将业务对象添加至第二数据模型的第二关联属性的取值内容中。例如,在期望建立针对个人存款的数据模型和针对协议条件的数据模型之间的关联关系时,第一数据模型如图9所示,根据关联期望对第一数据模型中的预设关联关系属性进行赋值,赋值对象为协议条件,得到如图12所示的第一数据模型。从数据库中查找到针对协议条件的第二数据模型如图10所示。个人存款属于业务领域类型,协议条件属于实体类型。第一数据模型包括第一关联属性:关联的实体。该第一关联属性的取值内容包括:“账户”、“余额”和“币种”。第二数据模型包括第二关联属性:关联的业务领域。该第二关联属性的取值内容包括:“理财产品”、“信用卡”和“个人账户”。在本操作s1106中,将协议条件添加至第一数据模型的第一关联属性的取值内容中,以得到如图13所示的第一数据模型。并且将个人存款添加至第二数据模型的第二关联属性的取值内容中,以得到如图14所示的第二数据模型。如图13~14所示,已建立起针对个人存款的第一数据模型和针对协议条件的第二数据模型之间的关联关系,二者中的任一发生数据变化时,另一个也会基于关联关系随之变化。根据本公开的实施例,在上述建立第一数据模型和第二数据模型之间的关联关系之后,重新将第一数据模型中的预设关联关系属性的取值内容置为空。在操作s1107,对数据库进行监测。在操作s1108,当监测到数据库的存储内容发生变化时,在确定数据库中增加针对上述赋值对象的第二数据模型时,建立第一数据模型和第二数据模型之间的关联关系。该建立关联关系的过程与上文中操作s1106同理,在此不再赘述。例如,沿用上文中的例子,上述操作s1106~s1108涉及两种情况。1)针对该(实体)协议条件的第二数据模型已经存在;2)针对该(实体)协议条件的第二数据模型不存在,但是未来会被创建。情况1,因为已经存在该数据模型,在获取到例如预设关联关系的赋值对象为“预设实体:协议条件”后。通过上述算法,系统会进行数据模型之间的关联操作。当再次查看第一数据模型和第二数据模型时,如图13和图14所示,针对个人存款的数据模型中关联的实体下多了一条数据:协议条件;以及针对协议条件的数据模型中关联的业务领域也多了一条数据:个人存款。情况2,由于不存在该数据模型,故无法查询到该条数据模型的具体信息内容,当前无法进行关联,但此时作为预设记录保存在数据信息中。当业务研发人员完成了建模讨论并确定进行实体建模后,在创建针对(实体)协议条件的数据模型时,由于通过上述算法,系统之前已经进行预设记录和监控,当发现创建的数据模型的内容与之前预设的模型是同样的类型(同属实体类型模型)且名称相同时,该(实体)协议条件的数据模型被创建后完成保存的那一刻,系统会执行该算法,自动创建针对(实体)协议条件的第二数据模型与针对(业务领域)个人存款的第一数据模型之间的关联关系,如图13和图14所示,针对个人存款的数据模型中关联的实体下多了一条数据:协议条件;以及针对协议条件的数据模型中关联的业务领域也多了一条数据:个人存款。当完成建立关联关系后,针对个人存款的数据模型在mongodb数据库的例子中数据结构如下:{"class_name":"businessdomain","name":"个人存款","aimdesc":"通过银行信用获取客户资金,并以此作为营运的基础,实现筹集资金,扩大盈利能力的经营目标。","defdesc":"个人客户在保留所有权条件下把资金或货币暂时转让与银行,并可以随时或按约定时间支取款项并获得利息收益的一种金融行为或活动。","scaledesc":"涉及的客户:个人客户","businessdomainrvalueflow":["制定个人存款制度","制定个人存款计划","提供资金服务"],"businessdomainrentity":["账户","余额","币种","协议条件"],"prereference":[]}。通过以上数据结构可以看出,“businessdomainrentity”字段的取值内容所对应的数组多了一条新的数据:协议条件,即表明建立关联关系成功,此时“prereference”字段的取值内容被清空,以便下一次设置使用。根据本公开实施例,由计算机系统执行上述过程,例如可以设置“prereference”的数据类型为数组形式便于存储大量的预设关联关系的内容便于系统进行批量解析处理。故不需要建模人员再去手动一个个数据去对不同的数据进行关联,从而达到自动化匹配关联的目的来提高效率。其次在数据还尚未存在时可以预先提前定制好,减少了滞后性,并可以减少建模人员发生遗漏或错误等情况,保证了建模过程和模型关联过程中的数据准确性。上述例子引用了业务领域和实体两种类型的数据模型示例性地说明本公开的实施方式,本公开的实施例方式可以应用于各种建模场景中需要进行数据同步关联使用的情况,上述例子不对本公开的应用场景造成限制。基于上文中各实施例,本公开实施例所提供的业务建模方法将通过元模型的技术,以及系统自动检索和关联存储的规则来克服过去建模人员进行建模时出现的效率性和准确性的问题,可以获得以下有益效果:1)通过预先在元模型中配置的预设关联关系属性,在需要进行数据关联时即可通过对于预设关联关系属性的设置来实现数据模型之间的关联,无需建模人员对一个个数据手动建立关系,减少了模型关联滞后性,且对建模人员有更加良好的工作体验,也更好体现了系统的易用性;2)通过计算机系统对数据之间自动进行关联,减少了建模人员的发生遗漏或者出错的情况,保证了建模成果的正确性和完整性;3)可通过自动批量建立数据之间的关联关系,尤其在数据量庞大和关系复杂的情况下,能够大大减少建模人员的工作时间从而提升工作效率;4)适用于各种具有数据模型关联场景的建模,具有普遍适用性。图15示意性示出了根据本公开实施例的用于计算机系统的业务建模装置的框图。如图15所示,该用于计算机系统的业务建模装置1500可以包括:配置模块1510、建模模块1520、赋值模块1530和关联模块1540。配置模块1510用于配置元模型文件,其中元模型文件包括:预设关联关系属性的信息。建模模块1520用于基于所述元模型文件,在数据库中构建针对业务对象的第一数据模型,第一数据模型包括:预设关联关系属性。赋值模块1530用于获取第一数据模型中的预设关联关系属性的赋值对象。关联模块1540用于当数据库中存在针对赋值对象的第二数据模型时,建立第一数据模型和第二数据模型之间的关联关系,以使第一数据模型的业务数据和第二数据模型的业务数据之间关联存储。需要说明的是,装置部分实施例中各模块/单元/子单元等的实施方式、解决的技术问题、实现的功能、以及达到的技术效果分别与方法部分实施例中各对应的步骤的实施方式、解决的技术问题、实现的功能、以及达到的技术效果相同或类似,在此不再赘述。根据本公开的实施例的模块、子模块、单元、子单元中的任意多个、或其中任意多个的至少部分功能可以在一个模块中实现。根据本公开实施例的模块、子模块、单元、子单元中的任意一个或多个可以被拆分成多个模块来实现。根据本公开实施例的模块、子模块、单元、子单元中的任意一个或多个可以至少被部分地实现为硬件电路,例如现场可编程门阵列(fpga)、可编程逻辑阵列(pla)、片上系统、基板上的系统、封装上的系统、专用集成电路(asic),或可以通过对电路进行集成或封装的任何其他的合理方式的硬件或固件来实现,或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者,根据本公开实施例的模块、子模块、单元、子单元中的一个或多个可以至少被部分地实现为计算机程序模块,当该计算机程序模块被运行时,可以执行相应的功能。例如,配置模块1510、建模模块1520、赋值模块1530和关联模块1540中的任意多个可以合并在一个模块中实现,或者其中的任意一个模块可以被拆分成多个模块。或者,这些模块中的一个或多个模块的至少部分功能可以与其他模块的至少部分功能相结合,并在一个模块中实现。根据本公开的实施例,配置模块1510、建模模块1520、赋值模块1530和关联模块1540中的至少一个可以至少被部分地实现为硬件电路,例如现场可编程门阵列(fpga)、可编程逻辑阵列(pla)、片上系统、基板上的系统、封装上的系统、专用集成电路(asic),或可以通过对电路进行集成或封装的任何其他的合理方式等硬件或固件来实现,或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者,配置模块1510、建模模块1520、赋值模块1530和关联模块1540中的至少一个可以至少被部分地实现为计算机程序模块,当该计算机程序模块被运行时,可以执行相应的功能。图16示意性示出了根据本公开实施例的适于实现上文描述的方法的计算机系统的框图。图16示出的计算机系统仅仅是一个示例,不应对本公开实施例的功能和使用范围带来任何限制。如图16所示,根据本公开实施例的计算机系统1600包括处理器1601,其可以根据存储在只读存储器(rom)1602中的程序或者从存储部分1608加载到随机访问存储器(ram)1603中的程序而执行各种适当的动作和处理。处理器1601例如可以包括通用微处理器(例如cpu)、指令集处理器和/或相关芯片组和/或专用微处理器(例如,专用集成电路(asic)),等等。处理器1601还可以包括用于缓存用途的板载存储器。处理器1601可以包括用于执行根据本公开实施例的方法流程的不同动作的单一处理单元或者是多个处理单元。在ram1603中,存储有系统1600操作所需的各种程序和数据。处理器1601、rom1602以及ram1603通过总线1604彼此相连。处理器1601通过执行rom1602和/或ram1603中的程序来执行根据本公开实施例的方法流程的各种操作。需要注意,所述程序也可以存储在除rom1602和ram1603以外的一个或多个存储器中。处理器1601也可以通过执行存储在所述一个或多个存储器中的程序来执行根据本公开实施例的方法流程的各种操作。根据本公开的实施例,系统1600还可以包括输入/输出(i/o)接口1605,输入/输出(i/o)接口1605也连接至总线1604。系统1600还可以包括连接至i/o接口1605的以下部件中的一项或多项:包括键盘、鼠标等的输入部分1606;包括诸如阴极射线管(crt)、液晶显示器(lcd)等以及扬声器等的输出部分1607;包括硬盘等的存储部分1608;以及包括诸如lan卡、调制解调器等的网络接口卡的通信部分1609。通信部分1609经由诸如因特网的网络执行通信处理。驱动器1610也根据需要连接至i/o接口1605。可拆卸介质1611,诸如磁盘、光盘、磁光盘、半导体存储器等等,根据需要安装在驱动器1610上,以便于从其上读出的计算机程序根据需要被安装入存储部分1608。根据本公开的实施例,根据本公开实施例的方法流程可以被实现为计算机软件程序。例如,本公开的实施例包括一种计算机程序产品,其包括承载在计算机可读存储介质上的计算机程序,该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中,该计算机程序可以通过通信部分1609从网络上被下载和安装,和/或从可拆卸介质1611被安装。在该计算机程序被处理器1601执行时,执行本公开实施例的系统中限定的上述功能。根据本公开的实施例,上文描述的系统、设备、装置、模块、单元等可以通过计算机程序模块来实现。本公开还提供了一种计算机可读存储介质,该计算机可读存储介质可以是上述实施例中描述的设备/装置/系统中所包含的;也可以是单独存在,而未装配入该设备/装置/系统中。上述计算机可读存储介质承载有一个或者多个程序,当上述一个或者多个程序被执行时,实现根据本公开实施例的方法。附图中的流程图和框图,图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上,流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分,上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意,在有些作为替换的实现中,方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如,两个接连地表示的方框实际上可以基本并行地执行,它们有时也可以按相反的顺序执行,这依所涉及的功能而定。也要注意的是,框图或流程图中的每个方框、以及框图或流程图中的方框的组合,可以用执行规定的功能或操作的专用的基于硬件的系统来实现,或者可以用专用硬件与计算机指令的组合来实现。本领域技术人员可以理解,尽管已经参照本公开的特定示例性实施例示出并描述了本公开,但是本领域技术人员应该理解,在不背离所附权利要求及其等同物限定的本公开的精神和范围的情况下,可以对本公开进行形式和细节上的多种改变。因此,本公开的范围不应该限于上述实施例,而是应该不仅由所附权利要求来进行确定,还由所附权利要求的等同物来进行限定。当前第1页12当前第1页12
当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1