Governance constrained query method and system based on semantic hub

Abstract

The application discloses a governance constraint controlled query method and system based on a semantic center. In view of the problems that governance constraints are easy to be bypassed, tampered and uncontrollable in the whole link in the prior art, the application receives a natural language query request, determines a set of data objects allowed to be accessed based on a semantic center white list, converts the request into a limited DSL that only allows AND conjunction and does not support subqueries, acquires and locks an anchor table and a corresponding governance strategy version, forcibly injects and marks tenant isolation predicates and soft deletion predicates as unremovable in a top layer WHERE conjunction field of a DSL AST, and compiles into a parameterized SQL statement after passing a first check, and executes and generates an audit record by using a parameter binding mode after passing a second check. The application realizes the whole-link forced locking and accurate checking of governance constraints by two-stage checking and unremovable governance predicate injection, and effectively prevents unauthorized access to data.

Description

Technical Field

[0001] This invention relates to the field of computer database query compilation and natural language query processing technology, and in particular to a governance constraint-controlled query method and system based on semantic center. Background Technology

[0002] As enterprises deepen their digital transformation, their reliance on data is increasing, leading to a rapid growth in the demand for data querying and analysis from non-technical business personnel. However, traditional data querying methods heavily rely on Structured Query Language (SQL), requiring users to have database schema knowledge and SQL syntax writing skills. This presents a significant learning barrier for business personnel lacking technical expertise, limiting the timely release of data value.

[0003] To lower the barrier to data querying, Natural Language to SQL (Text-to-SQL) technology has emerged. This technology aims to automatically convert user-input natural language questions into SQL queries that can be executed in a database. In recent years, with breakthroughs in the natural language understanding and generation capabilities of Large Language Models (LLMs), using LLMs to perform Text-to-SQL tasks has become a common technical solution. This approach typically uses prompt word engineering to guide the LLM to understand the user's natural language query intent and directly generate the corresponding SQL statement to execute the query.

[0004] However, when applying large language models to enterprise-level data query scenarios, especially in environments involving data security and compliance governance, existing technical solutions have revealed several key technical shortcomings: Governance constraints are easily bypassed: In enterprise applications, data queries must strictly adhere to pre-defined data governance policies, such as tenant isolation (e.g., tenant_id = :tenant_param) and soft deletion filtering (e.g., deleted_at ISNULL). In existing solutions, SQL statements directly generated by large language models may fail to include or omit these necessary governance filtering conditions, thereby raising the risk of unauthorized data access or causing users to query invalid data that should have been logically deleted.

[0005] Governance constraints are susceptible to tampering: Even if governance constraints are included in the generation phase, the database engine or middleware's query rewriting rules may adjust the structure of the SQL statement during subsequent query compilation and logic optimization. During this process, critical governance predicates may be accidentally deleted, replaced, or moved out of the top-level conjunctive domain of the WHERE clause (e.g., incorrectly pushed down into the JOIN ON clause or subquery), causing the governance constraints to become partially or completely invalid in the final executed SQL.

[0006] Uncontrollable end-to-end: Existing solutions generally lack a comprehensive and systematic verification mechanism covering the entire process from the generation of intermediate query representations (such as DSLs) to the final SQL execution. Typically, only simple syntax checks are performed at a single stage (such as after generation), failing to verify the integrity, morphological accuracy, and consistency between different abstract representations (such as DSLAST and SQL AST) of governance predicates at different stages before and after compilation. This results in the inability to systematically guarantee the effectiveness of governance constraints.

[0007] Uncertainty and security risks in generated results: Large language models themselves suffer from the "illusion" problem, meaning their generated SQL statements may contain syntax errors, reference non-existent table or field names in the database, leading to query execution failures. Furthermore, when dealing with aggregate queries, the model may generate aliases containing illegal characters (such as Chinese characters) or incorrectly reference non-aggregate fields not appearing in the GROUP BY clause, violating standard database syntax rules. Directly executing SQL statements generated by large models also introduces potential SQL injection attack risks.

[0008] Therefore, there is an urgent need for a technical solution that can fully utilize the natural language understanding capabilities of large language models and can also use systematic technical means to forcibly inject, lock, and accurately verify governance constraints throughout the entire query compilation and execution chain to solve the above-mentioned technical problems. Summary of the Invention

[0009] To address the technical problems in the existing technologies mentioned above, such as the ease with which governance constraints can be bypassed, tampered with, and the lack of control over the entire process, as well as the security risks caused by the uncertainty of the generated results of large language models, this invention proposes a governance constraint-controlled query method and system based on semantic center.

[0010] To achieve the above objectives, the present invention adopts the following technical solution: A governance-constrained controlled query method based on semantic center, the method comprising: S1. Receive natural language query requests; S2. Based on the whitelist information pre-registered in the semantic center, determine the set of data objects that are allowed to be accessed in this query; the whitelist information includes at least the tables, fields, INNER JOIN relationships, and operator sets that are allowed to be accessed; S3. Convert the natural language query request into a restricted DSL. The restricted DSL is used to describe the SELECT, FROM, INNER JOIN, WHERE, GROUP BY, ORDER BY, and LIMIT clauses of the query, and the restricted DSL satisfies the following restricted syntax constraints: logical expressions only allow AND conjunction, OR and NOT are not supported; subqueries, common table expressions (CTEs), and set operations are not supported; the join type only allows INNER JOIN. S4. Obtain the query template or entity identifier corresponding to the natural language query request from the semantic center, and obtain the pre-specified anchor table identifier based on the query template or entity identifier, wherein the anchor table belongs to the whitelist information; S5. Obtain and lock the governance strategy version corresponding to the data object set from the semantic center. The governance strategy includes at least a tenant isolation strategy and a soft deletion strategy. S6. In the top-level WHERE conjunctive domain of the abstract syntax tree (AST) corresponding to the restricted DSL, a governance predicate node is forcibly added and marked as non-removable. The governance predicate node includes at least a tenant isolation predicate and a soft deletion predicate for the anchor table. S7. Perform a first check on the DSL AST after injecting the governance predicate. If the first check fails, refuse to generate an executable query and output the check failure message. The first verification includes at least: verifying that all governance predicate nodes exist and are located in the top-level WHERE conjunctive domain; verifying that the governance predicates satisfy the restricted form, wherein tenant_id and deleted_at cannot be used as function parameters and cannot participate in arithmetic expressions; verifying that the tables, fields, INNER JOIN relationships, and operators referenced in the DSL all belong to the whitelist information; and verifying that the GROUP BY and ORDER BY only reference the anchor table fields or aggregation results, and do not reference non-anchor table fields. S8. When the first verification passes, the restricted DSL is compiled into a parameterized SQL statement, and a set of bind variables corresponding to the parameterized SQL statement is generated. S9. Parse the parameterized SQL statement to obtain an SQL abstract syntax tree, and perform a second verification. If the second verification fails, refuse to execute the parameterized SQL statement and output a verification failure message. The second verification includes at least: verifying that the top-level WHERE conjoint field of the SQL abstract syntax tree contains tenant_id = :tenant_param for the anchor table and deleted_at IS NULL for the anchor table; verifying that the governance predicate is consistent with the version of the locking governance strategy; and verifying that the GROUP BY and ORDER BY only reference fields from the anchor table or aggregation results. S10. When the second verification passes, the parameterized SQL statement is executed using parameter binding and an audit record is generated. The audit record includes at least the governance policy version identifier, the governance predicate summary, and the results of the first and second verifications.

[0011] Preferably, the restricted syntax constraints of the restricted DSL in step S3 include: logical expressions only allow AND conjunction, and do not support OR or NOT; subqueries, common table expressions (CTEs), and set operations are not supported; the join type only allows INNER JOIN. Further, the WHERE clause of the restricted DSL consists only of comparison predicates connected by AND, and bracket structures used to change logical precedence are prohibited; the complete syntax rules of the restricted DSL are defined in BNF normal form, and the use of keywords such as OR, NOT, EXISTS, ANY, ALL, UNION, INTERSECT, EXCEPT, WITH, and HAVING is explicitly prohibited.

[0012] Furthermore, the whitelist information further restricts the allowed comparison operators to include only =, !=, <, <=, >, >=, LIKE, ILIKE, IN, NOT IN, IS NULL, IS NOT NULL, and BETWEEN; it also restricts each INNER JOIN to use the join key pair registered in the semantic center, and the join key pair is an equivalence comparison predicate.

[0013] Preferably, the process of converting the natural language query request into a restricted DSL in step S3 specifically involves: generating multiple candidate restricted DSLs based on the semantic context information injected by the semantic center using a large language model, and selecting the candidate restricted DSL that passes the first verification for compilation; the semantic context information includes whitelist information, semantic entity definitions, query template examples, and anchor table configuration information.

[0014] Furthermore, the non-removable governance predicate node mentioned in step S6 carries an immutable identifier in the abstract syntax tree. The system prevents subsequent rewrite rules from performing operations such as deletion, replacement, or removal of the governance predicate node from the top-level WHERE conjunctive domain by embedding an immutability guard function in the compilation rewrite process.

[0015] Preferably, the present invention calculates the digest hash value of the subtree of the governance predicate node according to the normalized serialization rules, and performs a consistency check on the digest hash value after compiling the parameterized SQL statement to ensure that the governance predicate is not tampered with during the conversion from restricted DSL to SQL.

[0016] Furthermore, the second verification in step S9 also includes: after parsing the parameterized SQL statement into an SQL abstract syntax tree, confirming that tenant_id and deleted_at do not appear under the function call node or arithmetic expression node, to prevent the governance predicate form from being tampered with.

[0017] Preferably, when the user request does not specify LIMIT, a LIMIT node with the maximum number of rows to return is forcibly injected into the restricted DSL abstract syntax tree, and the existence of the LIMIT node is verified in the second verification to avoid the performance risks caused by a full table scan.

[0018] This invention also provides a governance-constrained controlled query system based on a semantic center, used to implement the above-mentioned controlled query method. The system includes a semantic center module, a DSL generation module, a governance injection module, a first verification module, a compilation module, a second verification module, and an execution and auditing module. Specifically: the semantic center module stores and manages whitelist information, governance strategies, semantic entities, query templates, anchor table configurations, and entity relationships; the DSL generation module converts natural language query requests into DSLs that satisfy restricted syntactic constraints; the governance injection module forcibly adds and marks non-removable governance predicate nodes to the top-level WHERE conjunctive domain of the abstract syntax tree (AST) corresponding to the restricted DSL; and the first verification module verifies the DSL after the governance predicate is injected. The AST performs governance predicate existence, position, and morphology checks, as well as whitelist checks. The compilation module is used to compile the restricted DSL into a parameterized SQL statement when the first check passes. The second check module is used to perform governance predicate matching checks, governance strategy version consistency checks, and digest hash consistency checks on the SQL abstract syntax tree obtained by parsing the parameterized SQL statement. The execution and auditing module is used to execute the parameterized SQL statement using parameter binding and generate audit records when the second check passes.

[0019] The present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-described semantic center-based governance constraint controlled query method.

[0020] Compared with the prior art, the present invention has the following advantages: (1) The unbypassability of governance constraints is guaranteed from the root by using restricted DSL syntax. This application defines a restricted DSL with weaker expressive power than SQL. By explicitly prohibiting syntax structures such as OR, NOT, subqueries, CTEs and various set operations, it ensures that once the governance predicate is injected into the top-level WHERE conjunction domain of the DSL abstract syntax tree (AST), it cannot be bypassed or circumvented through logical reorganization or nested queries. Combined with the immutable flag and interceptor mechanism set on the AST node, the possibility of the governance predicate being deleted, replaced or shifted is eliminated from the compiler principle level, solving the problem that governance constraints are easily bypassed or tampered with in the prior art.

[0021] (2) By employing a two-stage AST verification and digest hash consistency verification, the entire chain of governance constraints is made controllable. This application sets up two lines of defense at the DSL AST level and the compiled SQL AST level, respectively. The first verification ensures the existence, position, form, and compliance of the whitelist of data object references of the governance predicates before compilation; the second verification verifies the integrity and form of the governance predicates in the SQL AST again before execution, and ensures that the governance predicates are not accidentally modified by any intermediate link during the conversion from DSL to SQL by comparing the normalized digest hash values ​​of the governance predicate subtrees. This two-stage, multi-level verification mechanism solves the problem of the uncontrollable entire chain of governance constraints in the prior art.

[0022] (3) The robustness and security of large language model-generated queries are improved through semantic center and whitelist mechanism. This application provides effective whitelist information (such as tables, fields, JOIN relationships, etc.) to the large language model through semantic center as the generation context, guiding the model to generate DSLs with restricted structure and legal and compliant referenced data objects. At the same time, the compilation process adopts parameterized query, separating the user input value from the SQL structure, fundamentally avoiding the risk of SQL injection. This series of mechanisms effectively overcomes the defects of existing technologies, such as large models being prone to illusions, referencing non-existent schema objects, and having the risk of injection security.

[0023] (4) By standardizing the DSL structure and enforcing validation, the syntax compatibility problem in aggregate queries is solved. This application enforces the DSL syntax rules, requiring the GROUP BY and ORDER BY clauses to reference only anchor table fields or aliases of aggregate results, and verifies this through two-stage validation, avoiding common SQL syntax errors such as referencing non-grouping fields in ORDER BY. At the same time, by restricting aliases to combinations of English letters, numbers, and underscores that conform to identifier specifications, the execution failure problem caused by generating illegal character aliases in large models is avoided, thereby improving the reliability of the final execution of natural language queries.

[0024] The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described in detail below with reference to the accompanying drawings. Attached Figure Description

[0025] Figure 1 The flowchart illustrates a governance constraint-controlled query method based on semantic center, as provided in an embodiment of the present invention.

[0026] Figure 2 A structural diagram of a semantic center provided for an embodiment of the present invention.

[0027] Figure 3 This is a schematic diagram illustrating a method for matching query templates and entity identifiers based on natural language query requests, as provided in an embodiment of the present invention.

[0028] Figure 4 This is a schematic diagram of a restricted DSL AST structure provided in an embodiment of the present invention.

[0029] Figure 5 This is a schematic diagram of a two-stage verification process provided in an embodiment of the present invention, wherein the two-stage verification includes a first verification and a second verification.

[0030] Figure 6 A schematic diagram of a method for governance predicate digest hash consistency verification provided in an embodiment of the present invention.

[0031] Figure 7 This is a structural diagram of a governance constraint-controlled query system based on semantic center, provided in an embodiment of the present invention. Detailed Implementation

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

[0033] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to these processes, methods, products, or devices.

[0034] The following are explanations and definitions of the terms used in the embodiments of this invention: A Domain-Specific Language (DSL) is a computer language designed for a specific application domain or problem category. Unlike general-purpose programming languages, DSLs directly map the core concepts and operations of that domain through their syntax, semantics, and built-in abstractions. They shield users from low-level technical details by providing highly specialized, declarative expressions. Their core purpose is to enable domain experts to directly describe problems, rules, logic, or configurations in an intuitive way that closely resembles their professional terminology and thought processes. This significantly improves development efficiency, expressiveness, and maintainability for specific tasks, while lowering the barrier to entry.

[0035] An Abstract Syntax Tree (AST) is a tree-like representation of the syntactic structure of source code. It parses program code into a hierarchical tree structure composed of nodes and branches, ignoring specific syntactic details in the source code (such as parentheses and semicolons), thereby abstracting the logical structure and semantic relationships of the program. Each node in an AST represents a syntactic construct in the program (such as an expression, statement, or operator), and the hierarchical relationships between nodes reflect the nesting and combination of code. This tree structure is independent of specific grammar formats, providing a unified intermediate representation for program analysis, code transformation, optimization, and compilation processes, and is an important foundation for program processing and automation.

[0036] The Backus-Naur Form (BNF) is a meta-language representation used to precisely and formally describe the syntax of programming languages ​​or other formal languages. It defines the syntactic structure of a language through a finite set of "production rules," each rule expanding a "non-terminal symbol" (representing a syntactic category) into a sequence of "terminal symbols" (the actual symbols in the language) and other non-terminal symbols. The BNF paradigm clearly and unambiguously specifies how all legal sentences in a language are constructed, providing a rigorous theoretical foundation for language design, specification writing, and compiler / parser implementation.

[0037] The implementation of this invention will be described in detail below with reference to the aforementioned terminology.

[0038] The governance constraint-controlled query method and system based on semantic center provided in this embodiment are applied to the fields of computer database query compilation and natural language query processing technology. Through restricted DSL syntax pruning, AST node immutable attributes and interceptor mechanism, two-stage AST verification and SHA-256 digest hash consistency verification, the governance constraints are guaranteed to be unbypassable, unalterable or lost in the entire link from DSL generation to SQL execution.

[0039] Example 1 This embodiment provides a governance-constrained controlled query method based on semantic center, referring to... Figure 1 As shown, the method includes the following steps.

[0040] S1: Receive natural language query requests.

[0041] The computer device receives natural language query requests from users through its input interface. These natural language query requests are database data query needs expressed by the user in natural language, such as "query the total amount of confirmed sales orders this month".

[0042] S2: Semantic center whitelist information is determined.

[0043] Based on the whitelist information pre-registered in the semantic center, the set of data objects that are allowed to be accessed in this query is determined.

[0044] The semantic center is a structured storage system for storing and managing data access rules, semantic metadata, and governance strategies.

[0045] The whitelist information includes at least the tables, fields, INNER JOIN relationships, and operator sets that are allowed to be accessed.

[0046] In an optional implementation of this embodiment, the whitelist information further limits the allowed comparison operators to include only =, !=, <, <=, >, >=, LIKE, ILIKE, IN, NOT IN, IS NULL, IS NOT NULL, and BETWEEN; the whitelist information also limits each INNER JOIN to use the join key pair registered by the semantic center, and the join key pair is an equivalence comparison predicate.

[0047] refer to Figure 2 As shown, the semantic center adopts a multi-layer semantic model architecture, which includes, from top to bottom, an entity layer, a field layer, an indicator layer, a relationship layer, a template layer, and a bottom layer of governance strategies and whitelist information. The structure and function of each layer are as follows: (1) Entity Layer: The entity layer is the core foundational layer of the semantic center, used to store metadata information of business semantic entities. Each semantic entity corresponds to a core business object in the business scenario. The metadata of each semantic entity includes: a unique entity identifier, a display name, a main table name, a time field identifier, a marker indicating whether it is a core entity, its business domain, and a list of synonyms.

[0048] In this embodiment, the semantic entities stored in the entity layer include sales order, customer, and product; the main table of the sales order entity is sales_order, which is marked as the core entity and belongs to the sales domain, with synonyms including ["order", "sales order"]; the main table of the customer entity is customer, which belongs to the sales domain, with synonyms including ["customer", "buyer"]; the main table of the product entity is product, which belongs to the inventory domain, with synonyms including ["goods", "products"].

[0049] (2) Field Layer: The field layer is associated with the entity layer and is used to store the field-level semantic metadata of the corresponding main table for each entity. The metadata for each field includes: field unique identifier, display name, dimension / measure type marker, whether it is searchable, whether it is a primary key, field data type, enumeration value mapping relationship, and the source table it belongs to.

[0050] In this embodiment, the fields stored in the field layer include the order number (order_no), order status (status), order amount (total_amount), and customer name (customer_name) from the sales order table. The order number field is marked as a dimension field, searchable, and a primary key; the order status field is marked as a dimension field and configured with an enumeration value mapping relationship (confirmed → CONFIRMED); and the order amount field is marked as a measure field with a data type of DECIMAL.

[0051] (3) Metric Layer: The metric layer is associated with the field layer and is used to predefine reusable aggregate metric metadata for business purposes. The metadata for each metric includes: metric name, aggregation function, aggregation fields, and a list of optional grouping fields.

[0052] In this embodiment, the metrics stored in the metric layer include total order amount, number of orders, and average order amount; wherein the aggregation function of the total order amount metric is SUM, the aggregation field is total_amount, and the optional grouping fields are customer_name and status; the aggregation function of the number of orders metric is COUNT, the aggregation field is *, and the optional grouping fields are status and order_date; the aggregation function of the average order amount metric is AVG, and the aggregation field is total_amount.

[0053] (4) Relation Layer: The association layer stores metadata about the relationships between entities and defines the INNER JOIN rules between the corresponding main tables of the entities. The metadata for each association includes: left table identifier, right table identifier, join key pair (left table field, right table field), and join type (fixed to INNER JOIN).

[0054] In this embodiment, the relationships stored in the association layer include: an INNER JOIN relationship between the sales_order table and the customer table, with the join key pair being sales_order.customer_id = customer.id; and an INNER JOIN relationship between the sales_order table and the product table, with the join key pair being sales_order.product_id = product.id.

[0055] The association layer provides standardized JOIN paths for multi-entity query scenarios, and can automatically generate JOIN clauses that conform to whitelist rules through the shortest path algorithm.

[0056] (5) Template Layer: The template layer stores predefined, standardized query template metadata, with each template corresponding to a high-frequency business query scenario. Template metadata includes: template name, query intent type, required slot list, anchor table identifier, query example, and pre-configured filtering conditions.

[0057] In this embodiment, the query templates stored in the template layer include an order summary query template and a customer order statistics template. The order summary query template has an intent type of aggregation query, a required slot of time range and status, an anchor table of sales_order, and a query example of "query the total amount of confirmed sales orders this month". The customer order statistics template has an intent type of grouped aggregation query, a required slot of time range, an anchor table of sales_order, and a query example of "statistics the number and total amount of orders this month by customer".

[0058] (6) The underlying configuration layer includes governance policies and whitelist information, among which: Governance strategy: End-to-end data governance rules that bind storage and data objects, including at least tenant isolation policies and soft deletion policies, with each governance policy carrying a unique version number; In this embodiment, the tenant isolation policy is tenant_id = :tenant_param, the soft deletion policy is deleted_at IS NULL, and the policy version number is v2026.04.01; Whitelist information: Stores access control rules for the entire query chain, including the set of tables allowed to be accessed, the set of fields allowed to be accessed, the set of INNER JOIN key pairs allowed, and the set of operators allowed; In this embodiment, tables are allowed to include sales_order, customer, and product. Operators allowed include =, !=, <, >, LIKE, IN, IS NULL, etc. JOIN key pairs are allowed to include (customer_id, customer.id), etc.

[0059] S3: Natural language query requests are converted to restricted DSL.

[0060] The natural language query request is converted into a restricted DSL, which describes the SELECT, FROM, INNER JOIN, WHERE, GROUP BY, ORDER BY, and LIMIT clauses of the query, wherein the restricted DSL satisfies the following restricted syntax constraints: (1) Logical expressions only allow AND conjunction, and do not support OR or NOT; (2) Subqueries, Common Table Expressions (CTEs), and UNION / INTERSECT / EXCEPT set operations are not supported; (3) Only INNER JOIN is allowed for the connection type.

[0061] In an optional implementation of this embodiment, the WHERE clause of the restricted DSL consists only of comparison predicates connected by AND, and bracket structures used to change logical precedence are prohibited.

[0062] In an optional implementation of this embodiment, the specific process of converting a natural language query request into a restricted DSL is as follows: Multiple candidate restricted DSLs are generated by a large language model based on semantic context information injected by the semantic center. Pre-validation is performed on each candidate restricted DSL, and those that meet the restricted grammatical constraints and whitelist requirements are output to subsequent processes. Finally, the candidate restricted DSL that passes the first validation in step S7 is selected for compilation. The semantic context information includes whitelist information, semantic entity definitions, query template examples, and anchor table configuration information. The large language model is a pre-trained generative large language model used to convert natural language into structured DSLs.

[0063] In this embodiment, the lexical rules of the restricted DSL are as follows: (1) Identifier: It consists of letters, numbers, underscores and dollar signs. The first character must be a letter or an underscore. The regular expression is ^[a-zA-Z_$][a-zA-Z0-9_$]*$, which is used for table names, field names and aliases; (2) Qualified identifier: It consists of the table name and field name connected by a dot, in the format "table name.field name", and the regular expression is ^[a-zA-Z_$][a-zA-Z0-9_$]*\.[a-zA-Z_$][a-zA-Z0-9_$]*$; (3) Parameter placeholders: Named parameters that begin with a colon, in the format: parameter name, are converted into bind variables when compiled into SQL; (4) Literals: including string literals, numeric literals, boolean literals, and null literals; (5) Reserved keywords: SELECT, FROM, INNER JOIN, ON, WHERE, AND, GROUP BY, ORDER BY, ASC, DESC, LIMIT, OFFSET, AS, IS NULL, IS NOT NULL, BETWEEN, IN, NOT IN, LIKE, ILIKE, case-insensitive; (6) Forbidden keywords: OR, NOT, EXISTS, ANY, ALL, SOME, UNION, INTERSECT, EXCEPT, WITH, HAVING, CASE, WHEN, LEFT, RIGHT, OUTER, FULL, CROSS, NATURAL. The parser will directly report an error when it encounters a forbidden keyword.

[0064] The complete syntactic rules of the restricted DSL are defined in BNF paradigm as shown in Table 1.

[0065] Table 1: BNF Paradigm Definitions of Restricted DSL Complete Syntax Rules

[0066] The restricted DSL is serialized and transmitted and stored in JSON format within the system. Its JSON structure is defined as follows: { "table": "Main table name (must be on the whitelist)", "fields": ["Field1", "Field2"],"conditions": [ { "field": "Field name or qualified field name", "operator": "Operator", "value": "Value or array of values", "logic": "AND"} ], "joins": [ { "table": "Join table name", "type": "INNER", "leftField": "Left table.field", "rightField": "Right table.field"} ], "groupBy": ["Group field1", "Group field2"], "aggregateFields": [ { "function": "Aggregate function name", "field": "Aggregate field name", "alias": "Result alias"} ], "orderBy": [ { "field": "Sorting field name or aggregate alias", "direction": "ASC or DESC"} ], "limit": 100, "offset": 0} The value constraints for each field are as follows: The table field must be non-empty, match the preset identifier regular expression, and belong to the whitelist of allowed tables; The fields field is a string array, where each element matches a preset identifier or a qualified identifier regular expression; conditions.operator must be a whitelist of allowed operators; conditions.logic only allows the value "AND"; joins.type can only take the value "INNER"; The aggregateFields.function only allows values ​​of COUNT, SUM, AVG, MAX, and MIN. aggregateFields.alias must match the predefined identifier regular expression; orderBy.direction only allows values ​​of "ASC" or "DESC"; The limit field is a positive integer, and the maximum value does not exceed the upper limit configured by the system. In this embodiment, the default upper limit is 1000.

[0067] In this embodiment, the process by which the DSL parser deserializes the JSON-formatted DSL into an AST is as follows: (1) JSON structure validation: Validate that the input is valid JSON and contains the required field table; (2) Lexical validation: Perform identifier regular expression matching on each identifier class field and reject input containing illegal characters; (3) Prohibited Keyword Detection: Scan all string type field values ​​to check if they contain prohibited keywords. If a prohibited keyword is detected, the parsing will be refused. (4) AST construction: The validated JSON structure is converted into an AST node tree, with the root node being SelectStmt and the child nodes being FromClause, JoinList, WhereClause, GroupByClause, OrderByClause, and LimitClause in sequence; (5) Governance predicate injection point reservation: Reserve governance predicate injection positions in WhereClause's AndList; the governance predicate is an SQL condition expression used to implement data access governance rules, including but not limited to tenant isolation predicate and soft deletion predicate, used to enforce compliance constraints before query execution.

[0068] S4: Determine the anchor table.

[0069] The query template or entity identifier corresponding to the natural language query request is obtained from the semantic center, and the anchor table identifier is obtained based on the query template or entity identifier, wherein the anchor table belongs to the whitelist information.

[0070] Reference Figure 3 As shown, in this embodiment, the semantic center matches query templates and entity identifiers based on natural language query requests, and adopts a multi-strategy cascading matching architecture, specifically including the following steps: S41: Vocabulary-level rapid recall.

[0071] The system performs word segmentation and keyword extraction on natural language query requests, and implements fast candidate retrieval based on inverted indexes, specifically including: S411: Word segmentation and keyword extraction: Perform Chinese word segmentation processing on the natural language query request input by the user. In this embodiment, the HanLP word segmenter is used to extract word units tagged with nouns, verbs and adjectives, and filter out stop words and single-character word units; S412: Synonym Expansion: The extracted keywords are expanded based on the pre-registered synonym list of each entity in the semantic center and the query template, expanding the keyword set into an expanded keyword set containing the original keywords and their synonyms; S413: Inverted Index Matching: When the Semantic Center starts, it builds an in-memory inverted index for all enabled semantic entities and query templates. The index key is the entity / template name, display name, synonym, or word segmentation result in the description text, and the index value is the corresponding entity ID or template ID. The extended keyword set is used as the query term, and the text relevance score of each candidate entity / template is calculated using the BM25 scoring algorithm.

[0072] The BM25 scoring formula is as follows: Score(Q,D)=Σ IDF(qi)×(f(qi,D)×(k1+1)) / (f(qi,D)+k1×(1-b+b×|D| / avgdl)) Where Q is the extended keyword set, D is the indexed document of the candidate entity / template, qi is the i-th query term, f(qi,D) is the term frequency, |D| is the document length, avgdl is the average document length, and in this embodiment, k1=1.2 and b=0.75.

[0073] S41 outputs a set C1 of candidates whose BM25 scores are greater than a preset threshold T1, with each candidate carrying a text relevance score score_text.

[0074] S42: Semantic vector similarity ranking.

[0075] Semantic vector similarity is calculated on the candidate set recalled by S41 to achieve semantic-level fine ranking, specifically including: S421: Semantic Vector Encoding: The semantic center pre-calculates and stores semantic vectors for each semantic entity and query template. The semantic vectors are generated by encoding the display name, description, and synonym concatenation text of the entity / template by the text embedding model. In this embodiment, the vector dimension is 1024 dimensions. The semantic vectors are calculated asynchronously and persistently stored when the entity / template is created or updated. S422: Query Vector Calculation: Calculate the query vector Vq for the user's natural language query request using the same text embedding model; S423: Cosine Similarity Calculation: For each candidate in the candidate set C1, calculate the cosine similarity between its pre-stored semantic vector Vc and the query vector Vq. The calculation formula is as follows: sim(Vq,Vc)=(Vq·Vc) / (||Vq||×||Vc||) S42 assigns a semantic similarity score, score_semantic, to each candidate in the candidate set C1.

[0076] S43: Domain Context Enhancement.

[0077] The candidate scores are enhanced and adjusted based on the domain context information of the query request, specifically including: S431: Domain Detection: Detect business domain keywords from user query requests to determine the business domain to which the query belongs. Domain detection is based on the domain keyword mapping table registered in the semantic center. S432: Domain Affinity Weighting: For candidates in the candidate set that are the same as the detected business domain, apply a domain affinity weighting factor α, in this embodiment α=1.5; for candidates that do not belong to the domain, the weighting factor is 1.0; S433: Core Entity Priority: For candidates marked as core entities in the semantic center, apply a core entity weighting factor β, which is 1.2 in this embodiment; for candidates that are not core entities, the weighting factor is 1.0.

[0078] S44: Weighted fusion and priority arbitration. Specifically, it includes: S441: Overall Score Calculation: Calculate the overall matching score for each candidate. The formula is as follows: score_final=(w1×score_text+w2×score_semantic)×domain_boost×core_boost Where w1 and w2 are the weight coefficients of text relevance and semantic similarity, in this embodiment w1=0.4, w2=0.6, domain_boost is the domain affinity weighting factor, and core_boost is the core entity weighting factor.

[0079] S442: Matching result confirmed: For query template matching: select the candidate with the highest comprehensive score that exceeds the template matching threshold T_template as the matching query template; if no candidate exceeds the threshold, it is determined that there is no matching template. For entity identifier matching: the candidate with the highest overall score that exceeds the entity matching threshold T_entity is selected as the primary matching entity; at the same time, other candidates with an overall score that exceeds the associated entity threshold T_related are selected as associated entities to infer the INNER JOIN path.

[0080] S443: Anchor Table Determination: Based on the matching query template or main matching entity, obtain the pre-specified anchor table identifier from the semantic center; if a query template is matched, the anchor table is the main table specified in the template; if no template is matched but an entity is matched, the anchor table is the main table of that entity; if no matching query template or entity is found, throw a matching exception and terminate the query process.

[0081] In this embodiment, the matching process follows the template priority rule. When both the query template and the semantic entity are matched, the configuration information of the query template is used first. When multiple semantic entities are matched, the system calculates the INNER JOIN path between entities based on the entity association relationship registered in the semantic center and injects the path into the JOIN clause of the DSL.

[0082] In some optional implementations, the weight coefficients w1 and w2, weighting factors α and β, and matching thresholds T1, T_template, T_entity, and T_related can be dynamically configured and adjusted according to the matching accuracy requirements and domain characteristics of the business scenario. The k1 and b parameters in the BM25 algorithm can also be adapted and optimized based on corpus features.

[0083] S5: Lock the governance policy version.

[0084] The governance strategy version corresponding to the data object set is obtained and locked from the semantic center. The governance strategy includes at least a tenant isolation strategy and a soft deletion strategy. In this embodiment, after locking the governance strategy version, this version of the governance strategy is used throughout the entire query process to avoid inconsistencies in constraints caused by governance strategy updates during the query process.

[0085] S6: Force injection of non-removable governance predicates.

[0086] In the top-level WHERE conjunctive domain of the abstract syntax tree (hereinafter referred to as DSL AST) corresponding to the restricted DSL, a governance predicate node is forcibly added and marked as non-removable. The governance predicate node includes at least: For the anchor table, the tenant isolation predicate is: tenant_id = :tenant_param; The soft deletion predicate for the anchor table is: deleted_at IS NULL.

[0087] Reference Figure 4 As shown, in this embodiment, the non-removable governance predicate node carries an immutable identifier in the AST, and subsequent rewrite rules are prohibited from deleting, replacing, or removing the governance predicate node from the top-level WHERE conjunctive domain.

[0088] In this embodiment, each predicate node (PredicateNode) of the DSL AST contains the following attributes: nodeId: String type, a unique identifier for the node, in the format "pred_{uuid}", where uuid is a universally unique identifier. nodeType: An enumeration type with values ​​COMPARISON, IS_NULL, BETWEEN, and IN; column: Column reference type, formatted as "table name.field name"; operator: String type, operator; operand: parameter or constant type, parameter placeholder or constant; immutable: Boolean type, immutable identifier, true for governance predicate nodes, false by default for ordinary predicate nodes; governanceTag: String type, governance tag, with values ​​of "TENANT_ISOLATION", "SOFT_DELETE" or null; sourceVersion: String type, the version number of the source governance policy.

[0089] In this embodiment, node modification interception logic is set during the compilation and rewriting stages, implemented using the immutabilityGuard function, as referenced. Figure 4 The immutability guard function is a callback interception function embedded in the AST compilation and rewriting process, used to perform permission verification on modification operations of AST nodes. Its specific logic is as follows: when an operation request for a target node is received, including DELETE, REPLACE, MOVE, and MODIFY_OPERAND, the immutable attribute of the target node is first checked. If the immutable attribute of the target node is true, the operation is rejected, the violation attempt is recorded, and an immutable node violation exception is thrown; if the immutable attribute of the target node is false, the operation is allowed to continue.

[0090] The specific types of operations that are intercepted include: Deletion interception: When a rewrite rule attempts to remove a predicate node from the list of child nodes of the WHERE conjunctive domain, check the immutable property of the node; if it is true, the deletion is rejected. Replacement interception: When a rewrite rule attempts to replace a predicate node with another node, it checks the immutable property of the node to be replaced. If the immutable property is true, the replacement is rejected. Position movement interception: When a rewrite rule attempts to move a predicate node from the top-level WHERE conjunction domain to other positions such as a subquery, JOIN ON clause, or HAVING clause, check the immutable property of the node; if it is true, the move is rejected. Operand tampering interception: When a rewrite rule attempts to modify the operand of a governance predicate node, check the node's immutable property; if it is true, the modification is rejected.

[0091] When the immutability check interceptor detects a violation, the system performs the following exception handling: Immediately terminate the current query compilation process and do not generate any executable SQL; Generate structured error information containing the type of violation, target node identifier, and governance tag; Violations will be logged in the audit log for use in security audits. Return a verification failure response to the caller, explicitly indicating that the governance predicate protection mechanism has been triggered.

[0092] In this embodiment, after the governance predicate injection is completed, the first hash calculation is performed on the DSL AST with the injected governance predicate to generate a digest hash value H1. The specific method includes: Step a: Collect and manage predicate nodes: Traverse the top-level WHERE conjoint domain (AndList) of the current DSL AST, and filter out all predicate nodes carrying a governance tag (governanceTag is not empty) to obtain the governance predicate nodes. The governance predicate nodes are the tenant isolation predicates and soft deletion predicates that are effective in this query.

[0093] Step b: Sort by governmentTag lexicographical order: The collected governance predicate nodes are sorted lexicographically by governanceTag (SOFT_DELETE first, TENANT_ISOLATION second); if multiple nodes with the same tag exist (e.g., due to duplicate injection caused by defensive programming), they are further sorted lexicographically by the string referenced in the column.

[0094] Step c, semantic equivalence deduplication: After sorting, semantic deduplication is performed on the list. Two nodes are considered semantically equivalent if their column, operator, operand_type (operand type), and operand_value (operand value) are completely identical. For semantically equivalent duplicate nodes, only the first occurrence of the node after sorting is retained, and the rest are ignored.

[0095] Step d, Normalization serialization: The AST subtree is converted into a deterministic string representation, ensuring that semantically equivalent governance predicates generate completely consistent serialization results. The normalized serialization method is as follows: For each deduplicated governance predicate node, the system converts it into a single string line according to the following fixed format: governanceTag | column | operator | operand_type | operand_value The normalization rules for each field are as follows: governanceTag: Outputs the original value directly, in uppercase.

[0096] Columns: Convert all columns to lowercase, remove extra spaces, and use the fixed format "table_name.field_name". For example, when the anchor table is sales_order, the tenant isolation field is output as sales_order.tenant_id, and the soft delete field is output as sales_order.deleted_at.

[0097] operator: Convert to uppercase. For operators such as IS NULL and IS NOT NULL that consist of two words, retain a space between them.

[0098] operand_type: If the operand is a parameter placeholder (i.e., a named parameter that starts with a colon, such as tenant_param), then PARAM is output; if the operand is a constant (such as NULL, a number, or a string literal), then CONST is output.

[0099] operand_value: When operand_type is PARAM, output the name of the parameter placeholder (excluding the actual bound value); when operand_type is CONST, output the literal representation of the constant: NULL is output as NULL, numbers are output as their decimal strings, and strings are output without quotes but special characters must be escaped (the vertical bar | is replaced with \|, the newline character \n is replaced with \\n, and the backslash \ is replaced with \\).

[0100] The five fields mentioned above are separated by a vertical bar character "|". After single predicate serialization is completed, the system concatenates each serialized line into a complete string S using a newline character "\n" according to the node order determined in step b.

[0101] Step e: Convert string S to UTF format 8-encoding converted to byte sequence; Step f: Apply SHA to the UTF-8 byte sequence The 256 hash algorithm is used to calculate the hash digest of the byte sequence, resulting in a 32-byte hash digest. The hash value is then encoded into a 64-character lowercase hexadecimal string, which serves as the final hash digest H1.

[0102] In this embodiment, the hash calculation does not use a salting mechanism to avoid increasing the complexity of cross-node verification. The reason is as follows: the serialized content of the governance predicate itself contains structured information such as table names, field names, and governance tags, and there is no risk of rainbow table attacks. Salting would only increase the complexity of cross-node verification.

[0103] S7: Perform the first verification.

[0104] The first validation is performed on the DSL AST after the injection of governance predicates. If the first validation fails, the generation of executable queries is rejected and a validation failure message is output. Simultaneously, the data is fed back to the large language model to regenerate the DSL. (Refer to...) Figure 5 As shown, the first verification includes at least the following: (1) Existence check of governance predicates Traverse the top-level WHERE conjunctive domain of the DSL AST and check if there are any nodes marked as governance predicates. The verification rules are: there must be at least one predicate node with governanceTag="TENANT_ISOLATION" and at least one predicate node with governanceTag="SOFT_DELETE". If any governance predicate is missing, output an error message and refuse to continue compiling.

[0105] (2) Governance of predicate position verification Check whether all governance predicate nodes are located in the top-level WHERE conjunction domain. The verification rule is: traverse the AST tree and check whether the parent node of the governance predicate node is the AndList of the top-level WhereClause. If the governance predicate node is found to be located in a non-top-level position, output an error message and refuse to continue compiling.

[0106] (3) Governance predicate morphology verification The structure of the governance predicate node is checked to ensure it meets the restricted form requirements. The verification rules are as follows: the tenant isolation predicate must be in the form of anchor table.tenant_id = :tenant_param, the operator must be =, and the right operand must be a parameter placeholder; the soft delete predicate must be in the form of anchor table.deleted_at IS NULL, and the operator must be IS NULL; tenant_id and deleted_at cannot be used as function parameters and cannot participate in arithmetic expressions; if a form abnormality is detected, an error message is output, and compilation is refused.

[0107] (4) Whitelist verification Check whether all data objects referenced in the restricted DSL belong to the whitelist. The verification rules are as follows: the main table must be in the whitelist of allowed tables; all referenced fields must be in the whitelist of fields in the corresponding table; tables joined by JOIN must be in the whitelist of allowed tables; JOIN key pairs must be in the INNER JOIN relationship registered in the semantic center; operators used in the WHERE condition must be in the whitelist of allowed operators. If an unauthorized reference is detected, output an error message and refuse to continue compilation.

[0108] (5) Validation of the reference range of GROUP BY and ORDER BY Check whether the fields referenced in the GROUP BY and ORDER BY clauses conform to the anchor table constraints. The validation rules are as follows: fields in the GROUP BY clause must be fields of the anchor table, and references to fields outside the anchor table are not allowed; fields in the ORDER BY clause must be fields of the anchor table or aliases of the aggregation result, and references to fields outside the anchor table are not allowed; if an out-of-bounds reference is detected, an error message is output and compilation is refused.

[0109] (6) Complexity limit verification The complexity of the DSL is checked to see if it exceeds the system's configured limit. The verification rules are as follows: the number of WHERE conditions does not exceed maxConditions (the default value in this embodiment is 20); the number of JOINs does not exceed maxJoins (the default value in this embodiment is 3); the number of GROUP BY fields does not exceed maxGroupByFields (the default value in this embodiment is 5); and the LIMIT value does not exceed maxLimit (the default value in this embodiment is 1000). If the user request does not specify LIMIT and the system configuration requiresLimit=true, the default LIMIT value is automatically injected. If an over-limit is detected, an error message is output, and compilation is refused.

[0110] In some optional implementations, the thresholds of maxConditions, maxJoins, maxGroupByFields, and maxLimit can be dynamically configured and adjusted according to the needs of database performance and business query scenarios.

[0111] S8: Compiles into parameterized SQL.

[0112] Upon successful initial verification, the restricted DSL is compiled into a parameterized SQL statement, and a set of bind variables corresponding to the parameterized SQL statement is generated. In this embodiment, the compilation process strictly preserves the structure and position of the governance predicate node, without changing its form in the top-level WHERE conjunctive domain.

[0113] refer to Figure 6 After S8 is completed, the parameterized SQL statement is parsed to obtain the SQL Abstract Syntax Tree (SQLAST). Using the same rules as steps a to f, predicate nodes are collected from the top-level WHERE conjunctive domain of the SQLAST, sorted for deduplication, normalized serialization is performed, and SHA is calculated. The 256-bit digest hash value yields H2.

[0114] S9: Perform the second verification.

[0115] A second validation is performed on the SQL AST. If the second validation fails, the parameterized SQL statement is rejected and a validation failure message is output. (See reference...) Figure 5 As shown, the second verification includes at least the following: (1) Governance of predicate matching verification Verify that the top-level WHERE conjunctive field of the SQL abstract syntax tree contains tenant_id=:tenant_param for the anchor table and deleted_at IS NULL for the anchor table; if either governance predicate is missing, output an error message and refuse execution.

[0116] (2) Re-verification of predicate morphology Confirm that tenant_id and deleted_at do not appear under the function call node or arithmetic expression node; if a morphological abnormality is detected, output an error message and refuse to execute.

[0117] (3) Verification of consistency of governance strategy versions Verify that the governance policy version number corresponding to the governance predicate in the SQL AST is completely consistent with the governance policy version number locked in step S5; if the version number does not match, determine that the source of the governance predicate is abnormal, output error information, and refuse to execute.

[0118] (4) Re-validation of GROUP BY and ORDER BY Verify that the GROUP BY and ORDER BY clauses only reference the anchor table fields or aggregation results; if an out-of-bounds reference is detected, output an error message and refuse to execute.

[0119] (5) Digest hash consistency check Compare the calculated H2 with the previously obtained H1. If H1 and H2 are equal, it indicates that during the conversion from DSL abstract syntax tree to SQL abstract syntax tree, the set, order, column reference, operators, operand types and operand values ​​of all governance predicates have not changed. If H1 and H2 are not equal, it is determined that the governance predicate has been tampered with during compilation or query rewriting. At this time, execution is refused and a consistency check failure message is output, and the event is written to the audit log.

[0120] In an optional implementation of this embodiment, when the user request does not specify LIMIT, a LIMIT node with the maximum number of returned rows is forcibly injected into the DSL AST, and the existence of the LIMIT node is verified in the second verification.

[0121] S10: Execute securely and generate audit logs.

[0122] Upon successful completion of the second verification, the parameterized SQL statement is executed using parameter binding, an audit log is generated, and the query results are returned. The audit log includes at least the governance policy version identifier, the governance predicate summary, and the results of the first and second verifications. In this embodiment, using parameter binding to execute SQL effectively avoids the risk of SQL injection.

[0123] Example 2 This embodiment provides a governance-constrained controlled query system based on semantic center. The system is a functional module architecture that implements the method described in Embodiment 1, referring to... Figure 7 As shown, the system includes a semantic center module, a DSL generation module, a governance injection module, a first verification module, a compilation module, a second verification module, and an execution and auditing module.

[0124] The semantic center module is used to store and manage whitelist information, governance strategies, semantic entities, query templates, anchor table configurations, and entity associations. The semantic center module is also used to perform multi-strategy cascade matching of natural language query requests with query templates and entity identifiers, and output the matching results and anchor table identifiers.

[0125] The DSL generation module is used to convert natural language query requests into DSLs that satisfy restricted syntax constraints (restricted DSLs). The DSL generation module has a built-in large language model calling unit, which is used to generate multiple candidate restricted DSLs based on the semantic context information injected by the semantic center module, and output the candidate restricted DSLs to the first verification module for verification.

[0126] The governance injection module is used to forcibly add and mark as an irremovable governance predicate node in the top-level WHERE conjunctive domain of the abstract syntax tree (AST) corresponding to the restricted DSL; the governance injection module has a built-in hash calculation unit, which is used to calculate the digest hash value H1 of the subtree of the governance predicate node according to the normalized serialization rules.

[0127] The first verification module is used to perform verification on the DSL AST after the injection of governance predicates, including verification of the existence, position, and form of the governance predicates, as well as whitelist verification, GROUP BY and ORDER BY reference range verification, and complexity limit verification. When the verification fails, the first verification module refuses to generate an executable query and outputs verification failure information. When the verification passes, the first verification module outputs the DSL AST to the compilation module.

[0128] The compilation module is used to compile the restricted DSL into a parameterized SQL statement when the first verification passes, and to generate a set of bind variables corresponding to the parameterized SQL statement.

[0129] The second verification module is used to perform governance predicate matching verification, governance strategy version consistency verification, and digest hash consistency verification on the SQL abstract syntax tree obtained by parsing the parameterized SQL statement. The second verification module has a built-in hash verification unit, which is used to calculate the digest hash value H2 of the governance predicate subtree in the SQL AST and compare the consistency between H1 and H2. When the verification fails, the second verification module refuses to execute the parameterized SQL statement and outputs the verification failure information. When the verification passes, the parameterized SQL statement and the set of bind variables are output to the execution and auditing module.

[0130] The execution and auditing module is used to execute the parameterized SQL statement using parameter binding and generate an audit record when the second verification passes; the execution and auditing module is also used to return the query results to the user.

[0131] The system in this embodiment has the same implementation principle and technical effect as the method in Embodiment 1, and will not be repeated here.

[0132] Example 3 This embodiment provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the governance constraint-controlled query method based on semantic center as described in Embodiment 1.

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

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

[0135] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

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

Claims

1. A governance-constrained controlled query method based on semantic center, characterized in that, S1. Receive natural language query requests; S2. Based on the whitelist information pre-registered in the semantic center, determine the set of data objects that are allowed to be accessed in this query; the whitelist information includes at least the tables, fields, INNER JOIN relationships, and operator sets that are allowed to be accessed; S3. Convert the natural language query request into a restricted DSL. The restricted DSL is used to describe the SELECT, FROM, INNER JOIN, WHERE, GROUP BY, ORDER BY, and LIMIT clauses of the query, and the restricted DSL satisfies the following restricted syntax constraints: logical expressions only allow AND conjunction, OR and NOT are not supported; subqueries, common table expressions (CTEs), and set operations are not supported; the join type only allows INNER JOIN. S4. Obtain the query template or entity identifier corresponding to the natural language query request from the semantic center, and obtain the pre-specified anchor table identifier based on the query template or entity identifier, wherein the anchor table belongs to the whitelist information; S5. Obtain and lock the governance strategy version corresponding to the data object set from the semantic center. The governance strategy includes at least a tenant isolation strategy and a soft deletion strategy. S6. In the top-level WHERE conjunctive domain of the abstract syntax tree corresponding to the restricted DSL, a governance predicate node is forcibly added and marked as non-removable. The governance predicate node includes at least a tenant isolation predicate and a soft delete predicate for the anchor table. S7. Perform a first check on the DSL AST after injecting the governance predicate. If the first check fails, refuse to generate an executable query and output the check failure message. The first verification includes at least: verifying that all governance predicate nodes exist and are located in the top-level WHERE conjunctive domain; verifying that the governance predicates satisfy the restricted form, wherein tenant_id and deleted_at cannot be used as function parameters and cannot participate in arithmetic expressions; verifying that the tables, fields, INNER JOIN relationships, and operators referenced in the DSL all belong to the whitelist information; and verifying that the GROUP BY and ORDER BY only reference the anchor table fields or aggregation results, and do not reference non-anchor table fields. S8. When the first verification passes, the restricted DSL is compiled into a parameterized SQL statement, and a set of bind variables corresponding to the parameterized SQL statement is generated. S9. Parse the parameterized SQL statement to obtain an SQL abstract syntax tree, and perform a second verification. If the second verification fails, refuse to execute the parameterized SQL statement and output a verification failure message. The second verification includes at least: verifying that the top-level WHERE conjoint field of the SQL abstract syntax tree contains tenant_id = :tenant_param for the anchor table and deleted_at IS NULL for the anchor table; verifying that the governance predicate is consistent with the version of the locking governance strategy; and verifying that the GROUP BY and ORDER BY only reference fields from the anchor table or aggregation results. S10. When the second verification passes, the parameterized SQL statement is executed using parameter binding and an audit record is generated. The audit record includes at least the governance policy version identifier, the governance predicate summary, and the results of the first and second verifications.

2. The method according to claim 1, characterized in that, The WHERE clause of the restricted DSL described in step S3 consists only of comparison predicates connected by AND, and bracket structures used to change logical precedence are prohibited.

3. The method according to claim 1, characterized in that, The whitelist information further limits the allowed comparison operators to include only =, !=, <, <=, >, >=, LIKE, ILIKE, IN, NOT IN, IS NULL, IS NOT NULL, and BETWEEN.

4. The method according to claim 1, characterized in that, The whitelist information requires that each INNER JOIN must use the join key pair registered by the semantic center, and the join key pair is an equivalence comparison predicate.

5. The method according to claim 1, characterized in that, The step S3 of converting a natural language query request into a restricted DSL includes: generating multiple candidate restricted DSLs by a large language model based on semantic context information injected by the semantic center, and selecting the candidate restricted DSL that passes the first verification for compilation.

6. The method according to claim 1, characterized in that, The non-removable governance predicate node mentioned in step S6 carries an immutable identifier in the abstract syntax tree, and subsequent rewrite rules are prohibited from deleting, replacing or removing the governance predicate node from the top-level WHERE conjunctive domain.

7. The method according to claim 1, characterized in that, The digest hash value is calculated for the subtree of the governance predicate node according to the normalized serialization rules, and the consistency check is performed on the digest hash value after compiling the parameterized SQL statement.

8. The method according to claim 1, characterized in that, The second verification in step S9 further includes: after parsing the parameterized SQL statement into an SQL abstract syntax tree, confirming that tenant_id and deleted_at do not appear under the function call node or arithmetic expression node.

9. The method according to claim 1, characterized in that, When the user request does not specify LIMIT, a LIMIT node with the maximum number of returned rows is forcibly injected into the restricted DSL abstract syntax tree, and the existence of the LIMIT node is verified in the second check.

10. The method according to claim 1, characterized in that, The complete syntax rules of the restricted DSL are defined in BNF normal form, where: SelectStmt consists of SelectClause, FromClause, optional JoinList, optional WhereClause, optional GroupByClause, optional OrderByClause, and optional LimitClause; WhereClause is defined as WHERE followed by AndList, and AndList is composed of Predicates connected by AND; Predicate supports comparison predicates, IS NULL, IS NOT NULL, IN, NOT IN, BETWEEN, LIKE, and ILIKE forms; prohibited keywords include OR, NOT, EXISTS, ANY, ALL, SOME, UNION, INTERSECT, EXCEPT, WITH, HAVING, CASE, WHEN, LEFT, RIGHT, OUTER, FULL, CROSS, and NATURAL.

11. A governance-constrained controlled query system based on semantic center, characterized in that, include: The semantic center module is used to store and manage whitelist information, governance strategies, semantic entities, query templates, anchor table configurations, and entity relationships. The DSL generation module is used to convert natural language query requests into DSLs that meet restricted syntax constraints. The governance injection module is used to forcibly add and mark as non-removable governance predicate nodes in the top-level WHERE conjunctive domain of the abstract syntax tree corresponding to the restricted DSL; The first verification module is used to perform verification of the existence, position, and form of the governance predicates, as well as whitelist verification, on the DSL abstract syntax tree after the governance predicates are injected. The compilation module is used to compile the restricted DSL into parameterized SQL statements when the first verification passes; The second verification module is used to perform governance predicate matching verification, governance strategy version consistency verification, and digest hash consistency verification on the SQL abstract syntax tree obtained by parsing the parameterized SQL statement. The execution and auditing module is used to execute the parameterized SQL statement using parameter binding and generate audit records when the second verification passes.

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

Images