Hierarchical database building and retrieval method based on tree structure

Abstract

The invention provides a hierarchical database building and retrieval method based on a tree structure, data model design, hierarchical index building, data extraction, extraction and retrieval optimization and data storage and management, due to the inherent hierarchy and directivity of the tree structure, traversal and retrieval can become more visual and efficient, and the method is suitable for large-scale popularization and application. The tree structure supports efficient hierarchical traversal algorithms, such as depth-first search (DFS) and breadth-first search (BFS), and the algorithms are very effective for scenes such as authority inheritance and organization structure expansion.

Description

Technical Field

[0001] The present invention relates to the field of data retrieval, and in particular to a tree-structured hierarchical database building and retrieval method. Background Art

[0002] When processing complex structured data stored in the form of entity-relationship ER diagrams in a database, the complex dependencies between data make retrieval complicated. In this case, recursive queries are used. In large databases, recursive queries are very resource-intensive and difficult to guarantee accuracy. Summary of the invention

[0003] The purpose of the present invention is to address the deficiencies of the above-mentioned prior art and provide a hierarchical database construction and retrieval method based on a tree structure, which converts complex ER diagram relationships into a tree structure and can significantly improve retrieval efficiency.

[0004] To achieve the above object, the present invention adopts the following technical solutions: The present invention provides a tree-structured hierarchical database construction and retrieval method, comprising the following steps: S1. Design data model: define the dependency relationship between the root node of the tree structure and other nodes; S2. Build a hierarchical index: Starting from the top level of the tree, index the data layer by layer to build a complete hierarchical index structure; S3, data extraction: use hierarchical index tables to efficiently extract required data from the database; S4, extraction and retrieval optimization: Use the improved DFS / BFS algorithm with jump pointer to traverse the tree and perform extraction operations, and analyze the time complexity of the improved DFS / BFS algorithm with jump pointer; S5. Data storage and management: Ensure that the extracted data can be stored efficiently and can be easily accessed and queried later.

[0005] Further, the S1 includes: S101. Determine the root node of the tree structure: The root node modeling: set up is the set of all data entities in the database, where n is the number of data entities; set up Represents data entity The collection of other data entities it depends on; Root Node Defined as: ; S102. Define the dependency relationship between nodes: each node, except the root node, should have one or more dependent nodes; The dependency modeling: set up Represents dependent data entities The collection of child nodes; For any non-root node , there must be at least one , so that ,in, For all non-root nodes An element that makes up a set; For any data entity ,exist ,in, For data entities An element that makes up a set; Make data entity , indicating that each non-root node is depended on by at least one other node.

[0006] Further, the S2 includes: S201, hierarchical index establishment: starting from the top node of the tree structure, indexing data layer by layer downward; Recursive index query: set up Represents any node of a tree structure; set up Represents any node All child nodes of ; set up Represents any node Level of For the root node , set the root node level ; For any node and child nodes , set the child node Level ; S202: Building a hierarchical index table Organize the index information into a hierarchical index table for subsequent data extraction; For index tables , let each entry be , Include: Represents the node ID; Represents the node level; Represents the parent node ID; Represents a list of child nodes; S203, Index retrieval and hierarchy clarification: Recursive index building process: Starting from the root node, perform indexing operations for each node, query the node's child nodes, assign appropriate levels to each child node, and record the relationship between the node and the corresponding child nodes in the index table.

[0007] Further, the S3 includes: S301. Mathematical expression of data extraction order: Data is extracted from the bottom layer to the top layer, and the extraction order is determined by using the level information in the level index table; Define the maximum value of the level: set up Is the index table The maximum level of all entries in , the formula is: ; Extract in reverse order: For each level From the maximum level To 0, the node set of the corresponding level is defined as: ; Extract data layer by layer to ensure that the dependent nodes of each node are extracted before itself; S302. Mathematical expression of dependency check: Check whether the node dependencies have been extracted: The set of dependencies for each node is defined as: ; Check if all dependencies of a node have been extracted, using indicator functions to represent child nodes Has it been extracted? ; S303, avoid repeated extraction: Mark and check extraction status: Every time any node After extraction, update the status: ; Before extracting any node Before, check: .

[0008] Furthermore, in S4, the improved DFS / BFS algorithm with a jump pointer is specifically as follows: Use of jump pointer: The jump pointer directly starts from a node Jump to a node in the subtree , and across layer; Jump count calculation: The depth of the tree is , each time you cross Layer, when querying the target node, the total number of jumps required is: ; By using the jump pointer, the time complexity of querying the target node is ; For paths that cannot be reached directly by jumping, the number of node visits is: ; in, Represents the total number of nodes in the tree; Represents the number of branching factors; as the number of spanned layers increases, the jump pointer can cover more levels, and the number of remaining nodes that need to be visited layer by layer will decrease; After the introduction of jump pointers, the total time complexity is expressed as the sum of the complexity of the jump part and the complexity of the uncovered node part; The complexity of the jumping part: the number of jumps is , the complexity of each jump is O(1), then: ; The complexity of the uncovered node part: For nodes that are not covered by jumps, the number of node visits is , the access complexity is: ; Then, the total time complexity is: .

[0009] Further, the S5 includes: S501, data storage structure: storage node and level information; For every any node ,use Storage Node Tier , parent node , child node list , the data storage model is expressed as: ; in, Indicates the specific data of the node; S502, index creation and optimization: create indexes for common query paths; If a single level or node type is queried, create an index on that level or node type: ; in, Indicates the type or characteristics of a node; S503, optimizing data access path: adjusting the physical layout of data storage or index strategy according to the data access mode to reduce data access time; Let the data access function be , used to efficiently access any node relevant data; ; Represents actual data access operations, including reading data from storage media.

[0010] The beneficial effects of the present invention are as follows: due to the inherent hierarchy and directionality of the tree structure, traversal and retrieval can become more intuitive and efficient. The tree structure supports efficient hierarchical traversal algorithms, such as depth-first search DFS and breadth-first search BFS, which are very effective for scenarios such as permission inheritance and organizational structure expansion. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Figure 1 A flowchart of a tree-structured hierarchical database construction and retrieval method; Figure 2 Schematic diagram of the hierarchy and dependency relationships in the embodiment. DETAILED DESCRIPTION

[0012] In order to make the purpose, technical solution and advantages of the present invention more clearly understood, the present invention is further described in detail below in conjunction with the accompanying drawings. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not used to limit the present invention.

[0013] See also Figure 1 , a hierarchical database construction and retrieval method based on a tree structure, comprising the following steps: S1. Design data model: define the dependency relationship between the root node of the tree structure and other nodes; S2. Build a hierarchical index: Starting from the top level of the tree, index the data layer by layer to build a complete hierarchical index structure; The relationship between each level can be clarified to optimize the subsequent data extraction process.

[0014] S3, data extraction: use hierarchical index tables to efficiently extract required data from the database; Specifically, this process emphasizes data extraction from the bottom layer upwards, ensuring that upper-layer data is processed only after the lower-layer data on which it depends has been extracted, so as to avoid duplicate extraction and improve extraction efficiency.

[0015] S4, extraction and retrieval optimization: Use the improved DFS / BFS algorithm with jump pointer to traverse the tree and perform extraction operations, and analyze the time complexity of the improved DFS / BFS algorithm with jump pointer; S5. Data storage and management: Ensure that the extracted data can be stored efficiently and can be easily accessed and queried later.

[0016] The S1 includes: Specifically, the root node is the starting point of the tree structure, representing the bottom-level data, which does not depend on any other data. In the database model, the root node can be regarded as the main entity, and all other entities depend on it directly or indirectly. Those entities that do not depend on other data and other data depend on them are selected as root nodes.

[0017] S101. Determine the root node of the tree structure: The root node modeling: set up is the set of all data entities in the database, where is the number of data entities; set up Represents data entity The collection of other data entities it depends on; Root Node Defined as: ; S102. Define the dependency relationship between nodes: each node, except the root node, should have one or more dependent nodes; Specifically, these dependencies define a hierarchical structure between data, where each upper node depends on one or more lower nodes.

[0018] The dependency modeling: set up Represents dependent data entities The collection of child nodes; For any non-root node , there must be at least one , so that ,in, For all non-root nodes An element that makes up a set; For any data entity ,exist ,in, For data entities An element that makes up a set; Make data entity , indicating that each non-root node is depended on by at least one other node.

[0019] The S2 includes: S201, hierarchical index establishment: starting from the top node of the tree structure, indexing data layer by layer downward; implemented through recursive query, each query will collect index information of the current level node and its child nodes.

[0020] Recursive index query: set up Represents any node of a tree structure; set up Represents any node All child nodes of ; set up Represents any node Level of For the root node , set the root node level ; For any node and child nodes , set the child node Level ; S202: Building a hierarchical index table Organize the index information into a hierarchical index table for subsequent data extraction; Specifically, the index table includes node identifiers, levels, and dependency information. Each row in the table represents a node, including node ID, level, parent node ID, and child node list; For index tables , let each entry be , Include: Represents the node ID; Represents the node level; Represents the parent node ID; Represents a list of child nodes; S203, Index retrieval and hierarchy clarification: Recursive index building process: Starting from the root node, perform indexing operations for each node, query the node's child nodes, assign appropriate levels to each child node, and record the relationship between the node and the corresponding child nodes in the index table.

[0021] Specifically, through the index table, any node and related hierarchical and sub-node information can be quickly accessed, greatly improving the efficiency and accuracy of data retrieval.

[0022] The S3 includes: S301. Mathematical expression of data extraction order: Data is extracted from the bottom layer to the top layer, and the extraction order is determined by using the level information in the level index table; Define the maximum value of the level: set up Is the index table The maximum level of all entries in , the formula is: ; Extract in reverse order: For each level From the maximum level To 0, the node set of the corresponding level is defined as: ; Extract data layer by layer to ensure that the dependent nodes of each node are extracted before itself; S302. Mathematical expression of dependency check: Check whether the node dependencies have been extracted: The set of dependencies for each node is defined as: ; Check if all dependencies of a node have been extracted, using indicator functions to represent child nodes Has it been extracted? ; S303, avoid repeated extraction: Specifically, during the extraction process, if some data has been extracted in the next layer, it will not be extracted repeatedly. This is achieved by marking the extracted nodes in the index table. For each node, an extraction status is maintained, and the extraction status of the node is updated after each data extraction.

[0023] Mark and check extraction status: Every time any node After extraction, update the status: ; Before extracting any node Before, check: .

[0024] Specifically, special dependency processing: In order to prevent data extraction from entering an infinite loop, when the data is in the following three special dependencies, the processing method is as follows: Lower layer data dependency processing: The lower-level data dependency processing rule means that when data depends on lower-level data, it should be extracted directly from the bottom layer upwards. The advantage is that the lower-level data can be effectively utilized to ensure that when the upper-level data is extracted, the relevant lower-level information has been obtained and is available for use. This rule can effectively manage hierarchical data. For example, in organizational structures, product classifications, or file systems, the lower-level data is usually an important part of the upper-level data. Extracting the lower-level data first can ensure the integrity and accuracy of the upper-level data.

[0025] This rule is used in scenarios where data depends on underlying data and is frequently updated. If the underlying data changes frequently and the upper-level data is relatively stable, bottom-up extraction can ensure that the latest underlying data is extracted, and then the upper-level data is updated based on this data, thereby maintaining data consistency and real-time performance.

[0026] The lower-level data dependency processing rules can reduce redundant operations. When the lower-level data has been effectively extracted, the upper-level data can directly use this information to improve the extraction efficiency.

[0027] Same-layer data dependency processing: The same-layer data dependency processing rules apply to complex dependencies between data in the same layer. When extracting data in the same layer, if there are dependencies between them and they may also form complex dependencies with other data, special steps must be taken to handle these dependencies to protect the consistency and integrity of the data.

[0028] This rule manages the dependencies between data in the same layer. When extracting related data, if they have dependencies in the same layer and may form complex correlations with other data, they must be isolated to ensure data consistency and integrity to avoid potential data conflicts during the extraction process. Implementing this rule first requires identifying the dependencies between data. Then back up the data, either by creating a temporary table or copying related records to prevent any important information from being lost in the subsequent process. After the backup is complete, cut off the relationship between the data and set the related fields to null to ensure that they are no longer dependent on each other during extraction. Completing the step of cutting off the relationship allows data to be extracted safely without affecting other related data. After the data is successfully extracted, restore the relationship between the data from the backup and replenish it back to its original state. Finally, perform data verification to ensure the integrity and consistency of the extracted data, and confirm that the relationship between the data and other data has been correctly restored.

[0029] This rule can effectively manage the complex dependencies between data in the same layer through the steps of backup, severance and final recovery, improve the security of data extraction, reduce the risk of data conflicts, and ensure that the integrity of data is maintained throughout the extraction process.

[0030] Upper layer data dependency processing: The upper layer data dependency processing rules are applicable to complex dependencies between upper and lower layer data. When data depends on upper layer data, the relationship between upper and lower layer lines needs to be effectively managed; Specify the line to be retrieved and specify the initial node of the line. Specifying the initial node provides a clear starting point for line extraction, ensuring that the integrity of the data hierarchy is maintained in subsequent operations.

[0031] Cut off the relationship between the node and the line. Set the line name field to MULL to avoid conflicts with other node data during the extraction process. Since the extraction is performed from bottom to top, the lower layer data cannot be set to NULL, and the upper layer data can be set to NULL. This ensures that the lower layer data is always available during extraction, avoiding the loss of node information due to line changes.

[0032] After the relationship is cut off, the line name is extracted from the bottom layer to ensure that the latest line information is obtained during the extraction process. Data input must follow the order of line first and then node to ensure that when the node data is extracted, it can be correctly associated with the corresponding line.

[0033] After the extraction is completed, verify the integrity and consistency of the extracted line and node data. Ensuring that the relationship between line information and node information is correct will help with subsequent data analysis and use. This processing method can effectively manage the dependencies between lines and nodes and avoid potential data conflicts and inconsistencies.

[0034] In S4, the improved DFS / BFS algorithm with jump pointer is specifically as follows: In tree-layer databases, the time complexity of queries can be significantly reduced by introducing jump pointers.

[0035] Use of jump pointer: The jump pointer directly starts from a node Jump to a node in the subtree , and across layer; Specifically, when querying a target node, the jump pointer can be used only once in each layer instead of traversing all levels; Jump count calculation: The depth of the tree is , each time you cross Layer, when querying the target node, the total number of jumps required is: ; By using the jump pointer, the time complexity of querying the target node is ; Specifically, although the jump pointer can be used to directly jump over Layers, but in some cases it is still necessary to visit nodes not covered by the jump pointer. Assuming that the jump pointer covers the main levels, the remaining nodes still need to be visited in the normal layer-by-layer manner.

[0036] For paths that cannot be reached directly by jumping, the number of node visits is: ; in, Represents the total number of nodes in the tree; Represents the number of branching factors; as the number of spanned layers increases, the jump pointer can cover more levels, and the number of remaining nodes that need to be visited layer by layer will decrease; After the introduction of jump pointers, the total time complexity is expressed as the sum of the complexity of the jump part and the complexity of the uncovered node part; The complexity of the jumping part: the number of jumps is , the complexity of each jump is O(1), then: ; The complexity of the uncovered node part: For nodes that are not covered by jumps, the number of node visits is , the access complexity is: ; Then, the total time complexity is: .

[0037] Specifically, the traditional ER diagram recursive retrieval method: In traditional complex ER graph structure databases, there are multiple associations and dependencies between data. Recursive queries need to traverse the same nodes and relationships multiple times, resulting in low query efficiency. The key points for analyzing the time complexity of recursive queries are: Query depth: The depth of a recursive query refers to the number of levels of recursive calls. In some cases, the depth can be very large, especially when dealing with large hierarchical data; Number of nodes per level: This refers to the number of nodes that may be touched at each recursive level. For very densely connected data graphs, this number can grow quickly; Index efficiency: If the data in the database has good index support, the efficiency of recursive query will be significantly improved. Recursive query without index will lead to full table scan, which greatly increases the query time.

[0038] To give a specific complexity estimate, the simplified model is: Assume that each node has an average The branching factor and recursion depth are If we start from a node, the number of nodes touched by the first layer should be equal to the number of branches, so the first layer will touch nodes, the second layer will touch nodes, until the Layer nodes. Therefore, the total number of node visits is: ; The number of branching factors , that is, when the number of branches is greater than 1, the sequence is dominated by the last item, so the time complexity is approximately ; From 1 to Any number of .

[0039] The time complexity of recursive queries is highly dependent on the branching factor and the depth of the recursion, so recursive queries are very resource intensive when processing large and complex ER diagrams. The complexity increases rapidly in deeply recursive or data-intensive queries.

[0040] The comparison between the traditional ER graph recursive retrieval method and the improved DFS / BFS algorithm with jump pointer is as follows: the recursive query complexity of the traditional ER graph grows exponentially. The query complexity is , this is exponential growth.

[0041] In real databases, if there are many interrelated entities and relationships in the graph, the depth of the recursive query may be very large, and the average branching factor of each layer may also be very large. Therefore, the time complexity increases exponentially; in addition, due to the existence of loops and multiple paths in the graph structure, the same node will be visited multiple times in the recursive query, resulting in extremely low efficiency.

[0042] In contrast, the time complexity of the improved DFS / BFS algorithm with jump pointer is The query efficiency of the improved DFS / BFS algorithm with the introduction of jump pointers has been significantly improved. This method is suitable for data storage with clear hierarchical relationships. It can significantly improve query efficiency when the data depth is large and the access frequency is relatively concentrated.

[0043] The S5 includes: S501, data storage structure: storage node and level information; For every any node ,use Storage Node Tier , parent node , child node list , the data storage model is expressed as: ; in, Indicates the specific data of the node; S502, index creation and optimization: create indexes for common query paths; If a single level or node type is queried, create an index on that level or node type: ; in, Indicates the type or characteristics of a node; S503, optimizing data access path: adjusting the physical layout of data storage or index strategy according to the data access mode to reduce data access time; Let the data access function be , used to efficiently access any node relevant data; ; Represents actual data access operations, including reading data from storage media.

[0044] Example: Consider a specific complex case: an employee management system for a large organization, which contains different departments and sub-departments, as well as employee information under each department. In this case, the relationship between departments and sub-departments can form a complex tree-like hierarchical structure, where each department may have multiple sub-departments, and each sub-department may have its own sub-departments, and so on. This structure is very common in large enterprises or government agencies, especially those with complex administrative hierarchies. The specific explanation of the hierarchy and dependencies in this case is: See also Figure 2 , the root node is the headquarters: The root node is the top level of the entire organizational structure, usually the headquarters or the main administrative unit. It does not depend on any other department, but all other departments depend on it directly or indirectly. The root node is the main entity that supports the basic structure of the entire organization. In the case of this employee management system, the root node is set to the middle of the company. The headquarters is the top level of the entire organizational structure and is also the direct or indirect support and dependency point of all departments and sub-departments.

[0045] The headquarters is the root node in the database, and all hierarchical relationships extend from the headquarters. Each department can be located step by step through the root node. This unified hierarchical structure facilitates orderly management and extraction of department information, ensuring a clear search path.

[0046] The headquarters hierarchical index contains the sub-node information of all the first-level, second-level, and third-level departments. When you need to query the information of a certain department, the system can start from the headquarters' hierarchical index and quickly locate the target department through the jump pointer without recursion layer by layer. This index structure makes data access more direct and effectively reduces the multiple scans and recursive query processes of the database.

[0047] The second level is the main sub-sectors: In this employee management system example, the second level represents the first-level departments directly under the headquarters. These departments are the main functional departments in the organization, responsible for managing specific business areas, such as the Finance Department, Human Resources Department, Technology Department, and Marketing Department. Each major sub-department has its own independent functional scope, but is generally under the leadership of the headquarters and operates under the headquarters' strategic and policy framework.

[0048] The second layer directly depends on the root node, that is, each first-level department directly depends on the headquarters. This dependency means that the headquarters can directly influence these first-level departments, including decision-making, resource allocation, and policy guidance. At the same time, the second layer is responsible for managing more subdivided subordinate departments. Each first-level department contains several second-level departments to further refine and implement the functions of the department. For example, the technical department may contain sub-departments of the software development department, hardware maintenance department, and network security department.

[0049] In the database, the node structure of the second layer is: Node information: Each first-level department is designed as a node in the database, recording its department ID, name, and related information with the headquarters, such as the parent department ID; Subnode reference: A first-level department node contains references to its second-level departments, so that all second-level departments under the first-level department can be quickly located through the hierarchical index.

[0050] Employee data association: Each first-level department records the associated employee information, usually including basic information of department heads and senior managers.

[0051] The third level and below are more detailed sub-sectors: In the embodiment, the more detailed sub-departments at the third level and below represent specific departments or groups under each major sub-department. These more detailed sub-departments have more specialized functions and responsibilities and are the operational execution layer of an organization, responsible for specific business and project implementation. For example, the Technology Department, a major sub-department at the second level, includes multiple third-level sub-departments such as the Software Development Department, the Hardware Maintenance Department, and the Network Security Department, and the Software Development Department may be further subdivided into smaller teams such as the front-end development group and the back-end development group.

[0052] In the hierarchical design of the database, the third level and below sub-departments are defined as more detailed node levels. The information of these nodes in the database includes: Department ID: Each sub-department has a unique department ID, which is used to distinguish different departments in the database.

[0053] Department Level: records the level of the department, which is the third level or lower in this embodiment.

[0054] Parent Department ID: refers to the parent department of the department. For example, the parent department of the Software Development Department is the Technology Department.

[0055] Sub-department list: If there are smaller sub-departments under the department, references to these sub-departments are included, such as the references to the front-end development group and the back-end development group in the software development department.

[0056] Employee data: records the basic information of all employees in the department, such as name, position, and contact information. Sub-departments are dependent on their parent departments, forming a hierarchical dependency relationship; Directly dependent on the superior department: The third-tier and lower sub-departments directly rely on the management and resources of their superior departments. For example, the front-end development group and back-end development group of the software development department rely on the software development department and accept the task assignment and guidance of the software development department.

[0057] Directly dependent on the headquarters and root nodes: Through the transmission of the first and second level departments, these sub-departments are indirectly dependent on the headquarters. The policies and strategies designated by the headquarters are communicated through multiple levels of departments and will eventually be implemented at these execution levels.

[0058] Each sub-department has a clear management relationship to ensure that tasks and resources are allocated in an orderly manner and passed down to the execution units.

[0059] Comparison of algorithm efficiency of implementation cases: When performing data extraction operations, assume that you need to query the employee information of all third-level and lower sub-departments under the technical department. The specific organizational structure is as follows: the technical department is the second level, that is, the first-level department; the technical department contains multiple second-level departments, that is, the third level, such as the software development department, hardware maintenance department, and network security department. Each second-level sub-department contains multiple third-level sub-departments, such as the front-end development group and the back-end development group, forming more specific teams or groups.

[0060] Traditional recursive query method: Using the traditional recursive query method, the system needs to recursively traverse from the root node to the bottom-level sub-department layer by layer, which will result in many repeated queries, specifically: Query the technical department information: locate the technical department node and query basic information; Recursively query the second-level sub-departments: find the second-level sub-departments of the Technology Department, such as Software Development Department, Hardware Maintenance Department, and Network Security Department, and then enter each second-level department; Recursively query the third-level sub-departments: Enter the software development department, and then recursively query the third-level sub-departments, such as the front-end development group and the back-end development group; Extract employee data level by level: After reaching the lowest level of sub-department, extract all employee information and return to the previous level level by level until all sub-department information has been extracted; Starting from the technical department, query all sub-departments layer by layer until the employee information of the third-level and lower sub-departments is collected. The number of queries increases exponentially with the depth of the hierarchy and the branching factor of each layer. The time complexity of traditional recursive query is: ; If we assume , each department has four sub-departments on average, then the complexity of the recursive query is: ; This means that in traditional recursive queries, the system needs to perform up to 64 query operations to complete the traversal of the technology department and all its sub-departments.

[0061] New method using level indexing and jump pointers: By optimizing the hierarchical index and jump pointer, the number of recursive levels of the query can be reduced and the efficiency can be improved through operations. The specific steps are as follows: Directly locate the technical department: quickly find the technical department node through the hierarchical index of the root node; Use jump pointers to directly access secondary sub-departments: Starting from the Technology Department node, use jump pointers to directly jump to the secondary sub-departments of the Technology Department, such as the Software Development Department, Hardware Maintenance Department, and Network Security Department.

[0062] Parallel query of three-level sub-departments through indexes: The second-level sub-departments of the technical department, such as the software development department, record the indexes of the subordinate third-level sub-departments, such as the front-end development group and the back-end development group. Therefore, the system can directly query all third-level sub-departments in parallel without recursively entering each level.

[0063] Extract all employee data in parallel: Extract employee data of each sub-department in parallel starting from the Technology Department, summarize and return the final results.

[0064] The time complexity of the method is: ; That is, the sum of the complexity of the jumping part and the complexity of the uncovered node part.

[0065] The system requires only one jump operation in each level, so the complexity of the jump part is , that is, the linear complexity of the number of levels; Assumptions is the number of uncovered nodes. For nodes that are not directly covered by jump pointers, they still need to be visited layer by layer. The complexity of this part is ; In this example , and assuming that each layer of jump pointers covers most of the nodes, take . Then the query complexity will be close to: ; The comparison results show that the number of queries of the new algorithm is about 7, which is significantly lower than the 64 queries of the traditional algorithm. The efficiency difference is extremely significant. From a mathematical perspective, the time complexity of the traditional recursive algorithm is exponential growth, and the number of queries and time consumption will increase significantly. The time complexity of the new algorithm is linear growth, and the number of uncovered nodes is reduced by jumping pointers. Therefore, the overall query time increases slowly with the level depth.

[0066] The above-mentioned embodiments only express the implementation methods of the present invention, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the patent of the present invention. It should be pointed out that, for ordinary technicians in this field, several variations and improvements can be made without departing from the concept of the present invention, and these all belong to the protection scope of the present invention. Therefore, the protection scope of the patent of the present invention should be based on the attached claims.

Claims

1. A hierarchical database construction and retrieval method based on a tree structure, characterized in that: The following steps are involved: S1. Design data model: define the dependency relationship between the root node of the tree structure and other nodes; S2. Build a hierarchical index: Starting from the top level of the tree, index the data layer by layer to build a complete hierarchical index structure; S3, data extraction: use hierarchical index tables to efficiently extract required data from the database; S4, extraction and retrieval optimization: Use the improved DFS / BFS algorithm with jump pointer to traverse the tree and perform extraction operations, and analyze the time complexity of the improved DFS / BFS algorithm with jump pointer; S5. Data storage and management: Ensure that the extracted data can be stored efficiently and can be easily accessed and queried later.

2. A tree-structured hierarchical database building and retrieval method according to claim 1, characterized in that: The S1 includes: S101. Determine the root node of the tree structure: The root node modeling: set up is the set of all data entities in the database, where is the number of data entities; set up Represents data entity A collection of other data entities that it depends on; Root Node Defined as: ; S102. Define the dependency relationship between nodes: each node, except the root node, should have one or more dependent nodes; The dependency modeling: set up Represents dependent data entities The collection of child nodes; For any non-root node , there must be at least one , so that ,in, For all non-root nodes An element that makes up a set; For any data entity ,exist ,in, For data entities An element that makes up a set; Make data entity , indicating that each non-root node is depended on by at least one other node.

3. The tree-structured hierarchical database building and retrieval method according to claim 2, characterized in that: The S2 includes: S201, hierarchical index establishment: starting from the top node of the tree structure, indexing data layer by layer downward; Recursive index query: set up Represents any node of a tree structure; set up Represents any node All child nodes of ; set up Represents any node Level of For the root node , set the root node level ; For any node and child nodes , set the child node Level ; S202, constructing a hierarchical index table: Organize the index information into a hierarchical index table for subsequent data extraction; for the index table , let each entry be , Include: Represents the node ID; Represents the node level; Represents the parent node ID; Represents a list of child nodes; S203, index retrieval and hierarchy clarification: Recursive index building process: Starting from the root node, perform indexing operations for each node, query the node's child nodes, assign appropriate levels to each child node, and record the relationship between the node and the corresponding child nodes in the index table.

4. The tree-structured hierarchical database building and retrieval method according to claim 3, characterized in that: The S3 includes: S301. Mathematical expression of data extraction order: Data is extracted from the bottom layer to the top layer, and the extraction order is determined by using the level information in the level index table; Define the maximum value of the level: set up Is the index table The maximum level of all entries in , the formula is: ； Extract in reverse order: For each level From the maximum level To 0, the node set of the corresponding level is defined as: ； Extract data layer by layer to ensure that the dependent nodes of each node are extracted before itself; S302. Mathematical expression of dependency check: Check whether the node dependencies have been extracted: The set of dependencies for each node is defined as: ； Check if all dependencies of a node have been extracted, using indicator functions to represent child nodes Has it been extracted? ； S303, avoid repeated extraction: Mark and check extraction status: Every time any node After extraction, update the status: ; Before extracting any node Before, check: 。 5. The tree-structured hierarchical database building and retrieval method according to claim 4, characterized in that: In S4, the improved DFS / BFS algorithm with jump pointer is specifically as follows: Use of jump pointer: The jump pointer directly from a node Jump to a node in the subtree , and across layer; Jump count calculation: The depth of the tree is , each time you cross Layer, when querying the target node, the total number of jumps required is: ； By using the jump pointer, the time complexity of querying the target node is ; For paths that cannot be reached directly by jumping, the number of node visits is: ； in, Represents the total number of nodes in the tree; Represents the number of branching factors; as the number of spanned layers increases, the jump pointer can cover more levels, and the number of remaining nodes that need to be visited layer by layer will decrease; After the introduction of jump pointers, the total time complexity is expressed as the sum of the complexity of the jump part and the complexity of the uncovered node part; The complexity of the jumping part: the number of jumps is , the complexity of each jump is O(1), then: ； The complexity of the uncovered node part: For nodes that are not covered by jumps, the number of node visits is , the access complexity is: ； Then, the total time complexity is: 。 6. A tree-structured hierarchical database building and retrieval method according to claim 5, characterized in that: The S5 includes: S501, data storage structure: storage node and level information; For every any node ,use Storage Node Tier , parent node , child node list , the data storage model is expressed as: ； in, Indicates the specific data of the node; S502, index creation and optimization: create indexes for common query paths; If a single level or node type is queried, create an index on that level or node type: ； in, Indicates the type or characteristics of a node; S503, optimizing data access path: adjusting the physical layout of data storage or index strategy according to the data access mode to reduce data access time; Let the data access function be , used to efficiently access any node relevant data; ； Represents actual data access operations, including reading data from storage media.

Images