Data restoration methods, equipment, and storage media for constraining propagation and tracing the source of data.

Abstract

This application discloses a data repair method, device, and storage medium for constraint propagation and query tracing, comprising: splitting candidate modifications into patch atoms and generating patch write sets and patch reverse indexes; triggering constraint instance iterative expansion with patch write sets, recording directed propagation precursor relationships, and forming the scope of constraint propagation impact; generating query tracing slices and query backtracking indexes based on the location of affected data; executing patches in isolated verification, performing constraint checks and query deviation verification, and merging them into a joint verification result; when verification fails, tracing back to the data location in the patch write set according to the failure type along the directed propagation precursor relationship or the query backtracking index, locating the patch atom through the patch reverse index, adjusting and re-executing until the deviation conditions are met. This application ensures complete capture of constraint impact through constraint propagation delimitation triggered by patch write sets and iterative expansion, and accurately locates the root cause of failure by combining dual-track backtracking, thereby improving the accuracy and reliability of cross-table repair.

Description

Technical Field

[0001] This application relates to the technical field of database repair, and in particular to a data repair method, device and storage medium for constraint propagation and query tracing. Background Technology

[0002] In relational databases, foreign keys, uniqueness constraints, functional dependencies, containment dependencies, and derivation relationships work together to maintain data consistency across tables. During data acquisition, business migration, or multi-source integration, the same business object is often distributed across multiple relational tables. Repairing a single field or tuple can affect constraint instances in other tables along with constraint relationships, and may also change the query results formed by joining, filtering, grouping, or aggregation.

[0003] Database repair solutions typically rely on integrity constraint detection to identify violations and select a repair method based on repair cost or rule priority. In cross-table scenarios, performing a full re-examination of all constraint instances introduces a large amount of redundant calculations unrelated to candidate modifications; if only the data locations directly written by candidate modifications are checked, secondary violations caused by cross-table constraint propagation may be missed.

[0004] Query tracing techniques can explain the source of query results or locate the underlying data corresponding to the result items, but they are usually used independently of the data repair process. If constraint checks and query verifications are performed separately and lack a unified data location association, after verification failure, only failed constraints or failed queries are often obtained, making it difficult to reverse-engineer which modification unit among the candidate modifications participated in the failure verification task.

[0005] After verification fails, the field to be adjusted is selected based on the direct read position of the failed constraint or failed query, without simultaneously preserving the propagation path of the candidate modification triggering constraint instance's hierarchical expansion and the contribution path from the query result item to the basic data position. When there are intermediate constraint instances or query operators between the failed task and the candidate modification, only the intersection of the failed task's direct read position and the patch write position is calculated, which may miss the modification units associated with the failed task through intermediate constraint instances or query operators.

[0006] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0007] The main purpose of this application is to provide a data repair method, device and storage medium for constraint propagation and query tracing, which aims to solve the technical problems of insufficient accuracy and reliability of cross-table repair caused by the difficulty in effectively defining the verification scope, the difficulty in fully capturing the impact of constraints and the difficulty in locating failure-related patches in existing cross-table data repair.

[0008] To achieve the above objectives, this application proposes a data repair method for constraint propagation and query tracing, the method comprising: Candidate modifications are broken down into patch atoms. A unified data location encoding is used to generate the write position of each patch atom to form a patch write set. A patch inverse index is generated based on the write position. Each patch atom is a basic modification unit grouped by the current field for a single relation table, a single tuple identifier, and a modification type. The modification type includes add, delete, and update types. The unified data location encoding consists of a relation table identifier, a tuple identifier, and a field identifier. The patch inverse index is an index pointing from a data location to one or more patch atoms written to that data location. Before the initial verification, the original set of repair targets with executable acceptance predicates is recorded, and this original set of repair targets remains unchanged during subsequent patch adjustments and re-verification. Using the patch write set as the initial seed, the set of affected constraint instances and the set of affected data locations are iteratively expanded until they stabilize to form the constraint propagation influence range. In each iteration, a new constraint instance is triggered by the current set of affected data locations to be added to the set of affected constraint instances, and the set of affected data locations is expanded by the data locations read by the newly added constraint instances. During the iteration process, the directed propagation predecessor relationship between data locations and constraint instances is recorded. Based on the set of affected data locations, the contributing paths leading to the protected result items are filtered in each query source graph, and query source slices and query backtracking indexes are generated based on the contributing paths; An isolation verification state is established based on the current state of the target database. The query output and query source information of each protected query in the state before patch execution are recorded. In the isolation verification state, patch atoms are executed to obtain the state after patch execution, and the query output and corresponding query source information of each protected query in the state after patch execution are obtained. According to the query output before and after patch execution, the result items are aligned, and the result items with added, disappeared, changed values, or changed sorting are identified. Based on the contribution path of the corresponding result items in the query source graph before and after patch execution, the query source slice and query backtracking index are supplemented. Constraint checks are performed on the affected constraint instances in the scope of constraint propagation. Normalized query deviation verification is performed on the protected result items in the supplemented query source slice relative to the query output benchmark before patch execution. Based on whether the necessary binding is complete, whether the original repair goal is achieved, whether the verification task set is not empty, whether all necessary verification tasks are completed and the results are valid, whether the residual constraint violation set and the newly added hard constraint violation set are both empty, and whether each query deviation does not exceed the corresponding threshold, a joint verification result is formed. If the joint verification result passes, the patch atom is submitted to the target database according to the submission verification rules, and the repair result and verification record are output after successful submission. If the joint verification result indicates that there is a verification failure, if the necessary binding is incomplete, the target cannot be verified, or a traceable failure task cannot be obtained, the current repair is terminated and a failure record is output. Otherwise, the traceability path is determined according to the failed verification task in the joint verification result, and the data position of the patch write set is traced back based on the traceability path. If the failed verification task is a constraint check failure, the data position in the patch write set is traced back along the directed propagation predecessor relationship starting from the corresponding constraint instance node. If the failed verification task is a query deviation failure, the data position in the patch write set is traced back along the query backtracking index in the query traceability slice starting from the changed result item node. The patch atom corresponding to the data location is located using the patch inverse index. The patch atom is adjusted, and a new patch write set and patch inverse index are generated. Based on the regenerated patch write set and patch inverse index, constraint instance iteration triggering, query tracing slice filtering, and isolation joint verification are re-executed until the joint verification result passes or a preset stopping condition is met. When the joint verification result passes, the iterative adjustment process is terminated, the patch is submitted according to the submission verification rules, and the repair result and verification record are output upon successful submission. When the joint verification result fails and the preset stopping condition is met, or the submission fails, the current repair is terminated, uncommitted modifications are rolled back, and a failure record is output. The submission verification rules include verifying the target database version, field values ​​before patch modification, integrity constraint configuration version, and protected query configuration version within the same commit transaction or a commit mechanism with equivalent atomic verification capabilities. If any of these are inconsistent, the original verification result is prohibited from being used, and the isolation verification state is re-established and re-verified.

[0009] In one embodiment, the steps of splitting candidate modifications into patch atoms, generating write positions for each patch atom using unified data location encoding to form a patch write set, and generating patch inverse indexes based on the write positions include: Obtain the candidate modification set, and determine the corresponding relation table identifier based on the target relation table of each candidate modification; During the initial construction, candidate modifications with the same relation table identifier, the same tuple identifier, and the same modification type are merged. For multiple modified field values ​​of the same field after merging, the final modified value is retained according to the preset patch execution order to form a set of effective patch atoms. The preset patch execution order is determined by the input timing of each candidate modification or the priority of the configuration. Based on the relation table identifier, modified tuple identifier, and modified field identifier that each patch atom acts upon, determine the set of data write locations corresponding to each patch atom; Perform a union operation on the set of data write locations of all patch atoms to form the patch write set; For each data location in the patch write set, all patch atoms written to that data location are recorded to form the patch inverse index. When the same data location is written by multiple patch atoms, the patch inverse index records the identifier and execution order of each patch atom according to the preset patch execution order.

[0010] In one embodiment, before the step of using the patch write set as an initial seed to iteratively expand the set of affected constraint instances and the set of affected data locations until stable to form the constraint propagation influence range, the method further includes: Each integrity constraint in the integrity constraint set is bound to a combination of tuples in the current database state that satisfy the variable binding conditions to form an existing constraint instance. The integrity constraints include at least one of foreign key constraints, uniqueness constraints, functional dependencies, containment dependencies, and range constraints. The variable binding conditions are the matching conditions between the variables in the integrity constraints and the tuple fields. Based on the modification type, field value before modification, and field value after modification of the patch atom, incremental binding is performed on the variable binding conditions of the integrity constraint. Constraint instances that are added, disappear, or whose read positions change due to the patch atom are merged with the existing constraint instances to form a set of valid constraint instances. The change in read position refers to the change in the set of data positions read by the constraint instance when it performs constraint judgment due to the patch atom. For each valid constraint instance, record the set of data locations read when making constraint judgments; perform binding integrity verification on records that lack necessary variable bindings or whose read locations cannot be determined, and fail the verification if the record cannot be proven to be unrelated to the current affected scope and the original repair target and has not yet been resolved.

[0011] In one embodiment, the step of using the patch write set as an initial seed to iteratively expand the set of affected constraint instances and the set of affected data locations until stable to form the constraint propagation impact range includes: Using the patch write set as the initial trigger input, determine the initial set of affected constraint instances and the initial set of affected data locations. The initial set of affected constraint instances consists of constraint instances that read at least one data location from the patch write set, and the initial set of affected data locations consists of the union of the data locations read by each constraint instance in the patch write set and the initial set of affected constraint instances. During a certain round of iteration, determine the constraint instance that reads at least one data location in the current set of affected data locations and has not yet been included in the current set of affected constraint instances, and add the constraint instance to the updated set of affected constraint instances. In each constraint instance of the updated set of affected constraint instances, read the data locations that have not yet been included in the current set of affected data locations, and add the data locations to the updated set of affected data locations; The iteration stops when both the set of affected constraint instances and the set of affected data locations no longer change, and the set at which the iteration stops is taken as the range of influence of the constraint propagation.

[0012] In one embodiment, the step of recording the directed propagation predecessor relationship between data location and constraint instance during the iteration process includes: During the iteration process, the triggering events based on the data location and the constraint instance are recorded as first-type directed propagation precursor edges and second-type directed propagation precursor edges. Specifically, in the initial triggering phase and each iteration expansion phase, when the data location triggers the constraint instance to enter the set of affected constraint instances, the first-type directed propagation precursor edge between the data location and the constraint instance is recorded. The data relationship of the data location read by the constraint instance being included in the set of affected data locations is recorded as the second-type directed propagation precursor edge. When there are multiple triggering data locations for the same newly added constraint instance, all first-type directed propagation precursor edges are retained. The first type of directed propagation predecessor edge and the second type of directed propagation predecessor edge recorded are used to generate the directed propagation predecessor relationship.

[0013] In one embodiment, the step of filtering contributing paths to protected result items in each query origination graph based on the set of affected data locations, and generating query origination slices and query backtracking indexes based on the contributing paths, includes: Obtain a pre-configured set of protected queries, wherein the set of protected queries contains at least one protected query; For each protected query in the protected query set, obtain the query origin graph of the protected query in the current state of the target database. The query origin graph includes basic data location nodes, query operator nodes, intermediate result nodes, and protected result item nodes. Based on the set of affected data locations, in each query tracing graph, determine the query graph nodes where the set of basic contribution data locations of any query graph node intersects with the set of affected data locations, and use the determined query graph nodes as affected seed nodes; wherein, the set of basic contribution data locations is the set of all basic data locations that the corresponding node depends on or contributes to; Traverse from the affected seed node along the direction corresponding to the data contribution edge and the execution dependency edge to the protected result item node, and include the nodes located on the corresponding contribution path into the downstream reachable node set. The data contribution edge represents the flow relationship of data from the basic data position to the query result direction, and the execution dependency edge represents the execution dependency relationship between query operators. Based on the affected seed nodes and the set of downstream reachable nodes, a subgraph induced by the affected seed nodes and the set of downstream reachable nodes is extracted from the query origin graph as the query origin slice; Record the protected result item node identifier, the mapping relationship between the basic data location node and the unified data location code, and the direction of each data contribution edge and execution dependency edge within the slice for each query traceability slice, and establish the query backtracking index that accesses the basic data location node from the protected result item node.

[0014] In one embodiment, the step of executing patch atoms in the isolated verification state to obtain the post-patch execution state includes: An isolation verification state is established based on the current state of the target database, and each patch atom is executed sequentially according to a preset execution order based on the isolation verification state. After all patch atomic operations are completed, the final database state of the isolation verification state is taken as the post-patch state, wherein the isolation verification state is any one of the following isolation forms: database snapshot, transaction copy, or database branch.

[0015] In one embodiment, the steps of locating the patch atom corresponding to the data position via the patch inverse index, adjusting the patch atom, regenerating the patch write set and patch inverse index, and re-executing constraint instance iteration triggering, filtering query tracing slices based on the regenerated patch write set and patch inverse index, and executing the adjusted patch atom, until the joint verification result passes or a preset stopping condition is met, include: The constraint propagation influence range, the directed propagation precursor relationship, the query source tracing slice, the query backtracking index, the joint verification result, the constraint check result, and the query deviation verification result formed before the adjustment are marked as invalid; The patch write set and patch inverse index are regenerated based on the adjusted patch atoms; the original set of repair targets and their acceptance predicates recorded before the first verification are retained, and all original repair targets are re-verified after each round of isolation execution; Using the newly generated patch write set as the initial seed, the iterative expansion of the constraint instance is re-executed to reshape the constraint propagation influence range, and the directed propagation predecessor relationship is re-recorded; Based on the set of affected data locations in the newly formed constraint propagation impact range, the contributing paths are re-selected in each query source graph to regenerate query source slices and query backtracking indexes. Based on the current confirmed state of the target database, the isolation verification state is re-established, and the adjusted patch atoms are executed in it. The constraint checks are re-executed on the currently affected constraint instances, and the query deviation verification is re-executed to form a new joint verification result. When the new joint verification result fails and the preset stopping condition is not met, the failed verification task is re-identified, the associated patch atom is located and adjusted, and the above steps of regeneration and re-verification are repeated. When the new joint verification result passes, the iteration stops, and the repair result and verification record are output after the submission is verified and successfully completed. When the new joint verification result fails and the preset stopping condition is met, or the submission fails, the current repair is terminated and the unsubmitted modifications are rolled back, and the failure record is output.

[0016] Furthermore, to achieve the above objectives, this application also proposes a data repair device for constraint propagation and query tracing, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the data repair method for constraint propagation and query tracing as described above.

[0017] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the constraint propagation and query tracing data repair method described above.

[0018] One or more technical solutions proposed in this application have at least the following technical effects: The technical solution of this application decomposes candidate modifications into patch atoms, uses unified data location encoding to generate the write position of each patch atom to form a patch write set, and generates a patch reverse index based on the write position; uses the patch write set as an initial seed, iteratively expands the set of affected constraint instances and the set of affected data locations until stable to form the constraint propagation influence range, wherein each iteration triggers a new constraint instance to be added to the set of affected constraint instances by the current set of affected data locations, and expands the set of affected data locations by the data location read by the newly added constraint instance, and records the directed propagation predecessor relationship between data location and constraint instance during the iteration process; based on the set of affected data locations, the contribution path leading to the protected result item is screened in each query tracing graph, and a query tracing slice and a query backtracking index are generated based on the contribution path; in the isolation verification state, the patch atom is executed to obtain the state after patch execution, and the difference between the state after patch execution and the state before patch execution is used as the judgment basis to perform constraint checks on the affected constraint instances in the constraint propagation influence range, and the protected items in the query tracing slice are checked. The result item performs query deviation verification, merging the constraint check result and the query deviation verification result into a joint verification result. A tracing path is determined based on the failed verification tasks in the joint verification result. The data location of the patch write set is traced back along the tracing path. If the failed verification task is a constraint check failure, the data location in the patch write set is traced back along the directed propagation predecessor relationship, starting from the corresponding constraint instance node. If the failed verification task is a query deviation failure, the data location in the patch write set is traced back along the query backtracking index in the query source slice, starting from the changed result item node. The patch atom corresponding to the data location is located using the patch backtracking index. After adjusting the patch atom, the patch write set and patch backtracking index are regenerated. Based on the regenerated patch write set and patch backtracking index, constraint instance iteration triggering and query source slice filtering are re-executed, and the adjusted patch atom is executed until the joint verification result passes or a preset stopping condition is met. After successful verification, a submission check and repair result are output. If the stopping condition is met but verification fails, the process is rolled back and a failure record is output.

[0019] The technical solution of this application incorporates candidate modifications, constraint instances, and query results in cross-table repair into a unified data location tracking system, realizing dynamic bounding of constraint propagation, joint verification of constraints and queries, and location of failure-related patches, providing a basis for adjustment and re-verification of cross-table repair. Attached Figure Description

[0020] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0021] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 This is a flowchart illustrating the first embodiment of the data repair method for constrained propagation and query tracing of the present invention; Figure 2 This is a detailed step diagram of step S10 in one embodiment; Figure 3 This is a detailed step diagram of step S20 in one embodiment; Figure 4 This is a detailed step diagram of step S30 in one embodiment; Figure 5 This is a detailed step diagram of step S40 in one embodiment; Figure 6 This is a flowchart illustrating the second embodiment of the data repair method for constrained propagation and query tracing of the present invention; Figure 7 This is a flowchart illustrating the implementation of the data repair method for constrained propagation and query tracing of the present invention. Figure 8 This is a schematic diagram of the architecture of the data repair method for constraint propagation and query tracing of the present invention; Figure 9 This is a schematic diagram of the device structure of the hardware operating environment involved in the data repair method for constraint propagation and query tracing in this embodiment of the invention.

[0023] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0024] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0025] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0026] In the field of cross-table data repair, the verification and backtracking of candidate modifications are mainly carried out along two independent technical paths: constraint violation detection and query result tracing. However, there is a lack of a unified data location association mechanism between the two paths, making it difficult to effectively limit the scope of verification and locate the relevant patches for failure.

[0027] Existing remediation solutions typically rely on integrity constraints to detect violations and select a remediation method based on remediation cost or rule priority; query tracing techniques are used to interpret the source of query results or locate the underlying data corresponding to result items. However, in cross-table scenarios, performing a full re-examination on all constraint instances introduces a large amount of redundant calculations unrelated to candidate modifications; if only the data location directly written by candidate modifications is checked, secondary violations caused by cross-table constraint propagation are easily missed. Constraint checks and query verifications are performed separately and lack a unified data location interface. After verification failure, only failed constraints or failed queries are usually obtained, making it difficult to reverse-engineer the specific modification unit in the candidate modifications.

[0028] Comprehensive analysis reveals that the core dilemma faced by the above technical approaches lies in the fact that the propagation and contribution paths among candidate modifications, constraint instances, and query results cannot be continuously tracked and bidirectionally traced. This results in the inability to effectively define the scope of verification, the easy omission of secondary violations, the difficulty in locating failure-related patches, and insufficient accuracy and reliability of cross-table repair.

[0029] To address the aforementioned deficiencies, this application proposes a data repair method for constraint propagation and query tracing. This method triggers iterative expansion of constraint instances to stability through patch write sets, forming the scope of constraint propagation to define the verification boundary and recording the directed propagation precursor relationships. The location of affected data drives the generation of query tracing slices and the establishment of a query backtracking index. In the isolated verification state, patch atoms are executed, performing constraint checks on affected constraint instances and query deviation verification on protected result items in the query tracing slice, forming a joint verification result. If verification fails, constraint check failures are traced back along the directed propagation precursor relationships, and query deviation failures are traced back along the query backtracking index. The associated patch atoms are located via the patch backtracking index, adjusted, and the above steps are re-executed until the joint verification result passes or a preset stopping condition is met. Upon successful verification, a submission check is completed, and the repair result is output after submission. If the stopping condition is met but verification fails, the process is rolled back and a failure record is output.

[0030] Through the aforementioned technical means, this application incorporates candidate modifications, constraint instances, and query results in cross-table repair into a unified data location tracking system, realizing dynamic bounding of constraint propagation, joint verification of constraints and queries, and location of failure-related patches, providing a basis for the adjustment and re-verification of cross-table repair.

[0031] Based on this, embodiments of this application provide a data repair method for constraint propagation and query tracing, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the constraint propagation and query tracing data repair method of the present invention. In this embodiment, the constraint propagation and query tracing data repair method includes steps S10 to S60: Step S10: The candidate modification is split into patch atoms. A unified data location encoding is used to generate the write position of each patch atom to form a patch write set. A patch inverse index is generated based on the write position. The patch atom is a basic modification unit formed by grouping according to the current field for a single relation table, a single tuple identifier, and a modification type. The modification type includes addition type, deletion type, and update type. The unified data location encoding consists of relation table identifier, tuple identifier, and field identifier. The patch inverse index is an index pointing from the data position to one or more patch atoms written to that data position. Before the first verification, the original repair target set with executable acceptance predicates is recorded, and the original repair target set remains unchanged during subsequent patch adjustment and re-verification. In this embodiment, candidate modifications are broken down into patch atoms. A candidate modification refers to a tuple addition, tuple deletion, or field update operation performed on the relational database, which may involve multiple relation tables, multiple tuples, and multiple fields. To accurately track the impact of each modification operation and subsequently locate related patches for failures, these candidate modifications need to be decomposed into basic modification units at the current field grouping granularity, i.e., patch atoms. A patch atom corresponds to a single relation table, a single tuple identifier, and a modification type, including addition, deletion, and update. For update-type patch atoms, it records both the set of field values ​​before and after the modification; for addition-type, the set of field values ​​before modification is empty; for deletion-type, the set of field values ​​after modification is empty.

[0032] The system reads the set of relational tables, integrity constraints, protected queries, and corresponding query tracing information from the relational database to be repaired. It also reads the candidate modification set, grouping them into a valid patch atom set based on the same relational table, tuple identifier, and modification type when the set is not empty. When the same merged object contains multiple candidate values ​​for the same field, the last modified value is retained according to the preset patch execution order, and intermediate value records are saved according to the same execution order. Before the initial verification, the system records the original repair target set that must be completed in this repair. Each objective must at least record its identifier, corresponding constraints or data conditions, relevant tuple location information, and executable acceptance predicates. The original set of repair objectives remains fixed throughout this adjustment and re-verification process and does not shrink due to patch atom revocation, field splitting, or field value adjustment. In each round, the acceptance predicates of all objectives are re-executed in the current isolated execution state. An objective achievement flag is only displayed when all objectives have completed verification and met the requirements. Only take 1; if the objective is not met, the verification cannot be performed, or the objective set is empty or missing. Set to 0. Whether the disappearance of the target object signifies the completion of the target is explicitly defined by the pre-recorded acceptance predicate; it will not automatically be considered successful based on the constraint not being applicable.

[0033] Each patch atom is recorded using the following structure: ; in, Indicates the type of modification. The identifier representing the modified relation table. Indicates the identifier of the modified tuple. This represents the set of fields that have been modified. and These represent the sets of field values ​​before and after modification, recorded in the order of the fields in the modified field set; (Add operation) For an empty set, the deletion operation... This is an empty set of values. The sets of field values ​​before and after the update operation correspond to the fields in the set of modified fields, respectively. The field sets for adding or deleting patches cover all fields of the corresponding tuples. Incidental writes caused by candidate modifications are also included in the patch write set. If the write range cannot be fully determined, the patch is not automatically committed.

[0034] A unified data location code, consisting of a relational table identifier, a tuple identifier, and a field identifier, is used to determine the write location of each patch atom. This encoding method ensures that different fields in different relational tables can be uniquely located at the field-level granularity. , and Determine the set of data write locations for patch atoms ; Set of data write locations for all patch atoms Perform union operation: ,in For patch writing sets, the same data location is in Only one record is retained. The patch write set is a collection of data location records encoded according to the relation table identifier, tuple identifier, and field identifier. When the same data write location is atomically hit by multiple patches, only one set record is retained to avoid duplication. At the same time, the intermediate value sequence can be saved according to the patch execution order.

[0035] Patch writing set Each data position in Build a patch inverted index : ; in, Indicates the location where data is written. The system contains a set of patch atoms. When this set contains multiple patch atoms, the identifier and execution order of each patch atom are recorded according to a preset patch execution order. The patch inverse index establishes a reverse mapping relationship from data location to patch atom. When the same data location is written by multiple patch atoms, the patch inverse index records the identifier and execution order of each patch atom according to a preset patch execution order, so that after verification failure, it is possible to accurately trace back from the data location to all patch atoms written to that location and their execution order.

[0036] When candidate modification set Empty, missing patch location information, If at least one of the following conditions is met: the candidate modification set is empty, the relation table identifier of the patch atom is missing, the tuple identifier is missing, the field identifier is missing, the patch write set is empty, or the patch reverse index creation fails, no valid patch record is generated and autocommit is disabled; otherwise, the patch write set and the patch reverse index are output.

[0037] The construction of the patch write set and patch inverted index provides a unified data location addressing basis for subsequent constraint propagation, query verification, and failure backtracking, enabling the precise location and tracking of candidate modifications during cross-table repair. The above description covers the complete processing flow from candidate modifications to the patch write set and patch inverted index, providing a precise data location indexing foundation for subsequent steps.

[0038] Step S20: Using the patch write set as the initial seed, iteratively expand the set of affected constraint instances and the set of affected data locations until stable to form the constraint propagation influence range. In each iteration, a new constraint instance is triggered by the current set of affected data locations to be added to the set of affected constraint instances, and the set of affected data locations is expanded by the data locations read by the newly added constraint instances. During the iteration process, the directed propagation predecessor relationship between data locations and constraint instances is recorded. In this embodiment, a constraint instance refers to an executable check unit obtained by binding an integrity constraint to a variable in the current database state. Integrity constraints include foreign key constraints, uniqueness constraints, functional dependencies, containment dependencies, and range constraints. Hard constraints are integrity constraints configured to be met before verification. New non-hard constraint violations are not included in the set of new hard constraint violations; residual constraint violations are still counted according to the definition in step S40. The patch write set records the write locations of all candidate modifications. Data changes at these locations may cause changes in the satisfaction status of some constraint instances, or may trigger the generation of new constraint instances. To fully capture all the effects of cross-table constraint propagation, it is necessary to start from the patch write set and expand the affected constraint instances and affected data locations layer by layer. In each iteration, new constraint instances are triggered by the current set of affected data locations and added to the set of affected constraint instances. The data locations read by these newly added constraint instances further expand the set of affected data locations. This process is repeated until both sets no longer change, at which point a stable state is reached, forming the scope of constraint propagation impact. The scope of constraint propagation encompasses both the set of affected constraint instances and the set of affected data locations. The former is the set of constraint instances requiring constraint checks, while the latter is the set of all data locations involved in these constraint instances. The directed propagation precursor relationships between data locations and constraint instances recorded during iteration are described by two types of directed propagation precursor edges: the first type records the relationship where a data location triggers a constraint instance to enter the affected scope, and the second type records the relationship where a constraint instance propagates its read data location to the affected scope. Under the conditions of complete instance binding and read locations, inclusion of existence changes, and stable iteration, this mechanism covers constraint instances reachable by the patch write set, reducing omissions caused by only checking direct write locations.

[0039] In practice, each integrity constraint in the integrity constraint set is first bound to a combination of tuples in the current database state that satisfy its variable binding conditions, forming an existing constraint instance. Incremental binding is then performed based on the patch atom's modification type, the field value before modification, the field value after modification, and the variable binding conditions of the integrity constraint. Constraint instances added, disappeared, or whose read positions changed due to candidate modifications are added to the set of valid constraint instances. For each constraint instance Record constraint identifiers, variable binding values, and applicable states before and after patch execution: instances applicable only before execution are recorded as disappeared instances; instances applicable only after execution are recorded as new instances; instances applicable before and after execution with the same read location are recorded as persistent instances; instances applicable before and after execution but with a changed read location are recorded as changed instances. Simultaneously, record the set of read data locations for each applicable state. The applicable state after execution is derived incrementally based on the modification semantics of the patch atom; the actual execution of candidate modifications is completed in the isolation verification state. For instances lacking necessary variable bindings or whose read locations cannot be determined, record the constraint identifier, known bindings, association table, and reason for the absence, and include them in the unresolved binding record set. Executable instances are used to construct the set of valid constraint instances and data location indexes; unresolved binding records independently participate in binding integrity verification. A record can only be excluded if it can be determined through constraint definition, known read range, and current patch semantics that it is unrelated to the current affected range and the original repair target; if it cannot be determined whether it is related, it is treated as a necessary record. When necessary records are not yet resolved, the binding integrity flag is... Setting the value to 0 disables joint verification and outputs the reason for non-verification; if all necessary records are resolved or proven irrelevant, ... Set to 1. Record the set of data locations read during constraint judgment for each valid constraint instance. Establish a data location index based on the set of read data locations: ; in, A data location consisting of a relational table identifier, a tuple identifier, and a field identifier; Get constraint instance Read the union of data locations under all applicable conditions; This involves reading a set of constraint instances for the data location and recording the corresponding applicable states for subsequent checks to select the correct state.

[0040] For foreign key constraints, dependency constraints, or other existence constraints, when the target tuple pointed to by the variable binding does not exist, a unified data location code is still formed by the target relation table identifier, the target tuple identifier obtained from the binding value, and the target field identifier, and the read status of this location is recorded as MISSING. MISSING indicates that the target tuple does not exist, does not indicate that the actual field value is NULL, and does not change the triplet code of the data location. Foreign key check instances establish their check identity based on the referencing tuple and its reference value; even if the referenced target does not exist, the check instance should not be omitted simply because the target tuple cannot be matched. It is only treated as inapplicable when the referencing party itself disappears or the constraint application conditions are determined not to be met.

[0041] Patch-based writing set As the initial trigger input, determine the initial set of affected constraint instances and the initial set of affected data locations: ; ; in, Write a set for patches The set of constraint instances that are directly triggered, i.e., constraint instances that read at least one data location in the patch write set. for and The union of the data locations read from the constraint instances.

[0042] During initialization, for the initial set of affected constraint instances For each initial constraint instance, record the patch write set. The first propagation precursor edge from the trigger data position to the initial constraint instance, and the second propagation precursor edge from the initial constraint instance to the data position read and newly included in the affected range; subsequent iterations continue to record both types of propagation precursor edges for newly added nodes. Iterative expansion is performed according to the following relationship: ; ; in, and They represent the first The set of affected constraint instances and the set of affected data locations for each layer; calculate first in each round. And then according to the updated Calculation It also records the corresponding propagation predecessor edges for newly added constraint instances and data locations. All propagation predecessor edges form the constraint propagation predecessor relationship. When the same newly added constraint instance is triggered by multiple data locations, all first propagation predecessor edges are retained.

[0043] First time simultaneously satisfying and Stop iteration when the constraint propagation effect is defined. , where T is the iteration index when a stable state is reached.

[0044] by , To initialize the result, the first substitution into the recursive formula yields what is called the first round of recursion; if and Then, after the first round of recursion, a stable state is reached.

[0045] When the patch is written When empty, no effective propagation range is formed; when not empty but no constraint instance exists at any data position in the read, let For empty set, If the output range is still unstable after reaching the preset maximum number of iterations, an unstable output range flag will be displayed and automatic submission will be disabled.

[0046] All the first-type and second-type directed propagation predecessor edges recorded during the above iterative expansion process together form a directed propagation predecessor relationship. This relationship records which propagation trigger chain between the data location and the constraint instance triggered which one. After the iteration stabilizes, the influence range under the corresponding constraint dependency relationship is formed, providing a path basis for reverse tracing when subsequent constraint checks fail.

[0047] Specifically, the step of recording the directed propagation predecessor relationship between data location and constraint instance during the iteration process includes: During the iteration process, the triggering events based on the data location and the constraint instance are recorded as first-type directed propagation precursor edges and second-type directed propagation precursor edges. Specifically, in the initial triggering phase and each iteration expansion phase, when the data location triggers the constraint instance to enter the set of affected constraint instances, the first-type directed propagation precursor edge between the data location and the constraint instance is recorded. The data relationship of the data location read by the constraint instance being included in the set of affected data locations is recorded as the second-type directed propagation precursor edge. When there are multiple triggering data locations for the same newly added constraint instance, all first-type directed propagation precursor edges are retained. The first type of directed propagation predecessor edge and the second type of directed propagation predecessor edge recorded are used to generate the directed propagation predecessor relationship.

[0048] In this embodiment, during the iteration process, the triggering events based on the data location and the constraint instance are recorded as first-type directed propagation precursor edges and second-type directed propagation precursor edges. Specifically, in the initial triggering phase and each iteration expansion phase, when the data location triggers the constraint instance to enter the set of affected constraint instances, the first-type directed propagation precursor edge between the data location and the constraint instance is recorded. The data relationship of incorporating the data location read by the constraint instance into the set of affected data locations is recorded as the second-type directed propagation precursor edge. When there are multiple triggering data locations for the same newly added constraint instance, all first-type directed propagation precursor edges are retained. The recorded first-type directed propagation precursor edges and second-type directed propagation precursor edges are used to generate the directed propagation precursor relationship.

[0049] The directed propagation precursor relationship is a structured propagation path synchronously recorded during the generation of the constraint propagation influence range. Its function is to provide a traceable path for the re-location of associations after verification failure. This relationship consists of two types of directed propagation precursor edges: the first type records the triggering relationship when the data position triggers the constraint instance to enter the affected range, with the direction from the data position node to the constraint instance node; the second type records the expansion relationship when the constraint instance includes the data position it reads into the affected range, with the direction from the constraint instance node to the data position node. The recording of these two types of edges runs through the initial triggering stage and each iteration expansion stage of constraint propagation, together forming a directed bipartite graph with the data position node and the constraint instance node as vertices. By fully recording each triggering event and each transmission event, the directed propagation precursor relationship preserves the recorded propagation chain of constraint influence spreading step by step from the patch write set, so that when traversing in the reverse direction along this relationship, it is possible to backtrack from any failed constraint instance node to the data position in the patch write set that initially triggered the constraint instance to enter the affected range.

[0050] In practical implementation, when using the patch write set as the initial trigger input, the initial set of affected constraint instances is first determined. This initial set of affected constraint instances consists of constraint instances that read at least one data location from the patch write set. For each initial constraint instance in the initial set of affected constraint instances, a first-type directed propagation precursor edge is recorded between the data location in the patch write set that caused the initial constraint instance to be included in the initial set of affected constraint instances and the initial constraint instance itself. Subsequently, the initial set of affected data locations is determined; this set is the union of the patch write set and the data locations read by each constraint instance in the initial set of affected constraint instances. For each data location read by an initial constraint instance and added to the initial set of affected data locations during initialization, a second-type directed propagation precursor edge is recorded between the initial constraint instance and the data location. These two types of edges correspond to the first-type propagation event that triggers a constraint instance to enter the affected area, and the second-type propagation event that the constraint instance propagates its read location to the affected area, respectively.

[0051] In each iteration of expansion, constraint instances that read at least one data location from the current affected data location set but are not yet included in the current affected constraint instance set are added to the updated affected constraint instance set. For each new constraint instance, a first-type directed propagation precursor edge between the data location that caused the new constraint instance to be added to the affected constraint instance set and the new constraint instance is recorded. Subsequently, data locations read by each constraint instance in the updated affected constraint instance set but not yet included in the current affected data location set are added to the updated affected data location set. For each new data location, a second-type directed propagation precursor edge between the constraint instance that added the data location to the affected data location set and the data location is recorded. When the same new constraint instance is triggered by multiple data locations, all first-type directed propagation precursor edges are retained because these edges each represent different triggering sources; similarly, when the same constraint instance adds multiple data locations it reads to the affected data location set, a corresponding second-type directed propagation precursor edge is recorded for each data location. The above process is repeated until both the affected constraint instance set and the affected data location set no longer change.

[0052] A directed propagation precursor relationship is formed by all first-type and second-type directed propagation precursor edges. This relationship is a directed bipartite graph structure, where nodes include two types: data location nodes and constraint instance nodes. Edges include first-type directed propagation precursor edges pointing from data location nodes to constraint instance nodes and second-type directed propagation precursor edges pointing from constraint instance nodes to data location nodes. The direction of the first-type directed propagation precursor edges is data location → constraint instance, indicating that the data location triggers the constraint instance to enter the affected range through the read relationship. The direction of the second-type directed propagation precursor edges is constraint instance → data location, indicating that the constraint instance reads the data location when performing constraint judgment, thus including the data location in the affected range. The directions of the two types of edges together determine that the directed propagation precursor relationship propagates step by step forward from the patch write set along the path data location → constraint instance → data location → constraint instance → … When verification fails and reverse location is required, the path is traversed in the reverse direction of the directed bipartite graph, i.e., constraint instance → data location → constraint instance → data location → … . Starting from the failed constraint instance node, passing through intermediate data location nodes and constraint instance nodes, the path ultimately traces back to the failure-related data location in the patch write set. The recorded propagation precursor edges provide a basis for reverse location of associated patches along the existing propagation path.

[0053] Step S30: Based on the set of affected data locations, filter the contributing paths leading to the protected result items in each query source graph, and generate query source slices and query backtracking indexes based on the contributing paths; In this embodiment, based on the set of affected data locations within the constraint propagation influence range, contribution paths leading to protected result items are filtered in the query sourcing graph of each protected query. Query sourcing slices are generated based on these contribution paths, and a query backtracking index is established. Protected queries are those pre-configured to maintain result stability or limit deviation during data repair. The query sourcing graph is a directed graph representing the contribution relationships between query result items, query operators, intermediate result nodes, and basic data location nodes, with edges including data contribution edges and execution dependency edges. The set of affected data locations within the constraint propagation influence range reflects all data locations that may be affected by candidate modifications, but not all of these data locations will affect the output of the protected query. To accurately limit the scope of query verification, the set of affected data locations is used as a filtering condition to retain only those contribution paths leading to protected result items and passing through affected data locations in the query sourcing graph, thereby generating query sourcing slices. A query sourcing slice is essentially a subgraph of the complete query sourcing graph, containing only nodes and edges that have contribution paths to candidate modifications. Based on this, a query backtracking index is established to access the underlying data location nodes from the protected result item nodes. This index records the mapping relationship between the protected result item node identifier, the underlying data location nodes, and the unified data location code, as well as the directions of each data contribution edge and execution dependency edge within the slice. Through the above methods, the physical scope of constraint propagation is transformed into the logical filtering scope of query verification. After completing the alignment of the outputs before and after and the necessary source tracing supplementation, the redundant processing of irrelevant nodes in the verification and backtracking stages can be reduced.

[0054] In practice, for each protected query Obtain the query origin graph of the target database in its current state. including Basic data location node, query operator node, intermediate result node, and protected result item node. This includes data contribution edges and execution dependency edges. (Based on the node) The corresponding set of basic contribution data locations determines the set of affected seed nodes: ; in, Represents a node The corresponding set of basic contribution data locations; for connection, grouping, aggregation, or sorting nodes, the set of basic contribution data locations includes the data locations of the corresponding connection key, grouping key, aggregation input field, or sorting field.

[0055] From the affected seed node set Traverse along the directions corresponding to the data contribution edges and execution dependency edges to the set of protected result item nodes. This yields the set of downstream reachable nodes located on the corresponding contribution path. : ; in, Indicates a candidate downstream node. Indicates the protected result item node, It is a binary reachable function. and Represents the query source graph For any two nodes in, when There exist nodes To the node And when a directed path is formed by at least one of data contribution edges and execution dependency edges, Set the value to 1, otherwise set it to 0. For any two nodes in the query source graph, if there exists a directed path from the previous node to the next node consisting of at least one edge, namely a data contribution edge or an execution dependency edge, the next node is considered a downstream reachable node.

[0056] according to and Generate query source slices : ; in, Indicates by The induced subgraph is formed by the union of the set of affected seed nodes and the set of downstream reachable nodes. This subgraph is an initial query sourcing slice formed based on the current state of the target database.

[0057] When at least one of the following abnormal conditions is met: Query source graph Missing fracture, When an executable slice cannot be formed, or when the query source graph cannot represent the appearance, disappearance, or sort boundary changes of result items caused by addition, deletion, or non-monotonic query operators, the protected query will be protected. All input relations, related query operators, and protected result item nodes are used as a conservative query sourcing slice. When candidate modifications involve adding, deleting, or potentially changing join, grouping, aggregation, deduplication, or sorting results, the slice is supplemented with query sourcing information after patch execution. In cases where the above abnormal conditions are not met, and... When empty, the query will be protected. Mark as having no query impact and Set it to an empty set.

[0058] For each non-empty query tracing slice, the protected result item node identifier, the mapping between the basic data location node and the unified data location code, and the directions of each data contribution edge and execution dependency edge within the slice are recorded. A query backtracking index is established to access the basic data location node from the protected result item node. The query tracing slices and query backtracking indexes corresponding to each protected query are combined into a query slice set and output. The dependency relationship between the query backtracking index and the query tracing slices enables that when subsequent verification fails, the data can be precisely traced back to the basic data location from the protected result item node along the contribution path within the slice. The query tracing slices and query backtracking indexes formed in this step serve as the initial input for step S40, and are supplemented by step S40 for result items that have been added, disappeared, have changed values, or have changed sorting after the patch is executed. The above processing ensures that the physical impact range of constraint propagation is accurately transformed into the logical filtering range of query verification, realizing a precise mapping from physical impact to logical verification range.

[0059] Step S40: Establish an isolation verification state based on the current state of the target database, record the query output and query source information of each protected query in the state before patch execution, execute patch atoms in the isolation verification state to obtain the state after patch execution, and obtain the query output and corresponding query source information of each protected query in the state after patch execution; align the result items according to the query output before and after patch execution, identify the result items that are added, disappeared, have changed values, or have changed sorting, and supplement the query source slice and query backtracking index according to the contribution path of the corresponding result items in the query source graph before and after patch execution; perform constraint checks on the affected constraint instances in the scope of constraint propagation, perform normalized query deviation verification on the protected result items in the supplemented query source slice relative to the query output benchmark before patch execution, and form a joint verification result based on whether the necessary binding is complete, whether the original repair goal is achieved, whether the verification task set is not empty, whether all necessary verification tasks are completed and the results are valid, whether the residual constraint violation set and the newly added hard constraint violation set are both empty, and whether each query deviation does not exceed the corresponding threshold. In this embodiment, patch atoms are executed in the isolated verification state to obtain the post-patch state. The difference between the post-patch state and the pre-patch state is used as the basis for judgment. Constraint checks are performed on affected constraint instances within the constraint propagation scope, and query deviation verification is performed on protected result items in the query sourcing slice. The constraint check results and query deviation verification results are merged into a joint verification result. The isolated verification state is a verification environment isolated from the current state of the target database, and can be any form of database snapshot, transaction copy, or database branch. Executing patch atoms in the isolated verification state does not affect the current state of the target database, thus ensuring the security and rollbackability of the verification process. After the patch atoms are executed, the post-patch state is obtained, while the pre-patch state is the current state of the target database. The difference between the post-patch state and the pre-patch state reflects the actual changes caused to the database by the candidate modifications.

[0060] Based on this difference, the repair effect is verified from two dimensions: constraint consistency and query stability. Constraint checking is performed on affected constraint instances within the scope of constraint propagation. These constraint instances are all constraint instances with propagation paths to the candidate modification, determined through iterative expansion. This includes parts of the original constraint instances that have changed due to patch atoms, as well as constraint instances newly added due to patch atoms. Query deviation verification is performed on protected result items in the query sourcing slice. These protected result items are all result items with contributing paths to the candidate modification, determined through contribution path filtering. The constraint check results and query deviation verification results are combined to form a joint verification result, which comprehensively reflects the success of the candidate modification in both data consistency and query stability dimensions.

[0061] In practical implementation, based on the current state of the target database Establish an isolation verification state among database snapshots, transaction copies, and database branches. Record the query output and corresponding query tracing information of each protected query in the state before patch execution. Perform candidate modifications in the isolation verification state according to the execution order of the patch atoms to obtain the state after patch execution. It also obtains the query output and query source information of each protected query in the state after the patch is executed.

[0062] Align the query output before and after patch execution based on the stable result item identifiers. Specifically, align the query output before and after patch execution according to the stable result item identifiers; detailed queries use the result primary key or pre-fixed result item identifiers, aggregate queries use the grouping key, and sorting queries use the stable result item identifiers and sorting positions. Only the state after patch execution is considered. The existing items are recorded as newly added result items, and only exist in the state before the patch is executed. The items that exist in both states are denoted as disappearing result items; those that exist in both states but have different output values ​​are denoted as value change result items; and those whose sorting position or protected sorting boundary changes are denoted as sorting change result items. These result items are then grouped into a set of change result items. .

[0063] Based on the generated query source slice Based on this, and according to the contribution paths of the corresponding result items in the source graph before and after patch execution, the source slice and backtracking index are supplemented. This includes the contribution paths of newly added result items in the source graph after patch execution, the contribution paths of disappeared result items in the source graph before patch execution, and the contribution paths of result items with changed values ​​or sorting before and after patch execution. The query backtracking index is updated. If query backtracking information is missing or cannot represent the change in any state, all relevant input relationships, query operators, and protected result items for that query in the corresponding state are included in the conservative slice.

[0064] After the supplement is completed, the set of affected constraint instances within the scope of constraint propagation is used. and query slice set Generate a collection of tasks: ;

[0065]

[0066] in, , and These are respectively the constraint check task set, the query deviation verification task set, and the joint verification task set; and These represent the numbers after the supplement is completed. The set of individual query source slices and all query source slices. Protected queries with empty slices still generate verification tasks; only when the output before and after is valid and no changes are confirmed is a verification task recorded. , Otherwise, it will be processed according to the unverifiable rule. Empty slices that are confirmed to have no impact will not be processed as slices that cannot be executed.

[0067] For each task Record the data reading location set for the task Valid indicators of task completion and results And the task verification results; when the task is completed and the results are valid. When the task is not completed or the result is invalid Continuous instances and changed instances are determined before and after execution, respectively, based on their applicable states. New instances are only determined during the execution phase. The judgment is made that the disappearing instance only occurs in The judgment is as follows: An instance's inapplicability in a certain state must be based on explicit constraints; read errors, unknown binding states, or missing target tuples cannot be directly considered inapplicable. Specifically, for missing foreign key targets, an existence check is performed according to the MISSING rule; for unknown states, the completion and validity flags of necessary tasks are set to 0.

[0068] in, Represents constraint instances In database status The constraint state function; when constraint instance In state If the following does not apply, or if it applies and the constraints are satisfied, When constraint instances In state When the following applies but the constraint is not satisfied, .

[0069] For each constraint instance corresponding to a task in the constraint checking task set, the state before patch execution is as follows: and the status after patch execution The constraint judgment is performed during the patch execution. The state before patch execution is then considered. and the status after patch execution Constraint instances that are applicable to all constraints but not satisfied by any constraint are recorded in the residual constraint violation set. ;State before patch execution Not applicable or satisfied, and the status after patch execution. Instances of hard constraints that are applicable but not satisfied are added to the new hard constraint violation set. This applies only to the state prior to patch execution. 1. Instances that are no longer applicable after the patch is executed will not be included in the set of newly added hard constraint violations. 2. New instances that are only applicable after the patch is executed must have their constraint judged in the state after the patch is executed. If they do not meet the hard constraints, they will be included in the set of newly added hard constraint violations.

[0070] For each protected query, calculate the query deviation between the query output before and after patch execution, based on the query output type. The calculation method for the query deviation is directly related to the output type. Calculate the deviation for protected queries according to their output type: ; ; ; ; Numerical query bias is the normalized result of the absolute value of the difference between the numerical values ​​before and after patch execution relative to the absolute value of the numerical values ​​before patch execution, with the normalized denominator not less than a preset positive number. The set-type query bias is calculated by subtracting the intersection cardinality from the union cardinality as the numerator, and using a union cardinality not less than 1 as the denominator; when the union is not empty, it is equivalent to the Jaccard distance, and when both sets are empty, the bias is 0. The sorting-type query bias is the normalized result of the preset sequence difference relative to the union size of the preceding and following result items; when both sorted sequences are empty, the bias is 0. In this embodiment, d is the Levenshtein edit distance of the stable result item identifier sequence, and the insertion, deletion, and replacement costs are all 1; the parallel items are sorted according to the stable identifier, and the union size is calculated by deduplicating the result item identifier. The aggregation-type query is aligned according to the union of the grouping key: missing SUM and COUNT groups are padded with 0; missing AVG, MIN, and MAX groups are marked as incomparable when no preset comparison rules are set, and the corresponding task completion and result validity flags are added. Set to 0. For example, the output was 100 before the patch was executed, and 110 after the patch was executed. When the value is not greater than 100, the deviation for numerical queries is 0.1.

[0071] When at least one of the following conditions is met—output missing, output incomparable, or slice inoperable—the task completion and result validity flags of the corresponding query deviation verification task will be set. Set it to 0, and set the corresponding query deviation to 0. A value of 0 is used as a placeholder for values ​​in the joint verification calculation, and the reason for any anomalies is recorded; among them, This indicates that the task was not completed or the result was invalid. This indicates that the task is completed and the result is valid, and the actual query deviation is 0. These two should not be treated as the same.

[0072] When the aggregation type is SUM or COUNT, if a grouping key exists only in one state, the aggregation value of that grouping key in the other state will be set to 0; when the aggregation type is AVG, MIN or MAX and no missing group comparison rules are preset, the corresponding query output will be marked as incomparable, and the completion and result validity flags of the corresponding task will be set to 0.

[0073] For query deviation verification tasks that are completed normally, record the set of changed result items. The changed result items in the query are used as the starting point for query backtracking. This is based on the query output type. Select the corresponding deviation as and with a pre-fixed allowable deviation threshold Compare.

[0074] Based on the necessary binding integrity, the achievement of the original repair goals, the completion and validity of tasks and results, constraint violations, and query biases, a joint verification result is generated: ; in, Indicates an indicator function, This indicates the product; , These are the aforementioned necessary binding integrity flag and the original repair goal achievement flag, respectively. When , The following conditions must be met: the joint verification task set is empty; any necessary task is incomplete or has an invalid result; any violation set is not empty; or there is a query deviation exceeding the corresponding threshold. ,otherwise Output the joint verification results, constraint violation set, each query deviation, task status, changed result items, and records of unachieved goals.

[0075] The above description covers the complete process from patch execution to the generation of joint verification results, enabling constraint checks and query deviation verification to be completed collaboratively in the same isolated environment.

[0076] Step S50: If the joint verification result passes, the patch atom is submitted to the target database according to the submission verification rules, and the repair result and verification record are output after successful submission; if the joint verification result indicates that there is a verification failure, if the necessary binding is incomplete, the original repair target cannot be verified, or a traceable failure task cannot be obtained, the current repair is terminated and a failure record is output; otherwise, a traceability path is determined according to the failed verification task in the joint verification result, and the data position of the patch write set is traced back based on the traceability path. If the failed verification task is a constraint check failure, the data position in the patch write set is traced back along the directed propagation predecessor relationship starting from the corresponding constraint instance node; if the failed verification task is a query deviation failure, the data position in the patch write set is traced back along the query backtracking index in the query traceability slice starting from the changed result item node. In this embodiment, a tracing path is determined based on the failed verification tasks in the joint verification results, and the data location of the patch write set is traced back based on this tracing path. When the joint verification result fails, it is necessary to determine which verification tasks caused the verification failure. These tasks are organized into a set of failed verification tasks. Failed verification tasks include two categories: constraint check tasks and query deviation verification tasks. Different reverse tracing paths are required for different types of failed verification tasks because the two types of failures have different generation mechanisms. Constraint check failures include incomplete or invalid results of necessary constraint check tasks, residual constraint violations, or newly added hard constraint violations. For failed tasks where the corresponding constraint instance can be identified and the information required for backtracking is valid, the constraint instance appears in the constraint propagation influence range because there is a propagation path between it and certain data locations in the patch write set. These propagation paths are recorded in the directed propagation predecessor relationship. Therefore, constraint check failures should be traced back along the directed propagation predecessor relationship. Starting from the failed constraint instance node, the process traverses in the opposite direction of the first type of directed propagation predecessor edge from the data location to the constraint instance and the second type of directed propagation predecessor edge from the constraint instance to the data location until the data location in the patch write set is reached. A query deviation verification failure means that the output of a protected result item has changed beyond the allowed range before and after patch execution. This protected result item appears in the query sourcing slice because it has a contributing path to certain data locations in the patch write set; these contributing paths are recorded in the query sourcing slice and the query backtracking index. Therefore, a query deviation verification failure should start from the changed result item node and trace back along the query backtracking index in the query sourcing slice to the data location in the patch write set. Through this differentiated backtracking strategy, constraint check failures and query deviation verification failures are traced back to their respective patch write locations along their dependent structured paths.

[0077] In practical implementation, when the joint verification results When a result of 1 (i.e., passing) is obtained, the patch is submitted according to the submission verification rules specified in step S60, and the repair result and verification record are output after successful submission; the patch adjustment process is not triggered when the verification passes for the first time. A set of failed verification tasks is formed based on the task status, constraint violations, and query deviations. : ; in, and These represent constraint checking tasks and query deviation verification tasks, respectively. A set of failure verification tasks is formed by grouping tasks that meet at least one of the following conditions: task incomplete, residual constraint violation, newly added hard constraint violation, or query deviation exceeding the allowable deviation threshold. If the necessary binding is incomplete or the target cannot be verified, terminate the current repair and output an unverifiable record; if the original repair target is not achieved and there are no backtracked failed tasks, output a record of unachieved target and terminate the repair, and do not consider an empty set of failed tasks as a pass.

[0078] For failed constraint checking tasks, the predecessor relationship is propagated along the constraint, starting from the corresponding constraint instance node. The reverse traversal will find all instances that belong to the patch set. The data locations constitute the first set of failure-related data locations. The directed propagation precursor relationship is a directed bipartite relationship consisting of data location nodes and constraint instance nodes. The first type of directed propagation precursor edge indicates that the data location triggers the constraint instance to enter the affected range, and the second type of directed propagation precursor edge indicates that the constraint instance propagates its read data location to the affected range. During reverse traversal, starting from the failed constraint instance node, the data location that triggered the constraint instance to enter the affected range is visited along the reverse direction of the first type of directed propagation precursor edge. For data locations not yet belonging to the patch write set, the precursor constraint instances that include them in the affected range are visited along the reverse direction of the second type of directed propagation precursor edge. This process is repeated alternately to backtrack and collect data locations belonging to the patch write set.

[0079] For failed query deviation verification tasks, starting from the recorded changed result item node, the query backtracking index is used to traverse backwards along the supplemented query source slice to the basic data location node. Newly added result items are traced back along the contribution path after patch execution, disappeared result items are traced back along the contribution path before patch execution, and result items with value or sorting changes are traced back along the contribution paths before and after patch execution. The basic data location nodes are mapped to a unified data location code, and the mapped nodes belonging to the current patch write set are then... The data locations form the second set of failure-related data locations. Merging the first set of failure-related data locations and the second set of failure-related data locations yields the final set of failure-related data locations. And determine the associated patch atom set based on the patch inverted index. : ; in, This represents the set of patch atoms associated with the failed verification task. This represents the set of patch atoms indicating the location of the data to be written; when the verification task fails to be obtained, the necessary reverse traversal cannot be completed, or the basic data location node cannot be mapped to a unified data location code, or... If empty, output a flag indicating a missing source of failure and prevent the current patch from being submitted; The aforementioned backtracking forms a set of failure-related patches, providing a candidate range for adjustments; whether the patch adjustments eliminate the failure is determined by re-performing the joint verification.

[0080] Step S60: Locate the patch atom corresponding to the data location using the patch inverse index, adjust the patch atom, regenerate the patch write set and patch inverse index, and re-execute constraint instance iteration triggering, query source tracing slice filtering, and isolation joint verification based on the regenerated patch write set and patch inverse index until the joint verification result passes or a preset stopping condition is met. When the joint verification result passes, terminate the iterative adjustment process, submit the patch according to the submission verification rules, and output the repair result and verification record after successful submission. When the joint verification result fails and the preset stopping condition is met, or the submission fails, terminate the current repair and roll back the uncommitted modifications, and output a failure record. The submission verification rules include verifying the target database version, the field values ​​before patch modification, the integrity constraint configuration version, and the protected query configuration version within the same submission transaction or a submission mechanism with equivalent atomic verification capabilities; if any of these are inconsistent, the original verification result is prohibited from being used, the isolation verification state is re-established, and re-verification is performed.

[0081] In this embodiment, the patch inverse index is an index structure that points from a data location to the patch atom written to that data location. This index maps each data location in the set of failure-related data locations to its corresponding patch atom. A failure-related data location may be written by multiple patch atoms; in this case, the patch inverse index records all related patch atoms according to the preset patch execution order. The located patch atoms are adjusted using methods including patch undo processing, field-based splitting, and field value adjustment. Patch undo processing means undoing the entire patch atom; field-based splitting only applies to multi-field update patches, and after splitting, the write set and inverse index are rebuilt as independent patch atoms, no longer re-merged according to the initial rules; additions and deletions are performed as complete tuples; field value adjustment refers to adjusting the modified field values ​​within the field's value range, integrity constraints, and allowable deviation range. After adjustment, all intermediate calculation results before adjustment are marked as invalid because these intermediate results were calculated based on the patch atoms before adjustment and are no longer valid after adjustment. Then, based on the adjusted patch atoms, the patch write set and patch inverse index are regenerated, and the constraint instance iterative expansion, query tracing slice generation, isolation verification, and joint verification are re-executed from scratch, without reusing any pre-adjustment calculation results. This iterative adjustment process continues until the joint verification result passes or a preset stopping condition is met. When the joint verification result passes, the iterative adjustment process terminates, the patch is submitted according to the commit verification rules, and the repair result and verification record are output upon successful submission. When the joint verification result fails and the preset stopping condition is met, or the submission fails, the current repair is terminated and uncommitted modifications are rolled back, and a failure record is output. The commit verification rules include verifying the target database version, pre-patch field values, integrity constraint configuration version, and protected query configuration version within the same commit transaction or a commit mechanism with equivalent atomic verification capabilities; if any of these are inconsistent, the original verification result is prohibited from being used, the isolation verification state is re-established, and re-verification is performed.

[0082] In practical implementation, the associated patch atom set The patch atom executes the corresponding processing in patch undo, field-based splitting, and field value adjustment. In one embodiment, from a pre-configured limited combination of candidate field values, combinations that match the field type and value range are selected in a preset order, and joint validation is re-executed one by one; if candidates are exhausted or the stopping condition is met without success, the process is rolled back and a failure record is output. The adjusted result is: ; in, To adjust the number of times, For the first The set of patch atoms used in this verification. This is the set of associated patch atoms identified in this verification. For the reason The set of patch atoms that are retained after splitting by field or adjusting field values; revoked patch atoms are not included in this set.

[0083] Based on the adjusted patch atomic set, a new patch write set and patch reverse index are formed. The following are marked as invalid: the applicable status of constraint instances before adjustment, the scope of constraint propagation, the predecessor relationships of constraint propagation, the query output before and after patch execution, query tracing information, query tracing slices, query backtracking indexes, constraint check tasks, query deviation verification tasks, and failure verification tasks. Starting from step S20, the above objects are regenerated and joint verification is performed based on the newly formed patch write set, without reusing the calculation results from before adjustment. The entire process of regeneration and reverification above does not reuse any calculation results from before adjustment, ensuring that each calculation is based on the latest state of the current patch atomic set. The above invalidation handling applies to intermediate results calculated with the current patch, without deleting the original repair targets, target acceptance predicates, and pre-fixed query protection configurations. Verification of all original repair targets is re-executed in each round, even if the target's location no longer belongs to the current patch write set. The completion status and judgment result of target verification are recorded independently; joint verification fails if the target is not achieved.

[0084] After each successful joint verification, the target database version, pre-patch field values, integrity constraint configuration version, and protected query configuration version are checked within the same commit transaction or a commit mechanism with equivalent atomic verification capabilities. If all match, the patch is committed, and the repair result and verification record are output upon successful commit. If any item is inconsistent, the successful result is not reused, the isolation verification state is re-established, and the objects required for verification are regenerated. The same commit rule applies to initial successful verification and subsequent successful verification. If the preset maximum number of adjustments is reached without successful verification, the propagation scope reaches the preset iteration limit without stabilization, the status of necessary verification tasks is unknown, or the commit fails, the current repair is terminated, uncommitted modifications are rolled back, and a failure record is output. Re-verification due to version changes is also included in the preset retry limit.

[0085] The above description covers the complete iterative loop from patch atomic location, adjustment, failure marking, regeneration to iteration termination judgment, ensuring that each adjustment verification is based on the result of a completely new calculation, avoiding inaccurate verification caused by reusing failed intermediate data. When the new joint verification result fails and the preset stopping condition is not met, failure location, patch adjustment, object regeneration, and joint verification are repeated; when the joint verification result passes, a unified commit verification rule is executed, and the repair result and verification record are output after successful commit; when the verification fails and the preset stopping condition is met or the commit fails, the current repair is terminated, uncommitted modifications are rolled back, and a failure record is output.

[0086] Further, the steps of locating the patch atom corresponding to the data position via the patch inverse index, adjusting the patch atom, regenerating the patch write set and patch inverse index, and re-executing constraint instance iteration triggering, filtering query tracing slice based on the regenerated patch write set and patch inverse index, and executing the adjusted patch atom, until the joint verification result passes or reaches the preset stopping condition, include: The constraint propagation influence range, the directed propagation precursor relationship, the query source tracing slice, the query backtracking index, the joint verification result, the constraint check result, and the query deviation verification result formed before the adjustment are marked as invalid; The patch write set and patch inverse index are regenerated based on the adjusted patch atoms; the original set of repair targets and their acceptance predicates recorded before the first verification are retained, and all original repair targets are re-verified after each round of isolation execution; Using the newly generated patch write set as the initial seed, the iterative expansion of the constraint instance is re-executed to reshape the constraint propagation influence range, and the directed propagation predecessor relationship is re-recorded; Based on the set of affected data locations in the newly formed constraint propagation impact range, the contributing paths are re-selected in each query source graph to regenerate query source slices and query backtracking indexes. Based on the current confirmed state of the target database, the isolation verification state is re-established, and the adjusted patch atoms are executed in it. The constraint checks are re-executed on the currently affected constraint instances, and the query deviation verification is re-executed to form a new joint verification result. When the new joint verification result fails and the preset stopping condition is not met, the failed verification task is re-identified, the associated patch atom is located and adjusted, and the above steps of regeneration and re-verification are repeated. When the new joint verification result passes, the iteration stops, and the repair result and verification record are output after the submission is verified and successfully completed. When the new joint verification result fails and the preset stopping condition is met, or the submission fails, the current repair is terminated and the unsubmitted modifications are rolled back, and the failure record is output.

[0087] In this embodiment, the patch inverse index is an index structure that points from a data location to the patch atom written to that data location. This index maps each data location in the set of failure-related data locations to its corresponding patch atom. A failure-related data location may be written to by multiple patch atoms; in this case, the patch inverse index records all related patch atoms according to a preset patch execution order. After adjusting the located patch atoms, all intermediate calculation results before the adjustment, including constraint propagation influence range, directed propagation predecessor relationships, query source tracing slices, query backtracking indexes, joint verification results, constraint checking tasks, and query deviation verification tasks, can no longer be reused because these intermediate results are calculated based on the patch atoms before the adjustment. The adjusted patch atoms may cause changes in the constraint propagation path or the contribution path in the query source tracing slice. Therefore, all the above intermediate results must be marked as invalid, and all intermediate results must be regenerated from scratch based on the adjusted patch atoms. This is crucial to ensuring the accuracy of iterative verification.

[0088] In the specific implementation process, during the r-th adjustment, the patch atoms in the associated patch atom set undergo corresponding processing in patch revocation, field-based splitting, and field value adjustment. Patch revocation refers to revoking the entire patch atom and removing it from the candidate modification list; field-based splitting is performed according to the update patch splitting and grouping retention rules specified in step S60; field value adjustment refers to adjusting the modified field value within the field value range, integrity constraints, and allowable deviation range. After the above processing, the patch atoms retained after field-based splitting and field value adjustment are recorded as the retained patch atom set, forming the patch atom set used for the next verification. Revoked patch atoms are not included in the retained patch atom set. After determining the adjusted patch atom set, the constraint propagation impact range before adjustment, directed propagation predecessor relationships, query outputs before and after patch execution and query tracing information, query tracing slices, query backtracking indexes, constraint check tasks, query deviation verification tasks, and failure verification tasks are all marked as invalid. These marked invalid objects will no longer be referenced in subsequent steps, and their occupied storage space can be released or overwritten.

[0089] Based on the adjusted patch atom set, all steps starting from patch write set construction are re-executed. First, the patch write set and patch inverse index are reconstructed based on the adjusted patch atoms. Then, using the regenerated patch write set as the initial seed, iterative expansion of constraint instances is re-executed to reconstruct the constraint propagation impact range, and directed propagation predecessor relationships are re-recorded during the iteration process. Based on the set of affected data locations in the reconstructed constraint propagation impact range, contribution paths are re-selected in each query sourcing graph to regenerate query sourcing slices and query backtracking indexes. An isolation verification state is re-established based on the current confirmed state of the target database, where the adjusted patch atoms are executed, constraint checks are re-executed on affected constraint instances, and query deviation verification is re-executed to form new joint verification results. All the above regeneration and re-verification processes do not reuse any calculation results from before the adjustment, ensuring that each calculation step is based on the latest state of the current patch atom set. The original repair objectives and their acceptance predicates are fixed inputs and are not part of the above-mentioned failed calculation results; all original repair objectives must still be verified in each round. When the new joint verification result fails and the preset stopping condition is not met, the failure location, patch adjustment, object regeneration, and joint verification are repeated. After the joint verification passes, the unified submission verification rules specified in step S60 are executed. The repair result and verification record are only output after a successful submission; if the verification fails and the preset stopping condition is met, or if the submission fails, the current repair is terminated and uncommitted modifications are rolled back, and a failure record is output. This closed-loop mechanism of iterative adjustment and regeneration ensures that each post-adjustment verification is based on a completely new calculation, avoiding verification deviations or location errors that may result from reusing invalid intermediate data. The following is an illustrative example; the numerical values ​​are for demonstration purposes. Let... , , These contain (1,1,90), (1,1,100), and (1,100) respectively. (Constraints) according to Bind and require , according to Bind and require The goal of this repair is to eliminate [the target tuple] while preserving it. Violation. Protected query is The threshold is 0.12. The candidate patch will The value was changed from 90 to 110, with candidate values ​​of 110 and 100 respectively. The write set only contains... Initialization And extended to Subsequently included And its read position, then iteratively confirm stability. Query slice contains Contribution path to the SUM results. Initial validation underway. The violation persists; the query deviation is 20 / 90, exceeding the threshold. Both backtracking methods pinpointed this patch. After selecting candidate value 100, the isolation state was re-established from the pre-execution state, and the verification object was rebuilt. , All conditions are met, and the query deviation is 10 / 90, which is less than the threshold. Joint verification passes when the original goal is achieved, necessary bindings are complete, the task is completed effectively, and there are no violations. Submission is then performed after further verification.

[0090] Further, see Figure 2 , Figure 2 This is a detailed step diagram of step S10 in one embodiment, based on the shown... Figure 2 The steps of splitting candidate modifications into patch atoms, generating the write position of each patch atom using unified data position encoding to form a patch write set, and generating a patch inverse index based on the write position include S11~S15: Step S11: Obtain the candidate modification set and determine the corresponding relation table identifier based on the target relation table of each candidate modification; Step S12: During the initial construction, candidate modifications with the same relation table identifier, the same tuple identifier, and the same modification type are merged. For multiple modified field values ​​of the same field after merging, the final modified values ​​are retained according to the preset patch execution order to form a set of effective patch atoms. The preset patch execution order is determined by the input timing of each candidate modification or the priority of the configuration. Step S13: Determine the set of data write locations corresponding to each patch atom based on the relation table identifier, the modified tuple identifier, and the modified field identifier that each patch atom acts upon. Step S14: Perform a union operation on the data write position set of all patch atoms to form the patch write set; Step S15: For each data location in the patch write set, record all patch atoms written to that data location to form the patch reverse index. When the same data location is written by multiple patch atoms, the patch reverse index records the identifier and execution order of each patch atom according to the preset patch execution order.

[0091] In this embodiment, splitting candidate modifications into patch atoms and constructing patch write sets and patch inverse indexes constitutes the data preparation stage of the entire repair process. The core objective of this stage is to transform various candidate modification operations input by the user into basic modification units that can be precisely addressed and independently traced, and to establish a bidirectional index structure to support subsequent constraint propagation and failure backtracking. Candidate modifications may involve multiple relation tables, multiple tuples, and multiple fields. Conflicts or redundancies may exist between different candidate modifications; for example, when the same field is modified multiple times, only the last modification is valid. Therefore, candidate modifications need to be merged and deduplicated according to relation table identifiers, tuple identifiers, and modification types to form a valid set of patch atoms. Each patch atom uniquely corresponds to a modification type of a tuple in a relation table, and records its set of field values ​​before and after modification. Based on this, the write position of each patch atom is determined through unified data location encoding, thereby generating patch write sets and patch inverse indexes.

[0092] In the specific implementation process, a candidate modification set is first obtained. Each record in the candidate modification set contains at least the target relation table information, target tuple information, modified field information, pre-modification value, and post-modification value. The corresponding relation table identifier is determined in the relation table set based on the target relation table of each candidate modification. When the candidate modification set is empty, no valid patch record is output directly, and automatic submission is prohibited. When the candidate modification set is not empty, candidate modifications with the same relation table identifier, the same tuple identifier, and the same modification type are merged. Modification types include three types: addition, deletion, and update. If the merged object involves multiple modified field values ​​for the same field, the last modified value is retained according to the preset patch execution order, which is determined by the input timing or configured priority of each candidate modification, forming a valid patch atom set. The number of patch atoms in the valid patch atom set is denoted as M, where M is a positive integer. Each patch atom is recorded in a structured manner, including the modification type, the relation table identifier it affects, the modified tuple identifier, the modified field set, the pre-modification field value set, and the post-modification field value set. For patch atoms of the new type, the set of field values ​​before modification is an empty set; for patch atoms of the delete type, the set of field values ​​after modification is an empty set; for patch atoms of the update type, the set of field values ​​before modification and the set of field values ​​after modification correspond one-to-one with the fields in the set of modified fields.

[0093] Subsequently, based on the relation table identifier, modified tuple identifier, and modified field identifier of each patch atom, the set of data write positions corresponding to each patch atom is determined. The data write positions employ a three-level unified encoding composed of relation table identifier, tuple identifier, and field identifier. This encoding method can uniquely locate any field of any tuple in any relation table, providing a unified addressing space for subsequent constraint propagation and failure backtracking. A union operation is performed on the set of data write positions of all patch atoms in the valid patch atom set to form a patch write set. The patch write set is a collection of data position records; each record is encoded according to the relation table identifier, tuple identifier, and field identifier. When the same data write position is hit by multiple patch atoms, only one set record is retained, avoiding redundant processing caused by duplicate data positions. The patch write set reflects the union of all data positions involved in all candidate modifications and serves as the initial trigger input for subsequent constraint propagation. Finally, for each data position in the patch write set, all patch atoms written to that data position are recorded, forming a patch inverse index. The patch inverse index establishes a reverse mapping relationship from data position to patch atom. When multiple patch atoms write to the same data location, the patch inverse index records the identifier and execution order of each patch atom according to the preset patch execution order, so that after verification failure, it is possible to accurately trace back to all patch atoms written to that location and their execution order.

[0094] Additionally, if any of the following conditions are met: the relation table identifier of the patch atom is missing, the tuple identifier is missing, the field identifier is missing, the patch write set is empty, or the patch reverse index creation fails, the system outputs "No valid patch record" and disables auto-commit; otherwise, it outputs the patch write set and the patch reverse index. This description covers the complete processing flow from candidate modification acquisition, merging and deduplication, patch atom formation, write location determination, patch write set generation to patch reverse index creation, providing a precise data foundation for subsequent constraint propagation and failure backtracking.

[0095] Further, see Figure 3 , Figure 3 This is a detailed step diagram of step S20 in one embodiment, based on the shown... Figure 3 The step of using the patch write set as the initial seed and iteratively expanding the set of affected constraint instances and the set of affected data locations until stable to form the constraint propagation influence range includes: S21~S24: Step S21: Using the patch write set as the initial trigger input, determine the initial set of affected constraint instances and the initial set of affected data locations. The initial set of affected constraint instances consists of constraint instances that read at least one data location from the patch write set, and the initial set of affected data locations consists of the union of the data locations read by each constraint instance in the patch write set and the initial set of affected constraint instances. Step S22: In a certain round of iteration, determine the constraint instance that reads at least one data position in the current affected data position set and has not yet been included in the current affected constraint instance set, and add the constraint instance to the updated affected constraint instance set. Step S23: In each constraint instance of the updated set of affected constraint instances, read the data position that has not yet been included in the current set of affected data positions, and add the data position to the updated set of affected data positions. Step S24: When the set of affected constraint instances and the set of affected data locations no longer change, the iteration stops, and the set at the time of stopping the iteration is taken as the range of influence of the constraint propagation.

[0096] In this embodiment, using the patch write set as the initial trigger input and expanding the constraint propagation impact range through iterative expansion of constraint instances is the core mechanism for comprehensively capturing the impact of cross-table constraint propagation. The patch write set records the write locations of all candidate modifications. Data changes at these locations may alter the satisfaction status of some constraint instances or trigger new constraint instances to enter the affected range. To fully capture the constraint impact of cross-table cascading propagation, it is necessary to start from the patch write set, determine the affected constraint instances and affected data locations layer by layer, and iterate repeatedly until no new constraint instances or data locations are added. The constraint propagation impact range includes the set of affected constraint instances and the set of affected data locations. The former is the set of constraint instances that need to be checked, and the latter is the set of all data locations involved in these constraint instances. Under the conditions that instance binding and read locations are complete, existence changes have been included, and iteration is stable, this mechanism covers constraint instances reachable by the patch write set, reducing omissions caused by only checking direct write locations.

[0097] In the specific implementation process, the patch write set is first used as the initial trigger input to determine the initial set of affected constraint instances and the initial set of affected data locations. The initial set of affected constraint instances consists of constraint instances that read at least one data location from the patch write set. For each data location in the patch write set, all constraint instances that read that data location are found using a pre-established data location index, and the union of these constraint instances is taken as the initial set of affected constraint instances. The initial set of affected data locations consists of the union of the patch write set and the data locations read by each constraint instance in the initial set of affected constraint instances. This initialization process can be formally expressed as follows: the initial set of affected constraint instances equals the set of all constraint instances that read any data location from the patch write set, and the initial set of affected data locations equals the union of the patch write set and the set of data locations read by all constraint instances in the initial set of affected constraint instances. For each constraint instance in the initial set of affected constraint instances, all data locations read during constraint judgment are recorded; these data locations, together with the patch write set itself, constitute the initial set of affected data locations.

[0098] After initialization, the iterative expansion phase begins. In each iteration, firstly, constraint instances that read at least one data position from the current affected data position set and are not yet included in the current affected constraint instance set are identified and added to the updated affected constraint instance set. Specifically, all constraint instances that read any data position from the current affected data position set are searched using the data position index, and constraint instances not yet included in the affected constraint instance set are selected and added to the set. Subsequently, for each constraint instance in the updated affected constraint instance set, data positions that are not yet included in the current affected data position set are read and added to the updated affected data position set. Specifically, for each constraint instance in the updated affected constraint instance set, all data positions read are obtained, and data positions not yet included in the affected data position set are selected and added to the set. The formal expression of this iterative process is as follows: In the Nth iteration, the updated set of affected constraint instances equals the current set of affected constraint instances plus all constraint instances that have read any data position in the current set of affected data positions but have not yet been included; the updated set of affected data positions equals the current set of affected data positions plus all data positions read by constraint instances in the updated set of affected constraint instances but not yet included. Each iteration first calculates the updated set of affected constraint instances, and then calculates the updated set of affected data positions based on the updated set. That is, the expansion of data positions depends on the expansion of constraint instances, and the two form a progressive relationship.

[0099] The iteration terminates when both the set of affected constraint instances and the set of affected data locations cease to change. Iteration stops when the set of affected constraint instances after the Nth iteration is equal to the set after the (N-1)th iteration, and the set of affected data locations after the Nth iteration is equal to the set after the (N-1)th iteration. The set at the point of iteration termination is taken as the constraint propagation influence range, where the set of affected constraint instances is denoted as... The set of affected data locations is denoted as When the patch write set is empty, no effective propagation range is formed and automatic commit is prohibited. When the patch write set is not empty but there are no constraint instances that can read any data location within it, the set of affected constraint instances is set to empty, and the set of affected data locations is equal to the patch write set, and necessary query verification continues. When a stable state is not reached within the preset maximum number of iterations, an unstable range flag, along with the current set of affected constraint instances and the set of affected data locations, are output. The propagation precursor relationships recorded during the above iterative expansion process provide a recorded propagation path for reverse tracing when subsequent verification fails.

[0100] Further, see Figure 4 , Figure 4 This is a detailed step diagram of step S30 in one embodiment, based on the shown... Figure 4 The step of filtering contribution paths leading to protected result items in each query origination graph based on the set of affected data locations, and generating query origination slices and query backtracking indexes based on the contribution paths, includes S31~S36: Step S31: Obtain a pre-configured set of protected queries, wherein the set of protected queries contains at least one protected query; Step S32: For each protected query in the protected query set, obtain the query source graph of the protected query in the current state of the target database. The query source graph includes basic data location nodes, query operator nodes, intermediate result nodes, and protected result item nodes. Step S33: Based on the set of affected data locations, determine the query graph nodes in each query source graph where the set of basic contribution data locations of any query graph node intersects with the set of affected data locations, and use the determined query graph nodes as affected seed nodes; wherein, the set of basic contribution data locations is the set of all basic data locations that the corresponding node depends on or contributes to. Step S34: Traverse from the affected seed node along the direction corresponding to the data contribution edge and the execution dependency edge to the protected result item node, and include the nodes located on the corresponding contribution path into the downstream reachable node set. The data contribution edge represents the flow relationship of data from the basic data position to the query result direction, and the execution dependency edge represents the execution dependency relationship between query operators. Step S35: Based on the affected seed nodes and the set of downstream reachable nodes, extract the subgraph formed by the affected seed nodes and the set of downstream reachable nodes in the query source graph as the query source slice; Step S36: Record the protected result item node identifier, the mapping relationship between the basic data location node and the unified data location code, and the direction of each data contribution edge and execution dependency edge within the slice for each query traceability slice, and establish the query backtracking index that accesses the basic data location node from the protected result item node.

[0101] In this embodiment, based on the set of affected data locations within the constraint propagation influence range, contribution paths leading to protected result items are selected in the query sourcing graph of each protected query. Based on these contribution paths, query sourcing slices are generated, and a query backtracking index is established. This process outlines a complete transformation chain from the protected query set and constraint propagation influence range to query sourcing slices and query backtracking indexes. The processing chain ensures that the physical influence range of constraint propagation is accurately transformed into the logical filtering range for query verification. After completing the alignment of the outputs before and after and the necessary sourcing supplementation, redundant processing of irrelevant nodes during the verification and backtracking stages can be reduced.

[0102] Obtain the pre-configured set of protected queries. Protected queries are those pre-configured to maintain stable results or limit deviations during data repair. Their configuration information includes query statements, query output types, allowable deviation thresholds, and the method for generating the query source graph. Obtaining the protected query set provides a clear scope of queries for subsequent steps, ensuring that only pre-specified queries are included in the verification system. For each protected query in the protected query set, obtain the query source graph of that protected query in the current state of the target database. The query source graph contains a set of nodes and a set of edges. The edge set consists of data contribution edges and execution dependency edges. The nodes in the node set include basic data location nodes, query operator nodes, intermediate result nodes, and protected result item nodes. Basic data location nodes correspond to the field-level data locations read by the query; query operator nodes correspond to operations such as joins, filters, grouping, aggregation, or sorting during query execution; intermediate result nodes correspond to the temporary results after each operator execution; and protected result item nodes correspond to the final output items of the query. Through the above query source map, the contribution relationship between any protected result item and all the basic data locations it depends on can be accurately traced.

[0103] Using the set of affected data locations within the constraint propagation influence range as the filtering input, query graph nodes whose basic contribution data location set intersects with the affected data location set in each query source graph are identified. These identified query graph nodes are designated as affected seed nodes. The basic contribution data location set refers to the set of all basic data locations that a node depends on or contributes to: for a basic data location node, the basic contribution data location set is the data location it represents; for query operator nodes and intermediate result nodes, the basic contribution data location set is the set of all basic data locations processed or transmitted by that node; for protected result item nodes, the basic contribution data location set is the set of all basic data locations that the result item depends on. Any query graph node, including basic data location nodes, query operator nodes, intermediate result nodes, and protected result item nodes, is included in the affected seed node set if the intersection of its basic contribution data location set with the affected data location set within the constraint propagation influence range is not empty. In other words, the affected seed node set consists of all query graph nodes that satisfy the above non-empty intersection condition. Through the above filtering, all nodes in the source graph that have a direct or indirect data location association with the candidate modification are identified as affected seed nodes, which are the starting points for subsequent contribution path traversal.

[0104] Traversing from the affected seed node set along the directions corresponding to the data contribution edges and execution dependency edges to the protected result item node set yields the set of downstream reachable nodes located on the corresponding contribution paths. Data contribution edges represent the flow of data from the basic data location to the query result direction, while execution dependency edges represent the execution dependency relationship between query operators. Traversal proceeds along the directions of these two types of edges, starting from the affected seed node and gradually advancing along the positive directions of the data contribution edges and execution dependency edges until the protected result item node is reached. For any two nodes in the query origin graph, if there exists a directed path from the previous node to the next node consisting of at least one edge (data contribution edge or execution dependency edge), the next node is reachable from the previous node. The downstream reachable node set is determined as follows: for each node in the affected seed node set and each node in the protected result item node set, if there exists a directed contribution path from the affected seed node to a candidate downstream node, and the candidate downstream node is located on the contribution path from the affected seed node to the protected result item node, then the candidate downstream node is included in the downstream reachable node set. Through the above traversal, all contribution paths potentially affected by candidate modifications in the source graph are fully captured.

[0105] A query source slice is generated based on the set of affected seed nodes and the set of downstream reachable nodes. The query source slice is a subgraph induced by the union of the set of affected seed nodes and the set of downstream reachable nodes; that is, it retains only the nodes determined by the union and the directed edges between these nodes that exist in the original query source graph. The resulting subgraph is the query source slice. Essentially, the query source slice is a subgraph of the complete query source graph, containing only nodes and edges that contribute paths to the candidate modifications.

[0106] A conservative processing strategy is implemented when at least one of the following abnormal conditions is met: the query source graph is missing, the query source graph is broken, the query source graph cannot form an executable slice, or the query source graph cannot represent the appearance, disappearance, or sorting boundary changes of result items caused by additions, deletions, or non-monotonic query operators. When any of the above abnormal conditions are met, all input relations, related query operators, and protected result item nodes of the protected query are used as conservative query source slices. When the above abnormal conditions are not met and the set of affected seed nodes is empty, the protected query is marked as having no query impact and the query source slice is set to an empty set. The above conservative processing strategy ensures that when the query source graph is incomplete or cannot accurately represent changes in query semantics, query verification can still cover all potentially affected query results through a conservative scope, avoiding verification omissions caused by defects in the query source graph itself. For each non-empty query source slice, the protected result item node identifier, the mapping between the basic data location node and the unified data location code, and the direction of each data contribution edge and execution dependency edge within the slice are recorded, and a query backtracking index is established to access the basic data location node from the protected result item node. The query source slices and query backtracking indexes corresponding to each protected query are combined into a query slice set and output. The dependency relationship between the query backtracking index and the query source slices enables that when subsequent verification fails, the data can be precisely traced back to the basic data location from the protected result item node along the contribution path within the slice. The above complete processing flow ensures that the set of affected data locations within the constraint propagation influence range is accurately used to limit the query verification range, achieving a precise mapping from physical influence to logical verification range.

[0107] Further, see Figure 5 , Figure 5 This is a detailed step diagram of step S40 in one embodiment, based on the shown... Figure 5 The step of executing patch atoms in the isolated verification state to obtain the state after patch execution includes S41~S42: Step S41: Establish an isolation verification state based on the current state of the target database, and execute each patch atom sequentially according to the preset execution order based on the isolation verification state; Step S42: After all patch atoms have been executed, the final database state of the isolation verification state is taken as the post-patch state, wherein the isolation verification state is any one of the isolation forms of database snapshot, transaction copy, or database branch.

[0108] In this embodiment, executing patch atoms in the isolated verification state to obtain the post-patch execution state forms the basis for joint verification. The isolated verification state is a verification environment isolated from the current state of the target database. Executing patch atoms in this environment does not affect the actual state of the target database, ensuring the security and rollbackability of the verification process. The post-patch execution state refers to the final database state reached after all patch atoms have been executed sequentially in the isolated verification state according to a preset execution order. The pre-patch execution state corresponds to the current state of the target database, i.e., the state before the patch atoms are executed. The difference between the post-patch execution state and the pre-patch execution state reflects the actual data changes caused by the candidate modifications to the database. This difference is the common basis for subsequent constraint checks and query deviation verification. The isolated verification state can adopt any isolation form among database snapshots, transaction copies, or database branches. Different isolation forms differ in their implementation mechanisms, but all achieve the effect of isolation from the target database.

[0109] In the specific implementation process, an isolation verification state is first established based on the current state of the target database. The current state of the target database is denoted as... Based on system resource conditions and isolation requirements, one of the following methods—database snapshot, transaction copy, or database branch—is selected as the implementation method for the isolation verification state. The database snapshot method generates an independent read-only or writable snapshot by performing write-on-demand copying or full copying of the target database's storage files. The transaction copy method opens an independent transaction context, within which data modifications are not committed to the target database. The database branch method creates a logical branch or physical copy of the target database, allowing independent modification operations on the branch. Regardless of the isolation method used, the isolation verification state is logically consistent with the current state of the target database; that is, the initial state of the isolation verification state before patch execution is consistent with the current state of the target database. Exactly the same.

[0110] After the isolation verification state is established, each patch atom is executed sequentially according to a preset execution order based on this state. The preset execution order is determined by the system during the patch atom merging phase. When multiple patch atoms write to the same data location, the patch inverted index records the identifier and execution order of each patch atom according to this execution order. Setting the execution order ensures that dependencies between candidate modifications are handled correctly. The first patch atom is executed in the isolation verification state. After each patch atomic, the isolation verification state transitions from the current state to an intermediate state, denoted as [intermediate state]. For patch atoms of the "addition" type, a new tuple is inserted and the corresponding field values ​​are populated in the isolation verification state; for patch atoms of the "deletion" type, the specified tuple is removed in the isolation verification state; for patch atoms of the "update" type, the value of the specified field is modified from its original value to its modified value in the isolation verification state. Intermediate database states are recorded after each patch atom is executed. These intermediate states record the incremental changes after each patch atom is executed, providing a state basis for debugging and traceability during the verification process.

[0111] After all patch atoms have been executed, the final database state of the isolated verification state is used as the post-patch execution state. Assume the valid patch atom set contains... Each patch atom, the default execution order is... , ,..., The status after the patch is executed satisfy: That is, in order Each patch atom is applied sequentially to the initial state. Above. Status after patch execution. Compared to the state before patch execution The difference reflects the net effect of all candidate modifications. This difference will serve as a common criterion for subsequent constraint checks and query bias verification: constraint checks need to... and Constraint instance checks are performed separately in both states. Query deviation verification requires comparing the protected query in... and The output results are presented in two states. The isolation verification state is maintained until joint verification is complete. If joint verification passes, the patch is atomically committed to the target database after confirming that the target database version, field values ​​before patch modification, integrity constraint configuration version, and protected query configuration version are all consistent. If joint verification fails, the isolation verification state is discarded directly, without affecting the external database. The above description covers the complete processing flow from establishing the isolation verification state, sequential execution of atomic patches, recording intermediate states, to obtaining the final state after patch execution, providing a reliable state foundation for subsequent constraint checks and query deviation verification.

[0112] Furthermore, you can also view Figure 6 , Figure 6 This is a flowchart illustrating the second embodiment of the data repair method for constraint propagation and query tracing of the present invention, based on the shown... Figure 6Before the step of using the patch write set as the initial seed to iteratively expand the set of affected constraint instances and the set of affected data locations until stable to form the constraint propagation influence range, the method further includes steps S70~S90: Step S70: Bind each integrity constraint in the integrity constraint set to a combination of tuples in the current database state that satisfy the variable binding condition to form an existing constraint instance. The integrity constraint includes at least one of foreign key constraints, uniqueness constraints, functional dependencies, containment dependencies, and range constraints. The variable binding condition is the matching condition between the variable in the integrity constraint and the tuple field. Step S80: Based on the modification type, field value before modification, and field value after modification of the patch atom, perform incremental binding on the variable binding conditions of the integrity constraint, merge the constraint instances that are added, disappeared, or whose reading positions change due to the patch atom with the existing constraint instances to form a set of valid constraint instances. The change in reading position means that the set of data positions read by the constraint instance when it performs constraint judgment is changed due to the patch atom. Step S90: Record the set of data locations read when making constraint judgments for each valid constraint instance; perform a binding integrity check on records that lack necessary variable bindings or whose reading locations cannot be determined; records that cannot be proven to be unrelated to the current affected scope and original repair target and have not yet been resolved will fail the check.

[0113] In this embodiment, before using the patch write set as the initial seed for iterative expansion of constraint instances, a set of valid constraint instances needs to be pre-established. Integrity constraints include types such as foreign key constraints, uniqueness constraints, functional dependencies, containment dependencies, and range constraints. A constraint instance refers to an executable check unit obtained by binding an integrity constraint to variables in the current database state. To comprehensively capture all constraint instances that may be affected by candidate modifications, each integrity constraint in the integrity constraint set needs to be bound to a combination of tuples in the current database state that satisfy the variable binding conditions. Simultaneously, incremental binding is performed based on the modification type of the patch atom, the field value before modification, and the field value after modification, incorporating constraint instances added, disappeared, or whose read positions changed due to the patch atom into the set of valid constraint instances. The set of valid constraint instances is the initial input basis for subsequent constraint propagation iterative expansion; its integrity directly determines whether the scope of constraint propagation can fully cover the constraint effects passed across table cascading.

[0114] In the specific implementation process, each integrity constraint in the integrity constraint set is first bound to a combination of tuples in the current database state that satisfy the variable binding conditions, forming an existing constraint instance. The variable binding conditions are the matching conditions between variables in the integrity constraint and tuple fields. For foreign key constraints, the foreign key field value of the referencing tuple is bound to the key value of the target relation table; if the target tuple exists, its corresponding field is read; if it does not exist, an executable existence check is retained according to the MISSING rule. For functional dependencies, the variable binding conditions require matching the combination of values ​​of the determinant field with the corresponding determined factor field. Each integrity constraint is bound one by one to all combinations of tuples in the current database state that satisfy its variable binding conditions, generating an existing constraint instance set. Each constraint instance in the existing constraint instance set contains a constraint identifier, variable binding values, and all data read locations required for constraint judgment.

[0115] Subsequently, based on the modification type, pre-modification field value, and post-modification field value of the patch atom, incremental binding is performed on the variable binding conditions of the integrity constraint. For patch atoms of the addition type, the constraint instances that may be applicable after the addition are deduced based on the field values ​​of the tuple to be added. For patch atoms of the deletion type, it is distinguished whether the referrer tuple still exists: if the referrer still exists and the reference target is deleted, a foreign key check instance applicable after execution is retained or generated, the read status of the missing target position is recorded as MISSING, and it is determined in the isolation verification whether a new hard constraint violation has been formed; only when the referrer tuple itself disappears, or it is confirmed according to the constraint definition that the check is no longer applicable, is the corresponding instance recorded as a disappeared instance. For patch atoms of the update type, it is determined whether the instance's applicable status and read position have changed; if it is applicable before and after execution but the read position is different, it is recorded as a changed instance, and it is not directly considered inapplicable due to a change in read position. The above processing is based on the patch semantics for incremental deduction, and the actual execution of candidate modifications is completed in the isolation verification state. The change in read position refers to the change in the set of data positions read by the constraint instance when it performs constraint judgment due to the patch atom. The constraint instances that are added, disappeared, or whose read positions change due to the patch atom are merged with the existing set of constraint instances to form a set of valid constraint instances. The set of valid constraint instances is formed by merging the existing constraint instances with the constraint instances that are added, disappeared, or whose read positions change according to the patch semantics, and retains the applicable state and read position of each instance before and after the patch is executed; then step S20 iteratively determines the subset of affected constraint instances from this set.

[0116] For each valid constraint instance, record the set of data locations read during constraint evaluation. Each constraint instance needs to read field values ​​at several data locations during constraint evaluation, and these data locations may be distributed across multiple tuples in multiple relation tables. For foreign key constraint instances, the data locations read include the data locations of the foreign key field and the primary key field in the referenced relation table; for range constraint instances, the data locations read only include the data location of the constrained field itself. Record a complete set of read data locations for each valid constraint instance, which will be used for subsequent data location index construction and constraint propagation iteration expansion. When a constraint instance lacks necessary variable bindings or the read locations cannot be determined, record unresolved bindings in step S20 and perform binding integrity verification; if necessary bindings are missing, the binding integrity flag must be set to 0, and it is not acceptable to simply generate logs and then continue to determine that the joint verification has passed. The number of constraint instances in the set of valid constraint instances is denoted as C, the j-th constraint instance is denoted as c_j, and its set of read data locations is denoted as R(c_j). Through the above two-stage processing of existing constraint instance binding and incremental binding, under the condition that the necessary binding is complete and the read position is determinable, the effective constraint instance set provides the instantiation basis for subsequent constraint propagation; unresolved necessary binding records are blocked from passing by independent gating.

[0117] Furthermore, you can also view Figure 7 , Figure 7 This is a flowchart illustrating the implementation of the data repair method for constraint propagation and query tracing of the present invention. Figure 7 The indicated complete data processing flow takes a set of candidate modifications as input and goes through five core stages: patch atomic decomposition, constraint propagation impact range generation, query source tracing slice construction, isolation joint verification, and failure backtracking and iterative adjustment. The final output is a set of verified patch atoms along with the corresponding repair results and verification records. These five stages are not simply executed sequentially, but rather form a closed-loop processing system with feedback loops. The first four stages complete the initial verification of candidate modifications. The fifth stage triggers backtracking and patch adjustment when verification fails, driving the process back to the first stage for re-execution until verification passes or the termination condition is met. Figure 7 Solid lines with arrows indicate the forward data flow direction, while dashed lines with arrows indicate the reverse tracing and iterative rollback direction after failure, clearly distinguishing between normal processing paths and abnormal processing paths.

[0118] In the patch atom decomposition phase, the input candidate modification set is first preprocessed. Candidate modifications may involve multiple relation tables, multiple tuples, and multiple fields, and may involve multiple modifications to the same data location. This phase decomposes candidate modifications into patch atoms, which are the basic modification units at the current field grouping granularity. Their granularity is refined to a single relation table, a single tuple identifier, and a modification type, including insert, delete, and update. For update-type patch atoms, both the set of field values ​​before and after modification are recorded; for insert-type, the set of field values ​​before modification is empty; for delete-type, the set of field values ​​after modification is empty. A unified data location code composed of relation table identifiers, tuple identifiers, and field identifiers is used to determine the write position of each patch atom. A union operation is performed on the data write position sets of all patch atoms to form a patch write set. The patch write set is a set of data location records encoded according to the relation table identifier, tuple identifier, and field identifier; only one record is retained when the same data location is written by multiple patch atoms. For each data location in the patch write set, a patch inverse index is created. This index records all patch atoms written to that data location and their execution order, providing a mapping basis for locating patch atoms from data locations during subsequent failure backtracking. The patch write set and the patch inverse index constitute the data location addressing basis for all subsequent processing steps.

[0119] In the constraint propagation impact range generation phase, the patch write set is used as the initial seed input to the constraint propagation engine. A constraint instance is an executable check unit obtained by variable binding of integrity constraints in the current database state. When the data location in the patch write set changes, the satisfaction state of some constraint instances may change accordingly. These constraint instances then propagate the data locations they read to the affected range, triggering new constraint instances and forming a cascading propagation effect. To fully capture this effect, this phase executes an iterative expansion process: each iteration triggers new constraint instances to be added to the affected constraint instance set from the current affected data location set, and the affected data location set is expanded by the data locations read by the newly added constraint instances. This iteration is repeated until both sets no longer change, reaching a stable state and forming the constraint propagation impact range. In the initial trigger and each round of iterative expansion, the first type of directed propagation precursor edge from the data location to the constraint instance and the second type of directed propagation precursor edge from the constraint instance to its read data location are recorded synchronously. These two types of directed edges together constitute the directed propagation precursor relationship. This relationship records the propagation trigger chain during constraint propagation, showing which data location triggered which constraint instance, and which data locations were included in the scope of influence by that constraint instance, providing a path for reverse tracing when subsequent constraint checks fail.

[0120] In the query source slicing construction phase, the set of affected data locations within the constraint propagation impact range is input as a filtering condition to the query source processing module. Protected queries are pre-configured queries that require stable results or limited deviations during the repair process; each protected query has a corresponding query source graph. The query source graph is a directed graph representing the contribution relationship between query result items and basic data locations, containing basic data location nodes, query operator nodes, intermediate result nodes, and protected result item nodes, with edges including data contribution edges and execution dependency edges. This phase uses the set of affected data locations as a filtering condition, retaining only contribution paths leading to protected result items and passing through affected data locations in each query source graph, thus generating query source slices. Based on this, a query backtracking index is established to access basic data location nodes from protected result item nodes. This index records the protected result item node identifier, the mapping relationship between basic data location nodes and unified data location codes, and the direction of each edge within the slice. Through the above processing, the physical scope of constraint propagation is transformed into the logical filtering scope of query verification. After completing the alignment of the outputs before and after and the necessary source tracing supplementation, the repeated processing of irrelevant nodes in the verification and backtracking stages can be reduced.

[0121] During the isolation and joint verification phase, the before and after states and query outputs are obtained according to step S40, and the source tracing slices are supplemented. Residual constraint violations and newly added hard constraint violations are counted separately, and the deviation of each protected query is calculated. Combining the necessary binding integrity, the original repair target, and the task completion and validity status, the joint verification is judged according to the unified conditions of step S40. If it passes, the submission verification is performed, and the repair result is output after successful submission.

[0122] When the joint verification result fails and the preset stopping condition is not met. Figure 7 The process follows the dotted path to enter the failure reverse tracing and iterative adjustment phase; when the preset stopping condition is reached, the current repair is terminated and the failure record is output. This phase first determines the tracing path based on the failure verification tasks in the joint verification results, distinguishing between two types of failures: for constraint check failures, starting from the corresponding constraint instance node, traversing in the reverse direction of the directed propagation predecessor relationship, and forming a set of failure-related data locations for the traversed data locations that belong to the patch write set; for query deviation verification failures, starting from the changed result item node, tracing back along the query backtracking index to the data location in the patch write set within the query source slice. The traced failure-related data locations are located to the associated patch atom set via the patch reverse index, and these patch atoms are processed by patch revocation, field splitting, or field value adjustment. After adjustment, all intermediate calculation results before adjustment are marked as invalid, including the constraint propagation impact range, directed propagation predecessor relationship, query source slice, query backtracking index, and verification tasks, and all the above phases are re-executed based on the adjusted patch atoms. Figure 7 The dashed loop in the diagram clearly illustrates this iterative mechanism: after each adjustment, the process rolls back to the starting point and is re-executed, without reusing any invalid intermediate results, until the joint verification result passes or the preset stopping condition is met; after passing, it is submitted according to the unified submission verification rules, and the repair result and verification record are output after successful submission; if it fails and the stopping condition is met, it rolls back and outputs the failure record.

[0123] Furthermore, you can also view Figure 8 , Figure 8 This is a schematic diagram of the data repair method for constraint propagation and query tracing according to the present invention. Specifically, it is shown... Figure 8 This paper demonstrates the overall architecture of the cross-table data repair system based on constraint propagation and query sourcing proposed in this application, as well as the interaction relationships between its modules. The architecture is based on a unified data location encoding system and comprises five core functional modules: a patch building module, a constraint propagation engine, a query slicing module, an isolation verification engine, and a failure analysis engine. It takes a set of candidate modifications as input and verified patch atoms and repair verification records as output, constructing a complete processing framework covering modification indexing, dynamic definition of impact scope, precise limitation of verification scope, collaborative execution of dual verification, and failure-related patch location and iterative adjustment. The connections between the five modules are not a unidirectional pipeline model, but a closed-loop architecture including feedforward execution paths and feedback adjustment paths. The feedforward path carries the normal processing flow, while the feedback path carries the reverse tracing and iterative recalculation process after failure. Figure 8 The solid lines with arrows indicate the direction of feedforward data flow between modules, while the dashed lines with arrows indicate the direction of feedback tracing and rollback after failure, clearly distinguishing between normal processing paths and abnormal processing paths.

[0124] The patch building module resides in the data entry layer of the architecture, responsible for transforming the original candidate modifications into a data location index structure that all subsequent modules can uniformly recognize. This module receives a set of candidate modifications as input and executes four core functions: patch atom decomposition, unified data location encoding mapping, patch write set generation, and patch reverse index establishment. During patch atom decomposition, the module breaks down candidate modifications into basic modification units at the current field grouping granularity. Each patch atom corresponds to a single relation table, a single tuple identifier, and a modification type. During unified data location encoding mapping, a three-level encoding system consisting of relation table identifiers, tuple identifiers, and field identifiers is used to determine the write position of each patch atom. During patch write set generation, a union operation is performed on the data write position set of all patch atoms to form the patch write set. During patch reverse index establishment, for each data position in the patch write set, all patch atoms written to that data position and their execution order are recorded. The output of the patch building module includes the patch write set and the patch reverse index. The patch write set serves as the initial trigger input for the constraint propagation engine, and the patch reverse index serves as the location basis for the failure analysis engine. The aforementioned unified data location coding system runs through the entire architecture process, ensuring that candidate modification, constraint instance read location, basic data location node in the query traceability graph, and failure backtracking results are all mapped to the same field-level addressing space.

[0125] The constraint propagation engine resides in the core computation layer of the architecture. It is responsible for iteratively expanding constraint instances using patch write sets as initial seeds, generating the constraint propagation influence range, and recording directed propagation precursor relationships. This engine has direct data dependencies with the patch building module and the query slicing module. After receiving patch write sets from the patch building module, the constraint propagation engine first performs current state binding on integrity constraints and incremental binding based on patch semantics, merging existing constraint instances with newly added, disappeared, and read-position-changed constraint instances to form a valid constraint instance set. Then, using the patch write sets as initial trigger input, it executes an iterative expansion process: each iteration triggers a new constraint instance to be added to the affected constraint instance set from the current affected data position set, and the affected data position set is expanded by the data position read by the newly added constraint instance. This iteration repeats until both sets no longer change, reaching a stable state and forming the constraint propagation influence range. In the initial trigger and each round of iterative expansion, the first type of directed propagation precursor edge from the data position to the constraint instance and the second type of directed propagation precursor edge from the constraint instance to its read data position are recorded synchronously. These two types of directed edges together constitute the directed propagation precursor relationship. The constraint propagation engine outputs the constraint propagation influence range and the directed propagation predecessor relationship. The set of affected data locations in the constraint propagation influence range serves as the filtering input for the query slicing module, and the directed propagation predecessor relationship serves as the basis for the reverse tracing path of the failure analysis engine when constraint checks fail.

[0126] The query slicing module resides in the validation scope limitation layer of the architecture, responsible for transforming the physical impact scope output by the constraint propagation engine into the logical scope of query validation. This module has a direct interface with both the constraint propagation engine and the isolation validation engine. After receiving the set of affected data locations from the constraint propagation engine, the query slicing module obtains the query origin graph of each protected query in the current state of the target database. The query origin graph is a directed graph representing the contribution relationships between query result items, query operators, intermediate result nodes, and basic data location nodes, with edges including data contribution edges and execution dependency edges. Using the set of affected data locations as a filtering criterion, this module identifies query graph nodes in each query origin graph where the basic contribution data location set intersects with the affected data location set. These nodes are then identified as affected seed nodes. Traversing from the affected seed nodes along the directions corresponding to the data contribution edges and execution dependency edges to the protected result item nodes, nodes located on the corresponding contribution paths are included in the downstream reachable node set. Finally, the subgraph induced by the affected seed nodes and the downstream reachable node set is extracted as the query origin slice. Based on this, a query backtracking index is established to access the basic data location nodes from the protected result item nodes. The query slicing module outputs query source slices and query backtracking indexes to the isolation verification engine. The query source slices limit the coverage of query deviation verification, while the query backtracking indexes provide a path for the failure analysis engine to trace back when query deviation verification fails.

[0127] The isolation verification engine resides in the verification execution layer of the architecture, responsible for executing patch atoms and performing dual verification in the isolated environment. This engine has data dependencies on the patch building module, constraint propagation engine, and query slicing module, and is the final execution node in the feedforward path. The isolation verification engine receives a set of patch atoms from the patch building module, the scope of constraint propagation from the constraint propagation engine, and query source slices and query backtracking indexes from the query slicing module. Based on these inputs, the engine first establishes an isolation verification state, executing each patch atom sequentially according to the execution order, resulting in the post-patch execution state. Using the difference between the post-patch execution state and the pre-patch execution state as the criterion, the engine simultaneously performs verification on two dimensions: constraint checking, which checks whether the affected constraint instances satisfy integrity constraints after patch execution; and query deviation verification, which checks the protected result items in the query source slice, calculating the deviation value between the outputs of each protected query before and after patch execution. The engine forms a judgment result according to the joint verification conditions in step S40.

[0128] The failure analysis engine resides in the feedback processing layer of the architecture. It is responsible for identifying failed tasks, determining reverse tracing paths, locating associated patch atoms, and generating patch adjustment strategies when joint validation results fail. A direct feedback loop exists between this engine and the patch building module. After receiving the joint validation results from the isolated validation engine, the failure analysis engine first identifies the validation tasks that caused the failure and organizes them into a set of failed validation tasks. Depending on the type of failed validation task, the engine selects different reverse tracing paths: for constraint check failures, it traces back along the directed propagation predecessor relationship provided by the constraint propagation engine, starting from the corresponding constraint instance node, to the data location in the patch write set; for query deviation validation failures, it traces back along the query backtracking index provided by the query slicing module, starting from the changed result item node, to the data location in the patch write set within the query source slice. The failed data locations obtained through tracing are located to the associated patch atom set via the patch reverse index. These patch atoms are then processed by patch revocation, field splitting, or field value adjustment. After adjustment, the engine triggers the feedback loop, sending the adjusted patch atoms back to the patch building module and marking all intermediate calculation results before adjustment as invalid. Figure 8 The dashed feedback loop illustrates this iterative mechanism. After each adjustment, the process reverts to the patch build module for re-execution, without reusing any invalid intermediate results, until the joint verification result output by the isolated verification engine passes or the preset stopping condition is met. Upon passing, the patch is submitted according to the unified submission verification rules, and the repair result and verification record are output upon successful submission. If the patch fails and the stopping condition is met, the process rolls back and outputs a failure record. These five modules, through explicit data interfaces and feedback loops, achieve a complete closed-loop process from candidate modifications to verified patches.

[0129] This application provides a constraint propagation and query tracing data repair device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the constraint propagation and query tracing data repair method in the first embodiment described above.

[0130] The following is for reference. Figure 9This document illustrates a schematic diagram of a data repair device suitable for implementing constraint propagation and query tracing embodiments of this application. The data repair device for constraint propagation and query tracing embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 9 The data repair device for constraint propagation and query tracing shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0131] like Figure 9 As shown, the constraint propagation and query tracing data repair device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the constraint propagation and query tracing data repair device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the constraint propagation and traceability data repair device to exchange data wirelessly or via wired communication with other devices. Although constraint propagation and traceability data repair devices with various systems are shown in the figures, it should be understood that it is not required to implement or possess all of the systems shown. More or fewer systems can be implemented alternatively.

[0132] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0133] The data repair device for constraint propagation and query tracing provided in this application, employing the data repair method for constraint propagation and query tracing in the above embodiments, can solve the technical problems of insufficient accuracy and reliability in cross-table data repair caused by the difficulty in effectively defining the verification scope, the difficulty in fully capturing the impact of constraints, and the difficulty in locating failure-related patches. Compared with the prior art, the beneficial effects of the data repair device for constraint propagation and query tracing provided in this application are the same as those of the data repair method for constraint propagation and query tracing provided in the above embodiments, and other technical features in this data repair device for constraint propagation and query tracing are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0134] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0135] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0136] This application provides a storage medium, which is a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon. The computer-readable program instructions are used to execute the constraint propagation and query tracing data repair method in the above embodiments.

[0137] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0138] The aforementioned computer-readable storage medium may be included in the constraint propagation and query tracing data repair device; or it may exist independently and not be assembled into the constraint propagation and query tracing data repair device.

[0139] The aforementioned computer-readable storage medium carries one or more programs. When the aforementioned one or more programs are executed by the constraint propagation and query tracing data repair device, the constraint propagation and query tracing data repair device implements the technical content of the constraint propagation and query tracing data repair method embodiment shown above.

[0140] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0141] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0142] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0143] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described constraint propagation and query tracing data repair method. This solves the technical problems in existing cross-table data repair where the verification scope is difficult to define effectively, the impact of constraints is difficult to fully capture, and failure-related patches are difficult to locate, leading to insufficient accuracy and reliability in cross-table repair. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the constraint propagation and query tracing data repair method provided in the above embodiments, and will not be repeated here.

Claims

1. A data repair method based on constraint propagation and query tracing, characterized in that, Includes the following steps: Candidate modifications are broken down into patch atoms. A unified data location encoding is used to generate the write position of each patch atom to form a patch write set. A patch inverse index is generated based on the write position. Each patch atom is a basic modification unit grouped by the current field for a single relation table, a single tuple identifier, and a modification type. The modification type includes add, delete, and update types. The unified data location encoding consists of a relation table identifier, a tuple identifier, and a field identifier. The patch inverse index is an index pointing from a data location to one or more patch atoms written to that data location. Before the initial verification, the original set of repair targets with executable acceptance predicates is recorded, and this original set of repair targets remains unchanged during subsequent patch adjustments and re-verification. Using the patch write set as the initial seed, the set of affected constraint instances and the set of affected data locations are iteratively expanded until they stabilize to form the constraint propagation influence range. In each iteration, a new constraint instance is triggered by the current set of affected data locations to be added to the set of affected constraint instances, and the set of affected data locations is expanded by the data locations read by the newly added constraint instances. During the iteration process, the directed propagation predecessor relationship between data locations and constraint instances is recorded. Based on the set of affected data locations, the contributing paths leading to the protected result items are filtered in each query source graph, and query source slices and query backtracking indexes are generated based on the contributing paths; An isolation verification state is established based on the current state of the target database. The query output and query source information of each protected query in the state before patch execution are recorded. In the isolation verification state, patch atoms are executed to obtain the state after patch execution, and the query output and corresponding query source information of each protected query in the state after patch execution are obtained. According to the query output before and after patch execution, the result items are aligned, and the result items with added, disappeared, changed values, or changed sorting are identified. Based on the contribution path of the corresponding result items in the query source graph before and after patch execution, the query source slice and query backtracking index are supplemented. Constraint checks are performed on the affected constraint instances in the scope of constraint propagation. Normalized query deviation verification is performed on the protected result items in the supplemented query source slice relative to the query output benchmark before patch execution. Based on whether the necessary binding is complete, whether the original repair goal is achieved, whether the verification task set is not empty, whether all necessary verification tasks are completed and the results are valid, whether the residual constraint violation set and the newly added hard constraint violation set are both empty, and whether each query deviation does not exceed the corresponding threshold, a joint verification result is formed. If the joint verification result passes, the patch atom is submitted to the target database according to the submission verification rules, and the repair result and verification record are output after successful submission. If the joint verification result indicates that there is a verification failure, if the necessary binding is incomplete, the original repair target cannot be verified, or a traceable failure task cannot be obtained, the current repair is terminated and a failure record is output. Otherwise, the traceability path is determined according to the failed verification task in the joint verification result, and the data position of the patch write set is traced back based on the traceability path. If the failed verification task is a constraint check failure, the data position in the patch write set is traced back along the directed propagation predecessor relationship starting from the corresponding constraint instance node. If the failed verification task is a query deviation failure, the data position in the patch write set is traced back along the query backtracking index in the query traceability slice starting from the changed result item node. The patch atom corresponding to the data location is located using the patch inverse index. The patch atom is adjusted, and a patch write set and patch inverse index are regenerated. Based on the regenerated patch write set and patch inverse index, constraint instance iteration triggering, query tracing slice filtering, and isolation joint verification are re-executed until the joint verification result passes or a preset stopping condition is met. When the joint verification result passes, the iterative adjustment process is terminated, the patch is submitted according to the submission verification rules, and the repair result and verification record are output after successful submission. When the joint verification result fails and the preset stopping condition is met, or the submission fails, the current repair is terminated and uncommitted modifications are rolled back, and a failure record is output. The submission verification rules include verifying the target database version, field values ​​before patch modification, integrity constraint configuration version, and protected query configuration version within the same submission transaction or a submission mechanism with equivalent atomic verification capabilities. If any of these are inconsistent, the original verification result is prohibited from being used, the isolation verification state is re-established, and the verification is re-performed.

2. The data repair method for constraint propagation and query tracing as described in claim 1, characterized in that, The steps of splitting candidate modifications into patch atoms, generating the write position of each patch atom using unified data location encoding to form a patch write set, and generating a patch inverse index based on the write position include: Obtain the candidate modification set, and determine the corresponding relation table identifier based on the target relation table of each candidate modification; During the initial construction, candidate modifications with the same relation table identifier, the same tuple identifier, and the same modification type are merged. For multiple modified field values ​​of the same field after merging, the final modified value is retained according to the preset patch execution order to form a set of effective patch atoms. The preset patch execution order is determined by the input timing of each candidate modification or the priority of the configuration. Based on the relation table identifier, modified tuple identifier, and modified field identifier that each patch atom acts upon, determine the set of data write locations corresponding to each patch atom; Perform a union operation on the set of data write locations of all patch atoms to form the patch write set; For each data location in the patch write set, all patch atoms written to that data location are recorded to form the patch inverse index. When the same data location is written by multiple patch atoms, the patch inverse index records the identifier and execution order of each patch atom according to the preset patch execution order.

3. The data repair method for constraint propagation and query tracing as described in claim 1, characterized in that, Before the step of using the patch write set as the initial seed to iteratively expand the set of affected constraint instances and the set of affected data locations until stable to form the constraint propagation influence range, the method further includes: Each integrity constraint in the integrity constraint set is bound to a combination of tuples in the current database state that satisfy the variable binding conditions to form an existing constraint instance. The integrity constraints include at least one of foreign key constraints, uniqueness constraints, functional dependencies, containment dependencies, and range constraints. The variable binding conditions are the matching conditions between the variables in the integrity constraints and the tuple fields. Based on the modification type, field value before modification, and field value after modification of the patch atom, incremental binding is performed on the variable binding conditions of the integrity constraint. Constraint instances that are added, disappear, or whose read positions change due to the patch atom are merged with the existing constraint instances to form a set of valid constraint instances. The change in read position refers to the change in the set of data positions read by the constraint instance when it performs constraint judgment due to the patch atom. For each valid constraint instance, record the set of data locations read when making constraint judgments; perform binding integrity verification on records that lack necessary variable bindings or whose read locations cannot be determined, and fail the verification if the record cannot be proven to be unrelated to the current affected scope and the original repair target and has not yet been resolved.

4. The data repair method for constraint propagation and query tracing as described in claim 1, characterized in that, The step of using the patch write set as the initial seed and iteratively expanding the set of affected constraint instances and the set of affected data locations until stable to form the constraint propagation impact range includes: Using the patch write set as the initial trigger input, determine the initial set of affected constraint instances and the initial set of affected data locations. The initial set of affected constraint instances consists of constraint instances that read at least one data location from the patch write set, and the initial set of affected data locations consists of the union of the data locations read by each constraint instance in the patch write set and the initial set of affected constraint instances. During a certain round of iteration, determine the constraint instance that reads at least one data location in the current set of affected data locations and has not yet been included in the current set of affected constraint instances, and add the constraint instance to the updated set of affected constraint instances. In each constraint instance of the updated set of affected constraint instances, read the data locations that have not yet been included in the current set of affected data locations, and add the data locations to the updated set of affected data locations; The iteration stops when both the set of affected constraint instances and the set of affected data locations no longer change, and the set at which the iteration stops is taken as the range of influence of the constraint propagation.

5. The data repair method for constraint propagation and query tracing as described in claim 1, characterized in that, The step of recording the directed propagation predecessor relationship between data location and constraint instance during the iteration process includes: During the iteration process, the triggering events based on the data location and the constraint instance are recorded as first-type directed propagation precursor edges and second-type directed propagation precursor edges. Specifically, in the initial triggering phase and each iteration expansion phase, when the data location triggers the constraint instance to enter the set of affected constraint instances, the first-type directed propagation precursor edge between the data location and the constraint instance is recorded. The data relationship of the data location read by the constraint instance being included in the set of affected data locations is recorded as the second-type directed propagation precursor edge. When there are multiple triggering data locations for the same newly added constraint instance, all first-type directed propagation precursor edges are retained. The first type of directed propagation predecessor edge and the second type of directed propagation predecessor edge recorded are used to generate the directed propagation predecessor relationship.

6. The data repair method for constraint propagation and query tracing as described in claim 1, characterized in that, The step of filtering contribution paths leading to protected result items in each query origination graph based on the set of affected data locations, and generating query origination slices and query backtracking indexes based on the contribution paths, includes: Obtain a pre-configured set of protected queries, wherein the set of protected queries contains at least one protected query; For each protected query in the protected query set, obtain the query origin graph of the protected query in the current state of the target database. The query origin graph includes basic data location nodes, query operator nodes, intermediate result nodes, and protected result item nodes. Based on the set of affected data locations, in each query tracing graph, determine the query graph nodes where the set of basic contribution data locations of any query graph node intersects with the set of affected data locations, and use the determined query graph nodes as affected seed nodes; wherein, the set of basic contribution data locations is the set of all basic data locations that the corresponding node depends on or contributes to; Traverse from the affected seed node along the direction corresponding to the data contribution edge and the execution dependency edge to the protected result item node, and include the nodes located on the corresponding contribution path into the downstream reachable node set. The data contribution edge represents the flow relationship of data from the basic data position to the query result direction, and the execution dependency edge represents the execution dependency relationship between query operators. Based on the affected seed nodes and the set of downstream reachable nodes, a subgraph induced by the affected seed nodes and the set of downstream reachable nodes is extracted from the query origin graph as the query origin slice; Record the protected result item node identifier, the mapping relationship between the basic data location node and the unified data location code, and the direction of each data contribution edge and execution dependency edge within the slice for each query traceability slice, and establish the query backtracking index that accesses the basic data location node from the protected result item node.

7. The data repair method for constraint propagation and query tracing as described in claim 1, characterized in that, The steps of executing patch atoms in the isolated verification state to obtain the post-patch execution state include: An isolation verification state is established based on the current state of the target database, and each patch atom is executed sequentially according to a preset execution order based on the isolation verification state. After all patch atomic operations are completed, the final database state of the isolation verification state is taken as the post-patch state, wherein the isolation verification state is any one of the following isolation forms: database snapshot, transaction copy, or database branch.

8. The data repair method for constraint propagation and query tracing as described in claim 1, characterized in that, The steps include locating the patch atom corresponding to the data position using the patch inverse index, adjusting the patch atom, regenerating the patch write set and patch inverse index, and re-executing constraint instance iteration triggering, filtering query tracing slices based on the regenerated patch write set and patch inverse index, and executing the adjusted patch atom until the joint verification result passes or reaches the preset stopping condition. The constraint propagation influence range, the directed propagation precursor relationship, the query source tracing slice, the query backtracking index, the joint verification result, the constraint check result, and the query deviation verification result formed before the adjustment are marked as invalid; The patch write set and patch inverse index are regenerated based on the adjusted patch atoms; the original set of repair targets and their acceptance predicates recorded before the first verification are retained, and all original repair targets are re-verified after each round of isolation execution; Using the newly generated patch write set as the initial seed, the iterative expansion of the constraint instance is re-executed to reshape the constraint propagation influence range, and the directed propagation predecessor relationship is re-recorded; Based on the set of affected data locations in the newly formed constraint propagation impact range, the contributing paths are re-selected in each query source graph to regenerate query source slices and query backtracking indexes. Based on the current confirmed state of the target database, the isolation verification state is re-established, and the adjusted patch atoms are executed in it. The constraint checks are re-executed on the currently affected constraint instances, and the query deviation verification is re-executed to form a new joint verification result. When the new joint verification result fails and the preset stopping condition is not met, the failed verification task is re-identified, the associated patch atom is located and adjusted, and the above steps of regeneration and re-verification are repeated. When the new joint verification result passes, the iteration stops, and the repair result and verification record are output after the submission is verified and successfully completed. When the new joint verification result fails and the preset stopping condition is met, or the submission fails, the current repair is terminated and the unsubmitted modifications are rolled back, and the failure record is output.

9. A data repair device for constraint propagation and query tracing, characterized in that, The device includes a processor and a memory, wherein the memory stores a computer program, and when the processor executes the computer program, it implements the data repair method for constraint propagation and query tracing as described in any one of claims 1 to 8.

10. A storage medium storing a computer program thereon, wherein when the computer program is executed by a processor, it implements the data repair method for constraint propagation and query tracing as described in any one of claims 1 to 8.

Images