A data query processing method and device and related equipment

Abstract

This application discloses a data query processing method, apparatus, and related equipment. Based on an input natural language query request, the method retrieves database structure information, marks permission fields within the database structure information, and distinguishes between business fields and permission fields. It then generates business SQL based on the natural language query request and the marked database structure information, without including permission conditions set for the permission fields. The business SQL is parsed to obtain an abstract syntax tree (AST), and the data tables involved, their corresponding table names and aliases, and the positional relationships of the WHERE clauses are determined based on the AST. Applicable permission rules are determined based on the data tables, and permission conditions are generated based on the permission rules and the permission context information corresponding to the current query. Finally, based on the table names, aliases, and WHERE clause positions determined by the AST, the permission conditions are concatenated into the business SQL to obtain the final SQL. This ensures both accurate understanding of business semantics and secure and controllable data permissions.

Description

Technical Field

[0001] This application relates to the field of data processing and query technology, specifically to a data query processing method, apparatus, and related equipment. Background Technology

[0002] As the scale of business data in enterprise information systems continues to grow, users can effectively lower the barrier to data use by querying business data in databases using natural language. Therefore, the technology of generating structured query statements (Text2SQL) based on natural language is widely used in data analysis and information retrieval scenarios. Existing natural language query technologies typically provide the user's query request and database schema information to a large language model, which then understands the query intent and generates the corresponding SQL statement to access the database and obtain the results. In real-world business scenarios, database data usually has strict access control requirements. To meet access control needs, existing technologies typically provide the business query conditions and access control rules to the large language model together, or directly concatenate the SQL string according to preset rules after the model generates the SQL.

[0003] However, the above approach has obvious drawbacks: On the one hand, implementing business and permission isolation at the database structure information level during the business SQL generation stage can easily lead to the coupling of business query logic and permission control logic, increasing the uncontrollability of the generated results of the large language model and the complexity of permission maintenance; on the other hand, when business queries involve multi-table joins, table aliases, or complex subqueries, traditional text processing or regular expression matching methods cannot parse the deep syntax structure of SQL, making it difficult to accurately locate the true positional relationship between table aliases and WHERE clauses, which can easily lead to misaligned permission conditions or syntax errors.

[0004] Therefore, it is necessary to provide a data query processing method that achieves business and permission isolation at the database structure information level during the business SQL generation stage, and accurately parses its syntax structure and positional relationships based on the Abstract Syntax Tree (AST) after generating the business SQL, thereby improving the accuracy and syntax compatibility of collaborative processing of business queries and permission control. Summary of the Invention

[0005] In view of this, embodiments of this application provide a data query processing method, system, and related equipment to at least partially solve the above problems.

[0006] In a first aspect, embodiments of this application provide a data query processing method, including: Obtain the input natural language query request, retrieve the database structure information based on the natural language query request, and mark the permission fields in the database structure information to distinguish between business fields and permission fields; Business SQL is generated based on the natural language query request and the tagged database structure information, wherein the business SQL includes the business query conditions corresponding to the natural language query request, but does not include the permission conditions set for the permission field; The business SQL is parsed to obtain the abstract syntax tree corresponding to the business SQL, and the data tables involved in the business SQL, the table names and aliases of the data tables, and the positional relationship of the WHERE clauses are determined based on the abstract syntax tree. The applicable permission rules are determined based on the data table, and permission conditions are generated based on the permission rules and the permission context information corresponding to the current query. Based on the table name, table alias information, and the positional relationship of the WHERE clause determined by the abstract syntax tree, the permission conditions are concatenated into the business SQL to obtain the final SQL.

[0007] Secondly, based on the data query processing method described in the first aspect of this application, embodiments of this application also provide a data query processing apparatus, including: The structure tagging module is used to obtain the input natural language query request, retrieve database structure information based on the natural language query request, and tag the permission fields in the database structure information to distinguish between business fields and permission fields. The business SQL generation module is used to generate business SQL based on the natural language query request and the tagged database structure information, wherein the business SQL includes the business query conditions corresponding to the natural language query request, but does not include the permission conditions set for the permission field. The syntax parsing module is used to parse the business SQL, obtain the abstract syntax tree corresponding to the business SQL, and determine the data tables involved in the business SQL, the table names and aliases of the data tables, and the positional relationship of the WHERE clauses based on the abstract syntax tree. The permission condition generation module is used to determine the applicable permission rules based on the data table, and generate permission conditions based on the permission rules and the permission context information corresponding to the current query. The permission concatenation module is used to concatenate the permission conditions into the business SQL based on the table name, the table alias information determined by the abstract syntax tree, and the positional relationship of the WHERE clause, to obtain the final SQL.

[0008] Thirdly, embodiments of this application also provide a computer storage medium storing computer-executable instructions, which, when executed, perform any of the data query processing methods described in the first aspect of embodiments of this application.

[0009] Fourthly, embodiments of this application also provide an electronic device, including: a processor, a memory, a communication interface, and a communication bus, wherein the processor, the memory, and the communication interface communicate with each other through the communication bus; the memory is used to store at least one executable instruction, wherein the executable instruction causes the processor to execute any of the data query processing methods described in the first aspect of embodiments of this application.

[0010] This application provides a data query processing method, apparatus, and related equipment. The method distinguishes business fields from permission fields by marking permission fields during the database structure information retrieval stage, and generates business SQL containing only business query conditions and excluding permission conditions. This separates business semantic understanding and data permission control into two independent processing stages. This allows the large language model to focus solely on business semantics when generating SQL, reducing the possibility of confusion between business and permission conditions at the data source. This improves the accuracy of SQL generation and reduces the risk of data leakage caused by missing or bypassed permission conditions. Furthermore, the method performs syntax parsing on the generated business SQL to obtain an abstract syntax tree. Based on the abstract syntax tree, it determines the relevant data tables, table names, table aliases, and the positional relationships of the WHERE clauses. Then, it further analyzes the permission rules and permissions... The permission conditions generated from context information are concatenated to the business SQL, transforming the attachment of permission conditions from textual operations at the string level to deterministic operations at the syntax structure level. Even in scenarios with multiple table joins, table aliases, or complex subqueries, the appropriate position of the permission conditions can be accurately located. This helps reduce misalignment and syntax errors in permission condition attachment and lowers the risk of SQL injection introduced by directly concatenating strings from the large language model. At the same time, permission conditions are dynamically generated from permission rules and permission context information, allowing permission rules to be configured and updated independently of business code and the large language model. This eliminates the need for additional training of the large language model and the additional permission inference task undertaken by the large language model during the business SQL generation stage. It also reduces the maintenance cost of model prompt information caused by changes in permission rules, reducing permission maintenance costs while supporting multiple row-level data permissions such as departments, users, and custom SQL. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings.

[0012] Figure 1 A schematic diagram illustrating the workflow of a data query processing method provided in this application embodiment; Figure 2 A schematic diagram illustrating the architecture and data flow of a data query processing method provided in an embodiment of this application; Figure 3 This application provides a schematic diagram of a process for recalling permission rules and generating permission conditions in an embodiment of the present application. Figure 4 A flowchart illustrating the process of constructing permission conditions based on an abstract syntax tree, provided for an embodiment of this application; Figure 5 This is a schematic diagram of the structure of a data query processing device provided in an embodiment of this application; Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0013] To enable those skilled in the art to better understand the technical solutions in the embodiments of this application, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art should fall within the protection scope of the embodiments of this application.

[0014] It should be understood that the various steps described in the method implementation of this application have a definite technical logical relationship, and the object processed in the later step is generated by the previous step. Without changing the above-mentioned technical logical relationship between the steps, some steps can be implemented separately by different processing modules, or they can be implemented continuously by the same processing module; the method implementation may also include additional steps.

[0015] Example 1 This application provides a data query processing method, such as... Figure 1 As shown, Figure 1 This illustration shows a flowchart of a data query processing method provided in an embodiment of this application. The method can be implemented by, for example... Figure 2 The architecture implementation shown, Figure 2This is a schematic diagram illustrating the architecture and data flow of an exemplary data query processing method provided in an embodiment of this application.

[0016] like Figure 2 As shown, the data query processing system implementing the method described in this application includes at least a structure marking module, a business SQL generation module, a syntax parsing module, a permission condition generation module, and a permission concatenation module. The structure marking module is used to perform schema recall and permission field marking; the business SQL generation module is connected to a large language model and is used to generate pure business SQL without permission conditions; the syntax parsing module is used to generate an abstract syntax tree; the permission condition generation module is connected to a permission rule knowledge base / vector knowledge base and is used to perform permission rule recall and placeholder replacement; the permission concatenation module is used to accurately attach permission conditions based on the abstract syntax tree. In addition, the system may also include a security verification module and a database execution module.

[0017] The data flow is as follows: After the user inputs a natural language query request, the natural language query request is processed sequentially by the structure tagging module, the business SQL generation module, and the syntax parsing module. The parsing result obtained by the syntax parsing module is sent to the permission condition generation module. The permission condition generation module recalls permission rules from the permission rule knowledge base / vector knowledge base and generates permission conditions, and then sends the permission conditions to the permission concatenation module. The permission concatenation module completes the mounting of the permission conditions and outputs the final SQL. After the final SQL is verified by the security verification module, it is sent to the database execution module for execution, and finally presented to the user in the form of the execution result.

[0018] The data query processing method specifically includes the following steps: Step S101: Obtain the input natural language query request, retrieve the database structure information according to the natural language query request, and mark the permission fields in the database structure information to distinguish between business fields and permission fields.

[0019] In this embodiment, the natural language query request refers to a question entered by the user in natural language on the interactive interface, expressing a desire to query business data in the database, such as "query orders in Beijing in 2023 with a value greater than 10,000". The database structure information is data used to describe the structure of data tables and fields in the database, including at least table names, table descriptions, field names, field types, field descriptions, and inter-table relationships. The recall refers to retrieving the structural information of data tables and fields related to the current query from a storage medium (such as vector storage or a metadata database) that stores the full database structure information, based on the semantics of the natural language query request. This provides the necessary and sufficient structural basis for subsequent SQL generation without exceeding the context window of the large language model.

[0020] In the practical application scenario of this embodiment, the fields in the data table are not the same in nature: fields such as order amount, order region, and order time are used to carry business semantics and are the direct landing point of the user's query intent; while fields such as department identifier (dept_id), user identifier (user_id), creator identifier (creator_id), and creating department identifier (create_dept_id) do not carry the business semantics that users care about, but rather carry the data ownership relationship and are the landing point for implementing row-level data permission control. Traditional solutions provide the above two types of fields together to the large language model without distinction. When the large language model reads a field such as dept_id, it often infers and generates related filtering conditions based on its pre-trained prior knowledge, or when the user's question contains expressions such as "orders from our department" which contain both business semantics and ownership semantics, it mixes permission semantics with business semantics, thus polluting the permission logic at the source of SQL generation input.

[0021] Therefore, in this embodiment, this step is limited to applying explicit tags to the permission fields while recalling the database structure information, thereby isolating the business fields from the permission fields at the data source. Specifically, metadata tags can be attached to each field in the vector storage. For example, the metadata tag for a certain field can be represented as: { "column_name": "dept_id", "table_name": "sales_order", "is_permission_column": true, "permission_type": "DEPT", “description”: “Department ID (permission filtering field)” } Here, `column_name` and `table_name` are used to uniquely identify the field; `is_permission_column` is a permission field marker, used to indicate whether the field is a permission field; `permission_type` is the permission type corresponding to the permission field; and `description` is the description information of the permission field. After the above marking, this step outputs the marked database structure information to the subsequent processing flow, which clearly distinguishes three parts: the business field list (`BUSINESS_COLUMNS`), the permission field list (`PERMISSION_COLUMNS`), and the detailed metadata of the permission fields (`PERMISSION_COLUMN_METAS`).

[0022] By implementing the above steps, business semantics and permission semantics are explicitly separated at the database structure information input source before entering the large language model. This provides a definite metadata basis for the subsequent separation of the "business SQL generation" and "permission condition concatenation" stages, helping to reduce the possibility of mutual coupling and interference between the two types of logic at the prompt word level. The business SQL refers to the initial structured query statement generated by the large language model (or natural language to SQL engine) based solely on the user's natural language query request and database structure information. This statement only contains table join and filtering logic to realize the user's business query intent and has not yet injected any constraints related to the current user's data access permissions.

[0023] Step S102: Generate business SQL based on the natural language query request and the tagged database structure information, wherein the business SQL includes the business query conditions corresponding to the natural language query request, but does not include the permission conditions set for the permission field.

[0024] In this embodiment, the business SQL refers to a pure business query statement that expresses only the user's business query intent. The core of this step is to ensure that the large language model assumes only the single responsibility of "business semantic understanding and transcription" at this stage, without assuming any responsibility related to data permissions.

[0025] In the practical application scenario of this embodiment, if the large language model is required to simultaneously consider business conditions and permission conditions in the same inference process of generating SQL, the prompt must simultaneously contain the business description, permission rule description, permission variable values, and the priority statement between the two. The complexity of the prompt will increase dramatically with the number of permission rules. When processing such highly complex prompts, the large language model's attention is diverted by permission constraints, which will reduce the accuracy of understanding the business semantics and may also lead to omissions of permission conditions, incorrect values ​​of permission variables, or misplacement of permission conditions in OR branches, thus resulting in unauthorized access.

[0026] Therefore, in this embodiment, this step is limited to constructing business SQL generation prompt information based on the marking results obtained in step S101. In this prompt information, the responsibility boundaries of the large language model are explicitly declared. For example, the business SQL generation prompt information may include the following indications: [Key] You only need to handle users' business query conditions; you don't need to consider data permissions. [Prohibited] Do not generate WHERE conditions for the following permission-related fields: [dept_id, user_id, creator_id, create_dept_id]; [Reason] Data permissions will be handled uniformly in a subsequent dedicated node, so you do not need to worry about permission issues.

[0027] The list of fields listed in the "Prohibited" section above is derived from the list of permission fields output in step S101. Therefore, the declaration of this responsibility boundary is dynamically generated based on the recall results, rather than being hard-coded into the prompt word template. After inputting the business SQL prompt information into the large language model, the business SQL output by the large language model is, for example, as follows: SELECT * FROM sales_order WHERE region = 'Beijing' AND amount>10000 ANDyear = 2023.

[0028] It can be seen that the above business SQL only contains business query conditions transcribed from natural language query requests, and does not contain any filtering conditions for permission fields such as dept_id.

[0029] By implementing the above steps, on the one hand, the complexity of prompt words is significantly reduced, allowing the reasoning power of the large language model to focus on the accurate understanding and transcription of business semantics, thereby improving the accuracy of SQL generation; on the other hand, since the large language model is explicitly excluded from the responsibility of permission processing at this stage, the correctness of permission conditions no longer depends on the stability of the output of the large language model, thereby reducing the degree to which data permission control is affected by the uncertainty of the output of the generative model.

[0030] Step S103: Perform syntax parsing on the business SQL to obtain the abstract syntax tree corresponding to the business SQL, and determine the data tables involved in the business SQL, the table names and aliases of the data tables, and the positional relationship of the WHERE clauses based on the abstract syntax tree.

[0031] In this embodiment, the table alias information refers to a temporary abbreviation or alternative name assigned to a data table in an SQL statement (e.g., 'e' in 'SELECT * FROM employee AS e'). In complex business SQL, the same data table may be self-joined or joined multiple times. Extracting and binding the table alias information ensures that the specific table instance is accurately located when subsequent permission conditions are attached, avoiding misalignment of permission constraints or syntax conflicts. The abstract syntax tree (AST) refers to a tree-structured representation of the linear character sequence of an SQL statement, converted according to the grammatical rules of the SQL language, where each node corresponds to a grammatical component in the SQL statement. This step can be implemented using an SQL syntax parser; the SQL syntax parser is a parsing component that can convert an SQL statement into an abstract syntax tree according to the SQL syntax rules. JSqlParser is one example implementation, and this application does not limit the specific type of syntax parsing component used.

[0032] In the practical application scenarios of this embodiment, if regular expression matching or string search is used to locate the WHERE clause and concatenate the text, it may work barely in simple single-table queries, but it is very likely to fail in real-world enterprise-level query scenarios. For example, when the business SQL is a multi-table join query (such as SELECT…FROM sales_order o JOIN customer c ON o.customer_id = c.id WHERE …), the string level cannot determine which table a WHERE condition constrains, nor can it determine what alias prefix the permission field should be limited by. When the business SQL contains subqueries, multiple WHERE keywords will appear in the statement, and string search cannot distinguish whether they belong to the main query or a certain level of subquery. When the string constant in the SQL text happens to contain the word "where", regular expression matching will also produce false hits. All of the above situations will cause the permission conditions to be attached to the wrong position, which may result in SQL syntax errors causing query failure, or even cause the permission conditions to lose their constraint effect on the target table, resulting in privilege escalation.

[0033] Therefore, this embodiment limits this step to first elevating the business SQL to an abstract syntax tree, and then performing deterministic positioning on the tree structure. Specifically, the parser parses the business SQL into a tree structure with the query statement node as the root and the query body, SELECT list, FROM items, JOIN items, WHERE expressions, etc., as child nodes; then it traverses the FROM item nodes and JOIN item nodes in the abstract syntax tree, extracting the table name and its alias information carried by each data table node; at the same time, it locates the position of the WHERE expression node under each query body node, determines whether the WHERE clause exists, which level of the query body it belongs to, and the combination structure of its internal conditional expressions, thereby obtaining the positional relationship of the WHERE clause.

[0034] By implementing the above steps, the subsequent permission condition mounting operation is transformed from unreliable string text operation into a deterministic syntax structure operation, making the method described in this application naturally compatible with complex SQL forms such as multi-table joins, table aliases, and nested subqueries, providing a structured location basis for the accurate and secure mounting of permission conditions.

[0035] Step S104: Determine the applicable permission rules based on the data table, and generate permission conditions based on the permission rules and the permission context information corresponding to the current query.

[0036] In this embodiment, the permission rule refers to a pre-configured rule record describing under what subject conditions a data table can be accessed; the permission context information refers to context data used to determine the data access scope of the current query subject, which includes at least one of the current query subject's user identifier, department identifier, department set, and other information that can be used to determine the data access scope. The processing flow for this step can be found in [link to relevant documentation]. Figure 3 , Figure 3 This is a schematic diagram illustrating a process for recalling permission rules and generating permission conditions, provided in an embodiment of this application.

[0037] In this embodiment, the permission rules coexist in two storage formats: the permission rule knowledge base stores structured permission rule records for precise matching based on identifiers; the vector knowledge base stores vector representations obtained by vectorizing the description information and other content of the permission rules for vector retrieval based on semantic similarity. The permission rule knowledge base and the vector knowledge base can be stored separately or implemented in the same storage system with different index formats; this application does not limit this.

[0038] Specifically, permission rules can be stored in a pre-defined permission rule knowledge base. For example, a permission rule can be represented as: { “agent_id”: 1, "table_name": "sales_order", "permission_type": "DEPT", “description”: “Sales orders can only view data from this department and its sub-departments”. "permission_expr": "dept_id IN ({dept_ids})", "status": 1 } Where agent_id is the agent identifier, table_name is the data table constrained by the rule, permission_type is the permission type, description is the natural language description of the rule, permission_expr is the permission expression with variable placeholders, and status is the enabled status of the rule.

[0039] It should be noted that the "intelligent agent" referred to in this application embodiment refers to a processing entity used to carry out specific business query capabilities. It can correspond to an application, service, model call chain, or business function used to perform natural language query processing. The intelligent agent identifier is used to uniquely identify the corresponding intelligent agent, that is, to uniquely identify the specific large language model instance or AI business assistant currently processing the user's natural language request. For example, in an enterprise system, a 'material procurement intelligent agent' and an 'accounting management intelligent agent' may be deployed simultaneously. By identifying the intelligent agent identifier, the exclusive permission rule knowledge base can be loaded and accurately matched for intelligent agents in different business domains.

[0040] It should also be noted that the permission expression and permission condition mentioned in this application embodiment are two objects at different stages: the permission expression is an expression at the permission rule template stage, which contains variable placeholders that have not yet been valued, such as dept_id IN ({dept_ids}); the permission condition is a condition that can directly participate in SQL calculations after substituting the specific values ​​in the permission context information into the permission expression, such as dept_id IN (2, 3). Furthermore, the permission type of the permission field describes the permission attribute carried by the field, and the permission type of the permission rule describes the permission control method adopted by the permission rule. The two can be related, but are not limited to having the same data structure or the same values. Based on the data table extracted in step S103 (such as ["sales_order"]), the permission rule applicable to this query can be determined from the permission rule knowledge base.

[0041] After determining the applicable permission rules, the permission context information corresponding to the current query is further obtained. This permission context information may include the user identifier of the current query initiator, the department identifier to which they belong, or the department set consisting of the current department and its sub-departments obtained through recursive expansion of the organizational structure tree. Subsequently, the variable placeholders in the permission expression are replaced using the obtained permission context information. For example, if the permission expression is `dept_id IN({dept_ids})`, and the department set in the current permission context information is `{2, 3}`, then the placeholder `{dept_ids}` is replaced with "2, 3", resulting in the final permission condition: `dept_id IN (2, 3)`.

[0042] In the practical application scenario of this embodiment, the method of generating permission conditions by "rule template plus runtime variable replacement" is of great significance. On the one hand, the permission rules only store expression templates that are independent of specific individuals, and the same rule can serve all users, so the number of rules does not increase with the size of the organization. On the other hand, the actual value of the permission is dynamically injected by the permission context information only when a query occurs. Therefore, when personnel are transferred to different departments or the organizational structure is adjusted, there is no need to modify any permission rules, and the visible data range automatically changes with the change of permission context information.

[0043] like Figure 3 As shown, the specific processing flow for permission rule recall and permission condition generation in this step includes: Step S301: Obtain the data tables involved in the business SQL determined by the abstract syntax tree.

[0044] Step S302: Perform precise matching between the agent identifier and the data table on the knowledge base of permission rules, and / or perform vector recall based on semantic similarity to determine the applicable permission rules.

[0045] Step S303: Obtain the user identifier, department identifier, or department set corresponding to the current query as the permission context information.

[0046] Step S304: Determine whether the permission context information is missing or empty; if the determination result is yes, then proceed to step S305; if the determination result is no, then proceed to step S306.

[0047] Step S305: Generate a logical constant false condition expression as a blocking permission condition, and then execute step S309.

[0048] Step S306: Replace the variable placeholders in the permission expression according to the permission context information to obtain the sub-permission conditions.

[0049] Step S307: Determine whether multiple permission rules for the same data table are matched; if the determination result is yes, proceed to step S308; if the determination result is no, proceed to step S309.

[0050] Step S308: Combine multiple sub-permission conditions into an aggregate permission condition using the logical OR operator, and then execute step S309.

[0051] Step S309: Output the final permission conditions applied to the business SQL.

[0052] It should be noted that the branches formed by steps S304 and S305, as well as the branches formed by steps S307 and S308, are optional steps in this embodiment. Under the normal situation where the permission context information is complete and only a single permission rule is matched for the same data table, the generation of permission conditions can be completed through steps S301 to S303, S306, and S309. For the specific implementation methods and technical effects of the above two branches, please refer to the description in the corresponding paragraphs below.

[0053] By implementing the above steps, the permission rules exist completely independently of the business code and the large language model. They can be configured and dynamically updated by administrators in a visual manner without modifying the code or training the large language model. This supports complex row-level data permission scenarios such as "only view data of this department and its sub-departments" and "only view records created by the user".

[0054] Step S105: Based on the table name, table alias information, and the positional relationship of the WHERE clause determined by the abstract syntax tree, the permission conditions are concatenated into the business SQL to obtain the final SQL.

[0055] In this embodiment, based on the structured location data obtained in step S103, the permission conditions generated in step S104 are written to the corresponding positions in the abstract syntax tree. Then, the abstract syntax tree is used to generate the SQL text in reverse, resulting in the final SQL that contains both business query conditions and permission conditions. The processing flow for this step can be found in [link to relevant documentation]. Figure 4 , Figure 4 This is a flowchart illustrating a permission condition concatenation based on an abstract syntax tree, provided as an embodiment of this application.

[0056] Specifically, first, a mapping relationship is established between the table name and the table alias extracted from the abstract syntax tree; then, based on the data table constrained by the permission condition, the target table corresponding to the permission condition in the current business SQL is determined through this mapping relationship, and when the table alias is used in the data table, the permission fields in the permission condition are restricted by the table alias to avoid ambiguity in field ownership in multi-table join scenarios; subsequently, based on the positional relationship of the WHERE clause, the permission condition is concatenated to the WHERE condition corresponding to the target table using the logical AND operator.

[0057] For example, the business SQL is: SELECT * FROM sales_order WHERE region = 'Beijing' AND amount>10000 ANDyear = 2023 The permission condition is: dept_id IN (2, 3) The final SQL obtained after concatenation is: SELECT * FROM sales_order WHERE (region = 'Beijing' AND amount>10000 ANDyear = 2023) AND (dept_id IN (2, 3)) It should be noted that during the above concatenation, the original business condition and the newly added permission condition in the WHERE clause are each enclosed in parentheses before being connected by AND. This processing has substantial security significance in this embodiment: if the business condition contains the logical OR operator (e.g., region = 'Beijing' OR amount>10000), and the entire business condition is not enclosed in parentheses during concatenation, then according to the rule that AND operation has higher priority than OR operation in SQL, the concatenated permission condition will only constrain one branch of the OR, and the data in the other branch will bypass the permission condition and be returned, thus resulting in unauthorized data leakage. This embodiment, by enclosing the two conditions with parentheses at the abstract syntax tree level, enables the permission condition to impose constraints on the entire query result set.

[0058] like Figure 4 As shown, the specific processing flow for constructing permission conditions based on the abstract syntax tree described in this step may include: Step S401: Recursively traverse the abstract syntax tree corresponding to the business SQL, identify the query nodes at each level and the association type corresponding to each query node; wherein, the query node includes single-level query nodes, sub-query nodes and join query nodes.

[0059] Step S402: Establish the mapping relationship between the table name and the table alias of the data table, and determine the target table corresponding to the permission conditions.

[0060] Step S403: Add the table alias qualifying prefix before the permission field in the permission conditions.

[0061] Step S404: Determine whether the relationship type is an outer join; if the determination result is yes, proceed to step S405; if the determination result is no, proceed to step S406.

[0062] Step S405: Concatenate the permission conditions of the attached table alias prefix to the ON condition of the connection query node, and then execute step S409.

[0063] Step S406: Determine whether the query body to which the target table belongs contains a WHERE clause; if the determination result is yes, then proceed to step S407; if the determination result is no, then proceed to step S408.

[0064] Step S407: Concatenate the permission conditions into the WHERE condition using the logical AND operator, and then execute step S409.

[0065] Step S408: Create a WHERE clause in the query body and use the permission condition as its WHERE condition.

[0066] Step S409: Generate the final SQL from the abstract syntax tree.

[0067] It should be noted that the recursive traversal and association type identification in step S401, the table alias prefix supplementation in step S403, and the branches formed by steps S404 and S405 are all optional steps set by this embodiment for multi-table association statements or nested subquery statements. For their specific implementation methods and technical effects, please refer to the description in the corresponding paragraphs below. In the conventional case where the business SQL is a single-table query without join semantics, the concatenation of permission conditions can be completed only through steps S402, S406 to S409.

[0068] Through the implementation of the above steps, the process of concatenating permission conditions is completed entirely by deterministic syntax structure operations, without relying on the large language model to perform any form of string concatenation. This reduces the risk of SQL injection and the possibility of syntax errors introduced by directly concatenating strings using a generative model, and helps to prevent permission constraints from being bypassed in complex SQL forms.

[0069] Optionally, in one implementation of this embodiment, marking the permission fields in the database structure information includes: setting permission field markers, permission types, and permission field descriptions for the fields in the database structure information; and dividing the fields in the database structure information into a business field list, a permission field list, and detailed metadata of the permission fields according to the permission field markers.

[0070] In the practical application scenario of this embodiment, simply using a Boolean value to indicate whether a field is a permission field is insufficient to support subsequent processing. This is because subsequent permission rule retrieval also requires knowledge of the permission semantic category corresponding to the field, and declaring the prohibited scope to the large language model requires a directly enumerable list of field names. Therefore, this embodiment limits this step to writing three items simultaneously during the marking process: the permission field marker is used to provide a binary judgment result; the permission type is used to indicate whether the field carries departmental, user, or custom affiliation semantics; and the permission field description information is used to provide semantically matching natural language text during vector retrieval. After completing the above marking, a structured reorganization is further performed on the retrieval results based on the permission field marker, outputting three non-overlapping data structures: a business field list, a permission field list, and detailed permission field metadata. These are then written into the workflow state and passed to downstream nodes. This allows downstream business SQL generation nodes to directly reference the permission field list to construct a prohibited list, and permission rule retrieval nodes to directly reference the detailed permission field metadata to locate rules. Data is transferred between nodes using structured states rather than natural language text, improving the determinism and maintainability of the process execution.

[0071] Optionally, in one implementation of this embodiment, generating business SQL based on the natural language query request and the tagged database structure information includes: determining business query conditions based on the natural language query request; generating business SQL generation prompt information based on the business query conditions and the tagged database structure information, and inputting the business SQL generation prompt information into a large language model; instructing the large language model to process the business query conditions in the business SQL generation prompt information, and restricting the large language model to generate permission conditions set for the permission field based on the tag of the permission field, so as to obtain the business SQL.

[0072] In the practical application scenario of this embodiment, if the behavioral constraints on the large language model are only expressed in a general statement such as "don't consider permissions," the model often struggles to determine which fields fall under the permission category during inference and may still generate its own filtering conditions for fields such as `dept_id`. Therefore, this embodiment limits the granularity of the constraints to specific fields: the list of permission fields output in step S101 is directly expanded into a list of prohibited fields in the prompt message. This presents the model with a definite set of field names that can be compared item by item, rather than abstract concepts that it needs to infer on its own. At the same time, the prompt message also provides an explanation of the reason for the prohibited constraint, namely that data permissions will be handled uniformly by a subsequent dedicated node, thereby preventing the model from arbitrarily adding filtering conditions out of concern for missing permissions. Through the above method, the business SQL output by the large language model remains clean in terms of permission fields, providing an undisturbed syntactic space for the exclusive writing of permission conditions in subsequent stages, and eliminating the possibility of permission conditions being repeatedly concatenated or overwritten by incorrect conditions generated by the model.

[0073] Optionally, in one implementation of this embodiment, determining the applicable permission rule based on the data table includes: obtaining the agent identifier corresponding to the natural language query request; performing precise matching on a preset permission rule knowledge base based on the agent identifier and the data table to determine the applicable permission rule; and / or performing vector recall based on the semantic similarity between query-related information and permission rules in the permission rule knowledge base to determine the applicable permission rule.

[0074] In the practical application scenarios of this embodiment, there are two different requirements for the recall of permission rules: For data tables where rules have been explicitly configured by administrators, the recall process should be deterministic and efficient, allowing no ambiguity; however, for scenarios with a large number of rules or where rules express business semantics in natural language descriptions, a certain semantic generalization capability is required to recall semantically relevant rules even without precise rule configuration. Therefore, this embodiment limits the configuration of two recall strategies that can be used individually or in combination. The first is the precise matching strategy, which uses the agent identifier corresponding to the current natural language query request and the data table name extracted in step S103 as a composite search key to directly retrieve enabled rule records in the permission rule knowledge base. This strategy provides unique and deterministic search results with extremely low response latency. The second is the vector recall strategy, which vectorizes query-related information (such as the natural language query request itself, the table description of the involved data table, or the description information of permission fields), calculates semantic similarity with the vector representations of each permission rule in the permission rule knowledge base, and recalls relevant permission rules in descending order of similarity. When the two strategies are used in combination, exact matching can be performed first, and vector recall can be used as a fallback if the exact match fails. In this way, the recall of permission rules maintains determinism and low latency in normal scenarios, and also has semantic-level completion capabilities in scenarios with incomplete rule configuration or ambiguous semantic expression. Moreover, the rule base becomes more and more perfect as it is used.

[0075] Optionally, in one implementation of this embodiment, the method further includes: in response to a configuration operation for the permission rule knowledge base, obtaining an agent identifier, a data table identifier, a permission type, and a permission expression with variable placeholders, generating permission rules and storing them in the permission rule knowledge base; vectorizing the permission rules and synchronizing them to a vector knowledge base for use in the vector retrieval; and synchronously updating the corresponding permission rules in the vector knowledge base when the permission rules in the permission rule knowledge base are updated.

[0076] In the practical application scenario of this embodiment, an enterprise's data permission policy is not static; it evolves frequently due to organizational restructuring, additions or removals of business lines, or changes in compliance requirements. If the permission logic is hard-coded into program code or SQL templates, each policy change will trigger a round of code modification, testing, and release processes, resulting in high maintenance costs and lengthy change cycles. Therefore, this step in this embodiment is limited to providing a configuration entry point for permission rules that is independent of business code. Specifically, administrators can complete rule configuration in a visual manner in the system management backend, sequentially selecting the agent to which the rule belongs, selecting the data table to be controlled, setting the permission type (department, user, or custom), and filling in permission expressions with variable placeholders (e.g., {user_id}, {dept_id}, {dept_ids}); the system then generates a structured permission rule and writes it into the permission rule knowledge base. Meanwhile, to ensure that newly configured rules can be retrieved by the vector recall strategy, the text content, including the rule's description, is vectorized using an embedded model and synchronously written to the vector knowledge base. When the content of an existing rule is modified or its activation status is changed, the corresponding vector representation in the vector knowledge base is simultaneously refreshed to ensure consistency between the two storage systems. Through this method, adjusting the data permission policy is downgraded from a single code change to a single configuration operation. Permission rules take effect immediately without requiring a service restart or any retraining or fine-tuning of the large language model, significantly reducing the permission maintenance costs during long-term system operation.

[0077] Optionally, in one implementation of this embodiment, the permission rule includes a permission type and a permission expression with variable placeholders; generating permission conditions based on the permission rule and the permission context information corresponding to the current query includes: obtaining a user identifier, department identifier, or department set corresponding to the current query as the permission context information; replacing the variable placeholders in the permission expression according to the permission context information to obtain the permission conditions; wherein, the permission type includes at least one of department permissions, user permissions, and custom SQL permissions.

[0078] In the practical application scenarios of this embodiment, enterprise-level data permissions manifest in various forms. These include "visible to this department and its sub-departments" based on organizational affiliation, "visible only to the record creator" based on the record creator, and complex conditions such as "visible only to orders in East China with amounts below the approval threshold," which require specific business semantics. To cover these diverse forms, this step in this embodiment limits the permission types in the permission rules to at least three types: Departmental Permission Type (DEPT) is used for filtering based on department affiliation, and its permission expression typically references the placeholders {dept_id} or {dept_ids}; User Permission Type (USER) is used for filtering based on user affiliation, and its permission expression typically references the placeholder {user_id}; and Custom SQL Permission Type (CUSTOM) allows administrators to directly write any legal SQL condition fragment as the permission expression to express the aforementioned complex semantics. When generating permission conditions, the system first retrieves the user identifier of the initiating entity and its department identifier, or the set of departments obtained recursively from the current query session context, as permission context information. Then, it replaces the placeholder variables with the same name in the permission expression one by one with the corresponding values ​​from this permission context information. After the replacement is complete, the permission conditions that can directly participate in SQL calculations are obtained. This method allows the same set of rule templates, combined with runtime-injected permission context information, to serve all users. The number of rules does not increase with the size of the user base, and the visible data range automatically changes with the update of the permission context information after personnel or department changes, without requiring any modification to the rules themselves.

[0079] Optionally, in one implementation of this embodiment, the step of concatenating the permission conditions to the business SQL based on the table name, the table alias information, and the positional relationship of the WHERE clause determined by the abstract syntax tree includes: establishing a mapping relationship between the table name and the table alias of the data table; determining the target table corresponding to the permission conditions based on the mapping relationship between the table name and the table alias; and concatenating the permission conditions to the WHERE condition corresponding to the target table using a logical AND operator based on the positional relationship of the WHERE clause determined by the abstract syntax tree.

[0080] In the practical application scenario of this embodiment, permission rules are configured and recalled using table names as keys. However, business SQL often uses aliases to refer to data tables (e.g., FROM sales_order_o), resulting in a namespace mismatch. If a mapping relationship is not established and permission fields are directly limited by table names, the generated permission conditions will cause syntax errors in SQL using aliases because the table names are not bound. If no limiting prefix is ​​added, ambiguity regarding field attribution will arise when multiple tables are joined and different tables have permission fields with the same name. Therefore, this embodiment limits this step to traversing all data table nodes in the abstract syntax tree before concatenation, establishing a mapping relationship between table names and table aliases; then, using the table names recorded in the permission rules as an index to query this mapping relationship, determining the target table corresponding to the permission condition in the current business SQL and its actual referent name in the SQL; then, based on the WHERE clause position relationship determined in step S103, locating the WHERE expression node of the query body to which the target table belongs, and using the logical AND operator to combine the permission condition expression with the original condition expression into a new WHERE expression node and writing it back to the abstract syntax tree. Through the above method, the target object and position of the permission condition are uniquely determined at the syntax level, effectively reducing syntax errors in alias scenarios and ambiguity in multi-table scenarios. It should be noted that the processing method of concatenating permission conditions to the corresponding WHERE conditions of the target table described in this paragraph is applicable to scenarios where data tables are associated using an inner join or where there is no join semantics; when data tables are associated using an outer join, the mounting position of the permission condition can be further differentiated according to the join relationship type, and the specific implementation method is described later.

[0081] Optionally, in one implementation of this embodiment, the step of concatenating the permission conditions to the WHERE condition corresponding to the target table using a logical AND operator based on the WHERE clause positional relationship determined by the abstract syntax tree includes at least one of the following: when the business SQL involves multiple data tables, determining the permission rules applicable to each data table and generating corresponding permission conditions, and concatenating each permission condition to the WHERE condition of the corresponding target table according to the mapping relationship; when the business SQL contains a subquery, determining the positional relationship of the WHERE clause corresponding to the subquery according to the abstract syntax tree, and concatenating the permission conditions corresponding to the data tables involved in the subquery to the WHERE condition of the subquery; when the WHERE clause corresponding to the target table does not exist, creating a WHERE clause in the query body to which the target table belongs in the abstract syntax tree, and using the permission conditions as the WHERE condition of the created WHERE clause.

[0082] In the practical application scenarios of this embodiment, the syntax of business SQL is not always the simplest form of "single table with WHERE clause". The permission concatenation mechanism must cover various boundary situations, otherwise, permission omissions will occur, forming an unauthorized access channel. Therefore, this embodiment limits this step to providing specific processing methods for three typical situations. The first is the multi-table join situation: when the FROM item and the join item in the abstract syntax tree contain multiple data tables, the applicable rules are retrieved from the permission rule knowledge base for each table by its table name, and the respective permission conditions are generated. Then, according to the mapping relationship between table name and table alias, each permission condition is concatenated to the WHERE condition of its target table, so that each controlled table in the join query obtains independent and complete permission constraints, avoiding data leakage through the join path caused by "the main table is controlled but the join table is not controlled". Secondly, in the subquery scenario: each subquery level in the abstract syntax tree corresponds to an independent query body node. During traversal, the data tables involved in each query body are identified, and its own WHERE expression node is located. The permission conditions corresponding to the data tables at that level are concatenated into the WHERE condition of that level, thus allowing permission constraints to sink synchronously with the query nesting level, avoiding the situation where inner subqueries complete data aggregation prematurely outside of permissions by only attaching permission conditions at the outermost level. Thirdly, in the case without a WHERE clause: when there is no WHERE expression node in the query body of the target table, the condition combination operation is not performed. Instead, a new WHERE expression node is created in the query body, and the permission conditions are written as the condition expression of this node. This ensures that full table queries such as "SELECT * FROM sales_order" without any business filtering conditions are also subject to permission constraints. Through the above methods, the attachment of permission conditions can cover all kinds of complex SQL forms, reducing the possibility of permission blind spots due to special syntax forms. It should be noted that the method of appending the permission conditions to the WHERE condition of the target table in the first type of multi-table join scenario mentioned above is applicable to scenarios where the data tables are joined by an inner join or where there is no join semantics. When the data tables are joined by an outer join, the attachment position of the permission conditions can be further differentiated according to the type of join relationship. The specific implementation method is described later.

[0083] Optionally, in one implementation of this embodiment, when the business SQL contains multi-table join statements or nested subquery statements, concatenating the permission conditions to the business SQL includes: recursively traversing the abstract syntax tree (AST) corresponding to the business SQL to identify query nodes at each level and the join relationship types corresponding to each query node; wherein, the query nodes include single-level query nodes, subquery nodes, and join query nodes; extracting the table alias corresponding to the target data table in each query node, and adding the table alias prefix to the permission field in the permission conditions; when the join relationship type is an outer join, concatenating the permission conditions with the table alias prefix to the ON condition of the join query node to maintain the join query semantics; when the join relationship type is an inner join or a subquery exists, concatenating the permission conditions with the table alias prefix to the WHERE condition of the corresponding subquery node or main query node.

[0084] In more complex enterprise-level reporting scenarios, business SQL often involves multi-table joins (such as LEFT JOIN, RIGHT JOIN, INNER JOIN) or nested subqueries. In this embodiment, the syntax parsing module uses a recursive traversal mechanism to identify PlainSelect (single-level query), SubSelect (subquery), and Join (join query) nodes when parsing the Abstract Syntax Tree (AST), thereby achieving scope isolation.

[0085] For each independent query scope, extract the table name and table alias. For example, when the business SQL is SELECT * FROM sales_order s LEFT JOIN department d ON s.dept_id = d.id, extract the alias of sales_order as s, and automatically rewrite the recall permission condition dept_id IN ({dept_ids}) as s.dept_id IN ({dept_ids}).

[0086] Crucially, for outer joins (such as LEFT JOIN), directly appending the permission conditions of the secondary table to the WHERE clause will force the outer join to degenerate into an inner join, resulting in the loss of unmatched data from the primary table. This is because, during the join phase, the outer join fills rows in the primary table that do not match records from the secondary table with null values. However, the WHERE clause is evaluated after the join result is generated. The permission conditions for the secondary table fields will not be met when encountering these null rows, causing these primary table rows that should have been retained to be filtered out entirely, resulting in an unexpected contraction of the query results. Therefore, in this embodiment, after identifying the outer join type, the permission concatenation module accurately appends the permission conditions with the attached table alias prefix to the ON condition of the Join node; while for inner joins or subqueries, they are appended to the WHERE node of the corresponding scope.

[0087] Furthermore, in the outer join scenario, the permission conditions of the primary table and the secondary table can be handled differently: since the rows of the primary table will not be filled with null values ​​due to the join, the permission conditions corresponding to the primary table can still be appended to the WHERE node of the query scope, while only the permission conditions corresponding to the secondary table are appended to the ON condition of the Join node. Thus, while maintaining the semantics of the outer join, the permission constraints of the primary table participate in the convergence of the result set before the join operation.

[0088] This approach not only avoids field ambiguity errors caused by multiple tables having the same name (such as dept_id), but also ensures the integrity of join query semantics and the accuracy of data isolation under complex SQL structures.

[0089] Optionally, in one implementation of this embodiment, generating permission conditions based on the permission rules and the permission context information corresponding to the current query further includes: when the current query matches multiple permission rules for the same data table, constructing multiple sub-permission conditions based on the permission types corresponding to the multiple permission rules, and combining the multiple sub-permission conditions into an aggregate permission condition using the logical OR operator; and generating the final permission condition acting on the business SQL based on the aggregate permission condition.

[0090] In the practical application scenario of this embodiment, the same query initiator often possesses multiple authorized identities for the same data table. For example, a salesperson might be authorized to view all orders in the East China Sales Department according to departmental permission rules, and also authorized to view several cross-regional orders according to user permission rules. In this case, both DEPT and USER permission rules will be recalled for the sales_order table. If the conditions generated by multiple rules are concatenated using the logical AND operator, the semantics will degenerate into "both belongs to this department and was created by the individual," and the actual visible scope will be narrower than the scope authorized by any single rule alone. This results in data that should be visible being incorrectly hidden, leading to a phenomenon of authorization contraction. Therefore, in this embodiment, this step is limited to detecting multiple permission rules recalled for the same data table. First, placeholders are replaced according to the permission type of each rule to obtain multiple independent sub-permission conditions (e.g., dept_id IN (2, 3) and creator_id = 1001). Then, the above multiple sub-permission conditions are combined into an aggregated permission condition using the logical OR operator (e.g., (dept_id IN (2, 3) OR creator_id = 1001)). This aggregated permission condition is then enclosed in parentheses and used as the final permission condition in subsequent AND concatenation with business conditions. In this way, multiple authorized identities are semantically correctly expressed as the union of visible ranges rather than the intersection. This conforms to the common semantics of "multiple identities taking the union" in enterprise data authorization. Furthermore, because the aggregated permission condition is enclosed in parentheses, it will not interfere with the operation priority of business conditions. Thus, while expanding the authorization expression capability, the strictness of permission constraints is maintained.

[0091] Optionally, in one implementation of this embodiment, generating permission conditions based on the permission rules and the permission context information corresponding to the current query further includes: when it is detected that the permission context information corresponding to the current query is missing or empty, generating a logical constant false condition expression as a blocking permission condition to block data output when the current query does not obtain a valid permission context; and generating a final permission condition acting on the business SQL based on the blocking permission condition.

[0092] In the practical application scenario of this embodiment, the permission context information comes from the session identity of the current query. However, in abnormal situations such as expired session tokens, temporary unavailability of the identity service, asynchronous tasks not carrying the caller's identity, or requests entering through unauthenticated interfaces, the permission context information may be missing or have empty values. If this is not handled specifically, the variable placeholders in the permission expression will be replaced with empty values, causing the permission condition to degenerate into a tautology expression or even be skipped entirely. Ultimately, the SQL will degenerate into a full query statement without any permission constraints, forming a typical "failure equals openness" defect. The harm lies in the fact that the moment of failure is precisely the moment with the highest risk of data leakage. Therefore, in this embodiment, this step is limited to performing a validity check on the permission context information before performing placeholder replacement. Once a missing or empty context is detected, the placeholder replacement is no longer attempted. Instead, a logically always false conditional expression (e.g., 1 = 0) is directly constructed as a blocking permission condition (a conditional expression in SQL syntax whose result is always false, such as 1 = 0. When the system detects abnormal permission information or cannot determine user permissions, by attaching this condition to the target table, the return of data can be directly blocked at the database execution engine level, ensuring that the query result is an empty set, thereby achieving defensive data security isolation). After this blocking permission condition is concatenated with the business condition using AND, the final SQL will return an empty result set when executed in the database, thus blocking data output when the current query has not obtained a valid permission context. By means of the above method, the default behavior of the method described in this embodiment when the permission context is abnormal is changed from "open" to "deny", that is, it follows the security default principle of failure to close. Here, failure to close means that when a valid permission context cannot be obtained, the query without permission constraints will not continue to be executed, but a blocking permission condition that makes the query result empty will be generated. At the same time, since the blocking is completed at the database layer in the form of a valid SQL condition, the statement itself can still be executed normally and return a well-structured empty result set. The upper-layer business process will not be interrupted due to the exception, thus taking into account both security and system availability.

[0093] Optionally, in one implementation of this embodiment, after obtaining the final SQL, the method further includes performing security verification on the final SQL: verifying whether the final SQL is a SELECT statement; detecting whether the final SQL contains preset dangerous keywords; verifying whether the permission conditions are concatenated into the business SQL according to a preset concatenation relationship; and outputting the final SQL when the security verification passes.

[0094] In the practical application scenario of this embodiment, although the method described in this application has separated the process of concatenating permission conditions from the large language model, the business SQL itself is still generated by the large language model, and misleading instructions may be embedded in the natural language query request input by the user. Therefore, it is still necessary to set up an exit checkpoint independent of the generation link before the final SQL is delivered for execution. To this end, this step in this embodiment limits the verification of the final SQL execution to three dimensions. The first dimension is statement type verification, that is, parsing the statement type of the final SQL and confirming that it is a SELECT query statement, thereby rejecting any write-type or structure-modification-type statements from entering the execution stage. The second dimension is dangerous keyword detection, that is, comparing the final SQL with a preset set of dangerous keywords (such as DROP, DELETE, UPDATE, INSERT, TRUNCATE, GRANT, etc.), and once a match is found, the verification is determined to fail. Dimension three involves verifying the integrity of the permission concatenation. This means re-parsed the final SQL and checking whether it truly contains the generated permission conditions and whether these conditions are properly concatenated according to the preset relationship (i.e., connected to the business conditions using logical AND operators and located in the WHERE condition of the query body of the target table). This prevents permission conditions from being lost or tampered with during transmission due to anomalies. The final SQL is only output when all three dimensions of verification pass; if any dimension fails, the output is rejected and the corresponding alarm information is recorded. By implementing these steps, a security fallback independent of the generation process is added to the entire processing chain, ensuring that even if unexpected anomalies occur in the preceding stages, non-compliant SQL cannot reach the database execution stage.

[0095] Optionally, in one implementation of this embodiment, after obtaining the final SQL, the method further includes: transmitting the final SQL to a database execution module to obtain query results, and returning the query results to the user; wherein the final SQL includes the business query conditions and the permission conditions, and the database executes the query based on the final SQL so that the business query conditions and the permission conditions together serve as query filtering conditions.

[0096] In the practical application scenario of this embodiment, the execution location of permission filtering directly determines the security boundary and performance of the system. If a post-filtering method is adopted, where the database first returns all data and then the application layer filters out data one by one according to permissions, not only will duplicates of data that the user does not have permission to access appear in network transmission and memory, expanding the leakage surface, but it will also bring significant transmission and computational overhead when the basic data volume is large, and distort the results of aggregation operations such as COUNT and SUM. Therefore, this embodiment limits this step to sending the final SQL, which has been concatenated and passed security verification, to the database execution module as a whole, so that the business query conditions and permission conditions are evaluated uniformly as a single WHERE condition within the database engine, and jointly participate in the generation of the query plan and the selection of indexes. Therefore, business query conditions and permission conditions participate in query processing as unified query conditions on the database side, avoiding the need to first retrieve unauthorized data and then perform post-filtering at the application layer. This helps reduce the possibility of unauthorized data leaving the database boundary. Simultaneously, since permission conditions are typically based on indexed fields such as `dept_id` and `creator_id`, their participation in query processing may further narrow the scan range, improving query performance. After execution, the query results are returned to the user through the result rendering stage, completing a full conversational data query with data access control.

[0097] Optionally, in one implementation of this embodiment, the data query processing method described in this application can be applied not only to conversational data query (Text2SQL) scenarios but also to any other scenario where data permission control needs to be applied to dynamically generated query statements. For example, in a business intelligence (BI) report generation scenario, the report engine dynamically generates query statements based on the dimensions and metrics dragged by the user. These dynamically generated query statements can be used as the business SQL input to the syntax parsing stage, where the method described in this application attaches permission conditions. In a data interface service scenario, the server dynamically assembles query statements based on interface parameters, and the permission rule recall and permission condition concatenation process described in this application can also be reused. That is, in the implementation of this application where a natural language query request is used as input, the business SQL is generated by a large language model based on the natural language query request and the tagged database structure information. In other implementations, the business SQL can also be generated by a report engine, query builder, or other program modules based on business query requirements. The processing flow described in this application can be applied to any situation where row-level data permissions need to be attached to an existing query statement in a defined manner.

[0098] The data query processing method provided in this application distinguishes between business fields and permission fields by marking the permission fields in the database structure information during retrieval. Based on this, a business SQL containing only business query conditions and not permission conditions is generated. The business SQL is then parsed to obtain an abstract syntax tree. The data tables, table names, table aliases, and the positional relationship of the WHERE clauses involved are determined based on the abstract syntax tree. At the same time, the applicable permission rules are determined based on the data tables, and permission conditions are generated by combining the permission context information corresponding to the current query. Finally, the permission conditions are concatenated into the business SQL based on the table names, table aliases, and the positional relationship of the WHERE clauses determined by the abstract syntax tree to obtain the final SQL. This method separates business semantic understanding and data access control into two independent processing stages, allowing the large language model to focus on business semantics without assuming access control responsibilities, thus eliminating the coupling between business logic and access control logic at the data source. Furthermore, it replaces string-level text concatenation with deterministic operations at the syntactic structure level, ensuring accurate attachment of access control conditions in complex scenarios such as multi-table joins, table aliases, and nested subqueries. This avoids misalignment and syntax errors, as well as the SQL injection risk introduced by directly concatenating strings in a generative model. Simultaneously, access control rules are configured and dynamically updated independently of business code and the large language model. While supporting multiple row-level data permissions such as department, user, and custom SQL, it eliminates the need to retrain the model and avoids the additional access control reasoning tasks previously undertaken by the large language model in the business SQL generation stage, reducing access control maintenance costs.

[0099] Example 2 Based on the data query processing method provided in Embodiment 1 of this application, this embodiment also provides a corresponding data query processing device, such as... Figure 5 As shown, Figure 5 This is a schematic diagram of the structure of a data query processing device 50 provided in an embodiment of this application. The data query processing device 50 includes: The structure marking module 501 is used to obtain the input natural language query request, retrieve database structure information according to the natural language query request, and mark the permission fields in the database structure information to distinguish between business fields and permission fields. The business SQL generation module 502 is used to generate business SQL based on the natural language query request and the tagged database structure information, wherein the business SQL includes the business query conditions corresponding to the natural language query request, but does not include the permission conditions set for the permission field. The syntax parsing module 503 is used to parse the business SQL, obtain the abstract syntax tree corresponding to the business SQL, and determine the data table involved in the business SQL, the table name and table alias information corresponding to the data table, and the positional relationship of the WHERE clause based on the abstract syntax tree. The permission condition generation module 504 is used to determine the applicable permission rules based on the data table, and generate permission conditions based on the permission rules and the permission context information corresponding to the current query. The permission concatenation module 505 is used to concatenate the permission conditions into the business SQL based on the table name, the table alias information determined by the abstract syntax tree and the positional relationship of the WHERE clause, to obtain the final SQL.

[0100] Optionally, in one implementation of this embodiment, the structure tagging module 501 is further configured to set permission field tags, permission types, and permission field description information for the fields in the database structure information; and to divide the fields in the database structure information into a business field list, a permission field list, and detailed metadata of the permission fields according to the permission field tags.

[0101] Optionally, in one implementation of this embodiment, the business SQL generation module 502 is further configured to determine business query conditions based on the natural language query request; generate business SQL generation prompt information based on the business query conditions and the marked database structure information, and input the business SQL generation prompt information into the large language model; instruct the large language model to process the business query conditions in the business SQL generation prompt information, and restrict the large language model to generate permission conditions set for the permission field based on the marking of the permission field, so as to obtain the business SQL.

[0102] Optionally, in one implementation of this embodiment, the permission condition generation module 504 is further configured to perform precise matching on a preset permission rule knowledge base based on the agent identifier corresponding to the natural language query request and the data table to determine the applicable permission rule; and / or perform vector recall based on the semantic similarity between the query-related information and the permission rules in the permission rule knowledge base to determine the applicable permission rule.

[0103] Optionally, in one implementation of this embodiment, the device 50 further includes a rule configuration module (not shown in the figures). This rule configuration module is used to respond to a configuration operation for the permission rule knowledge base by obtaining an agent identifier, a data table identifier, a permission type, and a permission expression with variable placeholders, generating permission rules and storing them in the permission rule knowledge base; synchronizing the permission rules to a vector knowledge base after vectorization processing for use in the vector retrieval; and synchronously updating the corresponding permission rules in the vector knowledge base when the permission rules in the permission rule knowledge base are updated.

[0104] Optionally, in one implementation of this embodiment, the permission rule includes a permission type and a permission expression with variable placeholders; the permission condition generation module 504 is further configured to obtain the user identifier, department identifier, or department set corresponding to the current query as the permission context information; and replace the variable placeholders in the permission expression according to the permission context information to obtain the permission condition; wherein, the permission type includes at least one of department permissions, user permissions, and custom SQL permissions.

[0105] Optionally, in one implementation of this embodiment, the permission condition generation module 504 is further configured to: construct multiple sub-permission conditions based on the permission types corresponding to the multiple permission rules when the current query matches multiple permission rules for the same data table; and combine the multiple sub-permission conditions into an aggregate permission condition using the logical OR operator; and generate a logical constant false condition expression as a blocking permission condition when it is detected that the permission context information corresponding to the current query is missing or empty, so as to block data output when the current query does not obtain a valid permission context; and generate the final permission condition acting on the business SQL according to the aggregate permission condition or the blocking permission condition.

[0106] Optionally, in one implementation of this embodiment, the permission concatenation module 505 is further configured to establish a mapping relationship between the table name and the table alias of the data table; determine the target table corresponding to the permission condition according to the mapping relationship between the table name and the table alias; and concatenate the permission condition to the WHERE condition corresponding to the target table using a logical AND operator based on the WHERE clause position relationship determined by the abstract syntax tree.

[0107] Optionally, in one implementation of this embodiment, the permission concatenation module 505 is further configured to: when the business SQL involves multiple data tables, determine the permission rules applicable to each data table and generate corresponding permission conditions, and concatenate each permission condition to the WHERE condition of the corresponding target table according to the mapping relationship; when the business SQL contains a subquery, determine the positional relationship of the WHERE clause corresponding to the subquery according to the abstract syntax tree, and concatenate the permission conditions corresponding to the data tables involved in the subquery to the WHERE condition of the subquery; when the WHERE clause corresponding to the target table does not exist, create a WHERE clause in the query body to which the target table belongs in the abstract syntax tree, and use the permission conditions as the WHERE condition of the created WHERE clause.

[0108] Optionally, in one implementation of this embodiment, the permission concatenation module 505 is further configured to recursively traverse the abstract syntax tree (AST) corresponding to the business SQL when the business SQL contains multi-table join statements or nested subquery statements, in order to identify query nodes at each level and the join relationship types corresponding to each query node; wherein, the query nodes include single-level query nodes, subquery nodes, and join query nodes; extract the table alias corresponding to the target data table in each query node, and add the table alias limiting prefix before the permission field in the permission condition; when the join relationship type is an outer join, concatenate the permission condition with the table alias limiting prefix to the ON condition of the join query node to maintain the join query semantics; when the join relationship type is an inner join or there is a subquery, concatenate the permission condition with the table alias limiting prefix to the WHERE condition of the corresponding subquery node or main query node.

[0109] Optionally, in one implementation of this embodiment, the device 50 further includes a security verification module ( Figure 5 Not shown in the image, please refer to [link / reference]. Figure 2 The security verification module is used to perform security verification on the final SQL after obtaining it: verifying whether the final SQL is a SELECT statement; detecting whether the final SQL contains preset dangerous keywords; verifying whether the permission conditions are concatenated into the business SQL according to the preset concatenation relationship; and outputting the final SQL when the security verification passes.

[0110] Optionally, in one implementation of this embodiment, the device 50 further includes a database execution module ( Figure 5 Not shown in the image, please refer to [link / reference]. Figure 2The database execution module is used to receive the final SQL and execute the query to obtain the query result, and return the query result to the user in the form of execution result return; wherein, the final SQL includes the business query condition and the permission condition, so that the business query condition and the permission condition together serve as query filtering conditions.

[0111] The data query processing apparatus provided in this application includes a structure marking module that marks permission fields in the retrieved database structure information to distinguish between business fields and permission fields; a business SQL generation module that generates business SQL containing only business query conditions and excluding permission conditions based on the natural language query request and the marked database structure information; a syntax parsing module that parses the business SQL to obtain an abstract syntax tree and determines the data tables involved in the business SQL, the table names and aliases of the data tables, and the positional relationship of the WHERE clauses based on the abstract syntax tree; a permission condition generation module that determines the applicable permission rules based on the data tables and generates permission conditions based on the permission rules and the permission context information corresponding to the current query; and a permission concatenation module that concatenates the permission conditions into the business SQL based on the table names, table aliases, and the positional relationship of the WHERE clauses determined by the abstract syntax tree to obtain the final SQL. This system isolates business logic from permissions at the database structure level, allowing the large language model to focus on business semantic understanding without assuming permission responsibilities. It also uses deterministic operations at the syntax level to mount permission conditions, ensuring accurate mounting even in complex scenarios such as multi-table joins, table aliases, and nested subqueries. This guarantees both the accuracy of business semantic understanding and the security and controllability of data permissions. Furthermore, the permission rules support flexible configuration and dynamic updates, significantly reducing permission maintenance costs.

[0112] Example 3 This application also provides a storage medium storing a computer program thereon, which, when executed by a processor, implements any of the data query processing methods described in the foregoing embodiment one of this application.

[0113] Example 4 This application also provides an electronic device, such as... Figure 6 As shown, Figure 6 This application provides a schematic diagram of the structure of an electronic device 30, which includes: One or more processors 301, communication interface 302, memory 303 and communication bus 304, the processors 301, memory 303 and communication interface 302 communicate with each other through communication bus 304; Memory 303 is used to store one or more programs; When the one or more programs are executed by the one or more processors 301, the one or more processors 301 implement any of the data query processing methods described in Embodiment 1 of this application.

[0114] This application has now described specific embodiments of the subject matter. In some cases, the actions described in the claims can be performed in a different order and still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing can be advantageous.

[0115] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0116] For ease of description, the above devices are described separately by function as various units. Of course, in implementing this application, the functions of each unit can be implemented in one or more software and / or hardware.

[0117] It should also be noted that 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 process, method, article, or apparatus. Without further limitation, 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 that element.

[0118] Those skilled in the art will understand that the embodiments of this application can be provided as methods, systems, or computer program products. The embodiments of this application can also be implemented by a computer program, which can be stored in a computer-readable storage medium and executed by a processor to implement the above-described data query processing method; the computer-readable storage medium may include, but is not limited to, random access memory, read-only memory, flash memory, solid-state memory, disk storage, optical storage, or other media capable of storing computer programs.

[0119] This application can be described in the general context of computer-executable instructions that are executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific transactions or implement specific abstract data types. This application can also be practiced in distributed computing environments where transactions are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

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

[0121] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A data query processing method, characterized in that, include: Obtain the input natural language query request, retrieve the database structure information based on the natural language query request, and mark the permission fields in the database structure information to distinguish between business fields and permission fields; Business SQL is generated based on the natural language query request and the tagged database structure information, wherein the business SQL includes the business query conditions corresponding to the natural language query request, but does not include the permission conditions set for the permission field; The business SQL is parsed to obtain the abstract syntax tree corresponding to the business SQL, and the data tables involved in the business SQL, the table names and aliases of the data tables, and the positional relationship of the WHERE clauses are determined based on the abstract syntax tree. The applicable permission rules are determined based on the data table, and permission conditions are generated based on the permission rules and the permission context information corresponding to the current query. Based on the table name, table alias information, and the positional relationship of the WHERE clause determined by the abstract syntax tree, the permission conditions are concatenated into the business SQL to obtain the final SQL.

2. The data query processing method according to claim 1, characterized in that, The step of marking the permission fields in the database structure information includes: Set permission field flags, permission types, and permission field descriptions for the fields in the database structure information; Based on the permission field markers, the fields in the database structure information are divided into a business field list, a permission field list, and detailed metadata of the permission fields.

3. The data query processing method according to claim 1, characterized in that, The step of generating business SQL based on the natural language query request and the tagged database structure information includes: Determine the business query conditions based on the natural language query request; Based on the business query conditions and the marked database structure information, a business SQL generation prompt is generated, and the business SQL generation prompt is input into the large language model; The business SQL generation prompt message instructs the large language model to process the business query conditions, and restricts the large language model to generate permission conditions set for the permission field based on the flag of the permission field, so as to obtain the business SQL.

4. The data query processing method according to claim 1, characterized in that, The step of determining the applicable permission rules based on the data table includes: Obtain the agent identifier corresponding to the natural language query request; Based on the agent identifier and the data table, a precise match is performed on the preset permission rule knowledge base to determine the applicable permission rule; And / or, Vector recall is performed based on the semantic similarity between the query information and the permission rules in the permission rule knowledge base to determine the applicable permission rules.

5. The data query processing method according to claim 1, characterized in that, The permission rules include permission types and permission expressions with variable placeholders; The step of generating permission conditions based on the permission rules and the permission context information corresponding to the current query includes: Obtain the user identifier, department identifier, or department set corresponding to the current query as the permission context information; The placeholder variables in the permission expression are replaced according to the permission context information to obtain the permission conditions; The permission types include at least one of department permissions, user permissions, and custom SQL permissions.

6. The data query processing method according to claim 1, characterized in that, The step of concatenating the permission conditions into the business SQL based on the table name, table alias information determined by the abstract syntax tree, and the positional relationship of the WHERE clause includes: Establish a mapping relationship between the table name and the table alias of the data table; The target table corresponding to the permission conditions is determined based on the mapping relationship between the table name and the table alias; Based on the positional relationship of the WHERE clauses determined by the abstract syntax tree, the permission conditions are concatenated to the corresponding WHERE condition of the target table using a logical AND operator.

7. The data query processing method according to claim 6, characterized in that, The WHERE clause positional relationship determined based on the abstract syntax tree, which concatenates the permission conditions to the corresponding WHERE condition of the target table using a logical AND operator, includes at least one of the following: When the business SQL involves multiple data tables, the permission rules applicable to each data table are determined and corresponding permission conditions are generated. Then, according to the mapping relationship, each permission condition is concatenated to the WHERE condition of the corresponding target table. When the business SQL contains a subquery, the positional relationship of the WHERE clause corresponding to the subquery is determined according to the abstract syntax tree, and the permission conditions corresponding to the data tables involved in the subquery are concatenated into the WHERE condition of the subquery; When the WHERE clause corresponding to the target table does not exist, a WHERE clause is created in the query body to which the target table belongs in the abstract syntax tree, and the permission condition is used as the WHERE condition of the created WHERE clause.

8. The data query processing method according to claim 1, characterized in that, After obtaining the final SQL, the method further includes performing security verification on the final SQL: Verify that the final SQL statement is a SELECT statement; Detect whether the final SQL contains preset dangerous keywords; Verify whether the permission conditions are concatenated into the business SQL according to the preset concatenation relationship; When the security verification passes, the final SQL is output.

9. A data query processing device, characterized in that, include: The structure tagging module is used to obtain the input natural language query request, retrieve database structure information based on the natural language query request, and tag the permission fields in the database structure information to distinguish between business fields and permission fields. The business SQL generation module is used to generate business SQL based on the natural language query request and the tagged database structure information, wherein the business SQL includes the business query conditions corresponding to the natural language query request, but does not include the permission conditions set for the permission field. The syntax parsing module is used to parse the business SQL, obtain the abstract syntax tree corresponding to the business SQL, and determine the data tables involved in the business SQL, the table names and aliases of the data tables, and the positional relationship of the WHERE clauses based on the abstract syntax tree. The permission condition generation module is used to determine the applicable permission rules based on the data table, and generate permission conditions based on the permission rules and the permission context information corresponding to the current query. The permission concatenation module is used to concatenate the permission conditions into the business SQL based on the table name, the table alias information determined by the abstract syntax tree, and the positional relationship of the WHERE clause, to obtain the final SQL.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the data query processing method according to any one of claims 1 to 8.

Images