Method for constructing and using field roles based on hierarchical classification

Abstract

This application provides a method for constructing and using field roles based on hierarchical classification, including: loading a predefined domain ontology specification file as a preset ontology definition file and parsing it to extract all original data attribute information associated with business concept classes to construct a field description mapping table and assign field role labels; extracting associated ontology constraint features to generate field constraint metadata and calculating the aggregation grouping priority weights corresponding to each field; generating corresponding structured field rule objects for each field based on the aforementioned information and storing them in a memory cache space; responding to the query optimizer's query request initiated by parsing the input original natural language question to obtain the target field, retrieving the corresponding field rule object from the memory cache space and generating a structured query plan. This application achieves unified structured cache management of field metadata, and the query construction has a high degree of rationality.

Description

Technical Field

[0001] This application relates to the fields of natural language processing and database query optimization, and more specifically, to a method for constructing and using field roles based on hierarchical classification. Background Technology

[0002] In ontology-based natural language query optimization systems, understanding the terminology in user queries and correctly mapping it to ontology fields is one of the core tasks. However, simply knowing which field a term corresponds to is insufficient; the optimizer also needs to know the specific business classification role of that field, such as whether it is an identifier, an aggregateable metric, a finite enumeration value, or descriptive text. This classification role information is crucial for the optimizer to ultimately construct the correct underlying query execution plan.

[0003] Existing field role management and query parsing solutions typically employ a processing model based on hard-coded code or manual external configuration. This approach first involves writing multiple independent suffix matching rules at the code level to roughly determine the classification of certain specific field names. Then, developers manually write external, independent configuration files to specify the enumeration range or constraints for each field. Finally, when the system receives a query request, the various submodules within the optimizer call the aforementioned scattered code rules and configuration files to verify the necessary information at different stages, thereby driving the generation of the query plan.

[0004] However, this approach has significant technical flaws. Because the decision-making logic is scattered across various locations and manually specified, the system cannot automatically uncover and associate deep business characteristics and constraints of fields when faced with complex and ever-changing business entities. This forces the optimizer to repeatedly parse local data from isolated files or code when processing query plans. Furthermore, this decentralized management model lacks a unified structural object that integrates various labels, constraints, and grouping weights, making it unable to support the query optimizer in directly and quickly retrieving the complete characteristics of target fields from raw natural language input. This fails to meet the high-efficiency requirements for automated extraction and systematic application of field characteristics in natural language query optimization. Summary of the Invention

[0005] This application provides a method for constructing and using field roles based on hierarchical classification, so as to at least alleviate the above-mentioned technical problems.

[0006] A method for constructing and using field roles based on hierarchical classification, including: S1. Load a predefined domain ontology specification file as a preset ontology definition file. The preset ontology definition file contains specification descriptions of business concept classes, data attributes, and their interrelationships. Parse the preset ontology definition file to extract all original data attribute information associated with the business concept classes that need to be constructed with field roles from the preset ontology definition file, so as to construct a field description mapping table and assign field role labels to each field in the field description mapping table. S2. Extract the ontology constraint features associated with each field in the field description mapping table from the preset ontology definition file, generate field constraint metadata based on the extracted ontology constraint features, and calculate the aggregation grouping priority weight corresponding to each field in the field description mapping table. S3. Based on the field role label, the field constraint metadata, and the aggregation group priority weight, generate corresponding field rule objects for each field in the field description mapping table and store them in the memory cache space. The field rule object is a structured object that carries all the metadata of a single field. S4. In response to the query optimizer parsing the input original natural language question to obtain the target field and initiating a field feature query request accordingly, the field rule object corresponding to the target field is retrieved in the memory cache space to generate a structured query plan that matches the original natural language question.

[0007] Optionally, in S1, constructing a field description mapping table and assigning field role labels to each field in the field description mapping table includes: converting the original data attribute information into corresponding fields, where the fields are the specific representation of data attributes in the preset ontology definition file, to generate a field description mapping table containing all fields and their description information; applying a role classification process based on the field description mapping table to determine the field role labels that each field in the field description mapping table assumes in the query optimization process and assigning them to the corresponding fields in the field description mapping table.

[0008] Optionally, based on the field description mapping table, a role classification process is applied to determine the field role labels that each field in the field description mapping table assumes in the query optimization process and assign them to the corresponding fields in the field description mapping table. This includes: performing heuristic rule classification on the field description mapping table to identify the preliminary roles of each field and generating preliminary role labeling results including identifier role labels, metric role labels, and timestamp role labels; extracting the field names, field comments, and example values ​​associated with the fields not covered in the preliminary role labeling results, and encapsulating the extracted field names, field comments, and example values ​​into a classification guidance prompt containing role assignment instructions; inputting the classification guidance prompt into a pre-trained large language model for structured role mapping processing to return a structured role mapping result containing the correspondence between field names and field role labels; and based on the structured role mapping result containing the correspondence between field names and field role labels, determining the field role labels that each field in the field description mapping table assumes in the query optimization process and assigning them to the corresponding fields in the field description mapping table.

[0009] Optionally, based on the structured role mapping result containing the correspondence between field names and field role labels, the field role labels that each field in the field description mapping table assumes in the query optimization process are determined and assigned to the corresponding fields in the field description mapping table. This includes: parsing the structured role mapping result containing the correspondence between field names and field role labels returned by the pre-trained large language model to generate supplementary role mapping data; performing cross-logic verification on the preliminary role labeling result and the supplementary role mapping data to check whether there are fields with role assignment conflicts in the field description mapping table; if so, calling the preset configuration overriding logic to correct the field role labels corresponding to the fields with role assignment conflicts, so that each field in the field description mapping table has the field role labels that it assumes in the query optimization process.

[0010] Optionally, step S2, which generates field constraint metadata based on the extracted ontology constraint features, includes: assigning unique constraint flags to each field in the field description mapping table based on the ontology constraint features; determining a finite set of allowed values ​​corresponding to each field in the field description mapping table to construct an enumerated constraint list reflecting the label mapping relationship between fields; determining the data type name corresponding to each field in the field description mapping table and mapping the data type name to a preset category containing numeric, date, string, boolean, and unknown categories to generate a data type classification result corresponding to each field in the field description mapping table; and constructing the field constraint metadata based on the unique constraint flags, the enumerated constraint list, and the data type classification result.

[0011] Optionally, step S2, calculating the aggregation group priority weight corresponding to each field in the field description mapping table, includes: extracting fields corresponding to field role tags that match the field constraint metadata from the field description mapping table; calling a preset role weight configuration table to assign basic group priority weights to the extracted fields; determining the fields belonging to business identifier roles and internal identifier roles among the fields corresponding to field role tags that match the field constraint metadata, assigning a preset weight bonus coefficient to the fields of business identifier roles, and assigning a preset weight penalty coefficient to the fields of internal identifier roles; adjusting the basic group priority weights based on the preset weight bonus coefficients and preset weight penalty coefficients to obtain the adjusted group priority weights; determining the business attribute configurations of all fields in the field description mapping table, and calculating the aggregation group priority weight corresponding to each field in the field description mapping table based on the adjusted group priority weights and the business attribute configurations of all fields.

[0012] Optionally, S3 generates corresponding field rule objects for each field in the field description mapping table based on the field role tags, the field constraint metadata, and the aggregation group priority weights, and stores them in the memory cache space. The field rule object is a structured object carrying all metadata of a single field. This includes: performing association aggregation and encapsulation processing on the field role tags, the field constraint metadata, and the aggregation group priority weights to generate corresponding field rule objects for each field in the field description mapping table. The field rule object is a structured object carrying all metadata of a single field. All the field rule objects are assembled into a unified field rule set. The constructed field rule set is stored in the memory cache space, and a standardized query interface is constructed based on the field rule set stored in the memory cache space. The standardized query interface is called by the query optimizer.

[0013] Optionally, the field rule set is a collection of all the field rule objects. Each field rule object internally carries at least one of the following: field role labels, sub-labels, uniqueness constraint flags, enumeration constraint lists, data type classification results, and multi-dimensional metadata features of aggregation group priority weights. The enumeration constraint list contains a finite set of allowed values ​​and their label mapping relationships.

[0014] Optionally, S4, generating a structured query plan matching the original natural language problem includes: the standardized query interface performing field feature parsing processing on the retrieved field rule object to feed back the feature parsing result corresponding to the target field to the query optimizer; the query optimizer revising the initial query path generated internally by the query optimizer according to the field role labels included in the feature parsing result to obtain a revised query path, wherein the initial query path is a path structure representing the data retrieval order and connection method generated by the query optimizer based on the original natural language problem; the query optimizer penalizing the candidate field set involved in the initial query path to obtain a penalized candidate field set, wherein the candidate field set is a set of all fields to be used in the structured query plan initially selected by the query optimizer from the field description mapping table during the plan construction phase; the query optimizer constructing an aggregation query operator according to the aggregation group candidate list and aggregation group priority weight included in the feature parsing result, and generating a structured query plan matching the original natural language problem based on the revised query path, the penalized candidate field set, and the aggregation query operator.

[0015] Optionally, S4 further includes: obtaining the field role tag from the field rule object through the role query interface, and using the aggregation group priority weight in the field rule object to sort all fields in the field description mapping table in descending order through the weight sorting interface to generate an aggregation group candidate list.

[0016] Technical advantages of the technical solution provided in this application This application presents a method for constructing and using field roles based on hierarchical classification. Addressing the technical shortcomings of traditional processing solutions, such as scattered judgment logic and the inability to automatically mine deep ontology features, this method loads a predefined domain ontology specification file as a preset ontology definition file. It then parses this file to extract all original data attribute information associated with business concept classes, constructing a field description mapping table and assigning field role labels. This solves the problem of fragmented and incomplete field information maintenance caused by reliance on independent code or external configuration files in traditional solutions. Compared to the traditional manually set isolated judgments, this application directly extracts and maps based on the ontology specification file, achieving homogenization of field information and resulting in a high level of automation for assigning role labels to massive numbers of fields.

[0017] Based on the extracted ontology constraint features, field constraint metadata is generated, and the aggregation grouping priority weights corresponding to each field in the field description mapping table are calculated. This solves the technical problems of traditional solutions being unable to analyze deep-level field constraints and lacking quantitative dimensions. Because constraint features are extracted directly at the basic data level and grouping priorities are quantified, the query optimizer has sufficient reference data when facing complex aggregation query evaluations. Compared with traditional partial judgment methods, the rationality and comprehensiveness of the evaluation of the usability of field aggregation grouping are significantly improved.

[0018] Based on field role labels, field constraint metadata, and aggregation group priority weights, this application generates corresponding field rule objects for each field in the field description mapping table and stores them in the memory cache. This solves the technical bottleneck of traditional solutions lacking a unified and integrated structured object. Compared to the cumbersome process of traditional optimizers where each module needs to repeatedly parse from various configuration files, this application stores the structured object carrying all the metadata of a single field in the memory cache, establishing a unified and standardized data foundation for subsequent calls, resulting in higher execution efficiency for underlying data interactions.

[0019] In response to the query optimizer parsing the original natural language question to obtain the target field, a request is initiated to retrieve the corresponding field rule object from the memory cache space and generate a structured query plan. This forms a complete chain processing mechanism from ontology loading to unified caching to actual query invocation. Traditional query systems often lack a global metadata structure object, resulting in slow response times and the potential to miss key field constraints. This application enables the query optimizer to instantly acquire and utilize multi-dimensional complete features, including role tags and aggregation weights. Compared to traditional solutions, the generated structured query plan has a higher degree of consistency and reliability with the true intent of the original natural language question, better meeting the high efficiency requirements for automated extraction and systematic application of field characteristics in natural language query optimization. Attached Figure Description

[0020] Figure 1 This application provides an embodiment of a method for constructing and using field roles based on hierarchical classification.

[0021] Figure 2 This application provides an apparatus for constructing and using field roles based on hierarchical classification.

[0022] Figure 3 This is an electronic device according to an embodiment of the present application. Detailed Implementation

[0023] like Figure 1The illustration shows a method for constructing and using field roles based on hierarchical classification, as per an embodiment of this application. The method includes: S1, loading a predefined domain ontology specification file as a preset ontology definition file, wherein the preset ontology definition file contains specification descriptions of business concept classes, data attributes, and their interrelationships; parsing the preset ontology definition file to extract all original data attribute information associated with the business concept classes for which field roles need to be constructed, thereby constructing a field description mapping table and assigning field role labels to each field in the field description mapping table; S2, extracting ontology constraint features associated with each field in the field description mapping table from the preset ontology definition file, and based on the extracted... S3. Based on the field role label, the field constraint metadata, and the aggregation group priority weight corresponding to each field in the field description mapping table, generate a corresponding field rule object for each field in the field description mapping table and store it in the memory cache space. The field rule object is a structured object that carries all the metadata of a single field. S4. In response to the query optimizer parsing the input original natural language question to obtain the target field and initiating a field feature query request accordingly, the field rule object corresponding to the target field is retrieved in the memory cache space to generate a structured query plan that matches the original natural language question.

[0024] Optionally, in S1, constructing a field description mapping table and assigning field role labels to each field in the field description mapping table includes: converting the original data attribute information into corresponding fields, where the fields are the specific representation of data attributes in the preset ontology definition file, to generate a field description mapping table containing all fields and their description information; applying a role classification process based on the field description mapping table to determine the field role labels that each field in the field description mapping table assumes in the query optimization process and assigning them to the corresponding fields in the field description mapping table.

[0025] Preferably, during the system warm-up phase, in the process of parsing the preset ontology definition file and constructing the field description mapping table, the original data attribute information associated with the business concept classes is first extracted from the preset ontology definition file. The preset ontology definition file is a standardized description of concepts, attributes, and their interrelationships within a specific business domain. It describes the data attributes possessed by each business concept class in a structured form. For example, in the civil aviation ontology, the passenger class may contain data attributes such as passenger number, name, and frequent flyer class; the flight class may contain data attributes such as flight number, scheduled departure time, delay duration, and flight status. The parser traverses each business concept class in the preset ontology definition file, extracting the attribute name, data type label, semantic label, and text comments for all data attributes under each class. The attribute name is the unique identifier of the data attribute in the ontology; the data type label indicates the type of value carried by the data attribute; the semantic label is a human-readable Chinese or English name; and the text comments may contain more detailed descriptions or constraints for the field. Each extracted data attribute is treated as a field, and its attribute name is designated as the field name. Its class name, semantic tag, and text comment are defined as the field's descriptive information, thus forming a field description mapping table that uses the field name as the index key and includes the field's full name, class, semantic explanation, and original comments. This process transforms data attributes scattered throughout the predefined ontology definition file into a unified data structure, providing a complete set of processing objects for subsequent field role classification.

[0026] Preferably, for the established field description mapping table, a three-layer role classification process is executed, consisting of a heuristic rule classification layer, a large language model batch classification layer, and a post-validation and conflict resolution layer, to assign a field role label to each field in the table, representing its business semantics in query optimization. The first layer is heuristic rule classification. The system pre-sets a set of suffix matching rules based on field name string patterns and classification rules based on data type labels. These rules are pre-defined according to common ontology design conventions in the domain. For example, the suffix matching rule defines that when a field name ends with a preset character combination, its initial role can be directly labeled: fields ending with a preset character combination often represent internal, unique identifiers without actual business meaning and can be assigned the internal identifier role; fields ending with a preset character combination usually represent number-type identifiers with business meaning and can be assigned the business identifier role; fields ending with a preset character combination generally contain time information and can be assigned the timestamp role; fields ending with a preset character combination and whose data type label indicates a numeric type often represent measurable duration values ​​and can be assigned the measurement value role. Meanwhile, the data type classification rule defines that when a field's data type label belongs to numeric and does not match any suffix rule, its role is not immediately assigned, but is reserved for later processing. The system iterates through the field name in the field description mapping table, comparing the name with the preset suffix patterns one by one, while checking its corresponding data type label. Once a match is found, the field is assigned the corresponding preliminary role label. Fields that do not match any rules are marked as uncovered fields. This layer of processing quickly enables batch labeling of fields with significant pattern characteristics, outputting preliminary role labeling results containing both the preliminary role-labeled field set and the uncovered field set.

[0027] Preferably, the second layer is a batch classification by the large language model, processing the uncovered field set output by the first layer. For each uncovered field in the uncovered field set, its field name, semantic tag, and text annotation (if present) are extracted from the field description mapping table, and this information is encapsulated into a field item to be classified. The field item to be classified fully contains the natural language description of the field that can be semantically inferred. All field items to be classified corresponding to the uncovered field set are packaged, and a classification guidance prompt is constructed. The classification guidance prompt, in the form of a natural language instruction, clearly defines the task objective: to specify an optional set of field role tags for the large language model, including at least identifiers, metrics, limited attributes, timestamps, and descriptive categories, and to provide a semantic definition for each role; then, the list of field items to be classified is filled in line by line, with each field item accompanied by its field name and an explanatory description extracted from the semantic tag or text annotation. The classification guidance prompt also includes a return format instruction, requiring the large language model to return only a structured mapping result containing the correspondence between field names and field role tags, for example, using a preset data exchange format. The constructed classification guidance prompts are input into a pre-trained large language model for inference. Based on its understanding of natural language semantics, the large language model determines the most likely query role for each uncovered field in the actual business context and generates a structured role mapping result that matches the request format. This layer leverages the semantic generalization capability of the large language model to solve the role determination problem of complex or non-standard named fields that the first layer based on hard rules cannot handle, achieving semantic-level classification of uncovered fields.

[0028] Preferably, the third layer is post-verification and conflict resolution. Its processing objects include the preliminary role labeling results output from the first layer and the supplementary role mapping data parsed from the structured role mapping results of the second layer. The system merges the preliminary role labeling results and the supplementary role mapping data to form a complete role mapping set covering all fields in the field description mapping table. Subsequently, the system initiates a cross-logic verification process, traversing each field and its corresponding field role label in the complete role mapping set to check for role allocation conflicts or labeling situations that violate basic common sense. Cross-logic verification is based on a set of preset constraint rules. For example, a constraint rule defines that if a field's data type label is numeric, its field role label should not be labeled as a descriptive category, because descriptive categories usually correspond to free text, and a numeric field labeled as descriptive is considered a conflict; another constraint rule specifies that the role of a specific field (e.g., a field whose role is explicitly locked by the system administrator in the configuration file) should be based on the preset role in the configuration file. When a conflict is detected, the system calls the preset configuration overriding logic to replace the currently conflicting field role label with the preset field role label in the configuration file, completing the conflict correction. After cross-logic verification and configuration coverage correction, a conflict-free and high-confidence final role assignment result is obtained. Each field in the field description mapping table is assigned a specific field role label, selected from identifiers, metrics, limited attributes, timestamps, and descriptive features. This layer, through rule-based post-hoc checks and configuration intervention, ensures the rationality and reliability of the overall classification result combining heuristic rules and a large language model.

[0029] Preferably, the design of the above three-layer role classification process decouples the field role determination logic from the hard-coded rules scattered across various modules of the query optimizer, forming a centralized and auditable classification processing chain. The heuristic rule layer provides a stable, cost-free baseline classification capability that responds quickly to salient patterns, ensuring the classification efficiency of typical ontology fields. The large language model batch classification layer serves as a supplementary channel, specifically addressing "long-tail" fields that heuristic rules cannot cover. These fields may not be matched by simple rules due to non-standard naming or semantic ambiguity. The large language model infers roles by understanding the semantic labels of fields and the business context in the text, compensating for the rigidity of rules. The post-validation and conflict resolution layer, as an implementation layer, performs consistency verification and mandatory correction on the results of the first two heterogeneous classification sources. This design allows the system to both benefit from the semantic understanding provided by the large language model and prevent accidental errors that may arise from the output of the large language model through rule constraints. The three layers pass intermediate results sequentially, such as preliminary role labeling results, uncovered field sets, and supplementary role mapping data. This achieves the organic synergy of deterministic rules, non-deterministic semantic inference, and controlled post-hoc correction. As a result, the final field role labels obtained by each field in the field description mapping table have the characteristics of broad coverage, reasonable semantics, and system controllability. This provides a solid and accurate role data foundation for the subsequent construction of field rule objects for unified querying.

[0030] Optionally, based on the field description mapping table, a role classification process is applied to determine the field role labels that each field in the field description mapping table assumes in the query optimization process and assign them to the corresponding fields in the field description mapping table. This includes: performing heuristic rule classification on the field description mapping table to identify the preliminary roles of each field and generating preliminary role labeling results including identifier role labels, metric role labels, and timestamp role labels; extracting the field names, field comments, and example values ​​associated with the fields not covered in the preliminary role labeling results, and encapsulating the extracted field names, field comments, and example values ​​into a classification guidance prompt containing role assignment instructions; inputting the classification guidance prompt into a pre-trained large language model for structured role mapping processing to return a structured role mapping result containing the correspondence between field names and field role labels; and based on the structured role mapping result containing the correspondence between field names and field role labels, determining the field role labels that each field in the field description mapping table assumes in the query optimization process and assigning them to the corresponding fields in the field description mapping table.

[0031] Preferably, in the process of inputting the classification guidance prompt into the pre-trained large language model to perform structured role mapping processing, the pre-trained large language model is a specially trained deep neural network. Its internal structure, from bottom to top, includes an embedding representation layer, a multi-layered stacked transformation and decoding structure, and a role determination projection layer. These three layers are progressively advanced in function and work together to complete the reasoning transformation from natural language prompts to structured role mapping results. First, the embedding representation layer receives the input classification guidance prompt, which is a natural language text sequence composed of role assignment instructions, a list of fields to be classified, and a return format indication. The embedding representation layer performs word segmentation on the classification guidance prompt, dividing the text sequence into indivisible word units, each word unit corresponding to a natural language word or punctuation mark. Subsequently, the embedding representation layer queries a pre-set word embedding matrix, mapping each word unit to a high-dimensional semantic vector with a fixed dimension, and simultaneously superimposing positional encoding based on the positional information of the word unit in the sequence to form a word embedding representation sequence. This lexical embedding means that each element in the sequence is a vector that integrates lexical semantic information and positional information, providing an initial feature representation for subsequent network layers to perform contextual semantic modeling.

[0032] Preferably, the token embedding representation sequence output by the embedding representation layer is fed into a deep semantic coding network consisting of multiple stacked transformation-decoding structure layers with identical structures but independent parameters. Each transformation-decoding structure layer contains a multi-head self-attention operation module and a position-wise feedforward network module, with residual connections and hierarchical normalization operations introduced at the outputs of the two modules, respectively. Taking the processing flow of a single-layer transformation-decoding structure layer as an example, it receives the input hidden state matrix output by the previous layer as the processing object and first starts the multi-head self-attention operation module. This multi-head self-attention module projects the input hidden state matrix into a query matrix, a key matrix, and a value matrix using multiple sets of learnable linear mapping matrices. Each projection corresponds to an attention head. Within each attention head, the transpose of the query matrix and the key matrix is ​​calculated, divided by a scaling factor, and then normalized to obtain an attention weight matrix. Each element in this matrix represents the semantic dependency strength between two positions in the lexical embedding sequence. The attention weight matrix is ​​then multiplied by the value matrix to obtain the context representation output of that attention head. The context representation outputs of all attention heads are concatenated along the feature dimension and fused using an output linear mapping matrix to obtain the output representation of the multi-head self-attention module. This output representation is residually added to the input hidden state matrix and subjected to hierarchical normalization before being fed into the position-wise feedforward network module. The position-wise feedforward network module independently performs the same nonlinear transformation on the vector at each position in the input sequence. It typically contains two linear transformation layers and a nonlinear activation function in between, further enhancing the nonlinear expressive power of the features. Its output is then added to the module input as a residual and subjected to hierarchical normalization to generate the output hidden state matrix of the current transformation-decoding structure layer. This output hidden state matrix then serves as the input hidden state matrix for the next transformation-decoding structure layer, and so on, layer by layer. After stacking all transformation-decoding structure layers, the deep semantic hidden state matrix is ​​finally obtained. Each row vector in this deep semantic hidden state matrix incorporates the semantic modification relationship of the global context in the classification guidance prompt for the corresponding word position in that row, thus achieving deep encoding of the semantic relationship between the role assignment instruction and the field item to be classified.

[0033] Preferably, after the multi-layer transformation and decoding structure completes the deep semantic encoding of the classification guidance prompts, the role determination projection layer takes the position vector corresponding to each field item to be classified in the deep semantic hidden state matrix as input and performs role category determination. This role determination projection layer consists of a fully connected layer and a probability normalization operation. The fully connected layer multiplies the input position vector by a trainable projection weight and adds a bias term, mapping it to a log-odds vector with the same dimension as the set of field role labels. Each component in this log-odds vector corresponds to a predefined field role label, and its value reflects the model's original score for the field belonging to the corresponding role. The probability normalization operation performs an exponential operation on each component in the log-odds vector and normalizes it, obtaining a probability distribution vector. Each component in this probability distribution vector represents the confidence probability that the field to be classified is determined to be the corresponding field role label. During the inference phase, the field role label corresponding to the maximum confidence probability in the probability distribution vector is selected as the determined role for the field to be classified. The role determination projection layer performs the aforementioned projection and normalization operations on each field item to be classified in the classification guidance prompt, obtaining the role determination label corresponding to each uncovered field. Subsequently, the pre-trained large language model assembles the field name of each uncovered field and its corresponding role determination label into key-value pairs according to the return format instructions in the classification guidance prompt, and encapsulates all entries into a structured role mapping result for output.

[0034] Preferably, to achieve reliable inference for the pre-trained large language model in the field role classification task, a targeted training process needs to be performed before the system goes live. The training process processes a pre-constructed set of field role classification training samples. Each training sample in this set contains a field description text simulating an uncovered field and a manually verified labeled role tag. The labeled role tag is selected from identifier roles, metric roles, finite attribute roles, timestamp roles, and descriptive roles. When constructing training samples, representative and diverse field description information is collected from business ontologies across multiple domains, covering different naming styles and business contexts. Each field description is encapsulated in the same data format as the classification guidance prompts to form a training sample. The training process adopts a supervised learning paradigm, optimizing all trainable parameters in the pre-trained large language model in a batch-by-batch iterative manner. In each training batch, a set of training samples with classification guidance prompts is fed into the pre-trained large language model. The model sequentially undergoes word embedding transformation in the embedding representation layer, deep semantic encoding in the multi-layer transformation decoding structure layer, and probability distribution generation in the role determination projection layer. It then outputs a predicted probability distribution vector for each training sample's corresponding role label. This predicted probability distribution vector is compared with the labeled role labels carried by the training samples. The difference between the predicted probability distribution and the labeled true distribution is calculated using the cross-entropy loss function. The cross-entropy loss function is calculated as the negative logarithm of the category probability corresponding to the labeled role label; a larger difference value indicates a greater inconsistency between the predicted and labeled distributions. Subsequently, the difference value is propagated back through the network layer by layer, starting from the role determination projection layer, using the backpropagation algorithm to calculate the gradient of each layer's trainable parameters relative to the difference value. Based on the calculated gradient and a preset learning rate, a gradient descent optimizer is used to update the values ​​of each layer's trainable parameters along the gradient descent direction. By traversing multiple training epochs on the field role classification training sample set until the difference value converges below a preset threshold or tends to stabilize, the pre-trained large language model is obtained. Once trained, the parameters of each structural layer of the pre-trained large language model are fixed, enabling it to generalize descriptive information of uncovered fields that did not appear in the training samples and output role labels that match the business context. When the system officially performs field role classification, it can directly load the pre-trained large language model, input the classification guidance prompts, and obtain structured role mapping results without needing to update parameters during execution.

[0035] Preferably, the structural design of the pre-trained large language model described above enables each stage of role classification to be completed through the collaborative work of various layers within the model: the embedding representation layer completes the representation transformation from discrete text symbols to continuous semantic vectors; the multi-layer transformation decoding structure captures the semantic constraint relationship spanning a long distance between the role assignment instruction in the classification guidance prompt and the field item to be classified through self-attention operation, and refines and judges the contextual features related to the role layer by layer; the role judgment projection layer maps the refined deep semantic features to the probability distribution of the role category and generates the judgment result. This layer-by-layer progressive calculation method is different from classification methods that rely solely on hard-coded rule matching, and also different from shallow classifiers that judge only a single field independently. It enables the model to combine the role semantic definition pre-set in the role assignment instruction to infer the role attribution of uncovered fields that lack explicit patterns but have implicit semantic identities; at the same time, after pre-training on massive and diverse field descriptions, the parameter space formed by the model in the field role classification task enables it to generate relatively reasonable role inference results based on its learned semantic association knowledge when facing new, non-standard named fields that appear in the ontology evolution, without having to re-trigger costly training updates. The training process learns by associating domain-wide role definitions with diverse field description instances, giving the model robust semantic role discrimination capabilities even in the absence of hard naming patterns.

[0036] Optionally, based on the structured role mapping result containing the correspondence between field names and field role labels, the field role labels that each field in the field description mapping table assumes in the query optimization process are determined and assigned to the corresponding fields in the field description mapping table. This includes: parsing the structured role mapping result containing the correspondence between field names and field role labels returned by the pre-trained large language model to generate supplementary role mapping data; performing cross-logic verification on the preliminary role labeling result and the supplementary role mapping data to check whether there are fields with role assignment conflicts in the field description mapping table; if so, calling the preset configuration overriding logic to correct the field role labels corresponding to the fields with role assignment conflicts, so that each field in the field description mapping table has the field role labels that it assumes in the query optimization process.

[0037] Preferably, the structured role mapping results returned by the pre-trained large language model are parsed to generate supplementary role mapping data. This structured role mapping result is a data structure containing the correspondence between field names and field role labels. The parsing process reads each key-value pair sequentially, interpreting the key as the name of an uncovered field and the value as the role label determined by the large language model for that uncovered field. This establishes a mapping record between each field originally belonging to the uncovered field subset and its determined role label. The set of all mapping records constitutes the supplementary role mapping data. For example, in the context of civil aviation ontology, if the structured role mapping result contains key-value pairs such as frequent flyer level corresponding to limited attribute roles, flight status corresponding to limited attribute roles, and city name corresponding to descriptive roles, then the generated supplementary role mapping data will record the assignment of limited attribute roles to frequent flyer level, limited attribute roles to flight status, and descriptive roles to city name, respectively. This structurally solidifies the large language model's role inference results for each field in the uncovered field subset.

[0038] Preferably, after obtaining the supplementary role mapping data, it is merged with the preliminary role labeling results to form a complete role mapping set covering all fields in the field description mapping table. The preliminary role labeling results are the output of the heuristic rule classification stage, which records the fields that have obtained preliminary role labels through suffix matching or type classification rules and their corresponding field role labels, such as passenger number corresponding to internal identifier role, flight number corresponding to business identifier role, scheduled departure time corresponding to timestamp role, and delay duration corresponding to metric role, etc. The merging operation brings together the existing role labeling records in the preliminary role labeling results and the supplementary records in the supplementary role mapping data into the same mapping structure. For fields covered in the preliminary role labeling results, their role labels preferentially adopt the existing values ​​in the preliminary role labeling results; for fields in the uncovered field subset, their role labels are taken from the corresponding records in the supplementary role mapping data. The resulting complete role mapping set provides each field in the field description mapping table with role label information in the query optimization process, eliminating the role missing problem introduced by the uncovered field subset.

[0039] Preferably, a cross-logic check is performed on the complete role mapping set to check for any fields with conflicting role assignments. The cross-logic check is based on pre-defined conflict detection rules, which include at least type consistency constraints and configuration locking constraints. The type consistency constraint stipulates that for fields with numeric data type labels in the field description mapping table, their corresponding field role labels in the complete role mapping set must not be descriptive roles. This is because descriptive roles semantically correspond to unstructured free text, and labeling a numeric field as a descriptive role contradicts the data carrying format of the field, thus constituting a conflict. For example, if a numeric field is determined to be a descriptive role by the large language model in the supplementary role mapping data, the type consistency constraint will detect a role assignment conflict for that field. The configuration locking constraint stipulates that if a field is explicitly declared with a mandatory role label in a pre-defined configuration file, the corresponding field role label in the complete role mapping set must be consistent with the mandatory role label; otherwise, it is considered a conflict. Cross-logic verification iterates through each field in the complete role mapping set, judges each field according to the above rules, and outputs a list of conflicting fields in role allocation. This list records the names of all fields that are found to be in conflict and the reasons for the conflict.

[0040] Preferably, when cross-logic verification detects that the list of conflicting role assignment fields is not empty, the preset configuration overriding logic is invoked to correct the role labels corresponding to the conflicting fields. The specific correction action of the preset configuration overriding logic depends on the type of conflict: for violations of type consistency constraints, the preset configuration overriding logic, based on the field's data type label and possible value characteristics, reassigns a role label that conforms to numerical semantics to the conflicting numeric field, for example, correcting its field role label to a measurement role or a limited attribute role; for violations of configuration locking constraints, the preset configuration overriding logic reads the mandatory role label corresponding to the field from the preset configuration file and replaces the current field role label of the field in the complete role mapping set with the mandatory role label. After the correction process is completed, the corresponding record in the complete role mapping set is updated to obtain a conflict-free final role assignment result, in which each field role label satisfies both type consistency constraints and configuration locking constraints. Using the civil aviation scenario, suppose that the delay duration was originally mistakenly labeled as a descriptive role in the complete role mapping set. Since the data type label of the delay duration is a numeric type, after the cross-logic verification detects the conflict, the default configuration overriding logic corrects the role label of the delay duration field to a metric role. Also suppose that the default configuration file forces the airport code field to be designated as a business identifier role. If the airport code in the complete role mapping set is assigned other roles by the large language model, the configuration locking constraint will trigger a correction, replacing the role label of the airport code with the business identifier role.

[0041] Preferably, based on the final role allocation result, the field role labels corresponding to each field are assigned one by one to the corresponding fields in the field description mapping table, completing the role assignment for all fields in the field description mapping table. At this point, each field in the field description mapping table is formally assigned a field role label. This field role label accurately defines the business semantic role that the field undertakes in the query optimization process. Moreover, this label has undergone collaborative processing through three stages: heuristic rule classification, large language model semantic inference, and post-validation conflict correction, possessing rule determinism, semantic rationality, and system controllability. For example, the passenger number is assigned the internal identifier role, the flight number is assigned the business identifier role, the scheduled departure time is assigned the timestamp role, the delay duration is assigned the metric role, the frequent flyer level and flight status are assigned the limited attribute role, and the city name is assigned the descriptive role. Subsequent steps will directly use these determined field role labels as one of their core metadata when constructing field rule objects.

[0042] Preferably, the series of processes described above—parsing, merging, verifying, and correcting—constitutes the post-verification and conflict resolution layer in the three-layer role classification process. This layer globally integrates the results from two heterogeneous classification sources—heuristic rule classification and large language model batch classification—effectively eliminating semantic misjudgments and configuration deviations that may be introduced by a single classification method. The type consistency constraints and configuration locking constraints introduced by cross-logic verification perform dual verification of the role allocation results from two dimensions: field ontology data format and external management strategy. This ensures that contradictions that may arise from relying solely on patterns or semantics are promptly exposed. The preset configuration coverage logic provides a deterministic correction path for detected contradictions, avoiding the risk of generating inefficient query plans based on incorrect role information in subsequent query optimization stages due to unresolved conflicts. Through this post-verification and conflict resolution layer, the allocation of field role labels combines the high efficiency of automated batch processing with the high reliability of rule-based post-verification, providing support for the credibility of the final constructed field rule set as the unified metadata foundation for the optimizer.

[0043] Optionally, step S2, which generates field constraint metadata based on the extracted ontology constraint features, includes: assigning unique constraint flags to each field in the field description mapping table based on the ontology constraint features; determining a finite set of allowed values ​​corresponding to each field in the field description mapping table to construct an enumerated constraint list reflecting the label mapping relationship between fields; determining the data type name corresponding to each field in the field description mapping table and mapping the data type name to a preset category containing numeric, date, string, boolean, and unknown categories to generate a data type classification result corresponding to each field in the field description mapping table; and constructing the field constraint metadata based on the unique constraint flags, the enumerated constraint list, and the data type classification result.

[0044] Preferably, in the process of generating field constraint metadata, the ontology constraint features associated with each field in the field description mapping table are first extracted from the preset ontology definition file. Ontology constraint features are declarations in the preset ontology definition file, recorded in a standardized markup language, that restrict the values ​​or properties of fields. These may include functional attribute tags indicating that the field value is unique within the scope of its class instance, enumeration constraint declarations indicating that the field value must be selected from a limited enumeration, and data type declarations for the field. The extraction process involves a parser traversing the markup structure of the preset ontology definition file, identifying and collecting constraint declaration text that matches the name of each field in the field description mapping table. For functional attribute tags, the parser checks whether a uniqueness declaration tag corresponding to that field exists in the preset ontology definition file. If it exists, a unique constraint record is generated that records the field name and contains a uniqueness constraint flag set to true; otherwise, a unique constraint record with a false uniqueness constraint flag is generated. The set of unique constraint records corresponding to all fields is the unique constraint flag allocation result. For example, in the context of civil aviation ontology, the passenger ID field in the ontology tag is declared as a functional attribute. Based on this, the parser assigns a unique constraint flag of true to this field, while fields such as name and city name, which lack such declarations, are assigned a unique constraint flag of false. This processing converts the uniqueness declarations scattered throughout the ontology tag into Boolean flag fields that can be directly queried by subsequent programs, eliminating the need to parse the original ontology tag at runtime.

[0045] Preferably, while extracting ontology constraint features, a finite set of allowed values ​​for each field is determined from the field annotation text or ontology value constraint declaration associated with the field description mapping table, in order to construct an enumeration constraint list reflecting the mapping relationship between field values ​​and value labels. For each field in the field description mapping table, the parser reads the text annotation or value constraint declaration associated with that field in the preset ontology definition file and extracts candidate enumeration items from it according to preset pattern matching rules. The pattern matching rules can identify the guiding words listed in the annotation text and the subsequent list of values, and can also identify the value sequence presented in the ontology as an enumeration constraint structure. For each extracted candidate enumeration item, it is further detected whether it is accompanied by a synonym tag or Chinese definition connected by a delimiter; if it is accompanied by a tag, the value part of the candidate enumeration item is determined as an allowed value, and the tag part is determined as a value label, forming a value-to-label mapping entry; if it is not accompanied by a tag, the candidate enumeration item itself is used as both an allowed value and a value label. All mapping entries belonging to the same field are aggregated to form an enumeration constraint list corresponding to that field. Each entry in this list resembles a value label corresponding to a allowed value. Furthermore, if a field successfully parses at least one allowed value, an enumeration constraint flag is added to that field as true; otherwise, the flag is added as false. The enumeration constraint list stores the allowed discrete value space of the field and its user-facing display labels in a structured format. Using the civil aviation scenario, for the flight status field, the enumeration values ​​"on time," "delayed," and "cancelled" can be parsed from its annotations, and Chinese label mappings can be extracted to form an enumeration constraint list containing three mapping entries.

[0046] Preferably, after assigning uniqueness constraint flags and constructing an enumeration constraint list, category mapping is performed on the data type names of each field in the field description mapping table to generate data type classification results. The data type names of the fields originate from the data type declarations of each data attribute in the preset ontology definition file, and their naming follows a preset data type vocabulary, such as string type, integer type, date / time type, boolean type, etc. A preset category set serves as the mapping domain. The preset category set includes at least numeric, date, string, boolean, and unknown categories, with each preset category corresponding to a set of data type names. The mapping process reads the data type name of each field in the field description mapping table one by one, and searches for that data type name in a preset category set: if the data type name belongs to the name set corresponding to the numeric category (e.g., integer type, floating-point type belongs to the numeric category), then the data type classification result of that field is labeled as numeric; if it belongs to the name set corresponding to the date category (e.g., date type, datetime type belongs to the date category), then it is labeled as date; if it belongs to the name set corresponding to the string category, then it is labeled as string; if it belongs to the name set corresponding to the boolean category, then it is labeled as boolean; if it cannot be found in any defined name set, then it is labeled as unknown category. After the mapping is completed, each field obtains a data type classification result with uniform granularity. This data type classification result eliminates the heterogeneity between different ontology source data type vocabularies, providing a normalized type basis for type consistency constraint verification and grouping priority weight calculation. For example, the data type names of fields such as passenger number, flight number, and name are all string type in the civil aviation ontology, and after mapping, their data type classification results are uniformly labeled as string type; the data type name of the delay duration field may be integer type, but after mapping, it is labeled as numeric type.

[0047] Preferably, after obtaining the three intermediate products—uniqueness constraint flag allocation result, enumeration constraint list, and data type classification result—each field in the field description mapping table is used as an organizational unit to aggregate the above three metadata items belonging to the same field, constructing the field constraint metadata corresponding to that field. The aggregation process uses the field name as the association key, extracting the uniqueness constraint flag corresponding to the field from the uniqueness constraint flag allocation result, extracting the enumeration constraint list corresponding to the field from the enumeration constraint list (if the enumeration constraint flag of the field is false, the enumeration constraint list is an empty list), and extracting the data type classification result corresponding to the field from the data type classification result. These three pieces of data are merged into a single field constraint metadata entry. The field constraint metadata entry is encapsulated using a predefined data structure, and each field constraint metadata entry contains at least three attribute slots: uniqueness constraint flag, enumeration constraint list, and data type classification result. All field constraint metadata entries constitute complete field constraint metadata, which, along with the field role label, serves as the core input for constructing field rule objects in subsequent steps. Through this aggregation process, constraint information that was originally scattered in different parsing processes is organized into a unified metadata entry with field granularity, forming a field feature dimension that is orthogonal and complementary to the field role label, eliminating the redundancy problem of the optimizer obtaining local constraint attributes from scattered configurations at each stage.

[0048] Preferably, the construction process of the above-mentioned field constraint metadata links three stages of parsing and mapping operations: In the first stage, unique constraint markers are extracted and translated from the uniqueness declarations and configuration files of the preset ontology definition file, converting textual functional attribute declarations into Boolean markers that can be efficiently queried by the program; in the second stage, a finite set of allowed values ​​and label mappings are identified and extracted from the field's annotations and value constraints, converting the enumeration knowledge described in natural language or markup language into a structured list of enumeration constraints; in the third stage, heterogeneous data type names are semantically categorized into a finite set of preset categories, abstracting the detailed but messy data type labels into a normalized data type classification result. There is no strict sequential dependency between the three stages, but they are unified in the aggregation stage, ensuring that the field constraint metadata includes not only the field's value space constraints, but also the field's numerical morphological characteristics and the field's entity distinguishing ability identifier. This multi-dimensional constraint metadata construction method differs from the traditional approach of hard-coding uniqueness judgment, enumeration parsing, and type checking across various optimizer modules. It allows field constraint metadata to be generated and reside in memory all at once during the system warm-up phase. As a result, when the query optimizer initiates a field feature query, it does not need to repeatedly scan the ontology definition source file or load external configurations. It only needs to read the field constraint metadata entry corresponding to the field to obtain the complete constraint profile of the field in constant time. This provides a consistent and cohesive field constraint data foundation for subsequent operations such as aggregation grouping priority weight calculation and query plan correction.

[0049] Optionally, step S2, calculating the aggregation group priority weight corresponding to each field in the field description mapping table, includes: extracting fields corresponding to field role tags that match the field constraint metadata from the field description mapping table; calling a preset role weight configuration table to assign basic group priority weights to the extracted fields; determining the fields belonging to business identifier roles and internal identifier roles among the fields corresponding to field role tags that match the field constraint metadata, assigning a preset weight bonus coefficient to the fields of business identifier roles, and assigning a preset weight penalty coefficient to the fields of internal identifier roles; adjusting the basic group priority weights based on the preset weight bonus coefficients and preset weight penalty coefficients to obtain the adjusted group priority weights; determining the business attribute configurations of all fields in the field description mapping table, and calculating the aggregation group priority weight corresponding to each field in the field description mapping table based on the adjusted group priority weights and the business attribute configurations of all fields.

[0050] Preferably, in the process of calculating the aggregation grouping priority weights corresponding to each field in the field description mapping table, the fields corresponding to the field role tags that match the field constraint metadata are first extracted from the field description mapping table as a candidate grouping field set. This extraction action uses each field in the field description mapping table as a traversal unit, reads the field constraint metadata entry corresponding to that field in the field constraint metadata, and then obtains the field role tag that has been assigned to that field in the final role allocation result. The extraction action is filtered according to a preset role grouping rule, which defines which fields corresponding to the field role tags are eligible to participate in the calculation of aggregation grouping priority. The role grouping rule sets that fields of metric roles are generally not used for grouping because these fields carry continuous aggregable values ​​and lack discrete distinguishing ability in grouping semantics, so they are excluded from the candidate grouping field set; while fields of finite attribute roles are included in the candidate grouping field set because their values ​​come from finite discrete sets, fields of business identifier roles and internal identifier roles have entity distinguishing ability, fields of timestamp roles can be used for time dimension aggregation, and fields of descriptive roles, although free text, can also be used for grouping in certain business scenarios. Taking the civil aviation ontology as an example, the field description mapping table includes fields such as passenger ID, frequent flyer class, flight number, scheduled departure time, delay duration, flight status, and city name. Each field is assigned a role label based on the final role allocation result: passenger ID corresponds to the internal identifier role, frequent flyer class to the limited attribute role, flight number to the business identifier role, scheduled departure time to the timestamp role, delay duration to the metric role, flight status to the limited attribute role, and city name to the descriptive role. The extraction action iterates through these fields. Because the delay duration's role label is a metric role, it is excluded from the candidate grouping field set according to the role grouping rules. All other fields are included in the candidate grouping field set. Therefore, the candidate grouping field set contains six fields: passenger ID, frequent flyer class, flight number, scheduled departure time, flight status, and city name. Each of these fields is eligible to participate in the aggregation grouping priority sorting.

[0051] Preferably, after obtaining the candidate grouping field set, a preset role weight configuration table is invoked to assign a basic grouping priority weight to each field in the candidate grouping field set. The preset role weight configuration table is a mapping structure with field role labels as index keys and basic weight values ​​as values. This mapping structure is pre-defined based on the general grouping applicability of each field role in aggregate queries. In the preset role weight configuration table, finite attribute roles, due to their naturally discrete values ​​and business analysis dimension significance, are assigned higher basic weight values ​​(e.g., 1.0); business identifier roles and internal identifier roles, as a major category of identifier roles, are assigned medium basic weight values ​​(e.g., 0.7); timestamp roles are assigned lower basic weight values ​​(e.g., 0.3); descriptive roles are assigned even lower basic weight values ​​(e.g., 0.2); and measurement roles are assigned the lowest basic weight values ​​(e.g., 0.0) to indicate that they are generally unsuitable as grouping fields. The invocation process uses the field role label of each field in the candidate grouping field set as the query key to perform a lookup in the preset role weight configuration table, and assigns the found basic weight value as the basic grouping priority weight for that field. Following the civil aviation scenario, the role labels for frequent flyer level and flight status are both limited attribute roles, and after searching, they respectively obtain a basic grouping priority weight of 1.0; the role label for flight number is business identifier role, obtaining a basic grouping priority weight of 0.7; the role label for passenger number is internal identifier role, also obtaining a basic grouping priority weight of 0.7; the role label for scheduled departure time is timestamp role, obtaining a basic grouping priority weight of 0.3; and the role label for city name is descriptive role, obtaining a basic grouping priority weight of 0.2.

[0052] Preferably, after allocating the basic grouping priority weights, for fields in the candidate grouping field set belonging to the business identifier role and the internal identifier role, a differentiated weight adjustment is further performed to reflect the different applicability of these two types of identifiers in aggregated grouping. This adjustment action first reads the sub-label information already labeled for each field in the field constraint metadata. Sub-labels are detailed markers added to identifier role fields during the field role classification stage based on field name patterns or semantic features, including at least internal identifier sub-labels and business identifier sub-labels. For fields in the candidate grouping field set whose field role label is identifier role and whose sub-label is business identifier, a preset weight bonus coefficient is assigned. This weight bonus coefficient is a value greater than zero (e.g., 0.5), indicating that business identifiers have a higher grouping priority than ordinary identifiers in grouping queries due to their business readability and external interaction value. For fields in the candidate grouping field set whose field role label is identifier role and whose sub-label is internal identifier, a preset weight penalty coefficient is assigned. This weight penalty coefficient is a value greater than zero and less than one (e.g., 0.5), indicating that internal identifiers are usually surrogate keys generated internally by the system and have no business meaning for end users; their applicability in grouping queries should be reduced. The adjusted group priority weight of a field for the Business Identifier role is obtained by adding its base group priority weight to the weighting factor. Similarly, the adjusted group priority weight of a field for the Internal Identifier role is obtained by multiplying its base group priority weight to the weighting penalty factor. For other fields in the candidate grouping field set that do not belong to the Identifier role, their adjusted group priority weight is their base group priority weight. In the civil aviation scenario, the Flight Number field, with the Identifier role label and Business Identifier sub-label, has its base group priority weight of 0.7 added to the weighting factor of 0.5, resulting in an adjusted group priority weight of 1.2. The Passenger Number field, with the Identifier role label and Internal Identifier sub-label, has its base group priority weight of 0.7 multiplied to the weighting penalty factor of 0.5, resulting in an adjusted group priority weight of 0.35. Frequent flyer class, flight status, scheduled departure time, and city name do not belong to the Identifier role, and their adjusted group priority weights remain 1.0, 1.0, 0.3, and 0.2, respectively.

[0053] Preferably, after obtaining the adjusted grouping priority weights of each field, the business attribute configurations of all fields in the field description mapping table are further read to comprehensively calculate the final aggregated grouping priority weights corresponding to each field. The business attribute configuration is a declaration extracted from a preset configuration file or ontology annotation, specifying whether a field is forcibly included in or excluded from grouping in a specific business analysis scenario. The business attribute configuration may include a grouping blacklist flag and a grouping preference flag: if the grouping blacklist flag is true, it means that regardless of the field's role and basic weight, it should not be used as a grouping field in this business scenario; if the grouping preference flag is true and the field's original adjusted grouping priority weight is low, its weight can be increased to above the preset minimum usable threshold. The calculation process iterates through all fields in the field description mapping table (not just those in the candidate grouping field set). For each field, it first checks if the grouping blacklist flag in its business attribute configuration is true. If true, the aggregated grouping priority weight of that field is directly set to zero, indicating forced exclusion of the group. If the grouping blacklist flag is false, it uses the adjusted grouping priority weight of that field as a basis to continue checking if the grouping preference flag in its business attribute configuration is true. If true and its adjusted grouping priority weight is lower than the preset minimum preference threshold, its aggregated grouping priority weight is increased to the minimum preference threshold. In a civil aviation analysis scenario, the preset configuration file sets the grouping blacklist flag to true for the city name field and the grouping preference flag to true for the flight status field, with the preset minimum preference threshold set to 0.8. The process iterates through the field description mapping table. The city name field, marked as true in the grouping blacklist, has its aggregation grouping priority weight set to zero. The flight status field, marked as false in the grouping blacklist, has an adjusted grouping priority weight of 1.0. The grouping preference field, marked as true but with a weight no lower than the minimum preference threshold of 0.8, retains its final aggregation grouping priority weight of 1.0. The flight number field, marked as false in the grouping blacklist, has a final aggregation grouping priority weight of 1.2. The frequent flyer class field has a final weight of 1.0. The passenger number field has a final weight of 0.35. The scheduled departure time field has a final weight of 0.3. Although the delay duration field is not included in the candidate grouping field set, it remains within the iteration range, and its final aggregation grouping priority weight remains zero. Through this process, the aggregation grouping priority weight corresponding to each field in the field description mapping table is determined. Each aggregation grouping priority weight is a numerical value that can be used for quantitative comparison; fields with higher values ​​are more suitable as grouping criteria in aggregation queries.

[0054] Preferably, the above-described aggregation grouping priority weight calculation process, consisting of four steps—extraction, basic allocation, differentiated adjustment, and business configuration coverage—organically connects the preset role weight configuration table, sub-tags, weight bonus coefficients, weight penalty coefficients, and business attribute configurations, using field role labels as clues. This forms a derivation path from qualitative field role analysis to quantitative grouping priority analysis. Continuing with the example of the civil aviation ontology scenario, the final calculated aggregation grouping priority weights are: Flight Number 1.2, Flight Status 1.0, Frequent Flyer Level 1.0, Passenger Number 0.35, Scheduled Departure Time 0.3, City Name 0.0, and Delay Duration 0.0. Therefore, the Flight Number, due to its high distinguishability as a business identifier and weight bonus, becomes the optimal choice for grouping; Flight Status and Frequent Flyer Level follow closely as limited attributes; Although the Passenger Number is an identifier, its priority is significantly reduced after internal identifier penalties; Scheduled Departure Time, as a timestamp, receives lower priority; City Name is excluded due to the blacklist; and Delay Duration is excluded as a metric. The priority of each field in the grouped query is quantified into a set of sortable aggregation group priority weight values. When the query optimizer calls the weight sorting interface, it can directly use these values ​​to sort in descending order and quickly generate an aggregation group candidate list. For example, it can output the top few most suitable fields for grouping in the order of flight number, flight status, frequent flyer class, passenger number, and scheduled departure time.

[0055] Preferably, the above-mentioned method for calculating the priority weight of aggregation groups differs from the existing practice of hard-coding the applicability of grouping fields in the query optimizer code, and also differs from the scheme that determines whether a group can be grouped based on a single role label without distinguishing the degree of priority. By introducing a pre-defined role weight configuration table, this application solidifies the experiential knowledge of the applicability of role grouping for each field within the domain into a configurable weight mapping. For example, in the civil aviation field, a high weight of 1.0 is assigned to limited attributes, while a weight of zero is assigned to metrics, so that flight status and frequent flyer status automatically obtain higher grouping priority. By introducing a weighting factor to reward business identifier roles and a weighting penalty factor to suppress internal identifier roles, this application establishes a sub-label-based quantification mechanism within the broad role category of identifiers. This results in a significant difference in grouping priority between flight numbers and passenger numbers, even though both are identifiers, with flight numbers having a weight of 1.2 and passenger numbers having a weight of 0.35, thus pushing business-readable flight numbers to the top of the grouping candidate list. By introducing a blacklist and preference flags for business attribute configuration, this application provides business implementers with an intervention channel to cover the automatically calculated results in specific analysis scenarios. For example, city names can be forcibly excluded to avoid interference from dirty data, and flight status can be given a preference boost to obtain equal competitiveness among multiple limited attributes. The combination of these three mechanisms enables the final calculated aggregation grouping priority weight to reflect a comprehensive consideration of three dimensions: the semantic applicability of the field grouping, the business readability of the identifier, and the specific needs of the business scenario. This provides a directly comparable quantitative basis for the query optimizer to quickly select the optimal grouping field through the weight sorting interface during the plan construction phase.

[0056] Optionally, S3 generates corresponding field rule objects for each field in the field description mapping table based on the field role tags, the field constraint metadata, and the aggregation group priority weights, and stores them in the memory cache space. The field rule object is a structured object carrying all metadata of a single field. This includes: performing association aggregation and encapsulation processing on the field role tags, the field constraint metadata, and the aggregation group priority weights to generate corresponding field rule objects for each field in the field description mapping table. The field rule object is a structured object carrying all metadata of a single field. All the field rule objects are assembled into a unified field rule set. The constructed field rule set is stored in the memory cache space, and a standardized query interface is constructed based on the field rule set stored in the memory cache space. The standardized query interface is called by the query optimizer.

[0057] Preferably, in the process of generating corresponding field rule objects for each field in the field description mapping table based on field role labels, field constraint metadata, and aggregation group priority weights, the process first performs association aggregation encapsulation processing on each field in the field description mapping table as a processing unit. This processing reads the field role label assigned to the field in the final role allocation result, extracts the uniqueness constraint flag, enumeration constraint list, and data type classification result corresponding to the field from the field constraint metadata, and obtains the aggregation group priority weight value corresponding to the field from the calculated aggregation group priority weight. The above metadata items are aggregated and encapsulated according to a predefined data structure to generate a field rule object identified by the field name. This field rule object is a structured object that carries all metadata of a single field. It contains at least field role label slots, sub-label slots, uniqueness constraint flag slots, enumeration constraint list slots, data type classification result slots, and aggregation group priority weight slots. It may also additionally contain semantic label slots, text annotation slots, and source identifier slots. The source identifier is used to record how the field role label was obtained, such as whether it came from heuristic rule classification or large language model batch classification. Taking the flight status field in the civil aviation ontology as an example, after performing association aggregation encapsulation processing, the generated flight status field rule object contains the following: the field role label slot takes the value of a limited attribute role; the sub-label slot is empty; the uniqueness constraint flag slot is false; the enumerated constraint list slot contains three mapping entries: on-time to on-time, delay to delay, and cancellation to cancellation; the data type classification result slot is for string categories; the aggregation grouping priority weight slot is 1.0; and the source identifier slot can be recorded as a batch classification for a large language model. Through this processing, each field in the field description mapping table is converted into a field rule object with highly integrated internal metadata, eliminating the fragmentation problem of field characteristic information scattered across different data structures.

[0058] Preferably, after obtaining the field rule objects corresponding to each field, these field rule objects are assembled into a unified field rule set. The assembly process uses the field name as the association key to gather the scattered field rule objects into a mapping container. This mapping container supports fast lookup using the field name as an index. The field rule set is the collection of all field rule objects, and its internal structure can be represented as a key-value pair mapping, where the key is the field name and the value is the field rule object corresponding to that field. During the assembly process, a final completeness check is performed on the metadata from different processing stages. For example, it checks whether each field rule object must have a field role tag; if any is missing, it is supplemented according to preset default rules. After assembly, the field rule set constitutes a unified metadata view covering all fields in the current preset ontology definition file. This view simultaneously carries all characteristics of each field in the query optimization process, including its role semantics, value constraints, numerical form, and grouping priority. Following the civil aviation scenario, the assembled field rule set will include passenger number field rule objects, flight number field rule objects, scheduled departure time field rule objects, delay duration field rule objects, flight status field rule objects, frequent flyer class field rule objects, city name field rule objects, etc. Each field rule object can be directly retrieved in the field rule set by its field name, thus providing a single entry point for data access capability for the upper-level query optimization module.

[0059] Preferably, the completed field rule set is stored in a memory cache space, enabling the query optimizer to retrieve complete metadata for any field with low access latency during runtime. The memory cache space is a high-speed read / write storage area allocated during the system warm-up phase, with a lifecycle covering the entire system runtime. The storage operation writes the entire field rule set to the memory cache space via serialization or direct reference, ensuring that every field rule object in the field rule set resides in memory, avoiding latency caused by disk or network access to the ontology file in subsequent query optimization stages. Based on this, a standardized query interface is further constructed using the field rule set already residing in the memory cache space, for use by various processing stages of the query optimizer. The standardized query interface is an abstract encapsulation of the field rule set access logic. Its internal implementation receives query parameters from the caller, performs query location on the field rule set in the memory cache space, and returns the query results in a predefined format. The standardized query interface includes at least a role query interface, a weight sorting interface, an internal identifier determination interface, and a role-based filtering interface. The role query interface allows callers to retrieve the role tag for a given field name, mapping it to the corresponding role tag slot in the field rule object within the field rule set, and then returning the value. The weight sorting interface allows callers to obtain a candidate list of aggregation groups, sorted in descending order of aggregation group priority weight for all fields in the field description mapping table. Internally, it iterates through all field rule objects in the field rule set, extracts the aggregation group priority weight slot value for each field rule object, sorts the field names and weight values ​​in descending order, and generates and returns the candidate list of aggregation groups. The internal identifier determination interface allows callers to determine whether a given field is an internal identifier role. Internally, it accesses the role tag slot and sub-tag slot of the corresponding field rule object; it returns true if the field role tag is an identifier role and the sub-tag is an internal identifier sub-tag, otherwise it returns false. The role-based filtering interface allows callers to input a role type and returns a list of field names that match the role tags in all fields within the field rule set.

[0060] Preferably, the above query process is explained using a civil aviation ontology scenario as an example. During system runtime, when processing natural language input from the user, the query optimizer needs to penalize the candidate field set to reduce the probability of the internal identifier field being mistakenly selected as a query return value. At this time, the query optimizer calls the internal identifier determination interface in the standardized query interface, passing in the field name "passenger number". The internal identifier determination interface locates the field rule object corresponding to the passenger number in the field rule set, reads its field role label as "internal identifier role" and its sub-label as "internal identifier sub-label", determines the result as true, and returns it. Based on this, the query optimizer applies a penalty to the passenger number field, excluding it from the candidate field set or lowering its ranking. When performing aggregation grouping queries, the query optimizer calls the weight sorting interface. This interface iterates through all field rule objects in the field rule set, extracting the aggregation grouping priority weights: flight number (1.2), flight status (1.0), frequent flyer class (1.0), passenger number (0.35), scheduled departure time (0.3), city name (0.0), and delay duration (0.0). After sorting these in descending order, it generates a candidate list of aggregation groups, such as flight number, flight status, frequent flyer class, passenger number, scheduled departure time, etc. The query optimizer can then select the top few fields as grouping criteria to construct the aggregation query operator. When parsing user-input terms and verifying their validity, the query optimizer calls the role query interface, passing in the field name mapped to the user term to obtain the field role label. Based on the role type, it decides whether to include the field in the query. This interface call method eliminates the need for each module of the optimizer to repeatedly implement independent logic for field role determination in their own code. Instead, they all rely on the metadata query service provided by the field rule set and standardized query interface, thus achieving centralization and consistency in field metadata access logic.

[0061] Preferably, the generation of the aforementioned field rule objects, the assembly of the field rule set, the storage of the memory cache space, and the construction of the standardized query interface together constitute the unified field metadata layer in this application. This field metadata layer organically integrates data that was originally scattered in hard-coded rules, independent configuration files, and ontology source files into a structured field rule set, and provides standardized query services to the outside world in a high-performance, memory-resident form. Using the field rule object as the data carrier, the multi-dimensional metadata features of each field, such as field role labels, sub-labels, uniqueness constraint flags, enumeration constraint lists, data type classification results, and aggregation grouping priority weights, are centrally encapsulated in a unified container. This allows the query optimizer to obtain the complete feature profile of the required field in a single call through the standardized query interface when performing candidate bundle search, plan construction, field parsing, and other stages of processing, without having to read different storage locations or call different parsing logic multiple times. Unlike existing technologies where each module of the optimizer maintains its own field role judgment logic and constraint information, this application reduces the coupling of the optimizer's internal code by constructing a centralized field rule set and providing a unified query interface. When an ontology field is added or the role classification rules are adjusted, the field rule set only needs to be regenerated and the memory cache space refreshed during the system warm-up phase. Each module of the query optimizer can transparently obtain the updated metadata without modification, thereby improving the system's dynamic adaptability and maintenance efficiency.

[0062] Optionally, the field rule set is a collection of all the field rule objects. Each field rule object internally carries at least one of the following: field role labels, sub-labels, uniqueness constraint flags, enumeration constraint lists, data type classification results, and multi-dimensional metadata features of aggregation group priority weights. The enumeration constraint list contains a finite set of allowed values ​​and their label mapping relationships.

[0063] Preferably, the field rule set is a collection of all field rule objects, and each field rule object is a unified data carrier formed by structurally encapsulating all metadata features of a single field in the field description mapping table after field role classification, field constraint metadata construction, and aggregation grouping priority weight calculation. The multi-dimensional metadata features carried within the field rule object include at least six types: field role tags, sub-tags, uniqueness constraint flags, enumeration constraint lists, data type classification results, and aggregation grouping priority weights. These six types of features converge from different technical processing stages, collectively forming a complete business profile of a field in the query optimization process. Field role tags come from the final role allocation results, defining the role the field plays in query optimization, such as identifier role, measure role, limited attribute role, timestamp role, or descriptive role. Sub-tags are detailed markers attached to identifier role fields during the field role classification stage, used to distinguish internal identifiers from business identifiers. Uniqueness constraint flags come from field constraint metadata, indicating in Boolean form whether the field's value is unique within the scope of its class instance. The enumeration constraint list also originates from the field constraint metadata. Its internal structure is a list containing a finite set of allowed values ​​and their corresponding labels. Each entry in the list records the correspondence between a allowed value and the user-facing label for that value. The data type classification result comes from the field constraint metadata, labeling the field's data form using one of the preset categories, such as numeric, date, string, boolean, or unknown. The aggregation grouping priority weight comes from the aggregation grouping priority weight calculation stage and is a numerical value that can be used for quantitative comparison; fields with higher values ​​are more suitable for grouping in aggregation queries. These six metadata features are encapsulated in the same field rule object, allowing the query optimizer to retrieve all the metadata of a field at once by searching for the corresponding field rule object using the field name, without having to read it separately from different data sources or configuration files.

[0064] Preferably, taking the civil aviation ontology scenario as an example, the internal structure and content of the field rule object are explained. In this scenario, after all the processing in the system warm-up phase, each field in the field description mapping table is generated into a corresponding field rule object, and these field rule objects together constitute the field rule set. Taking the flight status field rule object as an example, its internal field role label slot has a finite attribute role value, indicating that the field value comes from a finite discrete set, which has high applicability in grouped queries; the sub-label slot is empty because flight status does not belong to the identifier role and does not need to be further subdivided; the uniqueness constraint flag slot is false, indicating that different flights can have the same flight status, and the value of this field is not unique; the enumeration constraint list slot contains three mapping entries, namely on-time to on-time, delay to delay, and cancellation to cancellation, where the first part of each entry is the allowed value and the second part is the label displayed to the user. This enumeration constraint list can be used when the query optimizer needs to verify whether the status value entered by the user is valid or to map it to a normalized value; the data type classification result slot is string category, indicating that this field stores text data; the aggregation group priority weight slot is 1.0, indicating that this field is a high-priority grouping candidate field in aggregation queries. Taking the delay duration field rule object as an example, its field role label slot is set to the measurement role, indicating that the field carries a continuous numerical value that can be aggregated and cannot be used for grouping; the sub-label slot is empty; the uniqueness constraint flag slot is false; the enumeration constraint list slot is an empty list; the data type classification result slot is a numeric category; and the aggregation grouping priority weight slot is 0.0, indicating that it is completely excluded as a grouping field. Taking the passenger number field rule object as another example, its field role label slot is set to the identifier role, and the sub-label slot is set to the internal identifier, indicating that the field is a surrogate key generated internally by the system and has no business meaning for end users; the uniqueness constraint flag slot is true, indicating that each passenger's number is unique; the enumeration constraint list slot is an empty list; the data type classification result slot is a string category; and the aggregation grouping priority weight slot is 0.35, because it belongs to the internal identifier role and is subject to a weight penalty, it has a low priority in grouping queries. The three examples above demonstrate that the field rule object uses a consistent internal slot structure to standardize and encapsulate the metadata of fields with different roles, constraints, and priorities, eliminating the problems of scattered storage and inconsistent formats of field characteristic information in different data structures.

[0065] Preferably, the enumeration constraint list carried within the field rule object has a specific structural composition. The enumeration constraint list is an ordered or unordered container of entries, where each entry is a key-value pair structure. The key is the allowed value, and the value is the value label corresponding to that allowed value. Allowed values ​​are the canonical values ​​permitted for the field in the ontology definition or data source, and the value label is the user-readable representation of that canonical value; a mapping relationship is established between the two. In the civil aviation ontology, the enumeration constraint list for the flight status field contains three entries: entry one allows the value of "on time" with the value label "on time"; entry two allows the value of "delay" with the value label "delay"; and entry three allows the value of "cancellation" with the value label "cancellation". When the query optimizer processes a user's natural language query, if the user uses an expression from the value label such as "delay", the optimizer can reverse-map it to the allowed value of "delay" through the enumeration constraint list, thereby generating a syntactically correct underlying query statement. When the query results need to be displayed to the user, the optimizer can map the allowed values ​​back to the value labels, presenting them in language that is easy for the user to understand. Furthermore, the enumeration constraint list is also used by the query optimizer to filter the candidate field set during the plan construction phase. If a field has a non-empty enumeration constraint list, it indicates that the field has a finite attribute role, and its values ​​are easier to group and aggregate in the response. The optimizer can therefore increase the priority of this field in the candidate field set. This design of the enumeration constraint list transforms the value constraint information, which originally existed only in the ontology file in the form of natural language comments and was difficult for the program to consume directly, into structured key-value pair mapping data, which is built into the field rule object. This allows the query optimizer to directly obtain structured constraint knowledge through the field rule object when handling tasks such as value validation, term mapping, and grouping decisions at each stage, without having to re-parse the original comment text.

[0066] Preferably, the sub-labels and uniqueness constraint flags carried within the field rule object work together to finely differentiate identifier-type fields. Sub-labels are further classification markers added to identifier role fields during the field role classification stage based on the pattern and semantic characteristics of the field name. Their value space includes at least internal identifiers and business identifiers. Internal identifier sub-labels indicate that the field is a surrogate primary key generated by the system for technical implementation purposes. Although it has uniqueness and entity differentiation capabilities at the ontology level, it lacks readability and understandability in business interactions and query outputs for end users. Business identifier sub-labels indicate that although the field belongs to the identifier role, its value has business meaning and external interaction value, such as flight number or order number. In queries, it can be used as an entity differentiation condition or as a result field displayed to the user. Uniqueness constraint flags mark whether the value of the field is unique within its instance scope from the ontology constraint or configuration level. In the field rule object, sub-labels and uniqueness constraint flags can coexist and point to the same field. Taking the passenger number field rule object as an example, its sub-label is an internal identifier, and its uniqueness constraint flag is true. This set of metadata characteristics allows the query optimizer to determine that this field is not suitable as a query result to be displayed to the user during the candidate cluster search phase, but it can be used as an efficient join key when constructing table join conditions. Taking the flight number field rule object as an example, its sub-label is a business identifier, and its uniqueness constraint flag is true. Based on this, the query optimizer determines that this field can be used as a grouping basis and as a query result, and it receives a weight bonus in the aggregation grouping priority weight calculation. Through the coexistence and cooperation of sub-labels and uniqueness constraint flags within the field rule object, the query optimizer no longer needs to check whether the field name ends with a certain preset character combination to determine whether the field is an internal identifier or a business identifier. Instead, it directly reads the pre-classified sub-labels and uniqueness constraint flags from the field rule object, thereby centralizing the field differentiation logic and improving execution efficiency.

[0067] Preferably, the data type classification result and aggregation grouping priority weight carried within the field rule object work together during the optimizer's plan construction phase to jointly influence the selection of grouping fields and the construction of aggregation operators. The data type classification result normalizes the data value format of a field to one of five preset categories: numeric, date, string, boolean, and unknown. This normalization eliminates the heterogeneity caused by different ontology source files potentially using different data type vocabularies. The aggregation grouping priority weight is a numerical value obtained by quantifying the applicability of the field as a grouping criterion in the aggregation query. When the query optimizer executes plan construction, if it needs to select grouping fields for the aggregation query, the optimizer calls the weight sorting interface. The weight sorting interface traverses all field rule objects in the field rule set, extracting the aggregation grouping priority weight and data type classification result for each field rule object. The optimizer excludes data types unsuitable as grouping criteria based on the data type classification result, such as reducing or excluding fields with an unknown data type classification result. Then, it sorts these fields in descending order according to the aggregation grouping priority weight to generate an aggregation grouping candidate list. Taking the civil aviation scenario as an example, the data type classification result of the flight number field rule object is string, with an aggregation grouping priority weight of 1.2; the data type classification result of the flight status field rule object is string, with an aggregation grouping priority weight of 1.0; the data type classification result of the frequent flyer level field rule object is string, with an aggregation grouping priority weight of 1.0; and the data type classification result of the delay duration field rule object is numeric, with an aggregation grouping priority weight of 0.0. When a user queries to calculate the average delay duration for each flight status, the optimizer obtains an aggregation grouping candidate list through the weight sorting interface, in which flight status is ranked before delay duration. Based on this, the optimizer selects flight status as the grouping field and delay duration as the aggregation metric field, constructing an aggregation query operator that conforms to the query semantics. This approach, where the data type classification result and aggregation grouping priority weight are uniformly provided by the field rule object, eliminates the need for the optimizer to hard-code the applicability rules for each data type in the code when selecting grouping fields, and also eliminates the need to maintain grouping priority logic separately for different field roles. All decision-making basis is directly read from the field rule object, thereby reducing the coupling between the optimizer's internal logic and the field metadata.

[0068] Preferably, all field rule objects in the field rule set are organized using a mapping structure with field names as index keys. This organization provides a unified and efficient field metadata access mode for each stage of the query optimizer. After the field rule set is built during the system warm-up phase, it resides in the memory cache. During subsequent formal operation, the query optimizer can retrieve the corresponding field rule object by using the field name as the query key at any time. The standardized query interface uniformly encapsulates the retrieval and reading behavior of the field rule set, allowing modules within the query optimizer such as candidate bundle search, plan construction, and field parsing to obtain the required metadata simply by calling the corresponding functional interfaces in the standardized query interface, without needing to understand the specific storage structure and metadata source details of the field rule set. For example, the candidate cluster search module calls the internal identifier determination interface, passing in the field name. This interface locates the corresponding field rule object in the field rule set, reads its field role label and sub-labels, and returns the determination result. The plan construction module calls the weight sorting interface, which traverses all field rule objects in the field rule set, extracts the aggregation group priority weights, sorts them in descending order, and returns the aggregation group candidate list. The field parsing module calls the role query interface, passing in the field name, and returns the field role label for that field, which is used for terminology mapping and applicability determination. This access architecture, centered on the field rule set and using standardized query interfaces as channels, transforms the scattered and heterogeneous access to field metadata by various modules of the query optimizer into a unified and standardized access to a single cache. When the preset ontology definition file changes, or when a new field is added or the role of an existing field is reclassified, the field role classification process and the calculation of field constraint metadata and aggregation group priority weights only need to be re-executed during the system warm-up phase, and the field rule set in the memory cache space needs to be refreshed. Modules of the query optimizer can then transparently use the updated metadata in subsequent queries without modifying their internal code, thereby improving the dynamic adaptability of the entire query optimization system to ontology evolution.

[0069] Optionally, S4, generating a structured query plan matching the original natural language problem includes: the standardized query interface performing field feature parsing processing on the retrieved field rule object to feed back the feature parsing result corresponding to the target field to the query optimizer; the query optimizer revising the initial query path generated internally by the query optimizer according to the field role labels included in the feature parsing result to obtain a revised query path, wherein the initial query path is a path structure representing the data retrieval order and connection method generated by the query optimizer based on the original natural language problem; the query optimizer penalizing the candidate field set involved in the initial query path to obtain a penalized candidate field set, wherein the candidate field set is a set of all fields to be used in the structured query plan initially selected by the query optimizer from the field description mapping table during the plan construction phase; the query optimizer constructing an aggregation query operator according to the aggregation group candidate list and aggregation group priority weight included in the feature parsing result, and generating a structured query plan matching the original natural language problem based on the revised query path, the penalized candidate field set, and the aggregation query operator.

[0070] Preferably, after the query optimizer parses the input natural language question to obtain the target field and initiates a field feature query request accordingly, the process of generating a structured query plan matching the original natural language question first involves the standardized query interface performing field feature parsing processing on the retrieved field rule objects. During the parsing of the original natural language question, the query optimizer has already associated the business terms involved in the question with one or more target fields in the field description mapping table through terminology mapping. Then, using the field name of the target field as a parameter, it calls the corresponding functional interface in the standardized query interface to initiate a field feature query request to the memory cache space. Based on the input field name, the standardized query interface locates and retrieves the field rule object corresponding to the target field in the field rule set. It then reads and assembles the multi-dimensional metadata features carried within the field rule object, such as field role labels, sub-labels, uniqueness constraint flags, enumeration constraint lists, data type classification results, and aggregation grouping priority weights, to generate a feature parsing result corresponding to the target field, and feeds this feature parsing result back to the query optimizer. The feature parsing results present the target field's complete business profile in the query optimization process to the query optimizer in a structured form, enabling the query optimizer to obtain all feature information of the field at once without having to access different configuration sources or execute independent judgment logic.

[0071] Preferably, simultaneously with or before the query optimizer obtains the feature parsing results, the query optimizer has internally generated an initial query path based on the semantic analysis of the original natural language question. This initial query path is a path structure initially constructed by the query optimizer based on the entities, conditions, and aggregation intents involved in the original natural language question, representing the data retrieval order and the inter-table join method. It defines the data tables to be accessed, the join relationships between tables, and the preliminary layout of data filtering conditions. Simultaneously, during the plan construction phase, the query optimizer initially selects a candidate field set from the field description mapping table. This candidate field set contains all fields that may be used in the query return results, grouping criteria, or filtering conditions in the current query context. Taking an original natural language question in the civil aviation field as an example, assuming the user inputs the question of querying the total delay time for each flight number, after parsing the question, the query optimizer identifies the involved entity as flights, the target output as flight number and delay time, and the aggregation intent as grouping by flight number and summing the delay times. The initial query path generated by the query optimizer will specify the flight table as the data source and lay out an initial plan structure with flight number as the grouping key and delay duration as the aggregation metric. At the same time, the candidate field set selected by the query optimizer from the field description mapping table may include fields that are potentially related to the query, such as flight number, scheduled departure time, delay duration, flight status, and passenger number.

[0072] Preferably, the query optimizer modifies the internally generated initial query path based on the field role labels included in the feature parsing results, resulting in a modified query path. The modification is based on the field role labels corresponding to each target field involved in the initial query path, as found in the feature parsing results. The query optimizer iterates through the target fields involved in the initial query path, reading the field role label from the feature parsing results for each target field. When a target field's field role label is "internal identifier," the query optimizer determines that although the field has the ability to uniquely identify entities at the ontology level, it lacks business readability for end users, and removes it from the list of returned result fields in the initial query path, retaining only its function as a table join key. When a target field's field role label is "measure," the query optimizer determines that the field is an aggregatable continuous value, adjusting its role in the initial query path to an operand for aggregation operations rather than a grouping or filtering field. When a target field's field role label is "finite attribute" and its feature parsing results' enumeration constraint list is not empty, the query optimizer determines that the field is suitable as a grouping criterion, adjusting its position in the initial query path to a candidate field for a grouping key. After the above field-by-field correction process, the query optimizer generates a revised query path. Compared to the initial query path, this revised path maintains consistency with the business role semantics of each field in terms of the selection of return result fields, arrangement of grouping fields, and assignment of aggregation operations. This reduces the risk of generating a query plan that does not conform to the user's intent due to role misjudgment. In the civil aviation scenario, assuming the initial query path originally included the passenger number as one of the return result fields, the query optimizer, based on the feature parsing result, identifies the passenger number field role as an internal identifier role and removes it from the list of return result fields. The revised query path only retains the flight number and delay duration as return results, using the flight number as the grouping key.

[0073] Preferably, after generating the corrected query path, the query optimizer applies penalty processing to the candidate field set involved in the initial query path, resulting in a penalized candidate field set. The purpose of penalty processing is to reduce the priority or directly exclude fields in the candidate field set that are unsuitable for appearing in the query results or unsuitable for grouping, thereby narrowing the selection range when constructing subsequent aggregation query operators. The query optimizer traverses each candidate field in the candidate field set, obtains the corresponding feature parsing result through the standardized query interface, and performs penalty judgment based on the field role label and sub-label contained therein. If the candidate field's field role label is "internal identifier" and its sub-label is "internal identifier," the query optimizer applies an exclusionary penalty to the candidate field, directly removing it from the candidate field set or resetting its ranking weight to zero, to prevent internal surrogate keys from being returned to the user as query results. If the candidate field's field role label is "descriptive" and its data type classification result is "numeric," the query optimizer determines that the field is a misclassified field, applies a weight reduction penalty to the candidate field, lowering its ranking position in the candidate field set. If a candidate field's role label is "measure," the query optimizer determines that while the field cannot be used as a grouping criterion, it can still be used as an operand in aggregation operations. Therefore, it applies an exclusionary penalty to the field's grouping candidate status in the candidate field set, but retains its status as a measure candidate. After this penalty process, the candidate field set no longer contains fields unsuitable for query output or grouping, resulting in a penalized candidate field set. In the civil aviation scenario, when querying the total delay time for each flight number, the candidate field set originally included passenger IDs. The query optimizer applies an exclusionary penalty based on the passenger ID's internal identifier role. The penalized candidate field set no longer includes passenger IDs, retaining only flight number, delay time, flight status, and other fields, thus avoiding displaying internal identifiers with no business meaning to the user.

[0074] Preferably, after obtaining the candidate field set after penalty processing, the query optimizer constructs an aggregation query operator based on the aggregation grouping candidate list and aggregation grouping priority weights included in the feature parsing results. The query optimizer obtains an aggregation grouping candidate list by calling the weight sorting interface in the standardized query interface, which sorts all fields in the field description mapping table in descending order of aggregation grouping priority weights. Each item in this aggregation grouping candidate list contains a field name and its corresponding aggregation grouping priority weight. The query optimizer performs an intersection analysis between the aggregation grouping candidate list and the penalty-processed candidate field set to generate a sequence of aggregation grouping candidate fields usable in the query context. Fields in this sequence are sorted from high to low aggregation grouping priority weights. Based on the aggregation intent parsed from the original natural language question, the query optimizer selects the top few fields with the highest aggregation grouping priority weights from the aggregation grouping candidate field sequence as grouping keys, and assigns fields labeled as "measurement value" as operands for aggregation operations, thus constructing the aggregation query operator. An aggregation query operator is a query execution unit that defines a grouping field, an aggregation function type, and an aggregation target field. For example, a grouping and summing operator might use flight number as the grouping field, summation as the aggregation function, and delay duration as the aggregation target field. In a civil aviation scenario, the query optimizer obtains an aggregation grouping candidate list from the weighted sorting interface. Flight number has an aggregation grouping priority weight of 1.2, flight status of 1.0, frequent flyer status of 1.0, and delay duration of 0.0. The query optimizer takes the intersection of the aggregation grouping candidate list and the penalized candidate field set. The flight number has the highest weight and matches the grouping intent in the intersection result. Delay duration is identified as a suitable metric for aggregation operations. Based on this, an aggregation query operator is constructed with flight number as the grouping field, delay duration as the aggregation target field, and summation as the aggregation function. This aggregation query operator can group the data in the flight table by flight number during execution and sum the delay duration within each group, thus outputting the user's expected result of the total delay duration for each flight number.

[0075] Preferably, after completing query path correction, candidate field set penalty processing, and aggregation query operator construction, the query optimizer generates a structured query plan matching the original natural language problem based on the corrected query path, the penalized candidate field set, and the aggregation query operator. The structured query plan is an execution scheme describing the data access order, table join methods, filtering conditions, grouping criteria, aggregation operations, and the list of returned fields. Internally, it organizes various query operators in a tree or graph structure, defining the complete data flow from data source reading to result output. The query optimizer uses the corrected query path as the main framework, attaches the returned result fields selected from the penalized candidate field set to this framework, embeds aggregation query operators at appropriate node positions, and rewrites and optimizes the filtering conditions based on the enumerated constraint list and data type classification results in the field rule object. For example, in a civil aviation scenario, for the original natural language problem of querying the total delay time for each flight number, the structured query plan generated by the query optimizer can be described as follows: using the flight table as the data source, performing a summation and aggregation operation on the delay time with the flight number as the grouping key, and returning a result set containing two columns: flight number and total delay time, excluding internal identifier fields such as passenger number. This structured query plan highly matches the true intent of the original natural language problem, and in its generation process, key decisions such as path correction, candidate penalties, and group selection directly rely on metadata provided by the field rule set, such as field role labels, sub-labels, enumeration constraint lists, and aggregation group priority weights, rather than the scattered rules hard-coded within the optimizer. This achieves an automated, centralized, and traceable decision chain from field metadata to the query plan.

[0076] Optionally, S4 further includes: obtaining the field role tag from the field rule object through the role query interface, and using the aggregation group priority weight in the field rule object to sort all fields in the field description mapping table in descending order through the weight sorting interface to generate an aggregation group candidate list.

[0077] Preferably, during the query optimizer execution plan construction process, field role tags are obtained from the field rule object through the role query interface. The role query interface is a functional interface within the standardized query interface, and its internal implementation logic encapsulates access operations to the field rule set in the memory cache space. When the query optimizer needs to know the field role tag of a target field in the query optimization process, it calls the role query interface with the field name of the target field as the input parameter. After receiving the call request, the role query interface performs a retrieval operation in the field rule set in the memory cache space using the passed field name as the query key, locates the field rule object corresponding to the field name, reads the field role tag value stored in the field role tag slot of the field rule object, and returns the field role tag value as the call result to the query optimizer. For example, in the civil aviation ontology scenario, after parsing the natural language input from the user, the query optimizer needs to determine the role of the field corresponding to the term "flight number" mentioned by the user in the query through term mapping. At this point, the query optimizer calls the role query interface with the flight number as a parameter. The role query interface locates the flight number field rule object in the field rule set, reads the business identifier role from its field role tag slot, and returns the business identifier role to the query optimizer. Based on this, the query optimizer determines that the flight number field can be used as an entity distinguishing condition, a grouping field, and a result field. This calling process allows the query optimizer to avoid repeatedly implementing field role determination rules in its own code logic, instead relying uniformly on the consistent metadata query service provided by the standardized query interface, thereby decoupling the field role determination logic from the core query processing logic of the query optimizer.

[0078] Preferably, in scenarios where the query optimizer needs to perform aggregated query grouping, the weight sorting interface uses the aggregation grouping priority weights in the field rule objects to sort all fields in the field description mapping table in descending order to generate an aggregation grouping candidate list. The weight sorting interface is another functional interface in the standardized query interface. Its internal implementation logic, each time it is called, it iterates through all field rule objects contained in the field rule set in the memory cache space. For each traversed field rule object, it reads the aggregation grouping priority weight value stored in its aggregation grouping priority weight slot and forms a weight pair with the field name corresponding to that field rule object and the read aggregation grouping priority weight value. After completing the traversal of all field rule objects, the weight sorting interface obtains a set of weight pairs, where each entry contains a field name and the aggregation grouping priority weight corresponding to that field. Subsequently, the weighted sorting interface uses the aggregation group priority weight as the sorting key to perform a descending sorting operation on all weighted pairs in the weighted pair set. This places the field with the highest aggregation group priority weight at the beginning of the sequence, the field with the second highest aggregation group priority weight at the next highest, and so on, until the field with the lowest aggregation group priority weight is placed at the end of the sequence. After sorting, the weighted sorting interface returns the sorted sequence of weighted pairs as an aggregation group candidate list to the caller. The order of the fields in this aggregation group candidate list reflects the recommended priority of each field as the grouping basis in the aggregation query. In the civil aviation ontology scenario, the field description mapping table includes fields such as passenger number, flight number, scheduled departure time, delay duration, flight status, frequent flyer class, and city name. The aggregation group priority weights corresponding to these fields are 0.35, 1.2, 0.3, 0.0, 1.0, 1.0, and 0.0, respectively. The weighted sorting interface iterates through the field rule objects of the aforementioned fields in the field rule set, extracts the aggregation grouping priority weights of each field, and forms a set of weighted pairings. After sorting the set of weighted pairings in descending order, the fields in the generated aggregation grouping candidate list are in the order of flight number, flight status, frequent flyer class, passenger number, and scheduled departure time. Delay duration and city name are placed at the end of the sequence or are directly excluded from the recommended grouping candidates because their weight is 0.0. After obtaining this aggregation grouping candidate list, the query optimizer can select several fields with the highest priority as grouping fields according to the aggregation intent of the current query, without having to evaluate the grouping applicability of each field itself.

[0079] Preferably, by using the role query interface and the weight ranking interface in combination, the query optimizer can quickly and in a standardized manner determine the role of the target field and prioritize the candidate fields for grouping during the plan construction phase. This provides a direct and usable decision basis for generating a structured query plan that matches the original natural language problem. In the specific processing flow, after obtaining the set of candidate fields, the query optimizer first obtains the field role label of each candidate field in the set through the role query interface. Based on the field role label, it performs a preliminary classification of the candidate fields: candidate fields with the field role label of "measure value role" are marked as aggregate operation operand candidates; candidate fields with the field role label of "limited attribute role" or "business identifier role" are marked as grouping field candidates; and candidate fields with the field role label of "internal identifier role" are excluded from the list of returned result candidates and grouping candidates. For example, in a civil aviation scenario, the query optimizer uses a role query interface to obtain the role labels for the flight number ("Business Identifier Role"), delay duration ("Measure Role"), and passenger number ("Internal Identifier Role"). Based on this, the flight number is marked as a candidate grouping field, the delay duration as a candidate aggregation operand, and the passenger number is excluded. Subsequently, the query optimizer calls a weighted sorting interface to obtain an aggregation grouping candidate list. This list is then matched against the set of fields already marked as grouping field candidates. The field with the highest aggregation grouping priority weight is selected as the grouping key. For example, if the flight number has the highest weight of 1.2 in the aggregation grouping candidate list returned by the weighted sorting interface, the query optimizer selects the flight number as the grouping key. Through this coordinated calling mechanism, the role determination and weighted sorting decisions are standardized into two interface calls. The query optimizer does not need to maintain any role determination rules or grouping priority calculation logic internally; all decision-making is dynamically obtained from the unified metadata layer of field rule sets.

[0080] Preferably, the design of the role query interface and the weight ranking interface allows the query optimizer to transparently perceive updates to field metadata without modifying its internal code. When the preset ontology definition file changes, or when new fields are added or existing field role tags are reclassified, the system re-executes the field role classification process and aggregate group priority weight calculation during the warm-up phase, generating an updated field rule set and refreshing the corresponding data in the memory cache. Subsequently, when the role query interface receives a call request from the query optimizer, it reads the field role tags from the updated field rule objects; when the weight ranking interface receives a call request, it iterates through the updated set of field rule objects, and the generated aggregate group candidate list automatically reflects the latest aggregate group priority weight ranking results. As the caller, the query optimizer's internal processing logic does not need to be aware of the specific update process of the field rule set; it only needs to maintain the same calling method for the role query interface and the weight ranking interface to automatically use the updated metadata in subsequent queries. This architecture, which separates interface encapsulation from metadata updates, enables the entire query optimization system to exhibit high dynamic adaptability in the face of ontology evolution and changes in business requirements. For example, if the default configuration file of the civil aviation ontology adds a setting to true for the grouping preference flag of the frequent flyer class field, the weight of the frequent flyer class may be increased after the system warm-up phase recalculates the aggregation grouping priority weights accordingly. Subsequently, the sorting position of the frequent flyer class in the aggregation grouping candidate list generated by the weight sorting interface will be moved forward accordingly. The query optimizer can automatically select the frequent flyer class as one of the grouping fields in subsequent aggregation queries without any modifications.

[0081] Preferably, the role query interface and weight ranking interface, as components of the standardized query interface, together with the internal identifier determination interface and the role-based filtering interface, constitute a unified field metadata access system for the query optimizer. When the query optimizer's candidate cluster search module performs penalty processing on the candidate field set, it calls the internal identifier determination interface to determine whether to apply an exclusionary penalty to a candidate field. When the query optimizer's plan construction module performs grouping field selection and aggregation query operator construction, it sequentially calls the weight ranking interface and the role query interface to obtain the grouping priority ranking and field role labels. When the query optimizer's field parsing module performs term mapping and field validity verification, it calls the role query interface and the role-based filtering interface to confirm the role type and availability of the target field. The underlying implementation of these four types of interfaces is based on unified access to the field rule set in the memory cache space. Their returned results all originate from the field metadata carried by the same field rule set, thus ensuring that the determination results for the role, constraints, and weights of the same field are consistent throughout all stages of query optimization, avoiding logical contradictions and query plan deviations that may arise from using different metadata sources at different stages. Taking the query of the total delay time for each flight number in a civil aviation scenario as an example, the candidate cluster search stage uses an internal identifier judgment interface to penalize and exclude passenger numbers from the candidate field set. In the plan construction stage, the flight number is selected as the grouping key through a weight sorting interface. After confirming the delay time as a metric role through a role query interface, it is assigned as the summation and aggregation operand. In the field parsing stage, the legal existence of the field corresponding to the user input term in the field rule set is confirmed through a role query interface. Throughout the process, all metadata queries are completed by calling different interfaces of the same field rule set. The information returned by each interface is consistent with each other and jointly supports the generation of a structured query plan that is highly consistent with the user's query intent.

[0082] like Figure 2 As shown, this is an embodiment of a field role construction and usage apparatus based on hierarchical classification, comprising: The first program unit loads a predefined domain ontology specification file as a preset ontology definition file. The preset ontology definition file contains specification descriptions of business concept classes, data attributes, and their interrelationships. The preset ontology definition file is parsed to extract all original data attribute information associated with the business concept classes that need to be constructed with field roles from the preset ontology definition file, so as to construct a field description mapping table and assign field role labels to each field in the field description mapping table. The second program unit extracts the ontology constraint features associated with each field in the field description mapping table from the preset ontology definition file, generates field constraint metadata based on the extracted ontology constraint features, and calculates the aggregation grouping priority weight corresponding to each field in the field description mapping table. The third program unit generates a corresponding field rule object for each field in the field description mapping table based on the field role label, the field constraint metadata, and the aggregation group priority weight, and stores it in the memory cache space. The field rule object is a structured object that carries all the metadata of a single field. The fourth program unit responds to the query optimizer parsing the input original natural language question to obtain the target field and initiates a field feature query request accordingly, so as to retrieve the field rule object corresponding to the target field in the memory cache space and generate a structured query plan that matches the original natural language question.

[0083] like Figure 3 The image shows an electronic device that includes a processor and a memory. The memory is used to store computer programs; When the processor executes the program stored in the memory, it implements the functions of each module of the device described in the embodiments of this application, or implements the steps of the method described.

[0084] Figures 2-3 For an exemplary description, please refer to the above. Figure 1 This will not be elaborated upon here.

Claims

1. A method for constructing and using field roles based on hierarchical classification, characterized in that, include: S1. Load a predefined domain ontology specification file as a preset ontology definition file. The preset ontology definition file contains specification descriptions of business concept classes, data attributes, and their interrelationships. Parse the preset ontology definition file to extract all original data attribute information associated with the business concept classes that need to be constructed for field roles, construct a field description mapping table, and assign field role labels to each field in the field description mapping table. S2. Extract ontology constraint features associated with each field in the field description mapping table from the preset ontology definition file, generate field constraint metadata based on the extracted ontology constraint features, and calculate the aggregation grouping priority weight corresponding to each field in the field description mapping table. S3. Generate corresponding field rule objects for each field in the field description mapping table based on the field role labels, the field constraint metadata, and the aggregation grouping priority weight, and store them in the memory cache space. The field rule object is a structured object that carries all metadata of a single field. S4. In response to the query optimizer parsing the input original natural language question to obtain the target field and initiating a field feature query request accordingly, the field rule object corresponding to the target field is retrieved in the memory cache space to generate a structured query plan that matches the original natural language question.

2. The method for constructing and using field roles based on hierarchical classification according to claim 1, characterized in that, S1 involves constructing a field description mapping table and assigning field role labels to each field in the field description mapping table, including: converting the original data attribute information into corresponding fields, where each field is a specific representation of the data attributes in the preset ontology definition file, to generate a field description mapping table containing all fields and their description information; applying a role classification process based on the field description mapping table to determine the field role labels that each field in the field description mapping table assumes in the query optimization process and assigning them to the corresponding fields in the field description mapping table.

3. The method for constructing and using field roles based on hierarchical classification according to claim 2, characterized in that, Based on the field description mapping table, a role classification process is applied to determine the field role labels that each field in the field description mapping table assumes in the query optimization process and assign them to the corresponding fields in the field description mapping table. This includes: performing heuristic rule classification on the field description mapping table to identify the preliminary roles of each field and generating preliminary role labeling results including identifier role labels, metric role labels, and timestamp role labels; extracting the field names, field comments, and example values ​​associated with the fields not covered in the preliminary role labeling results, and encapsulating the extracted field names, field comments, and example values ​​into a classification guidance prompt containing role assignment instructions; inputting the classification guidance prompt into a pre-trained large language model for structured role mapping processing to return a structured role mapping result containing the correspondence between field names and field role labels; and based on the structured role mapping result containing the correspondence between field names and field role labels, determining the field role labels that each field in the field description mapping table assumes in the query optimization process and assigning them to the corresponding fields in the field description mapping table.

4. The method for constructing and using field roles based on hierarchical classification according to claim 3, characterized in that, Based on the structured role mapping results containing the correspondence between field names and field role labels, the field role labels that each field in the field description mapping table assumes in the query optimization process are determined and assigned to the corresponding fields in the field description mapping table. This includes: parsing the structured role mapping results containing the correspondence between field names and field role labels returned by the pre-trained large language model to generate supplementary role mapping data; performing cross-logic verification on the preliminary role labeling results and the supplementary role mapping data to check whether there are fields with conflicting role assignments in the field description mapping table; if so, calling the preset configuration overriding logic to correct the field role labels corresponding to the fields with conflicting role assignments, so that each field in the field description mapping table has the field role labels that it assumes in the query optimization process.

5. The method for constructing and using field roles based on hierarchical classification according to claim 1, characterized in that, Step S2 generates field constraint metadata based on the extracted ontology constraint features, including: assigning unique constraint flags to each field in the field description mapping table based on the ontology constraint features; determining a finite set of allowed values ​​corresponding to each field in the field description mapping table to construct an enumerated constraint list reflecting the label mapping relationship between fields; determining the data type name corresponding to each field in the field description mapping table, and mapping the data type name to a preset category containing numeric, date, string, boolean, and unknown categories to generate a data type classification result corresponding to each field in the field description mapping table; and constructing the field constraint metadata based on the unique constraint flags, the enumerated constraint list, and the data type classification result.

6. The method for constructing and using field roles based on hierarchical classification according to claim 1, characterized in that, Step S2 calculates the aggregate grouping priority weight corresponding to each field in the field description mapping table, including: extracting fields corresponding to field role tags that match the field constraint metadata from the field description mapping table; calling a preset role weight configuration table to assign basic grouping priority weights to the extracted fields; determining the fields belonging to business identifier roles and internal identifier roles among the fields corresponding to field role tags that match the field constraint metadata, assigning a preset weight bonus coefficient to the fields of business identifier roles, and assigning a preset weight penalty coefficient to the fields of internal identifier roles; adjusting the basic grouping priority weights based on the preset weight bonus coefficients and preset weight penalty coefficients to obtain the adjusted grouping priority weights; determining the business attribute configurations of all fields in the field description mapping table, and calculating the aggregate grouping priority weight corresponding to each field in the field description mapping table based on the adjusted grouping priority weights and the business attribute configurations of all fields.

7. The method for constructing and using field roles based on hierarchical classification according to claim 5, characterized in that, S3. Based on the field role tags, field constraint metadata, and aggregation group priority weights, generate corresponding field rule objects for each field in the field description mapping table and store them in the memory cache space. The field rule object is a structured object that carries all metadata of a single field. This includes: performing association aggregation and encapsulation processing on the field role tags, field constraint metadata, and aggregation group priority weights to generate corresponding field rule objects for each field in the field description mapping table. The field rule object is a structured object that carries all metadata of a single field. Assemble all the field rule objects into a unified field rule set. Store the constructed field rule set in the memory cache space and build a standardized query interface based on the field rule set stored in the memory cache space. The standardized query interface is called by the query optimizer.

8. The method for constructing and using field roles based on hierarchical classification according to claim 7, characterized in that, The field rule set is a collection of all the field rule objects. Each field rule object internally carries at least one of the following: field role labels, sub-labels, unique constraint flags, enumeration constraint lists, data type classification results, and multi-dimensional metadata features of aggregation group priority weights. The enumeration constraint list contains a finite set of allowed values ​​and their label mapping relationships.

9. A method for constructing and using field roles based on hierarchical classification according to claim 7, characterized in that, S4. Generate a structured query plan matching the original natural language problem, including: the standardized query interface performs field feature parsing on the retrieved field rule object to provide the query optimizer with the feature parsing result corresponding to the target field; the query optimizer corrects the initial query path generated internally by the query optimizer based on the field role labels included in the feature parsing result to obtain a corrected query path, wherein the initial query path is a path structure generated by the query optimizer based on the original natural language problem, representing the data retrieval order and connection method; the query optimizer penalizes the candidate field set involved in the initial query path to obtain a penalized candidate field set, wherein the candidate field set is a set of all fields to be used in the structured query plan initially selected by the query optimizer from the field description mapping table during the plan construction phase; the query optimizer constructs an aggregation query operator based on the aggregation group candidate list and aggregation group priority weight included in the feature parsing result, and generates a structured query plan matching the original natural language problem based on the corrected query path, the penalized candidate field set, and the aggregation query operator.

10. A method for constructing and using field roles based on hierarchical classification according to claim 9, characterized in that, S4 further includes: obtaining the field role tag from the field rule object through the role query interface, and using the aggregation group priority weight in the field rule object to sort all fields in the field description mapping table in descending order through the weight sorting interface to generate an aggregation group candidate list.

Images