Multi-tenant database partitioning method, program product, and electronic device

Abstract

This application relates to a multi-tenant database partitioning method, a program product, and an electronic device. The method includes: obtaining a request to perform insurance business; matching the request to regional database information of a product management database based on product information and geographical region information in the request; if the request matches the regional database information, obtaining a product allocation rule in the product regional database and obtaining data required to perform the insurance business based on the product allocation rule; if the request does not match the regional database information, obtaining tenant information in the request and obtaining data required to perform the insurance business in the tenant database. The technical solution of this application combines geographical region information and partition rules, and can effectively avoid the problem of insurance business processing failures when only accessing the same database based on a single multi-tenant partition rule.

Description

[Technical Field]

[0001] This application claims priority to a Chinese patent application entitled "Multi-tenant database partitioning method, program product and electronic device," filed with the China Patent Office on June 7, 2022, application number 202210637186.6, the contents of which are incorporated herein by reference.

[0002] The present application relates to the computer technology field, and more particularly to a multi-tenant database partitioning method, program product, and electronic device. [Background technology]

[0003] As users' awareness of safety increases, they are increasingly aware of the importance of insurance, leading to an increasing number of users purchasing insurance. Many insurance companies have adopted the Software as a Service (SaaS) model. SaaS services allow companies to access information systems over the Internet without having to purchase hardware and software, build a machine room, or hire IT staff. Many insurance companies use SaaS services to conduct their insurance business, resulting in multiple tenants on the SaaS service vendor's server, each with its own corresponding database. For example, an urban medical insurance tenant has a corresponding urban medical insurance tenant database, and an accident insurance tenant has a corresponding accident insurance tenant database. Summary of the Invention [Problem to be solved by the invention]

[0004] However, due to the large number of users and high concurrency, database connection resources on the server are relatively valuable, and existing tenant partitioning methods cannot be changed according to changes in business. When users of the same tenant in different regions operate data in the same tenant database, performance problems such as increased database load and insufficient number of connections are likely to occur, and insurance business cannot be processed efficiently by simply accessing the corresponding tenant database based on tenant information. For example, for urban medical insurance items, with the conventional tenant partitioning method alone, when many users in different regions simultaneously request the server to retrieve data from the same tenant database, performance problems such as increased database load and insufficient number of connections corresponding to the urban medical insurance are likely to occur, and insurance business cannot be processed efficiently. [Means for solving the problem]

[0005] Therefore, the present application relates to a multi-tenant database partitioning method, a program product, and an electronic device. In a first aspect, an embodiment of the present application provides a multi-tenant database partitioning method used in a system including a server on which an interception matching module, including a data interception module, a region rule matching module, an organizational structure interception module, and a tenant rule matching module, is located, and a storage device that is a database, the method comprising: The data interception module obtains a request to perform an insurance transaction; The regional rule matching module matches the request with regional database information of a product management database in the database according to the product information and geographical region information in the request sent from the data interception module, where the product corresponds to a plurality of product regional databases in the database, and the product regional database includes product placement rules corresponding to insurance business operators; If the regional database information is matched, the regional rule matching module acquires a product placement rule from the product regional database, and acquires data required for performing insurance business based on the product placement rule; If the information does not match the regional database information, the organization configuration interception module acquires the requested tenant information, and the tenant rule matching module acquires data necessary for performing insurance business from the tenant database in the database based on the tenant information transmitted from the organization configuration interception module. Multi-tenant database partitioning method.

[0006]

[0013] It should be understood that for the same type of insurance, if the insured desires insurance in a different geographical region, the content of the corresponding insurance policy data will be different, and therefore different geographical regions may have different databases.

[0014] An embodiment of the present application is a multi-tenant database partitioning method used in a system including a server and a storage device that is a database, wherein a data interception module receives a request to perform insurance business, and a regional rule matching module matches the request with regional database information of a product management database in the database based on product information and geographical region information in the request sent from the data interception module, and if the request matches with the regional database information, the regional rule matching module obtains product placement rules from the product region database and obtains data necessary for performing the insurance business based on the product placement rules, and if the request does not match with the regional database information, an organizational structure interception module obtains tenant information in the request, and the tenant rule matching module obtains data necessary for performing the insurance business from a tenant database in the database based on the tenant information sent from the organizational structure interception module. The method combines geographical region information with the partition method, and according to the feature that the same insurance product can correspond to different regional databases, partitions different databases according to different regions corresponding to the same product, so that in high concurrency situations, the same product can access different product regional databases, improves the single partition rule based on tenant information, and only accesses the same database based on the single tenant partition rule, which can effectively avoid the problem of insurance business processing failure, and further improves the processing efficiency of insurance business.

[0007] In one possible embodiment of the above first aspect, the product management database in the database may be a lightweight directory access protocol, and the lightweight directory access protocol includes product information, geographical region information, and each product region database name, code, or route address corresponding to the product region database in the database.

[0008] As can be seen, the lightweight directory access protocol functions as a specialized database, organizing information according to a tree structure to optimize directory browsing and searching and content reading. The product management database employs the lightweight directory access protocol, and the regional rule matching module can more quickly match the request to the regional database information of the product management database in the database based on the product information and geographical region information in the request transmitted by the data interception module.

[0009] In one possible embodiment of the above first aspect, matching the request to regional database information of the product management database in the database further includes searching the product management database based on the product information and the geographical region information, and whether to find a specific product regional database name, code, or route address corresponding to the product information and the geographical region information.

[0010] It should be understood that by searching the product management database based on the product information and geographical region information, whether it is possible to find the product region database name, code, or route address corresponding to the product information and geographical region information, it is possible to quickly, conveniently, and efficiently match the request with the region database information of the product management database in the database, and obtain the matching result.

[0011] In one possible embodiment of the above first aspect, the regional rule matching module obtains product placement rules from a product regional database in the database, and obtains data necessary for performing insurance business based on the product placement rules, further including: the regional rule matching module obtains product placement rules from a specific regional database corresponding to the product regional database in the database via a regional database connection string, and obtains data necessary for performing insurance business based on the product placement rules.

[0012] It should be understood that the regional rule matching module can quickly and efficiently obtain product placement rules from the regional database via the regional database connection string and obtain data necessary to perform insurance business based on the product placement rules.

[0013] In one possible implementation of the first aspect above, the product region database including product placement rules corresponding to insurance business practitioners means that the product region database includes a product placement rule defined by one insurance business practitioner or multiple product placement rules defined by multiple insurance business practitioners.

[0014] It should be understood that the product region database includes a product placement rule defined by one insurance business practitioner or multiple product placement rules defined by multiple insurance business practitioners, providing multiple configuration rules for the same insurance product in the same region, making the region partition rule more reasonable.

[0015] In one possible implementation of the first aspect, the product information includes a product name or product number.

[0016] It should be understood that the product name or product number is an element that directly and effectively represents the product, and that including the product name or product number in the product information helps to match the local database information to the product management database based on the product information and local information.

[0017] In one possible implementation of the first aspect described above, the geographical region information includes a government region to which the product belongs, or a custom region to which the product belongs, which is customized.

[0018] It should be understood that the geographical region information includes the administrative region to which the product belongs or the custom region to which the product belongs, which can be combined with the product information to easily obtain a product region database, and efficiently access the corresponding specific region database based on the region information in the product management database.

[0019] In one possible implementation of the first aspect above, the local database information includes a product local database name, code, or route address.

[0020] It should be understood that the local database information may include a product local database name, code, or route address to provide various expressions for retrieving the product local database from the product management database.

[0021] In one possible implementation of the first aspect, the data required to perform insurance business includes: The data includes at least one of content data of basic elements in an insurance policy and logical data for creating an insurance policy, checking the status of insurance business, or examining an insurance policy.

[0022] As will be understood, the data required to carry out insurance business includes at least one of content data of basic elements in an insurance policy and logical data for creating an insurance policy, inquiring about the status of insurance business, or reviewing an insurance policy, so that after the data is acquired, insurance business can be efficiently processed based on the acquired data.

[0023] In one possible implementation of the first aspect above, the databases include a product management database, a product region database, and a tenant database.

[0024] It should be understood that the databases include a product management database, a product region database, and a tenant database, and provide conditions for realizing region partition rules and tenant partition rules.

[0025] In a second aspect, an embodiment of the present application is a multi-tenant database partition system, comprising: a data receiving module for receiving data; a data transfer module for transferring data; an intercept matching module for intercepting data and matching the intercepted data to a geographic partition rule or a tenant partition rule; a business logic module for executing business logic; The intercept matching module a data interception module for obtaining first data including product information and geographic region information; a region rule matching module for matching a region partition rule based on the product information and the geographic region information; an organizational configuration interception module for obtaining second data including tenant information; and a tenant rule matching module for matching tenant partition rules based on the tenant information.

[0026] As will be appreciated, the first data is the request data forwarded by the data forwarding module, and the second data is the request data forwarded by the local rule matching module.

[0027] As can be understood, the multi-tenant database partition device provided by the embodiments of the present application includes a data receiving module, a data transfer module, an interception matching module, and a business logic module, each of which can complete the processing of insurance business, among which the regional rule matching module includes a sub-module that completes dynamic partition rules according to geographical region information in multiple requests, and each of which can effectively realize the multi-tenant database partition method.

[0028] In a third aspect, an embodiment of the present application is a computer-readable storage medium having stored thereon instructions that, when executed on an electronic device, cause the electronic device to perform a multi-tenant database partitioning method according to the first aspect and any of the various possible implementations of the first aspect described above.

[0029] In a fourth aspect, an embodiment of the present application is a chip device including a communication interface for inputting and / or outputting information, and a processor for executing a computer-executable program to cause an electronic device equipped with the chip device to perform the multi-tenant database partitioning method of any of the first aspect and various possible realizations of the first aspect described above.

[0030] In a fifth aspect, an embodiment of the present application is a computer program product, comprising instructions for performing the multi-tenant database partitioning method of the first aspect described above and any of the various possible realizations of the first aspect.

[0031] In a sixth aspect, an embodiment of the present application includes an electronic device including a memory for storing instructions for execution by one or more processors of the electronic device, and a processor that executes the instructions stored in the memory such that, when the instructions are executed by the one or more processors of the electronic device, the multi-tenant database partitioning method of the first aspect described above and any of the various possible realizations of the first aspect is implemented. [Effects of the Invention]

[0032] Based on the above configuration, the present application has the following beneficial effects: An embodiment of the present application provides a multi-tenant database partitioning method for a system including a server and a storage device serving as a database, in which a data interception module receives a request for insurance business, and a regional rule matching module matches the request with regional database information of a product management database in the database based on product information and geographical region information in the request sent from the data interception module. If the request matches the regional database information, the regional rule matching module obtains a product allocation rule from the product regional database and obtains data required for insurance business based on the product allocation rule. If the request does not match the regional database information, an organizational structure interception module obtains tenant information in the request, and the tenant rule matching module obtains data required for insurance business from a tenant database in the database based on the tenant information sent from the organizational structure interception module. The method combines geographical region information with the partitioning method, and partitions different databases according to different regions corresponding to the same product in accordance with the feature that the same insurance product can correspond to different regional databases. In high-concurrency situations, the same product can access different product regional databases. This improves the single partitioning rule based on tenant information, effectively avoiding the problem of insurance business processing failures when only accessing the same database based on a single tenant partitioning rule, and further improving the processing efficiency of insurance business. A multi-tenant database partition device is also provided, which includes a data receiving module, a data forwarding module, an interception matching module, and a business logic module, and can effectively complete the process of processing insurance business, wherein the regional rule matching module includes a data interception module, a regional rule matching module, an organizational structure interception module, and a tenant rule matching module, and multiple sub-modules complete dynamic partition rules according to requested product information, geographical region information, or tenant information. [Brief explanation of the drawings]

[0033] [Figure 1A] FIG. 1 is a schematic diagram illustrating an insurance business scenario according to some embodiments of the present application. [Figure 1B] FIG. 1 is a schematic diagram illustrating an unfinished insurance policy interface according to some embodiments of the present application. [Figure 1C] FIG. 1 is a schematic diagram illustrating a completed insurance policy interface according to some embodiments of the present application. [Figure 2A] 2 illustrates a schematic block diagram of a server 200b according to some embodiments of the present application. [Figure 2B] 2 illustrates a schematic block diagram of an intercept matching module 203 according to some embodiments of the present application. [Figure 2C] 3 shows a schematic diagram of a database 300 according to some embodiments of the present application. [Figure 3] 2 is a schematic diagram illustrating the interaction process between the intercept matching module 203 and each sub-database of the database 300 according to some embodiments of the present application. [Figure 4] 1 illustrates a flowchart of a multi-tenant database partitioning method according to some embodiments of the present application. [Figure 5] 2 illustrates a hardware schematic diagram of a server 200b according to some embodiments of the present application. DETAILED DESCRIPTION OF THE INVENTION

[0034] Exemplary embodiments of the present application include, but are not limited to, a multi-tenant database partitioning method, a program product, and an electronic device.

[0035] In order to clarify the objectives, technical solutions and advantages of the present application, the technical solutions of the embodiments of the present application will be described in more detail below with reference to the accompanying drawings and examples. Obviously, the described embodiments are only some of the embodiments of the present application, but not all of the embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present application without any creative work fall within the scope of protection of the present application.

[0036] Hereinafter, the technical solutions of the embodiments of the present invention will be described in detail with reference to the accompanying drawings. 1A illustrates an insurance transaction scenario to which the technical solution of the present application can be applied according to some embodiments of the present application. As shown in FIG. 1A, the scenario includes an insurance policyholder, a user terminal 100 used by the insurance policyholder, an insurance company access server 200a, a SaaS service access server 200b, and a database 300 located on server 200b. To reduce operational costs, the insurance company purchases services from a SaaS vendor, and can process insurance transactions via access server 200b simply by locating the facilities required for processing the insurance transactions on the server.

[0037] The user terminal 100 can connect to the server 200a via a network, and the server 200a can connect to the server 200b via a network to process insurance business. For example, the user terminal 100 can communicate with the server 200a via a wireless network such as a wireless fidelity (Wi-Fi) network or Bluetooth, and the server 200a can communicate with the server 200b via a wireless network such as a wireless fidelity (Wi-Fi) network or Bluetooth.

[0038] Specifically, the user terminal 100 can install client software of an insurance company, such as an insurance application (APP), and the insured can access the server 200a through the insurance APP installed on the user terminal 100 to purchase the insurance products he or she needs, such as urban medical insurance, endowment insurance, vehicle insurance, and personal injury insurance. The insured can also use the instant messaging APP of the user terminal 100 to scan the two-dimensional code corresponding to each insurance to purchase insurance and process insurance transactions.

[0039] Server 200a encrypts data based on the request data sent from user terminal 100 and sends the encrypted request data to server 200b. Upon receiving the insurance business request, server 200b identifies the specific tenant to which the insurance product belongs based on the insurance product tenant information in the request, retrieves data stored in database 300 corresponding to the tenant belonging to server 200b based on the tenant partition rules, executes the insurance business content, and sends the processed insurance business results to server 200a. Server 200a decrypts the processed insurance business result data and sends the final result to user terminal 100, thereby completing the flow of processing the insurance business.

[0040] Naturally, in order for the insurance company to rent the software service provided by the SaaS service vendor, the data necessary for the insurance company's own business is installed on server 200b. By placing and processing insurance business that needs to be processed using the software service according to the business on server 200b, the insurance company can reduce maintenance costs and improve resource availability.

[0041] Specifically, for example, the insurance business handled is the creation of an urban medical insurance policy. FIG. 1B shows a screen 101 of the user terminal 100 when a user applies for insurance. When performing insurance policy business on the user terminal 100, the user must enter the necessary information for the insurance policy, and then enter data such as the product name, cities where insurance is available, and the insurance amount as shown in FIG. 1B, and then create the insurance policy. The user terminal 100 transmits a request to create an urban medical insurance policy to the server 200a. After receiving the request transmitted from the insured via the user terminal 100, the server 200a encrypts the request data and transmits the encrypted request data to the server 200b. After receiving the encrypted request for creating a city medical insurance policy, the server 200b identifies the tenant (hereinafter simply referred to as the "medical insurance tenant") to which the city medical insurance product belongs. For example, the server 200b recognizes that the medical insurance tenant is an insurance company. Based on the tenant partitioning rules, the server 200b retrieves data stored in the medical insurance tenant-related subdatabase (hereinafter simply referred to as the "medical insurance tenant database") of the database 300. The server 200a executes the request for creating a city medical insurance policy based on the retrieved data and sends the generated city medical insurance policy result to the server 200a. The server 200a then decrypts the processed insurance transaction result data according to a corresponding decryption method and sends the final result to the user terminal 100. Note that the transaction request for creating a city medical insurance policy is one of the insurance transactions installed on the server 200b by the insurance company and processed by the server 200b; the above is merely an example. The insurance transactions processed by the server 200b can also generate a blank insurance policy service, inquire about the status of the insurance transaction, and review the insurance policy based on the insurance request.

[0042] However, in the insurance transaction process, when many people simultaneously apply for insurance, multiple user terminals 100 send insurance application requests to server 200a, which then transmits encrypted request data to server 200b. Server 200a must access the same database based on the multi-tenant partitioning rules, which can easily cause performance issues such as increased database load and insufficient connections, resulting in policyholders failing to apply for insurance, wasting connection resources, and affecting the insurance transaction process. For example, when user terminal 100 sends a request to server 200a to create an urban medical insurance policy, server 200a receives the request from user terminal 100, encrypts data related to privacy security, and then transmits the encrypted request data to server 200b. Based on the received data request and tenant partitioning rules, server 200b determines that the urban medical insurance belongs to the medical insurance tenant. However, due to the large number of connections to the medical insurance tenant database, the connection to the medical insurance tenant database fails, preventing the creation of the insurance policy, wasting connection resources, and affecting the urban medical insurance transaction process.

[0043] It can be seen that the content of the corresponding insurance policy data for the same insurance type differs because the geographical regions where the insured person desires insurance differs. For example, for the same urban medical insurance, the coverage details, such as the urban medical reimbursement scope and reimbursement rate, deductible amount setting, insurance enrollment requirements, and usage area requirements, differ depending on the city. For the same urban medical insurance product, the coverage details for urban medical insurance in City A and urban medical insurance in City B are different. Therefore, it is possible to associate the insured product with the geographical region and partition based on the association between the insured product and the geographical region.

[0044] Therefore, this application proposes a multi-tenant database partitioning method, in which the server 200b matches the region partitioning rules based on the requested insurance product information and geographical region information, and if the matching is successful, executes insurance business logic based on the product allocation rules corresponding to the insurance companies obtained from the region partitioning rules and related data required for executing insurance business corresponding to the product allocation rules. On the other hand, if the matching with the region partitioning rules fails, it matches the tenant partitioning rules based on the requested tenant information, and if the matching is successful, executes insurance business logic based on the data related to executing insurance business obtained from the tenant partitioning rules. In particular, insurance products correspond to multiple product region databases, and the product region databases include product allocation rules corresponding to insurance business operators.

[0045] As can be understood, the above geographical areas may be areas based on different administrative divisions, such as provinces, cities, districts, and counties, or may be customized geographical areas based on economic development levels and permanent populations.

[0046] As can be understood, the insurance contents of the same insurance product purchased in different regions are different. Therefore, by combining insurance product and geographical region information in this way, and accessing different product regional databases for the same product in different geographical regions, and obtaining product allocation rules related to different insurance companies in the regional database, in the case of high concurrency, in the process of multiple user terminals 100 processing insurance business, by accessing different regional databases for different regions, only accessing the same database based on a single multi-tenant partition rule, the problem of users failing to process insurance business can be effectively avoided, the pressure on a single database can be reduced, and the processing efficiency of insurance business can be further improved.

[0047] For example, in the scenario shown in FIG. 1A, when the user fills in the insurance policy interface shown in FIG. 1B, the server 200b receives the request for creating urban medical insurance policy data. The server 200b acquires the requested product name and available cities for insurance and performs matching with the regional partitioning rules based on the product name "xx City Medical Insurance" and the available city "Anyang." If the matching is successful, the server 200b acquires the urban medical insurance product allocation rules corresponding to the insurance company and the related data required to execute the insurance business corresponding to the urban medical insurance product allocation rules from the regional database corresponding to Anyang (hereinafter referred to as the "Anyang database"), and executes the business logic based on the acquired data. If the matching with the regional partitioning rules is unsuccessful, the server 200b performs matching between the tenant information corresponding to the requested urban medical insurance product and the tenant partition. If the matching is successful, the server 200b acquires data related to the creation of the insurance policy from the medical insurance tenant database based on the rules of the matched tenant partition, and executes the business logic for creating the medical insurance policy based on the acquired data. After the server 200b executes the business logic of creating medical insurance, it sends data to the server 200a, and the server 200a decrypts the data and sends it to the user terminal 100. The user terminal 100 displays the insurance policy interface 102 as shown in FIG. 1C, and the insurance policy interface cannot be modified at this time.

[0048] As can be seen, for the same urban medical insurance business, the insurance business is different in different regions, such as cities like Anyang and Yulin. When server 200b receives insurance application requests from multiple user terminals 100 in Anyang, Yulin, etc., acquired from server 200a, it acquires urban medical insurance product allocation rules corresponding to insurance companies in the Anyang database and related data required to execute the insurance business corresponding to the urban medical insurance product allocation rules based on the regional partition rules, and generates urban medical insurance policy business logic based on the acquired data. It acquires urban medical insurance product allocation rules corresponding to insurance companies in the regional database corresponding to Yulin (hereinafter referred to as the Yulin database) based on the regional partition rules, and related data required to execute the insurance business corresponding to the urban medical insurance product allocation rules, and issues an urban medical insurance policy based on the acquired data. The data required to execute the insurance business logic is acquired in different regional databases according to the insurance request, thereby improving the processing efficiency of the insurance business.

[0049] 1A, the user terminal 100 may be an electronic device having a display screen on which an insurance company application can be installed. The server 200a and the server 200b may be individual servers or may be a server cluster consisting of multiple servers.

[0050] To make this proposal easier to understand, the device configuration corresponding to the server 200b will be first introduced. As shown in FIG. 2A, the server 200 b includes a data receiving module 201 , a data transferring module 202 , an intercept matching module 203 , and an execution business logic module 204 .

[0051] The following provides a detailed description of the functions of each module of the server 200b and its role in some embodiments of the present application.

[0052] Specifically, the data receiving module 201 receives request data. In some embodiments of the present application, the data receiving module 201 can receive request data related to insurance business sent from the server 200a and send the request data to the data transferring module 202. For example, the data receiving module 201 receives a message from the server 200a that includes at least one field of product information related to the insurance business, region information, or tenant information to which the insurance product belongs.

[0053] The data forwarding module 202 can be used to forward the request data. In some embodiments of the present application, the data forwarding module 202 can obtain the request data related to the insurance business sent from the data receiving module 201, filter irrelevant data in the request data, and send the filtered request data to the intercept matching module 203.

[0054] The intercept matching module 203 may be used to intercept data and match the data with a region partition rule or a tenant partition rule based on the intercepted data. In some embodiments of the present application, the intercept matching module 203 may receive data transmitted from the data transfer module 202, perform region partition rule matching based on the product information and geographical region information in the request data, and if the matching is successful, send the result data obtained by the matching to the business execution logic module 204. If the matching is unsuccessful, the intercept matching module 203 may obtain tenant information in the request, match the tenant partition rule based on the tenant information, and send the result data obtained by the matching to the business execution logic module 204.

[0055] As can be understood, by matching the corresponding partition strategy based on the geographical region information or tenant information in the acquired request, the traditional single-tenant partition method is improved. In the case of high concurrency, by adopting the regional partition strategy for the same insurance product, the problem of accessing different sub-databases and failing to access the same insurance policy database to acquire data can be avoided, and the processing efficiency of insurance business can be improved. It should be understood that in some embodiments, the interception matching module 203 may be a chain multi-interceptor.

[0056] The execution business logic module 204 executes business logic. In some embodiments of the present application, the execution business logic module 204 may receive insurance business data that has been successfully matched by the intercept matching module 203 and execute insurance business, such as creating an insurance policy, reviewing the insurance policy, or inquiring about the status of the insurance business.

[0057] To more clearly explain how the intercept matching module 203 matches sub-databases, the functional modules that the intercept matching module 3203 specifically comprises in some embodiments of the present application, and each sub-database included in the database 300 will be described.

[0058] As shown in FIG. 2B, the interception matching module 203 may include a data interception module 203 a, a region rule matching module 203 b, an organizational structure interception module 203 c, and a tenant rule matching module 203 d.

[0059] The data interception module 203a obtains the request data forwarded by the data forwarding module 202 and sends the request data to the local rule matching module 203b. It should be appreciated that in some embodiments, the data interception module 203a may be a data interceptor.

[0060] The regional rule matching module 203b receives the request data sent from the data interception module 203a, first searches the product management database in the database 300 based on the product information and regional information in the request data, finds specific regional database information corresponding to the product in the product management database, searches the product regional database in the database 300 based on the regional database information, and if the product regional database obtains the product placement rule corresponding to the insurance business operator and data corresponding to the product placement rule, the matching is successful, but if a specific region corresponding to the product is not found in the product management database, the matching fails.

[0061] The organizational configuration interception module 203c receives the request data sent from the local rule matching module 203b, obtains tenant information based on the request data, and sends the tenant information to the tenant rule matching module 203d. Note that the tenant information may be information about an insurance product or an insurance company corresponding to the insurance product. It should be understood that in some embodiments, the organizational configuration interception module 203c may be an organizational configuration interceptor.

[0062] The tenant rule matching module 203d receives data sent from the organizational structure interception module 203c, matches it to the tenant database in the database 300 based on the tenant information in the acquired data, acquires execution business logic data or insurance policy data etc. for executing insurance business corresponding to the tenant, and sends the searched data to the execution business logic module 204.

[0063] As shown in FIG. 2C, the database 300 includes a product management database 301, a product region database 302, and a tenant database 303.

[0064] It will be appreciated that each sub-database in database 300 may be a relational database or a Lightweight Directory Access Protocol (LDAP) database, which functions as a specialized database, organizing information according to a tree structure, a hierarchical database specially optimized for directory browsing and searching, and content retrieval, and capable of retrieving data an order of magnitude faster than retrieving data from a relational database.

[0065] The LDAP directory stores record items including an attribute type and an attribute value as a series of "attribute pairs." For example, the product management database 301 may be an LDAP database, and the regional database information stored in the product management database 301 may be insurance product information, regional information, and a product regional database name, code, or route address corresponding to the product regional database 302. Specifically, the attributes of the record items in the product management database 301 can be customized to include a product name attribute, a region attribute, a specific product regional database name, code, or a route address attribute corresponding to a specific regional database, and corresponding attribute values can be obtained based on the attributes.

[0066] Specifically, the product management database 301 includes information on each product and multiple regional databases corresponding to each product, such as the product regional database name, code, route address, etc. For example, if the product is insurance product K and the product is sold in cities A, B, and C, there is a city A database name, code, or regional database route address corresponding to insurance product K, a city B database name, code, or regional database route address corresponding to insurance product K, and a city C database name, code, or product regional database route address corresponding to insurance product K, and there are multiple regional databases corresponding to each of the multiple products. For example, an urban medical insurance product can be sold in multiple cities such as Yulin and Anyang, and the product management database 301 can include the database names, codes, or route addresses corresponding to the urban medical insurance products such as Yulin and Anyang.

[0067] The product region database 302 includes region databases corresponding to multiple products, and each sub-database of the product region database corresponds to a product region database name or route address acquired from the product management database. For example, for insurance product K, each sub-database includes the A city database or route address corresponding to the A city database corresponding to insurance product K, the B city database or route address corresponding to the B city database corresponding to insurance product K, and the C city database or route address corresponding to the C city database corresponding to insurance product K. For example, for urban medical insurance products, the corresponding multiple product region databases include regional databases such as the Weihai database, the Yulin database, and the Anyang database. Each product region database includes product placement rules corresponding to insurance business operators. One product region database may include product placement rules corresponding to multiple different insurance companies, specifically, multiple product placement rules defined by one insurance company, one product placement rule defined by one insurance company, or one product placement rule defined by multiple insurance companies, and is not particularly limited. For example, the Yulin database includes placement rules for urban medical insurance products established by multiple insurance companies.

[0068] Tenant database 303 includes multiple tenant databases, such as tenant A database, tenant B database, tenant C database, etc. Each tenant database may store data required for the same product from the same insurance company, or may store data required for multiple products from the same insurance company. For example, tenant database 303 may include an urban medical insurance tenant database.

[0069] It should be understood that the configuration diagram shown in the above-described server 200b is merely an example, and in other embodiments, the number of corresponding modules can be increased or decreased based on this, and a specific structure is not required herein. For example, a user management module, a user setting module, an insurance policy management module, etc. may also be included. Each sub-database included in the above-described database 300 is merely an example, and in other embodiments, the number of corresponding partitions can be increased or decreased based on this, and a specific structure is not required herein.

[0070] To better understand the process by which the intercept matching module 203 in the present application interacts with each sub-database in the database 300 when matching regional partition rules or tenant partition rules, the following will use an insurance business that creates insurance policies as an example to describe the interaction between each sub-module in the intercept matching module 203 and each sub-database in the database 300. Figure 3 shows a specific interaction process, including the following steps:

[0071] S301: The data interception module 203a intercepts a request to create an insurance policy. The insurance policy generation request intercepted by the data interception module 203 a includes information that can represent insurance product information, insured information, insurable geographical area information, product sales channels, etc., and therefore, a description thereof will be omitted here.

[0072] It should be understood that the product information may include information such as product number or name, and the insurable geographical area information may be areas by different administrative regions, for example, provinces, cities, districts, or counties, or may be geographical areas customized according to the level of economic development and the number of resident populations. Note that the product information and insurable cities may be identified by numbers, alphabets, etc. after being encrypted by the server 200a, and the specific identification method is not particularly limited.

[0073] For example, the data interception module 203a intercepts a request to create a city medical insurance policy, which may include information such as city medical insurance product information, policyholder information, and insurable city information.

[0074] S302: The data interception module 203a sends a request to create an insurance policy to the local rule matching module 203b. For example, the data interception module 203a sends a request to create a city medical insurance policy to the local rule matching module 203b.

[0075] S303: The region rule matching module 203b obtains product information and geographic region information based on the request data. For example, the regional rule matching module 203b acquires the code 01 of the urban medical insurance product and the identification number AY of the insurable city Anyang city based on the request for creating the urban medical insurance policy obtained.

[0076] S304: The area rule matching module 203b transmits to the product management database 301 a request to acquire specific area database information corresponding to the product.

[0077] It should be appreciated that in some embodiments, the local rule matching module 203b may define matching to local rules in the language of a particular domain, i.e., the language of common understanding. For example, Rule { RuleName = "RegionPartitionRule" {Get data from product region database}} It should be understood that the partition matching with the region rules described above is just one example, and other embodiments include many more implementations.

[0078] It can be understood that in the process of matching the regional partition rule, specific regional database information needs to be obtained. The regional rule matching module 203b sends a request to the product management database 301 to obtain specific regional database information corresponding to the product based on the obtained product information and geographical region information, where the request includes obtaining information such as the product regional database name, code, or route address corresponding to the insurance product.

[0079] For example, the regional rule matching module 203 b sends to the product management database 301 the product regional database name, code, or route address specifically corresponding to the product, the code 01 for obtaining the urban medical insurance product, and the identification number AY of the insurable city Anyang City.

[0080] S305: Whether the product management database 301 matches the regional database information. If so, proceed to step 314; otherwise, proceed to step 306. In some embodiments, the product management database 301 searches the database based on the product information and geographical region information obtained in the request to see whether region database information corresponding to the product and geographical region information exists in the database. If so, proceed to step 314 to obtain specific region database information corresponding to the product; if not, proceed to step 306 to return a region partition rule matching failure message.

[0081] For example, the product management database 301 checks whether there is a regional database corresponding to the insurance product number 01 and the insurable city Anyang City AY in the database based on the city medical insurance product number 01 and the insurable city Anyang City AY acquired in the request. If there is, proceed to step 314 to acquire the specific regional database name, code or route address corresponding to the product; if not, proceed to step 306 to return a regional partition matching failure message.

[0082] S306: The product management database 301 notifies the local rule matching module 203b that no matching local database information exists. In some embodiments, if no corresponding locality database information exists in the product management database 301, a message is sent to the locality rule matching module 203b that no matching locality database information exists.

[0083] For example, the product management database 301 does not match the regional database name, code, or route address corresponding to product number 01 and the insurable city Anyang City AY in the database, and sends a message to the regional rule matching module 203b that no matching regional database information exists.

[0084] S307: The local rule matching module 203b sends a request to create an insurance policy to the organizational structure interception module 203c. In some embodiments, if the regional rule matching module 203 b receives a message from the product management database 301 indicating that no matching regional database information exists and determines that the regional partition rule matching has failed, it sends a request to create an insurance policy to the organizational configuration interception module 203 c.

[0085] For example, the regional rule matching module 203b receives a message from the product management database 301 indicating that no matched regional database information exists, determines that the regional partition rule matching has failed, and sends a request to create an urban medical insurance policy to the organizational structure interception module 203c.

[0086] S308: The organizational structure interception module 203c sends a request to create an insurance policy including tenant information to the tenant rule matching module 203d. In some embodiments, the organizational structure interception module 203 c receives a request for creating an insurance policy from the area rule matching module 203 b, then obtains tenant information from the request data and transmits the tenant information to the tenant rule matching module 203 d. Here, the tenant information may include a tenant name, code, etc., and may be expressed in numbers, alphabets, other characters, etc., without being particularly limited. The tenant name and code may be the name or code of an insurance company corresponding to an insurance product.

[0087] For example, the organizational structure interception module 203c acquires a request for creating a city medical insurance policy sent from the area rule matching module 203b, and then acquires city medical insurance tenant information based on the request data and transmits the medical insurance tenant information to the tenant rule matching module 203d. Note that the tenant name corresponding to the city medical insurance product tenant database may be HMB tenant.

[0088] S309: The tenant rule matching module 203d obtains a request to create an insurance policy. It is understood that the tenant rule matching module 203d obtains the policy creation request sent from the organizational configuration interception module 203c. For example, the tenant rule matching module 203d obtains a request for creating a city medical insurance policy sent from the organizational configuration interception module 203c.

[0089] S310: The tenant rule matching module 203d sends a request to the tenant database 303 to obtain data required to execute the creation of an insurance policy in the corresponding tenant database. It should be appreciated that in some implementations, the tenant rule matching module 203d can define matching to tenant partition rules in the language of a particular domain, i.e., a language of common understanding.

[0090] For example, Rule {RuleName="TenantPartitionRule" {Get data in tenant database}} It should be understood that the tenant partition rules described above are merely examples, and other embodiments include many more implementations.

[0091] As will be appreciated, the tenant rule matching module 203d sends a request to the tenant database 303 based on the tenant information in the request to obtain the data necessary to execute the creation of the insurance policy in the corresponding tenant database. For example, the tenant rule matching module 203d sends a request to the tenant database 303 based on the urban medical insurance tenant information in the request to obtain the data necessary to execute the creation of the urban medical insurance policy in the HMB tenant database.

[0092] S311: The tenant database 303 obtains the data necessary to execute the creation of the insurance policy. In some embodiments, the tenant database 303 searches for data required to execute the creation of an insurance policy in the corresponding tenant database based on the acquired tenant information. It should be understood that the data required to execute the creation of an insurance policy may include the content of basic elements of an insurance policy and logical data for executing the creation of an insurance policy.

[0093] For example, based on the tenant information, the tenant database 303 searches the HMB tenant database for data necessary to execute the creation of a city medical insurance policy.

[0094] S312: The tenant database 303 sends the tenant rule matching module 203d the data required to execute the creation of the insurance policy. In some embodiments, the tenant database 303 searches the corresponding tenant database for the data required to execute the creation of the insurance policy, and then sends the retrieved data to the tenant rule matching module 203d.

[0095] For example, the tenant database 303 searches the HMB tenant database for data required to execute the creation of a city medical insurance policy, and then sends the retrieved data to the tenant rule matching module 203d.

[0096] S313: The tenant rule matching module 203d determines that the matching of the tenant partition rule is successful. In some embodiments, after retrieving the data, the tenant rule matching module 203d determines that the tenant partition rule matching is successful.

[0097] S314: The product management database 301 acquires specific regional database information corresponding to the product. In some embodiments, the product management database 301 searches for corresponding regional database information in the database based on the product information and the geographical area information. The corresponding regional database information may include a product regional database name, code, or route address corresponding to the insurance product and the geographical area information. The specific display method may be numbers, alphabets, etc., but it should be understood that this is not particularly limited.

[0098] For example, the product management database 301 searches the database for the urban medical product number 01 and the insurance-available city Anyang identification number AY, and the corresponding product area database name in the product management database 301 is Anyang database.

[0099] S315: The product management database 301 sends specific regional database information corresponding to the product to the regional rule matching module 203b. For example, the product management database 301 transmits to the regional rule matching module 203b that the regional database from which data for creating an insurance policy corresponding to the urban medical insurance product can be obtained is the Anyang database.

[0100] S316: The regional rule matching module 203b sends a request to the product regional database 302 to obtain the product placement rule in the corresponding product regional database and obtain the data required to execute the creation of the insurance policy based on the product placement rule.

[0101] In some embodiments, after obtaining the regional database information corresponding to the insurance product, the regional rule matching module 203b sends a request to the product regional database 302 to obtain the product placement rule in the corresponding product regional database and to obtain data required to execute the creation of an insurance policy based on the product placement rule. Among these, one product regional database may include product placement rules corresponding to multiple different insurance companies, specifically, multiple product placement rules defined by one insurance company, one product placement rule defined by one insurance company, or one product placement rule defined by multiple insurance companies, etc., and is not particularly limited here.

[0102] For example, after the regional rule matching module 203b obtains that the product regional database corresponding to the urban medical insurance product is the Anyang database, it sends a request to the product regional database 302 via the regional database connection string to obtain the allocation rule of the urban medical insurance product in the Anyang database and obtain the data required to execute the creation of the urban medical insurance policy according to the product allocation rule.

[0103] S317: The product region database 302 acquires the product placement rule and acquires data necessary for creating an insurance policy based on the product placement rule. In some embodiments, the product region database 302 searches a corresponding region database upon request to obtain product placement rules and obtain data necessary to execute the creation of an insurance policy based on the product placement rules.

[0104] For example, the product region database 302 searches the Anyang database based on the requested region database connection string, obtains the urban medical insurance product allocation rules, and obtains the data required to create the urban medical insurance policy based on the product allocation rules.

[0105] S318: The product region database 302 transmits the acquired product placement rule and data required to execute the creation of an insurance policy corresponding to the product placement rule to the region rule matching module 203b. In some embodiments, the product region database 302 retrieves a product placement rule, retrieves data necessary to execute the creation of an insurance policy from an execution corresponding to the product placement rule, sends the retrieved product placement rule to the region rule matching module 203 b, and generates data necessary to execute the creation of an insurance policy corresponding to the product placement rule.

[0106] For example, the product region database 302 acquires the placement rules for urban medical insurance products, acquires the data necessary for creating an urban medical insurance policy corresponding to the product placement rules, and then transmits the acquired urban medical insurance product placement rules and the data necessary for creating an urban medical insurance policy corresponding to the product placement rules to the region rule matching module 203b.

[0107] S319: The region rule matching module 203b determines that the region partition rule matching is successful. In some embodiments, after the region rule matching module 203b obtains the data, it determines that the region partition rule matching is successful.

[0108] For example, the regional rule matching module 203b determines that the regional partition rule matching is successful after obtaining data related to the creation of an urban medical insurance policy.

[0109] The execution order of steps S301 to S319 is an example, and in other embodiments, other execution orders may be adopted, or some of the steps may be divided or integrated, and the order is not limited here.

[0110] In addition, the insurance business processing executed as described above can also include insurance business such as insurance policy review, insurance business status inquiry, online claims, and cancellation, in addition to creating insurance policies, and the specific insurance business to be processed is not required here.

[0111] Based on the above-mentioned scenario shown in Figure 1, Figure 4 shows a flowchart of the execution of the multi-tenant database partition method in the embodiment of the present application, with the server 200b as the execution body. The specific flow includes the following steps:

[0112] S401: Obtain a request for execution of related insurance business. In some embodiments, the user terminal 100 sends a request to perform a related insurance transaction to the server 200a. After receiving the request sent from the user terminal 100, the server 200a encrypts the request data and sends the encrypted request to the server 200b, which then obtains the request to perform the related insurance transaction. It should be understood that performing the related insurance transaction may include creating an insurance policy, calculating the premium, inquiring about the current insurance transaction status, reviewing the insurance policy, canceling the insurance, and filing an insurance claim online, etc.

[0113] For example, the user terminal 100 sends a request to create an urban medical insurance policy to the server 200 a, and after the server 200 a receives the request sent by the user via the user terminal 100, it encrypts the request data and sends the encrypted request to the server 200 b, and the server 200 b obtains the request to execute the creation of the urban medical insurance policy.

[0114] As will be appreciated, in some embodiments, in the device diagram shown in Figure 2A, a data receiving module 201 receives a request to perform a related insurance transaction sent from a server 200a, and a data forwarding module 202 filters the data in the request.

[0115] S402: Determine whether matching with the regional partition rule is successful based on the product information and geographical region information in the request data. If the determination result is YES, proceed to step S404, and if the determination result is NO, proceed to step S403.

[0116] In some embodiments, after receiving a request to perform related insurance business, the server 200b obtains product information and geographical area information data in the request data, and matches the database 300 based on the insurance product information and specific geographical area information to determine whether a product area database corresponding to the specific location area exists. If a corresponding product area database exists, the server 200b searches for a product allocation rule in the corresponding product area database and obtains data required to perform insurance policy creation based on the product allocation rule. The server 200b determines that the matching with the area partition rule is successful and proceeds to step S404. If a region database corresponding to the specific location area does not exist, the server 200b determines that the matching with the area partition rule is unsuccessful and proceeds to step S403.

[0117] For example, after receiving a request to create an urban medical insurance policy, the server 200b obtains the urban medical insurance product information and insurable city information data in the request data, searches the database 300 based on the insurance product information and insurable cities to determine whether a regional database corresponding to the product and insurable cities exists, and if a corresponding regional database exists, searches the corresponding regional database for urban medical insurance product allocation rules, obtains the data required for creating the insurance policy based on the urban medical insurance product allocation rules, and confirms that matching with the regional partition rules has been successful. If a regional database corresponding to the product and insurable cities does not exist, it is determined that matching with the regional partition rules has failed.

[0118] 2A and 2B, in some embodiments, the data transfer module 202 filters the acquired request data and sends it to the intercepting matching module 203, and the regional rule matching module 203b of the intercepting matching module 203 determines whether matching with the regional partition rule is successful based on the product information and geographical region information in the request data. If the determination result is YES, proceed to step S404; if the determination result is NO, proceed to step S403.

[0119] S403: Matching with tenant partition rules based on tenant information in the request data. In some embodiments, after determining that matching with the regional partition rules has failed based on the product information and geographical region information in the request data, the server 200 b performs matching with the tenant partition rules based on the tenant information in the request data, i.e., performs search matching in each tenant database based on the tenant information in the request data, to obtain data required to perform related insurance business.

[0120] For example, after determining that the server 200b has failed to match the regional partition rules based on the urban medical insurance product information and cities where insurance is available in the request data, it performs a matching search with the tenant partition rules based on the medical insurance tenant information in the request data, i.e., a matching search in each tenant database based on the tenant information in the request data, and obtains the data necessary to execute the urban medical insurance policy and the logical data of the execution business.

[0121] As can be understood, in some embodiments, in the configuration diagram shown in FIG. 2B, the organizational structure interception module 203 c of the interception matching module 203 obtains tenant information in the request data, and the tenant rule matching module 203 b matches tenant partition rules based on the tenant information.

[0122] S404: Execute insurance business logic based on the successfully matched partition rules. In some embodiments, if the partition rule that has been successfully matched is a regional partition rule, data required for performing insurance business is obtained based on the regional partition rule and insurance business logic is executed, and if the partition rule that has been successfully matched is a tenant partition rule, data required for performing insurance business is obtained based on the tenant partition rule and insurance business logic is executed, where the data required for performing insurance business includes at least one of content data of basic elements on an insurance policy, logical data for creating an insurance policy, querying the insurance business status, or reviewing an insurance policy.

[0123] For example, if the partition rule that has been successfully matched is a regional partition rule, the data required to create an urban medical insurance policy is obtained based on the regional partition rule, and the business logic for creating the insurance policy is executed; if the partition rule that has been successfully matched is a tenant partition rule, the data required to create an urban medical insurance policy is obtained based on the tenant partition rule, and the business logic for creating the insurance policy is executed.

[0124] As will be appreciated, in some embodiments, in the block diagram shown in FIG. 2A, the business operations logic 204 module executes insurance business operations logic.

[0125] The execution order of steps S401 to S404 described above is an example, and in other embodiments, other execution orders may be adopted, or some of the steps may be divided or integrated, and is not limited to this.

[0126] To facilitate understanding of each embodiment of the present invention, the hardware configuration of the server 200b will be described. 5 shows a schematic block diagram of a server 200b according to some embodiments of the present application. As shown in FIG. 5, the server 200b for executing the multi-tenant database partitioning method shown in FIG. 4 provided herein may include one or more processors 201, a system memory 202, a non-volatile memory (NVM) 203, an input / output (I / O) device 204, a communication interface 205, and system control logic 206 for coupling the processor 201, the system memory 202, the non-volatile memory 203, the input / output (I / O) device 204, and the communication interface 205.

[0127] Here, processor 201 may include one or more single-core or multi-core processors. In some embodiments, processor 201 may include any combination of general-purpose processors and special-purpose processors (e.g., graphics processors, application processors, baseband processors, etc.). In some embodiments, processor 201 may be configured to perform matching with region partition rules based on product information and geographic region information in the request data, and if matching fails, perform matching with tenant partition rules based on tenant information in the request data, and execute insurance business logic according to the results of matching the partition rules.

[0128] System memory 202 is volatile memory, such as Random-Access Memory (RAM), Double Data Rate Synchronous Dynamic Random Access Memory (DDR SDRAM), etc. System memory is used to temporarily store data and / or instructions; for example, in some embodiments, system memory 202 may be used to store executable programs to implement the multi-tenant database partitioning methods described above.

[0129] Non-volatile memory 203 may include one or more tangible, non-transitory, computer-readable media for storing data and / or instructions. In some embodiments, non-volatile memory 203 may include any suitable non-volatile memory, such as flash memory, and / or any suitable non-volatile storage device, such as a hard disk drive (HDD), a compact disc (CD), a digital versatile disc (DVD), a solid-state drive (SSD), etc. In some embodiments, non-volatile memory 203 may be a removable storage medium, such as a Secure Digital (SD) memory card, etc.

[0130] In particular, system memory 202 and non-volatile memory 203 may include temporary and permanent copies, respectively, of instructions 207. Instructions 207 may include program instructions that, when executed by at least one of processors 201, cause server 200 to implement the multi-tenant database partitioning method provided by embodiments of the present application.

[0131] The input / output (I / O) devices 204 may include a user interface that allows a user to interact with the server 200b. For example, in some embodiments, the input / output (I / O) devices 204 may include an output device such as a display for displaying software systems used in the server 200b, and may further include input devices such as a keyboard, mouse, touchscreen, etc. Maintenance personnel for the server 200b may interact with the server 200b via the user interface and input devices such as a keyboard, mouse, touchscreen, etc.

[0132] The communication interface 205 may include a transceiver that provides the server 200b with a wired or wireless communication interface for communicating with any other suitable devices over one or more networks. In some embodiments, the communication interface 205 may be integrated into other components of the server 200b, such as the processor 201. In some embodiments, the server 200b may communicate with other devices via the communication interface 205.

[0133] System control logic 206 may include any suitable interface controllers that provide any suitable interfaces to other modules of server 200 b. For example, in some embodiments, system control logic 206 may include one or more memory controllers that provide interfaces connected to system memory 202 and non-volatile memory 203.

[0134] In some embodiments, at least one of the processors 201 may be packaged with logic of one or more controllers of system control logic 206 to form a system package (SiP). In other embodiments, at least one of the processors 201 may be integrated on the same chip as logic of one or more controllers of system control logic 206 to form a system on a chip (SoC).

[0135] It should be understood that server 200b may be any electronic device capable of executing the multi-tenant database partitioning methods provided herein, including computers, servers, tablets, handheld computers, etc., but embodiments of the present application are not limited thereto.

[0136] It should be noted that the configuration of the server 200b shown in the embodiment of the present application does not constitute a specific limitation of the server 200b. In other embodiments of the present application, the server 200b may include more or fewer components than those shown, and some components may be combined, some components may be divided, or different components may be arranged. The components shown in the drawings may be realized in hardware, software, or a combination of software and hardware.

[0137] Embodiments of the mechanisms disclosed herein may be implemented in hardware, software, firmware, or a combination of these implementations. Embodiments of the present application may be realized as a computer program or program code running on a programmable system including at least one processor, a storage system (including volatile and non-volatile memory and / or storage elements), at least one input device, and at least one output device.

[0138] Program code may be applied to input instructions to perform the functions described herein and to generate output information. The output information may be applied to one or more output devices, in known fashion. For purposes of this application, a processing system includes any system that has a processor, such as, for example, a DSP (Digital Signal Processor), a microcontroller, an ASIC (Application Specific Integrated Circuit), or a microprocessor.

[0139] The program code may be implemented in a high-level or object-oriented programming language to communicate with a processing system. If desired, the program code may also be implemented in assembly or machine language. Indeed, the mechanisms described herein are not limited in scope to any particular programming language. In either case, the language may be a compiled or interpreted language.

[0140] In some cases, the disclosed embodiments may be implemented in hardware, firmware, software, or any combination thereof. The disclosed embodiments may also be implemented as instructions carried by or stored on one or more transitory or non-transitory machine-readable (e.g., computer-readable) storage media, which may be read and executed by one or more processors. For example, the instructions may be distributed over a network or other computer-readable media. Thus, machine-readable media can include any mechanism for storing or transmitting information in a machine- (e.g., computer-) readable form, including, but not limited to, floppies, optical disks, read-only memories (CD-ROMs), magneto-optical disks, read-only memory (ROM), random access memory (RAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic or optical cards, flash memory, or tangible machine-readable memory for transmitting information in an electrical, optical, acoustic, or other form of propagated signal (e.g., carrier wave, infrared signal, digital signal, etc.) using the Internet. Thus, machine-readable media includes any type of machine-readable medium suitable for storing or transmitting electronic instructions or information in a machine- (e.g., computer-) readable form.

[0141] In the figures, some structural or method features may be shown in a particular arrangement and / or order. However, it should be understood that such a particular arrangement and / or ordering may not be required. Rather, in some embodiments, these features may be arranged in a different manner and / or order than that shown in the illustrative figures. Furthermore, the inclusion of structural or method features in a particular figure does not imply that such features are required in all embodiments, and in some embodiments, these features may not be included or may be combined with other features.

[0142] Note that each unit / module referred to in each device embodiment of the present application is a logical unit / module. Physically, one logical unit / module may be one physical unit / module, may be part of one physical unit / module, or may be realized by a combination of multiple physical units / modules. The physical realization of these logical units / modules themselves is not the most important thing; the combination of functions realized by these logical units / modules is the key to solving the technical problem proposed in the present application. Furthermore, in order to emphasize the innovative aspects of the present application, the device embodiments described in the present application do not introduce units / modules that are not particularly relevant to solving the technical problem presented in the present application. This does not imply that other units / modules are not present in the above-mentioned device embodiments.

[0143] It should be noted that in the examples and specification of this application, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another and do not necessarily require or imply that such an actual relationship or order exists between those entities or operations. Furthermore, the terms "comprise," "include," or any other variation thereof imply an inclusive and non-exclusive inclusion. Consequently, a process, method, article, or apparatus that includes a list of elements includes not only those elements but also other elements not expressly listed or that are inherent in such process, method, article, or apparatus. Absent further limitations, an element qualified by the phrase "including a" does not exclude the presence of other similar elements in the process, method, article, or apparatus that includes that element.

[0144] While the present application has been shown and described with reference to certain preferred embodiments thereof, those skilled in the art will recognize that various changes in form and detail can be made therein without departing from the spirit and scope of the present application.

Claims

1. A multi-tenant database partition method used in a system including a server on which an interception matching module including a data interception module, a region rule matching module, an organization structure interception module, and a tenant rule matching module is located, and a storage device that is a database, The data interception module obtains a request to perform an insurance transaction; The regional rule matching module matches the request with regional database information of a product management database in the database according to the product information and geographical region information in the request sent from the data interception module, where the product corresponds to a plurality of product regional databases in the database, and the product regional database includes product placement rules corresponding to insurance business operators; If the regional database information is matched, the regional rule matching module acquires a product placement rule from the product regional database, and acquires data required for performing insurance business based on the product placement rule; If the information does not match the regional database information, the organization configuration interception module acquires the requested tenant information, and the tenant rule matching module acquires data necessary for performing insurance business from the tenant database in the database based on the tenant information transmitted from the organization configuration interception module. Multi-tenant database partitioning method.

2. The method of claim 1, wherein the product management database in the database may be a lightweight directory access protocol, and the lightweight directory access protocol includes product information, geographical region information, and each product region database name, code, or route address corresponding to the product region database in the database.

3. Matching the request to the local database information of the product management database in the database 3. The method of claim 2, further comprising: searching a product management database based on the product information and the geographical area information to find a specific product area database name, code, or route address corresponding to the product information and the geographical area information.

4. The regional rule matching module acquires product placement rules from the product region database in the database, and acquires data necessary for executing insurance business based on the product placement rules. The method according to claim 1 or 3, further comprising: the regional rule matching module obtains product placement rules from a specific regional database corresponding to the product regional database in the database through a regional database connection string; and obtains data required for performing insurance business according to the product placement rules.

5. The product area database includes product placement rules corresponding to insurance business operators. The method according to claim 1, characterized in that the product region database includes a product placement rule defined by one insurance business practitioner or multiple product placement rules defined by multiple insurance business practitioners.

6. The method of claim 1 , wherein the product information includes a product name or product number.

7. 7. The method of claim 6, wherein the geographic region information includes an administrative region to which the product belongs or a custom region to which the product belongs.

8. 8. The method of claim 7, wherein the local database information includes a product local database name, code, or route address.

9. The data required to carry out insurance business is 9. The method according to claim 7 or 8, characterized in that the data includes at least one of content data of basic elements in an insurance policy and logical data for creating an insurance policy, checking the status of insurance business, or reviewing an insurance policy.

10. The database is 10. The method of claim 1, including a product management database, a product area database, and a tenant database.

11. A multi-tenant database partition device, comprising: a data receiving module for receiving data; a data transfer module for transferring data; an intercept matching module for intercepting data and matching the intercepted data to a geographic partition rule or a tenant partition rule; a business logic module for executing business logic; The intercept matching module a data interception module for obtaining first data including product information and geographic region information; a region rule matching module for matching a region partition rule based on the product information and the geographic region information; an organizational configuration interception module for obtaining second data including tenant information; a tenant rule matching module for matching tenant partition rules based on tenant information. A multi-tenant database partition device characterized by:

12. A computer-readable storage medium, comprising: A computer-readable storage medium storing instructions that, when executed on an electronic device, cause the electronic device to perform the multi-tenant database partitioning method of any one of claims 1 to 10.

13. a communication interface for inputting and / or outputting information; A chip device comprising: a processor for executing a computer-executable program to cause an electronic device equipped with the chip device to execute the multi-tenant database partitioning method described in any one of claims 1 to 10.

14. 1. A computer program product comprising: A computer program product comprising instructions for performing the multi-tenant database partitioning method according to any one of claims 1 to 10.

15. 1. An electronic device comprising: a memory for storing instructions to be executed by one or more processors of the electronic device; a processor that executes instructions stored in memory such that, when the instructions are executed by one or more processors of the electronic device, the electronic device implements the multi-tenant database partitioning method of any one of claims 1 to 10.

Images