An erp master data intelligent cleaning and consistency checking method based on a knowledge graph

Abstract

The present application relates to the technical field of data processing, in particular to an ERP master data intelligent cleaning and consistency checking method based on a knowledge graph. The method comprises the following steps: data acquisition and preprocessing; master data knowledge graph construction; master data intelligent cleaning and consistency checking; master data synchronization and graph updating. The present application constructs a shadow repair chain relying on a local constraint closure subgraph, quantitatively evaluates the chain transmission influence caused by candidate repair actions through structured constraint disturbance budget, and pre-positions to avoid cross-module business constraint conflict. Meanwhile, a reverse echo verification mechanism is introduced to deduce the reverse allowed domain of the repair item, generate a compensation operation, and build a repair atomic component hierarchical optimization scheme, so as to build a two-way checking system combining forward rule matching and reverse constraint verification, make up for the short board of traditional schemes lacking pre-position risk assessment and reverse constraint verification, and comprehensively guarantee the consistency of ERP cross-module master data full-link constraints.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and more specifically, to a method for intelligent cleaning and consistency verification of ERP master data based on knowledge graphs. Background Technology

[0002] As enterprises continue to advance their digital transformation, the scale and complexity of ERP master data are constantly increasing, and knowledge graph-based data governance technology has become an important technical path for master data quality control.

[0003] In the existing technology, there are various data cleaning solutions based on knowledge graphs. For example, Chinese patent CN202511254237.7 discloses a material data cleaning method and system that integrates a large language model and a knowledge graph. Its knowledge graph stores core knowledge such as material classification systems, terminology definitions, and quality rules in the form of structured triples, providing a standard basis and standardized constraints for the cleaning operation. Combined with the natural language understanding, fuzzy semantic parsing, and unstructured information extraction capabilities of the large language model, it improves the accuracy of material data cleaning. Another example is Chinese patent CN202411389068.3, which discloses an automatic data cleaning method and system based on a knowledge graph. It constructs corresponding knowledge graphs based on the data tables corresponding to each data source, classifies entities in the graph to obtain multiple groups of similar entities, and completes multi-source knowledge graph integration and multi-source data cleaning by determining the target entity name and related entities.

[0004] The two knowledge graph-based data cleaning solutions mentioned above still have two technical limitations when facing ERP cross-module master data governance scenarios with multi-level business constraint propagation characteristics. First, the data repair action lacks a pre-emptive chain constraint impact assessment and control mechanism, which can easily lead to unexpected cross-entity constraint conflicts. For the solution disclosed in CN202511254237.7, its knowledge graph is only used to carry quality rules and provide positive standard basis for cleaning operations. The repair action is directly executed based on the rule verification results, without setting up a pre-assessment stage for the transmission effect of attribute changes along the business constraint path. For the solution disclosed in CN202411389068.3, its data correction only revolves around entity name matching and related entity integration, without considering the chain effect of entity attribute or relationship adjustments on surrounding business constraints, and directly outputs the integrated target data table, which cannot avoid the related constraint mismatch problem caused by the correction action. Second, the consistency verification only adopts the forward rule matching logic and lacks a reverse verification mechanism based on related constraints, making it difficult to guarantee data consistency across the entire constraint chain. The verification logic of CN202511254237.7 uses the quality rules of knowledge graph storage as a benchmark to perform positive compliance judgment on the target material data, but fails to deduce the legal range of the corrected values ​​from the perspective of affected related entities and business links. The consistency verification of CN202411389068.3 only focuses on the name consistency and association matching of similar entities from the same source, without constructing reverse verification logic for cross-entity constraint links. It can only achieve local data matching consistency and cannot cover the consistency requirements of the complete business constraint chain. Therefore, we propose a knowledge graph-based intelligent cleaning and consistency verification method for ERP master data. Summary of the Invention

[0005] The purpose of this invention is to provide an intelligent cleaning and consistency verification method for ERP master data based on knowledge graphs, so as to solve the problems mentioned in the background art of existing data repair that lack pre-chain constraint evaluation and lack a reverse verification mechanism for related constraints.

[0006] To address the aforementioned technical problems, this invention provides a knowledge graph-based intelligent cleaning and consistency verification method for ERP master data, comprising the following steps: S1. Data Acquisition and Preprocessing: Collect the original master data and business constraint metadata of each business module of the ERP system, and perform standardized preprocessing on the original master data and business constraint metadata to obtain preprocessed master data and business constraint metadata. S2. Master Data Knowledge Graph Construction: Based on the preprocessed master data and business constraint metadata, an ERP master data domain knowledge graph is constructed through entity node mapping, business relationship modeling, and constraint rule graphing. S3. Intelligent cleaning and consistency verification of master data: Based on the knowledge graph of ERP master data domain, abnormal master data is cleaned and its consistency is verified through the shadow repair chain mechanism based on constraint disturbance budget and reverse echo verification, so as to obtain standard master dataset and repair execution package. S4. Master Data Synchronization and Knowledge Graph Update: Based on the standard master dataset and repair execution package, perform cross-module master data write-back and incremental update of the ERP master data domain knowledge graph.

[0007] As a further improvement to this technical solution, the data acquisition and standardization preprocessing in S1 includes the following steps: S1.1 Extract the original master data and the corresponding business constraint metadata from each business module of the ERP system to complete the unified collection of multi-source heterogeneous data; S1.2. Perform metadata field mapping, data format normalization, and encoding system unification on the collected raw master data to obtain standardized master data. S1.3. Perform constraint type classification, associated entity attribute annotation and constraint rule structuring on the collected business constraint metadata to obtain standardized business constraint metadata.

[0008] As a further improvement to this technical solution, the construction of the master data knowledge graph in S2 includes the following steps: S2.1 Based on the preprocessed master data, extract master data entities according to entity category, map each master data entry to entity nodes of the knowledge graph, and attach attribute labels and attribute values ​​to the corresponding entity nodes; S2.2 Based on the business association logic carried by the preprocessed master data, identify the business association relationships between different entity nodes, generate entity-relationship-entity triples, and complete the construction of the graph relationship layer; S2.3 Based on the preprocessed business constraint metadata, map and bind various business constraint rules to entity node attributes and inter-entity association triples to complete the constraint rule graph processing; S2.4 Perform structural compliance verification on the completed graph. After the verification is passed, output the ERP master data domain knowledge graph.

[0009] As a further improvement to this technical solution, the master data intelligent cleaning and consistency verification in S3 includes the following steps: S3.1 Based on the domain knowledge graph of ERP master data, identify abnormal master data entities and generate corresponding candidate repair values; S3.2 For each abnormal master data entity, extract the corresponding local constraint closure subgraph; S3.3 Execute candidate repair actions in a temporary copy of the local constraint closed subgraph, generate shadow repair states and calculate the structured constraint perturbation budget, complete the initial screening of candidate repair schemes, and output the candidate repair schemes that pass the initial screening and their corresponding shadow repair states. S3.4. Based on the shadow repair status that has passed the initial screening, perform reverse echo verification and generate the corresponding compensation operation; S3.5. Combine the main repair action and compensation operation to construct the repair atom group, and perform hierarchical optimization of candidate repair schemes; S3.6 Output the optimized standard master dataset and the corresponding repair execution package; the repair execution package includes execution preconditions, recovery data, local knowledge graph incremental data and the basis for repair operation execution.

[0010] As a further improvement to this technical solution, the extraction of the local constraint closure subgraph in S3.2 includes the following steps: S3.21. Taking the entity node corresponding to the abnormal master data entity as the central node, sort out all business constraint rules and constraint transmission paths associated with the central node; S3.22. Traverse the neighborhood entity nodes and associated triples along the constraint propagation path, and collect all associated nodes, attributes and relation edges that participate in constraint verification; S3.23. Trim redundant nodes and relation edges that are not constrained to the current anomaly repair scenario to form a locally constrained closed subgraph that covers all associated constraints.

[0011] As a further improvement to this technical solution, the shadow repair state generation and structured constraint perturbation budget calculation in S3.3 include the following steps: S3.31. Generate a local, independent temporary copy of the locally constrained closure subgraph without modifying the original ERP master data domain knowledge graph; S3.32. Convert each candidate repair value into a candidate repair action for attribute modification, relationship addition, relationship deletion, relationship migration or state change, and virtually execute all candidate repair actions in a temporary copy to generate the corresponding shadow repair state. S3.33. In the shadow repair state, re-verify the attribute value constraints, relationship existence constraints, relationship cardinality constraints, validity period constraints, and state linkage constraints, and compare the changes in constraint residuals before and after repair. S3.34. Calculate the change in constraints according to the type of constraint and generate a structured constraint disturbance budget; S3.35. Based on the structured constraint perturbation budget, candidate repair schemes that do not conform to the screening rules corresponding to the structured constraint perturbation budget are screened out, and the candidate repair schemes that pass the initial screening are output.

[0012] As a further improvement to this technical solution, the structured constraint perturbation budget generation and scheme elimination in S3.34 includes the following steps: S3.341. Count the number of newly added hard constraint violations, the number of key constraint unverifiable items, the number of non-target relationship disturbances, and the total number of repair operations in the form of independent components, and construct a four-dimensional structured constraint disturbance budget vector. Do not weight and merge the components. The structured constraint perturbation budget vector satisfies the following relationship: ; In the formula: This is the budget vector for the structured constraint perturbation. To increase the number of hard constraint violations, The number of unverifiable items for critical constraints. This represents the number of non-target relational perturbations. Total number of repair operations; S3.342. When the number of newly added hard constraint violations is greater than zero or the number of critical constraint unverifiable items is greater than zero, the corresponding candidate repair scheme is directly excluded. S3.343. The number of non-target relationship disturbances and the total number of repair operations are retained as independent evaluation dimensions for subsequent hierarchical optimization.

[0013] As a further improvement to this technical solution, the reverse echo verification and compensation operation in S3.4 includes the following steps: S3.41. Locate the associated entity nodes and end nodes of the relationship chain affected by the candidate repair actions, and sort out the business constraint rules corresponding to each node; S3.42. Based on the business constraint rules of each associated node, reversely deduce the set of allowed values ​​corresponding to the target repair attribute or target repair relationship; S3.43. Take the intersection of the allowed value sets corresponding to multiple associated constraints to form the reverse allowable domain of the target repair item; S3.44. Match and verify the candidate repair value with the reverse allowable field. If the candidate repair value does not belong to the reverse allowable field, exclude the corresponding candidate repair scheme. S3.45 When a candidate repair value belongs to the reverse allowable domain but still has constraint residuals, compensation operations are performed based on the unmet constraints to generate relationship completion, associated state synchronization, or validity period adjustment.

[0014] As a further improvement to this technical solution, the construction of the repair atom set and the hierarchical selection of candidate repair schemes in S3.5 include the following steps: S3.51. Sort and combine the main repair action and the compensation operation that must be executed synchronously according to the business constraint dependency relationship to form an indivisible repair atomic group. S3.52. The candidate repair schemes containing the repair atom group are compared in a hierarchical manner according to the priority of reverse echo residual, degree of non-target constraint disturbance, number of affected business modules, and total number of repair operations, and the optimal scheme is selected.

[0015] As a further improvement to this technical solution, the master data synchronization and map update in S4 include the following steps: S4.1. Based on the execution preconditions in the repair execution package, review the current master data status of the ERP system, and start the write-back process after confirming that the execution preconditions are met. S4.2. Perform master data write-back operations for each business module of the ERP system according to the operation execution order of the repair atomic group in the repair execution package. If the critical operation fails, the executed operation shall be undone according to the recovery data in the repair execution package. S4.3 After the master data write-back is successfully executed, the incremental update of the ERP master data domain knowledge graph is completed based on the incremental data of the local knowledge graph in the repair execution package.

[0016] Compared with the prior art, the beneficial effects of the present invention are as follows: 1. This invention constructs a shadow repair chain mechanism based on constraint perturbation budget, relies on temporary copies of local constraint closure subgraphs to pre-simulate candidate repair actions, quantifies and calculates the degree of constraint propagation perturbation, identifies and avoids cross-entity and cross-business module constraint conflicts caused by data repair in advance, and effectively improves the risk prediction capability and business compliance level of master data repair operations; 2. This invention employs a reverse echo verification mechanism to build a bidirectional constraint verification logic. By inversely deriving the allowed value range of the target repair item through associated constraints, and combining the hierarchical optimization of repair atomic components, the full-link consistency verification is completed. This compensates for the coverage limitations of a single forward rule verification, ensures the consistency of the full constraint link of ERP cross-module master data, and effectively improves the quality of master data cleaning. Attached Figure Description

[0017] Figure 1 This is a schematic diagram of the overall process steps of the present invention. Detailed Implementation

[0018] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0019] like Figure 1As shown, this embodiment provides a knowledge graph-based intelligent cleaning and consistency verification method for ERP master data. This method is applicable to quality governance scenarios of cross-module master data in enterprise resource planning systems, especially addressing the consistency maintenance needs of core master data such as materials, suppliers, customers, and financial accounts across multiple business modules. This method can be implemented on a data processing server connected to the ERP system database. By constructing a master data domain knowledge graph, it unifies the master data instances and business constraint rules scattered across various modules into a graph model. Based on this, a shadow repair chain mechanism based on constraint disturbance budgeting and reverse echo verification is run to achieve intelligent cleaning and consistency verification of abnormal master data. The overall processing flow starts with the collection and standardization of multi-source master data and constraint metadata, proceeding through knowledge graph construction, anomaly location and candidate repair generation, local shadow repair deduction, disturbance filtering and compensation verification, hierarchical optimization of repair schemes, and finally standard master data write-back and incremental graph update. Each step uses the knowledge graph as a link and the repair execution package as a carrier, forming a closed-loop governance system of "discovery-diagnosis-repair-synchronization". The method includes the following steps: S1. Data Acquisition and Preprocessing: This step involves collecting raw master data and business constraint metadata from each business module of the ERP system. The raw master data and business constraint metadata are then standardized and preprocessed to obtain preprocessed master data and business constraint metadata. Specifically, S1 collects raw master data and business constraint metadata from each business module of the ERP system. After standardization preprocessing, it outputs standardized master data and standardized business constraint metadata with a unified format and consistent semantics. This provides the foundational data for entity node mapping, business relationship modeling, and constraint rule graphing in S2. This includes the following steps: S1.1 Extract the original master data and corresponding business constraint metadata from each business module of the ERP system to achieve unified aggregation of multi-source heterogeneous data. In the ERP system, modules such as material management, procurement management, sales management, financial management, and production management independently maintain partial copies or master data views. The master data table structure, field naming conventions, encoding rules, and storage formats of each module differ. The business constraints such as validation rules, referential relationships, and state dependencies followed by each module exist in explicit forms such as database constraints and foreign key associations, while others exist implicitly in various places in forms such as application-layer validation logic, configuration table parameters, or business documents.

[0020] S1.1 configures corresponding data extraction adapters for each business module, extracting the following two types of data from relational database tables, views, configuration tables, interface logs, and some semi-structured business rule configuration files: The original master data includes: material master data, supplier master data, customer master data, financial account master data, organizational structure master data, project master data, and contract master data. Each master data record contains information such as entity identifier, current value of each attribute field, creation time, last modification time, module to which it belongs, and data status. During extraction, the record-level granularity in the source module is retained, and cross-module merging or deduplication is not performed.

[0021] Business constraint metadata describes the constraint rules that the master data of each module must adhere to, including: field value range constraints, field format constraints, field value consistency constraints, cross-entity referential integrity constraints, inter-entity relationship cardinality constraints, state linkage constraints, time validity constraints, and code uniqueness constraints. Extraction is performed using rule description fragments as the basic unit, retaining metadata such as the constraint source module, the entity type and attribute fields affected by the constraint, the reference relationships between constraints, and the constraint type identifier. Rules existing in the form of database constraints are obtained by querying system directory tables or data dictionaries; rules implemented in application layer logic are parsed from configuration tables or business rule description files using pre-defined rule extraction templates.

[0022] The extraction operation is performed according to the preset data synchronization cycle or the cleaning task trigger cycle. The extraction results are temporarily stored according to the source module identifier to form a unified multi-source dataset. Subsequent standardization processing is directly based on this dataset, without repeatedly accessing the production databases of each business module.

[0023] S1.2. Metadata field mapping, data format normalization, and encoding system unification are performed on the aggregated raw master data to obtain standardized master data. Specifically, the field names, data types, length constraints, and encoding rules of the master data table structures of different business modules vary, and the representation format of the same attribute value also differs in different modules. Directly importing the knowledge graph would result in the same entity being identified as multiple different nodes, or the same attribute value failing to perform equality comparisons and constraint checks between different nodes. Therefore, S1.2 eliminates these differences through the following processing: Metadata Field Mapping: A global master data model is pre-established, defining standard entity types and standard attribute sets, standard field names, and standard data types for each entity type. Based on the global master data model, the fields from the original master data tables of each module are mapped one by one to the standard attribute fields. Fields with different names but the same semantics are mapped using a pre-defined synonym field lookup table; if a standard attribute is missing in some modules, the corresponding field position is filled with a null value and marked as missing; fields that are unique to a module and have no globally corresponding attribute are retained in the extended attribute area and marked with the source module.

[0024] Data format normalization: After the field mapping is completed, the values ​​of the master data attributes are uniformly converted according to the data type and format specifications defined by the standard attributes. This includes: unifying the date and time format, converting different representations such as "yyyy / MM / dd", "dd-MM-yyyy", and "yyyyMMdd" in various modules into the ISO 8601 standard format; unifying the precision and decimal places of numeric types; standardizing the representation of Boolean values ​​and enumeration values; standardizing the handling of whitespace characters, newlines, and punctuation marks in text fields; and unifying the representation of null values ​​and empty strings.

[0025] Unified Coding System Processing: Business codes for master data entities may be generated using different coding rules in different modules, and the same real entity may hold different codes in different modules. Based on a pre-maintained coding mapping table or a globally unique identifier mapping relationship, the local codes of each module are replaced with a globally unified code, while retaining the correspondence between local and global codes. This is used to map the cleansing results back to the local coding system of each module during S4 master data write-back. Code values ​​not covered in the coding mapping table are marked as pending matching and output to the manual review queue.

[0026] After processing, standardized master data is obtained. Each master data record is represented by a globally unified data model. The attribute field names, data types, value formats, and entity codes are all consistent. Master data of the same entity from different modules have the conditions to be correlated and compared.

[0027] S1.3. Perform constraint type classification, associated entity attribute annotation, and constraint rule structuring on the collected business constraint metadata to obtain standardized business constraint metadata. Specifically, the business constraint metadata collected in S1.1 exists in the form of rule description fragments, and its expression depends on the local context of the source module. Some are natural language annotations, and some are unstructured or semi-structured configuration parameters, which cannot be directly loaded by the knowledge graph or uniformly interpreted by the graph computing engine. S1.3 transforms these multi-source heterogeneous constraint descriptions into structured constraint rules with unified structure, clear semantics, and direct mapping and binding to knowledge graph entity nodes and relation edges. The specific processing is as follows: Constraint Type Classification: Based on the semantic characteristics and validation scope of the constraint rules, each constraint rule is categorized into a predefined constraint type. Constraint types include at least: attribute value constraints (such as field value range, enumerated value list, regular expression pattern constraints), relationship existence constraints (such as a material must belong to at least one material group), relationship cardinality constraints (such as a purchase order can be associated with at most one approved supplier), timeliness constraints (such as the supplier's status must be "qualified" during the contract validity period), and status linkage constraints (such as when the purchase order status is "received," the associated inbound order status cannot be "pending receipt"). The type classification result is appended to each rule as a constraint type identifier.

[0028] Entity Attribute Annotation: For each constraint rule, identify and annotate the type of the subject entity constrained by the rule, the constrained attribute fields or relation types, and the reference entity type and its attribute fields involved in the rule. For example, in the constraint rule "The tax-inclusive amount of a purchase order shall not exceed the total amount of the associated contract," the subject entity type is "purchase order," the constrained attribute is "tax-inclusive amount," the reference entity type is "contract," and the reference attribute is "total amount." The annotation results form explicit association records between constraint rules and entity attributes, providing a basis for the location of constraint rules to graph nodes and relation edges in S2.

[0029] Structured processing of constraint rules: Constraint rules, after type classification and association annotation, are uniformly expressed in a structured rule representation. This can use a tuple structure of "constraint type + main entity type + main attribute / relationship + constraint parameter + reference entity type + reference attribute / relationship," or other structured expressions that can be directly parsed by subsequent graph processing flows. Complex logical constraints with multiple conjunctive or disjunctive conditions are decomposed into multiple basic constraint rules, retaining logical association markers. For constraints requiring external data sources or cross-system data for verification, external dependency markers are appended to the structured expression for use in subsequent verification processes when determining unverifiable items.

[0030] After processing, standardized business constraint metadata is obtained. Each constraint rule has a clear constraint type attribution, complete entity attribute association annotation, and a unified structured expression form, which can be directly used as input for S2.3 constraint rule graphing processing.

[0031] After processing in S1.1 to S1.3, the original master data and business constraint metadata from various business modules of the ERP are transformed into standardized master data and standardized business constraint metadata. The two are consistent in terms of data format and semantic expression, providing a consistent basic input for the construction of the S2 master data knowledge graph.

[0032] S2. Master Data Knowledge Graph Construction: Based on the preprocessed master data and business constraint metadata, an ERP master data domain knowledge graph is constructed through entity node mapping, business relationship modeling, and constraint rule graphification. Specifically, based on the standardized master data and standardized business constraint metadata obtained in S1, S2 uniformly expresses master data instances and their business constraints as a graph model, forming the ERP master data domain knowledge graph. This graph consists of a three-layer structure: an entity node layer, a relationship layer, and a constraint layer, providing a traversable and reasonable data foundation for anomaly identification, shadow repair, and consistency verification in S3. The steps include: S2.1 Based on the preprocessed master data, entity extraction is performed according to entity categories. Each master data entry is mapped to an entity node in the knowledge graph, and attribute tags and attribute values ​​are attached to the corresponding entity nodes. Specifically, each record in the standardized master data corresponds to a master data instance in the real business world. S2.1 transforms them one by one into entity nodes in the knowledge graph. During processing, the master data records are first grouped into entity categories such as materials, suppliers, customers, financial accounts, organizational structure, projects, and contracts according to the entity categories defined in the global master data model. Each record within the same entity category generates a corresponding entity node in the knowledge graph. The node identifier adopts the unified global code in S1.2. Multiple source module master data records corresponding to the same global code correspond to the same real business entity and are merged into a single entity node. The latest valid value of common attributes is taken based on the "last modification time" collected in S1.1. If the values ​​of the same common attribute in different modules conflict, they are simultaneously marked as "attribute inconsistency anomaly" and included in the anomaly identification scope of S3. The extended attributes unique to each module are retained in the node extended attribute area and the source module is marked. Master data records not covered by the encoding mapping table and marked as pending matching are temporarily generated as temporary entity nodes with local encoding and marked as "pending encoding matching". They are not included in the automatic cleaning and verification scope and will be merged into formal entity nodes after the global encoding is manually confirmed.

[0033] Each entity node is attached with attribute labels and attribute values. Attribute labels are taken from the standard attribute field names defined for that entity category in the global master data model, and attribute values ​​are the corresponding field values ​​normalized by S1.2. Taking a material entity as an example, the attribute labels attached to the node include material code, material name, specifications, basic unit of measurement, material group, and material type. The attribute values ​​are directly taken from the corresponding fields in the standardized master data for that material record. Attribute labels and attribute values ​​are attached to the node in key-value pairs, allowing subsequent constraint verification and repair operations to directly read and modify them.

[0034] S2.2 Based on the business association logic carried by the preprocessed master data, identify the business association relationships between different entity nodes, generate entity-relationship-entity triples, and complete the construction of the graph relationship layer; in addition to the attribute information of each entity itself, the standardized master data also carries the business association logic between entities. These association logics exist in the source system in the form of foreign key references, association tables, cross-reference fields, etc. After standardization in S1.2, they are uniformly expressed as association fields or association records between entities in the global data model.

[0035] S2.2 iterates through the association fields in the standardized master data, identifies the business relationships between entity nodes, and generates an "entity-relationship-entity" triple for each association. The subject and object of the triple are the entity nodes established in S2.1, and the relationship type is determined based on the business semantics of the association fields. Common business relationships include: the "supply" relationship between suppliers and materials, the "attribution" relationship between materials and material groups, the "coverage" relationship between contracts and materials, the "contractor" relationship between contracts and suppliers, the "attribution" relationship between financial accounts and organizational structures, and the "association" relationship between projects and contracts.

[0036] For cases where relational attributes exist (such as price, minimum order quantity, and delivery cycle in a "supply" relationship), the relational attributes are attached to the relational edges as key-value pairs while generating triples. The generated set of triples constitutes the relational layer of the knowledge graph, and entity nodes are interconnected through directed relational edges to form a traversable graph structure.

[0037] S2.3 Based on the preprocessed business constraint metadata, map and bind various business constraint rules to entity node attributes and inter-entity association triples to complete the constraint rule graph processing; Specifically, in the standardized business constraint metadata output by S1.3, each constraint rule has completed constraint type classification, associated entity attribute annotation, and structured expression. Based on this, S2.3 binds each constraint rule to the corresponding entity node attribute or entity association triple in the knowledge graph, making the constraint rules an integral part of the graph structure, rather than a validation script independent of the graph.

[0038] The specific binding method is as follows: For attribute value constraints, based on the association annotation results of the rules, the corresponding entity node and attribute label are located, and the constraint rules are attached to the attribute label to form a "node-attribute-constraint" binding. For relation existence constraints and relation cardinality constraints, based on the subject entity type and relation type marked by the rules, the corresponding entity node and relation type are located, and the constraint rules are attached to the relation type or entity node. The relation cardinality constraint is attached to the corresponding relation edge, and the relation existence constraint is attached to both the subject entity node and the corresponding relation edge. For time-sensitive constraints and state-linked constraints, based on the main entity type, reference entity type and association relationship marked by the rule, the two entity nodes involved and the relationship edge between them are located, and the constraint rule is attached to the relationship edge.

[0039] After binding, entity node attributes in the knowledge graph not only carry attribute values ​​but also a set of constraint rules applied to those attributes. By default, uniqueness constraints, required attribute constraints, and relationship existence constraints are classified as hard constraints, while other constraint types are classified as soft constraints. The enforcement level of constraints can be adjusted according to business configuration. Relationship edges not only express the business association between entities but also carry a set of constraint rules applied to that relationship. In this way, the constraint rules are graph-based, allowing S3 to directly obtain all constraint rules associated with any entity node or relationship edge through graph traversal during subsequent consistency checks, without needing to query an external constraint library.

[0040] S2.4 Perform structural compliance verification on the completed knowledge graph. After successful verification, output the ERP master data domain knowledge graph. Specifically, the knowledge graphs built in S2.1 to S2.3 undergo structural compliance verification before being used for cleaning and verification in S3 to eliminate potential structural errors introduced during the construction process. The verification content includes at least: Node integrity check: Check for entity nodes that do not have necessary attribute tags attached, or nodes whose attribute values ​​exceed the preset valid range. Such nodes may be caused by missing data or mapping errors in S1.

[0041] Relationship consistency check: Check whether the entity nodes referenced at both ends of the triple exist in the graph, and whether there are dangling references or isolated nodes.

[0042] Constraint binding validity verification: Check whether each constraint rule is successfully bound to at least one entity node attribute or relation edge in the graph, and whether there are constraint rules that cannot locate the binding target; for constraint rules that are labeled with reference entity type but whose reference entity node does not exist in the graph, mark them as constraints that cannot be verified and record them.

[0043] The structural problems found in the above verification are handled according to their severity: errors that affect the basic connectivity of the graph (such as dangling references or missing necessary attributes) are directly rolled back to the corresponding preceding steps for correction; problems that only affect the verifiability of individual constraints (such as missing reference entities) are recorded but the graph output is not blocked, and are used by S3 to determine unverifiable items when performing constraint verification.

[0044] After successful verification, an ERP master data domain knowledge graph is output, consisting of three layers: entity node layer, relationship layer, and constraint layer. This knowledge graph unifies master data instances, business relationships, and business constraint rules into a traversable, queryable, and locally modifiable graph, providing a structured operational foundation for S3's shadow repair inference, constraint disturbance budget calculation, and reverse echo verification.

[0045] S3. Intelligent Master Data Cleaning and Consistency Verification: Based on the ERP master data domain knowledge graph, anomaly master data is cleaned and its consistency verified through a shadow repair chain mechanism based on constraint disturbance budget and reverse echo verification, resulting in a standard master dataset and a repair execution package. Here, reverse echo verification refers to starting from the associated entity nodes and the end of the relationship chain affected by the repair action, and deriving the set of legal values ​​for the target repair item based on the business constraint rules attached to each node. A global reverse allowable domain is formed by taking the intersection of multiple constraints, thereby verifying the compliance of candidate repair values ​​and generating corresponding compensation operations. Furthermore, the shadow repair chain mechanism uses an independent temporary copy of the local constraint closure subgraph as a simulation carrier, sequentially executing a progressive repair verification chain: virtual repair deduction, initial screening using structured constraint disturbance budget, reverse echo verification compensation, and hierarchical selection of repair atomic components. Throughout the process, the original knowledge graph and ERP business data are not modified, achieving secure verification of the anomaly master data and outputting the optimal repair solution.

[0046] Specifically, S3, based on the ERP master data domain knowledge graph constructed by S2, executes the entire deductive process from anomaly identification to remediation plan generation. The input of S3 is the knowledge graph output by S2, which contains a three-layer structure: entity node layer, relation layer, and constraint layer. The output of S3 is the standard master dataset and the remediation execution package, which serves as the basis for S4 to perform master data write-back and incremental graph updates.

[0047] Furthermore, the processing logic of S3 generally unfolds in the following order: "anomaly detection and candidate generation—extraction of local constraint closure subgraphs—shadow repair deduction and initial perturbation screening—reverse echo verification and compensation—packaging and hierarchical optimization of repaired atom groups—result output." Each sub-step can be executed by a data processing server connected to the ERP system database. The storage and traversal of the knowledge graph are implemented based on a graph database, and calculations such as constraint verification, shadow repair, and reverse deduction are completed by the processing program on the server. S3 includes the following steps: S3.1 Based on the domain knowledge graph of ERP master data, identify abnormal master data entities and generate corresponding candidate repair values; Specifically, the process iterates through each entity node in the knowledge graph, reading the field value consistency constraints, encoding uniqueness constraints, attribute value constraints, relationship existence constraints, relationship cardinality constraints, timeliness constraints, and state linkage constraints attached to the node attributes. The current attribute values ​​and relationship states of the node are then compared one by one with the corresponding constraint rules. If the verification finds that an attribute value exceeds the range, a relationship is missing, the relationship cardinality exceeds the upper limit or falls below the lower limit, the timeliness attribute does not match the state of the associated entity, or the state linkage condition is not met, the entity node is marked as an abnormal master data entity, and the identifier of the violated constraint rule and its current value or state are recorded.

[0048] For each anomalous master data entity, candidate repair values ​​are generated based on the type of constraint rule it violated, and the generation is performed according to the following rules: For violations of attribute value constraints, candidate repair values ​​are obtained sequentially from the following sources until the number of candidate repair values ​​reaches a preset upper limit: The first source is the boundary value of the value range defined by the constraint rule itself (taking the boundary closest to the current violation value); the second source is the corresponding attribute value of the last valid record in the historical version of the abnormal entity; the third source is the common values ​​of this attribute for other entities with normal attribute values ​​in the same entity category. These common values ​​can be selected based on value frequency or by taking the median.

[0049] For cases where the existence constraint of relations is violated, the knowledge graph searches for similar entity nodes that satisfy the reference constraint conditions, and identifies the first few nodes found as candidate repair values. The search scope is initially limited to the graph region corresponding to the same business module. After the local constraint closure subgraph of S3.2 is extracted, precise verification and filtering are performed within the subgraph.

[0050] In cases where the cardinality constraint is violated, if the upper limit is exceeded, the currently associated relationships are sorted in reverse order of creation time, and redundant relationships at the end of the sort are identified as candidate deletion objects; if the lower limit is exceeded, the handling method for violations of the relationship existence constraint is referred to, and potential associated entity nodes that meet the conditions are searched as candidate addition targets.

[0051] In cases where state linkage constraints are violated, legal state values ​​defined in the linkage rules are read, and other legal state values ​​other than the current state value are used as candidate repair values.

[0052] The candidate repair values ​​generated for each anomalous entity are associated with the anomalous entity node in the form of a list, and each candidate repair value is accompanied by a source identifier. If the candidate repair value list for a certain anomalous entity is empty, the anomalous entity is directly marked as unresolved for automatic repair and output to the manual processing queue.

[0053] S3.2. For each anomalous master data entity, extract the corresponding local constraint closure subgraph. Specifically, taking the entity node corresponding to the anomalous master data entity as the central node, starting from this central node, traverse outward layer by layer along the constraint propagation path in the knowledge graph, incorporating nodes, attributes, relation edges, and constraint rules that are constraint-related to the current anomaly repair into the same subgraph, and removing redundant elements irrelevant to this repair, forming a local constraint closure subgraph. This step is specifically divided into the following sub-steps: S3.21. Taking the entity node corresponding to the abnormal master data entity as the central node, sort out all business constraint rules and constraint propagation paths associated with the central node; in the knowledge graph, starting from the abnormal entity node, query the attribute value constraint rules attached to each attribute of the node, the relationship existence constraint and relationship cardinality constraint rules attached to the relationship edge of the node as the subject or object, and the timeliness constraint and state linkage constraint rules attached to the relationship edge between the node and related nodes, and summarize to obtain the set of constraint rules directly acting on the central node. For each constraint rule in the set, if the rule is marked with a reference entity type or reference attribute, then starting from the central node, extend along the relationship edge in the graph towards the reference entity, and record the constraint propagation path from the central node to the reference node. If the reference node itself is also the subject node of other constraint rules, then continue to advance along the constraint propagation direction until all nodes with constraint propagation relationships have been traversed, or the traversal depth reaches the preset maximum hop threshold (usually set to 2-3 hops).

[0054] S3.22. Traverse the neighboring entity nodes and associated triples along the constraint propagation path, collecting all associated nodes, attributes, and relational edges participating in constraint verification. Starting from the central node, traverse the constraint propagation path outlined in S3.21 hop-by-hop. The traversal depth is limited by the maximum number of hops set in S3.21, stopping when the maximum number of hops is reached or the path terminates naturally. Collect the identifier of each neighboring entity node on the path, the attribute labels and values ​​related to the constraint rules on that node, and the relational triples connecting each node. The collection scope includes the direct neighboring nodes of the central node and the indirect neighboring nodes connected by multi-hop relationships and exhibiting constraint propagation, as well as all relational edges between these nodes participating in constraint verification. During the collection process, record the constraint propagation distance between each collected element and the central node, and the constraint rule identifiers traversed along the propagation path.

[0055] S3.23. Trim redundant nodes and relation edges that are not constrained to the current anomaly repair scenario to form a locally constrained closed subgraph that covers all associated constraints.

[0056] In this step, to fully accommodate all the rule elements required for constraint verification, the standard subgraph structure is expanded, and the local constraint closure subgraph is defined as a triple: ; In the formula: Represents a locally constrained closed subgraph; This represents the set of entity nodes in the subgraph that are constrained to the current anomaly repair, including the central node and its neighboring nodes reachable along the constraint propagation path; This represents the set of relation edges connecting nodes in a subgraph, where each relation edge participates in the validation of at least one constraint rule; This represents the set of constraint rules attached to node attributes and relation edges in the subgraph, which covers all constraints involved in fixing the current anomaly.

[0057] During the construction process, the set of nodes and relation edges collected in S3.22 is examined to determine whether each node and each relation edge has participated in the verification of at least one constraint rule related to the current anomaly repair. Nodes and relation edges that are not related to any constraint rules involved in anomaly repair are removed from the set. The remaining part after removal constitutes... and The corresponding constraint rules are formed After extraction, record the boundary node identifiers of the subgraph for subsequent determination of whether the impact of the repair exceeds the subgraph boundary.

[0058] S3.3. Execute candidate repair actions in a temporary copy of the local constraint closure subgraph, generate shadow repair states, calculate the structured constraint perturbation budget, complete the initial screening of candidate repair schemes, and output the candidate repair schemes that pass the initial screening and their corresponding shadow repair states; this step is specifically divided into the following sub-steps: S3.31. Generate a local, independent temporary copy of the local constraint closure subgraph without modifying the original ERP master data domain knowledge graph; the local constraint closure subgraph extracted in S3.2... All nodes, attribute values, relation edges, and attached constraint rules are completely copied into memory or temporary storage space, generating a temporary copy that is physically isolated from the original knowledge graph. The node identifiers and relation identifiers in the temporary copy are consistent with the original graph, but all subsequent modifications only apply to the temporary copy, and the original knowledge graph remains unchanged throughout the entire S3 processing.

[0059] S3.32. Convert each candidate repair value into a candidate repair action for attribute modification, relationship addition, relationship deletion, relationship migration or state change, and virtually execute all candidate repair actions in a temporary copy to generate the corresponding shadow repair state. In this step, each candidate repair value generated in S3.1 is mapped to a specific repair action type based on its corresponding constraint violation type. The mapping relationship is as follows: When an attribute value constraint is violated, the corresponding candidate repair value is converted into an attribute modification action, and the modification target is the specified attribute label of the abnormal entity node; When a relationship existence constraint violation is committed, the corresponding candidate repair value is transformed into a relationship addition action, and a new relationship edge is added to connect the abnormal entity node and the candidate target entity node. Violations of the cardinality constraint exceeding the upper limit are converted into relation deletion actions, while violations below the lower limit are converted into relation creation actions. When a state linkage constraint is violated, the corresponding candidate repair value is converted into a state change action, which modifies the state attribute value of the abnormal entity node. Situations involving entity attribution adjustments are transformed into relationship migration actions, which disconnect abnormal entity nodes from their original relationship targets and connect them to new target nodes. This action is executed as an atomic operation.

[0060] Furthermore, let the initial state of the locally constrained closed subgraph before repair be denoted as . A candidate repair scheme includes Candidate repair actions to be executed sequentially , No. One action After execution, the subgraph state changes from Change to Then the shadow repair status corresponding to the candidate repair scheme for: ; In the formula: This represents the initial state of the locally constrained closed subgraph before repair, including the attribute values ​​of each node and the relationship edges between nodes; Indicates the first One repair action; This represents the operation of repair actions on the subgraph state, satisfying the right-associative rule. Actions are applied to the subgraph state sequentially from right to left, consistent with the actual execution order of the action sequence. The attribute values ​​or relation edges of the corresponding nodes in the temporary copy are updated according to the action type. Each shadow repair state is associated with a corresponding candidate repair scheme, and the executed action sequence, the original value before each action modification, and the new value after modification are recorded.

[0061] S3.33. In the shadow repair state, re-verify attribute value constraints, relationship existence constraints, relationship cardinality constraints, validity period constraints, and state linkage constraints, and compare the changes in constraint residuals before and after repair; for basic rules decomposed from complex logical constraints, the verification is based on the retained logical association markers for combination judgment: conjunctive constraints are compliant only if all sub-constraints are satisfied, and disjunctive constraints are compliant only if at least one sub-constraint is satisfied.

[0062] In this step, for each shadow repair state, based on the node attribute values ​​and relation states in the temporary copy, we re-traverse all nodes and relation edges within the local constraint closure subgraph and re-examine the field value consistency constraints, encoding uniqueness constraints, attribute value constraints, relation existence constraints, relation cardinality constraints, timeliness constraints, and state linkage constraints, and perform constraint verification one by one, recording the verification results.

[0063] Record the initial state of the subgraph before repair. The set of constraint rule identifiers that are violated is as follows Shadow repair status The set of constraint rule identifiers that are violated is as follows Calculate the change in constraint residuals The difference in the number of elements in two sets: ; Furthermore, the changes in constraint violations before and after the repair are further divided into three categories: Set of resolved constraints The number of its elements is denoted as This indicates a constraint that was violated before repair but satisfied after repair. Add a set of violated constraints The number of its elements is denoted as This indicates a constraint that was satisfied before repair but violated after repair. The set of constraints that are violated both before and after the repair is denoted as . The number of its elements is denoted as .

[0064] The above quantities satisfy: ,and .

[0065] S3.34. Calculate the constraint changes according to constraint type and generate a structured constraint disturbance budget; S3.34 is specifically divided into the following sub-steps: S3.341. Count the number of newly added hard constraint violations, the number of key constraint unverifiable items, the number of non-target relationship disturbances, and the total number of repair operations in the form of independent components, and construct a four-dimensional structured constraint disturbance budget vector. Do not weight and merge the components. The structured constraint perturbation budget vector satisfies the following relationship: ; In the formula: Represents the structured constraint perturbation budget vector; This indicates the number of newly added hard constraint violations, and the statistical scope is as follows: The number of constraint rules belonging to the hard constraint type. Hard constraints refer to business constraint rules that will directly lead to data unavailability if violated. These include code uniqueness constraints, mandatory field rules in attribute value constraints, and mandatory association rules in relation existence constraints. Each constraint rule has been marked with a hard or soft constraint type identifier during S2.3 graph processing. This indicates the number of unverifiable critical constraints. The statistical scope is the number of constraint rules marked as hard constraints and core business rules that cannot be verified due to missing reference entities, unreachable external data sources, or incomplete constraint rules themselves. Unverifiable items of non-critical constraints are not included in this component's statistics. This indicates the number of non-target relation disturbances. The statistical scope is the number of changes to relation edges within the scope of the repair operation that are not the target of this repair. Changes include relation additions, relation deletions, and relation modifications. Among them, the relation boundary corresponding to the original abnormal constraint directly targeted by this repair is defined as the target relation. Relationship boundaries that are indirectly caused by changes during the repair process and are not directly related to the original abnormal constraint are defined as non-target relations. Relationship edges added by the compensation operation for residual constraints are not included in the statistics of non-target relation disturbances.

[0066] This represents the total number of repair operations. The statistical caliber is the sum of the counts of all repair actions included in the candidate repair scheme. Repair action types include attribute modification, relationship addition, relationship deletion, relationship migration, and status change.

[0067] Furthermore, the four components are counted independently without normalization or weighted merging.

[0068] S3.342. When the number of newly added hard constraint violations is greater than zero or the number of critical constraint unverifiable items is greater than zero, the corresponding candidate repair solutions are directly excluded; specifically... This indicates that the candidate repair scheme introduced new hard constraint violations during the repair process, and the repaired data still contains unacceptable constraint violations, so the scheme is directly excluded. This indicates that due to missing reference information, it is impossible to determine whether a key constraint is met after the repair, and the compliance of the repair result cannot be confirmed. Therefore, this solution is also directly excluded. Only when and At this point, candidate repair solutions that pass the screening in this step are retained for subsequent processing.

[0069] S3.343. The number of non-target relation perturbations and the total number of repair operations are retained as independent evaluation dimensions for subsequent stratified selection. Specifically, for candidate repair schemes that have passed the screening in S3.342 and have not been excluded, their... and The two component values ​​are retained along with the scheme and are not used for threshold judgment or sorting in this step. They are reserved for use as comparison dimensions during the S3.5 hierarchical optimization.

[0070] S3.35. Based on the structured constraint perturbation budget, candidate repair schemes that do not conform to the screening rules corresponding to the structured constraint perturbation budget are screened out, and the candidate repair schemes that pass the initial screening are output. Summarize the screening results of S3.342, and... and Candidate repair schemes are marked as having passed the initial screening, and a list of candidate repair schemes that have passed the initial screening and the shadow repair status of each scheme are output. If all candidate repair schemes for an anomalous entity are screened out, the anomalous entity is marked as having pending automatic repair and is output to the manual processing queue. At the same time, the perturbation budget vector of each scheme is retained for manual evaluation and reference.

[0071] S3.4. Based on the shadow restoration status that has passed the initial screening, perform reverse echo verification to generate the corresponding compensation operation; this step is specifically divided into the following sub-steps: S3.41. Locate the associated entity nodes and end nodes of the relationship chain affected by the candidate repair actions, and sort out the business constraint rules corresponding to each node. Specifically, for each candidate repair scheme that passes the initial screening, read the repair action sequence recorded in S3.32, and identify the nodes and relationship edges directly affected by each repair action in the local constraint closure subgraph. Starting from these affected nodes, extend outward along the relationship edges to the end node of the relationship chain (i.e., the boundary node of the local constraint closure subgraph, which has no constraint propagation path extending outward from the subgraph), and collect all the business constraint rules attached to these nodes. During the sorting, focus on those constraint rules that take the affected nodes as the main body and whose constraint conditions reference the modified attributes or modified relationships. These rules will be used as the constraint conditions for reverse derivation.

[0072] S3.42. Based on the business constraint rules of each associated node, reversely deduce the set of allowed values ​​corresponding to the target repair attribute or target repair relationship; In this step, for each constraint rule identified in S3.41, the parameters related to the attribute or relationship being repaired are taken as variables, and the other parameters in the constraint rule are substituted with their actual values ​​under the current shadow repair state to solve for the set of allowed values ​​for the variable under the constraint conditions. The reverse derivation proceeds from "requiring the associated node to meet a certain condition" to deduce "what value the repaired item must meet for the constraint of the associated node to be valid".

[0073] Furthermore, during the reverse derivation, the constraints are processed according to their types: For attribute value range constraints, if the constraint form is " The item to be repaired is... Then the set of values ​​can be directly taken as a range. If the constraint form is " ", and the item being repaired is The value is set to the current shadow repair state. Then, by reverse derivation, we get The allowed value range is If the item being repaired is Then, by reverse derivation, we get The allowed value range is ,in for The current value.

[0074] For equality constraints " When performing reverse derivation, the value of the item being repaired is allowed to degenerate into a single-point value, that is, to take the current value of the other party's attribute.

[0075] For enumeration constraints, during reverse derivation, the allowed set of values ​​is all the legal enumeration values ​​listed in the constraint rules.

[0076] For relation cardinality constraints, during reverse derivation, the allowed value is the set of nodes corresponding to the range of the number of associated entity nodes that satisfy the cardinality constraint.

[0077] Regarding timeliness constraints, when deriving in reverse, the validity period of the associated entity is used as the benchmark to deduce the legal start and end time intervals of the target repair item, and the set of allowed values ​​is the time range that meets the timeliness linkage requirements.

[0078] For state linkage constraints, during reverse derivation, the current legal state of the associated entity is used as the basis to deduce the legal state values ​​of the target repair item, and the set of allowed values ​​is all state enumeration values ​​that satisfy the linkage rules.

[0079] Each backward derivation yields a set of allowed values, denoted as the first... The set of allowed values ​​obtained by reverse derivation of the association constraints is: .

[0080] S3.43. Take the intersection of the allowed value sets corresponding to multiple association constraints to form the reverse allowable domain of the target repair item; specifically, let the target repair item be denoted as... The total number of associated nodes affected by this fix is ​​[number missing]. The constraint rules for each associated node are derived through reverse derivation to obtain information about... The allowed value sets are respectively Then the target repair item Reverse allowed domain Defined as the intersection of these allowed sets of values: ; like If there are no reverse constraints from associated nodes, then The attribute or relationship can be taken from the system's preset default reasonable range. When there is an empty set, it indicates that there is a conflict between the requirements of the various association constraints on the repair item. The candidate repair solution cannot satisfy all association constraints at the same time and is therefore excluded.

[0081] S3.44. Match and verify the candidate repair value with the reverse allowable domain. If the candidate repair value does not belong to the reverse allowable domain, exclude the corresponding candidate repair scheme. Specifically, record the target repair item in the candidate repair scheme. The candidate repair value is Matching and validation checks whether the following expression is true: ; when When this occurs, it indicates that the candidate repair value is acceptable from the perspective of constraints of all associated nodes, and the solution is verified through reverse echo; when or If the value is incorrect, it indicates that although the repair value may satisfy the constraints of the abnormal node itself, it may cause the constraints of a certain related node to be violated or there may be conflicts between constraints. Therefore, the solution is unacceptable and should be excluded.

[0082] S3.45 When a candidate repair value belongs to the reverse allowable domain but still has constraint residuals, compensation operations are performed based on the unmet constraint generation relationship completion, associated state synchronization, or validity period adjustment. After the compensation operation is generated, all compensation actions are virtually executed in a temporary copy of the shadow repair state, and the full constraint verification within the local constraint closure subgraph is re-executed. After confirming that there are no new hard constraint violations, it is then included in the subsequent repair atom group construction stage.

[0083] Specifically, for candidate repair values ​​belonging to the reverse allowable domain, further checks are conducted to determine if any unmet constraint rules still exist in the shadow repair state. If constraint residuals exist, the types of residual constraints and the reasons for their non-metdency are analyzed, and compensation operations are generated according to the following rules: If the residual is due to an unmet relation existence constraint, a relation completion compensation operation is generated. During completion, based on the target entity type specified in the relation existence constraint rules, entity nodes that satisfy the reference constraint conditions are searched within the local constraint closure subgraph or within the same business module. The first matching node found is used as the completion target, and a relation addition action is generated.

[0084] If the residual is due to a failure to meet the state linkage constraint, check the difference between the current state of the associated node and the state required by the linkage rule. If the issue can be resolved by modifying the state of the associated node to the legal state required by the linkage rule, then generate an associated state synchronization compensation operation and execute the state change action with the associated node as the target.

[0085] If the residual is due to a failure to meet the timeliness constraint, check the deviation between the validity period attribute of the abnormal entity or related entity and the constraint rule requirements. If the deviation can be resolved by adjusting the start and end dates of the validity period attribute within a reasonable range, generate a validity period adjustment compensation operation to modify the validity period attribute value to the most recent valid value that satisfies the constraint.

[0086] Compensation operations are associated with main repair actions and are expressed in the form of specific attribute modifications, relationship additions, or status changes.

[0087] S3.5. Combine the main repair action and compensation operation to construct the repair atom group, and perform hierarchical optimization of candidate repair schemes; this step is specifically divided into the following sub-steps: S3.51. Sort and combine the main repair action and the compensation operation that must be executed synchronously according to the business constraint dependency relationship to form an indivisible repair atomic group. In this step, for each candidate repair scheme verified by S3.4, its main repair action is merged with the compensation operation generated by S3.45. The business constraint dependencies between the operations are analyzed to determine the execution order of the operations. Dependencies include: whether the preconditions on which the compensation operation depends are created or modified by the main repair action or other compensation operations; and whether multiple operations modify the same attribute or the same relation edge and have sequential requirements.

[0088] Furthermore, the repair atom group is defined as an ordered sequence of operations: ; In the formula: Indicates the repair of atomic groups; Indicates the number within the group Each operation belongs to one of the following categories: attribute modification, relation addition, relation deletion, relation migration, or state change. Operations in the sequence are topologically ordered according to business constraint dependencies, with the output of preceding operations providing prerequisites for subsequent operations. All operations within a repair atomic group are treated as a whole; during execution, all operations must be executed sequentially and either all succeed or none fail. Partial execution is not allowed.

[0089] S3.52. The candidate repair schemes containing the repair atom group are compared in a hierarchical manner according to the priority of reverse echo residual, degree of non-target constraint disturbance, number of affected business modules, and total number of repair operations, and the optimal scheme is selected.

[0090] Specifically, for multiple candidate repair solutions corresponding to the same abnormal entity, they are compared layer by layer in descending order of priority as follows: The first layer compares the number of reverse echo residuals that still exist after S3.45 compensation for each scheme, that is, the number of association constraints that are not satisfied after the reverse allowable domain verification. Schemes with fewer residuals are given priority. The second layer compares the solutions when the results from the first layer are the same. value, The option with the smaller value is preferred; The third layer, when the results of the first two layers are the same, count the business modules to which the entity nodes involved in the operation in each repair atomic group belong (distinguished by the data source module recorded in S1), and prioritize the scheme with fewer business modules involved. The fourth layer compares the solutions when the results of the first three layers are the same. value, The option with the lower value is preferred.

[0091] Through the above stratified comparison, the optimal solution is selected from the verified candidate repair solutions. If multiple solutions are still tied for optimality after stratified comparison, the solution with the highest source priority is selected as the final solution, based on the priority of the candidate repair value generation source.

[0092] S3.6 Output the optimized standard master dataset and corresponding repair execution package; the repair execution package includes execution preconditions, recovery data, incremental data of the local knowledge graph, and the basis for execution of repair operations. Among them, the execution preconditions are automatically extracted based on the baseline state of the shadow repair simulation, including the current version number of the affected entity nodes, the data lock status of the associated modules, and the processing status of the associated business documents, to ensure that the write-back baseline is consistent with the simulation baseline.

[0093] Specifically, for the optimal repair scheme selected in S3.5, the execution results of the operations in its repair atomic group on the temporary copy are confirmed as the repaired master data state. The attribute values ​​and relation states of each entity node in the local constraint closure subgraph are extracted. Standard master data records within this local scope are generated according to the global master data model format defined in S1. The standard master data records corresponding to all repaired abnormal entities are summarized to form a standard master dataset.

[0094] At the same time, a corresponding repair execution package is generated for this optimal repair solution. The repair execution package contains the following four items: Prerequisites for execution: List the ERP system status conditions that must be confirmed before S4 performs write-back, including the current version number of each affected entity node, the data lock status of related modules, the processing status of related business documents, etc., to ensure that the system status during write-back is consistent with the shadow repair status during repair simulation. Data recovery: Record the original value modified by each operation in the repair atom group, that is, the original value before modification recorded in S3.32, organized in the form of key-value pairs or operation log, for data rollback to be performed when S4 write-back fails; Local knowledge graph incremental data: The graph changes involved in this repair are recorded in the form of a graph change operation sequence. Each change record includes the operation type (node ​​addition, node attribute modification, relation edge addition, relation edge deletion), operation object identifier, and values ​​before and after modification, so that S4 can perform incremental updates on the knowledge graph after completing the master data write-back. The basis for remediation operations is to record the abnormal constraint identifier, constraint verification result, reverse echo verification result, and disturbance budget vector corresponding to each remediation action, forming a traceable basis for the remediation operation to support subsequent audits and compliance reviews.

[0095] It should be added that S3 completes the full cleaning and verification of the abnormal master data, transforming the abnormal data in the knowledge graph constructed in S2 into a verified standard master dataset and a structured repair execution package. This provides directly executable operation instructions and data foundation for S4's cross-module master data write-back and incremental graph updates. The entire simulation process is completed on a temporary copy, and the original knowledge graph and ERP system production data remain unmodified in the S3 stage. The constraint disturbance budget vector is rigidly filtered out using independent components, and the reverse echo verification performs secondary compliance confirmation from the perspective of associated nodes through intersection operations and membership relationship judgments. Repair atomic groups ensure the atomicity and orderliness of repair operations, and hierarchical optimization balances repair quality and operational costs. These mechanisms together ensure the compliance of automatic repair results at the business constraint level and the reliability at the engineering execution level.

[0096] S4, Master Data Synchronization and Knowledge Graph Update: Based on the standard master dataset and repair execution package, this step performs cross-module master data write-back and incremental updates to the ERP master data domain knowledge graph. Specifically, it implements the repair scheme generated in S3 from the simulation environment into the ERP production system and knowledge graph. The input to S4 is the standard master dataset and repair execution package output by S3. The result of S4 is writing the cleaned and repaired master data back to each business module of the ERP system and synchronously updating the knowledge graph to ensure consistency between the knowledge graph and the master data state in the ERP system. Each sub-step of S4 can be executed by a data processing server connected to the ERP system database and the knowledge graph database. This includes the following steps: S4.1. Based on the preconditions in the repair execution package, review the current master data status of the ERP system. Once the preconditions are confirmed to be met, initiate the write-back process. Specifically, read the preconditions from the repair execution package, and initiate status queries to the ERP system item by item to obtain the current version number of each affected entity node, the data lock status of related modules, and the processing status of related business documents. Compare the current status obtained with the status recorded in the preconditions. If all conditions match, it indicates that the current status of the ERP system is consistent with the baseline status during the S3 repair simulation, and the write-back process can be safely initiated. If there are mismatches, it indicates that the relevant data in the ERP system has been modified by other operations during the S3 simulation, and write-back may lead to data inconsistency. In this case, postpone the write-back, mark the repair execution package as pending review, and output it to the manual processing queue for further judgment.

[0097] S4.2. Perform master data write-back operations for each business module of the ERP system according to the operation execution order of the repair atomic group in the repair execution package. If the critical operation fails, the executed operation shall be undone according to the recovery data in the repair execution package. In this step, repair atomic groups are read from the repair execution package. First, based on the local and global encoding mapping relationship preserved in S1.2, the global encoding is mapped to the local encoding of the target business module, and then executed sequentially according to the order of operations within the group. Each operation is mapped to a corresponding database operation instruction based on its type: attribute modification operations are mapped to UPDATE statements on the corresponding fields in the master data table of the corresponding module; relation addition operations are mapped to INSERT new related records in the related table; relation deletion operations are mapped to DELETE statements on the corresponding records in the related table; status change operations are mapped to UPDATE statements on the status fields; relation migration operations are composed of two database operations, relation deletion and relation addition, and are executed within the same transaction.

[0098] During operation execution, operations that affect master data consistency and may lead to incomplete data after failure are marked as critical operations. Critical operations include at least: modification operations on primary key fields or unique identifier fields in the master data table, clearing or modifying required fields, and repairing prerequisite operations that subsequent operations in an atomic group depend on.

[0099] When any critical operation fails, a rollback process is triggered: Following the reverse order of the executed operations, reverse recovery operations are performed record by record based on the recovery data in the repair execution package. Modified field values ​​are restored to their original values ​​before modification, newly added relationship records are deleted, and deleted relationship records are re-inserted, until all executed operations (including critical and non-critical operations) are undone. After the rollback is complete, the repair execution package is marked as a write-back failure and output to the manual processing queue.

[0100] For non-critical operations that fail, record the failure details and continue with subsequent operations. Once the repair atom group has finished executing, output a list of failed operations for manual processing.

[0101] S4.3 After the master data write-back is successfully executed, the incremental update of the ERP master data domain knowledge graph is completed based on the incremental data of the local knowledge graph in the repair execution package. The incremental update covers changes in entity node attributes and additions, deletions and modifications of relationship edges, but does not involve overall changes to the constraint rule layer. The constraint rules are updated separately according to the synchronization cycle of business constraint metadata.

[0102] Specifically, after confirming that all operations in the repair atomic group have been successfully executed and the transaction has been committed, the incremental local knowledge graph data in the repair execution package is read. The incremental data is organized in the form of a sequence of graph change operations, with each change record containing the operation type, the operation object identifier, and the values ​​before and after the modification. Following the order of the change records, graph update operations are executed one by one in the graph database: for change records of node attribute modification type, the corresponding entity node is located and the value of the specified attribute label is updated; for change records of relation edge addition type, a new relation edge is created between the two corresponding entity nodes and the relation attribute is attached; for change records of relation edge deletion type, the corresponding relation edge is located and deleted.

[0103] After the incremental update is completed, the attribute values ​​and relationship status of the corresponding entity nodes in the knowledge graph are consistent with the master data that has been written back in each business module of the ERP. The knowledge graph constructed by S2 is updated synchronously with the repair results of S3 and can be used for subsequent cleaning and verification tasks.

[0104] It should be added that S4, through three sub-steps—precondition review, atomic write-back and failure rollback, and incremental graph update—safely and consistently synchronizes the repair simulation results of S3 to the ERP production system and the knowledge graph. The transactional execution of repair atomic groups and the failure rollback mechanism for critical operations ensure data consistency during the cross-module master data write-back process. The use of incremental data from local knowledge graphs avoids the computational overhead of full graph reconstruction, enabling the knowledge graph to maintain synchronization with the ERP system's master data state at a relatively low update cost.

[0105] Those skilled in the art will understand that the process of implementing all or part of the steps of the above embodiments can be carried out by hardware or by a program instructing the relevant hardware.

[0106] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely preferred examples and are not intended to limit the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the claimed invention.

Claims

1. A knowledge graph-based intelligent cleaning and consistency verification method for ERP master data, characterized in that, Includes the following steps: S1. Data Acquisition and Preprocessing: Collect the original master data and business constraint metadata of each business module of the ERP system, and perform standardized preprocessing on the original master data and business constraint metadata to obtain preprocessed master data and business constraint metadata. S2. Master Data Knowledge Graph Construction: Based on the preprocessed master data and business constraint metadata, an ERP master data domain knowledge graph is constructed through entity node mapping, business relationship modeling, and constraint rule graphing. S3. Intelligent cleaning and consistency verification of master data: Based on the knowledge graph of ERP master data domain, abnormal master data is cleaned and its consistency is verified through the shadow repair chain mechanism based on constraint disturbance budget and reverse echo verification, so as to obtain standard master dataset and repair execution package. S4. Master Data Synchronization and Knowledge Graph Update: Based on the standard master dataset and repair execution package, perform cross-module master data write-back and incremental update of the ERP master data domain knowledge graph.

2. The method for intelligent cleaning and consistency verification of ERP master data based on knowledge graphs according to claim 1, characterized in that, The data acquisition and standardization preprocessing in S1 includes the following steps: S1.1 Extract the original master data and the corresponding business constraint metadata from each business module of the ERP system to complete the unified collection of multi-source heterogeneous data; S1.

2. Perform metadata field mapping, data format normalization, and encoding system unification on the collected raw master data to obtain standardized master data. S1.

3. Perform constraint type classification, associated entity attribute annotation and constraint rule structuring on the collected business constraint metadata to obtain standardized business constraint metadata.

3. The method for intelligent cleaning and consistency verification of ERP master data based on knowledge graphs according to claim 1, characterized in that, The construction of the master data knowledge graph in S2 includes the following steps: S2.1 Based on the preprocessed master data, extract master data entities according to entity category, map each master data entry to entity nodes of the knowledge graph, and attach attribute labels and attribute values ​​to the corresponding entity nodes; S2.2 Based on the business association logic carried by the preprocessed master data, identify the business association relationships between different entity nodes, generate entity-relationship-entity triples, and complete the construction of the graph relationship layer; S2.3 Based on the preprocessed business constraint metadata, map and bind various business constraint rules to entity node attributes and inter-entity association triples to complete the constraint rule graph processing; S2.4 Perform structural compliance verification on the completed graph. After the verification is passed, output the ERP master data domain knowledge graph.

4. The method for intelligent cleaning and consistency verification of ERP master data based on knowledge graphs according to claim 1, characterized in that, The master data intelligent cleaning and consistency verification in S3 includes the following steps: S3.1 Based on the domain knowledge graph of ERP master data, identify abnormal master data entities and generate corresponding candidate repair values; S3.2 For each abnormal master data entity, extract the corresponding local constraint closure subgraph; S3.3 Execute candidate repair actions in a temporary copy of the local constraint closed subgraph, generate shadow repair states and calculate the structured constraint perturbation budget, complete the initial screening of candidate repair schemes, and output the candidate repair schemes that pass the initial screening and their corresponding shadow repair states. S3.

4. Based on the shadow repair status that has passed the initial screening, perform reverse echo verification and generate the corresponding compensation operation; S3.

5. Combine the main repair action and compensation operation to construct the repair atom group, and perform hierarchical optimization of candidate repair schemes; S3.6 Output the optimized standard master dataset and the corresponding repair execution package; the repair execution package includes execution preconditions, recovery data, local knowledge graph incremental data and the basis for repair operation execution.

5. The method for intelligent cleaning and consistency verification of ERP master data based on knowledge graphs according to claim 4, characterized in that, The extraction of the local constraint closure subgraph in S3.2 includes the following steps: S3.

21. Taking the entity node corresponding to the abnormal master data entity as the central node, sort out all business constraint rules and constraint transmission paths associated with the central node; S3.

22. Traverse the neighborhood entity nodes and associated triples along the constraint propagation path, and collect all associated nodes, attributes and relation edges that participate in constraint verification; S3.

23. Trim redundant nodes and relation edges that are not constrained to the current anomaly repair scenario to form a locally constrained closed subgraph that covers all associated constraints.

6. The method for intelligent cleaning and consistency verification of ERP master data based on knowledge graphs according to claim 4, characterized in that, The shadow repair state generation and structured constraint perturbation budget calculation in S3.3 include the following steps: S3.

31. Generate a local, independent temporary copy of the locally constrained closure subgraph without modifying the original ERP master data domain knowledge graph; S3.

32. Convert each candidate repair value into a candidate repair action for attribute modification, relationship addition, relationship deletion, relationship migration or state change, and virtually execute all candidate repair actions in a temporary copy to generate the corresponding shadow repair state. S3.

33. In the shadow repair state, re-verify the attribute value constraints, relationship existence constraints, relationship cardinality constraints, validity period constraints, and state linkage constraints, and compare the changes in constraint residuals before and after repair. S3.

34. Calculate the change in constraints according to the type of constraint and generate a structured constraint disturbance budget; S3.

35. Based on the structured constraint perturbation budget, candidate repair schemes that do not conform to the screening rules corresponding to the structured constraint perturbation budget are screened out, and the candidate repair schemes that pass the initial screening are output.

7. The method for intelligent cleaning and consistency verification of ERP master data based on knowledge graphs according to claim 6, characterized in that, The structured constraint perturbation budget generation and scheme elimination in S3.34 includes the following steps: S3.

341. Count the number of newly added hard constraint violations, the number of key constraint unverifiable items, the number of non-target relationship disturbances, and the total number of repair operations in the form of independent components, and construct a four-dimensional structured constraint disturbance budget vector. Do not weight and merge the components. The structured constraint perturbation budget vector satisfies the following relationship: ； In the formula: This is the budget vector for the structured constraint perturbation. To increase the number of hard constraint violations, The number of unverifiable items for critical constraints. This represents the number of non-target relational perturbations. Total number of repair operations; S3.

342. When the number of newly added hard constraint violations is greater than zero or the number of critical constraint unverifiable items is greater than zero, the corresponding candidate repair scheme is directly excluded. S3.

343. The number of non-target relationship disturbances and the total number of repair operations are retained as independent evaluation dimensions for subsequent hierarchical optimization.

8. The method for intelligent cleaning and consistency verification of ERP master data based on knowledge graphs according to claim 4, characterized in that, The reverse echo verification and compensation operation in S3.4 includes the following steps: S3.

41. Locate the associated entity nodes and end nodes of the relationship chain affected by the candidate repair actions, and sort out the business constraint rules corresponding to each node; S3.

42. Based on the business constraint rules of each associated node, reversely deduce the set of allowed values ​​corresponding to the target repair attribute or target repair relationship; S3.

43. Take the intersection of the allowed value sets corresponding to multiple associated constraints to form the reverse allowable domain of the target repair item; S3.

44. Match and verify the candidate repair value with the reverse allowable field. If the candidate repair value does not belong to the reverse allowable field, exclude the corresponding candidate repair scheme. S3.45 When a candidate repair value belongs to the reverse allowable domain but still has constraint residuals, compensation operations are performed based on the unmet constraints to generate relationship completion, associated state synchronization, or validity period adjustment.

9. The method for intelligent cleaning and consistency verification of ERP master data based on knowledge graphs according to claim 4, characterized in that, The construction of the repair atom set and the hierarchical selection of candidate repair schemes in S3.5 include the following steps: S3.

51. Sort and combine the main repair action and the compensation operation that must be executed synchronously according to the business constraint dependency relationship to form an indivisible repair atomic group. S3.

52. The candidate repair schemes containing the repair atom group are compared in a hierarchical manner according to the priority of reverse echo residual, degree of non-target constraint disturbance, number of affected business modules, and total number of repair operations, and the optimal scheme is selected.

10. The method for intelligent cleaning and consistency verification of ERP master data based on knowledge graphs according to claim 1, characterized in that, The master data synchronization and map update in S4 include the following steps: S4.

1. Based on the execution preconditions in the repair execution package, review the current master data status of the ERP system, and start the write-back process after confirming that the execution preconditions are met. S4.

2. Perform master data write-back operations for each business module of the ERP system according to the operation execution order of the repair atomic group in the repair execution package. If the critical operation fails, the executed operation shall be undone according to the recovery data in the repair execution package. S4.3 After the master data write-back is successfully executed, the incremental update of the ERP master data domain knowledge graph is completed based on the incremental data of the local knowledge graph in the repair execution package.

Images