Query instruction generation method and related apparatus

Abstract

The application provides a query instruction generation method and related devices. The method comprises: discovering an implicit association relationship between tables based on historical query instructions of an analysis database, and dynamically updating a table relationship graph; wherein the table relationship graph comprises nodes and edges connecting the nodes; each node corresponds to a table of the database, and the implicit association relationship constitutes the edges connecting the nodes; in response to a received natural language query statement, determining at least one candidate connection path in the table relationship graph; wherein the candidate connection path comprises a plurality of nodes connected by edges; the nodes in the candidate connection path cover fields related to semantics of the natural language query statement; and generating a query instruction corresponding to the natural language query statement according to the at least one candidate connection path. The application can improve the accuracy of data query to a certain extent.

Description

Technical Field

[0001] One or more embodiments of this application relate to the field of database querying, and more particularly to a query instruction generation method and related apparatus. Background Technology

[0002] In the field of database query and natural language query conversion, existing technologies typically convert natural language query statements into corresponding query instructions based on predefined table structure relationships, explicit foreign key relationships, or manually configured table association rules in the database.

[0003] However, existing technologies still face the problem of accurately generating query instructions based on natural language query statements. Summary of the Invention

[0004] In view of this, one or more embodiments of this application provide a query instruction generation method and related apparatus, which can improve the accuracy of data query to a certain extent.

[0005] In a first aspect, one or more embodiments of this application propose a method for generating query instructions for a database, comprising: discovering implicit relationships between tables based on parsing historical query instructions of the database, and dynamically updating a table relationship graph; wherein the table relationship graph includes nodes and edges connecting the nodes; each node corresponds to a table in the database, and the implicit relationships constitute the edges connecting the nodes; in response to a received natural language query statement, determining at least one candidate connection path in the table relationship graph; wherein the candidate connection path includes multiple nodes connected by edges; the nodes in the candidate connection path cover the fields involved in the semantics of the natural language query statement; and generating a query instruction corresponding to the natural language query statement based on the at least one candidate connection path.

[0006] Secondly, one or more embodiments of this application propose a query instruction generation apparatus for a database, comprising: an update module, configured to discover implicit relationships between tables based on parsing historical query instructions of the database, and dynamically update a table relationship graph; wherein the table relationship graph includes nodes and edges connecting the nodes; each node corresponds to a table in the database, and the implicit relationships constitute the edges connecting the nodes; a determination module, configured to determine at least one candidate connection path in the table relationship graph in response to a received natural language query statement; wherein the candidate connection path includes multiple nodes connected by edges; the nodes in the candidate connection path cover the fields involved in the semantics of the natural language query statement; and a generation module, configured to generate a query instruction corresponding to the natural language query statement based on the at least one candidate connection path.

[0007] Thirdly, one or more embodiments of this application provide a computer device including a memory and a processor, wherein the memory stores at least one computer program, which is loaded and executed by the processor to implement the method as described above.

[0008] Fourthly, one or more embodiments of this application provide a computer program product including computer instructions that, when executed by a processor, implement the method as described above.

[0009] Fifthly, one or more embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, causes the processor to implement the method as described above.

[0010] As can be seen from the above embodiments, multiple embodiments in this application discover implicit relationships between tables by parsing historical query commands of the database, dynamically update the table relationship graph based on the implicit relationships, and then, upon receiving a natural language query statement, determine at least one candidate connection path covering the fields involved in the semantics of the natural language query statement based on the table relationship graph, and generate a corresponding query command based on the at least one candidate connection path. This achieves accurate identification of the table connection relationship corresponding to the natural language query statement and generation of query commands, thereby improving the accuracy of data query. Attached Figure Description

[0011] Figure 1 This is a schematic diagram of a table relationship graph provided in a scenario example of a query instruction generation method according to an embodiment of this application.

[0012] Figure 2 This is a schematic diagram of a table relationship graph provided in a scenario example of a query instruction generation method according to an embodiment of this application.

[0013] Figure 3 This is a flowchart of a query instruction generation method provided in one embodiment of this application.

[0014] Figure 4 This is a block diagram of a query instruction generation device provided in one embodiment of this application.

[0015] Figure 5 This is a schematic diagram of a computer device provided in one embodiment of this application. Detailed Implementation

[0016] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments.

[0017] In the description of the embodiments of this application, it should be understood that the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Therefore, features defined with "first" and "second" may explicitly or implicitly include one or more of the stated features. In the description of the embodiments of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0018] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0019] In related technologies, the field of database query and natural language query conversion typically requires first converting the user's natural language query statement into executable query instructions based on the table structure relationships in the database. Specifically, related solutions generally rely on predefined table structure relationships, explicit foreign key relationships, or manually configured table join rules in the database to determine the target tables involved in the query process and the join relationships between the tables, and then generate the corresponding query instructions. This type of approach can meet basic query needs to a certain extent in scenarios where the database structure is relatively fixed and the relationships between tables are relatively clear.

[0020] However, in real-world databases, besides predefined explicit relationships, there are often numerous implicit relationships between tables that are not explicitly defined but have been repeatedly used in historical queries. For these implicit relationships, related technologies typically lack effective mechanisms for discovery, maintenance, and utilization. This means that when faced with natural language queries involving multiple tables, the table join paths often still rely on statically configured table relationships or human experience. Consequently, on the one hand, the fields involved in the natural language query may not be fully covered; on the other hand, it can easily lead to unreasonable generated table join paths, thus affecting the accuracy of subsequent query commands.

[0021] With the development of natural language processing (NLP) and intelligent query technologies, the method of automatically generating query instructions based on natural language query statements has gradually been applied. This allows users to complete data query tasks without directly writing database query statements, thereby lowering the barrier to entry for database queries. However, even in this type of NLP query transformation scenario, if the implicit relationships actually formed during the historical database query process are not considered, it is still difficult to accurately identify the table join relationships corresponding to the natural language query statement. This is especially true in cases of multiple table joins and complex query semantics, which can easily lead to a mismatch between the generated query instructions and the actual query requirements.

[0022] In summary, the relevant technologies still face the challenge of accurately generating query instructions based on natural language query statements, which requires further improvement.

[0023] In several embodiments provided in this application, the query instruction generation method can be applied to electronic devices with certain computing and network access capabilities. This electronic device can be a desktop computer, laptop computer, tablet computer, smartphone, or a server. Specifically, the electronic device includes a processor, memory, and a network access module for network communication. The server can be an electronic device with strong data processing capabilities; of course, a server can also refer to a server cluster formed by multiple electronic devices, or a quantum server built using a quantum computer.

[0024] Please see Figure 1 and Figure 2 One embodiment of this application provides an example application scenario for a database query instruction generation method. The instruction generation device can operate as a schema alignment layer in the natural language query to database query instruction generation process. Specifically, the instruction generation device can, on the one hand, discover explicit and implicit relationships between tables by parsing historical query instructions, database metadata, and configured XML SQL, construct a table relationship graph, and dynamically update the table relationship graph; on the other hand, after receiving a natural language query statement, the instruction generation device can first convert the natural language query statement into a user semantic representation, then determine at least one candidate connection path based on the user semantic representation and the table relationship graph, and perform search, constraint checking, field completion, path scoring, and optimal path selection on the candidate connection paths, finally generating a query instruction corresponding to the natural language query statement based on the optimal path.

[0025] In this scenario example, we take the database of an internet healthcare platform as an example. This database may include multiple tables such as "Patient Information Table," "Consultation Order Table," "Doctor Information Table," "Department Information Table," "Payment Record Table," "Follow-up Visit Record Table," and "Doctor Scheduling Table." During the system initialization phase, the instruction generation device can first perform table node and field parameter discovery processing. Specifically, the instruction generation device can extract the names of all tables from the database metadata, as well as parameter data such as the field name, data type, nullability, primary key or foreign key, index information, and field description for each table's corresponding fields. Thus, the instruction generation device can form the basic table schema information for each table and write each table as a node into the initial node set of the table relationship graph. For example, the "Consultation Order Table" may include fields such as "Order Number," "Patient Identifier," "Doctor Identifier," "Order Amount," and "Order Time"; the "Doctor Information Table" may include fields such as "Doctor Identifier," "Doctor Name," "Department Identifier," and "Title"; and the "Department Information Table" may include fields such as "Department Identifier" and "Department Name." In this way, the instruction generation device can first establish a relatively complete foundation of table nodes and field attributes.

[0026] After initializing the table nodes, the instruction generation device can further construct and maintain the table relationship graph. Specifically, the edges in the table relationship graph can originate from explicit associations, such as foreign key relationships explicitly defined in the database schema, or from implicit associations discovered by parsing historical query instructions. Thus, the table relationship graph does not rely solely on a single relationship source, but rather integrates explicit relationships, historical usage relationships, and configuration relationships to form a set of directed edges.

[0027] For example, during the long-term operation of an internet healthcare platform, a large number of historical query commands have accumulated in the database. A particular historical query command can be used to query "the consultation order information, the name of the attending physician, and the name of the department corresponding to a certain patient". This historical query command can contain multiple specified join clauses; furthermore, the specified join clauses can include JOIN ON clauses. One JOIN ON clause can dynamically link the patient identifier field in the "Consultation Order Table" with the patient identifier field in the "Patient Information Table"; another JOIN ON clause can dynamically link the doctor identifier field in the "Consultation Order Table" with the doctor identifier field in the "Doctor Information Table"; and yet another JOIN ON clause can dynamically link the department identifier field in the "Doctor Information Table" with the department identifier field in the "Department Information Table". When parsing this historical query command, the command generation device can identify the two fields involved in the join in the JOIN ON clause and determine that there is an implicit relationship between the tables containing the two fields. Subsequently, the instruction generation device can construct structured data representing the implicit association. For example, the structured data may include source table identifier, target table identifier, source field identifier, target field identifier, connection direction, and the number of times the association occurs. Furthermore, the device updates the table relationship graph using tables as nodes and the structured data as directed edges.

[0028] For example, in another historical query instruction, it is necessary to query "the amount and payment status of paid consultation orders within a certain time range". This historical query instruction can use the JOIN ON clause to connect the order number field in the "Consultation Order Table" with the order number field in the "Patient Record Table". In this case, the instruction generation device can also identify the implicit association between the "Consultation Order Table" and the "Patient Record Table" established through the order number field, and continue to update the corresponding structured data to the table relationship graph. In addition, in some implementations, the platform can also pre-define the recommended connection relationship between the "Follow-up Visit Record Table" and the "Doctor Schedule Table" through XMLSQL configuration, which also serves as an explicit association. The instruction generation device can read this XMLSQL configuration and write the corresponding relationship into the table relationship graph. In this way, the table relationship graph can gradually form a comprehensive relationship graph that simultaneously includes explicit associations, historical query instruction inferred relationships, and explicit associations from XMLSQL configuration.

[0029] In this scenario example, the table relationship graph can also be self-maintained. That is, the instruction generation device can continuously monitor and collect newly added historical query instructions, and automatically discover new implicit relationships and update the table relationship graph after detecting new JOIN ON clauses, new tables, or new field connection methods. For example, when a "Doctor Performance Table" is subsequently added, and historical query instructions begin to frequently connect the "Doctor Information Table" and the "Doctor Performance Table" through the "Doctor Identifier" field, the instruction generation device can automatically learn the new association edge between the "Doctor Information Table" and the "Doctor Performance Table" without extensive manual intervention. In this way, the instruction generation device can dynamically adapt to changes in the database schema.

[0030] After completing the construction and updating of the table relationship graph, the instruction generation device can receive natural language queries input by users. For example, a platform operator might input the following natural language query: "Help me compile a list of doctors and departments whose total order amount for each department in the paid consultation orders in East China last month exceeds 10,000 yuan." Upon receiving the natural language query, the instruction generation device can first process it through semantic parsing to transform the natural language query into a user semantic representation. The user semantic representation can include target tables, join tables, fields, filtering conditions, and aggregation functions. For example, in this scenario, the instruction generation device can extract from the natural language query: the main query object is related to "consultation orders," the target fields include "doctor's name" and "department name," the filtering conditions include "last month," "East China," and "paid," the aggregation requirements include "compile the total order amount by department or doctor," and also include the filtering requirement of "total order amount exceeding 10,000 yuan." In this way, the natural language query can be first transformed into a structured user semantic representation, thus providing an intermediate semantic foundation for subsequent pattern alignment.

[0031] After generating the user semantic representation, the instruction generation device can calculate the vector similarity between the natural language query statement and the association information of the tables. The association information of the tables can include at least one of the following: the table name, field names, and field descriptions. For example, the field names of the "consultation order table" can include "order number," "order amount," "order time," "patient identifier," "doctor identifier," and "region identifier"; the field names of the "payment record table" can include "order number," "payment status," and "payment time"; the field names of the "doctor information table" can include "doctor name," "doctor identifier," and "department identifier"; and the field names of the "department information table" can include "department identifier" and "department name," etc. The corresponding field descriptions can further characterize the meaning of these fields in the internet healthcare scenario. The instruction generation device can encode the natural language query statement into a query statement vector and the association information of each table into a table information vector, and then calculate the vector similarity between the query statement vector and the table information vector one by one. For example, Sentence-BERT can be used to form semantic embeddings and then cosine similarity can be calculated.

[0032] Furthermore, the instruction generation device can determine tables related to the natural language query statement from the database tables based on a preset similarity threshold, and use these tables as nodes. For example, in this scenario, the vector similarity between the "consultation order table," "payment record table," "doctor information table," and "department information table" and the natural language query statement can all be greater than the similarity threshold. Therefore, the instruction generation device can determine these tables as related to the natural language query statement and use them as nodes to participate in subsequent candidate connection path searches. Tables with lower relevance to the current query intent, such as the "patient information table," may have a vector similarity lower than the similarity threshold, and therefore are not prioritized for inclusion in this round of graph search. In this way, the instruction generation device can first select table nodes that are more semantically matched to the natural language query statement.

[0033] After determining the relevant tables, the instruction generation device can determine the target table based on the user's semantic representation and the natural language query statement. The target table can serve as the starting node. In this scenario example, since the main query object is consultation orders, the instruction generation device can determine the "consultation order table" as the target table and use it as the starting node. Subsequently, the instruction generation device can execute a graph search algorithm on the table relationship graph, starting from the starting node to find the minimum spanning tree structure that can connect all fields involved in the natural language query statement, obtaining multiple initial candidate connection paths. Specifically, all fields involved in the natural language query statement can include the "order amount" field, the "order time" field, the "region identifier" field, the "payment status" field, the "doctor's name" field, and the "department name" field. At this time, the instruction generation device can start from the starting node corresponding to the "consultation order table" and search along the directed edges in the table relationship graph to obtain several connected structures that can connect the "payment record table," the "doctor information table," and the "department information table."

[0034] For example, the instruction generation device can search for the first path: "Consultation Order Table - Payment Record Table - Doctor Information Table - Department Information Table"; it can also search for the second path: "Consultation Order Table - Doctor Information Table - Department Information Table"; and the third path: "Consultation Order Table - Payment Record Table - Doctor Scheduling Table - Department Information Table". These paths may all be feasible in terms of field coverage, so they can be used as candidate connection paths in the subsequent screening stage.

[0035] When searching for candidate connection paths, the instruction generation device can also perform constraint checks on each path to ensure that the candidate connection paths meet the filtering conditions and aggregation requirements implicit in the natural language query statement. In this scenario example, "last month" in the natural language query statement corresponds to a time range filtering condition, "East China region" corresponds to a regional range filtering condition, "paid" corresponds to a status range filtering condition, "total order amount for each department" corresponds to grouping and summation aggregation requirements, and "total amount exceeds 10,000 yuan" corresponds to aggregation result filtering requirements. Therefore, when performing constraint checks on candidate connection paths, the instruction generation device can not only check whether the path covers output fields such as "doctor's name" and "department name," but also further check whether the path has the ability to carry condition fields and aggregation fields such as "order time," "regional identifier," "payment status," "order amount," and "department name." If a path connects to the "Consultation Order Table," "Doctor Information Table," and "Department Information Table," but lacks a "Payment Record Table," then that path cannot meet the "Paid" filtering condition. Similarly, if a path cannot support summing amounts by department, then that path also cannot meet the aggregation requirements implicit in the natural language query. Therefore, the instruction generation device can eliminate paths that do not meet the constraints.

[0036] In some cases, during graph search, if the instruction generation device finds that a field required by the natural language query is not present in all the tables involved in the determined natural language query, it can automatically infer and add a related table containing the missing field as a candidate connection path based on the table relationship graph. For example, in the initial search phase, the instruction generation device may first identify the "consultation order table," "payment record table," and "doctor information table" as related tables, forming a preliminary path of "consultation order table—payment record table—doctor information table." However, upon further checking the field coverage, the instruction generation device may find that the "department name" field is not located in the currently determined table but in the "department information table." At this time, the instruction generation device can automatically infer based on the table relationship graph that there is a related edge between the "doctor information table" and the "department information table" formed through historical query instructions and / or explicit foreign key relationships. Therefore, the "department information table" can be added to the current path as a related table containing the missing field. After being added, the candidate connection path can be expanded to "consultation order table - payment record table - doctor information table - department information table", thus fully covering all fields required by the natural language query statement.

[0037] After obtaining multiple candidate join paths that pass field coverage and constraint checks, the instruction generation device can perform multi-dimensional scoring on these candidate join paths. Specifically, the instruction generation device can comprehensively and quantitatively evaluate each candidate join path based on multiple dimensions, such as path length, primary and foreign key strength, and field coverage. Path length represents the number of edges required for the join, primary and foreign key strength represents the robustness of the join relationships between tables in the path, and field coverage represents the completeness of the coverage of the fields required by the natural language query statement in the path. Thus, the instruction generation device can calculate corresponding path scores for different candidate join paths.

[0038] For example, regarding the first path mentioned above, "Consultation Order Table—Payment Record Table—Doctor Information Table—Department Information Table," although the path length is relatively long, its field coverage is high, and it can fully meet the constraints such as "Paid," "Department Statistics," and "Total Order Amount." The second path, "Consultation Order Table—Doctor Information Table—Department Information Table," although shorter, lacks support for fields related to "Payment Status," resulting in insufficient field coverage and failing the constraint check. The third path, "Consultation Order Table—Payment Record Table—Doctor Scheduling Table—Department Information Table," can also connect to the "Department Information Table," but the primary and foreign key strength between the "Doctor Scheduling Table" and the current query object may be weaker than that of the "Doctor Information Table" path, and its direct correspondence with the "Doctor Name" field is poor. Therefore, after comprehensively comparing path length, primary and foreign key strength, and field coverage, the instruction generation device can determine that the first path has a higher overall score and identify it as the optimal path. In this way, the instruction generation device can complete the end-to-end intelligent selection from the user semantic representation to the optimal SQL connection path.

[0039] After determining the optimal path, the instruction generation device can generate a query instruction corresponding to the natural language query statement based on the optimal path. Specifically, the instruction generation device can determine the target tables involved in the query instruction based on the tables corresponding to each node in the optimal path; determine the JOIN relationships between the target tables based on the edges in the optimal path; and generate corresponding field selection content, condition restriction content, grouping processing content, and aggregation result filtering content by combining the filtering conditions, aggregation requirements, target fields, and screening conditions parsed from the user semantic representation. For example, for the aforementioned natural language query statement, the instruction generation device can generate a query instruction containing "consultation order table," "payment record table," "doctor information table," and "department information table," and include a time filtering condition of "last month," a regional filtering condition of "East China region," a status filtering condition of "paid," an aggregation requirement of "total order amount by department," and a result filtering condition of "total amount exceeds 10,000 yuan." Subsequently, the database can execute the query instruction and return query results that satisfy the user's query intent.

[0040] For example, when the natural language query is "to query the mobile phone numbers, attending physician names, and departments of patients who have had follow-up visits in the past seven days, and to count the number of follow-up patients in each department," the instruction generation device can first convert the natural language query into a user semantic representation containing target fields, filtering conditions, and aggregation requirements. Then, by calculating the vector similarity between the natural language query and the association information of tables such as the "Follow-up Visit Record Table," "Patient Information Table," "Doctor Information Table," and "Department Information Table," the device determines the relevant tables as nodes and identifies the "Follow-up Visit Record Table" as the target table and the starting node. Afterward, the instruction generation device can execute a graph search algorithm on the table relationship graph to first obtain the initial path "Follow-up Visit Record Table—Patient Information Table—Doctor Information Table." Then, if the "Department Name" field is found to be missing, the device automatically infers and adds the "Department Information Table" as an associated table, forming a complete candidate connection path. Furthermore, the instruction generation device can also combine the time filtering condition of "the past seven days" and the aggregation requirement of "the number of patients returning to each department" to perform constraint checks and path scoring on the path, and determine the optimal path after comparing it with other candidate paths, and finally generate the corresponding query instruction.

[0041] In this scenario example, the instruction generation device introduces a schema alignment layer into the process of generating query instructions from natural language queries. It first discovers all table names and table parameter data, and then integrates explicit foreign key relationships, implicit associations revealed by JOIN ON clauses in historical query instructions, and XML SQL configuration relationships to construct and dynamically maintain a self-maintaining table relationship graph. Upon receiving a natural language query, it first converts the query into a user semantic representation, then uses vector similarity calculation and similarity threshold filtering to determine relevant tables as nodes and the target table as the starting node. A graph search algorithm is then executed on the table relationship graph to find the minimum spanning tree structure that connects all fields involved in the natural language query. During the search process, constraint checks and field completion are further performed, and candidate connection paths are comprehensively evaluated using multi-dimensional scoring functions such as path length, primary and foreign key strength, and field coverage. Finally, the optimal path is selected, and the corresponding query instruction is generated. In this way, the instruction generation device can more accurately align the schema between natural language query statements and database table structures, reduce the error rate of query instruction generation in complex multi-table query scenarios, and effectively improve the accuracy and efficiency of data queries as well as the system's adaptability to changes in database schema.

[0042] Please see Figure 3 One embodiment of this application provides a method for generating query instructions for a database. The query instruction generation method can be applied to an instruction generation device, which can be applied to the aforementioned electronic device possessing certain computing power and network access capabilities. Of course, in some embodiments, the instruction generation device can also be software running on the electronic device. The query instruction generation method may include the following steps.

[0043] Step S110: Based on the historical query commands of the parsed database, discover the implicit relationships between tables and dynamically update the table relationship graph; wherein, the table relationship graph includes nodes and edges connecting the nodes; each node corresponds to a table in the database, and the implicit relationships constitute the edges connecting the nodes.

[0044] Step S120: In response to the received natural language query statement, determine at least one candidate connection path in the table relation graph; wherein, the candidate connection path includes multiple nodes connected by edges; the nodes in the candidate connection path cover the fields involved in the semantics of the natural language query statement.

[0045] Step S130: Generate a query instruction corresponding to the natural language query statement based on the at least one candidate connection path.

[0046] In this embodiment, the instruction generation device can discover implicit relationships between tables based on parsing historical query instructions from the database and dynamically update the table relationship graph. Historical query instructions refer to query instructions that have been executed during the database's historical usage, representing the actual connection usage between tables in a real-world scenario. Implicit relationships refer to relationships between tables that are not predefined as explicit foreign keys but can be identified by parsing historical query instructions. The table relationship graph is a graph data structure used to represent the relationship structure between multiple tables in a database, where nodes correspond to tables in the database, and edges connect nodes with existing relationships.

[0047] In some implementations, each table in the database can be added as a node to the table relationship graph, and implicit relationships discovered by parsing historical query commands can be written into the table relationship graph as edges connecting the corresponding nodes. This allows the table relationship graph to reflect the inter-table relationship structure formed during actual database queries. Specifically, the command generation device can periodically parse newly added historical query commands, or parse corresponding historical query commands when a database query log update is detected, to continuously discover new implicit relationships and dynamically update the table relationship graph. In this way, the table relationship graph can not only include the statically existing table structure relationships in the database, but also further reflect the table connection relationships actually used during historical queries.

[0048] In this embodiment, the instruction generation device can also determine at least one candidate connection path in the table relationship graph in response to a received natural language query statement. A natural language query statement refers to a query request entered by a user in natural language form, which may include query objects, query conditions, statistical requirements, and other semantic expressions related to data querying. A candidate connection path refers to a path in the table relationship graph consisting of multiple nodes connected by edges, which can be used to characterize the table connection relationship corresponding to the natural language query statement. The nodes in the candidate connection path cover the fields involved in the semantics of the natural language query statement; that is, the tables corresponding to the multiple nodes in the candidate connection path contain fields that can support the query semantics of the natural language query statement.

[0049] In some implementations, the instruction generation device can first perform semantic parsing on the natural language query to identify the query objects, field names, filtering expressions, or statistical expressions involved, and then combine this with the table relationship graph to determine one or more candidate connection paths that can cover the aforementioned fields. Specifically, when the natural language query involves multiple objects or multiple fields distributed across different tables, the instruction generation device can search for paths connecting the corresponding nodes in the table relationship graph and determine the paths that cover the fields involved in the semantics of the natural language query as candidate connection paths. In this way, the implicit relationships maintained in the table relationship graph can be utilized to match table connection paths that are more in line with actual query habits for the natural language query.

[0050] In this embodiment, the instruction generation device can generate a query instruction corresponding to the natural language query statement based on the at least one candidate connection path. A query instruction refers to a data query instruction that can be executed by the database, and it may include table selection information, table join information, field extraction information, and query condition information. In some embodiments, the instruction generation device can determine the target table involved in the query instruction based on the tables corresponding to each node in the candidate connection path; and determine the connection relationship between the target tables based on the edges in the candidate connection path; it can also combine the fields, filtering conditions, and statistical requirements involved in the natural language query statement to generate corresponding field selection content, condition restriction content, and statistical processing content, thereby forming a query instruction corresponding to the natural language query statement. Specifically, the instruction generation device can select a target candidate connection path with a high degree of matching with the natural language query statement from at least one candidate connection path, and generate a query instruction based on the target candidate connection path, so that the generated query instruction can more accurately reflect the query intent expressed by the natural language query statement.

[0051] In this embodiment, implicit relationships between tables are discovered by parsing historical query commands from the database, and the table relationship graph is dynamically updated based on these implicit relationships. Then, when a natural language query statement is received, at least one candidate connection path covering the semantically involved fields of the natural language query statement is determined based on the table relationship graph, and a corresponding query command is generated according to the at least one candidate connection path. This reduces the limitations of relying solely on static table structure relationships or manually configured rules, and enables the generated query command to better adapt to the table connection relationships in the actual database.

[0052] In this application, multiple embodiments parse historical query commands from the database to discover implicit relationships between tables, dynamically update the table relationship graph based on the implicit relationships, and then, upon receiving a natural language query statement, determine at least one candidate connection path that covers the fields involved in the semantics of the natural language query statement based on the table relationship graph, and generate a corresponding query command based on the at least one candidate connection path. This achieves accurate identification of the table connection relationships corresponding to the natural language query statement and generation of query commands, thereby improving the accuracy of data query.

[0053] In some implementations, the instruction generation device can discover implicit relationships between tables by parsing specified join clauses in the historical query instructions, and construct structured data representing the implicit relationships; using tables as nodes and the structured data as directed edges, the device can update the table relationship graph.

[0054] In this embodiment, the specified join clause can refer to a fragment of instruction in historical query commands used to characterize the join relationship between different tables. The specified join clause directly reflects the join usage patterns between different tables during historical queries. Therefore, the command generation device can identify the table relationships used in the actual query process by parsing the specified join clause. Compared to relying solely on predefined table structure relationships in the database, the relationships obtained by parsing the specified join clause better reflect the actual join habits and usage patterns between tables in real query scenarios, thus facilitating the discovery of implicit relationships that are not explicitly defined in the database but have already been used.

[0055] In this embodiment, the instruction generation device can perform syntax parsing on historical query instructions, locate the specified join clause, and extract the table identifiers, join field identifiers, and join direction information from the specified join clause to determine the implicit relationship between tables. Here, structured data refers to the data organization result used to represent the implicit relationship. Structured data can take the form of key-value pairs, relation records, graph edge records, or other data formats that can be recognized and processed by the program. In some embodiments, the structured data may include at least one of the following: source table identifier, target table identifier, source field identifier, target field identifier, join type, join direction, and number of times the join occurs. By converting the implicit relationship into structured data, it is easier to write the parsing results into the table relationship graph and supports continuous updating and maintenance of the table relationship graph.

[0056] In this embodiment, the instruction generation device can update the table relationship graph using tables as nodes and the structured data as directed edges. Here, directed edges represent the association between tables corresponding to two nodes, as revealed by historical query instructions, and the directed edges can carry the structured data content corresponding to the association. In other words, the nodes in the table relationship graph are used to carry tables in the database, while the edges not only represent the connection between tables but also record information such as which fields are used to establish the connection, in what connection scenarios they are used, and the frequency of use. Thus, the updated table relationship graph not only has the ability to express inter-table connectivity but also the ability to represent historical connection features in a fine-grained manner.

[0057] To illustrate this, consider an example. Assume a database includes a "Patient Information Table," a "Medical Record Table," and a "Doctor Information Table." A historical query might request the "name of the attending physician and the time of treatment for a specific patient." This query might contain specific join clauses connecting the "Patient Information Table" and the "Medical Record Table," as well as connecting the "Medical Record Table" and the "Doctor Information Table." When parsing this query, the command generation device can identify from the corresponding join clauses that there is an implicit relationship between the "Patient Information Table" and the "Medical Record Table," and another implicit relationship between the "Medical Record Table" and the "Doctor Information Table," and further construct the corresponding structured data for each. Subsequently, the command generation device can add the "Patient Information Table," "Medical Record Table," and "Doctor Information Table" as nodes to the table relationship graph, and write the two structured data sets as directed edges into the table relationship graph. Thus, when a natural language query such as "query the name of the doctor who last treated a patient" is received, the instruction generation device can more easily determine the candidate connection path from the "patient information table" to the "doctor information table" via the "medical record table" by utilizing the updated directed edges in the table relationship graph.

[0058] For example, in the context of internet healthcare, the database may also include "order tables," "consultation tables," and "doctor scheduling tables." Although some historical query commands may not have explicitly defined foreign key relationships in the database schema, they have repeatedly connected the "order table" and the "consultation table," or the "consultation table" and the "doctor scheduling table," through specified join clauses during actual queries. In this case, the command generation device can also extract the corresponding table join relationships by parsing the specified join clauses and construct structured data to write into the table relationship graph. Thus, even if the original database schema definition does not explicitly specify explicit foreign keys between these tables, the corresponding implicit relationships can be discovered and maintained using the join usage records accumulated from historical query commands.

[0059] In this embodiment, implicit relationships between tables are discovered by parsing the specified join clauses in historical query instructions, and structured data representing these implicit relationships is constructed. Then, the table relationship graph is updated with tables as nodes and the structured data as directed edges. This allows the table connection experience actually formed during historical queries to be deposited into the table relationship graph, making the table relationship graph more accurately reflect the actual relationship structure in the database and providing a more reliable graph foundation for determining candidate join paths based on natural language query statements.

[0060] In some implementations, the specified link clause includes a JOIN ON clause; wherein the JOIN ON clause is used to indicate two fields that are dynamically linked, the two fields being in different tables, and the implicit association between the tables in which the two fields are located.

[0061] In this embodiment, the JOIN ON clause is an instruction fragment in the historical query instruction used to describe the join conditions between different tables, which can explicitly specify the two fields involved in the join. Here, the two fields establishing the dynamic link refer to the two fields selected from different tables and used to establish the query join relationship during the execution of the historical query instruction. Since the two fields are in different tables and are used together in the join operation through the JOIN ON clause, the instruction generation device can identify the implicit association relationship between the tables where these two fields are located. In other words, although the explicit foreign key relationship between the two tables may not be predefined in the database schema, as long as the two tables have been joined multiple times or at least once through the JOIN ON clause in the historical query instruction, this actual join relationship can be identified as the implicit association relationship and further used to update the table relationship graph.

[0062] In this embodiment, the instruction generation device can perform syntactic analysis on historical query instructions, locate the JOIN ON clause, and extract the two fields involved in the join and their corresponding table identifiers from the JOIN ON clause. After extracting the two fields, the instruction generation device can convert the join relationship between the two fields into an implicit association between the corresponding tables, and further combine the field identifiers, the table identifiers, and the join direction information to construct structured data representing the implicit association. Thus, the implicit association identified through the JOIN ON clause can not only reflect "which two tables are related," but also "which two fields establish the association," thereby providing a more granular data foundation for subsequent updates to the table relationship graph.

[0063] To illustrate this, consider an example. Assume a database contains a "Patient Information Table" and a "Medical Record Table." A historical query command uses a JOIN ON clause to connect the patient ID field in the "Patient Information Table" with the patient ID field in the "Medical Record Table" to retrieve all medical records for a given patient. In this scenario, after parsing the JOIN ON clause, the command generation device identifies the two fields involved in the dynamic linking as the patient ID field in the "Patient Information Table" and the patient ID field in the "Medical Record Table." Since these two fields reside in different tables and are used in a join operation in the historical query command, the command generation device can determine that an implicit association exists between the "Patient Information Table" and the "Medical Record Table." Furthermore, the command generation device can construct corresponding structured data based on these two fields and update the table relationship graph as directed edges using this structured data.

[0064] For example, a database might include a "Consultation Order Table" and a "Doctor Schedule Table." In a historical query, if the query requires finding the "available doctor schedule information corresponding to a paid consultation order," the query can use a JOIN ON clause to connect the doctor identifier field in the "Consultation Order Table" and the "Doctor Schedule Table." The command generation device, by parsing this JOIN ON clause, can identify the connection between the "Consultation Order Table" and the "Doctor Schedule Table" established through the doctor identifier field. Even if these two tables are not configured as explicit foreign key tables in the original database schema definition, the JOIN ON clause still reflects the implicit relationship that has been formed between them during the actual query process. Thus, when a subsequent natural language query, such as "Query the doctor schedule information corresponding to a certain type of consultation order," is received, the command generation device can utilize the association edges identified based on the JOIN ON clause in the table relationship graph to more accurately determine the corresponding candidate connection paths.

[0065] In some implementations, multiple JOIN ON clauses with different field combinations can exist between the same pair of tables. In this case, the instruction generation device can record the join relationships corresponding to different field combinations and write them collectively as different representations of the implicit association between the two tables into the table relationship graph. This allows for a more complete preservation of the join experience accumulated from historical query instructions and provides more basis for selecting more suitable candidate join paths when facing different natural language queries.

[0066] In this embodiment, by specifically defining the specified join clause as a JOIN ON clause and using the JOIN ON clause to indicate the two fields that are dynamically linked, the implicit relationship between the tables in which the two fields are located can be identified. This allows for a clearer extraction of the actual connection basis between tables from historical query instructions, making the discovery process of implicit relationships more specific and clear, and further improving the accuracy of the table relationship graph update.

[0067] In some implementations, the instruction generation device can determine a target table based on the natural language query statement; wherein the target table serves as a starting node; and a graph search algorithm is executed on the table relationship graph to find the minimum spanning tree structure that can connect all fields involved in the natural language query statement, starting from the starting node, to obtain candidate connection paths.

[0068] In this embodiment, the target table refers to the table corresponding to the main query object of the natural language query statement, as determined based on the natural language query statement. In other words, the target table can serve as the table carrying the core query semantics of the natural language query statement and as the starting node when performing the graph search algorithm in the table relationship graph. Here, the starting node refers to the node that serves as the starting point for the search during the graph search process. Since natural language queries usually have relatively clear query objects, the instruction generation device can first perform semantic parsing on the natural language query statement to identify the keywords, entity names, or object descriptions that represent the main query object, and combine this with the semantic information of each table in the database to determine the target table that matches the main query object. In this way, the subsequent graph search process can start from the node that is closer to the user's query intent, reduce the diffusion search of irrelevant nodes, and improve the targeting of candidate connection path determination.

[0069] In this embodiment, all fields involved in a natural language query statement refer to the set of fields that need to participate in query processing to express the query intent of the natural language query statement. The set of fields may include fields that need to be returned in the query results, as well as fields used for filtering, sorting, statistical analysis, or grouping. Since these fields may be distributed across different tables, after determining the target table as the starting node, the instruction generation device can further identify which nodes correspond to which tables, and perform a graph search algorithm on the table relationship graph to find a connection structure starting from the starting node that can cover the tables corresponding to these fields.

[0070] In this embodiment, the graph search algorithm refers to an algorithm used to traverse nodes and edges in the table relationship graph to determine the connection structure that satisfies preset conditions. The graph search algorithm can employ breadth-first search, depth-first search, heuristic search, or other search methods suitable for graph structure traversal. Since the table relationship graph already contains explicit and implicit associations between tables, the instruction generation device can utilize the graph search algorithm to gradually expand the search range from the starting node to find a graph structure that can connect all the tables corresponding to the fields involved in the natural language query statement. Here, the minimum spanning tree structure refers to a connected structure containing as few nodes and edges as possible, while still connecting all fields. By finding this minimum spanning tree structure, redundant table connections can be reduced while covering all fields, thereby reducing the possibility of introducing irrelevant tables when generating subsequent query instructions and making the table connection relationships corresponding to the query instructions more compact and reasonable.

[0071] In some implementations, the instruction generation device can first identify the query object and multiple field descriptions from the natural language query statement, and then determine the target table corresponding to the query object as the starting node. For example, in an internet healthcare scenario, if the natural language query statement is "query the amount of a patient's consultation orders and the name of the attending physician in the last three months", the instruction generation device can identify the main query object as "consultation orders" or "patient consultation records", and then determine the "consultation order table" corresponding to the main query object as the target table, and use the "consultation order table" as the starting node. Meanwhile, the natural language query statement also involves the fields "order amount" and "attending physician name", where the "order amount" field can be located in the "consultation order table", and the "attending physician name" field can be located in the "doctor information table". At this time, the instruction generation device can execute a graph search algorithm on the table relationship graph, starting from the node corresponding to the "consultation order table", and find a graph structure connecting the "consultation order table" and the "doctor information table". If there is an associated edge in the table relationship graph where the "consultation order table" connects to the "doctor information table" via the "consultation record table", the instruction generation device can determine a minimum spanning tree structure that can cover all fields based on the connectivity relationship and use it as a candidate connection path.

[0072] In some implementations, when executing a graph search algorithm, the instruction generation device can obtain multiple graph structures, each capable of connecting all fields involved in the natural language query. These multiple graph structures can then be retained as different candidate connection paths for further selection of the candidate connection path with a higher degree of matching to the natural language query, serving as the target connection path for generating the query instruction. For example, the same "patient information table" can be connected to both the "consultation record table" and the "appointment registration table." Therefore, when faced with a natural language query involving patient and doctor information, the instruction generation device can simultaneously obtain multiple different connected structures and use each of these connected structures as a candidate connection path. This provides a richer foundation for subsequent path selection based on query conditions, statistical requirements, or semantic matching degree.

[0073] In this embodiment, a target table is determined based on the natural language query statement, and the target table is used as the starting node. A graph search algorithm is executed on the table relationship graph to find the minimum spanning tree structure that can connect all fields involved in the natural language query statement, starting from the starting node. Candidate connection paths are obtained, thereby transforming the query objects and field requirements in the natural language query statement into specific connected structures in the table relationship graph. This ensures that the determined candidate connection paths can cover all fields involved in the natural language query statement while reducing unnecessary table joins, thus providing a reliable foundation for generating query instructions that better match the natural language query statement.

[0074] In some implementations, the instruction generation device may perform constraint checks on each path when searching for candidate connection paths, so that the candidate connection paths can meet the filtering conditions and aggregation requirements implied by the natural language query statement.

[0075] In this embodiment, the determination of candidate connection paths is not only to determine whether the path can connect all the fields involved in the natural language query statement, but also to determine whether the path can support the query restriction logic and statistical processing logic that are not directly and explicitly written in the natural language query statement but have been implicitly expressed through semantic description.

[0076] In this embodiment, filtering conditions refer to the conditions used to limit the scope of the query. Filtering conditions can correspond to time ranges, object ranges, state ranges, numerical ranges, category ranges, or other restrictive expressions in natural language query statements. Aggregation requirements can refer to processing requirements used to instruct the query results to be statistically analyzed, summarized, counted, summed, averaged, grouped, or sorted. While filtering conditions and aggregation requirements may not appear directly in the standard syntax of database query statements in natural language queries, users typically implicitly express their query intent through natural language expressions. Therefore, when executing the graph search algorithm based on the table relation graph, the instruction generation device, in addition to considering whether the path covers all fields involved in the natural language query statement, can further perform constraint checks on each path to determine whether the table join structure corresponding to the path has the capacity to bear the filtering conditions and aggregation requirements.

[0077] In this embodiment, constraint checking refers to examining each path obtained during the graph search process, checking whether the tables corresponding to the nodes in the path and the connection relationships represented by the edges can support the condition constraints and statistical processing corresponding to the natural language query statement. Specifically, the instruction generation device can first perform semantic parsing on the natural language query statement to extract semantic information related to filtering conditions and aggregation requirements. For example, when the natural language query statement contains expressions such as "last three months," "paid," "more than 500 yuan," "statistics by department," "number of people counted," and "average cost," the instruction generation device can identify "last three months" as a time range filtering condition, "paid" as a status filtering condition, "more than 500 yuan" as a numerical range filtering condition, "statistics by department" as a grouping aggregation requirement, "number of people counted" as a count aggregation requirement, and "average cost" as an average value aggregation requirement. Based on this, the instruction generation device can combine the tables and fields covered by each path to determine whether the path contains the field sources and connection structures required to satisfy the corresponding filtering conditions and aggregation requirements.

[0078] In some implementations, if a path can connect all the fields involved in the natural language query, but lacks a table containing the fields required for filtering conditions or supporting aggregation requirements, the instruction generation device can determine that the path fails the constraint check and will not retain it as a candidate connection path. For example, the natural language query is "Query the names of doctors corresponding to the consultation orders paid in the last three months." In this scenario, the natural language query involves not only "order information" and "doctor's name," but also implicitly includes a time range filter condition of "last three months" and a status filter condition of "paid." If a path can connect the "consultation order table" and the "doctor information table," but does not contain a table recording the payment status field or order time field, or although it contains relevant tables, the corresponding fields cannot be correctly constrained through the connection relationships in the path, then although the path is feasible at the field coverage level, it cannot truly satisfy the complete query intent of the natural language query. Therefore, the instruction generation device can exclude the path during the constraint check phase.

[0079] In some implementations, the instruction generation device can perform real-time constraint checks on each expanding path during the graph search process, or it can perform constraint checks on multiple initial paths uniformly after the graph search has obtained multiple initial paths. If the former approach is used, paths that clearly do not meet the constraints of the natural language query statement can be eliminated as early as possible during the path expansion stage, reducing subsequent invalid searches. If the latter approach is used, after obtaining multiple connectable paths, the degree to which different paths meet the filtering conditions and aggregation requirements can be uniformly compared to select more suitable candidate connection paths for retention. Candidate connection paths must not only meet field connectivity requirements but also query semantic constraints.

[0080] To illustrate this, consider an example from an internet healthcare scenario. Assume the database includes a "Consultation Order Table," a "Doctor Information Table," a "Department Information Table," and a "Payment Record Table." When the natural language query is "Query the total amount of dermatology orders that have been paid for this month," the instruction generation device can identify four semantic categories: "department," "payment status," "order amount," and "this month." "Dermatology" corresponds to a category-based filtering condition, "this month" to a time-based filtering condition, "paid for" to a status-based filtering condition, and "total order amount" to a summation-based aggregation requirement. At this point, executing a graph search algorithm on the table relationship graph starting from the initial node may yield multiple paths connecting the "Consultation Order Table" and the "Department Information Table." However, not every path can simultaneously support both the "paid for" status determination and the summation of the "total order amount." The instruction generation device can only determine that a path passes the constraint check and be considered a candidate join path if a path simultaneously contains fields representing order amount, payment status, order time, and department category, and these fields can form a unified query structure through table joins in the path.

[0081] For example, when the natural language query is "to count the number of follow-up patients for each doctor in the last seven days", the implicit filtering condition of the natural language query can include "last seven days", and the aggregation requirements can include "grouped by doctor" and "counting the number of follow-up patients". In this case, the instruction generation device can check whether each path has the table join basis corresponding to the doctor identifier, patient identifier, follow-up visit identifier, and time field when searching for paths. If a path can connect from the "doctor information table" to the "patient information table", but cannot be associated with the table representing "follow-up visit", or cannot be associated with the time field representing "last seven days", then the path does not meet the complete semantic requirements of the natural language query and should not be used as a candidate join path.

[0082] In this embodiment, by performing constraint checks on each candidate connection path during the search, the candidate connection paths can meet the filtering conditions and aggregation requirements implicit in the natural language query statement. This avoids retaining paths that do not conform to the actual query semantics based solely on field coverage. The final determined candidate connection paths not only structurally connect all fields involved in the natural language query statement, but also semantically support the condition restrictions and statistical processing corresponding to the natural language query statement, thereby providing a more reliable path foundation for generating more accurate query instructions.

[0083] In some implementations, the instruction generation device can automatically infer and add the associated table containing the field as a candidate connection path based on the table relationship graph when the field required by the natural language query is not in all the tables involved in the determined natural language query.

[0084] In this embodiment, after the instruction generation device identifies fields and performs graph search based on the natural language query statement, if it finds that the currently determined set of tables cannot completely cover all the fields required by the natural language query statement, it does not directly terminate the process of determining the candidate connection path. Instead, it further utilizes the existing inter-table association structure in the table relationship graph to automatically infer the association tables to which the missing fields may belong, and adds the association tables to the corresponding connectivity structure to form a more complete candidate connection path.

[0085] In this embodiment, the fields required by the natural language query statement are not found in all the tables involved in the determined natural language query statement. This can include situations where, based on the currently identified query object, target table, and tables corresponding to multiple nodes initially covered by graph search, it is still impossible to find a field in these tables that supports the complete query intent of the natural language query statement. In other words, although the current path can connect some tables related to the natural language query statement, for some fields, they are neither located in all the tables involved in the determined natural language query statement nor covered by the current path. In this case, if the query instruction is still generated solely based on the current path, it may result in missing query result fields, inability to express filtering conditions, or inability to correctly execute aggregation requirements. Therefore, in this embodiment, the instruction generation device can further utilize the table relationship graph to perform field completion-based association table inference.

[0086] In this embodiment, the associated table refers to a table that has an associated edge in the table relationship graph with all tables involved in the determined natural language query statement, and contains the fields required by the natural language query statement. Since the table relationship graph already maintains explicit or implicit inter-table relationships based on historical query instructions, when a field is missing, the instruction generation device can start from one or more nodes in the currently determined path, expand outward along the edges in the table relationship graph, search for tables that are associated with the current set of tables and contain the target missing field, and identify these tables as the associated table. In this way, the table connection experience accumulated during historical queries can be used to supplement the discovery of source tables for fields that were not initially identified.

[0087] In this embodiment, the instruction generation device can first identify all required fields based on the natural language query statement and compare all fields with all tables involved in the currently determined natural language query statement. If the comparison result shows that there are uncovered fields, then the uncovered fields can be identified as missing fields. Subsequently, the instruction generation device can search for tables corresponding to other nodes connected to these nodes with associated edges in the table relationship graph, using the nodes already included in the current candidate connection path as the expansion basis, and determine whether the missing fields exist in these tables. If the missing field exists in a table, and the table can be connected to the nodes in the current path through the edges in the table relationship graph, then the table can be added as an associated table containing the field to the connection structure corresponding to the current path. Furthermore, the connection structure after adding the associated table can continue to serve as a new candidate connection path, or participate in subsequent path filtering as a completion result of the original candidate connection path.

[0088] In some implementations, when automatically inferring the association table, the instruction generation device can consider not only whether the missing field exists in a candidate table, but also factors such as the association strength, connection level, semantic matching degree of the fields, or historical usage frequency between the candidate table and the current path. This allows for the selection of a more suitable association table to be added to the current path from multiple tables that may contain the missing field. In this way, tables with low semantic relevance to the current query can be avoided during field completion, ensuring that the completed candidate connection path maintains good compactness and semantic consistency.

[0089] To illustrate this, consider an example. In an internet healthcare scenario, the database includes a "consultation order table," a "doctor information table," a "patient information table," and a "department information table." When the natural language query is "Query the doctor's name and department name corresponding to a patient's most recent consultation order," the instruction generation device first identifies the primary query object as the "consultation order table" and designates it as the target table and the starting node. Subsequently, when executing a graph search algorithm on the table relationship graph, the current path may first cover the "consultation order table" and the "doctor information table," thus satisfying the requirement to retrieve the "doctor's name" field. However, among all the tables involved in the identified natural language query, the "department information table" containing the "department name" field may not yet be included. In this case, the instruction generation device can identify the "department name" field as a missing field and automatically infer from the table relationship graph: since there is a related edge between the "doctor information table" and the "department information table" in historical query instructions, the "department information table" can be added to the current path as a related table containing the missing field. After being added, the candidate connection path can be expanded from the original "consultation order table - doctor information table" to "consultation order table - doctor information table - department information table", thereby fully covering all fields required by the natural language query statement.

[0090] For example, the database includes an "Appointment Record Table," a "Patient Information Table," a "Payment Record Table," and a "Coupon Usage Table." When the natural language query is "to count the number of appointments paid for using coupons in the past month," the instruction generation device may initially determine that the "Appointment Record Table" and the "Payment Record Table" are all the tables involved in the natural language query based on the semantics related to "number of appointments" and "payment," and form a preliminary path accordingly. However, if it is subsequently discovered that the "coupon usage identifier field" is not located in the currently determined table but in the "coupon usage table," it indicates that the field required by the natural language query is not in the currently determined set of tables. At this time, the instruction generation device can automatically infer the relationship between the "Payment Record Table" and the "Coupon Usage Table" based on the table relationship graph, and add the "Coupon Usage Table" as a related table to the current path. Thus, the completed candidate connection path can simultaneously support the time filtering of "past month," the condition restriction of "paying with coupons," and the statistical requirement of "number of appointments."

[0091] For example, a natural language query might be "Query the mobile phone number and attending physician's title of a patient who has completed a follow-up visit." In the initial identification stage, the instruction generation device might first determine the "Follow-up Visit Record Table" and the "Patient Information Table" as the entire set of tables involved in the natural language query, and then search for the corresponding path based on the table relationship graph. At this point, the "Patient Mobile Phone Number" field is already covered, but the "Attending Physician's Title" field might not be in the currently determined set of tables, but rather in the "Physician's Title Information Table" or the "Physician Information Table." In this case, the instruction generation device can continue searching outwards from the "Follow-up Visit Record Table" or its connected related nodes according to the table relationship graph, automatically inferring the associated table containing the "Attending Physician's Title" field, and adding this associated table to the current path. This allows the candidate connection paths to more completely cover all the output content required by the user's query semantics.

[0092] In some implementations, the instruction generation device can monitor field coverage in real time during the graph search process. After each path is extended, it can be determined whether the tables corresponding to the multiple nodes covered by the current path have covered all the fields required by the natural language query. If not, the process of automatically inferring and adding the associated table containing the required field based on the table relationship graph is triggered. In this way, the process of constructing candidate connection paths can be expanded from a simple "path search" to a joint determination process of "path search + field completion," thereby improving the adaptability of candidate connection paths to complex natural language queries.

[0093] In this embodiment, when the field required by the natural language query is not in all the tables involved in the determined natural language query, the associated table containing the field is automatically inferred and added as a candidate connection path based on the table relationship graph. This avoids the problem of insufficient field coverage of candidate connection paths due to incomplete initial table identification, and enables the determined candidate connection paths to more completely cover the field content required by the natural language query, thereby further improving the completeness of expression and matching accuracy of the natural language query when generating subsequent query instructions.

[0094] In some implementations, the instruction generation device can calculate the vector similarity between the natural language query statement and the association information of the table; wherein the association information of the table includes at least one of the following: the name of the table, the field names of the fields in the table, and the field descriptions; based on a preset similarity threshold, the table related to the natural language query statement is determined from the tables of the database as a node; wherein the vector similarity corresponding to the table related to the semantic expression is greater than the similarity threshold.

[0095] In this embodiment, before searching for candidate connection paths based on the table relationship graph, the instruction generation device can first filter the tables in the database by the semantic similarity between the natural language query statement and the association information of each table, thereby providing a more accurate node basis for subsequently determining the target table, starting node and candidate connection paths.

[0096] In this embodiment, table association information refers to information content that can characterize the semantic features of a table. Since table names, field names, and field descriptions in a database typically reflect the meaning of the corresponding table from different perspectives, the instruction generation device can obtain the association information of each table and use this information as the basis for the semantic representation of the table. Specifically, the table name directly represents the object or topic carried by the table, the field name reflects the type of data item stored in the table, and the field description further explains the meaning, usage scenario, or value semantics of the corresponding field. By comprehensively utilizing one or more of the above information, the semantic representation of the table can be made more complete, thereby facilitating subsequent judgment of the relevance between the natural language query statement and each table.

[0097] In this embodiment, vector similarity refers to the similarity result obtained by quantifying the closeness between two vectors after converting the natural language query statement and the table association information into corresponding vector representations. In other words, the instruction generation device can first encode the natural language query statement into a query statement vector, then encode the association information of each table into a table information vector, and further calculate the vector similarity between the query statement vector and each table information vector to characterize the semantic matching degree between the natural language query statement and the corresponding table. In some embodiments, the vector similarity can be calculated using cosine similarity, dot product similarity, or other similarity indicators used to measure the closeness of vectors. By using vector similarity, rather than relying solely on exact keyword matching or table name matching, the instruction generation device can still accurately identify the tables related to the natural language query statement even when faced with synonyms, aliases, or non-standard natural language expressions.

[0098] In this embodiment, the instruction generation device can obtain the association information of the corresponding tables for multiple tables in the database, and calculate the vector similarity between the natural language query statement and the association information of each table one by one. After obtaining the vector similarity for each table, the instruction generation device can compare the vector similarity with a preset similarity threshold, and determine the tables with vector similarity greater than the similarity threshold as tables related to the natural language query statement, adding them as nodes to the subsequent candidate connection path determination process. Here, the preset similarity threshold can be used to distinguish between "tables related to the semantics of the current query" and "tables that are not related to the semantics of the current query or have low relevance". In this way, tables that are closer to the semantic expression of the natural language query statement can be selected from multiple tables in the database first, and then, combined with the aforementioned table relationship graph, target table determination, graph search algorithm, constraint checking, and association table completion, at least one candidate connection path can be determined. This avoids performing invalid searches on a large number of irrelevant tables, improving the efficiency and accuracy of candidate connection path determination.

[0099] In some implementations, the instruction generation device can take the query object description, field description, filtering description, and statistical description in the natural language query statement as a whole as semantic input, and calculate the vector similarity with the association information of each table separately. For example, if the natural language query statement is "Query the names of the attending physicians corresponding to paid consultation orders in the past week", then the natural language query statement simultaneously contains semantic descriptions such as "consultation orders", "attending physicians", "paid", and "past week". In this case, the instruction generation device can obtain the association information of multiple tables such as the "consultation order table", "doctor information table", "payment record table", and "patient information table", and calculate the vector similarity between the natural language query statement and the association information of these tables. If the table name of the "Consultation Order Table" is "Consultation Order Table", and its field names include "Order Number", "Order Amount", "Order Time", "Patent Status", etc., and the field description also includes "Records patient consultation order information"; and the field names of the "Doctor Information Table" include "Doctor Name", "Doctor Number", "Title", "Department", etc., and the field description includes "Records basic information of the attending physician", then the natural language query statement will usually have a high vector similarity with the associated information of the "Consultation Order Table" and the "Doctor Information Table". If the corresponding vector similarity is greater than the similarity threshold, the instruction generation device can determine the "Consultation Order Table" and the "Doctor Information Table" as tables related to the natural language query statement, and use them as nodes to participate in the subsequent candidate connection path search.

[0100] For example, a natural language query might be "Statistics on the number of dermatology patients who have had follow-up visits in the past month." In this scenario, the natural language query includes semantic expressions such as "dermatology," "follow-up patients," "past month," and "number of people." The instruction generation device can obtain the association information from tables such as the "Department Information Table," "Follow-up Visit Record Table," "Patient Information Table," and "Patient Payment Record Table," and calculate the vector similarity between the natural language query and the association information of these tables. If the field description of the "Department Information Table" includes "records department name and department category information," the field description of the "Follow-up Visit Record Table" includes "records patient follow-up visit behavior and follow-up visit time," and the field description of the "Patient Information Table" includes "records patient basic information," then the vector similarity between the natural language query and the association information of the "Department Information Table" and the "Follow-up Visit Record Table" is likely to be high, while the vector similarity with the association information of the "Patient Payment Record Table" is likely to be low. At this point, the instruction generation device can prioritize the "department information table" and "follow-up visit record table" as nodes corresponding to relevant tables based on the similarity threshold, and then further search for candidate connection paths that connect these nodes and cover the fields required by the natural language query statement by combining the aforementioned graph search algorithm.

[0101] For example, in some cases, the expressions used by users in their natural language queries may not be exactly the same as the table names in the database. For instance, a user might enter "query doctor's schedule," while the corresponding table in the database might be named "doctor's outpatient schedule table"; or a user might enter "statistics on registration information," while the corresponding table in the database might be named "appointment record table." In such cases, relying solely on literal string matching might not accurately identify the relevant table. However, in this embodiment, since the table name, field name, and field description can be combined to form the table's association information, and semantic similarity can be calculated using vector similarity, even if the natural language query expression is not exactly the same as the table name, as long as their semantics are similar, the corresponding relevant table can still be identified relatively accurately. This enhances the adaptability of the instruction generation device to differences in natural language expressions.

[0102] In some implementations, the instruction generation device can also retain these tables as nodes when the vector similarity of multiple tables is greater than the similarity threshold, for subsequent use in the graph search algorithm within the table relationship graph. That is, the process of determining relevant tables based on the preset similarity threshold does not necessarily output only a single table, but can output multiple tables related to the semantic expression of the natural language query. In this case, if one of the relevant tables better carries the main query object, it can further serve as the aforementioned target table, acting as the starting node; while other relevant tables can serve as candidate expansion nodes in subsequent path searches. This allows for better integration of the vector similarity filtering process with the aforementioned target table determination, candidate connection path search, constraint checking, and association table completion processes.

[0103] In this embodiment, by calculating the vector similarity between the natural language query statement and the association information of the table, and based on a preset similarity threshold, the table related to the natural language query statement is determined from the tables of the database as a node. This allows for the selection of tables with a high degree of matching with the natural language query statement at the semantic level before searching for candidate connection paths, reducing the interference of irrelevant tables on path search, and improving the accuracy of subsequent determination of target tables, construction of candidate connection paths, and generation of query instructions.

[0104] Please see Figure 4 One or more embodiments of this application also provide a query instruction generation apparatus for a database. The query instruction generation apparatus may include: an update module, a determination module, and a generation module.

[0105] The update module is used to discover implicit relationships between tables based on the parsed historical query commands of the database and dynamically update the table relationship graph; wherein, the table relationship graph includes nodes and edges connecting the nodes; each node corresponds to a table in the database, and the implicit relationships constitute the edges connecting the nodes.

[0106] A determination module is configured to determine at least one candidate connection path in the table relation graph in response to a received natural language query statement; wherein the candidate connection path includes multiple nodes connected by edges; and the nodes in the candidate connection path cover the fields involved in the semantics of the natural language query statement.

[0107] The generation module is used to generate a query instruction corresponding to the natural language query statement based on the at least one candidate connection path.

[0108] In this embodiment, the functions and effects of the query instruction generation device can be explained in comparison with the aforementioned embodiments, and will not be repeated here.

[0109] Please see Figure 5This application also provides a computer device comprising: a memory and a processor, wherein the memory stores at least one computer program, and the at least one computer program is loaded and executed by the processor to implement the method described above.

[0110] The memory, processor, and communication interface in the computer device can communicate with each other via the system bus and network communication.

[0111] In this embodiment, the functions and effects implemented by the computer device can be explained by referring to the foregoing embodiments, and will not be repeated here.

[0112] This application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, causes the processor to implement the method as described above.

[0113] The functions and effects achieved in this embodiment can be explained by referring to other embodiments, and will not be repeated here.

[0114] This application also provides a computer program product containing instructions, including a computer program / instructions that, when executed by a processor, implement the method as described above.

[0115] The functions and effects achieved in this embodiment can be explained by referring to other embodiments, and will not be repeated here.

[0116] It is understood that the specific examples in this document are only intended to help those skilled in the art better understand the embodiments of this application, and are not intended to limit the scope of the invention.

[0117] It is understood that in the various embodiments of this application, the sequence number of each process does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0118] It is understood that the various implementation methods described in this application can be implemented individually or in combination, and the implementation methods in this application are not limited in this respect.

[0119] Unless otherwise stated, all technical and scientific terms used in the embodiments of this application have the same meaning as commonly understood by one of ordinary skill in the art. The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The term "and / or" as used in this application includes any and all combinations of one or more of the associated listed items. The singular forms "a," "the," and "the" as used in the embodiments of this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise.

[0120] It is understood that the processor in the embodiments of this application can be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method embodiments can be completed by the integrated logic circuits in the processor's hardware or by instructions in software form. The processor can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory; the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

[0121] It is understood that the memory in the embodiments of this application may be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. Specifically, non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory may be random access memory (RAM). It should be noted that the memory in the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0122] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0123] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the aforementioned method implementations, and will not be repeated here.

[0124] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0125] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0126] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0127] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0128] The above description is merely a specific embodiment of this application, but the scope of protection of this invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this invention should be determined by the scope of the claims.

Claims

1. A method for generating query instructions for a database, characterized in that, include: Based on the historical query commands of the parsed database, implicit relationships between tables are discovered, and the table relationship graph is dynamically updated; wherein, the table relationship graph includes nodes and edges connecting nodes; each node corresponds to a table in the database, and the implicit relationships constitute the edges connecting nodes; In response to a received natural language query, at least one candidate connection path is determined in the table relation graph; wherein the candidate connection path includes multiple nodes connected by edges; the nodes in the candidate connection path cover the fields involved in the semantics of the natural language query. Based on the at least one candidate connection path, a query instruction corresponding to the natural language query statement is generated.

2. The method according to claim 1, characterized in that, The process of discovering relationships between tables and dynamically updating the table relationship graph based on historical query commands from the parsed database includes: By parsing the specified join clauses in the historical query instructions, implicit relationships between tables are discovered, and structured data representing these implicit relationships is constructed. The table relationship graph is updated using the table as nodes and the structured data as directed edges.

3. The method according to claim 2, characterized in that, The specified link clause includes a JOIN ON clause; wherein, the JOIN ON clause is used to indicate two fields that are dynamically linked, the two fields are in different tables, and there is an implicit association between the tables in which the two fields are located.

4. The method according to claim 1, characterized in that, In response to a received natural language query, at least one candidate join path is determined in the table relation graph, including: The target table is determined based on the natural language query statement; wherein, the target table serves as the starting node; A graph search algorithm is executed on the table relationship graph to find the minimum spanning tree structure that can connect all fields involved in the natural language query statement, starting from the starting node, and to obtain candidate connection paths.

5. The method according to claim 4, characterized in that, A graph search algorithm is performed on the table relationship graph to find the minimum spanning tree structure that can connect all fields involved in the natural language query, starting from the starting node, to obtain candidate connection paths, including: When searching for candidate connection paths, each path is subjected to constraint checks to ensure that the candidate connection paths can meet the filtering conditions and aggregation requirements implied in the natural language query statement.

6. The method according to claim 4, characterized in that, A graph search algorithm is performed on the table relationship graph to find the minimum spanning tree structure that can connect all fields involved in the natural language query, starting from the starting node, to obtain candidate connection paths, including: When the field required by the natural language query is not in all the tables involved in the determined natural language query, the related table containing the field is automatically inferred and added as a candidate connection path based on the table relationship graph.

7. The method according to claim 1, characterized in that, In response to a received natural language query, at least one candidate join path is determined in the table relation graph, including: Calculate the vector similarity between the natural language query statement and the association information of the table; wherein the association information of the table includes at least one of the following: the name of the table, the field names of the fields in the table, and the field descriptions; Based on a preset similarity threshold, tables related to the natural language query statement are determined from the tables in the database and used as nodes; wherein the vector similarity of the tables related to the semantic expression is greater than the similarity threshold.

8. A computer-readable storage medium, characterized in that, It stores a computer program that, when executed by a processor, causes the processor to implement the method as described in any one of claims 1 to 7.

9. A computer device, characterized in that, The computer device includes a memory and a processor, the memory storing at least one computer program, the at least one computer program being loaded and executed by the processor to implement the method as described in any one of claims 1 to 7.

10. A computer program product, characterized in that, Includes computer instructions that, when executed by a processor, implement the method as described in any one of claims 1 to 7.

Images