A natural language based database operation method and computing device

Abstract

This application provides a database operation method and computing device based on natural language. The method includes: in response to receiving a query instruction, obtaining table structure information of the database; filtering the table structure information according to a first format to generate table structure metadata; inputting the query instruction and table structure metadata into a statement generation model to generate a Structured Query Language (SQL) statement; and executing the SQL statement to obtain the statement execution result. Based on this solution, by reconstructing the table structure information of all tables in the database into a metadata format that the model can parse, and inputting it along with the query instruction into the statement generation model, the model can use the database table structure as context for parsing when generating SQL statements. This allows for accurate matching of user query intent with the corresponding table structure, significantly improving the accuracy and adaptability of generated SQL statements, and optimizing semantic parsing capabilities in complex query scenarios.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, and in particular to a database operation method and computing device based on natural language. Background Technology

[0002] A database is a system specifically designed for the structured storage, management, and efficient retrieval of large amounts of data. Through structured storage, it avoids data storage chaos and achieves efficient data management, making it widely used in various business systems. Data management in a database typically requires the use of structured languages, such as Structured Query Language (SQL). However, using SQL to manage data in a database requires users to master SQL syntax and write accurate query statements, limiting the database usage capabilities of non-technical personnel.

[0003] Therefore, converting natural language into SQL statements has become a way to improve database availability. Traditional SQL statement conversion methods usually rely on predefined templates or preset knowledge bases. When the table structure or field information in the database changes, the templates or knowledge bases need to be manually updated, resulting in high maintenance costs and poor flexibility. On the other hand, the method of generating SQL statements using a Large Language Model (LLM) also suffers from inaccurate results due to insufficient understanding of the database structure, especially when faced with complex query conditions or cross-table joins, making it impossible for users to accurately manipulate the data in the database using natural language. Summary of the Invention

[0004] This application provides a database operation method and computing device based on natural language. By obtaining database table structure information when generating SQL statements, the information acquisition capability of the large language model is optimized, thereby improving the accuracy of its generated SQL statements.

[0005] To achieve the above objectives, the embodiments of this application adopt the following technical solutions: In a first aspect, embodiments of this application provide a database operation method based on natural language. The method includes: in response to receiving a query instruction, obtaining table structure information of the database; generating table structure metadata based on the table structure information and a first format for filtering the table structure information; inputting the query instruction and the table structure metadata into a statement generation model to generate a structured query language (SQL) statement; and executing the SQL statement to obtain the statement execution result.

[0006] Based on this solution, by reconstructing the table structure information of all tables in the database into a metadata format that the model can parse, and inputting it together with the query command into the statement generation model, the model can parse the database table structure as context along with the query command when generating SQL statements. This allows for accurate matching of user query intent with the corresponding table structure, significantly improving the accuracy and adaptability of generated SQL statements and optimizing semantic parsing capabilities in complex query scenarios.

[0007] In one possible implementation, in response to receiving a query instruction, obtaining table structure information from the database includes: in response to receiving a query instruction, generating a metadata query request for obtaining database table structure information based on the query text used to obtain the table structure information; sending the metadata query request to the database; and generating table structure information in response to receiving feedback data from the database.

[0008] Based on this solution, metadata query requests can be automatically generated using predefined query text to dynamically obtain the latest table structure information in the database, avoiding SQL generation errors caused by table structure changes. This mechanism eliminates the need for manual maintenance of the knowledge base, improving the system's adaptability to changes in database table structure and enabling real-time perception and response to database structure changes.

[0009] In another possible implementation, the table structure information is filtered according to a first format to generate table structure metadata, including: obtaining the first format; the first format includes at least one target field and an arrangement format of the target field; based on at least one target field and the arrangement format, the field values ​​corresponding to the target fields in the table structure information are converted into table structure metadata; and the table structure metadata is stored in the session variables corresponding to the statement generation model.

[0010] Based on this solution, table structure information can be accurately filtered and formatted, retaining only core metadata, reducing model input noise, and improving the efficiency and accuracy of statement generation. Furthermore, by dynamically writing the processed table structure metadata into session variables, continuous tracking of context state is achieved, supporting the consistency of session variables in multi-round interactive query scenarios, and further enhancing the system's ability to understand complex business logic.

[0011] In another possible implementation, based on at least one target field and an arrangement format, the field values ​​corresponding to the target field in the table structure information are converted into table structure metadata, including: parsing the table structure information to obtain the field values ​​corresponding to each field in the database; filtering out redundant information in the field values ​​based on at least one target field; and converting the field values ​​after filtering out redundant information into table structure metadata in list format according to the arrangement format.

[0012] Based on this solution, the structure of the retrieved database tables can be restructured in a lightweight manner, removing irrelevant fields and redundant descriptions, while retaining core fields as contextual information for the model. This effectively reduces the complexity of the model input and improves processing efficiency and generation accuracy.

[0013] In another possible implementation, redundant information in field values ​​is filtered out based on at least one target field, including: determining the target field value based on the field value corresponding to each field in the database and the target field; the target field value includes the field value corresponding to the field with the same field name as the target field; and extracting the target field value from the field values.

[0014] Based on this solution, field values ​​can be accurately filtered, retaining only key information that matches the target field, thus avoiding irrelevant data from interfering with the process of generating query statements.

[0015] In another possible implementation, the table structure metadata is stored in the session variable corresponding to the statement generation model. The method further includes: constructing the session variable corresponding to the statement generation model; generating the table structure text corresponding to the table structure metadata; and storing the table structure text in the session variable.

[0016] Based on this solution, the table structure text can be stored in session variables, enabling persistent management of context information and sharing across multiple rounds of interaction, avoiding repeated parsing of the database structure, and improving system response efficiency.

[0017] In another possible implementation, the query command and table structure metadata are input into the statement generation model to generate an SQL statement, including: obtaining the natural language text corresponding to the query command; determining the prompt words for the statement generation model based on the natural language text and session variables; and inputting the prompt words into the statement generation model to generate an SQL statement that conforms to the session variables.

[0018] This solution enables deep integration of user query intent with table structure text, allowing the model to accurately identify the required tables and fields when generating SQL statements, avoiding misjudgments due to missing context. By coupling natural language queries with structured metadata at the prompt word level, the model's ability to parse complex semantics is enhanced, improving the generation accuracy in scenarios such as cross-table joins and nested queries.

[0019] In another possible implementation, the prompt words for the statement generation model are determined based on natural language text and session variables, including: obtaining the prompt word template corresponding to the query command; and generating prompt words based on the prompt word template, natural language text, and session variables.

[0020] Based on this solution, prompt words can be structurally assembled using prompt word templates, organically integrating natural language queries with table structure context to ensure complete semantic information delivery. Flexible template configuration adapts to the SQL statement generation needs of different operation types, improving the model's generalization ability and output stability across multiple scenarios.

[0021] In another possible implementation, in response to receiving a query command, obtaining the table structure information of the database also includes: obtaining session variables; and if the table structure text is already stored in the session variables, generating an SQL statement based on the query command and the session variables.

[0022] Based on this solution, cached table structure contexts can be directly reused, avoiding repeated database accesses to retrieve metadata and significantly reducing system resource consumption. By dynamically binding structured text in session variables with the current query intent, efficient and accurate SQL generation is achieved, while ensuring consistency and coherence of context across multiple rounds of dialogue.

[0023] In another possible implementation, after executing the SQL statement to obtain the statement execution result, the method further includes: in response to receiving a query end instruction, generating a query record based on the statement execution result, session variables, and query instructions; and deleting the session variables.

[0024] Based on this solution, the table structure text stored in the session variables can be released after the session ends, and temporary context data can be cleaned up in a timely manner to avoid memory resource consumption.

[0025] In another possible implementation, executing an SQL statement to obtain the statement execution result includes: sending the SQL statement to the database; generating query result data conforming to a second format in response to receiving the execution result returned by the database; and displaying the query result data.

[0026] Based on this solution, the raw execution results returned by the database can be converted into a structured data format that conforms to users' reading habits, thereby improving the readability and interactive experience of the results.

[0027] Secondly, embodiments of this application also provide a natural language-based database operating system, which includes: an information acquisition module configured to acquire table structure information of a database in response to receiving a query instruction; an information filtering module configured to generate table structure metadata conforming to a first format based on the table structure information; an inference module configured to input the query instruction and table structure metadata into a statement generation model to generate a structured query language (SQL) statement; and a database interaction module configured to execute the SQL statement to obtain the statement execution result.

[0028] Thirdly, embodiments of this application also provide a computing device, including: a processor and a memory; the processor and the memory are coupled; the memory is used to store program instructions; the processor is used to execute the program instructions to perform the method as described in any of the first aspects above.

[0029] Fourthly, embodiments of this application provide a chip for performing the methods described in any of the first aspects above.

[0030] Fifthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a computer, implement the method as described in any of the first aspects.

[0031] In a sixth aspect, embodiments of this application provide a program product including a computer program that, when executed by a processor, implements the method as described in any of the first aspects. Attached Figure Description

[0032] Figure 1 A system framework diagram of a database operation method based on natural language provided for embodiments of this application; Figure 2 A flowchart illustrating a database operation method based on natural language provided in an embodiment of this application; Figure 3 A flowchart for obtaining table structure information provided in an embodiment of this application; Figure 4 A schematic diagram showing the MCP service module provided in an embodiment of this application; Figure 5 Another flowchart illustrating the database operation method based on natural language provided in this application embodiment; Figure 6 This is yet another flowchart illustrating a database operation method based on natural language provided in an embodiment of this application. Figure 7 A schematic diagram of the process for ending a database query provided in an embodiment of this application; Figure 8 A flowchart illustrating the generation of SQL statements provided in this application embodiment; Figure 9 A flowchart illustrating the process of obtaining query results provided in this application embodiment; Figure 10 A schematic diagram of the structure of a natural language-based database operating system provided for embodiments of this application; Figure 11 This is a schematic diagram of the interaction architecture of the database operating system provided in the embodiments of this application; Figure 12This is a schematic diagram of a computing device provided in an embodiment of this application. Detailed Implementation

[0033] The technical solutions of the embodiments of this application will now be described with reference to the accompanying drawings. To facilitate a clear description of the technical solutions of the embodiments of this application, the use of terms such as "first," "second," etc., in the embodiments of this application is for illustrative purposes and to distinguish the objects being described. There is no particular order between them, nor does it indicate a specific limitation on the number of devices in the embodiments of this application, and they do not constitute any limitation on the embodiments of this application.

[0034] The following explanations of the technical terms mentioned in the embodiments of this application are provided to facilitate understanding by those skilled in the art.

[0035] Structured Query Language (SQL) is a standard programming language for managing and manipulating relational databases. Through its defined rules, it allows users to write statements that support database operations such as querying, inserting, updating, and deleting. SQL uses a declarative syntax; users only need to describe the target data and conditions for the desired operation, and the database engine automatically parses and generates the optimal execution path.

[0036] The Model Context Protocol (MCP) is a standardized communication protocol for interaction between Large Language Models (LLMs) and external tools and data sources. It defines the encapsulation format, transmission mechanism, and access control policy of context information, enhancing the accuracy and reliability of LLMs in specific tasks.

[0037] The application scenarios of this application are described below.

[0038] Databases serve as carriers for users' structured data storage. Based on databases, efficient querying, statistics, analysis, and management of data are possible, and they are widely used in various business systems. In the daily operations of an enterprise, business personnel often need to retrieve specific data from databases to support decision-making. However, retrieving data from a database requires SQL statements, which necessitates that business personnel possess SQL writing skills or rely on database technicians for assistance in completing queries, thus limiting the ability of non-technical personnel to use databases.

[0039] Traditional SQL statement generation methods typically rely on manual writing or the creation of SQL statements based on fixed templates. For example, technical personnel write query templates or corresponding matching rules to match natural language descriptions and populate parameters to generate the corresponding SQL statements. However, such methods depend on a large number of manually designed rules, resulting in high maintenance costs, poor generalization ability, and difficulty in handling complex and ever-changing query requirements. Furthermore, they struggle to flexibly adapt to new semantic understanding scenarios when business users have other needs, such as complex multi-table joins or database update operations.

[0040] Traditional methods that convert natural language descriptions input by business users into SQL statements using natural language processing technology also rely on a predefined knowledge base to store the database table structure and call it when needed to match and map database table fields. However, when faced with dynamically changing database structures, the knowledge base needs to be updated frequently, otherwise semantic parsing errors will occur. In addition, the accuracy of traditional methods drops significantly when dealing with synonyms, omitted expressions, or complex nested queries.

[0041] To address the aforementioned issues, this application provides a database operation method based on natural language. By obtaining the database table structure when generating SQL statements, the method optimizes the contextual accuracy of SQL statements generated from natural language. It also performs deep matching between the real-time extracted table structure information and the user's query intent, avoiding parsing deviations caused by knowledge base lag.

[0042] The following is combined Figures 1 to 9 This example illustrates the database operation method based on natural language provided in the embodiments of this application.

[0043] Figure 1 This is a system framework diagram of a database operation method based on natural language, provided for an embodiment of this application.

[0044] like Figure 1 As shown, the natural language-based database operation method provided in this application embodiment can be applied to the user-side device 11, and the user-side device 11 is communicatively connected to the database-side device 12. The user-side device 11 can transmit corresponding query instructions to the database-side device 12 and receive feedback content from the database-side device 12 through the communication connection.

[0045] In this embodiment, the user-side device 11 can be a mobile phone, tablet computer, handheld computer, personal computer (PC), ultra-mobile personal computer (UMPC), netbook, or other terminal computing device. The database-side device 12 can be a database carrier device, such as a local server, cloud storage platform, or distributed database system.

[0046] When user-side device 11 receives a query command input by the user, it can request the table structure information of the database from database-side device 12. Upon receiving the corresponding table structure information, user-side device 11 can process the query command using the appropriate format and statement generation model to generate the corresponding SQL statement. After generating the SQL statement, user-side device 11 can send it to database-side device 12 to obtain the corresponding statement execution result.

[0047] The above system framework describes the overall architecture and data flow of the natural language-based database operation method. Based on the above description, to further explain the execution logic and key technical details of the method, the database operation method is illustrated below with reference to the accompanying drawings.

[0048] Figure 2 A flowchart of a database operation method based on natural language provided in an embodiment of this application.

[0049] like Figure 2 As shown, this embodiment includes the following steps S11-S14: S11: In response to receiving a query command, obtain the table structure information of the database.

[0050] In step S11, the user-side device can connect to a database, which can be a relational database storing business data tables composed of structured data. The database can be hosted on a local server, a cloud storage platform, or a distributed database system, and supports the standard SQL query protocol. In this embodiment, the table structure information obtained in step S11 is the metadata of each data table in the database, including the full data such as the name of each data table, field names, field types, primary and foreign key constraints, and index information.

[0051] When the user-side device receives a query command, it can execute a metadata query request to extract the currently valid table structure metadata from the database, providing real-time data support for the subsequent SQL statement generation process.

[0052] In one example, the user-side device can be a terminal device such as a mobile phone, tablet, or personal computer, running a client application that supports natural language interaction. In another example, the user-side device can also be a server that can communicate with the terminal device to receive query commands sent by the terminal device and convert the natural language into corresponding SQL statements through subsequent processing.

[0053] The database in this application embodiment can be a relational database management system that supports the standard SQL protocol, such as MySQL, PostgreSQL, or Oracle. The query requests, such as SQL statements, sent by the user-side device to the database are initiated to the database management system, which parses them and completes the database operation process by calling the corresponding storage resources of the database.

[0054] Users can input natural language queries through the client application, such as "show the products with the highest sales last quarter". Upon receiving this instruction, the user-side device first sends a metadata query request to the database to obtain the table structure information of all tables in the current database, including table names, field names, data types, and constraints, and then converts this table structure information into corresponding table structure metadata and caches it in the local session context.

[0055] In one example, the table structure information obtained by the user-side device includes data such as the database table name, field names, data types, constraints, and indexes. The table name refers to the data table from which this table structure information originates; the field names refer to the column names of the data columns within the data table; the data types refer to the data types corresponding to the content in the data columns; constraints are parameters used to constrain how the content of each data column in the data table is filled, and constraints can include primary key constraints, foreign key constraints, etc.; indexes include various parameters used to accelerate database query speed.

[0056] S12: Filter table structure information according to the first format to generate table structure metadata.

[0057] In step S12, since some parameters in the database table structure, such as the data length corresponding to the field, have no direct impact on the generated SQL statement, and a large amount of redundant information may interfere with the model's recognition of key semantics, it is necessary to filter and format the original table structure information.

[0058] After obtaining the table structure information, the user-side device can simplify and normalize the various metadata in the table structure information, retaining core information such as table name, field name, data type, and primary key and foreign key constraints in the constraint relationship, and generating table structure metadata that conforms to the first format defined in the user-side device.

[0059] In this context, a primary key constraint refers to whether the data column corresponding to a field name is a primary key parameter, while a foreign key constraint identifies whether the data column corresponding to a field name is a foreign key that relates to other tables and the target table and data column it references. In some embodiments, by utilizing primary key and foreign key constraints, the statement generation model can accurately construct the relationship logic between data tables, avoiding semantic ambiguity when generating cross-table queries.

[0060] In one example, the first format can be used to filter table structure information, thereby limiting the number of fields in the table structure information, preserving key semantic identifiers to simplify the metadata structure, and reducing the computational overhead of generating SQL statements.

[0061] S13: Input the query instructions and table structure metadata into the statement generation model to generate a Structured Query Language (SQL) statement.

[0062] In step S13, the user-side device can input the natural language text corresponding to the query instruction and the table structure metadata in the first format into the pre-trained statement generation model. The statement generation model identifies the contextual relationship between the natural language text and the table structure metadata and uses it as prompt words to generate the corresponding SQL statement.

[0063] In one example, the statement generation model could be a Large Language Model (LLM), trained on text and code data, capable of understanding natural language and generating structured query statements. Based on the input context, this model can accurately identify user intent and, combined with key information such as field semantics in the database table structure and primary and foreign key constraints, automatically generate syntactically correct and logically rigorous SQL query statements, thus achieving efficient conversion from natural language to executable database queries.

[0064] For example, when natural language involves cross-table queries across multiple data tables, the statement generation model can use primary key constraints and foreign key constraints to construct the relationship logic between the various data tables, thus avoiding semantic ambiguity in the generated SQL statements.

[0065] S14: Execute the SQL statement to obtain the result of the statement execution.

[0066] In step S14, after receiving the SQL statement generated by the statement generation model, the user-side device can send it to the database for execution. That is, the process of the user-side device executing the SQL statement may include sending the SQL statement to the corresponding database-side device to obtain the statement execution result from the database-side device.

[0067] In this embodiment, the user-side device can send a generated SQL statement to the database by calling the database operation interface in the target database. After receiving the SQL statement, the database can execute the query operation accordingly, scan the relevant data tables, filter matching data records according to the conditions in the statement, and finally return the result set to the user-side device.

[0068] After receiving the result set returned by the database, the user-side device can present the result set as the statement execution result to the user through the display module. It is understood that the query instructions and processes in the above embodiments are merely illustrative examples. In reality, the SQL statements generated based on steps S11 to S14 can, based on their semantics, also perform corresponding add, delete, and modify operations on the database to achieve comprehensive data management. For example, when a user inputs "add a new order record," the system can parse the intent and generate an INSERT statement; for "delete expired product information," a DELETE statement is automatically constructed and executed, improving the convenience of database operations.

[0069] This embodiment of the application, through steps S11-S14 described above, can query table structure metadata in the database based on user-input natural language commands, and automatically convert natural language into SQL statements using a statement generation model. This allows non-professional users to efficiently complete database query and management operations. In this way, database operations do not require users to manually write code; data operations can be performed solely through natural language text, significantly lowering the barrier to entry and improving the intelligence level of data interaction.

[0070] The steps in the above embodiments will be further described below with reference to the accompanying drawings.

[0071] Figure 3 A flowchart illustrating the process of obtaining table structure information as provided in an embodiment of this application.

[0072] like Figure 3 As shown, in one implementation, in the above... Figure 2 Based on the illustrated embodiment, step S11 may include the following steps S111-S113: S111: In response to receiving a query instruction, generate a metadata query request to obtain database table structure information based on the query text.

[0073] In step S111, the user-side device is equipped with a query text for obtaining database table structure information. The query text is a standardized SQL statement for querying the full database table structure, so that after receiving the query instruction, the user-side device can obtain the complete metadata of the table structure in the database based on the query text, including table name, field name, data type, constraint information, and index information.

[0074] In one example, the query text can be implemented through the MCP service module, which is a core component for enabling secure and efficient communication between user-side devices and the database. It encapsulates metadata query requests based on the MCP communication protocol and extracts table structure information by calling database access tools through an interface.

[0075] Figure 4 This is a schematic diagram showing the MCP service module provided in an embodiment of this application.

[0076] For example, such as Figure 4 As shown, the MCP service module can respond to user input by pre-registering a dedicated database operation tool and defining its name (e.g., `execute_sql`) based on the user's input. Its input and output parameters are defined according to the MCP communication protocol specification to ensure data transmission integrity and security. This database operation tool encapsulates user-defined query text. Upon receiving a query command, the user-side device automatically invokes this tool and generates a metadata query request based on the query text.

[0077] The database operation tools in the MCP service module can leverage the self-describing nature of the database to obtain the full table structure of the database by querying the system tables. The query text can be a predefined SQL statement, designed to retrieve the full table structure information in one go, avoiding the inefficiency and information loss caused by multiple queries.

[0078] In one example, such as Figure 4 As shown, the query text includes at least three core query parts: a first query field 41 for specifying the query content, a second query field 42 for specifying the data source, and a third query field 43 for limiting the query conditions. The three work together to construct the complete metadata query logic.

[0079] The first query field 41 defines the type of metadata to be retrieved, such as table name, field name, whether it is a primary key, whether it can be nullable, and maximum data length, ensuring that the metadata query results have complete structured descriptive capabilities. The second query field 42 points to the database system table, such as information_schema.tables or information_schema.columns in a MySQL database, ensuring that the query scope covers all table structure information of the target database. The third query field 43 adds filtering conditions, such as specifying a specific database name, to limit the queried table structure information to the target range, avoiding redundant data interference. Through the combination of these three, the query text can accurately extract the complete table structure metadata of the specified database and return it to the user-side device in a standardized format, providing high-quality and consistent data input for subsequent table structure processing modules.

[0080] For example, the first query field 41 could be "SELECT TABLE_NAME, COLUMN_NAME, IS_NULLABLE, DATA_TYPE, CHARACTER_MAXIMUM_LENGTH, COLUMN_KEY", the second query field 42 could be "FROM information_schema.columns", and the third query field 43 could be "WHERE TABLE_SCHEMA = 'user_database'". This allows for the efficient retrieval of structural metadata such as column names, data types, null constraints, primary key information, and character length limits from all tables in the target database using a single SQL statement, ensuring complete information and eliminating the system overhead of duplicate queries.

[0081] It is understood that the specific content of the query text shown in the above embodiments is only an example provided in the embodiments of this application. The query text used in the embodiments of this application is not limited to the specific field combinations and syntax structures limited by the above examples, and the specific implementation form of the query text is not limited in the embodiments of this application. Field selection and query logic can be flexibly adjusted according to the metadata organization method of different database systems to ensure compatibility and scalability.

[0082] For example, the first query field can also include more metadata attribute fields, such as column description, default value, character set, sorting rules, etc. The return name of each field can also be customized by introducing the "AS" field, which can improve the readability and compatibility of the result set, such as "COLUMN_NAME AS column_name", thereby achieving a unified field naming standard.

[0083] The second query field can be adjusted to the system table path corresponding to the database based on changes in the database type, or the query path can be dynamically generated by querying the table structure information of all tables in the database. For example, in Oracle databases, system views such as all_tab_columns or dba_tab_columns can be used to replace "information_schema.columns" in the second query field.

[0084] The third query field can also be expanded with filtering conditions according to actual needs, such as limiting to specific table names, column name prefixes, or data type categories, to further narrow the query scope and improve response efficiency.

[0085] S112: Send the metadata query request to the database.

[0086] In step S112, after generating a metadata query request, the user-side device can send it to the database. The database can receive and parse the request, and retrieve the corresponding record from the system table according to the instruction corresponding to the metadata query request, execute the query, and return the result set. It is understood that the database in this embodiment refers to a database management system, which has the ability to parse SQL syntax, locate the metadata storage location, and execute access control, thereby responding to external query requests and returning structured results.

[0087] In one example, the returned result set will contain the table structure information of all tables in the target database that meet the criteria. After organizing the query results in a standardized format, the data will be transmitted to the user's device as feedback data.

[0088] In some embodiments, the user-side device can trigger the MCP service module to call the metadata query interface, encapsulate the query text into request parameters, and transmit them to the database server via a secure communication protocol. After parsing the request, the server uses pre-compiled SQL to perform metadata retrieval and obtain the corresponding result set, ensuring that the query process complies with the database access control policy.

[0089] S113: In response to receiving feedback data from the database, generate table structure information.

[0090] In step S113, the user-side device can respond to the feedback data sent by the database server, parse and structure the returned metadata information, extract key fields such as table name, column name, data type, and constraints, and map them into locally recognizable objects to obtain the table structure information of the database.

[0091] In one example, when sending feedback data, the database can encapsulate metadata information into JSON (JavaScript Object Notation) or XML data packets to obtain structured data, making it easier for user-side devices to parse and process. At the same time, the standardized output of the database ensures consistency in metadata representation across different database systems, enhancing the compatibility and scalability of cross-platform metadata interaction.

[0092] Taking the database encapsulating metadata information in JSON format as an example, the feedback data can include a collection of key-value pairs corresponding to attributes such as table name, column name, data type, and whether null is allowed. For example, the feedback data can be in the following form: [{"table_name":"Products","column_name":"ProductID","data_type":"int","column_type":"int","max_length":null,"is_nullable":"NO","default_value":null,"extra_info":"auto_increment","column_key":"PRI","column_comment":""}).

[0093] This data structure can be directly loaded by the parsing engine of the user-side device. By traversing the JSON array, the table structure information in memory can be constructed, improving query efficiency and response speed while reducing the complexity of data parsing.

[0094] Through the above steps S111 to S113, the embodiments of this application can accurately obtain the database table structure information before generating SQL statements, ensuring that the user-side device has the context support of the data model when constructing SQL statements, thereby avoiding syntax errors and field misuse, and thus improving the accuracy and execution efficiency of queries.

[0095] In one implementation, after receiving feedback data from the database and generating corresponding table structure information, the user-side device can process and modify the table structure information to reconstruct it in a way that is closer to the understanding and generation logic of the large language model, thereby optimizing its context-aware ability in the natural language to SQL statement conversion process.

[0096] Figure 5 This is another flowchart illustrating a database operation method based on natural language provided in an embodiment of this application.

[0097] like Figure 5 As shown, in one implementation, in the above... Figure 2 Based on the illustrated embodiment, step S12 may include the following steps S121-S125: S121: Obtain the first format.

[0098] In step S121, after obtaining the table structure information, the user-side device can first read the first format stored in its own storage, so that the user-side device can use the first format to process the obtained table structure information and obtain the corresponding table structure metadata.

[0099] In this embodiment, the first format may include the target field and the arrangement format of the target field. The target field refers to the key field in the table structure information that needs to be retained, and the arrangement format refers to the arrangement format of the field values ​​corresponding to the selected target field.

[0100] For example, the target fields in the first format can retain only the core fields closely related to natural language understanding and SQL generation, such as table name, column name, data type, whether it can be nullable, and the insertion of default values, thereby reducing noise interference in the input of the statement generation model and improving the efficiency of semantic parsing.

[0101] The arrangement format involves arranging the field values ​​corresponding to the core fields in the database in a predefined order. For example, the field information can be organized in a fixed order of "table name, column name, data type, whether it can be nullable, and insert default value" to ensure a consistent format and clear structure, thereby reducing the risk of model misjudgment caused by redundant information.

[0102] S122: Based on at least one target field and arrangement format, convert the field value corresponding to the target field in the table structure information into table structure metadata.

[0103] In step 122, after obtaining the first format, the user-side device can convert the corresponding fields in the table structure information based on the target fields and arrangement format in the first format, and convert them into the corresponding table structure metadata, so that the user-side device can generate the SQL statement corresponding to the query instruction based on the table structure metadata.

[0104] For example, the user-side device can extract the corresponding field values ​​from each field in the table structure information based on the field name of the target field, and then generate table structure metadata that matches the arrangement format based on the extracted field values.

[0105] S123: Store the table structure metadata into the session variables corresponding to the statement generation model.

[0106] In step S123, the user-side device can store the obtained table structure metadata in the session variables of the statement generation model to provide contextual content for the statement generation model through the table structure metadata, so that the statement generation model can continuously reference the table structure metadata during the process of generating SQL statements.

[0107] Session variables are a context management mechanism in LLM (Local Management Module), providing a temporary, readable, writable, and transferable storage space within a single session for temporarily storing structured data related to the current session. Session variables are created at the start of a session and automatically released at its end, ensuring the isolation and security of context information. By introducing session variables into the SQL generation process, user-side devices can continuously transmit simplified table structure metadata across multiple interactions, avoiding repeated parsing of original information and improving processing efficiency.

[0108] In some embodiments, session variables are primarily used to provide a stable and unchanging context for a single session, ensuring that the user always queries based on the same simplified table structure information during multiple rounds of command input. This avoids the ambiguity or loss of certain table structure information during multiple rounds of command input in the same usage process due to the attention mechanism of LLM, thereby improving the consistency and accuracy of the SQL statements generated by LLM with the table structure of the database.

[0109] This embodiment of the application, through steps S121 to S123, effectively integrates the table structure information of the database, removes redundant information from the table structure information, and reconstructs it into a lightweight format that is easy for LLM to understand. This ensures that the table structure metadata is highly aligned with natural language queries in terms of semantic expression and logical organization, thereby improving the accuracy and efficiency of SQL generation. Furthermore, based on the LLM mechanism, the table structure metadata is stored using session variables, achieving the persistence and efficient reuse of context information. This enables LLM to stably and accurately understand the correspondence between user intent and database structure in multi-turn interactions, significantly improving the coherence and semantic matching of SQL generation.

[0110] S124: Get session variables.

[0111] In step S124, the user-side device can determine whether the corresponding table structure text already exists in the LLM as the model's context based on the number of responses the LLM receives in the current session. It is understood that step S124 can be executed when the user-side device receives a query command, used to determine whether the required table structure text is already contained in the current session context.

[0112] If the session variable does not store the table structure text, the user-side device can execute step S1231 to create the corresponding session variable, and then execute steps S1232 and S1233 to write the reconstructed table structure text into the session variable. If the session variable stores the table structure text, the user-side device can execute step S125 to call the statement generation model to parse the user-input query command and the text stored in the session variable to generate the corresponding SQL statement.

[0113] S125: When the table structure text is already stored in the session variables, generate an SQL statement based on the query command and the session variables.

[0114] In step S125, the user-side device can directly access the table structure text in the loaded session variables. Based on the query command and session variables, it uses a statement generation model to generate the corresponding SQL statement. This avoids the redundant overhead of repeatedly transmitting the same table structure information in a single session, while ensuring the contextual consistency of semantic parsing. This enables a dynamic maintenance and on-demand loading mechanism for session variables, ensuring that session variables are updated or rebuilt only in the initial stage of a multi-round interaction. Subsequent interactions directly reuse the cached table structure information, maintaining the contextual consistency within a single LLM session and reducing communication and computing resource consumption.

[0115] This embodiment of the application, through steps S124 to S125 described above, achieves efficient management and reuse of table structure metadata in the session context, effectively reducing redundant data transmission in multi-round interactions and improving the response speed and semantic accuracy of SQL generation. Simultaneously, by dynamically judging the state of session variables, it ensures timely updates to session variables during the first query or when the structure changes, and directly reuses cached data during non-first queries and when the structure has not changed. This optimizes resource utilization efficiency while maintaining semantic coherence, avoids redundant computational overhead, and improves the efficiency of SQL statement generation.

[0116] Figure 6 This is another flowchart illustrating a database operation method based on natural language provided in an embodiment of this application.

[0117] like Figure 6 As shown, in one implementation, in the above... Figure 5 Based on the illustrated embodiment, steps S122 and S123 may respectively include the following steps S1221-S1223 and steps S1231-S1233: S1221: Parse the table structure information to obtain the field value corresponding to each field in the database.

[0118] In step S1221, after obtaining the table structure information, the user-side device can parse the table structure information to obtain the field values ​​corresponding to each table structure field. For example, after obtaining feedback data, the user-side device can directly use the JSON-formatted feedback data as table structure information and obtain its field values, such as table name, column name, data type, and whether it is a primary key, through parsing.

[0119] Taking the feedback data in the aforementioned embodiment as an example, the user-side device can obtain field values ​​such as table name "Products", column name "ProductID", data type "int", whether it can be null "NO", and insertion default value "null". The user-side device obtains the attribute values ​​corresponding to all fields in the table structure information to avoid omission of table structure metadata, ensure the integrity of table structure metadata, and improve the accuracy and executability of the subsequently generated SQL statements.

[0120] S1222: Based on at least one target field, filter out redundant information in the field values.

[0121] In step S1222, when the user-side device extracts the field value corresponding to the field, it can classify and process the field attributes based on predefined field classification rules. For example, fields with the same table name can be grouped into the same logical group to facilitate the unified management and structured organization of subsequent fields.

[0122] In one example, the first format may also include a field value filtering method, where the filtering method refers to filtering out redundant information in the obtained field values ​​that is not related to the generation of the SQL statement, such as internal identifiers automatically generated by the database or technical fields without business meaning, such as maximum data length, field notes, key type, extended attributes, etc.

[0123] In this embodiment, the user-side device can also extract the target field value corresponding to the target field from the table structure information returned by the database to determine the information that needs to be retained and the redundant information in the field value. For example, the target field value can be determined by the field value corresponding to the field with the same field name as the target field. By extracting the target field value from the field values, redundant information can be filtered out, avoiding redundant information from affecting the statement generation efficiency of the statement generation model.

[0124] S1223: Convert the field values ​​after filtering out redundant information into table structure metadata in list format according to the arrangement format.

[0125] In step S1223, the user-side device filters out redundant information from the field values ​​using the first format, obtaining simplified structured field information, and organizes it into lightweight metadata in a unified order. For example, the arrangement format defined in the first format can be a list based on the table names of the data table, with the table names serving as the top-level nodes of the list, generating table structure metadata in list format.

[0126] In one example, the table structure metadata can be represented in the format shown in Table 1 below: Table 1

[0127] Among them, the column name, data type, whether it can be nullable, and the default value are all core fields that the user-side device selects from the table structure information received, including the full table structure of the database, based on the first format. The corresponding values ​​are all valid attribute values ​​extracted and cleaned from the received raw metadata, ensuring that only key information that contributes to the semantics of SQL generation is retained.

[0128] In one example, the first format can also be a JSON format that filters out some key-value pairs in the table structure information, such as a JSON object that only retains core fields such as column names, data types, whether they can be nullable, and insert default values, in order to reduce interference from redundant information.

[0129] By aggregating fields with the same table name to form a metadata set based on data tables, the table structure can be described, achieving a clear expression of table structure information. Table structure metadata facilitates the model's rapid location of the target table and its field details, improving the efficiency of natural language to SQL statement conversion. Furthermore, this structure optimizes the model's understanding of field hierarchy relationships, reduces ambiguity during semantic parsing, and avoids contextual interference caused by redundant fields or formatting issues, further enhancing the LLM's accurate understanding of the mapping relationship between user query intent and database structure.

[0130] S1231: Construct session variables corresponding to the statement generation model.

[0131] In step S1231, the user-side device can construct session variables corresponding to the LLM before generating SQL statements, so as to store table structure metadata through session variables, provide stable context support for the LLM through session variables, and ensure that the simplified table structure information is continuously referenced in multiple rounds of interaction.

[0132] In one example, the process of constructing session variables can be triggered immediately after the user-side device receives the query command. This allows the user-side device to obtain the table structure metadata and write it into the corresponding session variables, ensuring that it can be directly referenced in subsequent SQL generation. This mechanism effectively ensures context consistency, avoids parsing deviations caused by repeated information loading or structural changes, and improves the stability and response efficiency of LLM's understanding of the database structure in multi-turn interaction scenarios.

[0133] S1232: Generate the table structure text corresponding to the table structure metadata.

[0134] In step S1232, the user-side device can convert the table structure metadata into the corresponding table structure text so that it can be stored in session variables in subsequent processes.

[0135] In one example, the user-side device can present the table structure metadata, converted to a list format, as text, so that the LLM can directly parse and understand the table structure text in subsequent steps.

[0136] In another example, the user-side device can also maintain the original format of the table structure information when generating table structure metadata. That is, generate table structure metadata in JSON or XML format consistent with the table structure in the database, and serialize it and store it in session variables. This allows the LLM to efficiently parse and accurately map field relationships when generating SQL, enhance the model's ability to recognize complex table structures, and thus improve the accuracy and execution efficiency of the generated statements.

[0137] S1233: Store the table structure text into a session variable.

[0138] In step S1233, the user-side device can write table structure metadata into session variables to manage and call the table structure metadata in a unified manner through session variables. This ensures that the LLM can continuously and stably access the same table structure information in multiple sessions, improves the coherence and consistency of SQL statements generated by the LLM, and avoids parsing errors caused by context switching or missing information.

[0139] Meanwhile, the introduction of session variables allows the LLM to handle multiple rounds of query requests within a single session without repeatedly loading the complete table structure, significantly reducing model input length and computational overhead. Furthermore, the lifecycle of session variables can be coupled with the lifecycle of the LLM session; after the session ends, table structure metadata in the session variables can be cleared, releasing memory resources and ensuring system efficiency and data security.

[0140] Figure 7 This is a schematic diagram of a process for ending a database query, provided in an embodiment of this application.

[0141] like Figure 7 As shown, in one implementation, in the above... Figure 2 and Figure 6 Based on the illustrated embodiment, the database operation method provided in this application embodiment may further include the following steps S15-S16: S15: In response to receiving a query end instruction, generate query records based on the statement execution result, session variables, and query instructions.

[0142] In step S15, after receiving the query end command input by the user, the user-side device can generate a complete query record based on the statement execution result obtained in the current session, the table structure text in the session variables, and the query command in the current session. In one example, the query record includes the query command text, the corresponding SQL statement, the execution result summary, and the session timestamp, which is used for subsequent statement generation traceability and facilitates subsequent users to query and reproduce the statement generation process.

[0143] The query termination command can be a user-initiated "End Query" command, a user closing the session connection, a user exiting the database operation interface, or a system detecting a session timeout. Upon receiving a query termination command in any of these forms, the user-side device can trigger the process of generating a query record and persistently store the query record in a local log file.

[0144] S16: Delete session variables.

[0145] In step S16, after generating and storing the query record, the user-side device can release the memory resources of the session variables corresponding to the LLM and clear the table structure text in the cache to avoid invalid occupation of system memory resources. This ensures that temporary data is promptly reclaimed and computing resources are released after multiple rounds of interaction. This mechanism not only improves the overall operating efficiency of the system but also supports the rapid initialization of subsequent new sessions, ensuring the stability and continuity of service responses.

[0146] It is understandable that deleting a session variable can mean deleting the data content in the storage space corresponding to the session variable, thereby clearing the storage space corresponding to the session variable, but retaining the structure definition of the variable for reuse in subsequent sessions; or it can mean completely releasing the memory space occupied by the variable, and recreating the session variable and loading the latest table structure text through step S124 in the aforementioned embodiment when needed.

[0147] The above-mentioned session variable deletion method can be flexibly configured according to the memory management needs of the actual deployment environment. In this application embodiment, there is no restriction on its specific implementation method.

[0148] Figure 8 This is a flowchart illustrating the process of generating SQL statements provided in an embodiment of this application.

[0149] like Figure 8 As shown, in one implementation, in the above... Figure 2 Based on the illustrated embodiment, step S13 may include the following steps S131-S133: S131: Obtain the natural language text corresponding to the query command.

[0150] In step S131, after receiving the query command, the user-side device can perform semantic parsing on the query command to obtain the natural language text corresponding to the query command. It is understood that the statement generation model used in this embodiment is a large language model set up on the backend of the user-side device. The query command input by the user through the interactive front end of the user-side device is not directly transmitted to the large language model for SQL statement generation. Instead, after the interactive front end receives the query command, the user-side device preprocesses the query command, converts it into natural language text, and then inputs it along with the table structure information cached in the session variables into the large language model to execute the SQL statement generation process.

[0151] In one example, since the query command received by the user-side device can be a text command, the user-side device can directly perform text standardization processing on the text command to obtain the corresponding natural language text. For example, it can unify character encoding, remove redundant spaces, or supplement grammatical structures to improve the accuracy of semantic parsing. For non-text query commands, such as voice or graphical input, the user-side device first converts them into standard text through the corresponding recognition module before performing standardization processing.

[0152] S132: Determine prompt words for the statement generation model based on natural language text and session variables.

[0153] In step S132, since the query command is not a prompt word input into the statement generation model, the user-side device can perform context alignment between the natural language text generated corresponding to the query command and the table structure metadata cached in the session variables, construct a prompt word that conforms to the input format of the large language model, and then input it into the statement generation model for joint encoding. This allows the model to fully perceive the field constraints and relationships of the database table structure while understanding the user's query intent, thereby generating an SQL statement that conforms to the syntax and is semantically accurate.

[0154] In one example, the user-side device can be configured with a prompt word template. This template predefines the concatenation format of natural language text and table structure metadata, such as separating semantic descriptions and field information using special symbols, and annotating the target field, condition fields, and relationships. After obtaining the natural language text corresponding to the query instruction and the table structure metadata from session variables, the user-side device combines them into structured prompt words according to the prompt word template, and inputs them into a large language model for semantic understanding and SQL generation. In this way, the model can accurately capture the user's query intent based on context alignment and generate efficient and secure SQL statements by combining the actual database structure, effectively avoiding field misuse or syntax errors, and improving query accuracy and system reliability.

[0155] For example, the prompt template may include task information and input hints. The task information refers to the task that the large language model needs to perform, while the input hints are the required information for the large language model to perform the task. In this embodiment, the task information may be "You are an intelligent SQL generator (SQL AGENT). Based on the provided table structure information: 1. Deeply analyze the semantic intent of the user's query; 2. Intelligently infer the fields actually needed by the user (prioritizing name fields rather than ID fields); 3. Accurately generate data manipulation SQL;" Only generate the required SQL output; do not add any thought process, explanations, or content outside the specified format. ".

[0156] Input suggestions include standardized natural language query text and table structure metadata dynamically loaded from session variables. In the suggestion template, these can be presented in the following format: ## Input source - User Inquiry Natural Language Request Reference: Natural Language Text - DDL LLM output For table structure information related to the question, please refer to: "Session variables".

[0157] Here, "natural language text" refers to the standardized result of the user-input query, and "session variables" are the lightweight table structure text cached in the current session. This allows for the generation of corresponding prompt text based on prompt word templates, natural language text, and session variables, which then serves as input to the large language model to execute the SQL statement generation process.

[0158] In some embodiments of this application, since users may perform operations other than querying database content when operating the database, such as adding or deleting table structures or modifying data records in the query command input by the user, the user-side device can set multiple prompt word templates to adapt to different operation types according to the operation type corresponding to the query command.

[0159] Before generating prompts using prompt templates, user-side devices can identify operation type keywords in query commands, such as "add," "insert," "delete," and "modify," to determine the corresponding operation category and then select a matching prompt template. Different templates will guide the large language model to generate SQL statements that conform to semantic intent and grammatical rules, ensuring that CRUD operations can be executed safely under structured constraints, preventing data anomalies caused by unauthorized operations or logical errors, and improving the system's responsiveness and operational stability to complex requests.

[0160] S133: Input the prompt words into the statement generation model to generate SQL statements that conform to the session variables.

[0161] In step S133, after the user terminal generates the prompt word, it can input the prompt word into the statement generation model. The model parses the semantic information and context of the prompt word and automatically generates an SQL statement that conforms to the relational database specification based on the semantic rules and syntax structure of the SQL.

[0162] Among them, the table structure metadata in the session variables provides complete and accurate context support for the model, ensuring that the target table and fields can be accurately located when generating SQL statements, so that the generated SQL statements fully comply with the database requirements in terms of syntax structure and can reflect the true intent of the query command entered by the user.

[0163] This application embodiment achieves automated conversion from natural language queries to SQL statements through the above steps S131 to S133, improving the security and efficiency of database operations while ensuring semantic accuracy. By dynamically loading table structure metadata and using a multi-template prompting mechanism, the large language model can accurately understand user intent in specific contexts and generate operation statements that conform to grammatical rules and permission constraints. This effectively avoids execution errors caused by semantic ambiguity or structural misjudgment, providing a reliable statement conversion function for data interaction in complex business scenarios.

[0164] Figure 9 This is a schematic diagram of a process for obtaining query results provided in an embodiment of this application.

[0165] like Figure 9 As shown, in one implementation, in the above... Figure 2 Based on the illustrated embodiment, step S14 may include the following steps S141-S143: S141: Send the SQL statement to the database.

[0166] In step S141, after the user-side device generates an SQL statement that conforms to the session variables using the statement generation model, it sends the SQL statement to the database, executes the SQL statement, operates on the target data in the database, and obtains the corresponding operation results.

[0167] S142: In response to receiving the execution result returned by the database, generate query result data that conforms to the second format.

[0168] In step S142, the user-side device can generate query result data conforming to the second format in response to the execution result returned by the database. Because the SQL statement sent by the user-side device can perform any of the various types of operations such as CRUD (Create, Read, Update, Delete), the execution results received by the user-side device will differ based on the different operation types. Accordingly, the query result data generation logic will be differentiated according to the operation type.

[0169] For example, for query operations, if the returned result is a dataset that meets the criteria, the system will encapsulate the dataset into structured response content according to the second format, including the mapping relationship between field names and corresponding values, and supporting additional annotations for pagination and sorting information. For insert, update, or delete operations, it will generate operation feedback results including the number of rows affected, execution status code, and timestamp. This processing mechanism ensures that the query result data can accurately reflect the actual effect of the database operation and provides a consistent data interaction interface for the front-end application, enabling users to operate the database and obtain structured feedback by inputting natural language, achieving a low-threshold and high-efficiency data interaction experience.

[0170] S143: Display the query results data.

[0171] In step S143, the user-side device can display corresponding content on the interactive front end based on the obtained query result data, enabling users to intuitively obtain the information they need. For query operations, the system presents the dataset in table format on the front end, supporting field filtering, pagination browsing, and sorting interaction; for add, delete, and modify operations, the system provides feedback on the execution status through prompt boxes, displaying the number of rows affected and the operation timestamp, enhancing the credibility of the operation. Simultaneously, the front-end interface retains optional viewing entries for natural language commands and corresponding SQL statements, facilitating technical personnel to trace and debug the execution process, ensuring transparent and controllable operation.

[0172] This application embodiment achieves a complete closed loop from natural language to database operation through the above steps S141 to S143, ensuring that users can efficiently and accurately complete data query and management tasks without having to master SQL syntax. It also makes it easier for users to view operation results and understand the system execution logic, improve human-computer collaboration efficiency, and lower the data access threshold.

[0173] Corresponding to the aforementioned embodiments of the database operation method based on natural language, this application also provides embodiments of the database operating system based on natural language.

[0174] Figure 10 This is a schematic diagram of the structure of a natural language-based database operating system provided in an embodiment of this application. Figure 11 This is a schematic diagram of the interaction architecture of the database operating system provided in an embodiment of this application.

[0175] like Figure 10 As shown in the figure, this application embodiment also provides a natural language-based database operating system 1000, which may include an information acquisition module 1010, an information filtering module 1020, an inference module 1030, and a database interaction module 1040.

[0176] The information acquisition module 1010 is used to obtain the table structure information of the database in response to receiving a query command.

[0177] The information filtering module 1020 is used to generate table structure metadata that conforms to the first format based on the table structure information.

[0178] The inference module 1030 is used to input query instructions and table structure metadata into the statement generation model to generate Structured Query Language (SQL) statements.

[0179] The database interaction module 1040 is used to execute SQL statements and obtain the results of the statement execution.

[0180] like Figure 11 As shown, the database operating system 1000 provided in this application embodiment can be set in the user-side device 1100. The user-side device 1100 also includes an interactive front-end 1110, which is used to receive natural language commands input by the user and display the query result data generated by the database operating system 1000 based on the user input commands. The interactive front-end 1110 presents the query results in a visual manner, supports the user to perform dynamic filtering and export operations on the data, and retains the history of natural language commands for easy tracing and reuse in the future.

[0181] Database system 1120 is a database management system. The storage space corresponding to database system 1120 contains business data. Database system 1120 can perform corresponding operations on the business data in its storage space in response to received SQL statements.

[0182] The database system 1120 can be located within the user-side device 1100 or in an external independent device such as a cloud server or a local server, communicating with the user-side device 1100 through a secure encrypted channel. For example, the database interaction module 1040 in the database operating system 1000 establishes a connection with the database system 1120 to send SQL statements to the database and receive execution results, ensuring accurate transmission of instructions and secure data interaction.

[0183] Figure 12 This is a schematic diagram of a computing device provided in an embodiment of this application.

[0184] like Figure 12 As shown, the computing device 1200 includes a processor 1201 and a memory 1202. Exemplarily, the computing device 1200 may also include a communications interface 1203 and a communications bus 1204.

[0185] The processor 1201, memory 1202, and communication interface 1203 communicate with each other via communication bus 1204. The communication interface 1203 may include a transmitter and receiver for communicating with other devices or communication networks. It can be a wired interface (port), such as a fiber distributed data interface (FDDI) or a gigabit Ethernet interface (GE).

[0186] In some embodiments, the processor 1201 is used to execute program 1205, specifically performing the relevant steps in the above-described inference task execution method embodiments. Specifically, program 1205 may include program code, which includes computer-executable instructions.

[0187] For example, processor 1201 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement some embodiments of this application. Computing device 1200 may include one or more processors, which may be processors of the same type, such as one or more CPUs; or processors of different types, such as one or more CPUs and one or more ASICs. The CPU may be a single-core CPU or a multi-core CPU.

[0188] In some embodiments, memory 1202 is used to store program 1205. Memory 1202 may include high-speed random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device.

[0189] Specifically, program 1205 can be called by processor 1201 to cause computing device 1200 to perform the method operations described in the above embodiments.

[0190] Some embodiments of this application provide a computer-readable storage medium storing at least one executable instruction that, when executed on a computing device 1200, causes the computing device 1200 to perform the natural language-based database operation method described in the above embodiments.

[0191] Specifically, the executable instructions can be used to enable the computing device 1200 to perform database operation methods based on natural language.

[0192] For example, the computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a compact disc read-only memory (CD-ROM), magnetic tape, a floppy disk, and an optical data storage device, etc.

[0193] This application provides a chip device in some embodiments, which is applied to a server. The chip device includes one or more interface circuits and one or more processors. The interface circuits and processors are interconnected via lines. The interface circuits are used to receive signals from the server's memory and send signals to the processors, the signals including computer instructions stored in the memory. When the server processor executes the computer instructions, the server performs the various steps of the natural language-based database operation method shown in the above-described method embodiments.

[0194] The beneficial effects that the readable storage medium provided in some embodiments of this application can achieve can be referred to the beneficial effects in the corresponding natural language-based database operation method provided above, and will not be repeated here.

[0195] It should be noted that in this application, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

[0196] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the apparatus embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0197] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution apparatus, device, or equipment (such as a computer-based device, a processor-included device, or other device that can fetch and execute instructions from, an instruction execution apparatus, device, or equipment).

[0198] For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by or in conjunction with an instruction execution means, apparatus, or device.

[0199] More specific examples of computer-readable media (a non-exhaustive list) include the following: electrical connections having one or more wires (electronic devices), portable computer disks (magnetic devices), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM).

[0200] Furthermore, the computer-readable medium can even be paper or other suitable media on which the program can be printed, because the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in computer memory. It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof.

[0201] In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution device. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc. The embodiments described above are merely specific embodiments of this application and are not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made based on the technical solutions of this application should be included within the scope of protection of this application.

Claims

1. A database operation method based on natural language, characterized in that, include: In response to receiving a query command, retrieve the table structure information of the database; The table structure information is filtered according to the first format to generate table structure metadata; The query command and the table structure metadata are input into the statement generation model to generate a Structured Query Language (SQL) statement. Execute the SQL statement to obtain the statement execution result.

2. The method according to claim 1, characterized in that, The step of responding to a query instruction and obtaining the table structure information of the database includes: In response to receiving a query instruction, a metadata query request for obtaining database table structure information is generated based on the query text used to query the table structure information. Send the metadata query request to the database; In response to receiving feedback data from the database, the table structure information is generated.

3. The method according to claim 1 or 2, characterized in that, The step of filtering the table structure information according to the first format to generate table structure metadata includes: Obtain the first format; the first format includes at least one target field and the arrangement format of the target field; Based on the at least one target field and the arrangement format, the field value corresponding to the target field in the table structure information is converted into the table structure metadata; The table structure metadata is stored in the session variable corresponding to the statement generation model.

4. The method according to claim 3, characterized in that, The step of converting the field value corresponding to the target field in the table structure information into the table structure metadata based on the at least one target field and the arrangement format includes: Parse the table structure information to obtain the field value corresponding to each field in the database; Based on the at least one target field, redundant information in the field value is filtered out; The field values, after filtering out redundant information, are converted into table structure metadata in list format according to the arrangement format.

5. The method according to claim 4, characterized in that, The step of filtering out redundant information in the field values ​​based on the at least one target field includes: The target field value is determined based on the field value corresponding to each field in the database and the target field; the target field value includes the field value corresponding to the field whose field name is the same as the target field; Extract the target field value from the field values.

6. The method according to any one of claims 3 to 5, characterized in that, The method of storing the table structure metadata into the session variable corresponding to the statement generation model further includes: Construct session variables corresponding to the statement generation model; Generate the table structure text corresponding to the table structure metadata; Store the table structure text into the session variable.

7. The method according to any one of claims 3 to 6, characterized in that, The step of inputting the query instruction and the table structure metadata into the statement generation model to generate an SQL statement includes: Obtain the natural language text corresponding to the query command; Based on the natural language text and the session variables, determine the prompt words for the statement generation model; The prompt words are input into the statement generation model to generate SQL statements that conform to the session variables.

8. The method according to claim 7, characterized in that, Based on the natural language text and the session variables, the prompt words for the statement generation model are determined, including: Obtain the prompt word template corresponding to the query command; The prompt word is generated based on the prompt word template, the natural language text, and the session variables.

9. The method according to any one of claims 3 to 8, characterized in that, The step of responding to receiving a query instruction and obtaining the table structure information of the database further includes: Obtain the session variables; When the table structure text has been stored in the session variable, an SQL statement is generated based on the query instruction and the session variable.

10. A computing device, characterized in that, include: Processor and memory; The processor and the memory are coupled together; The memory is used to store program instructions; The processor is used to execute the program instructions to perform the natural language-based database operation method as described in any one of claims 1 to 9.

Images