A natural language based database semantic mapping construction process

Abstract

The application discloses a natural language-based database semantic mapping construction process and relates to the technical field of database construction.The process comprises the following steps: S1, obtaining a natural language query sentence input by a user, and pre-processing the natural language query sentence to obtain a standardized query text and semantic features; the application divides the query into a fact query, an analysis query and a fuzzy exploration query by performing intention recognition and complexity evaluation on the natural language query first, and then dynamically activates a lightweight mapping template, a deep semantic analysis and a multi-table connection reasoning mechanism or an interactive clarification and candidate recommendation mechanism according to the query level, so that the fact query is quickly completed with field matching and condition generation, the analysis query obtains multi-table connection and aggregation reasoning support, and the fuzzy exploration query is clarified and candidate recommendation is recommended to determine the intention, thereby realizing dynamic balance between semantic mapping precision and allocation of computing resources.

Description

Technical Field

[0001] This invention relates to the field of database construction technology, specifically to a database semantic mapping construction process based on natural language. Background Technology

[0002] A database is a collection of data organized, stored, and managed according to data structures. It serves as the infrastructure for data persistence, sharing, retrieval, and analysis in various information systems. In scenarios such as enterprise management, internet services, e-commerce, and data analysis, databases undertake critical tasks such as storing massive amounts of business data, supporting transaction processing, and assisting in decision analysis. Their efficiency directly impacts the overall performance of the information system and the user experience. Database semantic mapping construction refers to the process of converting the user's query intent, expressed in natural language, into a structured semantic representation that the database can understand and execute. This process typically requires determining the target table, target fields, filtering conditions, inter-table joins, and operations such as aggregation, grouping, and sorting involved in the query, and organizing this semantic information into query statements suitable for the target database type. The accuracy and efficiency of database semantic mapping construction determine the usability of the natural language query interface.

[0003] Natural language, as the entry point for user interaction with databases, lowers the technical barrier to database use, enabling non-technical users to complete data queries and analysis without needing to master structured query languages. Accurately and efficiently mapping natural language queries into executable database queries is of great significance for improving data retrieval efficiency and expanding the scope of data applications.

[0004] Currently, existing natural language query interfaces typically employ a uniform mapping process when processing user queries, performing the same or similar preprocessing, semantic parsing, relation mapping, and statement generation steps on all queries. While this approach can handle some queries, it suffers from several problems due to the lack of differentiation between query complexity and intent type: For simple fact queries, the deep parsing and relational reasoning in the uniform process incur unnecessary computational overhead, lengthening response time; for analytical queries involving multi-table joins, aggregation calculations, and time comparisons, the uniform process's parsing depth and join reasoning capabilities are insufficient, leading to incomplete or incorrect mapping results; for exploratory queries with missing, broad, or ambiguous query objects, the uniform process often directly outputs incorrect or empty results, failing to guide users to clarify their true query intent. Therefore, existing technologies struggle to achieve a balance between semantic mapping accuracy and response efficiency, resulting in unreasonable allocation of computational resources. Thus, developing a database semantic mapping construction process based on natural language is of great significance. Summary of the Invention

[0005] The purpose of this invention is to overcome the shortcomings of existing technologies and provide a database semantic mapping construction process based on natural language. This process addresses the common problem in existing technologies that use a uniform mapping process when processing natural language queries. These processes perform similar semantic parsing and relational mapping steps indiscriminately on all queries, failing to dynamically adjust the mapping strategy according to the complexity and intent type of the query. This results in simple queries consuming too many parsing resources, complex queries having insufficient mapping accuracy, and fuzzy queries lacking effective clarification and guidance. Overall, there is a problem of balancing semantic mapping accuracy, response efficiency, and computational resource allocation.

[0006] To solve the above-mentioned technical problems, the present invention provides the following technical solution: a database semantic mapping construction process based on natural language, the process comprising the following steps:

[0007] S1. Obtain the natural language query statement input by the user, preprocess the natural language query statement to obtain standardized query text and semantic features;

[0008] S2. Perform intent recognition and complexity assessment on standardized query text and semantic features, and classify queries into fact queries, analytical queries, or fuzzy exploratory queries based on the intent recognition results and complexity assessment results.

[0009] S3. Based on the partitioning results, dynamically activate the semantic mapping links corresponding to the query level. If the query is a fact query, call the lightweight mapping template library to perform field matching and condition generation on the standardized query text to obtain the first semantic mapping result. If the query is an analytical query, start the deep semantic parsing and multi-table join reasoning mechanism to construct the query semantic graph and select the multi-table join path to obtain the second semantic mapping result. If the query is a fuzzy exploration query, start the interactive clarification and candidate recommendation mechanism to generate clarification questions and candidate mapping sets, and determine the third semantic mapping result based on user feedback.

[0010] S4. Convert the first semantic mapping result, the second semantic mapping result, or the third semantic mapping result into an executable query statement for the target database and output it.

[0011] Furthermore, the preprocessing of the natural language query statement in step S1 includes the following steps:

[0012] The system performs word segmentation, part-of-speech tagging, entity recognition, and dependency parsing on natural language queries. Entity recognition includes identifying person names, place names, organization names, time expressions, product names, and indicator names.

[0013] Semantic features are extracted based on entity recognition results and dependency parsing results. These semantic features include query objects, target fields, filtering conditions, aggregation operations, grouping requirements, sorting requirements, time constraints, and fuzzy pronouns.

[0014] By removing modal particles from natural language query statements and replacing synonyms with uniform expressions, standardized query text is obtained.

[0015] Furthermore, the specific steps in step S2 for performing intent recognition and complexity assessment on the standardized query text and semantic features, and classifying the query into fact queries, analytical queries, or fuzzy exploratory queries, are as follows:

[0016] The standardized query text is classified into intent types, namely fact query intent, analysis query intent, or fuzzy exploration query intent.

[0017] Extract complexity features from standardized query text. Complexity features include whether the query contains aggregation operators, multi-table join terms, grouping and sorting terms, fuzzy pronouns, query length, and the number of conditions in the query.

[0018] The query complexity level is determined based on complexity characteristics. The intent classification results are combined with the query complexity level. When the query object is clear and the conditions are direct, it is classified as a fact query. When the query contains aggregation operations or multi-table join requirements, it is classified as an analytical query. When the query object is missing or the filtering conditions conflict, it is classified as a fuzzy exploratory query.

[0019] Furthermore, in step S3, if the query is a fact query, when calling the lightweight mapping template library to perform field matching and condition generation on the standardized query text, the lightweight mapping template library is pre-built from a data dictionary, database table structure, and historical query logs. The lightweight mapping template library contains multiple mapping templates, each containing a query pattern, target table identifier, target field identifier, condition field identifier, and operators. The standardized query text is matched against the query pattern in the lightweight mapping template library. The matching process supports synonym expansion and field aliases. When multiple mapping templates match simultaneously, a comprehensive score for each matching template is calculated using a template matching comprehensive scoring formula. The template with the highest score is selected as the target template. The template matching comprehensive scoring formula is: ,in The overall matching score for the mapped template. To determine the completeness of the match, the value ranges from [0, 1] and is calculated as the ratio of the intersection size to the union size of the query text terms and the template query pattern terms. This represents the field coverage, with a value range of [0, 1]. It is the ratio of the number of target query fields covered by the template to the total number of query fields. This is a normalized value for template usage frequency, ranging from [0, 1]. It is calculated by the ratio of the template's historical usage count to the highest usage count in the template library. , , These are the weight coefficients for match completeness, field coverage, and usage frequency, respectively, satisfying... The initial values ​​of each weight coefficient were determined by business experts using the analytic hierarchy process (AHP), and subsequently optimized iteratively using gradient descent based on feedback from the accuracy of historical queries.

[0020] Furthermore, in step S3, if the query is an analytical query, when the deep semantic parsing and multi-table join reasoning mechanism is activated, the multi-table join reasoning mechanism generates candidate multi-table join paths based on the foreign key relationships and table association relationships in the database metadata. Starting from the table nodes involved in the query semantic graph, it searches for join paths that cover all required table nodes and have direct join relationships. When multiple candidate join paths exist, the multi-table join path fit degree formula is used to calculate the fit score of each candidate path, and the path with the highest score is selected as the target join path. When there are no direct foreign key relationships between the multiple tables involved in the query, the minimum join path is found through the intermediate table in the database metadata. The multi-table join path fit degree formula is: ,in Assign a fitness score to the candidate connection path. This represents the path length, i.e., the number of table joins contained in the path, and its value is a positive integer. This is the foreign key directness coefficient, with a value range of [0, 1]. It is 1 for direct foreign key joins and decreases proportionally with the number of intermediate table levels for indirect joins. The normalized connection cardinality, with a value in the range [0, 1], is calculated as the ratio of the total connection cardinality of this path to the maximum connection cardinality among all candidate paths. , These are the weight coefficients corresponding to foreign key directness and connection cardinality, respectively, satisfying... The weighting coefficients are determined by the cost model of the database query optimizer and iteratively by combining historical query performance data under the business scenario.

[0021] Furthermore, if the query in step S3 is an analytical query, then the deep semantic parsing and multi-table join reasoning mechanism is activated to construct a query semantic graph and select multi-table join paths to obtain the second semantic mapping result. The specific steps are as follows:

[0022] Perform dependency parsing and semantic role labeling on standardized query text to identify entities, constraints, aggregation operations, grouping requirements, and sorting requirements in the query;

[0023] Based on the database metadata, entities are mapped to target tables or target fields, and constraints are mapped to filter conditions. A query semantic graph is constructed. The nodes in the query semantic graph include table nodes, field nodes, and value nodes, and the edges in the query semantic graph include attribution relationships, filter relationships, connection relationships, and aggregation relationships.

[0024] The target join path is determined based on the foreign key relationships and table associations in the database metadata, and a second semantic mapping result is generated based on the query semantic graph and the target join path.

[0025] Furthermore, if the query in step S3 is a fuzzy exploratory query, then an interactive clarification and candidate recommendation mechanism is activated to generate a clarification question and a candidate mapping set. The specific steps for determining the third semantic mapping result based on user feedback are as follows:

[0026] Based on the intent recognition results and semantic features, identify the ambiguities in the query. The ambiguities include missing query objects, unclear time ranges, unclear dimensions, or conflicting filtering conditions.

[0027] For ambiguous points, generate clarifying questions and generate a candidate mapping set based on the identified semantic information and database metadata;

[0028] The system returns the clarifying question and candidate mapping set to the user, receives user feedback, updates the standardized query text or semantic features based on the user feedback, repeats the clarification and recommendation process if there are still ambiguities after the update, and generates a third semantic mapping result if the query intent is clear.

[0029] Furthermore, in step S3, if the query is a fuzzy exploratory query, when the interactive clarification and candidate recommendation mechanism is activated to generate a candidate mapping set, the candidate mapping set combines the user's historical queries, database statistics, and commonly used business dimensions. The candidate mapping recommendation scoring formula is used to calculate the recommendation score for each candidate mapping, and the sets are generated by sorting them from highest to lowest score. The candidate mapping set is displayed as options in the user interface. The clarification question and the candidate mapping set are output simultaneously or in stages. The user provides feedback by clicking, selecting, or supplementing input. The user's historical queries include records of queries executed in the past. Database statistics include table access frequency and field usage frequency. Commonly used business dimensions are determined by business rule configuration. The candidate mapping recommendation scoring formula is: ,in The recommended score for the candidate mapping. The historical matching score for a user ranges from (0, 1] and is obtained by normalizing the frequency of the user's past selections of the corresponding mapping. The database popularity metric, with values ​​ranging from (0, 1), is obtained by normalizing the global access frequency of the candidate mapping's corresponding table and field. The business dimension fit is calculated based on the weights of commonly used dimensions configured in the business rules, with a value range of (0, 1). , , The weighting coefficients are power-order, satisfying... The initial weights are determined by business experts using the analytic hierarchy process, and are subsequently dynamically adjusted using Bayesian optimization based on user clicks and selections.

[0030] Furthermore, in step S4, when converting the first semantic mapping result, the second semantic mapping result, or the third semantic mapping result into an executable query statement for the target database and outputting it, the first semantic mapping result, the second semantic mapping result, and the third semantic mapping result adopt a unified semantic mapping intermediate representation. The semantic mapping intermediate representation includes the target table identifier, the target field identifier, the set of filtering conditions, the set of join paths, the aggregation operation, the grouping field, and the sorting field. The target database type is read, and the semantic mapping intermediate representation is converted into a query statement corresponding to the target database type. The target database type includes relational databases, columnar databases, and non-relational databases.

[0031] Furthermore, in step S2, the intent classification uses a trained text classification model or rule classifier. The rule classifier classifies intent based on whether aggregation operation words, multi-table join words, grouping and sorting words, and fuzzy pronouns appear in the query. The complexity assessment extracts the query length and the number of conditions, and compares the query length and the number of conditions with preset judgment conditions. The preset judgment conditions are configured according to the business scenario. The preset judgment conditions include a query length threshold and a condition number threshold, which are determined by the number of database tables and fields in the business scenario.

[0032] Compared with existing technologies, this natural language-based database semantic mapping construction process has the following advantages:

[0033] This invention first performs intent recognition and complexity assessment on natural language queries, classifying them into fact queries, analytical queries, and fuzzy exploration queries. Then, it dynamically activates lightweight mapping templates, deep semantic parsing and multi-table join reasoning mechanisms, or interactive clarification and candidate recommendation mechanisms based on the query level. This enables fact queries to quickly complete field matching and condition generation, analytical queries to obtain multi-table join and aggregation reasoning support, and fuzzy exploration queries to clarify intent through clarification and candidate recommendations. This achieves a dynamic balance between semantic mapping accuracy and computational resource allocation, ensuring high-precision mapping while reducing the parsing overhead of simple queries, enhancing the mapping capability of complex queries, and improving the interactive experience of fuzzy queries. Ultimately, this improves the overall response efficiency and usability of database semantic mapping construction.

[0034] Other advantages, objectives and features of the invention will be set forth in part in the description which follows, and in part will be apparent to those skilled in the art from the following examination or study, or may be learned from the practice of the invention. Attached Figure Description

[0035] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are merely some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without any creative effort.

[0036] Figure 1 A flowchart illustrating the process of constructing a database semantic mapping based on natural language;

[0037] Figure 2 A flowchart illustrating the steps involved in constructing a natural language-based database semantic mapping.

[0038] Figure 3 This is a flowchart for preprocessing natural language query statements. Detailed Implementation

[0039] To further illustrate the technical means and effects of the present invention in achieving its intended purpose, the following detailed description of the specific implementation methods, structures, features, and effects of the present invention, in conjunction with the accompanying drawings and preferred embodiments, is provided below.

[0040] This invention provides a database semantic mapping construction process based on natural language, targeting enterprise-level data query scenarios. It categorizes queries into three types—factual queries, analytical queries, and fuzzy exploratory queries—through a dual-level approach of identifying the execution intent and assessing the complexity of natural language queries. Then, it dynamically activates corresponding semantic mapping links for different query types. For simple factual queries, lightweight template matching achieves rapid response; for complex analytical queries, deep semantic parsing and multi-table join reasoning ensure mapping accuracy; and for fuzzy exploratory queries, interactive clarification and candidate recommendation mechanisms clarify user intent. Finally, the semantic mapping results are uniformly converted into executable query statements for the target database. This solution can dynamically allocate computing resources according to actual query needs, ensuring the accuracy of mapping high-complexity queries while reducing the parsing overhead of low-complexity queries. It effectively solves the problem of resource waste and insufficient accuracy inherent in traditional unified mapping processes, achieving a dynamic balance between semantic mapping accuracy and computational efficiency. A detailed description is provided below with specific embodiments.

[0041] This embodiment is deployed on an enterprise sales data analysis platform. The underlying target database is a relational database, containing four core business tables: a user table, an order table, a product table, and a region table. These tables are linked through primary keys and foreign keys. The order table stores all transaction order information, the user table stores basic customer information, the product table stores basic product attributes, and the region table stores administrative region division information. The order table is linked to the user table's primary key via a user ID field, and to the product table's primary key via a product ID field. The product table is linked to the region table's primary key via a region ID field. The platform front-end provides a natural language query entry point. After the user enters a Chinese query, the system automatically executes the semantic mapping construction process described in this embodiment, ultimately generating an executable structured query and returning the query results.

[0042] like Figure 1 As shown, the semantic mapping construction process in this embodiment executes four core steps sequentially: query preprocessing, intent and complexity grading, differential semantic mapping, and query statement generation. Figure 2 As shown, the overall step framework of this embodiment corresponds to four major processing modules. Each module is executed in sequence, and the output of the previous module serves as the input of the next module, forming a complete processing chain.

[0043] First, perform query preprocessing. For example... Figure 3 As shown, the preprocessing of natural language queries includes three stages: syntactic analysis, semantic feature extraction, and text standardization. First, the user-input natural language query is obtained, and then segmented, tagged with parts of speech, identified, and subjected to dependency parsing. The entity identification stage covers six core entity categories: names of people, places, organizations, time expressions, product names, and indicator names. For example, in the query, "July 2026" is identified as a time expression, "sales amount" as an indicator name, and "Product A" as a product name. Dependency parsing clarifies the grammatical dependencies between terms, such as determining the correspondence between modifiers and core terms, providing a grammatical basis for subsequent semantic feature extraction.

[0044] After syntactic analysis, semantic features are extracted based on entity recognition and dependency parsing results. These semantic features include eight categories: query object, target field, filtering conditions, aggregation operations, grouping requirements, sorting requirements, time constraints, and fuzzy pronouns. For example, for the query "Statistics on sales revenue for each region in the first half of 2026 and sorted in descending order," the extracted query object is sales data, the target field is sales revenue, the filtering condition is "first half of 2026," the aggregation operation is summation, the grouping requirement is grouping by region, the sorting requirement is descending order, and there are no fuzzy pronouns. For the query "Check recent sales," the extracted query object is sales data, the time constraint is an ambiguous "recent range," there is the fuzzy pronoun "recent," and the other features are not explicitly identified.

[0045] After feature extraction, text standardization is performed to remove modal particles from the query and replace synonyms with standardized expressions. For example, colloquial "sales volume" is replaced with the standard term "sales quantity," and "sales amount" is replaced with "sales revenue." Modal particles without real semantic meaning, such as "ah" and "ne," are removed, and word order is corrected. Finally, a standardized query text with uniform format and semantic norms, along with its corresponding semantic feature set, is obtained and output to the next processing stage.

[0046] Next, intent recognition and complexity assessment are performed. This step receives standardized query text and semantic features, and classifies the query from two dimensions: intent classification and complexity assessment. First, intent classification is performed. This embodiment uses a hybrid approach combining a rule classifier and a pre-trained text classification model to achieve intent recognition. The rule classifier performs preliminary classification based on whether the query contains aggregation operators, multi-table joiners, grouping / sorting words, and fuzzy pronouns. If the query contains aggregation operators such as summation, statistical averages, or multi-table joiners such as associations and comparisons, it is initially determined to be an analysis query intent. If the query contains vague expressions such as "take a look" or lacks a clear query object, it is initially determined to be a fuzzy exploration query intent. Other queries are initially determined to be factual query intents. The preliminary classification results are then input into a text classification model fine-tuned with business data, outputting the final intent classification results, yielding either factual query intent, analysis query intent, or fuzzy exploration query intent. This hybrid classification method ensures classification efficiency for scenarios with clear rules while improving classification accuracy for scenarios with flexible expressions.

[0047] After completing intent classification, complexity assessment is performed. Complexity features are extracted from standardized query text, including six indicators: whether the query contains aggregation operators, multi-table joins, grouping and sorting terms, fuzzy pronouns, query length, and the number of conditions in the query. Query length is calculated based on the number of terms after word segmentation, and the number of conditions is calculated based on the number of extracted filtering conditions. The query length and number of conditions are compared with preset judgment conditions, which are configured according to the business scenario and include query length thresholds and condition number thresholds. In this embodiment, the query length threshold is set to 15 terms, and the condition number threshold is set to 3. Query lengths and condition numbers less than or equal to the thresholds are classified as low complexity; query lengths or condition numbers greater than the thresholds are classified as medium to high complexity. The thresholds for the preset judgment conditions are determined by the number of database tables and fields in the business scenario. When the number of business tables increases or the field dimensions expand, the threshold parameters are adjusted upwards to ensure that the complexity classification is adapted to the business scale.

[0048] Finally, the intent classification results are combined with the query complexity level to complete the query type classification. When the query object is clear and the conditions are direct, and it corresponds to a fact query intent and is at a low complexity level, it is classified as a fact query; when the query includes aggregation operations or multi-table join requirements, and it corresponds to an analytical query intent and is at a medium-to-high complexity level, it is classified as an analytical query; when the query object is missing or the filtering conditions conflict, and it corresponds to a fuzzy exploration query intent, it is classified as a fuzzy exploration query. For example, querying the sales volume of product A in July 2026, the query object is clear and the conditions are direct, so it is classified as a fact query; calculating the sales volume of each region and category in the first half of 2026 and sorting it in descending order, including aggregation operations and grouping and sorting requirements, is classified as an analytical query; looking at recent sales, the query object is unclear and the time range is vague, so it is classified as a fuzzy exploration query.

[0049] Then, differential semantic mapping is executed. Based on the query segmentation results, the semantic mapping links corresponding to the query levels are dynamically activated, and different mapping logics are executed for the three types of queries.

[0050] In the first scenario, when the query is a fact query, a lightweight mapping template library is invoked to perform field matching and condition generation on the standardized query text, yielding the first semantic mapping result. The lightweight mapping template library is pre-built from the data dictionary database table structure and historical query logs. The library contains multiple mapping templates, each containing five core elements: query pattern, target table identifier, target field identifier, condition field identifier, and operator. During the template library's construction, successfully executed queries are abstracted, extracting common elements from similar queries into query patterns, which are then bound to fixed table fields and operators. For example, querying the sales quantity of a product in a specific month corresponds to a unified query pattern, binding the order table as the target table, sales quantity as the target field, time and product as condition fields, and equality as the default operator.

[0051] The system matches standardized query text against query patterns in a lightweight mapping template library. The matching process supports synonym expansion and field aliases; for example, "sales quantity" and "sales volume" are synonyms, and "user ID" and "uid" are field aliases. These are automatically included in the synonym set for comparison during matching, improving the recall rate. When only one mapping template matches successfully, that template is directly used to generate the mapping result; when multiple mapping templates match simultaneously, the optimal template is selected through a quantitative scoring method.

[0052] In the specific implementation of this embodiment, a comprehensive score for each matching template is calculated using a template matching comprehensive scoring formula, and the template with the highest score is selected as the target template. The template matching comprehensive scoring formula is as follows: In the formula, This is the overall matching score for the mapping template. To determine the completeness of the match, the value ranges from 0 to 1. It is calculated by the ratio of the intersection size to the union size of the query text terms and the template query pattern terms. This calculation method is essentially based on the Jaccard similarity of terms, and the matching degree is calculated based on the semantic units after word segmentation, avoiding the semantic misjudgment problem caused by character-level matching. Field coverage, ranging from 0 to 1, is the ratio of the number of target query fields covered by the template to the total number of query fields. The more fields covered, the higher the score, reflecting the degree to which the template covers the query requirements. This is a normalized value for template usage frequency, ranging from 0 to 1. It is calculated by the ratio of the template's historical usage count to the highest usage count in the template library. The higher the usage frequency, the higher the score, reflecting the template's historical reliability and versatility.

[0053] , , The weights are assigned to the frequency of use for matching completeness field coverage, and the sum of these three factors equals 1. The initial values ​​of the weights are determined by business experts using the analytic hierarchy process (AHP). During the determination process, business experts construct pairwise comparison judgment matrices based on three evaluation dimensions: matching accuracy, field completeness, and historical reliability. They calculate the weight vector for each dimension and verify that the consistency ratio of the judgment matrices is less than 0.1, ensuring logical consistency in the weight allocation. In this embodiment, the initial weights are respectively... It equals 0.5. It equals 0.3. It equals 0.2. After the system goes live, the weight coefficients are iteratively optimized using gradient descent based on the accuracy feedback of historical queries. The optimization process takes the correct mapping results of manual annotation as the true value and the hit rate of the top template in the comprehensive score ranking as the optimization objective. The weight is updated once every 1000 annotated queries to gradually improve the accuracy of template matching.

[0054] Taking a specific query as an example, when a query matches multiple candidate templates, the matching completeness, field coverage, and normalized usage frequency values ​​corresponding to each template are extracted and substituted into the template matching comprehensive scoring formula to calculate the comprehensive matching score of each template. After sorting the scores from high to low, the template with the highest score is selected as the target template. Based on the table field mapping relationship and operation rules bound to the target template, the corresponding first semantic mapping result is generated.

[0055] In the second scenario, when the query is an analytical query, a deep semantic parsing and multi-table join reasoning mechanism is initiated to construct a query semantic graph and select multi-table join paths to obtain the second semantic mapping result. This stage consists of four execution steps.

[0056] The first step involves performing dependency parsing and semantic role labeling on the standardized query text. This identifies entity constraints, aggregation operations, grouping requirements, and sorting requirements within the query, refines the role attribution of semantic units, and clarifies the logical relationships between semantic components. The second step maps entities to target tables or target fields and constraints to filtering conditions based on database metadata, constructing a query semantic graph. The nodes in the query semantic graph include three types: table nodes, field nodes, and value nodes. The edges in the query semantic graph include four types: attribution relationships, filtering relationships, connection relationships, and aggregation relationships. This graph structure fully expresses the semantic logic of the query, providing a structured foundation for subsequent connection reasoning.

[0057] The third step involves generating candidate multi-table join paths based on foreign key relationships and table associations in the database metadata. Starting from the table nodes involved in the query semantic graph, a join path is sought that covers all required table nodes and has a direct join relationship. When there is no direct foreign key relationship between the multiple tables involved in the query, the minimum join path is found through the intermediate table in the database metadata to ensure that all target tables can be effectively joined. When multiple candidate join paths exist, the optimal join path is selected using a quantitative scoring method.

[0058] In the specific implementation of this embodiment, the adaptation score of each candidate path is calculated using the multi-table join path adaptation formula, and the path with the highest score is selected as the target join path. The multi-table join path adaptation formula is: In the formula, The candidate connection path is given a fitness score; the higher the score, the better the path. The path length is the number of table joins included in the path. It is a positive integer. The longer the path, the larger the denominator and the lower the overall score, reflecting the query optimization principle of prioritizing short paths. This is the foreign key directness coefficient, ranging from 0 to 1. It is 1 for direct foreign key joins and decreases proportionally with the number of intermediate table layers for indirect joins. The coefficient is multiplied by 0.8 for each additional intermediate table, reflecting that direct joins have higher reliability and lower execution overhead. The normalized connection cardinality, ranging from 0 to 1, is calculated as the ratio of the total connection cardinality of the path to the maximum connection cardinality among all candidate paths. The smaller the connection cardinality, the less the value is added (1). The larger the value, the higher the score, reflecting the query optimization principle of prioritizing small cardinality joins and reducing the amount of data scanned.

[0059] and These are the weight coefficients corresponding to foreign key directness and join cardinality, respectively, and their sum equals 1. The weight coefficients are determined by the cost model of the database query optimizer. During calibration, the cost calculation logic of the target database's native optimizer is referenced, decomposing the total query cost into two parts: join jump cost and data scan cost, corresponding to the weight proportions of foreign key directness and join cardinality, respectively. In this embodiment, the initial weights are respectively... It equals 0.4. It equals 0.6. During system operation, the weight coefficients are determined iteratively by combining historical query performance data under business scenarios. The actual execution time of each candidate path is used as the labeled data, and the negative correlation between the fit score and the actual execution time is used as the optimization objective. The weight coefficients are adjusted iteratively through linear regression to make the scoring results more in line with the actual query performance and ensure that the selected path has the best execution efficiency.

[0060] Taking a specific query as an example, when a query involves multiple business tables and generates multiple candidate join paths, the path length, foreign key directness coefficient, and total join cardinality of each path are calculated. First, the normalized join cardinality of each path is calculated based on the maximum join cardinality of all candidate paths. Then, the fit score of each path is calculated by substituting it into the multi-table join path fit formula. After sorting the paths from high to low scores, the path with the highest score is selected as the target join path.

[0061] The fourth step is to generate a complete second semantic mapping result based on the query semantic graph and the selected target connection path, which includes all target table target field filtering conditions, connection relationships, aggregation, grouping and sorting information.

[0062] In the third scenario, when the query is a fuzzy exploratory query, an interactive clarification and candidate recommendation mechanism is activated to generate clarification questions and a set of candidate mappings. The third semantic mapping result is then determined based on user feedback. This stage consists of five execution steps. First, based on the intent recognition results and semantic features, the fuzzy points in the query are identified. These fuzzy points include four categories: missing query objects, unclear time ranges, unclear dimensions, or conflicting filtering conditions. For example, in a query to view recent sales data, the identified fuzzy points are unclear time ranges and unclear statistical dimensions. Second, clarification questions are generated for the identified fuzzy points. For example, two types of clarification questions are generated: "Which time range of sales data do you need to query?" and "Which dimension do you need to view sales data?". The question wording is tailored to the business scenario and conforms to the user's daily expression habits. Third, a set of candidate mappings is generated based on the identified semantic information and database metadata. This set contains multiple mapping schemes that may match the user's intent, covering common query dimensions and time ranges. Fourth, the clarification questions and the set of candidate mappings are returned to the user, and user feedback is received. Clarification questions and candidate mapping sets can be output simultaneously or in stages. The candidate mapping set is displayed as options in the user interface, and users provide feedback by clicking to select or supplementing their input. In the fifth step, the standardized query text or semantic features are updated based on user feedback. If ambiguity still exists after the update, the clarification and recommendation process is repeated. If the query intent is clear, a third semantic mapping result is generated.

[0063] In the specific implementation of this embodiment, when generating the candidate mapping set, the recommendation score for each candidate mapping is calculated using a candidate mapping recommendation scoring formula, combining three types of data: user historical query database statistics, commonly used business dimensions, and so on. The candidate mapping set is then generated by sorting the scores from highest to lowest. The candidate mapping recommendation scoring formula is as follows: In the formula, The recommendation score is the candidate mapping score; the higher the score, the higher the recommendation priority. The historical matching score is 0 to 1. It is obtained by normalizing the frequency of the user's past selection of the corresponding mapping. The calculation uses a smoothing process of adding one to ensure that the value is always greater than 0, reflecting the user's personalized query preferences. The higher the frequency of past selection of the mapping scheme, the higher the score. The database statistics are based on a score ranging from 0 to 1. The score is obtained by normalizing the global access frequency of the fields in the candidate mapping table. The higher the global access frequency, the higher the score, reflecting the global universality of the mapping scheme. The business dimension fit score ranges from 0 to 1 and is calculated from the weights of commonly used dimensions configured in the business rules. The core business dimensions have a higher fit score, reflecting the priority of the business scenario and ensuring that the recommendation results meet the business management requirements.

[0064] , , These are power-order weighting coefficients, and the sum of the three equals 1. The initial weights are determined by business experts using the analytic hierarchy process (AHP). Experts construct pairwise comparison matrices from three dimensions: user personalization, global popularity, and business compliance. They calculate the weight vector and verify its consistency. In this embodiment, the initial weights are as follows: It equals 0.3. It equals 0.3. It equals 0.4. During system operation, the weight coefficients are dynamically adjusted through Bayesian optimization based on user click feedback. The optimization goal is to achieve a conversion rate of user clicks on candidate options. The weight distribution is updated every 500 user interactions to gradually improve the user matching degree of candidate recommendations, making the recommendation results more in line with the usage habits of different users.

[0065] Finally, the query statement is transformed and output. The first, second, or third semantic mapping result is converted into an executable query statement for the target database and output. In this embodiment, the three types of semantic mapping results use a unified semantic mapping intermediate representation. The semantic mapping intermediate representation contains seven core elements: target table identifier, target field identifier, filter condition set, connection path set, aggregation operation grouping field, and sorting field. This ensures a unified output format for different mapping links and provides standardized input for subsequent transformations. During the transformation, the target database type is first read, and the semantic mapping intermediate representation is converted into a query statement corresponding to the target database type. Target database types include relational databases, columnar databases, and non-relational databases. Standard structured query statements are generated for relational databases, query statements adapted to columnar storage syntax are generated for columnar databases, and query instructions in the corresponding format are generated for non-relational databases. In this embodiment, the target database is a relational database. Finally, a standard structured query statement is generated and submitted to the database for execution, and the query results are returned to the front-end interface.

[0066] In summary, this embodiment employs a hierarchical and differentiated semantic mapping architecture, matching processing chains of corresponding complexity to different types of query needs. This allows simple fact queries to quickly obtain mapping results without deep parsing, effectively shortening response time. Complex analytical queries receive deep support for multi-table join reasoning and semantic graph construction, ensuring the completeness and accuracy of mapping results. Fuzzy exploratory queries quickly clarify intent through interactive clarification and intelligent candidate recommendations, avoiding erroneous queries or empty results. The entire solution dynamically allocates computing resources based on actual query needs, achieving a dynamic balance between semantic mapping accuracy and computing resource utilization efficiency, effectively improving the overall performance and user experience of the database's natural language query interface.

[0067] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make some modifications or alterations to the above-disclosed technical content to create equivalent embodiments without departing from the scope of the present invention. Any simple modifications, equivalent changes and alterations made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the scope of the present invention.

Claims

1. A database semantic mapping construction process based on natural language, characterized in that, The process includes the following steps: S1. Obtain the natural language query statement input by the user, preprocess the natural language query statement to obtain standardized query text and semantic features; S2. Perform intent recognition and complexity assessment on standardized query text and semantic features, and classify queries into fact queries, analytical queries, or fuzzy exploratory queries based on the intent recognition results and complexity assessment results. S3. Based on the partitioning results, dynamically activate the semantic mapping links corresponding to the query level. If the query is a fact query, call the lightweight mapping template library to perform field matching and condition generation on the standardized query text to obtain the first semantic mapping result. If the query is an analytical query, start the deep semantic parsing and multi-table join reasoning mechanism to construct the query semantic graph and select the multi-table join path to obtain the second semantic mapping result. If the query is a fuzzy exploration query, start the interactive clarification and candidate recommendation mechanism to generate clarification questions and candidate mapping sets, and determine the third semantic mapping result based on user feedback. S4. Convert the first semantic mapping result, the second semantic mapping result, or the third semantic mapping result into an executable query statement for the target database and output it.

2. The database semantic mapping construction process based on natural language according to claim 1, characterized in that, The preprocessing of the natural language query statement in step S1 includes the following steps: The system performs word segmentation, part-of-speech tagging, entity recognition, and dependency parsing on natural language queries. Entity recognition includes identifying person names, place names, organization names, time expressions, product names, and indicator names. Semantic features are extracted based on entity recognition results and dependency parsing results. These semantic features include query objects, target fields, filtering conditions, aggregation operations, grouping requirements, sorting requirements, time constraints, and fuzzy pronouns. By removing modal particles from natural language query statements and replacing synonyms with uniform expressions, standardized query text is obtained.

3. The database semantic mapping construction process based on natural language according to claim 1, characterized in that, The specific steps in step S2 for performing intent recognition and complexity assessment on standardized query text and semantic features, and classifying queries into fact queries, analytical queries, or fuzzy exploratory queries, are as follows: The standardized query text is classified into intent types, namely fact query intent, analysis query intent, or fuzzy exploration query intent. Extract complexity features from standardized query text. Complexity features include whether the query contains aggregation operators, multi-table join terms, grouping and sorting terms, fuzzy pronouns, query length, and the number of conditions in the query. The query complexity level is determined based on complexity characteristics. The intent classification results are combined with the query complexity level. When the query object is clear and the conditions are direct, it is classified as a fact query. When the query contains aggregation operations or multi-table join requirements, it is classified as an analytical query. When the query object is missing or the filtering conditions conflict, it is classified as a fuzzy exploratory query.

4. The database semantic mapping construction process based on natural language according to claim 1, characterized in that, In step S3, if the query is a fact query, the lightweight mapping template library is invoked to perform field matching and condition generation on the standardized query text. The lightweight mapping template library is pre-built from a data dictionary, database table structure, and historical query logs. It contains multiple mapping templates, each including a query pattern, target table identifier, target field identifier, condition field identifier, and operators. The standardized query text is matched against the query pattern in the lightweight mapping template library. The matching process supports synonym expansion and field aliases. When multiple mapping templates match simultaneously, a comprehensive score for each matching template is calculated using a template matching comprehensive scoring formula. The template with the highest score is selected as the target template. The template matching comprehensive scoring formula is as follows: ,in The overall matching score for the mapped template. To match completeness, For field coverage, Normalized values ​​for template usage frequency. , , These are the weight coefficients corresponding to match completeness, field coverage, and usage frequency, respectively.

5. The database semantic mapping construction process based on natural language according to claim 1, characterized in that, If the query in step S3 is an analytical query, when the deep semantic parsing and multi-table join reasoning mechanism is activated, the multi-table join reasoning mechanism generates candidate multi-table join paths based on foreign key relationships and table association relationships in the database metadata. Starting from the table nodes involved in the query semantic graph, it searches for join paths that cover all required table nodes and have direct join relationships. When multiple candidate join paths exist, the multi-table join path fit degree formula is used to calculate the fit score of each candidate path, and the path with the highest score is selected as the target join path. When there are no direct foreign key relationships between the multiple tables involved in the query, the minimum join path is found through the intermediate table in the database metadata. The multi-table join path fit degree formula is: ,in Assign a fitness score to the candidate connection path. For path length, The foreign key directness coefficient. For normalized connection cardinality, , These are the weighting coefficients corresponding to foreign key directness and connection cardinality, respectively.

6. The database semantic mapping construction process based on natural language according to claim 1, characterized in that, If the query in step S3 is an analytical query, then the deep semantic parsing and multi-table join reasoning mechanism is activated to construct a query semantic graph and select multi-table join paths to obtain the second semantic mapping result. The specific steps are as follows: Perform dependency parsing and semantic role labeling on standardized query text to identify entities, constraints, aggregation operations, grouping requirements, and sorting requirements in the query; Based on the database metadata, entities are mapped to target tables or target fields, and constraints are mapped to filter conditions. A query semantic graph is constructed. The nodes in the query semantic graph include table nodes, field nodes, and value nodes, and the edges in the query semantic graph include attribution relationships, filter relationships, connection relationships, and aggregation relationships. The target join path is determined based on the foreign key relationships and table associations in the database metadata, and a second semantic mapping result is generated based on the query semantic graph and the target join path.

7. The database semantic mapping construction process based on natural language according to claim 1, characterized in that, If the query in step S3 is a fuzzy exploratory query, then the interactive clarification and candidate recommendation mechanism is activated to generate a clarification question and a candidate mapping set. The specific steps for determining the third semantic mapping result based on user feedback are as follows: Based on the intent recognition results and semantic features, identify the ambiguities in the query. The ambiguities include missing query objects, unclear time ranges, unclear dimensions, or conflicting filtering conditions. For ambiguous points, generate clarifying questions and generate a candidate mapping set based on the identified semantic information and database metadata; The system returns the clarifying question and candidate mapping set to the user, receives user feedback, updates the standardized query text or semantic features based on the user feedback, repeats the clarification and recommendation process if there are still ambiguities after the update, and generates a third semantic mapping result if the query intent is clear.

8. The database semantic mapping construction process based on natural language according to claim 1, characterized in that, If the query in step S3 is a fuzzy exploratory query, when the interactive clarification and candidate recommendation mechanism is activated to generate a candidate mapping set, the candidate mapping set combines the user's historical queries, database statistics, and commonly used business dimensions. The recommendation score for each candidate mapping is calculated using the candidate mapping recommendation scoring formula, and the candidate mappings are sorted from highest to lowest score to generate the candidate mapping set. The candidate mapping set is displayed as options in the user interface. The clarification question and the candidate mapping set are output simultaneously or in stages. The user provides feedback by clicking, selecting, or supplementing input. The user's historical queries include records of queries executed in the past. Database statistics include table access frequency and field usage frequency. Commonly used business dimensions are determined by business rule configuration. The candidate mapping recommendation scoring formula is: ,in The recommended score for the candidate mapping. For users' historical matching scores, To statistically analyze the popularity of data in the database, For business-dimensional fit, , , The power-order weighting coefficient.

9. The database semantic mapping construction process based on natural language according to claim 1, characterized in that, In step S4, when the first semantic mapping result, the second semantic mapping result, or the third semantic mapping result is converted into an executable query statement for the target database and output, the first semantic mapping result, the second semantic mapping result, and the third semantic mapping result adopt a unified semantic mapping intermediate representation. The semantic mapping intermediate representation includes the target table identifier, the target field identifier, the set of filtering conditions, the set of join paths, the aggregation operation, the grouping field, and the sorting field. The target database type is read, and the semantic mapping intermediate representation is converted into a query statement corresponding to the target database type. The target database type includes relational databases, columnar databases, and non-relational databases.

10. The database semantic mapping construction process based on natural language according to claim 1, characterized in that, In step S2, intent classification uses a trained text classification model or rule classifier. The rule classifier classifies intent based on whether aggregation operation words, multi-table join words, grouping and sorting words, and fuzzy pronouns appear in the query. Complexity assessment extracts query length and number of conditions, and compares query length and number of conditions with preset judgment conditions. The preset judgment conditions are configured according to the business scenario and include query length threshold and condition number threshold. The query length threshold and condition number threshold are determined by the number of database tables and fields in the business scenario.

Images