Data query method, electronic device and storage medium

Abstract

Provided are a data query method, an electronic device and a computer readable storage medium. A public relation table is added between a first-stage table and sub-tables corresponding to the first-stage table in database design, wherein the public relation table comprises a single record corresponding to each sub-table needing to be associated, and represents the association relationship between a root node and other nodes in a relation tree.

Description

Data query method, electronic device and storage medium

[0001] This application claims priority to the Chinese patent application filed with the China Patent Office on December 15, 2023, with application number 202311736889.5 and application name “Data Query Method, Electronic Device and Storage Medium”. The entire contents of the above application are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of insurance and financial technology, and in particular to a data query method, an electronic device, and a computer-readable storage medium. Background Art

[0003] In the insurance and finance sector, breaking down insurance policies into policy elements and storing each element individually in a dynamically linked storage model facilitates the management and retrieval of policy information. To achieve this storage, policies can be broken down into Java objects with associated relationships and mapped to a relational database.

[0004] To achieve dynamic model association, the following two methods can be used:

[0005] (1) A one-to-many relationship is established on the Java entity class for all policy models that may have related relationships. However, each query requires polling all sub-tables that may have sub-items to be queried, resulting in redundant data query operations.

[0006] (2) Using the inheritance model in the Java persistence layer API, the association relationships are stored one by one in the public relationship table. Each time a record is read, it is necessary to query the public relationship table once to determine which sub-tables have the sub-items required for the query, and then read the records one by one in the sub-tables according to the unique identification code of the sub-item required to be queried in the public relationship table.

[0007] It can be seen from this that the above two methods of realizing dynamic model association will both generate redundant query operations and cannot realize batch query of insurance policies. The query process is relatively complex and time-consuming.

[0008] Summary of the Invention

[0009] The present application provides a data query method, electronic device, and computer-readable storage medium for use in electronic devices. This method adds a public relationship table between a first-level table and its corresponding sub-table in a database design. The public relationship table contains a single record corresponding to each sub-table to be associated, representing the relationship between the root node and other nodes in a relationship tree. This effectively reduces the number of data reads during database querying and increases data query efficiency.

[0010] In a first aspect, an embodiment of the present application provides a data query method, which is applied to an electronic device, the method comprising: obtaining a user's query request; querying a first-level table according to the query request, determining and reading a public relations table associated with the sub-item to be queried corresponding to the query request in the first-level table, wherein the first-level table is a table that can be queried based on the query request without passing through the public relations table, and the public relations table includes an association relationship between the first-level table and all sub-tables associated with the first-level table; determining one or more target sub-tables to be queried based on the association relationship and the query request, and querying the one or more target sub-tables to obtain all query results corresponding to the query request.

[0011] It should be understood that by adding a public relationship table between the first-level table and its corresponding sub-table in the database design, the public relationship table contains a single record corresponding to each sub-table that needs to be associated, representing the association relationship between the root node and other nodes in the relationship tree.

[0012] It should be noted that the public relations table does not directly maintain the association relationship between elements, but rather maintains one or more types of sub-objects corresponding to the first-level objects. The first-level objects are stored in a first-level table, and each type of sub-object is stored in a separate sub-table. Furthermore, the association relationship between the first-level objects in the first-level table and one or more types of corresponding sub-objects is stored as a public relations table. During the query of the first-level objects, a single read of the public relations table can be used to determine the corresponding multiple sub-tables, and then data can be read from the corresponding sub-tables. This effectively reduces the number of data reads during the database query process and increases data query efficiency.

[0013] It should be understood that the association relationship between elements can be maintained through specific records in the sub-table.

[0014] In a possible implementation of the first aspect, determining one or more target sub-tables to be queried based on the association relationship and the query request includes: determining one or more target sub-tables from multiple sub-tables associated with the public relationship table based on the query request.

[0015] It should be understood that in the process of determining one or more target sub-tables from multiple sub-tables associated with the public relation table based on the query request, the public relation table only needs to be read once, and the one or more target sub-tables can be queried in batches.

[0016] In a possible implementation of the first aspect above, determining one or more target sub-tables from multiple sub-tables associated with a public relations table includes: determining one or more sub-items in the public relations table according to a query request; and determining one or more associated sub-tables based on the one or more sub-items, wherein the sub-item is a single row of data in the foreign key column data of the public relations table.

[0017] It should be understood that the above one or more sub-items are single-row data in the foreign key column data of the public relation table, which can be used to query the associated sub-table.

[0018] In some embodiments, the above sub-item may be the table name of a sub-table.

[0019] In a possible implementation of the first aspect above, querying one or more target sub-tables to obtain all query results corresponding to the query request includes: batch acquiring multiple data records from the one or more target sub-tables according to query parameters of the query request; and integrating the multiple data records into query results.

[0020] It should be understood that by determining one or more target sub-tables, required data records can be obtained in batches from multiple data records in the one or more target sub-tables, and the queried data records can be integrated into query results and presented to the user.

[0021] In a possible implementation of the first aspect above, a foreign key of the public relationship table is associated with one or more target sub-tables.

[0022] It should be understood that the foreign key in the public relation table can be used to associate with one or more target sub-tables. For example, the foreign key can be the table name of each sub-table.

[0023] In a possible implementation of the first aspect above, the column data corresponding to the foreign key of the public relationship table does not contain duplicate row data.

[0024] It should be understood that each sub-item in the column data corresponding to the foreign key of the public relation table is unique, so that data query can be completed by reading the public relation table once, effectively improving query efficiency and avoiding redundant query times.

[0025] In a possible implementation of the first aspect above, the foreign key of the public relationship table includes the table name of each sub-table associated with the first-level table.

[0026] In some embodiments, the foreign key of the public relation table may be the table name of each sub-table associated with the first-level table, thereby facilitating batch query of each sub-table.

[0027] In a possible implementation of the first aspect above, a method for obtaining a public relations table includes: obtaining data to be stored; splitting at least one data element contained in the data to be stored, and determining an association relationship between at least one data element, wherein the data element is used to characterize a data category of the data; determining one or more categories of sub-elements corresponding to the first-level element based on the association relationship, and determining a public relations table based on the correspondence between the categories of the first-level element and the sub-elements.

[0028] It should be understood that data elements (hereinafter referred to as elements) can be used to represent the data category of specific data. Based on the data category, first-level elements and sub-elements of one or more categories corresponding to the first-level elements can be determined. In some embodiments, sub-objects can be used to represent one or more categories of sub-elements, and first-level objects can be used to represent first-level elements. Furthermore, by storing the first-level objects and one or more sub-objects associated with the first-level objects in the same table, a public relationship table can be constructed.

[0029] Then, when querying the first-level elements, multiple sub-objects of the category associated with the first-level elements can be queried in the public relations table. Each sub-object only occupies one data record, and each sub-object queried can point to a subordinate table. For example, by using the sub-object as the table name of the subordinate table, multiple data records in the subordinate table can be batch read in a single query of the public relations table.

[0030] In a second aspect, an embodiment of the present application further provides an electronic device comprising: one or more processors; one or more memories; one or more memories storing one or more instructions, which, when one or more instructions are executed by the one or more processors, enables the electronic device to execute the data query method provided by the first aspect and various possible implementations.

[0031] In a third aspect, an embodiment of the present application further provides a computer-readable storage medium, characterized in that instructions are stored on the storage medium, which, when executed on a computer, enable the computer to execute the data query method provided by the above-mentioned first aspect and various possible implementations.

[0032] In a fourth aspect, an embodiment of the present application further provides a computer program product, characterized in that it includes a computer program / instruction, which, when executed by a processor, implements the data query method provided in the above-mentioned first aspect and various possible implementations.

[0033] The beneficial effects of the second to fourth aspects mentioned above can be found in the relevant descriptions of the first aspect and various possible implementations of the first aspect, and will not be elaborated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] FIG1 shows a schematic diagram of a storage scenario of associated data according to an embodiment of the present application;

[0035] FIG2 shows a schematic diagram of a storage structure of a Java entity class construction model;

[0036] FIG3 shows a schematic diagram of a storage structure based on the JPA inheritance model;

[0037] FIG4A shows a schematic diagram of an implementation process of a data query method according to an embodiment of the present application;

[0038] FIG4B shows a schematic structural diagram of a Java object association model according to some embodiments of the present application;

[0039] FIG4C shows a schematic structural diagram of a database element association model according to some embodiments of the present application;

[0040] FIG5 shows a schematic diagram of a storage structure of a database instance according to an embodiment of the present application;

[0041] FIG6 shows a schematic diagram of a relationship tree and table association relationships according to an embodiment of the present application;

[0042] FIG7 shows a schematic diagram of a specific implementation process of database query according to an embodiment of the present application;

[0043] FIG8 is a flow chart showing a specific implementation method for constructing a public relationship table according to an embodiment of the present application;

[0044] FIG9 shows a block diagram of a server 200 according to an embodiment of the present application. DETAILED DESCRIPTION

[0045] In order to make the purpose, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be described in detail below with reference to the accompanying drawings and specific implementation methods.

[0046] The illustrative embodiments of the present application include, but are not limited to, a data query method, an electronic device, and a computer-readable storage medium.

[0047] It is understood that the terminal devices applicable to the present application may be mobile phones, tablet computers, desktop computers, laptop computers, handheld computers, netbooks, augmented reality (AR) / virtual reality (VR) devices, smart TVs, smart watches, etc., as well as those having one or more processors embedded or coupled therein, without limitation herein.

[0048] It can be understood that the electronic devices applicable to the present application may include servers, wherein the applicable servers may be cloud servers, physical servers, large-bandwidth servers, high-defense servers, dedicated line servers or group servers and other rental-type servers. In addition, the applicable servers may be complex instruction set computing (CISC) architecture servers or reduced instruction set computing (RISC) architecture servers, and there is no limitation here.

[0049] In order to facilitate understanding of the technical solutions provided by the embodiments of the present application, the meanings of some related field terms involved in the embodiments of the present application are explained below.

[0050] (1) Java persistence API (JPA) is a set of object-relational mapping specifications on the Java EE platform, used to map Java objects to relational databases.

[0051] (2) Multi-table association query is to use one entity class object to operate or query data in multiple tables.

[0052] (3) Databases are used to store a large number of data entities. Database design is the process of planning and structuring the data entities in the database and the relationships between these data entities.

[0053] (4) Data entity. In terms of databases, an entity often refers to a set of individual data corresponding to a certain type of data object. Each data entity can use a data table structure to record the individual data corresponding to the data object, as well as the relationship between the individual data. Therefore, the data table structure of each data entity can include one or more interrelated data tables, and the primary keys of the data tables are interrelated. For example, the primary key of one data table can be the foreign key of another data table.

[0054] (5) A data table consists of three parts: the table name, the fields in the table, and the records in the table. Designing a data table structure (hereinafter referred to as the table structure) means defining the data table file name, determining the fields in the data table, the field name, field type, and width of each field, and then inputting this data into the computer.

[0055] (6) Primary key refers to a column or combination of columns in a data table whose value uniquely identifies each row in the table. The primary key of a data table can be linked to the foreign keys of other tables to link the addition, deletion, change / modification of field text in other data tables.

[0056] (7) An association table, also known as a join table, intermediate table, or bridge table, is a common structure in database design used to represent a many-to-many relationship between two tables in a relational database. In a many-to-many relationship, entries in one table can be associated with multiple entries in another table. An association table typically contains two or more foreign keys, each of which corresponds to the primary key of the other child table. An association table can also contain additional information about the relationship, such as a timestamp, weight, etc.

[0057] The following describes in detail the scenario of calculating premiums based on hard-coded calculation rules with reference to FIG1 .

[0058] FIG1 shows a schematic diagram of a storage scenario of associated data according to an embodiment of the present application.

[0059] Referring to Figure 1, this scenario includes data interaction between a terminal 100 and a server 200. The terminal 100 can be connected to the server 200, which can be a cloud server. The server 200 can provide a server cluster environment for the database to read and write data in the server cluster environment, thereby providing data storage services to the terminal 100.

[0060] A user or platform operator of the corresponding business system can run a business system application through terminal 100. For example, the business system may be insurance business system 101, and the user may be an insurance agent. The insurance agent can log in to a system account on insurance business system 101 running on terminal 100 and store or read policy information from the database on server 200. For example, to read policy information, the insurance agent can send a query request for policy information to the database on server 200 and then retrieve a query result from the database, which contains the policy information corresponding to the query request.

[0061] It should be understood that the terminal 100 can provide the user with an application interface of the insurance business system 101 for querying insurance policy information, thereby obtaining the user's query request and sending the query request to the database in the server 200. Furthermore, the database determines a query result containing insurance policy information based on the query request and sends it to the terminal 100 for provision to the user.

[0062] In some implementations, a one-to-many association is established on a Java entity class for all policy models that may have an associated relationship. Referring to Figure 2, a one-to-many policy model is established in the Java entity class based on each policy element. For example, the "Policy" element may be associated with "Insured," "Line of Business (LOB) Information," "Form," "Coverage," "Schedule 1," and "Schedule 2," generating a one-to-many association. If a query request detects that the "Policy" element is being queried, the "Insured" subtable, "Line of Business (LOB) Information," "Form," "Coverage," "Schedule 1," and "Schedule 2" subtables pointing to "Policy" can be queried. Furthermore, each time a new object type is added, the associations of other objects must be adjusted and new associations added. Furthermore, each query requires polling the subtables corresponding to all query sub-items associated with the query element, resulting in redundant data query operations.

[0063] It can be understood that the above elements can represent the data category of specific data.

[0064] In other embodiments, the inheritance pattern in JPA is used to store the association relationships one by one in the public relation table. Referring to Figure 3, the public relation table includes tables 301 to 308, wherein table 302 containing the "insured" element points to table 301, and table 303 containing the "policy list" element points to table 302 and table 301 containing the "insured" element. Similarly, tables 304 to 308 all point to table 301. Moreover, each record in the public relation table corresponds to a record in the database. For example, if the number of "insured unique identification codes (insured ID)" in table 302 is "19", then there are a total of 19 "insured unique identification codes" in table 302, and they correspond one-to-one to the 19 records corresponding to the total 19 "insured unique identification codes" in the database.

[0065] It should be understood that if a relational database with a public relation table is to be queried for a record, it is unavoidable to query the public relation table. For example, to query a record by referring to the policy element unique identifier "001," it is necessary to determine which subtables in public relation table 301 contain the policy element unique identifier "001" required for the query. Then, the records in each subtable corresponding to the policy element unique identifier "001" in public relation table 301 must be retrieved.

[0066] In order to avoid the problem of multiple readings of the public relations table, an embodiment of the present application provides a data query method by adding a public relations table between the first-level table and its corresponding sub-table in the database design. The public relations table contains a single record corresponding to each sub-table that needs to be associated, representing the association relationship between the root node and other nodes in the relationship tree.

[0067] It should be noted that the public relations table does not directly maintain the association relationship between elements, but rather maintains one or more types of sub-objects corresponding to the first-level objects. The first-level objects are stored in a first-level table, and each type of sub-object is stored in a separate sub-table. Furthermore, the association relationship between the first-level objects in the first-level table and one or more types of corresponding sub-objects is stored as a public relations table. When querying the first-level objects, a single read of the public relations table can determine the corresponding multiple sub-tables, and then read data from the corresponding sub-tables. It should be understood that the association relationship between elements can be maintained through the specific records of the sub-tables.

[0068] Thus, in the scenario of server-terminal device interaction shown in FIG1 , when server 200 detects a query request sent by the business system running on terminal device 100, server 200 only needs to read the public relations table once to accurately locate one or more sub-tables associated with the first-level table, enabling a single read of the public relations table to batch query multiple policy data records in the database. This effectively reduces the number of data reads during the database query process and increases data query efficiency.

[0069] For example, when it is necessary to query multiple insured persons in a single insurance policy and multiple liabilities agreed upon by multiple insured persons in the insurance policy, the associated subtables of the insurance policy table include the "insured" subtable and the "liability" subtable. Set up a public relations table corresponding to a single record in the insurance policy table, and set a foreign key pointing to each subtable in the public relations table. When the server 200 queries multiple insured persons and multiple liabilities in the insurance policy table, it is only necessary to read the public relations table once to read multiple records in the "insured" subtable and the "liability" subtable based on the column data corresponding to the foreign key. This achieves a single read of the public relations table to obtain batch data records. Compared to the implementation method of reading the public relations table at least once for each subtable queried in the scenario shown in Figure 3 above, the present application can effectively reduce the number of data reads in the database query process and improve query efficiency.

[0070] Based on the scenario shown in FIG1 above, FIG4A shows a schematic diagram of an implementation process of a data query method according to an embodiment of the present application. It is understood that the execution entity of each step shown in FIG4A can be the server 200 in the scenario shown in FIG1. ​​Specifically, the implementation process may include the following steps:

[0071] S401: Obtain a user's query request.

[0072] Exemplarily, the server 200 may obtain a query request of the user from the terminal 100. The query request includes query parameters for determining an object to be queried.

[0073] S402 : Read the public relation table once according to the query request, and determine a target sub-table from multiple sub-tables associated with the public relation table.

[0074] For example, the server 200 may determine the public relations table to be read based on the query parameters in the query request. The public relations table may contain foreign keys associated with multiple sub-tables, and the sub-tables may be queried by associating each sub-item in the foreign key with the sub-table. In some embodiments, the foreign key of the public relations table may be the table name of the associated sub-table. The query parameters may be used to determine the name of the sub-table to be queried by the user, and then the target sub-table to be queried is determined from the multiple sub-tables associated with the public relations table.

[0075] It should be understood that the above-mentioned public relationship table is an association table corresponding to each record in the table specified by the query request (ie, the first-level table).

[0076] The following describes in detail the construction method of the public relationship table with reference to FIG. 4B and FIG. 4C .

[0077] Figure 4B shows a schematic diagram of the structure of a Java object association model according to some embodiments of the present application. Figure 4C shows a schematic diagram of the structure of a database element association model according to some embodiments of the present application.

[0078] Referring to Figure 4B , within a Java object, an inheritance relationship of multiple elements is constructed. For example, multiple insured persons correspond to a single insurance policy, and each insured person has multiple liabilities, where a liability is the insurance liability stipulated in the policy. Thus, the multiple relationships contained within a single insurance policy can be generated as multiple relationship objects. These multiple relationship objects can be mapped to a database and integrated into a common relationship table. These relationship objects can be, for example, Java objects.

[0079] It should be understood that the insured relationship can be used to represent the logical association relationship between insureds, such as the mother-child relationship, the husband-wife relationship, etc.; and the above-mentioned liability relationship can be used to represent the insurance liability stipulated in the insurance policy. The insurance liability usually has an association relationship with each insured. For example, if the insured A is insured with critical illness insurance, then all the insurance liabilities of the critical illness insurance can be stipulated in the insurance policy of the insured A through the agreement. At this time, the critical illness insurance liability has a logical association relationship with the insured A. Therefore, multiple association relationships can be set to inherit the logical association relationship between the insurance policy and the insured contained in the insurance policy, and inherit the logical association relationship between the insurance policy and the liabilities contained in the insurance policy. In the Java object association model, the "relationship" object can contain two element objects, one is the "insured relationship" object, and the other is the "liability relationship" object. At this time, the "relationship" object can be used to represent the association relationship between multiple insureds and the above-mentioned single insurance policy and the association relationship between multiple liabilities and the above-mentioned single insurance policy.

[0080] Furthermore, by mapping the Java object association model shown in FIG. 4B to the database, the database element association model shown in FIG. 4C can be obtained.

[0081] Referring to Figure 4C , in the Java object association model, "Relationship" objects can be used to represent multiple relationships within an insurance policy. Each relationship defines information about multiple associated elements. Therefore, a public relationship table can be established in the database to encompass the multiple relationships contained within the "Relationship" object. For example, an insurance policy can be mapped to a public relationship table containing multiple relationships. This public relationship table can be used to directly search for all of the policy's relationships, specifically the subtable containing the "Insured" element and the subtable containing the "Liability" element. In this case, a single read of the public relationship table is sufficient to directly query all required subtables, facilitating batch acquisition of all required subitems.

[0082] S403: Acquire multiple data records from the target sub-table in batches according to the query request.

[0083] Illustratively, the server 200 may determine the target sub-item from the target sub-table according to the query parameters of the query request, and then obtain multiple data records including the target sub-item.

[0084] For example, if the query parameters in a query request require information about the policy liability for Insured A in policy "001," the policy table can be queried to determine the corresponding public relations table, and the "Insured" and "Liability" sub-items can be selected from the foreign key columns in the public relations table. The data record for Insured A can then be determined from the "Insured" sub-table associated with the "Insured" sub-item, and the data record containing the parameter "Insured A" can be retrieved from the "Liability" sub-table associated with the "Liability" sub-item. This allows server 200 to batch query multiple sub-tables and retrieve multiple data records from each sub-table by simply reading the public relations table once.

[0085] S404: Integrate multiple data records into a query result.

[0086] For example, the server 200 may integrate multiple data records into a single file, and send the file as a query result to the terminal 100 to provide to the user.

[0087] It should be understood that through the above steps S401 to S404, by designing a public relations table in the database, after obtaining the user's query request, the server 200 only needs to read the public relations table once to query multiple sub-tables associated with the public relations table, and can batch query multiple data records from each sub-table, thereby improving query efficiency.

[0088] In some embodiments, each record in the public relations table is unique, so each sub-table only occupies a single record in the public relations table, reducing database capacity usage. In addition, if a user performs data processing such as adding, deleting, modifying, or querying data in the database of server 200 through terminal 100 as shown in FIG1 , there is no need to modify each data object as shown in FIG2 . Instead, it is only necessary to maintain the logical associations between objects (i.e., many-to-one or one-to-many relationships) shown in FIG4B and FIG4C and the associations between the foreign keys of the public relations table and the sub-tables, effectively reducing the amount of data to be maintained and processed, saving time and effort.

[0089] The database instance in the embodiment of the present application is described in detail below with reference to FIG5 and FIG6.

[0090] Figure 5 shows a schematic diagram of a storage structure of a database instance according to an embodiment of the present application. Figure 6 shows a schematic diagram of a structure of a relationship tree and table association relationships according to an embodiment of the present application.

[0091] Referring to Figure 5, in the database instance of an embodiment of the present application, the sub-items contained in the policy table 501 are associated with the four sub-items in the element information table 502, and the element information table 502 is associated with other sub-tables through the four sub-items. For example, the record of "policy product line information" in the element information table is associated with the policy product line information table 503.

[0092] Refer to Figure 6, which is the structure of the relationship tree and table association relationship of the database instance shown in Figure 5. Among them, the insurance policy is the root node of the relationship tree, and the root node "insurance policy" is associated with other second-level nodes through the first-level node "element information". It should be understood that the data table corresponding to the "insurance policy" root node is the insurance policy table 501, and the data table corresponding to the first-level node "element information" is the element information table 502. Furthermore, according to the association relationship of "root node ← first-level node ← second-level node" in the relationship tree, the database association structure of "first-level table ← public relationship table ← one or more sub-tables" can be obtained. Therefore, if you need to query the data corresponding to the second-level node, you only need to query the first-level node of "element information" once, that is, if you need to query the data records in one or more sub-tables, you only need to read the public relationship table once.

[0093] For example, referring back to Figure 5, element information table 502 is the public relation table for the root node "Policy." It uses the foreign key "Sub-element Type" to store the table names corresponding to all child nodes associated with the root node "Policy," such as "Policy Customer," "Policy Product Line Information," "Insured," and "Insurance Liability." Furthermore, element information table 502 can be linked to the primary key "Element ID" of the Policy Product Line Information table 503, the primary key "Element ID" of the Insured table 504, and the primary key "Element ID" of the Liability table 505 through the foreign key "Sub-element Type." Therefore, if you need to query the three data records with element IDs "205," "206," and "207" in liability table 505, you only need to read the public relations table (i.e., element information table 502) once, and link it to liability table 505 through the sub-item "insurance liability" in the foreign key column of element information table 502, thereby batch reading the three data records with element IDs "205," "206," and "207" in liability table 505. Compared to the public relations table in the example of Figure 3 above, if you need to query three records, you need to read the public relations table three times, resulting in a redundant query process.

[0094] Based on the database examples shown in Figures 5 and 6 above, Figure 7 shows a schematic diagram of a specific implementation process of database query according to an embodiment of the present application.

[0095] It is understood that the execution entity of each step shown in Figure 7 may be the server 200 in the scenario shown in Figure 1. Specifically, the implementation process may include the following steps:

[0096] S701: The terminal 100 detects a query statement input by a user and generates a query request according to the query statement.

[0097] For example, the terminal 100 may provide the user with a query statement input function through an interface provided by the business system, thereby facilitating the terminal 100 to generate a corresponding query request according to the query statement.

[0098] S702 , the terminal 100 sends a query request to the server 200 .

[0099] Exemplarily, the terminal 100 may send a query request to the server 200 via a wired or wireless manner.

[0100] S703: The server 200 searches for a target sub-item in the first-level table according to the query parameters in the query request, and determines a related public relationship table according to the target sub-item.

[0101] For example, server 200 searches for the target sub-item to be queried in the first-level table based on the query parameters in the query request. For example, server 200 can obtain the policy's unique identification code (e.g., policy ID or policy number) by parsing the query request, thereby determining the policy sub-item to be queried. Furthermore, server 200 can search for the public relation table corresponding to the target sub-item based on the foreign key contained in the target sub-item.

[0102] For example, referring to the scenario shown in Figure 5 above, the server 200 parses the query request to find that the query is for an insurance policy, and the policy number is "000000001", then the insurance policy table 501 can be queried, and the row data of the example in Figure 5 can be used as the target sub-item based on the policy number.

[0103] Furthermore, the corresponding public relation table is found according to the foreign key contained in the row data. The foreign key is the column data used to associate with the public relation table. Then the column data "201" as the foreign key in the current sub-item can be associated with the public relation table 502.

[0104] S704: The server 200 determines one or more sub-items of the public relationship table according to the query request, and determines one or more associated sub-tables according to the one or more sub-items.

[0105] Exemplarily, server 200 may select one or more sub-items of the public relations table based on the query parameters included in the query request. It should be understood that the public relations table includes foreign keys, and the column data containing the foreign keys may be the names of sub-tables. Selecting one or more sub-items of the public relations table involves selecting the names of one or more sub-tables to be queried, and then querying the data of each sub-table based on the association between the foreign keys of the public relations table and the sub-tables.

[0106] For example, referring to the scenario shown in Figure 5 above, the element information table 502 is a public relationship table, and the foreign key of the element information table 502 is the column data with the attribute "sub-element type". Each row in the column data of "sub-element type" can be associated with a sub-table. For example, it can be associated with the responsibility table 505 based on the row data with the sub-element type of "responsibility", so that multiple row data in the responsibility table 505 can be batch queried by reading the element information table 502 once.

[0107] In some embodiments, when the server 200 first obtains the insurance policy data that needs to be written into the database, it can construct a JPA association based on the relational table according to the logical association relationship between the elements in the insurance policy data, forming a database association relationship model as shown in Figure 4C above, and obtaining a data storage structure of the first-level table ← public relationship table ← one or more sub-tables.

[0108] It can be understood that, in the process of the server 200 reading the insurance policy, the logical association relationship between the first-level table and its sub-tables can be rebuilt based on the association relationship in the public relationship table.

[0109] S705: The server 200 obtains multiple data records from the determined one or more sub-tables according to the query request.

[0110] Exemplarily, the server 200 may obtain one or more data records from the determined one or more sub-tables according to the query parameters of the query request.

[0111] For example, referring to the scenario shown in FIG5 , server 200 can determine, based on the query parameters, that the sub-tables to be queried are "Insured" table 504 and "Liability" table 505. It can then query "Insured" table 504 by reading the "Insured" sub-item of the sub-element type in element information table 502, and query "Liability" table 504 by reading the "Policy Liability" sub-item of the sub-element type in element information table 502. Furthermore, it is possible to batch query one or more rows of data in "Insured" table 504 and one or more rows of data in "Liability" table 505 by reading element information table 502 once.

[0112] It should be understood that one row of data in the above text may correspond to one data record.

[0113] S706: The server 200 integrates the acquired multiple data records into a query result.

[0114] Exemplarily, the server 200 integrates the acquired multiple data records into a data set as a query result, so as to facilitate returning it to the terminal 100 .

[0115] S707 , the server 200 sends the query result to the terminal 100 .

[0116] Exemplarily, the server 200 may return the query result to the terminal 100 via a wired or wireless manner.

[0117] S708: The terminal 100 displays the query result.

[0118] Exemplarily, the terminal 100 may provide the query result to the user via a display screen.

[0119] It can be understood that through the above steps S701 to S708, the server 200 queries the first-level table based on the query parameters in the obtained query request, and then determines the corresponding public relations table based on the first-level table. By reading the public relations table once, the sub-items serving as foreign keys in the public relations table and the query parameters are determined to determine one or more sub-tables to be queried, and then one or more data records are batch-acquired from the one or more sub-tables as query results, which are returned to the terminal 100. As a result, the server 200 only needs to read the public relations table once to determine the sub-tables to be queried from the public relations table, thereby accelerating the query process.

[0120] The specific implementation method process of constructing the public relationship table in the embodiment of the present application is described in detail below based on Figure 8.

[0121] It is understood that the execution entity of each step shown in Figure 8 may be the server 200 in the scenario shown in Figure 1. Specifically, the implementation process may include the following steps:

[0122] S801: Acquire service data sent by the terminal 100.

[0123] Exemplarily, referring to the scenario shown in FIG1 , the server 200 may obtain the business data sent by the insurance business system in the terminal 100 in a wired or wireless manner.

[0124] S802: Determine elements and relationships between elements based on business data.

[0125] For example, multiple elements can be split according to business data, multiple elements can be split according to the insurance policy content that needs to be stored, and the logical relationship between the elements can be determined.

[0126] For example, referring to the scenario shown in Figure 4B, the "policy" element, the "insured" element, and the "liability" element can be determined for the agreement content contained in the insurance policy. Furthermore, the corresponding relationship between the elements can be determined. For example, if the policy element contains multiple insureds, the insured element can contain multiple liabilities.

[0127] S803: Construct a JPA association based on the association table according to the association relationship between the elements to obtain a public relationship table.

[0128] Exemplarily, the server 200 maps the logical association relationship between elements to the database storage space to construct a JPA association based on a relation sheet in the database, and further constructs a public relation table of the business data to be stored.

[0129] It is understood that the aforementioned elements can represent the data category of specific data, and based on the data category of the data, a first-level element and one or more sub-elements of the corresponding categories can be determined. In some embodiments, sub-objects can be used to represent one or more categories of sub-elements, and first-level objects can be used to represent first-level elements. Furthermore, by storing the first-level objects and one or more sub-objects associated with the first-level objects in the same table, a public relationship table can be constructed.

[0130] Then, when querying the first-level elements, multiple sub-objects of the category associated with the first-level elements can be queried in the public relations table. Each sub-object only occupies one data record, and each sub-object queried can point to a subordinate table. For example, by using the sub-object as the table name of the subordinate table, multiple data records in the subordinate table can be batch read in a single query of the public relations table.

[0131] [Corrected 19.04.2024 in accordance with Rule 91] For example, referring to Figure 5, information on multiple policy product lines, insureds, and policy liabilities corresponding to an insurance policy can be added to the public relation table as foreign keys. In some embodiments, if duplicate subkey values ​​appear within the foreign key, for example, two "insureds," the duplicates can be deleted. This ensures that each row of data in the public relation table's foreign key column corresponds to a specific subtable, reducing storage space and avoiding redundant query processing during data queries.

[0132] It should be understood that through the above steps S801 to S803, logical association relationships and JPA association relationships between elements in business data can be constructed in the process of storing business data on the server 200, and then in the subsequent process of updating and maintaining the database, the logical association relationships and JPA association relationships between data can be maintained at the same time, reducing maintenance costs.

[0133] FIG9 shows a block diagram of a server 200 according to an embodiment of the present application. In some embodiments, the server 200 may include one or more processors 804, a system control logic 808 connected to at least one of the processors 804, a system memory 812 connected to the system control logic 808, a non-volatile memory (NVM) 816 connected to the system control logic 808, and a network interface 820 connected to the system control logic 808.

[0134] In some embodiments, the processor 804 may include one or more single-core or multi-core processors. In some embodiments, the processor 804 may include any combination of general-purpose processors and specialized processors (e.g., graphics processors, application processors, baseband processors, etc.). In embodiments where the server 200 employs an enhanced base station (evolved node b, eNB) 101 or a radio access network (RAN) controller 102, the processor 804 may be configured to execute various embodiments.

[0135] In some embodiments, system control logic 808 may include any suitable interface controller to provide any suitable interface to at least one of processors 804 and / or any suitable device or component in communication with system control logic 808 .

[0136] In some embodiments, the system control logic 808 may include one or more memory controllers to provide an interface to the system memory 812. The system memory 812 may be used to load and store data and / or instructions. In some embodiments, the memory 812 of the server 200 may include any suitable volatile memory, such as a suitable dynamic random access memory (DRAM).

[0137] NVM / memory 816 may include one or more tangible, non-transitory computer-readable media for storing data and / or instructions. In some embodiments, NVM / memory 816 may include any suitable non-volatile memory such as flash memory and / or any suitable non-volatile storage device, such as at least one of a hard disk drive (HDD), a compact disc (CD) drive, and a digital versatile disc (DVD) drive.

[0138] NVM / storage 816 may include a portion of storage resources on the device where server 200 is installed, or it may be accessible to the device but not necessarily part of the device. For example, NVM / storage 816 may be accessed over a network via network interface 820.

[0139] In particular, system memory 812 and NVM / storage 816 may respectively include a temporary copy and a permanent copy of instructions 824. Instructions 824 may include instructions that, when executed by at least one of processors 804, cause server 200 to implement the aforementioned data query method. In some embodiments, instructions 824, hardware, firmware, and / or software components thereof may additionally or alternatively be located in system control logic 808, network interface 820, and / or processor 804.

[0140] The network interface 820 may include a transceiver for providing a radio interface for the server 200, thereby communicating with any other suitable devices (such as a front-end module, an antenna, etc.) via one or more networks. In some embodiments, the network interface 820 may be integrated with other components of the server 200. For example, the network interface 820 may be integrated with at least one of the processor 804, the system memory 812, the NVM / storage 816, and a firmware device (not shown) having instructions. When at least one of the processors 804 executes the instructions, the server 200 implements the above-described data query method.

[0141] The network interface 820 may further include any suitable hardware and / or firmware to provide a multiple-input multiple-output radio interface. For example, the network interface 820 may be a network adapter, a wireless network adapter, a telephone modem, and / or a wireless modem.

[0142] In one embodiment, at least one of the processors 804 may be packaged together with logic for one or more controllers of the system control logic 808 to form a system-in-package (SiP). In one embodiment, at least one of the processors 804 may be integrated on the same die with logic for one or more controllers of the system control logic 808 to form a system-on-chip (SoC).

[0143] Server 200 may further include input / output (I / O) devices 832. I / O devices 832 may include a user interface to enable a user to interact with server 200, and peripheral component interfaces to enable peripheral components to interact with server 200. In some embodiments, server 200 may also include sensors for determining at least one of environmental conditions and location information related to server 200.

[0144] In some embodiments, the user interface may include, but is not limited to, a display (e.g., an LCD display, a touch screen display, etc.), a speaker, a microphone, one or more cameras (e.g., a still image camera and / or a video camera), a flashlight (e.g., an LED flash), and a keyboard.

[0145] In some embodiments, the peripheral component interface may include, but is not limited to, a non-volatile memory port, an audio jack, and a power interface.

[0146] In some embodiments, the sensors may include, but are not limited to, a gyroscope sensor, an accelerometer, a proximity sensor, an ambient light sensor, and a positioning unit. The positioning unit may also be part of or interact with the network interface 820 to communicate with components of a positioning network (e.g., Global Positioning System (GPS) satellites).

[0147] According to the method provided in the embodiments of the present application, the present application also provides a computer program product, which includes: computer program code, which, when executed on a computer, enables the computer to implement the steps performed by the server 200 in any one of the above embodiments.

[0148] According to the method provided in the embodiments of the present application, the present application also provides a computer-readable medium, which stores program code. When the program code runs on a computer, the computer implements the steps performed by the server 200 in any of the above embodiments.

[0149] The various embodiments disclosed in this application can be implemented in hardware, software, firmware, or a combination of these implementation methods. The embodiments of the present application can be implemented as a computer program or program code executed on a programmable system, which includes 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.

[0150] Program code can be applied to input instructions to perform the functions described herein and generate output information. The output information can be applied to one or more output devices in a known manner. For purposes of this application, a processing system includes any system having a processor such as, for example, a digital signal processor (DSP), a microcontroller, an application specific integrated circuit (ASIC), or a microprocessor.

[0151] Program code can be implemented with a high-level programming language or an object-oriented programming language to communicate with the processing system. Where necessary, program code can also be implemented in assembly language or machine language. In fact, the mechanism described in this application is not limited to the scope of any particular programming language. In either case, the language can be a compiled language or an interpreted language.

[0152] 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 or stored on one or more temporary or non-temporary 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 through other computer-readable media. Therefore, a machine-readable medium may include any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer), including but not limited to floppy disks, optical disks, optical discs, read-only memories (CD-ROMs), magneto-optical disks, read-only memories (ROMs), random access memories (RAMs), erasable programmable read-only memories (EPROMs), electrically erasable programmable read-only memories (EEPROMs), magnetic or optical cards, flash memory, or a tangible machine-readable memory for transmitting information (e.g., carrier waves, infrared signals, digital signals, etc.) using the Internet in electrical, optical, acoustic, or other forms of propagation signals. Therefore, a machine-readable medium includes any type of machine-readable medium suitable for storing or transmitting electronic instructions or information in a form readable by a machine (e.g., a computer).

[0153] In the accompanying drawings, 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 order may not be required. Rather, in some embodiments, these features may be arranged in a manner and / or order different from that shown in the illustrative drawings. In addition, the inclusion of a structural or method feature in a particular figure does not imply that such feature is required in all embodiments, and in some embodiments, such features may not be included or may be combined with other features.

[0154] It should be noted that the units / modules mentioned in the various device embodiments of the present application are all logical units / modules. Physically, a logical unit / module can be a physical unit / module, or a part of a physical unit / module, or can be implemented as a combination of multiple physical units / modules. The physical implementation of these logical units / modules themselves is not the most important. The combination of functions implemented by these logical units / modules is the key to solving the technical problems raised by this application. In addition, in order to highlight the innovative part of this application, the above-mentioned device embodiments of this application do not introduce units / modules that are not closely related to solving the technical problems raised by this application. This does not mean that other units / modules do not exist in the above-mentioned device embodiments.

[0155] It should be noted that in the examples and description of this patent, relational terms such as first and second, etc. are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device that includes a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the sentence "including a" does not exclude the presence of other identical elements in the process, method, article or device that includes the element.

[0156] While the present application has been shown and described with reference to certain embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the scope of the present application.

Claims

1. A data query method, applied to an electronic device, characterized in that: The method comprises: Get the user's query request; querying the first-level table according to the query request, determining and reading a public relation table associated with the sub-item to be queried corresponding to the query request in the first-level table, wherein the first-level table is a table that can be queried based on the query request without passing through the public relation table, and the public relation table includes an association relationship between the first-level table and all sub-tables associated with the first-level table; One or more target sub-tables to be queried are determined based on the association relationship and the query request, and the one or more target sub-tables are queried to obtain all query results corresponding to the query request.

2. The method according to claim 1, characterized in that The determining one or more target sub-tables to be queried based on the association relationship and the query request includes: One or more target sub-tables are determined from a plurality of sub-tables associated with the public relationship table based on the query request.

3. The method according to claim 2, characterized in that The determining one or more target sub-tables from the plurality of sub-tables associated with the public relationship table comprises: Determine one or more sub-items in the public relationship table according to the query request; One or more associated sub-tables are determined according to one or more sub-items, wherein the sub-item is a single row of data in the foreign key column data of the public relationship table.

4. The method according to claim 1, characterized in that: The querying the one or more target sub-tables to obtain all query results corresponding to the query request includes: Batch acquiring multiple data records from one or more of the target sub-tables according to the query parameters of the query request; The multiple data records are integrated into a query result.

5. The method according to claim 2, characterized in that: The foreign key of the public relation table is associated with one or more of the target sub-tables.

6. The method according to claim 5, characterized in that The column data corresponding to the foreign key of the public relationship table does not contain duplicate row data.

7. The method according to claim 5, characterized in that The foreign key of the public relationship table includes the table name of each sub-table associated with the first-level table.

8. The method according to claim 1, characterized in that The method of obtaining the public relation table includes: Get the data to be stored; Splitting at least one data element contained in the data to be stored, and determining an association relationship between the at least one data element, wherein the data element is used to characterize a data category of the data; One or more categories of sub-elements corresponding to the first-level element are determined according to the association relationship, and a public relationship table is determined according to the correspondence between the first-level element and the categories of the sub-elements.

9. An electronic device, characterized in that: include: one or more processors; One or more memories; the one or more memories store one or more instructions, and when the one or more instructions are executed by the one or more processors, the electronic device executes the data query method according to any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that: The storage medium stores instructions, which, when executed on a computer, enable the computer to execute the data query method according to any one of claims 1 to 8.

Images