An electronic component supply-demand matching transaction system based on a knowledge graph

Abstract

The application relates to the technical field of knowledge graph data processing, and discloses an electronic component supply-demand matching transaction system based on a knowledge graph, which comprises a component ontology speed labeling module, a constraint speed analysis module and a dynamic decoupling query planning module. The dynamic decoupling query planning module comprises a query cost estimation submodule. The system is used for configuring speed labels for knowledge graph data, analyzing a query into a static constraint subgraph and a dynamic constraint subgraph, and estimating the execution costs of the two subgraphs by using the query cost estimation submodule before execution. Based on the cost comparison result, it is determined and confirmed whether the static constraint subgraph is preferentially executed or the dynamic constraint subgraph is preferentially executed. The application introduces a dynamic inversion mechanism based on cost, solves the query plan mismatching problem caused by the dependence of static priority rules under the condition of extremely skewed data distribution, and enables the system to self-adaptively select an optimal execution path.

Description

Technical Field

[0001] This invention relates to a knowledge graph-based electronic component supply and demand matching trading system, belonging to the field of knowledge graph data processing technology. Background Technology

[0002] Currently, in existing data management and information retrieval practices, using database systems to uniformly store, manage, and query massive amounts of data rich in semantic relationships is a common technical approach. Its core value lies in providing efficient and accurate data access support for upper-layer applications. Especially in the field of electronic components, technical solutions have begun to utilize knowledge graphs to solve complex matching problems, such as finding substitute materials. For example, Chinese invention patent CN115080587B discloses a knowledge graph-based method, device, and medium for electronic component substitution. This solution mainly treats electronic component substitution as a link prediction task in the knowledge graph, achieving matching by constructing substitution relationships. However, this solution and other existing technologies mainly focus on matching static parameters and knowledge reasoning, but do not effectively solve a key problem: in real supply and demand matching transactions, the system must simultaneously handle this type of relatively static data physical specifications and substitution relationships with another type of high-frequency dynamic data, such as real-time inventory, price, and delivery time.

[0003] However, in many complex application scenarios, data streams naturally exhibit heterogeneous speed characteristics, meaning that two types of data with drastically different real-world cycles coexist in the system: one is static data with extremely low change frequency, measured on a yearly or even longer scale, such as physical specifications, compliance standards, or established relationships; the other is dynamic data with extremely high change frequency, measured on a minute or even second scale, such as real-time inventory, prices, or instantaneous status. When planning their execution paths, existing data query engines often implicitly assume data homogeneity in their underlying design, meaning they cannot distinguish between these two types of data at different speeds. This leads to high-frequency dynamic data constantly flushing the cache when processing complex queries that mix high and low frequency constraints, causing the static data cache, which should be stably reused, to frequently fail, resulting in query performance issues. More seriously, this indiscriminate query planning can easily lead to a discrepancy between semantics and timeliness, that is, returning an erroneous result that is compliant with static standards but has already become invalid in dynamic reality.

[0004] Therefore, the technical problem to be solved by this invention is how to construct a query planning mechanism that can perceive and utilize the periodic differences in data authenticity, fundamentally reconstruct the query execution order, so as to avoid query performance problems and ensure absolute consistency between semantics and timeliness. Summary of the Invention

[0005] This invention provides a knowledge graph-based electronic component supply and demand matching trading system. Its main purpose is to solve the problems of query plan mismatch, cache failure, and semantic and timeliness deviation caused by the assumption of data homogeneity in existing query engines when facing heterogeneous speed data streams such as static truths and dynamic facts.

[0006] To achieve the above objectives, this invention provides a knowledge graph-based electronic component supply and demand matching trading system. The system includes a meta-ontology speed annotation module, a constraint speed parsing module, and a dynamic decoupling query planning module. The dynamic decoupling query planning module includes a query cost estimation sub-module.

[0007] The meta-ontology velocity labeling module is used to pre-configure velocity labels for relation types and attribute types in the knowledge graph based on the authenticity and periodicity of the data. The velocity labels include at least the [STATIC] label and the [HIGH_DYNAMIC] label.

[0008] The constraint velocity parsing module is used to receive user query requests and, based on the velocity label, parse the user query request into at least one static constraint subgraph with the [STATIC] label and at least one dynamic constraint subgraph with the [HIGH_DYNAMIC] label.

[0009] The dynamic decoupling query planning module calls the query cost estimation submodule before determining the query execution plan to estimate the first cost of independently executing the static constraint subgraph and the second cost of independently executing the dynamic constraint subgraph. Based on the comparison between the first and second costs, it determines a final query execution order. When the first cost is less than or equal to the second cost, the dynamic decoupling query planning module determines the final query execution order to prioritize the execution of the static constraint subgraph to generate a static candidate set, and then applies the dynamic constraint subgraph only to the static candidate set. When the second cost is lower than the first cost, the dynamic decoupling query planning module determines the final query execution order to reverse to prioritize the execution of the dynamic constraint subgraph to generate a dynamic candidate set, and then applies the static constraint subgraph only to the dynamic candidate set.

[0010] Preferably, the system further includes: a tag speed auditing module and a configuration dynamic correction module. The tag speed auditing module is used to periodically obtain the actual data change log of the attribute type configured with the [STATIC] tag by the meta-ontology speed annotation module in the knowledge graph, and calculate the actual data change frequency. The configuration dynamic correction module is used to automatically adjust the speed tag of the attribute type to a speed level with a faster change cycle when the actual data change frequency exceeds the preset change frequency threshold for the [STATIC] tag.

[0011] Preferably, the system further includes: a query cardinality capture module and a query decay attribution module; the query cardinality capture module is used to obtain the initial cardinality corresponding to the user query request, capture the first cardinality of the candidate set generated by the priority execution constraint subgraph, and obtain the second cardinality of the final matching result during the execution of the final query execution order by the dynamically decoupled query planning module; the query decay attribution module is used to determine the main attribution of query result decay based on the comparison of the initial cardinality, the first cardinality and the second cardinality, and attach a semantic context flag to the final matching result according to the attribution.

[0012] Preferably, the dynamic decoupling query planning module is also used to monitor the cardinality of the static candidate set generated when executing the static constraint subgraph labeled [STATIC]; when the cardinality of the static candidate set is zero or lower than a preset cardinality threshold, static query adaptive relaxation is triggered; static query adaptive relaxation includes: querying the ontology of the knowledge graph to obtain the semantically equivalent entities of keywords that failed to match in the static constraint subgraph; and using the semantically equivalent entities to rewrite and re-execute the static constraint subgraph.

[0013] Preferably, the system also includes a context safety rule base. The constraint speed parsing module is further used to parse context constraints from user query requests. The dynamic decoupling query planning module is further used to obtain context constraints from the constraint speed parsing module during the execution of the final query execution order, after the static constraint subgraph is executed to generate a static candidate set, and before the dynamic constraint subgraph is executed. Based on the context safety rule base, the module performs an independent judgment and filtering on the candidate entities generated based on substitutable relationships in the static candidate set, in order to remove candidate entities that are prohibited from substitution under context constraints from the static candidate set.

[0014] Preferably, the system also includes a query history log database and a speed inference module; the constraint speed parsing module is further used to: activate the speed inference module when encountering an unknown constraint without a configured speed label while parsing a user query request; the speed inference module is used to query the query history log database, and count the static frequency of the unknown constraint appearing together with the known [STATIC]-labeled constraints and the dynamic frequency of the unknown constraint appearing together with the known [HIGH_DYNAMIC]-labeled constraints in historical queries; based on the comparison of the static and dynamic frequency of the unknown constraint, a temporary speed label is inferred for the unknown constraint for use by the dynamic decoupling query planning module.

[0015] Preferably, the query cost estimation submodule is used to obtain the data cardinality and data distribution skewness of the static constraint subgraph and the dynamic constraint subgraph by querying the index statistics and historical execution histogram of the knowledge graph; and based on the data cardinality and data distribution skewness, combined with the preset IO cost model and CPU cost model, calculate the first cost and the second cost respectively.

[0016] Preferably, the tag speed audit module is used during the audit cycle. Within, retrieve the number of times the attribute type's value has changed. Total number of instances of the property type ; Frequency of actual data changes for computed attribute types ,in Configure a dynamic correction module for use when When the frequency of change exceeds the preset threshold for the [STATIC] label, the speed label adjustment is triggered.

[0017] Preferably, the query decay attribution module is used to calculate a first decay rate, which characterizes the degree of decay of the first cardinality relative to the initial cardinality; calculate a second decay rate, which characterizes the degree of decay of the second cardinality relative to the first cardinality; when the first decay rate is greater than the second decay rate, it is determined that the decay of the query result is mainly attributed to the constraint subgraph that is executed first in the final query execution order; when the second decay rate is greater than the first decay rate, it is determined that the decay of the query result is mainly attributed to the constraint subgraph that is executed later in the final query execution order; when it is mainly attributed to the static constraint subgraph, the semantic context flag is determined to be a static specification bottleneck; when it is mainly attributed to the dynamic constraint subgraph, the semantic context flag is determined to be a dynamic supply bottleneck.

[0018] Preferably, the static query adaptive relaxation includes: a dynamic decoupling query planning module, which initiates a semantic expansion query to the ontology of the knowledge graph for keywords that fail to match in the static constraint subgraph; the semantic expansion query is used to find semantically equivalent entities in the ontology that have equivalent class relations and exact matching relations with the keywords that fail to match in the static constraint subgraph; when a semantically equivalent entity is found, the dynamic decoupling query planning module automatically rewrites the static constraint subgraph, expands the query conditions to include the keywords that fail to match in the static constraint subgraph and semantically equivalent entities, and regenerates the static candidate set using the rewritten static constraint subgraph.

[0019] Compared with the prior art, the beneficial effects of the present invention are:

[0020] 1. This invention establishes a query execution order based on the data authenticity cycle through the synergistic effect of the meta-ontology velocity annotation module, constraint velocity parsing module, and dynamic decoupling query planning module. This method utilizes velocity annotation at the ontology layer to guide the query planner to dynamically decouple complex requests into static and dynamic constraints, and to force the priority execution of the static constraint subgraph to generate a stable intermediate candidate set. Dynamic constraints are only applied to this candidate set. This operating mechanism ensures that the execution order of data queries matches the data change cycle, avoiding the erosion of stable static data cache by high-frequency dynamic data. It also avoids invalid matching results that may be returned due to query plan mismatch, which are semantically and temporally inconsistent.

[0021] 2. Based on the above query mechanism, this invention further constructs a feedback loop for data fact verification of configuration tags through the collaboration of the tag speed audit module and the configuration dynamic correction module. This mechanism utilizes the actual data change log in the knowledge graph to periodically audit attributes configured as static or low-speed dynamic, calculate their actual change frequency, and automatically adjust the speed tag of the attribute to a faster speed level when the actual change frequency does not match the expected change frequency. This design transforms the speed tag foundation on which query planning depends from static manual configuration to a dynamically self-healing configuration, avoiding the systemic risk of static priority rules in the main scheme becoming invalid due to initial configuration mismatch or subsequent evolution of data characteristics.

[0022] 3. The dynamic decoupled query planning module of this invention does not rely on a single rigid execution rule, but further combines a query cost estimation submodule with a static query adaptive relaxation mechanism. On the one hand, before execution, the system uses the index statistics of the graph to estimate the execution cost of each constraint subgraph. When the estimated cost of the dynamic constraint is lower than that of the static constraint, the system will actively reverse its basic static priority logic and execute the dynamic constraint first. On the other hand, when the execution of the static constraint returns zero results, the system does not terminate immediately, but actively queries the ontology to obtain semantically equivalent entities, automatically rewrites the static subgraph, and then executes again. This dual judgment mechanism based on cost and semantics transforms query planning from a fixed rule type to a dynamic adaptive type, ensuring that the system can maintain the rationality of the query path and the completeness of the results even under complex conditions such as extremely skewed data distribution or inconsistent semantic expression. Attached Figure Description

[0023] Figure 1 This is a schematic diagram of the query decoupling and dynamic cost determination process of the present invention;

[0024] Figure 2 This is a performance curve showing the estimated cost and actual response time of the present invention as a function of a base.

[0025] Figure 3 This is a sequence diagram showing the interaction between the modules for cost estimation and dynamic execution plan determination in this invention. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be described in detail below. Obviously, the described embodiments are only some embodiments of this invention, not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0027] This invention provides a knowledge graph-based electronic component supply and demand matching trading system. Its system-level design addresses a technical challenge in handling specific scenarios of electronic component supply and demand matching using knowledge graphs: the simultaneous coexistence of data streams with drastically different timelines within the graph database. On one hand, there is static data with extremely low change frequency, represented by specifications, standards, and substitutability; on the other hand, there is dynamic data with extremely high change frequency, represented by inventory, prices, and delivery dates. Existing query engines, lacking the ability to perceive this speed heterogeneity when planning query paths, often lead to query plan mismatches, resulting in cache invalidation, decreased query performance, and potentially returning semantic errors. Invalid results that contradict timeliness; to address this challenge, the present invention provides a collaborative operating system consisting of a meta-ontology speed annotation module, a constraint speed parsing module, and a dynamically decoupled query planning module with a built-in query cost estimation submodule. This system introduces a metadata layer based on data authenticity cycles, guiding the query planner to dynamically estimate and determine the cost of the query plan before execution, adaptively determining the optimal query execution order. This mechanism ensures that the system maintains query performance and semantic consistency of results even in complex situations with extremely skewed data distribution. In a specific engineering implementation, the meta-ontology speed annotation module... This module operates during the ontology layer construction phase of the knowledge graph, providing a metadata configuration interface for defining the data authenticity period. System administrators or those skilled in the art, based on their domain knowledge, can pre-configure a velocity tag for each relation type and attribute type in the knowledge graph schema using this module. The velocity tag includes at least the [STATIC] tag and the [HIGH_DYNAMIC] tag. Taking a typical electronic component knowledge graph as an example, relationships such as hasSpecification and isCompliantWith describe inherent physical attributes or industry standards, and their data authenticity period is in years. The unit is therefore configured as the [STATIC] tag; while the relationships describing instantaneous transaction status, such as hasStock and hasPrice, may have data authenticity periods in seconds or minutes, so they are configured as the [HIGH_DYNAMIC] tag; in addition, the system can also support the [SLOW_DYNAMIC] tag to represent data with a change period of days or weeks, such as suppliedBy or hasRiskRating; all these tags and their corresponding default lifecycles are stored in the metadata layer of the knowledge graph or in a configuration library that can be accessed at high speed by the query engine, providing a logical basis for subsequent query parsing.

[0028] The constraint speed parsing module, as a pre-processing stage of query compilation, has the core task of dynamically decomposing user query requests into logical execution units carrying speed attributes when the system receives such requests. When a query request is submitted to the system, this module performs syntax parsing on the constraint part of the query statement, identifying all relation types and attribute types traversed by the query. This module utilizes the configuration provided by the meta-ontology speed labeling module to perform speed matching on each parsed constraint condition, and logically reorganizes constraints with the same speed label into a constraint subgraph. Taking a user query to find all AEC-Q200 compliant, 10uF capacitors with an inventory greater than 10,000 as an example, the parsing process of this module is as follows: Input: User query request string; Processing: Identify constraint condition 1: ?partisCompliantWithAEC-Q200; Identify constraint condition 2: ?parthasSpecification10uF; Identify constraint condition 3: ?parthasStock?stock and ?stock>10000; Access metadata layer: Query isCompliantWith and hasSpecification with the label [STATIC]; Query hasStock with the label... Label it as [HIGH_DYNAMIC]; Reorganize: Incorporate constraints 1 and 2 into the static constraint subgraph; Incorporate constraint 3 into the dynamic constraint subgraph; Output: Generate at least one static constraint subgraph labeled [STATIC] and at least one dynamic constraint subgraph labeled [HIGH_DYNAMIC], and submit these decoupled subgraphs and their labels together to the subsequent dynamic decoupling query planning module; The dynamic decoupling query planning module is the core execution unit for realizing dynamic determination of query paths in this invention. Its characteristic is that it does not rely on a fixed static priority rule, but introduces a dynamic reversal mechanism based on real-time cost estimation. In traditional query optimization, a common heuristic is to prioritize constraints with high selectivity (i.e., small result sets). However, in heterogeneous high-speed data streams, a highly selective dynamic constraint, for example, with a specific batch number, may have a cardinality of only 3, while a highly selective static constraint, for example, with all capacitors, may have a cardinality of up to 5 million. When these two constraints coexist, the fixed static priority rule will force a high-cost, invalid filtering, leading to a severe drop in query performance. To avoid query plan mismatch under such extremely skewed data distribution conditions, this module calls its built-in query cost estimation submodule before determining any query execution plan.

[0029] The cost estimation submodule utilizes the graph database's own statistical information to quantitatively estimate the cost of each subgraph to be executed. This submodule estimates the first cost of independently executing each statically constrained subgraph. The second cost of independently executing dynamic constraint subgraphs. In a specific implementation, the estimation procedure is as follows: Input: Static constraint subgraph and dynamic constraint subgraph; Processing: This submodule obtains the data cardinality and data distribution skewness of each subgraph by querying the index statistics and historical execution histogram of the knowledge graph; Cost Model: Based on the obtained cardinality and skewness, combined with the preset IO cost model and CPU cost model, the first cost and the second cost are calculated respectively; This cost function can be simplified to ,in, and These represent the preset IO cost weights and CPU cost weights, respectively. and These represent the estimated number of I / O operations and the estimated base, respectively; Output: Return and Two quantified values; the dynamically decoupled query planning module, based on the above estimation results, performs a query plan determination; when the first cost is less than or equal to the second cost, i.e. When the static constraint has higher selectivity or lower cost, the system determines the final query execution order as follows: first, execute the static constraint subgraph to generate a static candidate set, then apply the dynamic constraint subgraph only to this static candidate set; when the second cost is lower than the first cost, i.e. This indicates a situation of extreme data skew. In this case, the selectivity of dynamic constraints is much higher than that of static constraints. The system determines that the final query execution order is reversed: the dynamic constraint subgraph is executed first to generate a dynamic candidate set, and then the static constraint subgraph is applied only to the dynamic candidate set. In one example, compliance verification is performed only on a few (e.g., 3) discounted parts. This cost-based dynamic reversal mechanism enables the system to adaptively select the optimal execution path, ensuring query performance.

[0030] To further ensure the long-term accuracy of the velocity tags relied upon by the meta-ontology velocity labeling module, the system of this invention may also include a tag velocity auditing module and a configuration dynamic correction module. Given that manually configured tags may have initial mismatches or configuration drift due to business evolution, this auditing mechanism provides a data-driven self-healing closed loop. The tag velocity auditing module is used to periodically obtain the actual data change logs in the knowledge graph for attribute types configured with the [STATIC] tag and calculate the actual data change frequency. In a specific calibration procedure, this module operates within a preset auditing cycle. Inside, with Taking 7 days as an example, retrieve the total number of times the value of this attribute type has changed. Total number of instances of this property type and through To calculate the frequency of its standardized actual data changes ;in, This refers to the actual frequency of data changes. For the total number of value changes, This represents the total number of instances. The audit cycle is specified; configuring a dynamic correction module is used to... Compare with a preset change frequency threshold for the [STATIC] label; when When the frequency exceeds the change frequency threshold, this module is activated and automatically adjusts the speed tag of the attribute type to a speed level with a faster change cycle, thereby ensuring that the metadata on which query planning relies is always consistent with the data facts. To enhance the value of query results, especially to provide decision-making basis for queries with zero or few results, the system of this invention may also include a query cardinality capture module and a query decay attribution module. During the process of the dynamically decoupled query planning module executing its layer-by-layer filtering, the query cardinality capture module is attached to this process and captures the cardinality of key nodes, including at least: the initial cardinality corresponding to the user query request. The first cardinality of the candidate set generated by the constraint subgraph that is executed first. And the second cardinality for obtaining the final matching result. If the attribution module is queried, then before returning the final result, the attribution module will perform an analysis. , and Attribution analysis is performed on the cardinality changes between them; in a specific implementation, this module calculates the first decay rate (used to characterize...). Compared to The degree of attenuation) and the second attenuation rate (used to characterize) Compared to The degree of decay is determined by comparing the magnitudes of the two decay rates. When the decay is mainly attributed to the static constraint subgraph, the semantic context flag is identified as a static specification bottleneck. When the decay is mainly attributed to the dynamic constraint subgraph, the semantic context flag is identified as a dynamic supply bottleneck. This flag will be attached to the final matching result, so that even if the user gets 0 results, they can know the main link that blocked the query, thus providing a basis for subsequent decisions.

[0031] To enhance the semantic robustness of queries, the dynamically decoupled query planning module can also integrate a static query adaptive relaxation mechanism. This mechanism addresses the scenario where exact matching of static semantics fails, i.e., the static criteria of the user query, taking AEC-Q200 as an example, have no direct match in the knowledge graph, but its equivalent entity, taking AEC-Q201 as an example, exists. In this case, when the dynamically decoupled query planning module executes the static constraint subgraph labeled [STATIC], if it detects that the cardinality of the generated static candidate set is zero or lower than a preset cardinality threshold, it triggers static query adaptive relaxation. This relaxation mechanism includes: the system automatically initiating a semantic expansion query to the ontology of the knowledge graph to find the matching entity in the ontology. Keywords that fail to match have semantically equivalent entities with an equivalent class (owl: equivalentClass) or an exact match (skos: exactMatch). When such a semantically equivalent entity is found, the module automatically rewrites the static constraint subgraph, expanding the query conditions from matching AEC-Q200 to matching AEC-Q200 or matching AEC-Q201, and re-executes the query using the rewritten subgraph, thus avoiding missing query results due to inconsistent semantic expression. To address the risk of applicability of static knowledge in specific engineering contexts, the system may also include an independent context safety rule base. This mechanism targets scenarios where certain static truths, such as Part_Ai, are... Taking sAlternativeForPart_B as an example, it has a strong context dependency in engineering. Therefore, the constraint speed parsing module is also used to parse context constraints from user query requests, taking Context=Automotive as an example. The dynamic decoupling query planning module is further used to: in its execution flow, after the static constraint subgraph is executed to generate a static candidate set, and before the dynamic constraint subgraph is executed, initiate an independent decision step; this step, based on the context safety rule base, performs a context-constraint-based filtering on the candidate entities generated based on substitutable relationships in the static candidate set, removing any candidate entities prohibited from substitution in the current context from the static candidate set. The removal ensures the applicability of the final result in engineering applications. Finally, to address the issue of missing speed tags caused by the evolution of knowledge graph schemas, the system of this invention may also include a query history log database and a speed inference module. When the constraint speed parsing module encounters an unknown constraint without a configured speed tag while parsing a query, taking carbonRating>5 as an example, the speed inference module is activated. The speed inference module queries the query history log database and statistically analyzes the static frequency of the unknown constraint co-occurring with constraints with known [STATIC] tags and the dynamic frequency of the unknown constraint co-occurring with constraints with known [HIGH_DYNAMIC] tags in historical queries.By comparing the magnitudes of these two frequencies, the module infers a temporary velocity label for the unknown constraints, which is then used by the dynamically decoupled query planning module. This design allows the query optimization mechanism of this invention to maintain its operation even when facing an evolving knowledge graph.

[0032] Example 1: This example is a specific operational instance of the technical solution described above under a specific knowledge graph query scenario. This scenario involves an urgent query request initiated by a purchaser of high-reliability components in its supply and demand matching transaction system. The query request is to find all capacitors conforming to the AEC-Q200 automotive standard with the [STATIC] tag, and these capacitors must also be in the daily special offer batch list of supplier A with the [HIGH_DYNAMIC] tag. In this specific knowledge graph instance, the data distribution of the knowledge graph is extremely skewed, that is, the nodes conforming to the [STATIC] constraint are based on... The estimated number of nodes is 50 million, while the estimated cardinality of nodes conforming to the [HIGH_DYNAMIC] constraint is only 10. In conventional query methods, the fixed static priority rule will cause the system to process 50 million nodes, leading to a query performance bottleneck. When the system of this invention receives the user's query request, the constraint speed parsing module parses it into a static constraint subgraph and a dynamic constraint subgraph as described above. Before determining the execution plan, the dynamic decoupling query planning module calls the query cost estimation submodule. This submodule estimates the first cost of independently executing the static constraint subgraph based on the index statistics of the graph. The cost, based on an estimated base of 50 million, was deemed high, along with the second cost of independently executing the dynamic constraint subgraph. The cost, based on an estimated baseline of 10, was deemed low; the dynamic decoupling query planning module, according to... The comparison results triggered the query execution order reversal logic. Instead of executing the conventional static priority path, the system determined a dynamic priority final query execution order. The system's execution flow was restructured as follows: First, the dynamic constraint subgraph is executed first, obtaining a dynamic candidate set containing only 10 nodes from the knowledge graph. Second, the static constraint subgraph, i.e., AEC-Q200 compliance verification, is applied only to this dynamic candidate set of 10 nodes for final filtering. Through this cost-estimated dynamic reversal, the query planning module and the query cost estimation submodule are dynamically decoupled, transforming a high-cost query operation that might lead to a full graph scan into a low-cost operation that only verifies 10 nodes, thus returning the final matching result within milliseconds. This operational example demonstrates that the system architecture avoids query plan mismatch problems caused by extremely skewed data distribution, transforming query planning from relying on fixed data speed label rules to dynamically determining data costs, thus solving the query performance problem of heterogeneous speed data streams under extreme conditions.

[0033] Example 2: This example objectively verifies the performance of the dynamically decoupled query planning module and its built-in query cost estimation submodule in the knowledge graph query under extremely skewed data distribution conditions. To this end, a graph query test platform was constructed based on an electronic component knowledge graph dataset containing 100 million nodes and 500 million edges. This dataset has been pre-annotated using the meta-ontology speed annotation module described earlier. Approximately 50 million nodes conform to the [STATIC] label, and [HIGH_DYNAMIC] is also present. The total number of inventory-type relationships tagged is approximately 100 million; the hardware specifications of the test environment consist of a server with a processor having 32 computing cores and 256GB of memory; two query systems were deployed on this platform for comparison: the first system was the control sample group, which used a conventional query engine whose query planner was fixed with a static priority heuristic rule, i.e., always prioritizing the execution of the constraint subgraph of the [STATIC] tag; the second system was the sample group of this invention, which adopted the technical solution of this invention, i.e., query requests were determined and scheduled by a dynamically decoupled query planning module and its query cost estimation submodule; The experiment employed a hybrid workload containing two types of query requests, with each type of request being executed 1000 times, and its average query response time recorded. To simulate the real update pressure of the [HIGH_DYNAMIC] data flow, 100 concurrent write operations per second were applied in the background during the experiment to continuously impact the database cache. The definitions and data distribution characteristics of the two types of query requests are as follows: Query Type 1 (Low-skewed query): A combination of a [STATIC] constraint and a [HIGH_DYNAMIC] constraint, whose static constraint subgraph is estimated by the query cost prediction submodule. The estimated base number for the static constraint subgraph is 1200 nodes, and the estimated base number for the dynamic constraint subgraph is 40 million nodes. Under this condition, the selectivity of static constraints is higher than that of dynamic constraints. Query type 2 (high skew query): A combination of a [STATIC] constraint and a [HIGH_DYNAMIC] constraint. According to the query cost estimation submodule, the estimated base number for the static constraint subgraph is 50 million nodes, and the estimated base number for the dynamic constraint subgraph is 10 nodes. Under this condition, the selectivity of dynamic constraints is much higher than that of static constraints. The test data of the two systems under the same workload are shown in Table 1.

[0034] Table 1: Performance Comparison Test Data of the Query System

[0035]

[0036] Referring to Table 1, for Type 1 (low-skew) queries, the query cost estimation submodule estimates... Therefore, the dynamic decoupling query planning module of the present invention's sample group determines the static priority execution order, which is consistent with the comparison sample group. The average response time of the present invention's sample group (155.1ms) is slightly increased compared to the comparison sample group (152.4ms), which is attributed to the fixed overhead caused by the execution cost estimation. Compared with the total response time of query type 1, this overhead accounts for a relatively small proportion. For type 2 (high skew) queries, the data distribution is reversed. Due to its fixed static priority rule, the comparison sample group forces the filtering of 50 million [STATIC] nodes, resulting in an average response time of 18542.7ms. In contrast, the query cost estimation submodule of the present invention's sample group estimates the following at this time: Based on this comparison result, the dynamic decoupling query planning module determines and reverses the execution order to dynamic priority, that is, it prioritizes the execution of the [HIGH_DYNAMIC] constraint subgraph involving only 10 nodes, and then applies the static constraints to the dynamic candidate set of these 10 nodes. This path change keeps the average response time at 25.3ms, outperforming the comparison sample. Experimental data shows that the cost-based dynamic reversal mechanism of this invention solves the query plan mismatch problem caused by conventional query planners relying on static priority rules under extremely skewed data distribution conditions, enabling the system to adaptively select the optimal execution path and ensuring query performance.

[0037] Example 3: This example is a comparative example, designed to demonstrate the necessity of the query cost estimation submodule and cost comparison-based judgment features of the present invention compared to other fixed heuristic rules. This comparative example uses the same experimental platform, knowledge graph dataset, background concurrent write operation pressure, and two types of query requests (Type 1 low skewness, Type 2 high skewness) as Example 2. This comparative example uses a single comparative sample group whose query engine removes the query cost estimation submodule and cost comparison-based judgment logic of the present invention, replacing them with a publicly known... The fixed heuristic rule, which is the opposite of the fixed static priority rule in the comparative sample group in Example 2, is the fixed dynamic priority rule. This rule requires the query planner to always prioritize the execution of the constraint subgraph labeled [HIGH_DYNAMIC] under any operating condition. The two types of query requests in Example 2 were each executed 1000 times by the comparative sample group (fixed dynamic priority), and their average query response time was recorded. The results were then combined and compared with the experimental data of the comparative sample group (fixed static priority) in Example 2 and the sample group of the present invention (dynamic cost determination), as shown in Table 2.

[0038] Table 2: Performance Comparison of Query System under Different Planning Strategies

[0039]

[0040] Referring to the experimental data in Table 2: For Type 1 (low-skew) queries, the characteristic is that the selectivity of static constraints is much higher than that of dynamic constraints. The comparative sample group with fixed static priority showed a low response time of 152.4ms; while the comparative sample group (fixed dynamic priority), due to its fixed rules, prioritized the execution of dynamic constraint subgraphs with a cardinality of up to 40 million, resulting in a dramatic increase in average response time to 21345.8ms, causing query performance failure; the sample group of this invention, through cost estimation, determined... The system adaptively selected a static priority path, achieving a low response time of 155.1ms. The slight difference between this and the control group stemmed from the cost estimation itself. For Type 2 (highly skewed) queries, characterized by significantly higher selectivity of dynamic constraints compared to static constraints, the control group, with its fixed dynamic priority, exhibited a low response time of 25.1ms because its rules perfectly matched this condition. In contrast, the control group, with its fixed static priority, prioritized the execution of static constraint subgraphs with a base of 50 million due to its fixed rules, resulting in a dramatic increase in average response time to 18542.7ms, rendering the query performance ineffective. This invention's sample, through cost estimation, determined... The system triggered a dynamic reversal, adaptively selecting the dynamic priority path and achieving a low response time of 25.3ms. The slight difference between this and the comparative sample group also stemmed from cost estimation overhead. The experimental results show that any query engine based on fixed heuristic rules, whether fixed static priority or fixed dynamic priority, cannot effectively handle two data distribution scenarios simultaneously. When the data distribution skew direction does not match its fixed rules, it will lead to a severe drop in query performance. The dynamic decoupled query planning module and its query cost estimation submodule used in the sample group of this invention can adaptively select the optimal execution path through cost determination and maintain a low response time in both scenarios covered by the experiment.

[0041] Example 4: This example combines Figures 1 to 3 This document describes a knowledge graph-based electronic component supply and demand matching trading system. Figure 1 As shown, it begins with a user query request, which is received by the constraint speed parsing module. Based on the speed tags pre-configured by the meta-ontology speed annotation module, the constraint speed parsing module parses the query into static and dynamic subgraphs. The parsing results are sent to the dynamic decoupled query planning module, which activates the query cost estimation submodule to estimate the static first cost and the dynamic second cost. The estimation process relies on index statistics, historical execution histograms, and ontology data obtained from the knowledge graph. The estimation results are then fed into the cost comparison and judgment logic. When the first cost is less than or equal to the second cost, the system prioritizes static execution. When the second cost is less than the first cost, the system reverses this to prioritize dynamic execution. Regardless of the path executed, the results are sent to the query decay attribution module for analysis and the addition of semantic context markers. Finally, the matching results with attribution markers are output.

[0042] like Figure 2 As shown, the left vertical axis represents the estimated cost, and the right vertical axis represents the actual response time in milliseconds. The figure plots two data curves for estimated cost and actual response time, showing the trend of the horizontal axis changing with the base value, and clearly revealing the high positive correlation between the two: when the base value is low, from 10 to 100,000, both curves remain at extremely low levels close to zero, while when the base value increases to a high range, starting from 1,000,000, both the estimated cost and actual response time show a sharp, non-linear upward trend, and reach a peak at the base value of 50,000,000.

[0043] like Figure 3 As shown in the sequence diagram, this sequence diagram illustrates the collaboration of four core components: the dynamically decoupled query planning module, the query cost estimation submodule, the knowledge graph, and the query executor. The interaction begins with the dynamically decoupled query planning module initiating a cost estimation to the query cost estimation submodule and passing the static constraint subgraph and the dynamic constraint subgraph. The query cost estimation submodule then executes the query index statistics on the knowledge graph and obtains the cardinality and distribution skewness of the returned data. Its internal processing includes obtaining the static cardinality and dynamic cardinality, then calculating the first cost of the static constraints and applying the IO cost model and the CPU cost model, and finally calculating the second cost of the dynamic constraints and applying the IO cost. The model and CPU cost model ultimately return the first cost and the second cost to the dynamically decoupled query planning module. Based on the comparison result of first cost ≤ second cost, the dynamically decoupled query planning module determines the execution order: static priority, that is, first execute static constraints to generate a candidate set and then apply dynamic constraints, and issue a static priority execution plan to the query executor; or based on the comparison result of second cost < first cost, it determines the reverse execution order: dynamic priority, that is, first execute dynamic constraints to generate a candidate set and then apply static constraints, and issue a dynamic priority execution plan to the query executor. After executing the query plan, the query executor finally returns the query result.

[0044] Example 5: This example provides engineering procedures for calibrating the key thresholds required by the internal logic modules of the system of the present invention in a specific knowledge graph deployment environment. These procedures are used to ensure the reproducible operation of the tag speed audit module, the static query adaptive relaxation mechanism, and the query decay attribution module. In a system initialization deployment scenario, the challenge is to set a non-empirical, data-based initial value for three core parameters: change frequency threshold, preset base threshold, and decay rate calculation logic. This is to determine the IO cost weight on which the query cost estimation submodule relies. CPU cost weighting The system provides a calibration procedure that selects a record from the historical log database containing... A benchmark test set for each query request, and for each query in that test set. ( This allows you to obtain the estimated number of I / O operations based on the index statistics of the knowledge graph. and the estimated base Meanwhile, the query was executed in an isolated test environment. To obtain its actual query response time Finally, the system utilizes the acquired data Group 3 data Using a standard multiple linear regression algorithm, a set of... and The values ​​in this set make the cost estimation function... Compared to actual query response time The least squares error of the fitting error between them is minimized. The first procedure is used to calibrate the preset change frequency threshold of the [STATIC] label on which the configuration dynamic correction module depends. This procedure selects two reference attributes in the knowledge graph: one is an attribute explicitly labeled as [HIGH_DYNAMIC] by the meta-ontology velocity labeling module, taking hasStock as an example, and the other is an attribute explicitly labeled as [STATIC], taking isCompliantWith as an example. The system in an audit cycle The data change sampling for these two attributes is set to occur within 24 hours; the sampling statistics show that the hasStock attribute... The actual data change frequency is based on the formula. Calculated as The isCompliantWith property for To maintain sufficient margin of error to handle rare static data corrections while strictly distinguishing between dynamic and static data, the [STATIC] label has a preset change frequency threshold. It was identified as This means that changes occur approximately every 115 days; when the tag speed audit module calculates the value of any [STATIC] tag attribute... Larger than this When the dynamic correction module is configured, it is triggered, which corresponds to the audit cycle required by the tag speed audit module. The setup procedure includes: identifying all attribute types configured with the [SLOW_DYNAMIC] label from the meta-ontology velocity annotation module, querying the knowledge graph's data change log to obtain the actual change timestamps of these attribute types over a longer historical period of 90 days, and then calculating the interval between these timestamps to determine a statistical value that can represent a typical slow change cycle, such as the 95th percentile change interval. Ultimately, the audit cycle will be... Set as this statistical value times, Take integers from 1 to 3, such that... The calculation can reliably reflect the actual frequency of changes in slow data, while the period is much smaller than the annual-scale change period implied by the [STATIC] label.

[0045] The second procedure is used to calibrate the preset cardinality threshold on which the static query adaptive relaxation mechanism relies. This procedure aims to balance two engineering goals: avoiding false negatives due to semantic inconsistencies and preventing invalid expansion of valid queries. The system analyzes the query history log database of the knowledge graph using a sample containing 100,000 query records as an example, statistically analyzing the cardinality distribution of the result set returned by the [STATIC] constraint subgraph. The statistics show that queries with a cardinality of 0 account for 15.2%, queries with a cardinality of 1 account for 3.1%, and queries with a cardinality between 2 and 5 account for 4.5%. In electronic component matching scenarios, returning one result is generally considered a valid match, while returning zero results is a clear signal of query failure. To maximize the interception of false negative queries and avoid unnecessary semantic expansion of queries with one result (which would increase query latency), the preset cardinality threshold is set to 0; that is, static query adaptive relaxation is triggered if and only if the cardinality of the static candidate set is 0. The third procedure is used to make the internal algorithm path of the query decay attribution module transparent; when the query cardinality capture module obtains the initial cardinality during query execution... First cardinal number Generated by the priority subgraph and the second cardinality After the final matching result is obtained, the query attenuation attribution module starts the calculation; its algorithm steps are as follows: Input: Processing: Calculate the first attenuation rate ,in Characterize the degree of decay of the first base relative to the initial base; calculate the second decay rate. ,in This characterizes the degree of decay of the second cardinal number relative to the first cardinal number; it should be noted that when or When the value is 0, to avoid division by zero errors, the decay rate can be directly set to 0 or 1, depending on the business logic definition; Perform comparison: when When the query result decay is determined, it is mainly attributed to the constraint subgraph that is executed first; when When the determination is made, the main reason is attributed to the constraint subgraph that is executed later; the output is: based on the attribution result and the type of the subgraph executed first (static or dynamic), a semantic context flag of static specification bottleneck or dynamic supply bottleneck is attached to the final matching result; through the above procedure, the key thresholds of the system are calibrated in a data-driven manner, and the core attribution algorithm is defined in a reproducible formula, ensuring the consistency and maintainability of the system in engineering deployment.

[0046] Example 6: This example provides supplementary disclosure of the specific engineering implementation details of several core data processing modules in the preceding technical solution, aiming to make their internal algorithm paths and data structures transparent to ensure reproducibility for those skilled in the art. Regarding the internal algorithm path of the query cost estimation submodule, the procedure for calculating the first cost and the second cost is as follows: This submodule physically relies on the ability to access the index statistics or cardinality histogram maintained internally by the graph database. When it receives the static constraint subgraph transmitted by the constraint speed parsing module... and dynamic constraint subgraph Then, it performs a two-stage cost calculation: Input: Static constraint subgraph and dynamic constraint subgraph ; processing (with Calculate the first cost as an example Cardinality estimation: This submodule initiates an internal query to the database's statistics manager to obtain the execution... The estimated cardinality of the nodes and relation types involved Cost modeling: based on the estimated baseline The total cost is calculated using a pre-defined I / O cost model and a CPU cost model; in a specific implementation, this model can be simplified to... ,in and Preset IO cost weights and CPU cost weights for the system (e.g.) ), For estimating the average IO block factor (e.g.) (representing the average I / O consumed per data item) For estimating the average CPU calculation factor (e.g.) (representing the average CPU cycles consumed per data item); Output: This submodule calculates in the same way... And finally return to the dynamic decoupled query planning module. and Two quantized values.

[0047] Secondly, regarding the knowledge graph ontology and its semantic extension query upon which the static query adaptive relaxation mechanism relies, the implementation details are as follows: This ontology is stored in the knowledge graph as a specific set of triples, used to define semantic equivalence relations at the schema level. An example of its data structure is shown below:<kg:AEC-Q200><owl:equivalentClass><kg:AEC-Q201> ;<kg:RoHS-EU><skos:exactMatch><kg:RoHS-China> When the dynamic decoupling query planning module executes the static constraint subgraph (based on keywords) (Taking AEC-Q200 as an example) After detecting a cardinality of 0 according to the threshold specified in Example 4, a semantic expansion query for the ontology is immediately and automatically triggered. In a SPARQL implementation, the algorithmic steps of this query are as follows: Input: Keywords that failed to match. Process: Execute a SPARQL query on the graph database. The query statement is: SELECT ?equiv WHERE {<kg:AEC-Q200><owl:equivalentClass> |<skos:exactMatch> ?equiv}; Output: Retrieves a list of semantically equivalent entities returned by the query (e.g., ... =[AEC-Q201]); Rewrite: Dynamic Decoupling Query Planning Module Based on The original static constraint subgraph is automatically rewritten, its query conditions are expanded from (MATCHAEC-Q200) to (MATCHAEC-Q200ORMATCHAEC-Q201), and then re-executed. Furthermore, regarding the data structure and independent decision logic of the context security rule base, the implementation details are as follows: This rule base is constructed as a key-value storage structure independent of the graph database and accessible to the system at high speed. Taking a hash table as an example, its data structure is used to store prohibition rules defined by domain engineers: Key: Automotive: isAlternativeFor: Part-XYZ-001->Value: VETO; Key: Medical: isAlternativeFor: Part-ABC-002->Value: VETO; After the dynamic decoupling query planning module generates the static candidate set, its algorithmic steps for independent decision are: Input: Static candidate set and context constraints obtained from the constraint velocity parsing module. (like =Automotive); Processing: Traversal Each candidate entity in ;examine If the entity was generated based on the isAlternativeFor ​​relation, then retrieve the original entity that was substituted. (like =Part-XYZ-001); Construct query key Perform a key query in the context security rule base: ;like Returning to VETO will return the entity. from Remove from the middle; Output: Return the purified product. This is for subsequent execution of the [HIGH_DYNAMIC] constraint subgraph.

[0048] Finally, the implementation details of the algorithm path for calculating the associated frequency in the speed inference module are as follows: The query history log library on which this module depends is constructed as a structured log database, and its core table QueryLogs contains at least the following fields: QueryID (query ID), Timestamp, and ConstraintSet, a text or array field containing all constraints of the query; when the constraint speed parsing module encounters an unknown constraint... (like When carbonRating is equal to 0, the velocity inference module is activated and executes the following algorithm: Input: Unknown constraints Processing: Define a known set of tags: =[isCompliantWith,hasSpecification,...]; =[hasStock, hasPrice, ...]; Execute static adjoint frequency query: Count_{Static}=SELECTCOUNT(QueryID)FROMQueryLogsWHEREEConstraintSetCONTAINSXAND(ConstraintSetCONTAINSANYOFTag_{Static}); Execute dynamic adjoint frequency query: Count_{Dynamic}=SELECTCOUNT(QueryID)FROMQueryLogsWHEREEConstraintSetCONTAINSXAND(ConstraintSetCONTAINSANYOFTag_{Dynamic}); Calculate adjoint rate: When the denominator is 0, return the default value, such as 0.5; Output: the calculated adjoint rate. Returning the values ​​to the constraint speed parsing module and the calibrated inference threshold. Compare to determine Temporary speed label.

[0049] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the present invention can be implemented in other specific forms without departing from the spirit or essential characteristics of the present invention.

[0050] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention.

Claims

1. A knowledge graph-based electronic component supply and demand matching trading system, characterized in that, The system includes a meta-ontology velocity annotation module, a constraint velocity parsing module, and a dynamic decoupling query planning module. The dynamic decoupling query planning module includes a query cost estimation sub-module. The meta-ontology velocity labeling module is used to pre-configure velocity labels for relation types and attribute types in the knowledge graph based on the authenticity and periodicity of the data. The velocity labels include at least the [STATIC] label and the [HIGH_DYNAMIC] label. The constraint velocity parsing module is used to receive user query requests and, based on the velocity label, parse the user query request into at least one static constraint subgraph with the [STATIC] label and at least one dynamic constraint subgraph with the [HIGH_DYNAMIC] label. The dynamic decoupling query planning module calls the query cost estimation submodule before determining the query execution plan to estimate the first cost of independently executing the static constraint subgraph and the second cost of independently executing the dynamic constraint subgraph. Based on the comparison between the first and second costs, it determines a final query execution order. When the first cost is less than or equal to the second cost, the dynamic decoupling query planning module determines the final query execution order to prioritize the execution of the static constraint subgraph to generate a static candidate set, and then applies the dynamic constraint subgraph only to the static candidate set. When the second cost is lower than the first cost, the dynamic decoupling query planning module determines that the final query execution order is reversed to prioritize the execution of the dynamic constraint subgraph to generate a dynamic candidate set, and then the static constraint subgraph is applied only to the dynamic candidate set.

2. The knowledge graph-based electronic component supply and demand matching trading system according to claim 1, characterized in that, The system also includes: a tag speed auditing module and a configuration dynamic correction module. The tag speed auditing module is used to periodically obtain the actual data change logs in the knowledge graph for attribute types that have been configured with the [STATIC] tag by the meta-ontology speed annotation module, and calculate the actual data change frequency. The configuration dynamic correction module is used to automatically adjust the speed tag of the attribute type to a speed level with a faster change cycle when the actual data change frequency exceeds the preset change frequency threshold for the [STATIC] tag.

3. The knowledge graph-based electronic component supply and demand matching trading system according to claim 1, characterized in that, The system also includes: a query cardinality capture module and a query decay attribution module; the query cardinality capture module is used to obtain the initial cardinality corresponding to the user query request, capture the first cardinality of the candidate set generated by the priority execution constraint subgraph, and obtain the second cardinality of the final matching result during the execution of the final query execution order by the dynamically decoupled query planning module; the query decay attribution module is used to determine the main attribution of query result decay based on the comparison of the initial cardinality, the first cardinality and the second cardinality, and attach a semantic context flag to the final matching result according to the attribution.

4. The knowledge graph-based electronic component supply and demand matching trading system according to claim 1, characterized in that, The dynamic decoupling query planning module is also used to monitor the cardinality of the static candidate set generated when executing the static constraint subgraph labeled [STATIC]; when the cardinality of the static candidate set is zero or lower than the preset cardinality threshold, it triggers static query adaptive relaxation. The static query adaptive relaxation includes: querying the ontology of the knowledge graph to obtain semantically equivalent entities of keywords that fail to match in the static constraint subgraph; and using the semantically equivalent entities to rewrite and re-execute the static constraint subgraph.

5. The knowledge graph-based electronic component supply and demand matching trading system according to claim 1, characterized in that, The system also includes a context safety rule base, and the constraint speed parsing module is also used to parse context constraints from user query requests; the dynamic decoupling query planning module is also used to obtain context constraints from the constraint speed parsing module in the final query execution order, after the static constraint subgraph is executed to generate the static candidate set and before the dynamic constraint subgraph is executed; Based on the context security rule base, the candidate entities generated from the static candidate set based on substitutability are subjected to independent judgment and filtering based on context constraints, so as to remove candidate entities that are prohibited from substitution under context constraints from the static candidate set.

6. The knowledge graph-based electronic component supply and demand matching trading system according to claim 1, characterized in that, The system also includes a query history log database and a speed inference module. The constraint speed parsing module is also used to: activate the speed inference module when encountering an unknown constraint without a configured speed label while parsing a user query request; the speed inference module is used to query the query history log database to count the static frequency of the unknown constraint appearing together with the known [STATIC]-labeled constraints and the dynamic frequency of the unknown constraint appearing together with the known [HIGH_DYNAMIC]-labeled constraints in historical queries; based on the comparison of the static and dynamic frequency of the unknown constraint, a temporary speed label is inferred for the unknown constraint for use by the dynamic decoupling query planning module.

7. The knowledge graph-based electronic component supply and demand matching trading system according to claim 1, characterized in that, The query cost estimation submodule is used to obtain the data cardinality and data distribution skewness of the static constraint subgraph and the dynamic constraint subgraph by querying the index statistics and historical execution histogram of the knowledge graph; and based on the data cardinality and data distribution skewness, combined with the preset IO cost model and CPU cost model, calculate the first cost and the second cost respectively.

8. The knowledge graph-based electronic component supply and demand matching trading system according to claim 2, characterized in that, The tag speed audit module is used to audit the speed during the audit period. Inside, get the number of times the attribute type's value has changed. Total number of instances of the property type ; Actual data change frequency of computed attribute types ,in Configure a dynamic correction module for use when When the frequency of change exceeds the preset threshold for the [STATIC] label, the speed label adjustment is triggered.

9. A knowledge graph-based electronic component supply and demand matching trading system according to claim 3, characterized in that, The query decay attribution module is used to calculate the first decay rate, which characterizes the degree of decay of the first base relative to the initial base. A second decay rate is calculated, which characterizes the degree of decay of the second cardinality relative to the first cardinality. When the first decay rate is greater than the second decay rate, it is determined that the decay of the query result is mainly due to the constraint subgraph that is executed first in the final query execution order. When the second decay rate is greater than the first decay rate, it is determined that the decay of the query result is mainly due to the constraint subgraph that is executed last in the final query execution order. When it is mainly due to the static constraint subgraph, the semantic context flag is determined to be a static specification bottleneck. When it is mainly due to the dynamic constraint subgraph, the semantic context flag is determined to be a dynamic supply bottleneck.

10. A knowledge graph-based electronic component supply and demand matching trading system according to claim 4, characterized in that, The static query adaptive relaxation specifically includes: a dynamic decoupling query planning module, which initiates a semantic expansion query to the ontology of the knowledge graph for keywords that fail to match in the static constraint subgraph; the semantic expansion query is used to find semantically equivalent entities in the ontology that have equivalent class relations and exact matching relations with the keywords that fail to match in the static constraint subgraph; when semantically equivalent entities are found, the dynamic decoupling query planning module automatically rewrites the static constraint subgraph, expands the query conditions to include the keywords that fail to match in the static constraint subgraph and semantically equivalent entities, and regenerates the static candidate set using the rewritten static constraint subgraph.

Images