Graph topology retrieval and connected graph completion method

Abstract

The application relates to a graph topology retrieval and connected graph completion method. The application is suitable for the technical field of database intelligent query. The technical scheme comprises the following steps: first, abstracting a database table and association into a schema relationship graph; after receiving a query, recalling relevant nodes by using at least two strategies and merging the relevant nodes into a candidate set, and extracting edges to generate a candidate subgraph; then, analyzing the connectedness of the subgraph; if there are multiple connected components, encapsulating each component into a supernode, screening a bridging node to build a supergraph, searching for a candidate path satisfying a path length constraint, and screening a target connection path according to a quality score; finally, integrating nodes and edges corresponding to the target path into an atomic graph, and obtaining a completed connected subgraph as a constraint context output generated by a structured query.

Description

Technical Field

[0001] This invention relates to a method for graph topology retrieval and connected graph completion. It is applicable to the field of intelligent database query technology. Background Technology

[0002] As enterprise-level business systems iterate and upgrade, business databases typically contain dozens to hundreds of tables, with complex relationships formed between them through foreign keys, dimension tables, and enumeration mappings. Intelligent data interaction technologies, exemplified by natural language query data, rely on large language models to convert user natural language requests into executable structured query statements, significantly lowering the barrier to entry for using business data.

[0003] In the implementation of existing technologies, if the entire database structure, field definitions, and inter-table relationships are input into a large language model as context, it faces several challenges. First, the model's context window length limits its capacity to fully accommodate large-scale schema information. Second, long contexts are prone to attention dilution issues, where irrelevant schema fragments can interfere with model judgments, leading to problems such as missing table relationships, incorrect relationships, and phantom table names in the generated queries. Therefore, schema retrieval mechanisms are commonly used in engineering projects, inputting only the portion of the table structure information relevant to the user's query into the model.

[0004] Existing schema recall methods often employ multi-pronged strategies, such as semantic matching and structural matching, to filter relevant table nodes and then extract related edges where both ends are within the recall set to generate candidate subgraphs. However, this technical solution has the following significant drawbacks: 1. The candidate subgraphs generated by the recall often have topological connectivity issues. Multiple business-related tables belong to different connectivity components and lack the intermediate bridging tables or relationships required for connection, making it impossible to form a complete table connection path, which leads to the downstream being unable to generate correct multi-table join queries.

[0005] 2. Existing graph completion methods often directly apply the shortest path algorithm of general graph theory, treating all nodes indiscriminately without distinguishing the roles of entity tables, dimension tables, and enumeration ontologies in the business database. This can easily lead to the misuse of dimension table and enumeration nodes as long-distance bridges, generating invalid connection paths without business semantics, and even causing excessive fan-out of dimension table hubs.

[0006] 3. In large-scale business database scenarios, existing technologies struggle to balance query efficiency and result completeness: expanding the recall scope leads to an increase in context size, reducing model generation quality and query efficiency; narrowing the recall scope can easily miss key associations, exacerbating the subgraph breakage problem.

[0007] 4. Traditional graph data retrieval only returns a set of nodes, lacking in-depth analysis of the topology and failing to provide fine-grained information such as the distribution of connected components and the composition of node categories, making it difficult to support result interpretation and parameter tuning. Summary of the Invention

[0008] The technical problem to be solved by the present invention is to provide a graph topology retrieval and connected graph completion method to address the above-mentioned problems.

[0009] The technical solution adopted in this invention is: a graph topology retrieval and connected graph completion method, comprising: The data tables and relationships between tables in the target business database are abstracted into graph nodes and graph edges to form a schema relationship graph; Receive query requests and use at least two recall strategies to recall relevant nodes in the schema relationship diagram. Merge the nodes recalled by each strategy according to a preset merging rule to obtain a candidate node set. Based on the candidate node set, extract the associated edges in the Schema relationship graph where both ends belong to the candidate node set, and generate a candidate subgraph; Perform connectivity analysis on the candidate subgraph to identify all connected components contained in the candidate subgraph; When the candidate subgraph contains at least two connected components, each connected component is encapsulated as a super node. Nodes that do not belong to the candidate node set are selected from the schema relationship graph as candidate bridge nodes. Based on the edge relationship of the schema relationship graph, a hypergraph containing super nodes and candidate bridge nodes is constructed. In the hypergraph, candidate paths that satisfy the preset maximum path length are searched for each pair of connected component hypernodes. The path quality score of each candidate path is calculated, and the path is filtered based on the quality score to obtain the target connection path corresponding to each pair of hypernodes. The nodes and edges corresponding to each target connection path in the schema relation graph are merged into the candidate subgraph to obtain the completed connected subgraph, and the connected subgraph is output as the constraint context for the structured query generation.

[0010] Through the aforementioned technical means, the multi-component connectivity completion problem is transformed into a low-complexity path search problem between supernodes by using hypergraph abstraction, which significantly compresses the path search space and improves the efficiency of completion operation under large-scale graphs. By automatically filling broken associations in the recall subgraph through connectivity completion, the output subgraph has complete connectivity, providing coherent table association constraints for the generation of downstream structured queries, effectively reducing problems such as missing associations and incorrect associations, and ensuring the success rate of multi-table query generation without inputting the full schema, thus achieving a balance between context scale control and information integrity.

[0011] As a preferred embodiment, the category attributes of the graph nodes include at least entity class, relation class, dimension table class and enumerated ontology class; the step of filtering candidate bridging nodes from the schema relation graph includes: filtering out nodes that do not belong to the candidate node set and whose category is entity class or relation class as candidate bridging nodes.

[0012] By employing the aforementioned technical means, candidate bridging nodes are constrained based on the node type attributes of the business database. This directly excludes enumeration ontology and dimension table type nodes from bridging qualifications at the search space level, fundamentally preventing enumeration and dimension tables from being misused as long-distance connection bridges. This ensures that the backbone nodes of the completion path are all entity or relation type nodes with business relevance, significantly improving the business rationality of the completion results.

[0013] As a preferred embodiment, the preset merging rule is a weighted merging rule, including: Assign corresponding strategy weights to each recall strategy, assign corresponding position weights to the ranking of nodes in the single strategy recall results, calculate the comprehensive weighted score of each node, sort them from high to low according to the comprehensive weighted score, and extract no more than a preset maximum number of nodes to form a candidate node set.

[0014] By employing the aforementioned technical means, the credibility of different recall strategies is distinguished by strategy weights, and the relevance of node ranking is reflected by position weights, thus achieving the scientific fusion of multi-path recall results. At the same time, by truncating the maximum number of nodes, the size of the initial subgraph is strictly controlled from the recall stage to avoid excessive expansion of the context after subsequent completion, thus balancing recall comprehensiveness and computational complexity while ensuring recall relevance.

[0015] As a preferred embodiment, the connectivity analysis of the candidate subgraph also outputs the node category distribution, leaf component identifier, and at least one item from the list of isolated nodes for each connected component; wherein, a connected component consisting only of dimension table type and enumerated ontology type nodes is marked as a leaf component.

[0016] By employing the aforementioned technical means, fine-grained component-level topology features are provided, including node category composition, leaf component attributes, and isolated node information. This not only provides a basis for subsequent path filtering but also provides data support for operation and maintenance personnel to participate in and interpret the results, thereby improving the interpretability and debuggability of the solution.

[0017] As a preferred approach, before selecting the target connection path, a filtering step is performed on the candidate paths: candidate paths containing leaf components in the middle are removed, as well as candidate paths whose intermediate nodes are dimension table classes or enumeration ontology classes; then the remaining candidate paths are sorted and filtered according to the path quality score.

[0018] By employing the aforementioned technical means, invalid candidate paths that do not conform to business semantics are directly eliminated through pre-filtering rules, reducing the computational load of subsequent path quality assessment. At the same time, it further ensures that the completed path does not use leaf components, dimension tables, or enumeration nodes as intermediate bridges, avoiding the generation of lengthy dimension chains or enumeration connections without business meaning, and ensuring that the completed path conforms to the modeling logic of the business database.

[0019] As a preferred embodiment, the path quality score is obtained by multiplying the path length penalty factor by the weighting factor corresponding to each node category in the path; wherein the weighting factor corresponding to entity class and relation class nodes is higher than the weighting factor corresponding to dimension table class and enumeration ontology class nodes, and the longer the path length, the smaller the path length penalty factor value.

[0020] Through the above technical means, multi-factor quantitative evaluation of path quality is adopted. The length penalty factor prioritizes the selection of shorter paths with fewer hops to control the size of the subgraph after completion. The node category weighting factor guides the path to prioritize entity and relationship backbone nodes. The business semantic weight is used to correct the pure topological shortest path to avoid pseudo-shortest paths and achieve a balance between topological shortest and semantic optimality.

[0021] As a preferred embodiment, the recall strategy includes at least two of semantic recall, structural recall, relational recall, and sample recall; wherein, semantic recall is based on query semantic matching of related nodes and edges; structural recall identifies important topological elements based on graph structural features; relational recall performs precise matching through relation type and attributes; and sample recall selects based on the statistical features of data samples.

[0022] Through the aforementioned technical means, the multi-dimensional recall strategy covers relevant nodes from multiple dimensions such as semantics, topology, relationships, and statistics, avoiding the one-sidedness of a single recall strategy and improving the comprehensiveness of recall; it limits the number of retained paths for a single pair of components, further controls the size of the subgraph after completion, avoids excessive expansion of nodes caused by completion, and ensures the information density of the downstream context.

[0023] A graph topology retrieval and connected graph completion device, comprising: The graph construction module is used to abstract the data tables and relationships between tables in the target business database into graph nodes and graph edges to form a schema relationship graph; The multi-dimensional recall module is used to receive query requests and recall relevant nodes in the schema relationship diagram using at least two recall strategies. The nodes recalled by each strategy are merged according to a preset merging rule to obtain a set of candidate nodes. The subgraph generation module is used to extract the associated edges that both ends belong to the candidate node set from the Schema relationship graph based on the candidate node set, and generate candidate subgraphs; A connectivity analysis module is used to perform connectivity analysis on the candidate subgraph and identify all connected components contained in the candidate subgraph. The hypergraph construction module is used to encapsulate each connected component as a super node when the candidate subgraph contains at least two connected components, filter nodes that do not belong to the candidate node set from the schema relationship graph as candidate bridge nodes, and construct a hypergraph containing super nodes and candidate bridge nodes based on the edge relationship of the schema relationship graph. The path evaluation and filtering module is used to search for candidate paths that satisfy a preset maximum path length for each pair of connected component supernodes in the hypergraph, calculate the path quality score of each candidate path, and filter based on the quality score to obtain the target connection path corresponding to each pair of supernodes. The connectivity completion module is used to merge the nodes and edges corresponding to each target connection path in the schema relationship graph into the candidate subgraph to obtain the completed connected subgraph, and output the connected subgraph as the constraint context generated by the structured query.

[0024] A computer device includes a processor and a memory, the memory storing a computer program, wherein the processor executes the computer program to implement the steps of the graph topology retrieval and connected graph completion method.

[0025] A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the graph topology retrieval and connected graph completion method.

[0026] The beneficial effects of this invention are as follows: This invention automatically discovers and fills in the missing bridging nodes and related edges in the recall subgraph through the connectivity completion mechanism of hypergraph dimensionality reduction, so that the output subgraph has complete connectivity, providing coherent multi-table association constraints for downstream structured query generation, and fundamentally solving the core problem that the recall subgraph is broken and therefore cannot generate correct multi-table queries; in actual business database verification scenarios, it can significantly improve the query generation pass rate of complex multi-table queries.

[0027] This invention categorizes business database nodes into entities, relations, dimension tables, enumeration ontologies, etc., and implements differentiated strategies throughout the entire process of hypergraph construction, path filtering, and quality assessment. This fundamentally prevents enumerations and dimension tables from being misused as long-distance bridges, suppresses the problem of excessive fan-out of dimension table hubs, and ensures that the completion results fully conform to the modeling logic of the business database, thus possessing strong business interpretability.

[0028] This invention sets scale constraints at multiple stages, from node truncation in the recall phase and the upper limit of path search length to the limit of the number of paths for a single component. This ensures both the connectivity and information integrity of the subgraph and strictly controls the expansion of the subgraph after completion. It avoids problems such as excessively long context and attention dilution caused by full schema input, and balances operational efficiency and query performance in large-scale business database scenarios.

[0029] This invention provides multi-dimensional topological information such as component category distribution, leaf component identification, and isolated nodes in connectivity analysis output. This not only provides fine-grained input for the completion algorithm but also supports operation and maintenance personnel in performance tuning and problem troubleshooting, changing the shallow output mode of traditional graph retrieval that only returns a set of nodes.

[0030] This invention integrates semantic, structural, relational, and multi-path sample recall strategies, matching relevant nodes from multiple dimensions such as text semantics, topological importance, association type, and data statistics. This overcomes the shortcomings of single semantic recall, which is prone to missing key topological nodes, and improves the coverage and accuracy of the initial recall, providing a high-quality foundation for subsequent completion. Attached Figure Description

[0031] Figure 1 This is a flowchart of the graph topology retrieval and connected graph completion method of the present invention. Figure 2 This is a flowchart of the graph connectivity analysis process of the present invention. Figure 3 This is a schematic diagram illustrating the principle of the hypergraph construction and path discovery algorithm of this invention. Figure 4 This is a schematic diagram illustrating the principle of the multi-dimensional recall strategy of this invention. Figure 5 This is a schematic diagram comparing the subgraphs before and after connectivity completion according to the present invention. Detailed Implementation

[0032] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. This embodiment takes the intelligent query scenario of the operation and maintenance business database of large and medium-sized reservoirs and dams as a typical application scenario, and fully elaborates on the implementation details of this method. This solution can also be extended to other industry business database scenarios with complex multi-table relationships.

[0033] Example 1: This example is a graph topology retrieval and connected graph completion method, which specifically includes the following steps: S1. Abstract the data tables and relationships between tables in the target business database into graph nodes and graph edges to form a schema relationship graph.

[0034] In this embodiment, the data tables, fields, foreign key relationships between tables, dimension table relationships, enumeration mapping relationships, etc. in the target business database are abstracted into graph nodes and graph edges with category attributes in advance, and a globally connected schema relationship graph is constructed as the topological basis for subsequent retrieval and completion.

[0035] This example predefines a unified graph data structure specification, covering core data objects such as graph nodes, graph edges, graph instances, connectivity analysis results, and recall strategies: Graph nodes: contain core components such as unique node identifier, node name, node category, node attributes, and metadata information. Values ​​can be of types such as entity, relation, dimension table, enumerated ontology, fact table, and attribute.

[0036] Graph edges: include core components such as start node, end node, relationship type, edge weight, and edge attributes.

[0037] Graph example: It includes three parts: graph name, node list, and edge list, which fully describe the topology and attribute information of a schema graph.

[0038] Connectivity analysis results include: Boolean values ​​for connectivity status, number of connected components, list of connected components, maximum size of connected components, list of isolated nodes, and component details analysis; among which, component details analysis includes fields such as component number, component size, list of component nodes, node category distribution, and leaf component identifier.

[0039] Recall strategy: includes strategy name, strategy type, strategy weight, and strategy parameters. The strategy type can take values ​​such as semantics, structure, relation, and sample.

[0040] In this embodiment, the JSON Schema definition of the data structure is as follows: { "GraphNode": { "type": "object", "properties": { "code": { "type": "string", "description": "Unique identifier for the node" }, "name": { "type": "string", "description": "Node Name" }, "category": { "type": "string", "enum": ["entity", "relationship", "dimension_table","enum_ontology", "fact_table", "attribute"], "description": "Node category" }, "properties": { "type": "object", "description": "Node attributes" }, "metadata": { "type": "object", "description": "Metadata information" } }, "required": ["code", "name", "category"] }, "GraphEdge": { "type": "object", "properties": { left: { "$ref": "# / GraphNode", "description": "Starting node" }, "right": { "$ref": "# / GraphNode", "description": "Termination Node" }, "relation_type": { "type": "string", "description": "relationship type" }, "weight": { "type": "number", "minimum": 0, "description": "edge weight" }, "properties": { "type": "object", "description": "edge attribute" } }, "required": ["left", "right", "relation_type"] }, "Graph": { "type": "object", "properties": { "name": { "type": "string", "description": "Image Name" }, "nodes": { "type": "array", "items": {"$ref": "# / GraphNode"}, "description": "Node list" }, "edges": { "type": "array", "items": {"$ref": "# / GraphEdge"}, "description": "edge list" } } }, "ConnectivityAnalysis": { "type": "object", "properties": { "is_connected": { "type": "boolean", "description": Is the graph connected? }, "num_components": { "type": "integer", "minimum": 0, "description": "Number of connected components" }, "components": { "type": "array", "items": { "type": "array", "items": {"type": "string"} }, "description": "Connected component list" }, "largest_component_size": { "type": "integer", "minimum": 0, "description": "Maximum connected component size" }, "isolated_nodes": { "type": "array", "items": {"type": "string"}, "description": "Isolated node list" }, "component_analysis": { "type": "array", "items": { "type": "object", "properties": { "component_id": {"type": "integer"}, "size": {"type": "integer"}, "nodes": {"type": "array", "items": {"type": "string"}}, "category_distribution": {"type": "object"}, "is_leaf_component": {"type": "boolean"} } } } } }, "RetrievalStrategy": { "type": "object", "properties": { "name": { "type": "string", "description": "strategy name" }, "type": { "type": "string", "enum": ["semantic", "structural", "relational","sample"], "description": "strategy type"}, "weight": { "type":"number", "minimum": 0, "maximum": 1, "description": "strategy weight" }, "parameters": { "type": "object", "description": "Strategy parameters" } } } } In this embodiment, the category attributes of graph nodes include at least entity class, relationship class, dimension table class, and enumerated ontology class. In the dam operation and maintenance business database scenario, the business meaning and role positioning of each type of node are as follows: Entity-type nodes: These correspond to core business object tables, such as dam hubs, buildings, monitoring sections, monitoring instruments, equipment, and inspection work orders. They are the core backbone of business relationships and can be used as bridging nodes.

[0041] Relationship nodes: These are tables that correspond to relationships between different entities or many-to-many intermediate tables, such as instrument-section relationship tables or equipment-defect relationship tables. They are the core bridges connecting different entities and are given priority as bridging nodes.

[0042] Fact table type nodes: These correspond to business fact data tables, such as seepage monitoring data tables, displacement monitoring data tables, and defect record tables, and carry core business data.

[0043] Dimension table type nodes: corresponding to dimension tables, such as organization dimension, manufacturer dimension, line dimension, etc., can participate in association but are not given priority as long-distance bridging.

[0044] Enumerated ontology nodes: These correspond to enumerated classification tables, such as defect level, operating status, and instrument type. They are only used as leaf nodes and are prohibited from being used as intermediate bridges.

[0045] By classifying the business database into categories, the modeling semantics are natively embedded into the graph model, providing a data foundation for subsequent differentiated completion logic.

[0046] S2. Receive the query request and use at least two recall strategies to recall relevant nodes in the schema relationship diagram. Merge the nodes recalled by each strategy according to the preset merging rules to obtain a candidate node set.

[0047] This embodiment supports recall strategies such as semantic recall, structural recall, relational recall, and sample recall, which can be flexibly combined. The overall execution flow of multi-dimensional recall is as follows: traverse all configured recall strategies, call the recall logic of each strategy in sequence, and match nodes related to the query request from the original schema relationship graph; if a single strategy fails to execute, the overall process is not interrupted, and the strategy can simply return an empty result; finally, return the recall node set corresponding to each strategy.

[0048] The core algorithm logic for multi-dimensional recall in this embodiment is as follows: ALGORITHM MultiDimensionalRetrieval(query, raw_graph, strategies)INPUT: query - query string raw_graph - raw graph data Strategies - List of Recall Strategies OUTPUT: Recall result dictionary BEGIN retrieval_results ← {} FOR EACH strategy_name IN strategies DO strategy ← getStrategy(strategy_name) TRY nodes ← strategy.retrieve(query, raw_graph) retrieval_results[strategy_name] ←nodes CATCH exception retrieval_results[strategy_name] ← [] END TRY END FOR RETURN retrieval_results END The implementation logic of each recall strategy in this example is as follows: Semantic Recall: After standardizing the user query text, calculate the semantic similarity between each graph node and the query text in turn. Nodes with similarity higher than a preset threshold are retained, sorted from high to low similarity, and the top preset number of nodes are taken as the semantic recall results.

[0049] The core function logic of semantic recall is as follows: FUNCTION semanticRetrieval(query, graph) relevant_nodes ← [] query_lower ← query.toLowerCase() FOR EACH node IN graph.nodes DO score ← calculateSemanticScore(query_lower, node) IF score>0.3 THEN relevant_nodes.add((node, score)) END IF END FOR / / Sort by score relevant_nodes ← SORT(relevant_nodes, BY score DESC) RETURN [node FOR (node, score) IN relevant_nodes[0:20]] END Structure Recall: Based on the topological features of the schema relationship graph, the degree centrality score and betweenness centrality score of all nodes are calculated separately. A comprehensive topological importance score is then calculated for each node with a fixed weight. This score is multiplied by the category weight of the corresponding node category to obtain the final score. Nodes with scores higher than a preset threshold are retained, and the nodes are sorted from highest to lowest score. The top preset number of nodes are selected as the structure recall results. This strategy can identify hub nodes that are semantically not directly matched but occupy key topological positions.

[0050] The core function logic for structured recall is as follows: FUNCTION structuralRetrieval(query, graph) G ← convertToNetworkX(graph) relevant_nodes ← [] / / Calculate the importance of the structure centrality_scores ← calculateDegreeCentrality(G) betweenness_scores ← calculateBetweennessCentrality(G) FOR EACH node IN graph.nodes DO importance_score ← 0.6 × centrality_scores[node.code] + 0.4 × betweenness_scores[node.code] category_weight ← getCategoryWeight(node.category) final_score ← importance_score × category_weight IF final_score>0.1 THEN relevant_nodes.add((node, final_score)) END IF END FOR relevant_nodes ← SORT(relevant_nodes, BY score DESC) RETURN [node FOR (node, score) IN relevant_nodes[0:15]] END Relationship recall: Based on the association type mentioned in the query, accurately match the corresponding relationship node and associated entity node.

[0051] Sample recall: Based on the statistical characteristics of business data samples, such as data volume and historical query frequency, filter frequently accessed table nodes.

[0052] In this embodiment, the multi-path recall results are fused using a weighted merging rule. The specific execution process is as follows: Corresponding strategy weights are pre-set for different recall strategies, and position weights are set for each node in the recall results. The higher the ranking, the higher the position weight, and the position weight is the reciprocal of the ranking. For each node, its score in each recall strategy is multiplied by the corresponding strategy weight and position weight, and the results are summed to obtain a comprehensive weighted score. All nodes are sorted from high to low according to the comprehensive weighted score, and no more than a preset maximum number of nodes are selected to form the final candidate node set.

[0053] The core function logic for weighted merging is as follows: FUNCTION weightedMerge(retrieval_results) node_scores ← initializeDict() node_objects ← initializeDict() / / Strategy weights strategy_weights ← { "semantic": 0.4, "structural": 0.3, "relational": 0.2, "sample": 0.1 } FOR EACH strategy_name, nodes IN retrieval_results DO weight ← strategy_weights.get(strategy_name, 0.25) FOR i ← 0 TO LENGTH(nodes) - 1 DO node ← nodes[i] / / Position weight: Nodes listed earlier have higher weight. position_weight ← 1.0 / (i + 1) node_scores[node.code] ← node_scores[node.code]+ weight × position_weight node_objects[node.code] ← node END FOR END FOR / / Sort by score sorted_nodes ← SORT(node_scores.items(), BY score DESC) / / Return the first N nodes max_nodes ← MIN(50, LENGTH(sorted_nodes)) RETURN [node_objects[code] FOR (code, score) IN sorted_nodes[0:max_nodes]] END The typical recall strategy configuration in this embodiment is as follows: { "retrieval_strategies_config": { "semantic_strategy": { "keyword_matching": { "weight": 0.8, "fuzzy_threshold": 0.7 }, "property_matching": { "weight": 0.3, "case_sensitive": false }, "category_bonus": { "entity": 0.2, "relationship": 0.2 } }, "structural_strategy": { "centrality_measures": { "degree_centrality": 0.6, "betweenness_centrality": 0.4 }, "importance_threshold": 0.1, "category_weights": { "entity": 1.0, "relationship": 0.9, "dimension_table": 0.6 } }, "merge_strategies": { "union": { "description": "Take the union of all policy results", "deduplication": true }, "weighted": { "description": "Strategy-based weight merging", "max_nodes": 50, "position_weight_decay": true } } } } S3. Based on the candidate node set, extract the associated edges that both ends of the candidate node set belong to the candidate node set in the Schema relationship graph, and generate a candidate subgraph.

[0054] S4. Perform connectivity analysis on the candidate subgraph to identify all connected components contained in the candidate subgraph.

[0055] In this embodiment, connectivity analysis uses a depth-first search algorithm to identify all connected components of the candidate subgraph. The specific process is as follows: convert the candidate subgraph into an adjacency list format, initialize the set of visited nodes and the list of connected components; traverse all nodes in sequence. If a node has not been visited, start a depth-first traversal, classify all traversed nodes into the same connected component, and mark them as visited; after the traversal is completed, all connected components are obtained.

[0056] After identifying connected components, feature analysis is performed on each component: the distribution of the number of each node category within the component is statistically analyzed to determine whether the component is a leaf component; if a connected component consists only of dimension table type and enumerated ontology type nodes, it is marked as a leaf component. This type of component only serves as the endpoint of business attributes and has no bridging value. At the same time, isolated nodes in the subgraph are identified, that is, independent nodes with a degree of 0.

[0057] The final output is a structured connectivity analysis result, which includes information such as connectivity status, number of components, list of component nodes, maximum component size, list of isolated nodes, category distribution of each component and leaf component identifier. This provides input for subsequent completion and also supports the interpretation of operation and maintenance commissioning results.

[0058] The core algorithm logic for connectivity analysis in this embodiment is as follows: ALGORITHM AnalyzeConnectivity(graph) INPUT: Graph Structure OUTPUT: Connectivity analysis results BEGIN G ← convertToAdjacencyList(graph) components ← [] visited ← initializeSet() / / Depth-first search for connected components FOR EACH node IN G.nodes DO IF node NOT IN visited THEN component ← [] dfsVisit(G, node, visited, component) components.add(component) END IF END FOR / / Analyze the characteristics of each component component_analysis ← [] FOR i ← 0 TO LENGTH(components) - 1 DO comp ← components[i] category_counts ← countCategories(comp) analysis ← { component_id: i, size: LENGTH(comp), nodes: comp, category_distribution: category_counts, is_leaf_component: isLeafComponent(comp) } component_analysis.add(analysis) END FOR / / Calculate overall metrics largest_size ← MAX(LENGTH(comp) FOR comp IN components) isolated_nodes ← findIsolatedNodes(G) result ← { is_connected: LENGTH(components) = 1, num_components: LENGTH(components), components: components, largest_component_size: largest_size, component_sizes: [LENGTH(comp) FOR comp IN components], isolated_nodes: isolated_nodes, component_analysis: component_analysis } RETURN result END FUNCTION dfsVisit(G, node, visited, component) visited.add(node) component.add(node) FOR EACH neighbor IN G.adjacentNodes(node) DO IF neighbor NOT IN visited THEN dfsVisit(G, neighbor, visited, component) END IF END FOR END S5. When the candidate subgraph contains at least two connected components, each connected component is encapsulated as a super node. Nodes that do not belong to the candidate node set are selected from the schema relationship graph as candidate bridge nodes. Based on the edge relationship of the schema relationship graph, a hypergraph containing super nodes and candidate bridge nodes is constructed.

[0059] S51. Generate a corresponding supernode for each connected component, and record the original node set corresponding to each supernode; identify and mark the leaf component supernodes.

[0060] S52. Filter candidate bridging nodes: From all nodes in the original schema relationship graph, exclude nodes that already belong to the candidate node set, and then exclude enumerated ontology class and dimension table class nodes. The remaining entity class and relationship class nodes are added to the hypergraph as candidate bridging nodes.

[0061] S53. Establish meta-edges: Traverse all edges in the original schema graph and map the nodes at both ends of the edge to the corresponding super nodes or candidate bridge nodes; if the mapping results at both ends are different, establish the corresponding meta-edges in the hypergraph.

[0062] S54. By constructing a hypergraph, the complex path search between multiple nodes in the original graph is reduced to a path search between a small number of hypernodes. At the same time, invalid bridging nodes are directly filtered out at the search space level, which greatly improves the efficiency and effectiveness of subsequent path search.

[0063] The core function logic for hypergraph construction in this embodiment is as follows: FUNCTION buildMetaGraph(components, G, sub_nodes) meta_G ← initializeGraph() comp_id2nodes ← {} leaf_comps ← {} / / Create a supernode for each connected component FOR i ← 0 TO LENGTH(components) - 1 DO comp_id ← "comp_" + i comp_id2nodes[comp_id] ← components[i] meta_G.addNode(comp_id) / / Leaf component identification IF isLeafComponent(components[i]) THEN leaf_comps.add(comp_id) END IF END FOR / / Add non-subgraph nodes non_sub_nodes ← G.nodes - sub_nodes FOR EACH node IN non_sub_nodes DO IF NOT isEnumOrDimension(node) THEN meta_G.addNode(node) END IF END FOR / / Add meta edge FOR EACH edge (u, v) IN G.edges DO u_comp ← findComponentFor(u, comp_id2nodes) v_comp ← findComponentFor(v, comp_id2nodes) u_meta ← u_comp IF u_comp EXISTS ELSE u v_meta ← v_comp IF v_comp EXISTS ELSE v IF u_meta ≠ v_meta THEN meta_G.addEdge(u_meta, v_meta) END IF END FOR RETURN meta_G END S6. In the hypergraph, for each pair of connected component hypernodes, search for candidate paths that satisfy the preset maximum path length, calculate the path quality score of each candidate path, and filter based on the quality score to obtain the target connection path corresponding to each pair of hypernodes.

[0064] On the constructed hypergraph, for each pair of connected component supernodes, search for all simple paths whose length does not exceed the preset maximum length to obtain a set of candidate paths.

[0065] The pre-filtering step then proceeds: candidate paths containing leaf components in the middle are eliminated, as are candidate paths where the intermediate nodes are dimension table classes or enumeration ontology classes. The default bridging rule is that dimension table class and enumeration ontology class nodes cannot be used as bridging nodes in the middle of a path; they can only be used as path endpoints. Pre-filtering directly eliminates invalid paths that do not conform to business semantics, reducing subsequent computation.

[0066] The remaining candidate paths after filtering are evaluated for path quality. The path quality score is calculated by multiplying the path length penalty factor by the weighted factors corresponding to the categories of each node in the path. The path length penalty factor decreases as the number of hops increases, and the longer the path, the stronger the penalty. The node category weighted factors are set with differentiated values ​​according to the node type. The weighted factors for entity and relationship nodes are greater than 1, while the weighted factors for other node categories are less than 1.

[0067] After calculating the quality scores of all candidate paths, they are sorted from highest to lowest score. For each pair of connected component supernodes, no more than three of the highest-scoring paths are retained as target connection paths. Through quality assessment and path number limitation, the semantic rationality of the completed path is ensured while controlling the size of the subgraph after completion.

[0068] The core algorithm logic for path discovery and quality assessment is as follows: ALGORITHM FindConnectionPaths(meta_graph, components) INPUT: meta_graph - Hypergraph components - List of connected components OUTPUT: List of connection paths BEGIN connection_paths ← [] FOR i ← 0 TO LENGTH(components) - 1 DO FOR j ← i + 1 TO LENGTH(components) - 1 DO comp_i_id ← "comp_" + i comp_j_id ← "comp_" + j TRY / / Find all simple paths all_paths ← findAllSimplePaths(meta_graph, comp_i_id, comp_j_id, 10) / / Filtering and sorting paths valid_paths ← filterAndRankPaths(all_paths) connection_paths ← connection_paths ∪ valid_paths CATCH NoPathException CONTINUE END TRY END FOR END FOR RETURN connection_paths END FUNCTION filterAndRankPaths(paths) valid_paths ← [] FOR EACH path IN paths DO / / Filter intermediate paths containing leaf components IF hasLeafNodesInMiddle(path) THEN CONTINUE END IF / / Calculate path quality quality_score ← calculatePathQuality(path) valid_paths.add((path, quality_score)) END FOR / / Sort by quality valid_paths ← SORT(valid_paths, BY quality_score DESC) / / Return the top N best paths max_paths ← MIN(3, LENGTH(valid_paths)) RETURN [path FOR (path, score) IN valid_paths[0:max_paths]] END FUNCTION calculatePathQuality(path) IF LENGTH(path)<= 2 THEN RETURN 1.0 END IF quality_score ← 1.0 / / Path length penalty length_penalty ← 1.0 / (LENGTH(path) - 1) quality_score ← quality_score × length_penalty / / Weighted intermediate node types FOR EACH node_id IN path[1:-1]DO IF isEntity(node_id) THEN quality_score ← quality_score × 1.2 ELSE IF isRelationship(node_id) THEN quality_score ← quality_score × 1.5 ELSE quality_score ← quality_score × 0.8 END IF END FOR RETURN quality_score END S7. Merge the nodes and edges corresponding to each target connection path in the Schema relationship graph into the candidate subgraph to obtain the completed connected subgraph, and output the connected subgraph as the constraint context generated by the structured query.

[0069] All selected target connection paths are mapped back to their corresponding original nodes and edges in the original schema graph. These are then merged into the initial candidate subgraph using a set union method. After automatic deduplication, a completed connected subgraph is obtained. If the subgraph is already connected, the original subgraph is returned directly without performing subsequent completion steps to avoid unnecessary computation.

[0070] The core algorithm logic for connectivity completion in this embodiment is as follows: ALGORITHM ConnectInterGraph(raw_graph, sub_graph) INPUT: raw_graph - raw connected graph subgraph - The subgraph that needs to be completed OUTPUT: The completed connected graph BEGIN / / Create a graph representation G ← convertToAdjacencyList(raw_graph) sub_nodes ← extractNodeCodes(sub_graph.nodes) sub_edges ← extractEdgePairs(sub_graph.edges) / / Analyze the connectivity of subgraphs components ← findConnectedComponents(sub_nodes, sub_edges) IF LENGTH(components)<= 1 THEN RETURN sub_graph / / Connected END IF / / Constructing a hypergraph meta_graph ← buildMetaGraph(components, G, sub_nodes) / / Find connection path connection_paths ← findConnectionPaths(meta_graph, components) / / Extract path elements new_nodes ← sub_nodes new_edges ← sub_edges FOR EACH path IN connection_paths DO path_nodes, path_edges ← extractPathElements(path, G) new_nodes ← new_nodes ∪ path_nodes new_edges ← new_edges ∪ path_edges END FOR / / Build the result graph result_graph ← buildResultGraph(raw_graph, new_nodes, new_edges) RETURN result_graph END Example 2: This example is a graph topology retrieval and connected graph completion device, comprising: The graph construction module is used to abstract the data tables and relationships between tables in the target business database into graph nodes and graph edges to form a schema relationship graph; The multi-dimensional recall module is used to receive query requests and recall relevant nodes in the schema relationship diagram using at least two recall strategies. The nodes recalled by each strategy are merged according to a preset merging rule to obtain a set of candidate nodes. The subgraph generation module is used to extract the associated edges that both ends belong to the candidate node set from the Schema relationship graph based on the candidate node set, and generate candidate subgraphs; A connectivity analysis module is used to perform connectivity analysis on the candidate subgraph and identify all connected components contained in the candidate subgraph. The hypergraph construction module is used to encapsulate each connected component as a super node when the candidate subgraph contains at least two connected components, filter nodes that do not belong to the candidate node set from the schema relationship graph as candidate bridge nodes, and construct a hypergraph containing super nodes and candidate bridge nodes based on the edge relationship of the schema relationship graph. The path evaluation and filtering module is used to search for candidate paths that satisfy a preset maximum path length for each pair of connected component supernodes in the hypergraph, calculate the path quality score of each candidate path, and filter based on the quality score to obtain the target connection path corresponding to each pair of supernodes. The connectivity completion module is used to merge the nodes and edges corresponding to each target connection path in the schema relationship graph into the candidate subgraph to obtain the completed connected subgraph, and output the connected subgraph as the constraint context generated by the structured query.

[0071] Example 3: This example is a computer device, including a processor and a memory. The memory stores a computer program, and when the processor executes the computer program, it implements the steps of the graph topology retrieval and connected graph completion method described in Example 1.

[0072] Example 4: This example is a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the steps of the graph topology retrieval and connected graph completion method described in Example 1.

Claims

1. A method for graph topology retrieval and connected graph completion, characterized in that, include: The data tables and relationships between tables in the target business database are abstracted into graph nodes and graph edges to form a schema relationship graph; Receive query requests and use at least two recall strategies to recall relevant nodes in the schema relationship diagram. Merge the nodes recalled by each strategy according to a preset merging rule to obtain a candidate node set. Based on the candidate node set, extract the associated edges in the Schema relationship graph where both ends belong to the candidate node set, and generate a candidate subgraph; Perform connectivity analysis on the candidate subgraph to identify all connected components contained in the candidate subgraph; When the candidate subgraph contains at least two connected components, each connected component is encapsulated as a super node. Nodes that do not belong to the candidate node set are selected from the schema relationship graph as candidate bridge nodes. Based on the edge relationship of the schema relationship graph, a hypergraph containing super nodes and candidate bridge nodes is constructed. In the hypergraph, candidate paths that satisfy the preset maximum path length are searched for each pair of connected component hypernodes. The path quality score of each candidate path is calculated, and the path is filtered based on the quality score to obtain the target connection path corresponding to each pair of hypernodes. The nodes and edges corresponding to each target connection path in the schema relation graph are merged into the candidate subgraph to obtain the completed connected subgraph, and the connected subgraph is output as the constraint context for the structured query generation.

2. The graph topology retrieval and connected graph completion method according to claim 1, characterized in that, The category attributes of the graph nodes include at least entity class, relation class, dimension table class and enumerated ontology class; the step of filtering candidate bridge nodes from the schema relation graph includes: filtering out nodes that do not belong to the candidate node set and whose category is entity class or relation class as candidate bridge nodes.

3. The graph topology retrieval and connected graph completion method according to claim 1, characterized in that, The preset merging rule is a weighted merging rule, including: Assign corresponding strategy weights to each recall strategy, assign corresponding position weights to the ranking of nodes in the single strategy recall results, calculate the comprehensive weighted score of each node, sort them from high to low according to the comprehensive weighted score, and extract no more than a preset maximum number of nodes to form a candidate node set.

4. The graph topology retrieval and connected graph completion method according to claim 1, characterized in that, The connectivity analysis of the candidate subgraph also outputs the node category distribution, leaf component identifier, and at least one item from the list of isolated nodes for each connected component; wherein, a connected component consisting only of dimension table class and enumerated ontology class nodes is marked as a leaf component.

5. The graph topology retrieval and connected graph completion method according to claim 4, characterized in that, Before selecting the target connection path, a filtering step is performed on the candidate path: candidate paths containing leaf components in the middle are removed, as well as candidate paths whose middle nodes are dimension table classes or enumeration ontology classes; then the remaining candidate paths are sorted and filtered according to the path quality score.

6. The graph topology retrieval and connected graph completion method according to claim 1, characterized in that, The path quality score is obtained by multiplying the path length penalty factor by the weighting factor corresponding to each node category in the path; the weighting factor corresponding to entity class and relation class nodes is higher than that corresponding to dimension table class and enumeration ontology class nodes. The longer the path length, the smaller the path length penalty factor value.

7. The graph topology retrieval and connected graph completion method according to claim 1, characterized in that, The recall strategy includes at least two of semantic recall, structural recall, relational recall, and sample recall; wherein, semantic recall is based on query semantic matching of nodes and edges; structural recall identifies important topological elements based on graph structure features; relational recall performs precise matching through relation type and attributes; and sample recall selects based on the statistical features of data samples.

8. A graph topology retrieval and connected graph completion device, characterized in that, include: The graph construction module is used to abstract the data tables and relationships between tables in the target business database into graph nodes and graph edges to form a schema relationship graph; The multi-dimensional recall module is used to receive query requests and recall relevant nodes in the schema relationship diagram using at least two recall strategies. The nodes recalled by each strategy are merged according to a preset merging rule to obtain a set of candidate nodes. The subgraph generation module is used to extract the associated edges that both ends belong to the candidate node set from the Schema relationship graph based on the candidate node set, and generate candidate subgraphs; A connectivity analysis module is used to perform connectivity analysis on the candidate subgraph and identify all connected components contained in the candidate subgraph. The hypergraph construction module is used to encapsulate each connected component as a super node when the candidate subgraph contains at least two connected components, filter nodes that do not belong to the candidate node set from the schema relationship graph as candidate bridge nodes, and construct a hypergraph containing super nodes and candidate bridge nodes based on the edge relationship of the schema relationship graph. The path evaluation and filtering module is used to search for candidate paths that satisfy a preset maximum path length for each pair of connected component supernodes in the hypergraph, calculate the path quality score of each candidate path, and filter based on the quality score to obtain the target connection path corresponding to each pair of supernodes. The connectivity completion module is used to merge the nodes and edges corresponding to each target connection path in the schema relationship graph into the candidate subgraph to obtain the completed connected subgraph, and output the connected subgraph as the constraint context generated by the structured query.

9. A computer device comprising a processor and a memory, the memory storing a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the graph topology retrieval and connected graph completion method as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the graph topology retrieval and connected graph completion method as described in any one of claims 1 to 7.

Images