CN111858615A - 数据库表生成方法、系统、计算机系统和可读存储介质 - Google Patents

Abstract

本公开提供了一种数据库表生成方法、数据库表生成系统、计算机系统和计算机可读存储介质可用于大数据技术领域或其他领域。其中，该方法包括：获取业务实体模型涉及的业务实体信息，其中，业务实体信息包括业务实体标识符和第一属性信息；根据业务实体模型涉及的业务实体信息定义逻辑模型的逻辑实体信息，其中，逻辑实体信息包括逻辑实体标识符和第二属性信息；将逻辑实体标识符作为数据库表中的主键；以及根据第二属性信息为主键创建属性字段，以得到与逻辑实体标识符关联的数据库表。

Description

数据库表生成方法、系统、计算机系统和可读存储介质

技术领域

本公开大数据技术领域，更具体地，涉及一种数据库表生成方法、数据库表生成系统、计算机系统和计算机可读存储介质。

背景技术

随着数字化时代的快速发展，越来越多的应用类、实体类以及业务类信息需要通过数据的形式呈现，即企业级业务实体模型架构的最终落地需要通过数据库物理表结构的方式，也因此需要建设一套IT数据模型，通过生成数据库表，以适应数字化时代的管理需求。

在实现本公开构思的过程中，发明人发现相关技术中至少存在如下问题，由于应用类、实体类以及业务类信息出现的不确定性，伴随着该类信息的出现，即需要随时准备增加与之相关的数据库表，在该类信息数据关系繁杂时，也需要相应的建议具有对应关系的数据库表结构，导致数据库表随着外部信息的产生出现无限制且无规则的增长，不利于维护数据标准化，更不利于进行数据管理。

发明内容

有鉴于此，本公开提供了一种数据库表生成方法、数据库表生成系统、计算机系统和计算机可读存储介质。

本公开的一个方面提供了一种数据库表生成方法，包括：获取业务实体模型涉及的业务实体信息，其中，所述业务实体信息包括业务实体标识符和第一属性信息；根据所述业务实体模型涉及的业务实体信息定义逻辑模型的逻辑实体信息，其中，所述逻辑实体信息包括逻辑实体标识符和第二属性信息；将所述逻辑实体标识符作为数据库表中的主键；以及根据所述第二属性信息为所述主键创建属性字段，以得到与所述逻辑实体标识符关联的数据库表。

根据本公开的实施例，上述的数据库表生成方法还包括：获取业务实体模型涉及的第一关系实体信息，其中，所述第一关系实体信息包括不同的所述业务实体信息之间的关联关系；根据所述业务实体模型涉及的第一关系实体信息定义逻辑模型的第二关系实体信息，其中，所述第二关系实体信息包括不同的所述逻辑实体信息之间的关联关系；以及根据所述第二关系实体信息生成所述数据库表之间的关联关系。

根据本公开的实施例，根据所述业务实体模型涉及的业务实体信息定义逻辑模型的逻辑实体信息还包括：将所述业务实体模型中的多个所述业务实体标识符定义为所述逻辑模型中的一个所述逻辑实体标识符；和/或将所述业务实体模型中的一个所述业务实体标识符定义为所述逻辑模型中的多个所述逻辑实体标识符；和/或将所述业务实体模型中的多个所述第一属性信息定义为所述逻辑模型中的一个所述第二属性信息；和/或将所述业务实体模型中的一个所述第一属性信息定义为所述逻辑模型中的多个所述第二属性信息。

根据本公开的实施例，根据所述第二属性信息为所述主键创建属性字段还包括：获取所述逻辑模型中的与所述逻辑实体标识符相关的应用实施类属性信息；以及根据与所述逻辑实体标识符相关的应用实施类属性信息为所述主键创建属性字段。

根据本公开的实施例，根据所述第二属性信息为所述主键创建属性字段还包括：获取所述逻辑模型中的与所述逻辑实体标识符相关的冗余类属性信息；以及根据与所述逻辑实体标识符相关的冗余类属性信息为所述主键创建属性字段。

根据本公开的实施例，根据所述第二属性信息为所述主键创建属性字段还包括：获取所述逻辑模型中的与所述逻辑实体标识符相关的衍生类属性信息；以及根据与所述逻辑实体标识符相关的衍生类属性信息为所述主键创建属性字段。

根据本公开的实施例，上述的数据库表生成方法还包括：根据分库分表策略对所述逻辑模型中的所述第二属性信息进行分类；以及根据所述逻辑模型中的与所述逻辑实体标识符相关和分类结果为同一类的所述第二属性信息构建数据库表。

本公开的另一个方面提供了一种数据库表生成系统，包括：获取模块，用于获取业务实体模型涉及的业务实体信息，其中，所述业务实体信息包括业务实体标识符和第一属性信息；定义模块，用于根据所述业务实体模型涉及的业务实体信息定义逻辑模型的逻辑实体信息，其中，所述逻辑实体信息包括逻辑实体标识符和第二属性信息；主键生成模块，用于将与所述逻辑实体标识符相关作为数据库表中的主键；以及字段生成模块，用于根据所述第二属性信息为所述主键创建属性字段，以得到与所述逻辑实体标识符关联的数据库表。

本公开的另一方面提供了一种计算机系统，包括：一个或多个处理器；存储器，用于存储一个或多个程序，其中，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如上所述的方法。

本公开的另一方面提供了一种计算机可读存储介质，存储有计算机可执行指令，所述指令在被执行时用于实现如上所述的方法。

本公开的另一方面提供了一种计算机程序，所述计算机程序包括计算机可执行指令，所述指令在被执行时用于实现如上所述的方法。

根据本公开的实施例，通过采用了获取业务实体模型涉及的业务实体信息，其中，业务实体信息包括业务实体标识符和第一属性信息；根据业务实体模型涉及的业务实体信息定义逻辑模型的逻辑实体信息，其中，逻辑实体信息包括逻辑实体标识符和第二属性信息；将逻辑实体标识符作为数据库表中的主键；以及根据第二属性信息为主键创建属性字段，以得到与逻辑实体标识符关联的数据库表的技术手段，由于该方法是基于企业级业务架构指导下进行的数据库表的设计，所以至少部分地克服了数据库表无规则快速增长的技术问题，进而达到了基于企业级业务架构指导表结构设计、提高数据标准化水平和数据质量、优化数据合理布局以及提升数据使用效能等技术效果。

附图说明

通过以下参照附图对本公开实施例的描述，本公开的上述以及其他目的、特征和优点将更为清楚，在附图中：

图1示意性示出了根据本公开实施例的可以应用数据库表生成方法的示例性系统架构；

图2示意性示出了根据本公开实施例的数据库表生成方法的流程图；

图3示意性示出了根据本公开实施例的数据库表生成方法的另一流程图；

图4示意性示出了根据本公开实施例的根据业务实体信息定义逻辑实体信息的流程图；

图5示意性示出了根据本公开实施例的数据库表生成方法中第一类型属性字段的生成流程图；

图6示意性示出了根据本公开实施例的数据库表生成方法中第二类型属性字段的生成流程图；

图7示意性示出了根据本公开实施例的数据库表生成方法中第三类型属性字段的生成流程图；

图8示意性示出了根据本公开实施例的基于分库分表策略的数据库表生成方法的流程图；

图9示意性示出了根据本公开实施例的数据库表生成方法中业务类模型与IT数据类模型的关系示意图；

图10示意性示出了实现本公开实施例的数据库表生成方法的一种较为完整的实施方案；

图11示意性示出了根据本公开实施例的数据库表生成方法中设计D模型的示意图；

图12示意性示出了根据本公开实施例的数据库表生成系统的框图；以及

图13示意性示出了根据本公开实施例的适于实现上文中描述的数据库表生成方法的计算机系统的框图。

具体实施方式

以下，将参照附图来描述本公开的实施例。但是应该理解，这些描述只是示例性的，而并非要限制本公开的范围。在下面的详细描述中，为便于解释，阐述了许多具体的细节以提供对本公开实施例的全面理解。然而，明显地，一个或多个实施例在没有这些具体细节的情况下也可以被实施。此外，在以下说明中，省略了对公知结构和技术的描述，以避免不必要地混淆本公开的概念。

在此使用的术语仅仅是为了描述具体实施例，而并非意在限制本公开。在此使用的术语“包括”、“包含”等表明了所述特征、步骤、操作和/或部件的存在，但是并不排除存在或添加一个或多个其他特征、步骤、操作或部件。

在此使用的所有术语(包括技术和科学术语)具有本领域技术人员通常所理解的含义，除非另外定义。应注意，这里使用的术语应解释为具有与本说明书的上下文相一致的含义，而不应以理想化或过于刻板的方式来解释。

在使用类似于“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的系统等)。

为了适应数字化银行的发展要求，商业银行需要理解行业发展趋势，分析企业存在的威胁和机遇。在企业战略、目标、愿景指导下，通过建设企业级业务架构，指导全行的系统设计，确保各个系统的建设的整体性和协同性。在企业级业务架构指导下，通过系统性方法设计企业级业务实体模型，使用企业级结构化、标准化的语言为利益相关方提供了业务信息的逻辑视图，深度关注业务本质、逻辑结构和含义，展示、支撑商业银行战略意图和能力。由于企业级业务实体模型架构的最终落地是通过数据库表的方式实现的，因此需建设一套与业务架构对应的IT数据模型。

在实现本公开的过程中发明人发现传统的IT数据模型的设计，是根据业务信息的产生，直接从IT层面进行考虑，在进行数据标准化时，直接从数据库表层面实现，导致企业数据库表结构繁杂、增长过快，且不利于管理。

有鉴于此，本公开的实施例提供了一种数据库表生成方法、数据库表生成系统、计算机系统和计算机可读存储介质。该方法包括获取业务实体模型涉及的业务实体信息，其中，业务实体信息包括业务实体标识符和第一属性信息；根据业务实体模型涉及的业务实体信息定义逻辑模型的逻辑实体信息，其中，逻辑实体信息包括逻辑实体标识符和第二属性信息；将逻辑实体标识符作为数据库表中的主键；以及根据第二属性信息为主键创建属性字段，以得到与逻辑实体标识符关联的数据库表。

图1示意性示出了根据本公开实施例的可以应用数据库表生成方法的示例性系统架构100。需要注意的是，图1所示仅为可以应用本公开实施例的系统架构的示例，以帮助本领域技术人员理解本公开的技术内容，但并不意味着本公开实施例不可以用于其他设备、系统、环境或场景。

如图1所示，根据该实施例的系统架构100可以包括终端设备101、102、103，网络104和服务器105。网络104用以在终端设备101、102、103和服务器105之间提供通信链路的介质。网络104可以包括各种连接类型，例如有线和/或无线通信链路等等。

用户可以使用终端设备101、102、103通过网络104与服务器105交互，以接收或发送消息等。终端设备101、102、103上可以安装有各种实现该数据库表生成的客户端应用，例如有针对性的APP类应用或可实现相应功能的网页版系统等。

终端设备101、102、103可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。

服务器105可以是提供各种服务的服务器，例如对用户利用终端设备101、102、103所浏览的网站提供支持的后台管理服务器。后台管理服务器可以对接收到的用户请求(例如包括新增业务类请求信息、新增实体信息以及其他数据信息等)进行分析存储等处理，并将处理结果(例如根据用户请求获取或生成的业务实体信息、逻辑实体信息或数据库表结构等)反馈给终端设备。

需要说明的是，本公开实施例所提供的数据库表生成方法一般可以由服务器105执行。相应地，本公开实施例所提供的数据库表生成系统一般可以设置于服务器105中。本公开实施例所提供的数据库表生成方法也可以由不同于服务器105且能够与终端设备101、102、103和/或服务器105通信的服务器或服务器集群执行。相应地，本公开实施例所提供的数据库表生成系统也可以设置于不同于服务器105且能够与终端设备101、102、103和/或服务器105通信的服务器或服务器集群中。或者，本公开实施例所提供的数据库表生成方法也可以由终端设备101、102、或103执行，或者也可以由不同于终端设备101、102、或103的其他终端设备执行。相应地，本公开实施例所提供的数据库表生成系统也可以设置于终端设备101、102、或103中，或设置于不同于终端设备101、102、或103的其他终端设备中。

例如，新增的业务信息可以原本存储在终端设备101、102、或103中的任意一个(例如，终端设备101，但不限于此)之中，或者存储在外部存储设备上并可以导入到终端设备101中。然后，终端设备101可以在本地执行本公开实施例所提供的数据库表生成方法，或者将新增的业务信息发送到其他终端设备、服务器、或服务器集群，并由接收该新增的业务信息的其他终端设备、服务器、或服务器集群来执行本公开实施例所提供的数据库表生成方法。

应该理解，图1中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。

需要说明的是，本公开实施例确定的数据库表生成方法、数据库表生成系统、计算机系统和计算机可读存储介质可用于大数据技术领域在需要进行数据化管理时为其提供方便快捷的实现方式，也可用于除大数据技术领域之外的任意领域，本公开实施例确定的数据库表生成方法、数据库表生成系统、计算机系统和计算机可读存储介质的应用领域不做限定。

图2示意性示出了根据本公开实施例的数据库表生成方法的流程图。

具体地，如图2所示，该方法包括操作S201～S204。

在操作S201，获取业务实体模型涉及的业务实体信息，其中，业务实体信息包括业务实体标识符和第一属性信息。

根据本公开的实施例，业务实体模型从业务视角定义企业经营管理的所需要的全部数据及其之间的关系，即上述的业务实体信息。具体地，该业务实体信息例如可以包括多个核心实体，以及与每个核心实体相关联的生命周期、属性实体和协议实体。业务实体信息例如为核心实体时，业务实体标识符代表可以唯一确定该核心实体的属性信息，第一属性信息代表该业务实体下的除该业务实体标识符之外的其他属性信息。其中，核心实体例如可以为账户、产品协议、参与人协议和执行证据等，执行证据表示具体的业务事件和明细信息。以核心实体为账户时为例，生命周期表示该账户从开户到销户的时间周期，属性实体包括例如账号、协议编号、开户时间、账户名称、账户别名、受限明细最大序号等信息，协议实体表示该账户与银行签的协议类型。

根据本公开的实施例，获取业务实体模型涉及的业务实体信息包括两种情况。在第一种情况下，数据库表结构为第一次设计，业务实体模型作为一个全新的为最终的数据库表的设计提供实体数据支撑的模型，此时要获取业务实体模型中所有的业务实体信息，具体地，包括所有的业务实体标识符和所有的除业务实体标识符之外的其他属性信息。在第二种情况下，数据库表结构不是第一次设计，业务实体模型具有一个原始的模型架构，有新增类业务或更新类业务出现时，需要根据该新增类业务或更新类业务扩展数据库表结构，此时只需在该业务实体模型的原始模型架构中确定与该新增类业务或更新类业务有关联的业务实体信息，并根据该新增类业务或更新类业务的需求在该业务实体信息的基础上进一步完善，例如可以包括完善属性信息等，然后获取并基于该进行了更新的部分业务实体信息进入下一步操作。

在操作S202，根据上述业务实体模型涉及的业务实体信息定义逻辑模型的逻辑实体信息，其中，逻辑实体信息包括逻辑实体标识符和第二属性信息。

根据本公开的实施例，逻辑实体信息中对应上述的业务实体信息，并具有与上述业务实体信息相同的内容，逻辑实体标识符对应上述的业务实体标识符，同样表示可以唯一确定一个逻辑实体的属性信息，第二属性信息对应上述的第一属性信息，表示该逻辑实体下的除该逻辑实体标识符之外的其他属性信息。

根据本公开的实施例，基于上一步操作中获取的业务实体模型涉及的业务实体信息，确定针对逻辑模型中的逻辑实体信息的定义范围。该定义范围例如可以包括在上述两种不同的情况下确定的对全部或者部分的逻辑实体标识符和全部或部分的其他属性信息的定义的范围。

根据本公开的实施例，在上一步操作中获取业务实体模型涉及的业务实体信息为上述第一种情况的前提下，得到逻辑模型中所有的逻辑实体信息均为实现构建数据库表结构的有效信息，该逻辑实体信息为针对业务实体模型中所有的业务实体标识符和其他属性信息的逻辑视图化表示，该逻辑实体信息相应的包括所有的逻辑实体标识符和所有的其他属性信息。

根据本公开的实施例，在上一步操作中获取业务实体模型涉及的业务实体信息为上述第二种情况的前提下，得到逻辑模型中的部分逻辑实体信息为实现更新或扩展数据库表结构的有效信息，该部分逻辑实体信息例如可以为针对现有数据库表结构新增或更新的业务实体对应具有的业务实体标识符和其他属性信息的逻辑视图化表示，该部分逻辑实体信息相应的包括新增或更新的逻辑实体标识符和新增或更新的其他属性信息。

在操作S203，将逻辑实体标识符作为数据库表中的主键。

根据本公开的实施例，逻辑实体标识符对应上述的业务实体标识符，例如可以为账户ID、产品协议类别、参与人协议的序列号和执行证据的相关属性等。

根据本公开的实施例，在上一步操作中确定了逻辑实体信息的定义范围的情况下，以该确定的定义范围中的逻辑实体标识符作为主键构建数据库表。

需要说明的是，如果现存的数据库表中已有与该逻辑实体标识符相关的表结构，则进一步根据属性信息或该逻辑实体标识符自身的限定范围来判定是否需要新增数据库表。该逻辑实体标识符自身的限定范围例如可以表现为：该逻辑实体标识符自身为一个超类(父类)，且可以包含多个子类，可以根据其子类信息判定是否需要新增数据库表，该限定范围可不限于此。

在操作S204，根据上述第二属性信息为上述主键创建属性字段，以得到与上述逻辑实体标识符关联的数据库表。

根据本公开的实施例，由于业务实体标识符和逻辑实体标识符的一一对应关系，该逻辑实体标识符相关的属性信息同样对应上述的业务实体标识符相关的属性信息，例如可以为生命周期属性、属性实体、协议相关属性和关系属性，其中，以业务实体信息为账户实体时为例，属性实体例如可进一步包括姓名、身份证号、日期、余额等信息。

根据本公开的实施例，在上一步操作中确定了逻辑实体信息的范围的情况下，通过该确定的范围中新增的逻辑实体标识符或针对某一逻辑实体标识符更新的与其相关的属性信息进一步更新数据库表中主键或相关主键的属性字段，以进一步完善上述数据库表。

通过上述具体实施例，由于数据库表是在企业级业务架构的指导下，通过系统性方法设计，可有效优化数据分布，提升数据使用效能，且基于指导的数据库表结构的设计，可在数据源上即对数据进行规则化分配，有效避免了数据库表的无规则增长。

下面参考图3～图8，结合具体实施例对图2所示的方法做进一步说明。

图3示意性示出了根据本公开实施例的数据库表生成方法的另一流程图。

如图3所示，该方法包括操作S301～S303。

在操作S301，获取业务实体模型涉及的第一关系实体信息，其中，第一关系实体信息包括不同的业务实体信息之间的关联关系。

根据本公开的实施例，第一关系实体信息例如可以为业务实体模型中不同的业务实体标识符之间存在的逻辑上关联信息或者用来表示不同业务实体间关系的直观表示，例如账户实体和生命周期实体间可存在关联关系、账户实体和协议实体间可存在关联关系等等。

在操作S302，根据业务实体模型涉及的第一关系实体信息定义逻辑模型的第二关系实体信息，其中，第二关系实体信息包括不同的逻辑实体信息之间的关联关系。

根据本公开的实施例，第一关系实体信息和第二关系实体信息可以为一一对应的关系，例如业务实体模型中两实体间存在的关联关系，映射至逻辑模型上实现逻辑化展示，以得到逻辑模型中的第二关系实体信息。

在操作S303，根据第二关系实体信息生成数据库表之间的关联关系。

根据本公开的实施例，数据库表之间的关联关系和第二关系实体信息可以为一一对应的关系，数据库表之间的关联关系例如可以通过设置主外键或者创建关系表的形式实现。

通过上述具体实施例，由于设计了不同实体间具体的关联关系，有利于数据库表结构在一个确定的结构形式下有序扩展，有益于保持数据库表的规整化。

图4示意性示出了根据本公开实施例的根据业务实体信息定义逻辑实体信息的流程图。

需要事先说明的是，在获取逻辑模型中的逻辑实体信息时，还包括反范式化处理得到的逻辑实体标识符和/或相关的其他属性信息。具体的，本实施例中，出于性能或有效的数据管理的考虑，对业务实体信息进行反范式化处理后得到该逻辑实体信息。

根据本公开的实施例，该反范式化处理操作例如可以包括实体或属性的整合和拆分等。其中，实体或属性的整合包括超类子类实体自底向上整合、超类子类实体自上向下整合、属性实体整合、关系实体整合等。实体或属性的拆分包括按属性拆分、按发生值拆分等。

根据本公开的实施例，如图4所示，该流程可以包括操作S401～S404其中至少之一。

在操作S401，将业务实体模型中的多个业务实体标识符定义为逻辑模型中的一个逻辑实体标识符。

根据本公开的实施例，该操作具体可以表现为超类子类实体自底向上整合，超类实体和子类实体之间频繁同时更新或检索时，建议采用这种方式。

需要说明的是，采用这种方式时，一般需要被整合的超类和/或多个子类实体的大部分属性应保持一致。

在操作S402，将业务实体模型中的一个业务实体标识符定义为逻辑模型中的多个逻辑实体标识符。

根据本公开的实施例，该操作具体可以表现为超类子类实体自上向下整合，在超类实体不具备太多具体的业务含义且包含属性较少的情况下，建议使用此类整合方式。

在操作S403，将业务实体模型中的多个第一属性信息定义为逻辑模型中的一个第二属性信息。

根据本公开的实施例，该操作具体可以表现为属性实体整合，在属性实体的发生值较少且固定(几乎不增加)且其包含的属性不用于查询条件的情况下，建议做此类整合。

需要说明的是，如果属性实体中的属性不固定(比如客户可能还存在其它的电话类型，如工作电话等)，则不建议做此整合，否则会降低数据存取的灵活性(需要扩字段)。

在操作S404，将业务实体模型中的一个第一属性信息定义为逻辑模型中的多个第二属性信息。

根据本公开的实施例，该操作具体可以表现为按属性拆分，类似垂直拆分，可按场景、产品、业务领域拆分。

需要说明的是，不同场景下需要使用的属性字段差异较大，拆分出来的属性可能会具有高内聚低耦合的特点。

此外，除上述操作之外，实体或属性的整合还可以包括关系实体整合，在被整合的业务实体信息通常发生值较少且不含除键值之外的其他属性的情况下，建议做此类整合。

需要说明的是，一般不建议关系实体与其他实体进行整合，因此类整合方式可能会扰乱数据结构。

需要说明的是，在具体实施过程中，上述各整合和拆分方式也可以同时不存在，其存在与否视实际应用情况而定，在此不做限制。

综上，还需要说明的是，反范式化处理亦需要遵循一定准则，至少要保证数据有效性。

通过上述具体实施例，由于根据实际情况对实体和/或属性信息进行整合或拆分处理，得到的数据库表结构的设计更有利于实际工作需要，可以实现将业务相关的细节类信息更好的融合入数据库表中。

图5示意性示出了根据本公开实施例的数据库表生成方法中第一类型属性字段的生成流程图。

如图5所示，该方法包括操作S501～S502。

在操作S501，获取逻辑模型中的与逻辑实体标识符相关的应用实施类属性信息。

根据本公开的实施例，应用实施类属性信息例如可以包括时间戳、各类控制标志指示符等，该类属性信息原本不存在于业务实体模型中，其是在业务实体模型至逻辑模型的转化过程中根据应用需求识别来增加的应用特定数据，例如可以包括技术数据与外部数据。

根据本公开的实施例，为了使应用执行更为有效，增加了该应用实施类属性信息。

在操作S502，根据上述与逻辑实体标识符相关的应用实施类属性信息为上述主键创建属性字段。

需要说明的是，针对该应用实施类属性信息，需要应用特定数据建立维护策略和文档追踪机制，以便对新增的应用实施类属性信息及相关的原有属性信息的关系进行记录和跟踪。

通过上述具体实施例，由于针对实际应用设计完善了逻辑模型中逻辑实体对象的属性相关信息，促进了数据整合，更有利于支持管理决策，从源头保证数据的一致性。

图6示意性示出了根据本公开实施例的数据库表生成方法中第二类型属性字段的生成流程图。

如图6所示，该方法包括操作S601～S602。

在操作S601，获取逻辑模型中的与逻辑实体标识符相关的冗余类属性信息。

根据本公开的实施例，冗余类属性信息指对一些存在重复数据的属性在可控前提下进行增加字段等的冗余类处理的操作。

根据本公开的实施例，考虑需要增加冗余数据处理的情况包括：现有系统或组件重用导致某些数据重复，出于性能或保护现有投资重用的考虑，对一些重复数据进行冗余处理；以及数据频繁被不属于本逻辑实体对象的其他实体对象检索，且应用对响应时间有较高要求时进行冗余数据处理。具体操作包括：首先根据与某一主键相关的一些属性的数据的重复度确定需要增加冗余的属性字段，然后将该冗余添加到该主键或于该主键相关联的数据库表中。

在操作S602，根据上述与逻辑实体标识符相关的冗余类属性信息为上述主键创建属性字段。

需要说明的是，针对冗余处理操作，需要建立冗余数据维护策略、应用，需要保证冗余数据的一致性，以及考虑冗余数据的存储开销。

通过上述具体实施例，由于对重复数据增加冗余处理，指导数据标准建设，可进一步提高数据质量。

图7示意性示出了根据本公开实施例的数据库表生成方法中第三类型属性字段的生成流程图。

如图7所示，该方法包括操作S701～S702。

在操作S701，获取逻辑模型中的与逻辑实体标识符相关的衍生类属性信息。

根据本公开的实施例，衍生类属性信息指继承自原属性，并经进一步演变而产生的属性信息。

根据本公开的实施例，业务实体模型原则上包括了未构建数据库表所有需要的源数据，任何数据都可以从该源数据继承，某些情况下如果需要花很多时间频繁来生成数据，出于效率的考虑定义衍生数据，对于衍生规则较复杂且需要频繁生成数据采用衍生数据处理。具体地，首先确定要衍生的数据或属性信息，然后在原业务实体信息内针对原属性信息增加衍生属性或针对原属性实体新增相应的衍生属性实体。

在操作S702，根据上述与逻辑实体标识符相关的衍生类属性信息为上述主键创建属性字段。

需要说明的是，针对衍生数据处理机制：需要建立衍生数据追踪机制，以便可以追溯到逻辑模型中具体的数据项；需要定义衍生数据的域及有效取值，用以确定衍生范围，避免衍生过于宽泛导致真实的数据难以捕捉；需要确定衍生数据项的生成时间和重新衍生的频率，用以保证数据结构的稳定性；需要建立衍生数据相关命名规则，以便区分衍生数据和源数据。

通过上述具体实施例，由于对数据进行衍生处理，可以通过数据概念间的关系，建立更加灵活的数据模型与架构，进一步可支持业务的快速创新。

图8示意性示出了根据本公开实施例的基于分库分表策略的数据库表生成方法的流程图。

如图8所示，该方法包括操作S801～S802。

在操作S801，根据分库分表策略对逻辑模型中的第二属性信息进行分类。

根据本公开的实施例，分库分表策略的分配模式例如可以包括水平分表和垂直分表。水平分表例如可以是因单表数据量大而在水平方向上针对不同的记录进行的分表方式。垂直分表例如可以根据数据库表中除主键之外的其他属性信息的冷热程度、查询频率、属性相似度或适用范围等对该些属性信息进行垂直方向上的分类，并存储入不同的数据库表中。

根据本公开的实施例，水平分表可以表现为按发生值拆分的针对实体和属性的拆分放肆，选定的拆分字段应可以将源表数据记录均衡或相对均衡的分散到多张物理表中。需要说明的是，拆分后得到的多张数据表的数据结构完全一致。

在操作S802，根据逻辑模型中的逻辑实体标识符和分类结果为同一类的上述第二属性信息构建数据库表。

根据本公开的实施例，在分库分表方式为上述的垂直分表的情况下，对数据库表中除主键之外的其他属性信息进行分类后，对每一类分类结果均配合相同或相应的主键以构建一个完整的具有表示类信息的数据库表。

通过上述具体实施例，由于对除逻辑实体标识符(即上述的主键)之外的其他属性信息进行分类存储及处理，可有效提高商业银行数据标准化水平和数据质量、优化数据合理布局、提升数据使用效能。

根据本公开的另一个实施例，综合上述具体实施方式，提供了一种较为完整的数据库表生成方法，以下结合一具体的数据模型体系对该方法进一步说明。

根据本公开的实施例，数据模型体系自上而下包括概念模型(A模型)、业务对象模型(B模型)、业务实体模型(C模型)、应用级逻辑模型(C’模型)和应用级物理模型(D模型)五层模型。且其中，A模型、B模型、C模型是业务模型，属于业务架构的范畴；C’模型、D模型是IT数据模型，属于数据架构的范畴。

A模型，作为企业级概念数据模型，用于同一数据理念。

B模型，是企业核心资源的结构化体现，其从企业角度用结构图描述业务信息，实现业务的对象视图展示。

根据本公开的实施例，C模型，从业务视角定义企业经营管理的所需要的全部数据及其之间的关系，在B模型的基础上，对B模型中的业务对象进一步深入，以获取每个业务对象的业务实体信息，最终将该业务实体信息以统一的逻辑数据关系图展示，有关业务实体信息的更细节化的描述已在上文中有所体现，在此不再赘述。

C’模型，主要考虑应用范围和实施层面的要求，通过对企业级逻辑数据模型进行降范而得到应用级逻辑关系数据图的展示。

D模型，主要考虑在具体应用实施时采用的实际数据库，如MySQL(关系型数据库)、Hbase(非关系型分布式数据库)等，并基于应用级逻辑模型(即C’模型)进行落地设计，最终得到数据库表结构。

基于以上数据模型体系，需要事先说明的是，本公开实施例在生成数据库表结构的过程中，主要基于以下原则：

数据模型继承原则：继承C模型开展C’模型设计，继承C’模型开展D模型设计。比如在C模型设计合理，且应用无特殊需要的情况下，应该保持C模型与C’模型的一致性。

遵循数据标准原则：在IT数据模型建设过程中，继承C模型的数据标准关联成果，确保物理表数据一致性，提升数据质量。

性能和效率保障原则：结合应用实施考虑要素，运用反范式化、增加应用实施属性、冗余数据处理等方法将C模型转化为C’模型，以提升性能和效率。

架构决策辅助原则：对于C模型和C’模型不完全一致场景，需在应用和数据层面制定架构决策辅助原则，以保证实体间的数据一致性。

基于上述原则，本实施例的数据库表生成方法，总体上基于上述数据模型体系实现，并在企业级业务架构的指导下，通过系统性方法设计应用级逻辑模型和应用级物理模型，继承业务架构设计成果，遵循业务架构设计的数据标准，实现业务架构落地，进而形成继承业务架构模型的IT数据模型，即数据库表结构。

具体地，C模型主要目的是深度关注业务，从业务架构视角记录了各核心资源的业务内容，并定义了各业务实体(包括业务实体标识符和其他的属性信息)间的关系，通过统一业务术语，提升企业的核心竞争力。C’模型继承C模型，但是更多的关注应用设计，允许去范化以及一定程度的数据冗余；在C模型的指导下，根据应用设计需要设计C’模型。D模型继承C’模型实体和属性，并根据实际使用的数据库，设计类型、长度、索引、分区等物理特性；在C’模型的指导下，根据实际数据库类型，设计D模型，指导数据库表结构设计。

进一步的，图9示意性示出了根据本公开实施例的数据库表生成方法中业务类模型与IT数据类模型的关系示意图。

根据本公开的实施例，C’逻辑数据对象继承B模型的业务对象；根据业务组件与应用映射关系，可以是1∶1继承，根据实体父子类关系也可以存在少部分1∶N的情况。C’模型的逻辑实体(包括逻辑实体标识符和其他的属性信息)继承C模型的业务实体，非业务类实体(例如可以包括衍生类实体等)根据IT实施需要在C’阶段生成。应用的C’模型继承C模型的属性，结合实施需要，允许新增部分技术类或衍生类属性。D模型可以1∶1继承C’模型实体和属性。在C模型、C’模型、D模型设计阶段分别做好贯标(贯彻一定的数据标准)工作，对于C’模型承接的实体属性需要同步遵循C模型的贯标成果。

根据本公开的实施例，针对由C模型至D模型的架构转变，图10示意性示出了实现本公开实施例的数据库表生成方法的一种较为完整的实施方案。

根据本公开的实施例，该方案包括：在C模型指导下，通过确定C’范围、审视C模型、设计C’模型、定义C’模型、设计D模型等主要步骤完成数据库表设计全流程。

具体而言，针对确定C’范围，根据本公开的实施例，基于业务组件与业务实体关系、业务组件与应用关系，框定各应用需承接的C模型中的实体范围，需要事先说明的是，下文中提到的实体可以为对应模型下的业务实体标识符或属性实体标识符等，以确定该实体所属的业务实体类别或属性实体类别，具体地包括：

(a)理解应用范围，确认本项目设计范围与C模型的对应关系。

业务组件与任务：流程模型定义了业务组件与任务的映射关系，一个业务组件可以包含多个任务，不能跨流程模型定义业务组件。

任务与C模型实体：流程模型经过与实体模型对接，定义了任务与C模型实体的映射关系，不同的任务可以对应同一个实体，也可以对应不同的实体，但实体不能跨首要责任业务组件创建，即属于不同业务组件的两个任务不能对应至同一个实体。

应用与实体：关系在流程模型中已经定义，目标架构基于上述的业务组件与任务的对应关系，以及上述的任务与C模型实体的对应关系，来继承流程模型相关定义。

主辅数据：确认本项目使用的数据范围，包含主责数据及需使用的其他组件的数据。

(b)理解C模型的涵义及业务场景。

阅读C模型，理解C模型中业务实体的涵义：判断业务实体是属于核心实体、属性实体还是关系实体。

通过各业务实体间的关系、实体生命周期等信息的确定，进一步理解实际业务场景。

具体而言，针对审视C模型，根据本公开的实施例，审视C模型包括理解及检查C模型，通过应用九个规则进行范化处理，反向更新C模型，提高数据质量，并同步维护C模型与C′模型的映射关系。其中，该九个规则为经验化产物，在针对具体的应用场景时，更具体的规则可不限于此。

根据本公开的实施例，该九个规则可以包括：

规则一(隐藏的含义)：如果业务实体的属性中有隐藏的含义，澄清每一个含义。可能需要修改实体类型或者采取其他行动。

规则二(排他性)：检查业务实体的属性的实例，确认各实例是否互斥，含义范围是否不同。

规则三(多取值)：检查业务实体的属性，确认业务是否需要该属性保存多个取值。

规则四(历史)：检查业务实体的属性，确认业务是否需要保留属性的历史取值。

规则五(出现相同的发生值)：检查业务实体的属性，确认是否有同名异义或者异名同义的情况，另外如果出现重复的属性或者实例，需要考虑定义额外的业务实体。

规则六(可适性)：检查业务实体的属性是否适用于每个具体发生值。如果不能适用于所有的发生值，那么考虑分开定义不同的实体。

规则七(衍生)：检查业务实体的属性，确认是否可以从已有的实体中再次衍生出新实体。

规则八(颗粒度)：检查业务实体的属性，确认颗粒度级别是否足够细。

规则九(依赖性)：检查业务实体的属性，确认是否依赖于业务实体的标识。

具体而言，针对设计C’模型，根据本公开的实施例，在C模型的基础上，结合应用实施考虑的相关因素，运用上文中实施例提到的实体反范式化、增加应用实施属性、冗余数据处理、衍生数据处理等方法将C模型转化为C’模型来提升性能和效率。

具体而言，针对定义C’模型，根据本公开的实施例，在完成C’模型设计后，进一步对C’模型中的数据对象、实体和属性进行详细定义，重点是C’建模阶段新增或修改的实体、属性。例如包括：

(a)定义C’模型中的数据对象。

维护数据对象描述信息，包括如下要素：数据对象中文名称、数据对象英文名称、关联业务对象、首要责任应用、目的、定义、范围和维护人。

(b)定义C’模型中的实体。

首先维护C’模型数据实体描述信息，包括如下要素：数据实体中文名称、数据实体英文名称、目的、定义、范围、归属数据对象、首要责任应用和维护人。

然后维护C’模型数据实体与C模型实体的映射关系，包括如下主要要素：

C’模型实体信息：实体英文名称、实体中文名称、归属数据对象；

C模型实体信息：实体英文名称、实体中文名称、归属业务对象；以及

映射结果：是否能与C模型映射、映射类型、C’处理模式。

(c)定义C′模型中的属性。

首先维护C’模型数据属性描述信息，包括如下要素：数据实体中文名称、数据实体英文名称、属性中文名称、属性英文名称、目的、定义和范围。

然后维护C’模型实体属性与C模型实体属性的映射关系，包括如下要素：

C’模型属性信息：数据实体英文名、数据实体中文名、属性中文名、数据标准名称；

C模型属性信息：实体中文名、属性中文名；

映射结果：是否能与C模型映射、映射类型、C’处理模式。

具体而言，针对设计D模型，图11示意性示出了根据本公开实施例的数据库表生成方法中设计D模型的示意图。

根据本公开实施例，D模型继承自C’模型，D模型的数据库表与C’模型的逻辑实体一般为1∶1对应，根据应用实施需要，会存在少部分N∶1关系；D模型的字段与C’模型的属性1∶1对应，并从具体数据库角度，增加数据类型、长度、索引等数据库特性，并考虑分库分表等设计。具体包括：定义表基本信息、定义字段信息、定义索引、分库分表设计、识别敏感信息字段和确定生命周期管理策略。其中：

定义表基本信息：包括表英文名、中文名、主要操作类型、数据源类型。其中英文名按照规范命名，数据源类型根据数据分布视图确定。

定义字段信息：包括英文名、中文名、字段类型和长度等。其中英文名按照规范命名，字段类型和长度同字段关联的域。

定义索引：唯一索引从C’模型的实体标识符获取；通过分析与本实体相关的业务对象服务对本实体的操作，为保证访问效率，分析是否需要增加其他索引。

分库分表设计：确定每个实体分库分表策略。

识别敏感信息字段：根据敏感信息类型识别敏感信息字段。

确定生命周期管理策略：根据相关规范和业务数据保留需求，确定每个实体(例如可以为具体的某个客户)的生命周期策略，通过其生命周期确定确定该客户的开户、销户状态。

需要说明的是，图11中D模型的物理表结构中的数据(基本信息和字段信息)仅是针对数据库表中基本信息模块的一种示例性实施例而已，具体的，在数据库表中，还可以包括数据源模块、字段信息模块、字典模块、变形字段模块、索引信息模块、约束信息模块、分区信息模块和生命周期模块等。

基于上述具体实施例，关于本公开的数据库表生成方法，继承业务架构模型，准确定义了数据的分类、描述信息和数据间关系，形成企业级通用语言，为跨部门、跨业务、跨开发团队间对数据含义的沟通、理解提供一致的平台。同时，可确保企业级数据模型的前瞻性，提前支持未来新业务的扩展。

图12示意性示出了根据本公开实施例的数据库表生成系统的框图。

如图12所示，数据库表生成系统1200包括获取模块1210、定义模块1220、主键生成模块1230和字段生成模块1240。

获取模块1210，用于获取业务实体模型涉及的业务实体信息，其中，业务实体信息包括业务实体标识符和第一属性信息；

定义模块1220，用于根据业务实体模型涉及的业务实体信息定义逻辑模型的逻辑实体信息，其中，逻辑实体信息包括逻辑实体标识符和第二属性信息；

主键生成模块1230，用于将逻辑实体标识符作为数据库表中的主键；以及

字段生成模块1240，用于根据第二属性信息为主键创建属性字段，以得到与逻辑实体标识符关联的数据库表。

根据本公开的实施例，上述的数据库表生成系统还包括获取子模块、定义子模块和生成子模块。

获取子模块，用于获取业务实体模型涉及的第一关系实体信息，其中，第一关系实体信息包括不同的业务实体信息之间的关联关系。

定义子模块，用于根据业务实体模型涉及的第一关系实体信息定义逻辑模型的第二关系实体信息，其中，第二关系实体信息包括不同的逻辑实体信息之间的关联关系。

生成子模块，用于根据第二关系实体信息生成数据库表之间的关联关系。

根据本公开的实施例，上述的数据库表生成系统还包括第一定义单元和/或第二定义单元和/或第三定义单元和/或第四定义单元。

第一定义单元，用于将业务实体模型中的多个业务实体标识符定义为逻辑模型中的一个逻辑实体标识符。

第二定义单元，用于将业务实体模型中的一个业务实体标识符定义为逻辑模型中的多个逻辑实体标识符。

第三定义单元，用于将业务实体模型中的多个第一属性信息定义为逻辑模型中的一个第二属性信息。

第四定义单元，用于将业务实体模型中的一个第一属性信息定义为逻辑模型中的多个第二属性信息。

根据本公开的实施例，上述的数据库表生成系统还包括第一获取单元和第一字段生成单元。

第一获取单元，用于获取逻辑模型中的与逻辑实体标识符相关的应用实施类属性信息。

第一字段生成单元，用于根据上述与逻辑实体标识符相关的应用实施类属性信息为主键创建属性字段。

根据本公开的实施例，上述的数据库表生成系统还包括第二获取单元和第二字段生成单元。

第二获取单元，用于获取逻辑模型中的与逻辑实体标识符相关的冗余类属性信息。

第二字段生成单元，用于根据上述与逻辑实体标识符相关的冗余类属性信息为主键创建属性字段。

根据本公开的实施例，上述的数据库表生成系统还包括第三获取单元和第三字段生成单元。

第三获取单元，用于获取逻辑模型中的与逻辑实体标识符相关的衍生类属性信息。

第三字段生成单元，用于根据上述与逻辑实体标识符相关的衍生类属性信息为主键创建属性字段。

根据本公开的实施例，上述的数据库表生成系统还包括分类单元和数据库表生成单元。

分类单元，根据分库分表策略对逻辑模型中的第二属性信息进行分类。

数据库表生成单元，用于根据逻辑模型中的逻辑实体标识符和分类结果为同一类的第二属性信息构建数据库表。

根据本公开的实施例的模块、子模块、单元中的任意多个、或其中任意多个的至少部分功能可以在一个模块中实现。根据本公开实施例的模块、子模块、单元中的任意一个或多个可以被拆分成多个模块来实现。根据本公开实施例的模块、子模块、单元中的任意一个或多个可以至少被部分地实现为硬件电路，例如现场可编程门阵列(FPGA)、可编程逻辑阵列(PLA)、片上系统、基板上的系统、封装上的系统、专用集成电路(ASIC)，或可以通过对电路进行集成或封装的任何其他的合理方式的硬件或固件来实现，或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者，根据本公开实施例的模块、子模块、单元中的一个或多个可以至少被部分地实现为计算机程序模块，当该计算机程序模块被运行时，可以执行相应的功能。

例如，获取模块1210、定义模块1220、主键生成模块1230以及字段生成模块1240中的任意多个可以合并在一个模块/子模块/单元中实现，或者其中的任意一个模块/子模块/单元可以被拆分成多个模块/子模块/单元。或者，这些模块/子模块/单元中的一个或多个模块/子模块/单元的至少部分功能可以与其他模块/子模块/单元的至少部分功能相结合，并在一个模块/子模块/单元中实现。根据本公开的实施例，获取模块1210、定义模块1220、主键生成模块1230以及字段生成模块1240中的至少一个可以至少被部分地实现为硬件电路，例如现场可编程门阵列(FPGA)、可编程逻辑阵列(PLA)、片上系统、基板上的系统、封装上的系统、专用集成电路(ASIC)，或可以通过对电路进行集成或封装的任何其他的合理方式等硬件或固件来实现，或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者，获取模块1210、定义模块1220、主键生成模块1230以及字段生成模块1240中的至少一个可以至少被部分地实现为计算机程序模块，当该计算机程序模块被运行时，可以执行相应的功能。

需要说明的是，本公开的实施例中数据库表生成系统部分与本公开的实施例中数据库表生成方法部分是相对应的，数据库表生成系统部分的描述具体参考数据库表生成方法部分，在此不再赘述。

图13示意性示出了根据本公开实施例的适于实现上文中描述的数据库表生成方法的计算机系统的框图。图13示出的计算机系统仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

如图13所示，根据本公开实施例的计算机系统1300包括处理器1301，其可以根据存储在只读存储器(ROM)1302中的程序或者从存储部分1308加载到随机访问存储器(RAM)1303中的程序而执行各种适当的动作和处理。处理器1301例如可以包括通用微处理器(例如CPU)、指令集处理器和/或相关芯片组和/或专用微处理器(例如，专用集成电路(ASIC))，等等。处理器1301还可以包括用于缓存用途的板载存储器。处理器1301可以包括用于执行根据本公开实施例的方法流程的不同动作的单一处理单元或者是多个处理单元。

在RAM 1303中，存储有系统1300操作所需的各种程序和数据。处理器1301、ROM1302以及RAM 1303通过总线1304彼此相连。处理器1301通过执行ROM 1302和/或RAM 1303中的程序来执行根据本公开实施例的方法流程的各种操作。需要注意，所述程序也可以存储在除ROM 1302和RAM 1303以外的一个或多个存储器中。处理器1301也可以通过执行存储在所述一个或多个存储器中的程序来执行根据本公开实施例的方法流程的各种操作。

根据本公开的实施例，系统1300还可以包括输入/输出(I/O)接口1305，输入/输出(I/O)接口1305也连接至总线1304。系统1300还可以包括连接至I/O接口1305的以下部件中的一项或多项：包括键盘、鼠标等的输入部分1306；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分1307；包括硬盘等的存储部分1308；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分1309。通信部分1309经由诸如因特网的网络执行通信处理。驱动器1310也根据需要连接至I/O接口1305。可拆卸介质1311，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器1310上，以便于从其上读出的计算机程序根据需要被安装入存储部分1308。

根据本公开的实施例，根据本公开实施例的方法流程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读存储介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分1309从网络上被下载和安装，和/或从可拆卸介质1311被安装。在该计算机程序被处理器1301执行时，执行本公开实施例的系统中限定的上述功能。根据本公开的实施例，上文描述的系统、设备、装置、模块、单元等可以通过计算机程序模块来实现。

本公开还提供了一种计算机可读存储介质，该计算机可读存储介质可以是上述实施例中描述的设备/装置/系统中所包含的；也可以是单独存在，而未装配入该设备/装置/系统中。上述计算机可读存储介质承载有一个或者多个程序，当上述一个或者多个程序被执行时，实现根据本公开实施例的方法。

根据本公开的实施例，计算机可读存储介质可以是非易失性的计算机可读存储介质。例如可以包括但不限于：便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

例如，根据本公开的实施例，计算机可读存储介质可以包括上文描述的ROM 1302和/或RAM 1303和/或ROM 1302和RAM 1303以外的一个或多个存储器。

附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时电可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。本领域技术人员可以理解，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合，即使这样的组合或结合没有明确记载于本公开中。特别地，在不脱离本公开精神和教导的情况下，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合。所有这些组合和/或结合均落入本公开的范围。

以上对本公开的实施例进行了描述。但是，这些实施例仅仅是为了说明的目的，而并非为了限制本公开的范围。尽管在以上分别描述了各实施例，但是这并不意味着各个实施例中的措施不能有利地结合使用。本公开的范围由所附权利要求及其等同物限定。不脱离本公开的范围，本领域技术人员可以做出多种替代和修改，这些替代和修改都应落在本公开的范围之内。

Claims (10)

1.一种数据库表生成方法，包括：

获取业务实体模型涉及的业务实体信息，其中，所述业务实体信息包括业务实体标识符和第一属性信息；

根据所述业务实体模型涉及的业务实体信息定义逻辑模型的逻辑实体信息，其中，所述逻辑实体信息包括逻辑实体标识符和第二属性信息；

将所述逻辑实体标识符作为数据库表中的主键；以及

根据所述第二属性信息为所述主键创建属性字段，以得到与所述逻辑实体标识符关联的数据库表。

2.根据权利要求1所述的方法，还包括：

获取业务实体模型涉及的第一关系实体信息，其中，所述第一关系实体信息包括不同的所述业务实体信息之间的关联关系；

根据所述业务实体模型涉及的第一关系实体信息定义逻辑模型的第二关系实体信息，其中，所述第二关系实体信息包括不同的所述逻辑实体信息之间的关联关系；以及

根据所述第二关系实体信息生成所述数据库表之间的关联关系。

3.根据权利要求1所述的方法，其中，根据所述业务实体模型涉及的业务实体信息定义逻辑模型的逻辑实体信息还包括：

将所述业务实体模型中的多个所述业务实体标识符定义为所述逻辑模型中的一个所述逻辑实体标识符；和/或

将所述业务实体模型中的一个所述业务实体标识符定义为所述逻辑模型中的多个所述逻辑实体标识符；和/或

将所述业务实体模型中的多个所述第一属性信息定义为所述逻辑模型中的一个所述第二属性信息；和/或

将所述业务实体模型中的一个所述第一属性信息定义为所述逻辑模型中的多个所述第二属性信息。

4.根据权利要求1所述的方法，其中，根据所述第二属性信息为所述主键创建属性字段还包括：

获取所述逻辑模型中的与所述逻辑实体标识符相关的应用实施类属性信息；以及

根据与所述逻辑实体标识符相关的应用实施类属性信息为所述主键创建属性字段。

5.根据权利要求1所述的方法，其中，根据所述第二属性信息为所述主键创建属性字段还包括：

获取所述逻辑模型中的与所述逻辑实体标识符相关的冗余类属性信息；以及

根据与所述逻辑实体标识符相关的冗余类属性信息为所述主键创建属性字段。

6.根据权利要求1所述的方法，其中，根据所述第二属性信息为所述主键创建属性字段还包括：

获取所述逻辑模型中的与所述逻辑实体标识符相关的衍生类属性信息；以及

根据与所述逻辑实体标识符相关的衍生类属性信息为所述主键创建属性字段。

7.根据权利要求1所述的方法，还包括：

根据分库分表策略对所述逻辑模型中的所述第二属性信息进行分类；以及

根据所述逻辑模型中的所述逻辑实体标识符和分类结果为同一类的所述第二属性信息构建数据库表。

8.一种数据库表生成系统，包括：

获取模块，用于获取业务实体模型涉及的业务实体信息，其中，所述业务实体信息包括业务实体标识符和第一属性信息；

定义模块，用于根据所述业务实体模型涉及的业务实体信息定义逻辑模型的逻辑实体信息，其中，所述逻辑实体信息包括逻辑实体标识符和第二属性信息；

主键生成模块，用于将所述逻辑实体标识符作为数据库表中的主键；以及

字段生成模块，用于根据所述第二属性信息为所述主键创建属性字段，以得到与所述逻辑实体标识符关联的数据库表。

9.一种计算机系统，包括：

一个或多个处理器；

存储器，用于存储一个或多个程序，

其中，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现权利要求1至7中任一项所述的方法。

10.一种计算机可读存储介质，其上存储有可执行指令，该指令被处理器执行时使处理器实现权利要求1至7中任一项所述的方法。

Images