Data query statement dynamic generation method and device, equipment and medium

Abstract

The invention relates to the technical field of data query, can be applied to business scenes such as financial science and technology and medical health, and discloses a data query statement dynamic generation method and device, equipment and a medium, and the method comprises the steps: receiving query request information, matching business strategies, completing conflict resolution, and generating a target business strategy set; obtaining dynamic context information formed by a database structure, an index, statistical information and a system load; and generating an initial data query statement based on the target business strategy set, the dynamic context information and the query request information, and obtaining an executable data query statement through grammar verification, logic optimization and execution cost analysis. According to the method, service rule analysis, conflict resolution and environment perception are combined, so that the query statement generation process can be adaptively adjusted along with the change of the service rules and the change of the running state of the database, and the accuracy and execution efficiency of query statement generation are improved while the correctness of service logic is kept.

Description

Technical Field

[0001] This invention relates to the field of data query technology, and in particular to a method, apparatus, device, and medium for dynamically generating data query statements. Background Technology

[0002] In the field of intelligent data querying, business systems typically need to automatically generate structured data query statements based on user requests to support complex data analysis, statistical calculations, and operational decisions. However, existing technologies still have many shortcomings in practical applications, especially in dealing with dynamically changing rules, diverse business scenarios, and differences in database environments, lacking stable and efficient processing capabilities.

[0003] In the fintech business, data queries often involve tasks such as transaction behavior analysis, risk assessment, user segmentation, and accounting statistics. These queries typically require the simultaneous application of multiple business logics, such as compliance verification logic, data access control logic, transaction calculation logic, and indicator statistical logic. Current technologies generally hard-code these rules directly into the code, resulting in a high degree of coupling between business rules and code. Once financial institutions adjust their business practices—for example, by changing indicator calculation methods, customer classification rules, or access control policies—the system must be modified and redeployed, leading to insufficient response time. Furthermore, when multiple rules work together on the same query, existing systems lack a unified conflict identification and coordination mechanism, easily resulting in problems such as conflicting rule coverage relationships, contradictory logical meanings, or inconsistent processing results, thus affecting the accuracy and stability of business data analysis.

[0004] In the healthcare sector, data queries are frequently used for scenarios such as patient visit behavior statistics, structured medical record analysis, follow-up system management, and high-risk population identification. Due to the complexity and frequent updates of healthcare business rules—such as adjustments to diagnostic grouping methods, changes in timeframes, and changes in medical insurance review rules—hard-coded solutions are ill-suited to adapt. More importantly, the structure of healthcare data varies significantly across different systems; database index configuration, data distribution characteristics, and real-time load can all affect query execution efficiency. Existing technologies fail to perceive the dynamic state of the database environment, relying solely on static templates to generate query statements. This prevents the generated results from being adjusted according to actual system load, data distribution, or index conditions, leading to decreased execution performance and even response delays under high load, thus impacting the real-time requirements of healthcare operations. Summary of the Invention

[0005] The main objective of this invention is to provide a method, apparatus, device, and storage medium for dynamically generating data query statements, aiming to solve the technical problem that existing technologies cannot generate usable and efficient data query statements under conditions of dynamic changes in business rules and real-time changes in the database operating environment.

[0006] To achieve the above objectives, the present invention provides a method for dynamically generating data query statements, comprising: Receive data query request information containing query metrics, query dimensions, and filter conditions; Based on the data query request information, atomic business strategies and composite business strategies are matched from the preset business strategy library; Logical conflict detection is performed on the atomic business strategy and the composite business strategy, and the conflict is resolved according to the preset priority resolution strategy to generate a target business strategy set. Obtain dynamic context information; Based on the target business strategy set, the dynamic context information, and the data query request information, a matching query template is selected from the preset query template library and mapped and filled to generate an initial data query statement; Based on the dynamic context information, the initial data query statement is subjected to syntax validation, logic optimization, and execution cost analysis to generate an executable data query statement.

[0007] Furthermore, to achieve the above objectives, the present invention provides a data query statement dynamic generation device, comprising: The data request parsing module is used to receive data query request information containing query metrics, query dimensions, and filter conditions. The business strategy matching module is used to match atomic business strategies and composite business strategies from a preset business strategy library based on the data query request information. The strategy conflict resolution module is used to perform logical conflict detection on the atomic business strategy and the composite business strategy, and to resolve the conflict according to the preset priority resolution strategy to generate a target business strategy set. The context acquisition module is used to obtain dynamic context information; The template instantiation module is used to select a matching query template from a preset query template library and map and fill it based on the target business strategy set, the dynamic context information and the data query request information to generate an initial data query statement. The query optimization module is used to perform syntax validation, logic optimization, and execution cost analysis on the initial data query statement based on the dynamic context information, and generate an executable data query statement.

[0008] Furthermore, to achieve the above objectives, the present invention also provides a computer device, the computer device including a memory, a processor, and a data query statement dynamic generation program stored in the memory and executable on the processor, wherein when the data query statement dynamic generation program is executed by the processor, it implements the steps of the data query statement dynamic generation method as described above.

[0009] Furthermore, to achieve the above objectives, the present invention also provides a non-volatile computer-readable storage medium storing a data query statement dynamic generation program, wherein the data query statement dynamic generation program, when executed by a processor, implements the steps of the data query statement dynamic generation method described above.

[0010] Beneficial Effects: This invention relates to the field of data query technology and can be applied to business scenarios such as fintech and healthcare. It discloses a method, apparatus, device, and medium for dynamically generating data query statements, comprising: receiving data query request information containing query indicators, query dimensions, and filtering conditions; matching atomic and composite business strategies through a business strategy library and resolving conflicts to generate a target business strategy set; collecting database schema information, index information, statistical information, and system load information to form dynamic context information; using the target business strategy set, dynamic context information, and data query request information, selecting query templates from a query template library and completing mapping and filling to generate an initial data query statement; and combining the dynamic context information to perform syntax validation, logic optimization, and execution cost analysis to generate an executable data query statement. This invention combines business rule parsing, conflict resolution, and environment awareness, enabling the query statement generation process to adaptively adjust to changes in business rules and database operating status, thereby improving the accuracy and execution efficiency of query statement generation while maintaining the correctness of business logic. Attached Figure Description

[0011] The present invention will be further described below with reference to the accompanying drawings and embodiments. In the accompanying drawings: Figure 1 This is a schematic diagram of an application environment for a data query statement dynamic generation method according to an embodiment of the present invention; Figure 2 This is a flowchart illustrating an embodiment of the data query statement dynamic generation method of the present invention; Figure 3 This is a schematic diagram of the functional modules of a preferred embodiment of the data query statement dynamic generation device of the present invention; Figure 4 This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention; Figure 5 This is another structural schematic diagram of a computer device according to one embodiment of the present invention. Detailed Implementation

[0012] It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the invention.

[0013] The data query statement dynamic generation method provided in this embodiment of the invention can be applied to, for example... Figure 1In this application environment, the client communicates with the server via a network. The server can receive data query request information containing query metrics, query dimensions, and filtering conditions from the client. It then matches atomic and composite business strategies using a business strategy library and resolves conflicts to generate a target business strategy set. It collects database schema information, index information, statistical information, and system load information to form dynamic context information. Using the target business strategy set, dynamic context information, and data query request information, it selects a query template from a query template library and completes mapping and filling to generate an initial data query statement. Finally, it performs syntax validation, logic optimization, and execution cost analysis based on the dynamic context information to generate an executable data query statement. This invention combines business rule parsing, conflict resolution, and environment awareness, enabling the query statement generation process to adaptively adjust to changes in business rules and database operating status, thereby improving the accuracy and execution efficiency of query statement generation while maintaining the correctness of business logic. The client can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The server can be implemented using a standalone server or a server cluster consisting of multiple servers. The following detailed description of specific embodiments further illustrates this invention.

[0014] Please see Figure 2 , Figure 2 This is a flowchart illustrating an embodiment of the data query statement dynamic generation method provided by the present invention. It should be noted that although the logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than that shown here.

[0015] like Figure 2 As shown, the method for dynamically generating data query statements proposed in this invention includes the following steps: S10, Receive data query request information containing query indicators, query dimensions and filtering conditions; In this embodiment, when receiving a data query request containing query metrics, query dimensions, and filtering conditions, a communication channel to an external system needs to be established first, such as a network interface to a front-end page, business middleware, or third-party service. The original query request is received through this interface. The original query request carries a structured data payload, which includes query metric fields representing statistical objectives, query dimension fields representing grouping or slicing dimensions, and filtering condition fields defining the data range. After receiving the original query request, the receiving module initiates a parsing process, performing syntactic decomposition on the data payload according to a preset data format protocol. Different fields are extracted from a unified carrier and mapped to a set of query metrics, a set of query dimensions, and a set of filtering conditions, respectively. The parsed field names, field types, and field values ​​need to be compared with a metadata dictionary. The metadata dictionary records the names, type definitions, and allowed value ranges of available business fields. This comparison determines whether the query metrics point to statistically significant fields, whether the query dimensions are suitable as grouping criteria, and whether the comparison operations of the filtering conditions match the field types. When the parsing and comparison are all successful, the input content is encapsulated into a unified data query request information object. This object internally stores the query indicator list, query dimension list, and filter condition expression in a structured form, forming a standardized input unit that can be directly used in subsequent processing steps.

[0016] This embodiment filters out requests with missing fields, mismatched types, or abnormal conditions during the input stage by uniformly parsing, comparing metadata, and encapsulating the query metrics, query dimensions, and filtering conditions in the original query request. It retains only data query request information with clear semantics and valid fields, thereby providing a stable and consistent input foundation for subsequent data processing and reducing the interference of abnormal requests on the overall query chain.

[0017] S20, Match atomic business strategies and composite business strategies from a preset business strategy library based on the data query request information; In this embodiment, when matching atomic and composite business strategies from a pre-defined business strategy library based on data query request information, the system first needs to perform structural parsing on the data query request information. This involves converting the query metrics, query dimensions, and filtering conditions, which have already been standardized in the previous step, into an internal representation that is easy to retrieve. This representation can be a set of field names, a set of semantic tags, or a mapping table from fields to their business meanings. The pre-defined business strategy library stores multiple business strategies. Each business strategy is associated with a set of triggering conditions, applicable scenario markers, and output action definitions. Triggering conditions are typically described in the form of "query metric combination," "query dimension combination," "whether the filtering field appears," or "field value range." The strategy library can establish retrieval entry points using field indexes, tag indexes, or inverted indexes. Atomic business strategies are used to express a single, indivisible processing logic, such as the calculation method for a single metric or a single data permission constraint. Composite business strategies are used to express processing logic obtained by combining multiple atomic business strategies through logical operators, such as a joint constraint that simultaneously satisfies multiple conditions or a priority relationship between different strategies. The matching process compares the combination of fields in the data query request information with the effective trigger conditions in the business strategy library. The comparison can be performed based on rules such as complete inclusion of the field name set, field values ​​falling within a predefined range, and consistent scenario labels. When the comparison result meets the trigger conditions of the strategy entry record, the business strategy is added to the matching result set and marked as an atomic business strategy or a composite business strategy according to the structure type of the record inside the business strategy, providing structured business rule input for subsequent conflict detection and template instantiation.

[0018] This embodiment matches data query request information with a preset business strategy library and clearly distinguishes between atomic business strategies and composite business strategies during the matching process. It can flexibly express various business calculation rules and data access constraints in a configuration manner without changing the underlying query assembly logic. This allows query behavior to automatically inherit the latest business definition and provides a clear rule structure input for subsequent conflict resolution and template filling, reducing the maintenance cost and rule update delay caused by hard-coded rules.

[0019] S30, perform logical conflict detection on the atomic business strategy and the composite business strategy, and resolve the conflict according to the preset priority resolution strategy to generate a target business strategy set; In this embodiment, during the logical conflict detection process for atomic and composite business strategies, a unified expression structure needs to be constructed for both types of strategies. The condition part is broken down into fields, value ranges, and logical operator combinations, while the control requirements are broken down into action expressions such as data filtering, indicator definitions, or permission restrictions. Atomic business strategies are characterized by simple conditions and concentrated constraints; composite business strategies are formed by logically combining multiple strategies, resulting in a wider scope and more complex internal structure. To determine whether there is a contradiction between the two types of strategies, a comparison relationship needs to be established based on the data object range covered by the strategy. Strategies acting on the same field combination or the same value range are grouped into one analysis unit, and conflicts are identified by comparing whether the action expressions are opposite and whether mutually exclusive constraints are generated. For example, if one strategy requires retaining a certain data range, and another strategy requires excluding the same range, a conflict exists.

[0020] When performing priority-driven conflict resolution, priority information needs to be matched to each policy based on preset priority rules. These rules can be configured according to the importance of different policy types; for example, security control policies can be defined as more important than business computing policies. When a conflict occurs, the priorities of policies within the same analysis unit are compared to determine which policies should be retained. Policies with lower priority are marked as not participating in subsequent processing, thus forming a set of business rules free of logical contradictions. The result of conflict resolution is the filtering and adjustment of the policy set, ensuring consistency in the applicability of each policy and avoiding contradictory or incompatible requirements for the same data object.

[0021] This embodiment detects logical conflicts between atomic and composite business strategies and resolves them using priority rules. This ensures that the final set of strategies remains consistent within the same data object scope, preventing contradictory rules from interfering with subsequent processing. It helps reduce manual review costs and improves the stability of rule application.

[0022] S40, Obtain dynamic context information; In this embodiment, the process of obtaining dynamic context information requires constructing a set of environment information reflecting the database structure, index configuration, data size distribution, and operational status around the data query execution environment. The data table schema definition information in the dynamic context information comes from the database metadata system. It reads structured descriptions such as table names, field names, field types, and constraints through system-level interfaces to reflect the data organization method. Primary and foreign key constraints are obtained by analyzing the relationship definitions in the metadata and are used to identify cross-table join paths and dependencies between fields. The index field list and index type attributes come from the database index configuration dictionary. By reading information such as index names, associated fields, and index categories, it reflects the acceleration structures available for the current query. The numerical distribution histogram data and the estimated number of rows in the data table come from the data statistics view maintained by the database. The statistics module generates distribution information on field value ranges and frequencies and provides table-level size estimations to assist in determining the filtering ratio of the filtering conditions. Real-time system load indicators are obtained by calling the operation monitoring interface, including current CPU usage, memory usage, storage IOPS, and other operational data, to reflect the operational environment pressure during query execution. These structures, indexes, data distributions, and system operating status are integrated to form a dynamic data set that reflects the execution environment, providing an environmental basis for subsequent processing logic.

[0023] The database's system information view can be used to extract table schema definitions and primary / foreign key constraints, and the index list and index type attributes can be loaded through the information architecture interface. The analysis and statistics module can also collect histogram data of field numerical distributions and estimated table row counts, and combine this with the real-time metrics interface of the system monitoring module to obtain the current operating environment's load status. Integration can employ a unified data packaging structure to combine the above information into a set of environment data that can be directly referenced by the query generation module. Furthermore, in scenarios where the database supports extension modules, this information can be cached in a shared memory area to reduce the cost of repeated access.

[0024] This embodiment constructs dynamic context information that includes structural information, index information, data scale distribution, and runtime load, enabling subsequent processing logic to have environmental awareness capabilities and allowing relevant judgments to be completed based on the real-time execution environment, thus ensuring the applicability and efficiency of the generated content.

[0025] S50, based on the target business strategy set, the dynamic context information and the data query request information, select a matching query template from the preset query template library and map and fill it to generate an initial data query statement; In this embodiment, an initial data query statement is generated based on the target business strategy set, dynamic context information, and data query request information. This requires extracting structured features from the query requirements, available resources, and determined strategy requirements, and then matching these features with a pre-defined query template library to complete the statement construction. The target business strategy set provides logical constraints such as aggregation methods, filtering rules, or display structures, which can be extracted from the strategy entries in the set. The query metrics, query dimensions, and filtering conditions in the data query request information express the content requirements requested by the user and consist of structured fields that can be directly mapped to variable placeholders in the query template. The dynamic context information includes a list of indexed fields, data distribution characteristics, and structural constraints, which can be used to determine the order of filtering conditions or the selection of connection structures.

[0026] The query template library is a set of reusable structured templates. Each template uses variable placeholders to indicate different population positions, such as for selecting fields, limiting conditions, join relationships, or sorting rules. During template matching, the applicable template type needs to be identified based on the strategy type in the target business strategy set, such as aggregation templates, detail templates, or multi-table join templates. After template matching is complete, the correspondence between filter conditions and the index field list needs to be analyzed. Priority is determined by calculating the overlap between fields and indexes, and the order of filter conditions is adjusted, placing easier-to-filter conditions at the beginning of the template to improve the executability of the initial data query statement.

[0027] Subsequently, the query metrics, query dimensions, and adjusted filter conditions are mapped to variable placeholders in the query template. During this mapping process, field name normalization, data type validation, and template placeholder structure integrity validation are performed to avoid generating structures that do not conform to database syntax rules. After mapping is complete, the variable placeholders in the template are replaced with specific fields and conditions, forming a complete initial data query statement.

[0028] This embodiment combines business strategies, query requirements, and runtime environment information in the template matching and filling process, enabling the generated initial data query statement to balance the accuracy of business logic, the completeness of user content requirements, and the ability to optimize the executable structure, thereby achieving the construction of a query statement with a reasonable structure and better execution efficiency.

[0029] S60, based on the dynamic context information, perform syntax verification, logic optimization and execution cost analysis on the initial data query statement to generate an executable data query statement.

[0030] In this embodiment, based on dynamic context information, the initial data query statement undergoes syntax validation, logic optimization, and execution cost analysis. This requires parsing the original statement structure into a computable data structure for subsequent verification and reasoning. Syntax validation is accomplished by constructing an abstract syntax tree (AST), which consists of keyword nodes, field nodes, expression nodes, and connection nodes, reflecting the hierarchical structure of the statement. The parsing process requires the introduction of a syntax rule set, which includes field naming conventions, operator usage constraints, and expression validity requirements. Syntax errors are identified by verifying nodes layer by layer, such as missing keywords, undefined fields, or conflicting expression structures. Syntax error correction relies on the correction guidelines in the syntax rule set to replace or supplement the parsed node structure, restoring the AST to a processable state.

[0031] Logical optimization leverages dynamic contextual information about data volume, field distribution characteristics, and index configuration to rewrite the abstract syntax tree. This rewriting includes rearranging filter conditions, removing invalid conditions, merging redundant joins, and replacing equivalent expressions. By calculating the matching relationship between filter fields and the index field list, it identifies the nodes containing highly efficient filtering conditions and prioritizes these nodes. For structures containing multi-table joins, foreign key constraints can be used to adjust the join order, reducing the scan range. Logical optimization can also utilize numerical distribution histogram data to perform equivalent replacements on range expressions, making the expression calculation path shorter or more easily recognized by the database execution engine.

[0032] Execution cost analysis utilizes estimated table row counts, index field characteristics, and real-time system load metrics from dynamic context information to evaluate the execution cost of different rewrite structures using a cost model. The cost model estimates the costs of filtering, joining, and sorting nodes separately, and then comprehensively calculates the cost based on scan cost, filtering cost, join cost, and execution load impact to form a total cost. The results of the execution cost analysis are used to select the abstract syntax tree (AST) with a superior structure. Finally, the selected AST is converted into executable data query statements conforming to database syntax specifications. The conversion process includes node serialization, keyword filling, and expression expansion, restoring the tree structure to a linear text statement.

[0033] This embodiment improves the correctness, stability, and execution performance of the initial data query statement by performing syntax parsing, logical structure rewriting, and cost evaluation, while maintaining the semantics of the statement.

[0034] In one embodiment, step S10 above includes: S101, Establish a data communication interface with the client and receive the original query request sent by the client; S102, parse the original query request and extract the query indicators, query dimensions and filtering conditions; S103, Based on a preset metadata dictionary, verify the existence of the query indicators, the compliance of the query dimensions, and the consistency of the data types of the filtering conditions; S104 encapsulates the verified query metrics, query dimensions, and filtering conditions into data query request information.

[0035] In this embodiment, the system first needs to establish a data communication interface with the client. This data communication interface can be understood as a connection mechanism for transmitting structured or semi-structured request messages between the front-end query tool and the back-end query engine. This mechanism is typically implemented based on application layer protocols in the network protocol stack, such as HTTP-based interfaces, gRPC-based remote call interfaces, or message queue-based asynchronous interfaces. The interface definition needs to specify the encoding format, field names, field types, and error return structure of the request messages so that the client can construct query requests according to a unified format, and the back-end can fully parse and process these requests. In this scenario, the client can be a reporting system, data analysis platform, or business system front-end, generating raw query requests through interface input, template selection, or parameter configuration and sending them to the back-end via the data communication interface.

[0036] Once the original query request reaches the backend, it needs to be structured by the parsing module. The original query request can be a JSON object, a set of form parameters, or a composite expression embedded in natural language. The parsing module needs to convert these different forms of requests into a unified internal representation. This internal representation must distinguish at least three basic categories: query metrics, query dimensions, and filtering conditions. Query metrics typically refer to the measurement fields that need to be calculated or summarized, such as transaction amount, order quantity, drug usage, etc., generally corresponding to numeric or aggregatable fields. Query dimensions represent the perspective for classifying or grouping query results, such as time interval, geographical region, department, product type, etc., corresponding to enumeration fields, hierarchical fields, or key-value fields. Filtering conditions limit the range of data participating in the statistics, such as time interval restrictions, regional restrictions, customer category restrictions, or treatment stage restrictions, corresponding to Boolean expressions, comparison expressions, or set inclusion relationships. The parsing module needs to identify these fields from the original query request and store them into the metric set, dimension set, and condition set respectively, ensuring that subsequent processing can clearly distinguish their different semantic roles.

[0037] After initial parsing, validation needs to be performed using a pre-defined metadata dictionary. The metadata dictionary is a structured repository that provides a unified description of data resources. It records the legal names, data tables, field types, value ranges, business meanings, and constraints related to other fields for each indicator and dimension field. For query indicators, the validation process checks if the indicator name exists in the metadata dictionary, confirming that the indicator has been modeled in the data system and has a calculable definition. It also verifies the matching relationship between aggregation methods and field types, such as allowing summation or average statistics only for numerical indicators. For query dimensions, the validation process checks if the dimension belongs to the set of allowed grouping fields, determines if the dimension has a data source that can be connected to the target indicator, and whether it meets predefined hierarchical structure requirements, such as whether the time dimension supports grouping by day, week, or month. For filtering conditions, it verifies whether the comparison values ​​used in the conditions are consistent with the field types recorded in the metadata dictionary. For example, date fields cannot use string pattern matching operations, the condition values ​​of enumeration fields must be in the valid enumeration set, and numerical fields cannot be compared with text thresholds. This avoids query errors or implicit data truncation caused by type mismatches.

[0038] After the metrics, dimensions, and filtering conditions undergo multi-dimensional validation through the metadata dictionary, these validated contents need to be encapsulated into data query request information. The encapsulation process organizes the scattered sets of metrics, dimensions, and conditions into a unified internal data structure. This structure can include query identifiers, metric lists, dimension lists, condition expression trees, and client-related session information or permission markers. Through this encapsulation, subsequent modules no longer directly process the raw request text. Instead, they perform rule matching, template selection, and subsequent processing based on the validated and clearly structured request information, ensuring semantic stability and structural consistency when the same query is transmitted between different modules.

[0039] This embodiment establishes a unified data communication interface, performs structured parsing on the original query request, and verifies the existence, compliance, and type consistency of query indicators, query dimensions, and filtering conditions based on the metadata dictionary. The verified content is then encapsulated as data query request information. This allows for standardized expression and strict constraints of business intent at the query entry point, thereby reducing the probability of invalid and erroneous queries entering subsequent processing stages, improving the consistency and controllability of indicator and dimension usage, and providing a clear and semantically explicit input foundation for subsequent rule matching and statement generation processes.

[0040] In one embodiment, step S20 above includes: S201, parse the data query request information and extract query indicators and query dimensions; S202, using the query indicators and query dimensions as search conditions, traverse the preset business strategy library and read the pre-configured activation trigger conditions for each business strategy in the business strategy library; S203, logically compare the query metrics and query dimensions with the effective triggering conditions to filter out all candidate business strategies that meet the effective triggering conditions; S204, Identify the logical structure attributes of the candidate service strategies; S205, when the logical structure attribute is characterized as an indivisible single processing logic, the candidate business strategy is determined as an atomic business strategy. S206, when the logical structure attribute is characterized as a combined processing logic containing logical operators, the candidate business strategy is determined as a composite business strategy.

[0041] In this embodiment, the process of matching business strategies based on data query request information first requires extracting query metrics and query dimensions from the already constructed data query request information. The data query request information can be viewed as a structured object output from the preceding processing stage, containing a set of fields for measuring statistical objectives and a set of fields for grouping and displaying or analyzing slices. Query metrics typically correspond to numerical or aggregatable fields, such as transaction amount, number of orders, and drug usage, while query dimensions typically correspond to enumerable or categorical fields, such as region, time granularity, product category, and department category. At this stage, the system reads the metric list and dimension list from the data query request information using pre-defined field positions, key names, or internal field identifiers, and converts them into a set structure that facilitates logical matching, such as a set type or an ordered list structure, providing a foundation for subsequent retrieval and comparison of business strategies.

[0042] A business strategy library is a centralized collection of configurations storing business logic rules. It can be implemented using relational database tables, key-value stores, or a configuration center. Each business strategy, when stored, includes two key fields: a strategy identifier, a strategy description, an applicable business scenario tag, and activation trigger conditions and logical structure attributes. Activation trigger conditions define the conditions under which the business strategy needs to be activated. These can include the set of mandatory query metrics, the set of mandatory query dimensions, allowed or prohibited dimension combinations, and restrictions related to time range, channel type, and user role. Logical structure attributes mark the structural form of the internal logical expression of the strategy, such as whether it contains only a single condition judgment or logical operations between multiple conditions.

[0043] The matching process traverses the business strategy library using query metrics and query dimensions as search criteria. During traversal, computational overhead can be reduced through two levels of filtering: the first level performs a coarse screening based on the applicable scenario tags and query topic tags configured for each strategy, excluding strategies clearly irrelevant to the current query topic; the second level reads the activation trigger conditions for each strategy, checks the inclusion relationship between the set of query metrics and the set of metrics required by the strategy, and checks the intersection, subset, or equality relationship between the set of query dimensions and the set of dimensions required by the strategy. Activation trigger conditions can be stored using structured fields combined with logical operation trees. For example, an atomic condition can be expressed as a triple of field name, comparison operator, and target value, and multiple atomic conditions can be combined into an expression tree using logical operation nodes such as AND, OR, and NOT. During the matching phase, the system maps query metrics and query dimensions to input variables for atomic conditions, performs evaluation operations on this expression tree, and marks the current strategy as a candidate business strategy when the evaluation result is true.

[0044] After obtaining the set of candidate business strategies, it is necessary to identify the logical structure attributes of each candidate strategy. Logical structure attributes can be obtained by analyzing the internal expression tree structure. For strategies containing only a single atomic condition and lacking explicit logical operation nodes, their logical structure can be considered an indivisible single processing logic. These strategies typically apply simple constraints to only one type of indicator or dimension, such as "all monetary indicators are uniformly displayed with two decimal places" or "date dimensions are uniformly converted to natural months." For strategies containing two or more atomic conditions and containing logical operation nodes such as AND, OR, and NOT, their logical structure can be considered a combined processing logic, such as "when the queried indicator is the rate of return and the dimension includes risk level, apply combined constraints, using different calculation methods for different risk levels," or similar composite logic. The system can determine whether a strategy has only a single leaf node and no logical operation nodes by traversing the number of nodes and operation types in the logical expression tree. If so, the logical structure attribute is marked as a single processing logic; if logical operation nodes or multiple leaf nodes exist, it is marked as a combined processing logic containing logical operators.

[0045] Based on logical structure attributes, candidate business strategies are further divided into atomic business strategies and composite business strategies. Atomic business strategies are rules that cannot be logically broken down into smaller rule units but still possess independent business meaning. They typically undertake localized, single-function business constraints, such as the value specification of a single field or the display specification of a single type of indicator. Composite business strategies are rule units composed of multiple logical conditions, often involving indicator combinations, dimension combinations, and contextual conditions simultaneously. They implement grouped control over query behavior, such as controlling both field calculation methods and the display order of field combinations. Through this division, the system can perform conflict detection, priority handling, and combined application of atomic and composite strategies in subsequent processing, thereby making business logic management more refined and structured.

[0046] This embodiment explicitly extracts query metrics and dimensions from data query request information. Using these field sets as the basis for retrieval and judgment, it traverses the business strategy library and evaluates each strategy based on the logical expression constructed by the effective trigger conditions. Then, combined with logical structure attributes, it divides candidate rules into atomic business strategies and composite business strategies. Under the premise that the business logic configuration is completely externalized, it can establish a stable and interpretable mapping relationship between query intent and applicable rules. This allows fine-grained control for a single field and combined control across fields to be accurately identified and classified. This provides a clearly structured rule input for subsequent conflict detection, priority adjudication, and query statement generation, and maintains the consistency and maintainability of query behavior in scenarios where business rules are frequently adjusted.

[0047] In one embodiment, step S30 above includes: S301, parse the data object definition domains under the action of the atomic business strategy and the composite business strategy, and identify multiple competing business strategies that have logical definition differences for the same data object definition domain; S302, Read the preset priority resolution strategy, in which the preset priority resolution strategy is pre-configured with the priority weight sequence of data security type strategy, business processing type strategy and performance optimization type strategy; S303, Based on the priority weight sequence, determine the priority weight value corresponding to each of the competitive business strategies; S304, compare the priority weight values ​​of the multiple competitive business strategies to determine the maximum priority weight value among the multiple competitive business strategies; S305, retain the competing business strategy with the maximum priority weight value, and eliminate the competing business strategy whose priority weight value is numerically less than the maximum priority weight value. S306, summarize the competitive business strategies that are retained after the elimination operation, along with the atomic and composite business strategies that are not identified as competitive business strategies, to generate a target business strategy set.

[0048] In this embodiment, when performing logical conflict detection on atomic and composite business strategies, the system first needs to define the data object domain of each business strategy. The data object domain can be understood as a set of target data units constrained by the business strategy, such as a certain indicator field and its bound dimension combination, a set of rows for a type of business record, or a specific set of columns in a detail table. Atomic and composite business strategies typically carry scope information during configuration, such as bound field names, table names, dimension filtering conditions, and business tags. The system maps each strategy to a standardized data object domain representation by parsing the field references, constraints, and target table identifiers in the strategy configuration. This representation can be stored using a triple structure of "target table identifier + field set + dimension constraint" for subsequent comparison of the scope of different strategies.

[0049] After obtaining the data object definition domain corresponding to each strategy, it is necessary to identify multiple competing business strategies that have logical definition differences for the same data object definition domain. Competing business strategies refer to multiple strategies that provide inconsistent rule descriptions for the same data object under the premise of the same or highly overlapping scope of action. For example, different value range restrictions for the same field, different calculation methods for the same indicator, and contradictory filtering conditions for the same dimension. The system can quickly determine whether two strategies point to the same data object definition domain by normalizing the data object definition domain and sorting or hashing the field set and dimension constraints. After determining that the scope of action is consistent, the system further compares the logical expressions inside the strategies, including comparison operator types, threshold ranges, aggregation methods, and combinations of filtering conditions. Once incompatible relationships are detected in the rules on the same field or the same indicator, these strategies are grouped into the same set of competing business strategies.

[0050] After identifying the set of competing business strategies, a pre-defined priority resolution strategy needs to be introduced to uniformly manage the priority of different types of strategies in conflict scenarios. The priority resolution strategy can be stored in a separate configuration table or strategy center, which pre-configures priority weight sequences for three types of strategies: data security strategies, business processing strategies, and performance optimization strategies. Data security strategies typically cover rules such as access control, data masking, and compliance filtering; business processing strategies cover calculation scope, scope switching, and business segmentation rules; and performance optimization strategies cover index usage preferences, pagination granularity, and pre-aggregation selection. The priority weight sequence can be expressed using integer weights, segmented weights, or multi-level weights. For example, the highest weight range can be configured for data security strategies, the middle weight range for business processing strategies, and relatively lower weights for performance optimization strategies. Furthermore, different sub-weights can be set within each type based on the importance of the strategy.

[0051] After establishing the priority resolution strategy, the system determines the corresponding priority weight value for each competing business strategy. In implementation, strategies can first be categorized into data security, business processing, or performance optimization types based on the type identifier in the strategy configuration. Then, a base weight value is assigned to each strategy according to the mapping relationship of that type in the priority weight sequence. If there are sub-levels within the same type, such as "mandatory security policy" and "suggestive security policy," a fine-tuning weight can be added to the base weight value to form the final priority weight value. The system stores these weight values ​​along with the identifiers of the competing business strategies in a memory structure, providing input for subsequent numerical comparisons.

[0052] When comparing the priority weights of multiple competing business strategies, a simple maximum value selection logic can be used, or a equivalence processing strategy can be added on top of that. The most basic implementation is to scan the current set of competing business strategies, record the highest priority weight value encountered, and simultaneously update the strategy set corresponding to that weight value. After the scan is complete, the highest priority weight value existing in this conflict group is obtained. If the implementation allows multiple strategies with identical weights, multiple strategies can be retained in the strategy set corresponding to the highest priority weight value to support secondary judgment in subsequent stages, such as further differentiation by combining specific scenario tags or manual approval parameters.

[0053] After priority comparison, the system performs conflict resolution based on the highest priority weight value. Competing business strategies with a weight value equal to the highest priority weight value are retained. Competing business strategies with a weight value less than the highest priority weight value are marked as pending elimination and removed from the candidate set for subsequent combination. During the elimination process, the identifier of the eliminated strategy and the reason for its overriding can be recorded for auditing or subsequent debugging. In this way, only the highest priority set of rules is retained within the same data object definition domain, avoiding contradictory logical fragments when generating data query statements.

[0054] After eliminating competing business strategies for each group, the system needs to construct a target business strategy set. This set consists of two parts: one category comprises the competing business strategies retained after elimination operations across each data object domain; the other category includes atomic and composite business strategies that were never identified as competing strategies. In implementation, the system can distinguish between strategies that "participated in conflict resolution and were retained" and those that "did not participate in conflict resolution" using a unified flag field, and then add these two types of strategies to the output set in the same scan. The final target business strategy set is a set of mutually consistent rules across each data object domain, which can be directly used for subsequent data query template selection and field logic assembly.

[0055] Through the above steps, this embodiment can form a unique set of effective rules for the same query object in scenarios where multiple data security control rules, business calculation rules, and performance optimization rules coexist. This avoids situations where data permission restrictions, calculation methods, and performance optimizations overlap or cancel each other out, allowing subsequent query construction to run on a set of business rules without internal contradictions. This improves the controllability of rule management and the consistency of generated query logic.

[0056] In one embodiment, step S40 above includes: S401, Establish a management interaction connection with the target database, and read the data table schema definition information and primary and foreign key constraint relationships of the target database; S402, retrieve the index configuration dictionary of the target database, and extract the list of index fields that are currently in effect and their corresponding index type attributes; S403, query the data statistics view of the target database to obtain the histogram data of the numerical distribution of the target data field and the estimated value of the number of rows in the data table; S404, Call the system operation monitoring interface to collect real-time system load indicators of the processing environment running the target database; S405, integrate and encapsulate the data table schema definition information, the primary and foreign key constraints, the index field list, the index type attribute, the numerical distribution histogram data, the estimated number of rows in the data table, and the real-time system load index to generate dynamic context information.

[0057] In this embodiment, the process of obtaining dynamic context information first requires establishing a management interaction connection with the target database. The target database can be a relational database system or a data management system with a similar metadata management mechanism. The management interaction connection differs from ordinary business read / write connections; its connection account typically has permissions to access the data dictionary, statistical views, and runtime status views. This can be implemented by establishing a long-lived connection or a connection pool through a database driver, configuring the connection address, port, authentication credentials, and connection timeout parameters. After the connection is established, a handshake verification is performed to confirm access to the system-level metadata view and statistical information view, providing a channel for subsequent unified retrieval of structure information and runtime status information.

[0058] Assuming the management interaction connection is available, it is necessary to retrieve the data table schema definition information and primary and foreign key constraints from the target database. Data table schema definition information typically comes from the system data dictionary or information architecture view, including field attributes such as table name, field name, field data type, length, precision, decimal places, whether nullables are allowed, default value, and schema. In implementation, query conditions can be constructed based on the database name and table name combination, and a query can be initiated against the system data dictionary view. The returned results are then converted into a structured set of field descriptions and categorized by table. Primary and foreign key constraints are generally obtained through constraint views or key-value views, including the primary key field combinations for each table, the target table and target fields referenced by foreign keys, and cascading rules for updates and deletions. By uniformly parsing this constraint information, a complete structural foundation can be provided for subsequent data dependency analysis, join path generation, and constraint checks.

[0059] After understanding the table structure and constraints, it's necessary to retrieve the target database's index configuration dictionary to extract the list of currently active index fields and their corresponding index type attributes. The index configuration dictionary typically exists as a system index view, recording information such as index name, table, included fields, index order, uniqueness, clustering, and storage structure type. In implementation, this can be achieved by filtering indexes marked as invalid or unavailable, retaining only records that are active, and breaking down each index record into a table-level list of index fields. Index type attributes can include structure types such as B-trees, bitmaps, hashes, and full-text indexes, as well as combinations like single-column or composite indexes, and sorting attributes such as ascending or descending order. By organizing the list of index fields and index type attributes, a mapping relationship between fields and available indexes can be constructed, providing a foundation for subsequently determining whether a filter condition can hit the index.

[0060] After obtaining the structure and index information, it is necessary to query the data statistics view of the target database to obtain the histogram data of the numerical distribution of the target data fields and the estimated number of rows in the data table. The data statistics view is usually maintained by the database optimization component, recording the estimated number of rows and data pages for each table, as well as the numerical distribution statistics generated for some important fields. The numerical distribution histogram data can express the frequency of a field in different value intervals in the form of interval boundaries plus frequency, or it can record high-frequency values ​​by adding discrete values ​​to frequency. The estimated number of rows in the data table reflects the number of records in the current table at the time of statistics. In implementation, based on the list of target data fields of business interest, the corresponding field statistics records in the statistics view can be queried, and the raw histogram data can be converted into a structure suitable for subsequent calculations, such as an array or key-value mapping, with accompanying metadata such as statistical timestamps and sampled row counts, in order to determine the freshness and reliability of the statistical data. These statistical data can support cost estimation and scanning strategy judgment based on selectivity.

[0061] In addition to the internal database views, it's necessary to call the system monitoring interface to collect real-time system load metrics of the processing environment running the target database. The processing environment can include the physical host, virtual machine, or container cluster hosting the database service. System load metrics can cover CPU utilization, memory usage, disk I / O throughput, disk I / O latency, network bandwidth usage, and the number of active sessions. These metrics can be obtained through various paths, such as calling interfaces provided by the operating system monitoring agent, accessing the database's built-in performance views, or connecting to the metric query interface of an external monitoring platform. During the collection process, it's crucial to control the sampling frequency and time window to avoid additional load on the production environment. Furthermore, each collection result should be appended with the collection time point and sampling interval information to facilitate subsequent assessment of whether these metrics are sufficiently close to the query construction time.

[0062] After acquiring all the aforementioned information, it is necessary to integrate and encapsulate the data table schema definition information, primary and foreign key constraints, index field list, index type attributes, numerical distribution histogram data, estimated table row count, and real-time system load metrics to generate dynamic context information. This integration and encapsulation can be accomplished by constructing a unified data structure. For example, using the target database identifier as the top-level key, substructures can be created for each table. At the table level, the field definition set, primary and foreign key relationship set, and index configuration set can be attached. For the field level structure, the corresponding numerical distribution histogram data and statistical information can be attached. At the global level, the real-time system load metrics and acquisition time of the current processing environment can be stored separately. During integration, it is necessary to maintain the association between information from different sources. For example, field references in the index field list should be bound to the field definition structure, and foreign key references should be bound to the referenced table structure. The final dynamic context information is saved in a unified format and can be cached in memory or written to dedicated storage to support subsequent processes that quickly retrieve the structural, statistical, and load characteristics of the current environment by table, field, and running status.

[0063] Through the above steps, this embodiment can simultaneously reflect the logical structure characteristics, physical index structure, data distribution characteristics, and operating environment load status of the current database within a single data structure. This provides continuous, consistent, and near-real-time context input for subsequent processing such as data query construction, adjustment, and cost evaluation. Thus, without changes to business rules and query templates, the query behavior can be adaptively adjusted solely by changes in environmental information, which is beneficial for improving the sensitivity and adaptability of the query execution process to structural and load changes.

[0064] In one embodiment, step S50 above includes: S501, Analyze the aggregation processing type in the data query request information, and retrieve a query template that matches the aggregation processing type from the preset query template library. The query template contains variable placeholders. S502, Extract the list of index fields from the dynamic context information; S503, identify the filter condition fields contained in the target business strategy set and the data query request information, and compare the filter condition fields with the index field list; S504, dynamically adjust the order of the filter condition fields according to the comparison results, so as to adjust the filter condition fields existing in the index field list to the preceding position of the variable placeholder filling sequence; S505, the query indicators, query dimensions, and filter condition fields after adjusting the sorting order in the data query request information are mapped and filled into the variable placeholders in the query template to generate the initial data query statement.

[0065] In this embodiment, when generating the initial data query statement using the target business strategy set, dynamic context information, and data query request information, it is first necessary to analyze the aggregation processing type in the data query request information. The aggregation processing type refers to the type of operation used to statistically summarize detailed data during the query process, such as summation, counting, average, maximum, minimum, or percentile. In implementation, this can be achieved by parsing the indicator configuration, expression string, or structured fields in the query request to identify the aggregate function identifier and the set of fields it applies to. These aggregation processing types are then abstracted into unified operation tags to drive the subsequent template retrieval process. The preset query template library uses multiple parameterized query skeletons as basic units. Each query template is bound to one or more aggregation processing types, data source structure characteristics, grouping requirements, and other metadata. Inside the template, variable placeholders mark the positions to be replaced, such as placeholders representing indicator fields, dimension fields, filter clauses, sorting clauses, and grouping clauses. When performing template retrieval, you can use the aggregation processing type as the main search key, and filter the template set by conditions such as whether the query request contains grouping dimensions, whether pagination is required, and whether multiple table joins are required, to select one or more query templates whose syntax structure and operational semantics best match the current query requirements.

[0066] After determining the target query template, the list of indexed fields needs to be extracted from the dynamic context information. The dynamic context information encapsulates the configuration of the target database's currently valid indexes, including the table name associated with each index, field combinations, sorting direction, and index structure type. The list of indexed fields can be constructed as a table-based mapping of field sets, with each table name corresponding to a set of field identifiers that support index access. In implementation, based on the set of data tables involved in the query request, a subset of the indexed fields for the corresponding tables can be selected from the dynamic context information, and these field names or identifiers can be uniformly encoded into the list of indexed fields. This provides a basis for subsequent index hit determination of the filtering criteria fields.

[0067] After obtaining the target query template and index field list, it is necessary to identify the filter condition fields contained in the target business strategy set and data query request information. Filter condition fields are the set of fields that constitute the filtering logic. These include both condition fields directly configured by the user in the query request and additional condition fields introduced by permission rules, data quality rules, or business constraint rules in the target business strategy set. In implementation, the filter condition structure in the query request can be parsed first, extracting the field names involved in the condition expressions and their respective data tables. Then, the business rules in the target business strategy set that match the current query context are traversed, and the fields defined in the rules and their comparison operations are included in the filter condition field set. Through merging and deduplication, a complete list of filter condition fields can be formed, and each field is associated with its source tag so that user conditions and policy conditions can be distinguished later if needed. Subsequently, the filter condition fields are compared with the index field list. The comparison process can be based on the combination key of field name and table name to determine whether each filter condition field appears in the index field set of the corresponding table, and the matching results are recorded, forming a sequence of filter condition fields with index hit tags.

[0068] After obtaining the sequence of filter condition fields marked with index hits, the order of these fields needs to be dynamically adjusted based on the comparison results. Relational databases often refer to the matching between the condition order and the index structure during the parsing and optimization phases of query execution. The position of fields in the condition list that can hit the prefix of a composite index affects the execution plan selection. In implementation, filter condition fields can be divided into two categories: fields with matching records in the index field list and unmatched fields. Within the index-hit fields, further sorting can be performed based on the field order in the composite index or the index selection degree, for example, prioritizing fields that are the first column of the composite index or fields with high selection degree. After internal sorting, the index-hit field sequence is placed before the variable placeholder fill sequence, and the non-index field sequence is appended after it, resulting in the rearranged filter condition field sequence. The variable placeholder fill sequence indicates the order in which condition expressions are filled in the query template. When the prefix position is occupied by fields supported by an index, it is more beneficial for the database optimizer to generate an execution plan that utilizes the index.

[0069] After adjusting the order of the filter criteria fields, the query metrics, query dimensions, and the adjusted filter criteria fields from the data query request information need to be mapped and populated into the variable placeholders within the query template to generate the initial data query statement. Query metrics refer to statistical result fields that users or upper-level business expect to calculate, such as total revenue or order quantity, and can be bound one-to-one with placeholders in the template used for aggregation fields and expressions. Query dimensions refer to categorization fields used for grouping or slice analysis, such as time segments, customer categories, and region identifiers, and can be mapped to grouping clauses and selection list placeholders in the template. The adjusted filter criteria fields are used to populate placeholders in the template used to construct filter clauses. During population, comparison operators and value placeholders can be introduced simultaneously to form complete conditional expression fragments. The mapping and population process can be driven by a parameter mapping table, binding each placeholder identifier to the corresponding field name, operator, and parameter. Then, the template rendering engine replaces the placeholders with specific field references and calculation expressions, generating an initial data query statement in text form that conforms to database syntax specifications. The initial data query statement structurally reflects the additional filtering logic introduced by the target business strategy set, the field sorting reflects the influence of the index configuration in the dynamic context information, and the aggregation and grouping expressions meet the requirements of the aggregation processing type and dimension configuration in the data query request information.

[0070] This embodiment utilizes the target business strategy set, dynamic context information, and data query request information in the process of query template selection and mapping. It matches the aggregation processing type with the template structure in the query template library, extracts the index field list from the dynamic context information, and performs index hit comparison and order reordering on the filter condition fields accordingly. Then, it maps and fills the query indicators, query dimensions, and rearranged filter condition fields into the variable placeholders of the template to generate the initial data query statement. This achieves the unified integration of business rules, environment structure information, and query requirements in the statement construction stage without changing the business configuration entry point. The generated initial data query statement can accurately reflect the business strategy constraints and adapt to the current index configuration at the condition arrangement level, thereby improving the space for subsequent execution plan optimization and reducing the requirement for manual rewriting of query statements.

[0071] In one embodiment, step S60 above includes: S601, perform syntax parsing on the initial data query statement to generate an abstract syntax tree structure; S602, verify the grammatical correctness of the abstract syntax tree structure, correct the grammatical errors found during the grammatical correctness verification, and generate a grammatically correct abstract syntax tree structure. S603, based on the dynamic context information, apply logic optimization to rewrite and optimize the grammatically correct abstract syntax tree structure to generate an optimized abstract syntax tree structure; S604, using the numerical distribution histogram data, the estimated number of rows in the data table, and the real-time system load index in the dynamic context information, perform a cost analysis on the optimized abstract syntax tree structure; S605, Select the optimal abstract syntax tree structure based on the cost analysis results, and convert the optimal abstract syntax tree structure into an executable data query statement that conforms to the target database syntax specification.

[0072] In this embodiment, the process of performing syntax validation, logic optimization, and execution cost analysis on the initial data query statement using dynamic context information first requires performing syntax parsing on the initial data query statement to convert the textual query expression into an abstract syntax tree structure. The syntax parsing process can be implemented based on a lexical analyzer and a parser built according to the target database's syntax specifications. The lexical analyzer breaks down the query text into basic symbols such as keywords, identifiers, operators, and delimiters. Then, the parser derives a tree structure according to the query statement's syntax rules, mapping information such as selection lists, source tables, join conditions, grouping conditions, filtering conditions, and sorting conditions to nodes and hierarchical relationships in the abstract syntax tree structure. The abstract syntax tree structure is used as an intermediate representation of the query statement in this process, providing a structured view for subsequent syntax correctness verification, logic optimization, and execution cost analysis.

[0073] After obtaining the abstract syntax tree (API) structure, its syntactic correctness needs to be verified. Syntactic errors discovered during verification should be corrected to generate a syntactically correct API structure. Syntactic correctness verification may include checking whether keyword usage conforms to the target database's syntax rules, whether clause combination order meets conventions, whether field references appear in valid positions, and whether there are constraint conflicts between aggregate functions and grouping fields. Detected errors can be corrected using rule bases or automatic repair strategies. For example, automatic completion of missing delimiters, dictionary-based replacement of keyword spelling errors, and adjustment of the select list or grouping list when aggregate functions and grouping fields do not match. The resulting syntactically correct API structure ensures that subsequent logic optimization and execution cost analysis are based on a syntactically valid query representation, preventing syntax errors from being triggered again during the optimization phase.

[0074] Once a grammatically correct abstract syntax tree (AST) structure is formed, it needs to be rewritten and optimized based on dynamic context information to generate an optimized AST structure. The dynamic context information encapsulates table schema definition information, primary and foreign key constraints, index field lists, index type attributes, numerical distribution histogram data, estimated table row counts, and real-time system load metrics. Among these, the table schema definition information, primary and foreign key constraints, and index field lists are directly related to logical optimization. Logical optimization can include predicate pushdown, join order adjustment, redundant condition elimination, subquery rewriting as a join, and converting conditions suitable for index access into index-usable forms. In implementation, equi-join conditions can be identified based on primary and foreign key constraints, and filter conditions that can be pushed down to the subquery or base table level can be moved down the syntax tree. Condition expressions can be adjusted based on the index field list to align condition fields with the index prefix structure. Unnecessary projected fields can be pruned based on the table schema definition information, thereby reducing the number of intermediate result columns. The optimized abstract syntax tree structure remains logically equivalent to the original query, but structurally it is more suitable for combining dynamic context information for execution cost analysis.

[0075] After forming the optimized abstract syntax tree (AST) structure, cost analysis needs to be performed on the optimized AST structure using the numerical distribution histogram data, estimated table row counts, and real-time system load metrics from the dynamic context information. The numerical distribution histogram data reflects the frequency distribution of the target data field across different value ranges, which can be used to estimate the selectivity of filtering conditions. For example, it can estimate the percentage of records meeting the conditions based on the overlap between the condition range and the histogram bins. The estimated table row count provides information on the magnitude of the overall number of records in each table, which can be used to estimate the scale of join results and intermediate results. Real-time system load metrics include information such as the current CPU usage, I / O queue length, and memory usage of the processing environment, which can be used to adjust the relative cost weights of different physical execution strategies at the current moment. During cost analysis, the AST structure can be traversed from top to bottom or bottom to top. For each join node, filter node, and aggregation node, the number of output rows is estimated based on statistical information. Then, based on the operation type and real-time system load metrics, the corresponding estimated execution time or resource consumption is calculated to obtain the cost score of the entire AST structure. If multiple candidate optimized abstract syntax tree structures are generated during the logic optimization phase, cost analysis can be performed on each candidate version separately to provide a basis for selecting the optimal version in the future.

[0076] After obtaining the cost analysis results, the optimal abstract syntax tree (API) structure needs to be selected based on these results, and then converted into an executable data query statement that conforms to the target database's syntax specifications. The selection process can be based on preset cost comparison rules, ranking the cost values ​​of multiple candidate API structures and selecting the version with the lowest estimated cost as the optimal API structure. If only a single optimized API structure exists, it can be directly considered the optimal structure. The conversion process can be implemented using a syntax generator built specifically for the target database's syntax specifications. This generator re-serializes various nodes in the API structure into text-based query statements. For example, it determines the order of clauses such as SELECT, FROM, JOIN, WHERE, GROUP BY, and ORDER BY based on node hierarchy, generates field lists and operation expression strings based on field and expression nodes, and generates conditional expression combinations based on filter nodes. For grammatical elements that differ between different database dialects, dialect mapping rules can be introduced during the generation stage to convert the unified representation in the API structure into keywords, function names, and restricted syntax supported by the target database, ultimately resulting in an executable data query statement that can be directly submitted and executed in the target database.

[0077] This embodiment introduces syntax parsing to generate an abstract syntax tree structure after the initial data query statement is generated, followed by syntax correctness verification and error correction, logic optimization driven by dynamic context information, and execution cost analysis based on numerical distribution histogram data, estimated data table row counts, and real-time system load indicators. Then, combining the cost analysis results, the optimal abstract syntax tree structure is selected, and the conversion into an executable data query statement is completed. This achieves a complete conversion chain from text-level query requests to structured, optimizable, and evaluable query representations. The generated executable data query statement remains syntactically valid, undergoes targeted rewriting in its logical structure, and its execution cost is quantitatively evaluated based on data distribution and runtime load. Therefore, without changing the way upper-layer business requests are expressed, the stability and execution efficiency of query statements are improved, reducing the reliance on manual tuning of the underlying database execution plan.

[0078] In one embodiment, a data query statement dynamic generation device is provided, which corresponds one-to-one with the data query statement dynamic generation method in the above embodiments. (Refer to...) Figure 3 , Figure 3 This is a schematic diagram of the functional modules of a preferred embodiment of the data query statement dynamic generation device of the present invention. The modules include a data request parsing module 10, a business strategy matching module 20, a strategy conflict resolution module 30, a context acquisition module 40, a template instantiation module 50, and a query optimization module 60. Detailed descriptions of each functional module are as follows: The data request parsing module 10 is used to receive data query request information containing query metrics, query dimensions and filtering conditions; The business strategy matching module 20 is used to match atomic business strategies and composite business strategies from a preset business strategy library based on the data query request information. The strategy conflict resolution module 30 is used to perform logical conflict detection on the atomic business strategy and the composite business strategy, and to resolve the conflict according to the preset priority resolution strategy to generate a target business strategy set. Context acquisition module 40 is used to acquire dynamic context information; The template instantiation module 50 is used to select a matching query template from a preset query template library and map and fill it based on the target business strategy set, the dynamic context information and the data query request information to generate an initial data query statement. The query optimization module 60 is used to perform syntax verification, logic optimization, and execution cost analysis on the initial data query statement based on the dynamic context information, and generate an executable data query statement.

[0079] In one embodiment, the data request parsing module 10 is specifically used for: Establish a data communication interface with the client to receive the original query requests sent by the client; Parse the original query request to extract query metrics, query dimensions, and filtering conditions; Based on a preset metadata dictionary, verify the existence of the query metrics, the compliance of the query dimensions, and the consistency of the data types of the filtering conditions; The verified query metrics, query dimensions, and filtering conditions are encapsulated into data query request information.

[0080] In one embodiment, the business strategy matching module 20 is specifically used for: Parse the data query request information to extract query metrics and query dimensions; Using the query metrics and query dimensions as search criteria, the preset business strategy library is traversed to read the pre-configured activation trigger conditions for each business strategy in the business strategy library. The query metrics and query dimensions are logically compared with the effective triggering conditions to filter out all candidate business strategies that meet the effective triggering conditions. Identify the logical structure attributes of the candidate service strategies; When the logical structure attribute is characterized as an indivisible single processing logic, the candidate business strategy is determined as an atomic business strategy. When the logical structure attribute is characterized as a combined processing logic containing logical operators, the candidate business strategy is determined as a composite business strategy.

[0081] In one embodiment, the strategy conflict resolution module 30 is specifically used for: Analyze the data object definition domains that the atomic business strategy and the composite business strategy apply to, and identify multiple competing business strategies that have logical definition differences for the same data object definition domain; Read the preset priority resolution strategy, which pre-configures the priority weight sequence of data security type strategy, business processing type strategy and performance optimization type strategy; Based on the priority weight sequence, determine the priority weight value corresponding to each of the competitive business strategies; The priority weight values ​​of multiple competing business strategies are compared numerically to determine the maximum priority weight value among the multiple competing business strategies. Retain the competing business strategy with the maximum priority weight value, and eliminate the competing business strategy whose priority weight value is numerically less than the maximum priority weight value; The target business strategy set is generated by summarizing the remaining competitive business strategies after the elimination operation, along with the atomic and composite business strategies that were not identified as competitive business strategies.

[0082] In one embodiment, the context acquisition module 40 is specifically used for: Establish a management interaction connection with the target database and read the data table schema definition information and primary and foreign key constraints of the target database; Retrieve the index configuration dictionary of the target database and extract the list of index fields that are currently in effect and their corresponding index type attributes; Query the data statistics view of the target database to obtain the histogram data of the numerical distribution of the target data fields and the estimated value of the number of rows in the data table; Call the system operation monitoring interface to collect real-time system load indicators of the processing environment running the target database; The data table schema definition information, the primary and foreign key constraints, the index field list, the index type attributes, the numerical distribution histogram data, the estimated number of rows in the data table, and the real-time system load indicators are integrated and encapsulated to generate dynamic context information.

[0083] In one embodiment, the template instantiation module 50 is specifically used for: Analyze the aggregation processing type in the data query request information, and retrieve a query template that matches the aggregation processing type from a preset query template library. The query template contains variable placeholders. Extract the list of indexed fields from the dynamic context information; Identify the filter condition fields contained in the target business strategy set and the data query request information, and compare the filter condition fields with the index field list; The order of the filter criteria fields is dynamically adjusted based on the comparison results, so that the filter criteria fields existing in the index field list are moved to the preceding position of the variable placeholder filling sequence; The query metrics, query dimensions, and adjusted filter condition fields from the data query request information are mapped and filled into the variable placeholders in the query template to generate the initial data query statement.

[0084] In one embodiment, the query optimization module 60 is specifically used for: The initial data query statement is parsed to generate an abstract syntax tree structure; Verify the grammatical correctness of the abstract syntax tree structure, correct the grammatical errors found during the grammatical correctness verification, and generate a grammatically correct abstract syntax tree structure. Based on the dynamic context information, the application logic optimization is used to rewrite and optimize the grammatically correct abstract syntax tree structure, generating an optimized abstract syntax tree structure. Using the numerical distribution histogram data, estimated number of rows in the data table, and real-time system load indicators in the dynamic context information, the cost of performing the optimized abstract syntax tree structure is analyzed. Based on the cost analysis results, the optimal abstract syntax tree structure is selected, and the optimal abstract syntax tree structure is converted into an executable data query statement that conforms to the target database syntax specification.

[0085] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 4As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides determination and control capabilities. The memory includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with external clients via a network connection. When the computer program is executed by the processor, it implements the server-side functions or steps of a dynamic data query statement generation method.

[0086] In one embodiment, a computer device is provided, which may be a client, and its internal structure diagram may be as follows: Figure 5 As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides determination and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with an external server via a network connection. When executed by the processor, the computer program implements client-side functions or steps of a dynamic data query statement generation method.

[0087] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform the following steps: Receive data query request information containing query metrics, query dimensions, and filter conditions; Based on the data query request information, atomic business strategies and composite business strategies are matched from the preset business strategy library; Logical conflict detection is performed on the atomic business strategy and the composite business strategy, and the conflict is resolved according to the preset priority resolution strategy to generate a target business strategy set. Obtain dynamic context information; Based on the target business strategy set, the dynamic context information, and the data query request information, a matching query template is selected from the preset query template library and mapped and filled to generate an initial data query statement; Based on the dynamic context information, the initial data query statement is subjected to syntax validation, logic optimization, and execution cost analysis to generate an executable data query statement.

[0088] In one embodiment, a non-volatile computer-readable storage medium is provided, which may be non-volatile or volatile, and stores a computer program thereon. When the computer program is executed by a processor, it performs the following steps: Receive data query request information containing query metrics, query dimensions, and filter conditions; Based on the data query request information, atomic business strategies and composite business strategies are matched from the preset business strategy library; Logical conflict detection is performed on the atomic business strategy and the composite business strategy, and the conflict is resolved according to the preset priority resolution strategy to generate a target business strategy set. Obtain dynamic context information; Based on the target business strategy set, the dynamic context information, and the data query request information, a matching query template is selected from the preset query template library and mapped and filled to generate an initial data query statement; Based on the dynamic context information, the initial data query statement is subjected to syntax validation, logic optimization, and execution cost analysis to generate an executable data query statement.

[0089] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions on the server side and client side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0090] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0091] It should be noted that if any software tools or components not belonging to this company appear in the embodiments of this application, they are merely illustrative examples and do not represent actual use. The embodiments described above are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

[0092] The user personal information involved in this application embodiment is all authorized (knowing and consenting) by the relevant parties or fully authorized by all parties, and the executing entity can obtain it through various open, legal and compliant means. The collection, storage, use, processing, transmission, provision and disclosure of the information, data and signals involved all comply with the relevant laws and regulations of the relevant countries and regions, and do not violate public order and good morals.

Claims

1. A method for dynamically generating data query statements, characterized in that, Includes the following steps: Receive data query request information containing query metrics, query dimensions, and filter conditions; Based on the data query request information, atomic business strategies and composite business strategies are matched from the preset business strategy library; Logical conflict detection is performed on the atomic business strategy and the composite business strategy, and the conflict is resolved according to the preset priority resolution strategy to generate a target business strategy set. Obtain dynamic context information; Based on the target business strategy set, the dynamic context information, and the data query request information, a matching query template is selected from the preset query template library and mapped and filled to generate an initial data query statement; Based on the dynamic context information, the initial data query statement is subjected to syntax validation, logic optimization, and execution cost analysis to generate an executable data query statement.

2. The method for dynamically generating data query statements as described in claim 1, characterized in that, Receive data query request information containing query metrics, query dimensions, and filter conditions, including: Establish a data communication interface with the client to receive the original query requests sent by the client; Parse the original query request to extract query metrics, query dimensions, and filtering conditions; Based on a preset metadata dictionary, verify the existence of the query metrics, the compliance of the query dimensions, and the consistency of the data types of the filtering conditions; The verified query metrics, query dimensions, and filtering conditions are encapsulated into data query request information.

3. The method for dynamically generating data query statements as described in claim 1, characterized in that, Based on the data query request information, atomic business strategies and composite business strategies are matched from a preset business strategy library, including: Parse the data query request information to extract query metrics and query dimensions; Using the query metrics and query dimensions as search criteria, the preset business strategy library is traversed to read the pre-configured activation trigger conditions for each business strategy in the business strategy library. The query metrics and query dimensions are logically compared with the effective triggering conditions to filter out all candidate business strategies that meet the effective triggering conditions. Identify the logical structure attributes of the candidate service strategies; When the logical structure attribute is characterized as an indivisible single processing logic, the candidate business strategy is determined as an atomic business strategy. When the logical structure attribute is characterized as a combined processing logic containing logical operators, the candidate business strategy is determined as a composite business strategy.

4. The method for dynamically generating data query statements as described in claim 1, characterized in that, Logical conflict detection is performed on the atomic business strategies and composite business strategies, and conflict resolution is carried out according to a preset priority resolution strategy to generate a target business strategy set, including: Analyze the data object definition domains that the atomic business strategy and the composite business strategy apply to, and identify multiple competing business strategies that have logical definition differences for the same data object definition domain; Read the preset priority resolution strategy, which pre-configures the priority weight sequence of data security type strategy, business processing type strategy and performance optimization type strategy; Based on the priority weight sequence, determine the priority weight value corresponding to each of the competitive business strategies; The priority weight values ​​of multiple competing business strategies are compared numerically to determine the maximum priority weight value among the multiple competing business strategies. Retain the competing business strategy with the maximum priority weight value, and eliminate the competing business strategy whose priority weight value is numerically less than the maximum priority weight value; The target business strategy set is generated by summarizing the remaining competitive business strategies after the elimination operation, along with the atomic and composite business strategies that were not identified as competitive business strategies.

5. The method for dynamically generating data query statements as described in claim 1, characterized in that, Obtain dynamic context information, including: Establish a management interaction connection with the target database and read the data table schema definition information and primary and foreign key constraints of the target database; Retrieve the index configuration dictionary of the target database and extract the list of index fields that are currently in effect and their corresponding index type attributes; Query the data statistics view of the target database to obtain the histogram data of the numerical distribution of the target data fields and the estimated value of the number of rows in the data table; Call the system operation monitoring interface to collect real-time system load indicators of the processing environment running the target database; The data table schema definition information, the primary and foreign key constraints, the index field list, the index type attributes, the numerical distribution histogram data, the estimated number of rows in the data table, and the real-time system load indicators are integrated and encapsulated to generate dynamic context information.

6. The method for dynamically generating data query statements as described in claim 1, characterized in that, Based on the target business strategy set, the dynamic context information, and the data query request information, a matching query template is selected from a preset query template library and mapped and populated to generate an initial data query statement, including: Analyze the aggregation processing type in the data query request information, and retrieve a query template that matches the aggregation processing type from a preset query template library. The query template contains variable placeholders. Extract the list of indexed fields from the dynamic context information; Identify the filter condition fields contained in the target business strategy set and the data query request information, and compare the filter condition fields with the index field list; The order of the filter criteria fields is dynamically adjusted based on the comparison results, so that the filter criteria fields existing in the index field list are moved to the preceding position of the variable placeholder filling sequence; The query metrics, query dimensions, and adjusted filter condition fields from the data query request information are mapped and filled into the variable placeholders in the query template to generate the initial data query statement.

7. The method for dynamically generating data query statements as described in claim 1, characterized in that, Based on the dynamic context information, the initial data query statement undergoes syntax validation, logic optimization, and execution cost analysis to generate an executable data query statement, including: The initial data query statement is parsed to generate an abstract syntax tree structure; Verify the grammatical correctness of the abstract syntax tree structure, correct the grammatical errors found during the grammatical correctness verification, and generate a grammatically correct abstract syntax tree structure. Based on the dynamic context information, the application logic optimization is used to rewrite and optimize the grammatically correct abstract syntax tree structure, generating an optimized abstract syntax tree structure. Using the numerical distribution histogram data, estimated number of rows in the data table, and real-time system load indicators in the dynamic context information, the cost of performing the optimized abstract syntax tree structure is analyzed. Based on the cost analysis results, the optimal abstract syntax tree structure is selected, and the optimal abstract syntax tree structure is converted into an executable data query statement that conforms to the target database syntax specification.

8. A device for dynamically generating data query statements, characterized in that, The data query statement dynamic generation device includes: The data request parsing module is used to receive data query request information containing query metrics, query dimensions, and filter conditions. The business strategy matching module is used to match atomic business strategies and composite business strategies from a preset business strategy library based on the data query request information. The strategy conflict resolution module is used to perform logical conflict detection on the atomic business strategy and the composite business strategy, and to resolve the conflict according to the preset priority resolution strategy to generate a target business strategy set. The context acquisition module is used to obtain dynamic context information; The template instantiation module is used to select a matching query template from a preset query template library and map and fill it based on the target business strategy set, the dynamic context information and the data query request information to generate an initial data query statement. The query optimization module is used to perform syntax validation, logic optimization, and execution cost analysis on the initial data query statement based on the dynamic context information, and generate an executable data query statement.

9. A computer device, characterized in that, The computer device includes a memory, a processor, and a data query statement dynamic generation program stored in the memory and executable on the processor. When the data query statement dynamic generation program is executed by the processor, it implements the steps of the data query statement dynamic generation method as described in any one of claims 1-7.

10. A non-volatile computer-readable storage medium, characterized in that, The storage medium stores a dynamic data query statement generation program, which, when executed by a processor, implements the steps of the dynamic data query statement generation method as described in any one of claims 1-7.

Images