Pith. sign in

REVIEW 2 major objections 5 minor 31 references

EviDC claims that organizing existing denial constraints into a prefix tree and expanding evidence only along reachable violation paths reduces intermediate evidence and improves runtime in incremental DC discovery.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

T0 review · deepseek-v4-flash

2026-07-31 23:13 UTC pith:TMMMV4YQ

load-bearing objection The pruning idea is fresh, but the DCTrie traversal silently misses violations for numeric DCs containing ≤, ≥, or ≠ — a load-bearing correctness bug. the 2 major comments →

arxiv 2607.24021 v1 pith:TMMMV4YQ submitted 2026-07-27 cs.DB

EviDC: A Violation-Guided Algorithm for Incremental Denial Constraint Discovery

Qian Zhou , Xixian Han , Xiaolong Wan This is my paper
classification cs.DB
keywords denial constraintsincremental discoveryevidence constructionprefix treeDCTriedata qualityintegrity constraintsviolation-guided pruning
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

EviDC sets out to show that existing denial constraints can guide the construction of incremental evidence, rather than being checked only after evidence is built. The algorithm organizes the current constraint set into a prefix tree, DCTrie, whose root-to-leaf paths are potential violation paths, and expands evidence for inserted tuples only along reachable branches. The paper reports that this cuts intermediate evidence and runtime compared with IncDC and 3DC in most tested scenarios, with larger gains at higher insertion ratios and dataset sizes. A sympathetic reader would take away that incremental constraint maintenance can be made substantially cheaper by letting the constraints themselves steer the search.

Core claim

The central claim is that for incremental denial-constraint discovery under tuple insertions, the set of existing DCs can be repurposed as a trie of violation paths; during incremental evidence construction, each tuple-pair context is refined attribute group by attribute group, and whenever its active set of reachable trie nodes becomes empty, the context is pruned. EviDC is the concrete algorithm that implements this, and the experiments show that it reduces intermediate evidence and runtime in most scenarios, becoming more effective as insertion ratio and dataset size grow. The paper also shows that building DCTrie is far cheaper than building full evidence sets or indexes.

What carries the argument

DCTrie is the load-bearing structure: a prefix-sharing tree in which each DC (and its symmetric form) is inserted as a path across attribute-group layers, with wildcard nodes for attributes a DC does not constrain. Evidence construction proceeds in the same layer order; each evidence context stores the current right-tuple set, partial evidence, and an Active set of trie nodes; context splitting and mask-based evidence refinement advance only along reachable nodes, and an empty Active set terminates the context.

Load-bearing premise

The pruning is sound only if the fixed attribute-group order, the three-direction grouping of numerical predicates, and wildcard inheritance preserve every way a tuple pair can satisfy a DC path; if any combination is missed, a real violation is silently pruned.

What would settle it

Log every pruned evidence context during an EviDC run and replay the same inserted tuples through an exhaustive verifier that checks all tuple pairs against every existing DC; if any tuple pair that violates a DC appears in a pruned context, the pruning has discarded a real violation. A cheaper spot-check: construct a DC containing t.A != s.A on a numerical attribute, insert a tuple pair with t.A < s.A, and verify that EviDC still reports the violation.

Watch this falsifier. Get emailed when new claim-graph text bears on it.

Share X Bluesky LinkedIn Reddit HN

If this is right

  • Intermediate evidence volume drops because tuple-pair contexts that cannot reach any DC leaf are pruned early.
  • Runtime is reduced by about 50% versus 3DC in most scenarios, and the gap grows with insertion ratio.
  • DCTrie construction is sub-second on most datasets, whereas 3DC and IncDC spend hundreds of seconds preprocessing.
  • Memory usage is lower because only surviving evidence contexts and the trie are kept, not full historical evidence sets.
  • The method scales roughly linearly with data size in the tested settings.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The same violation-path idea could be applied to other dependency types (FDs, UCCs, order dependencies) by encoding their violation witnesses as paths.
  • If DCTrie were updated incrementally as constraints are repaired, the preprocessing advantage could extend to continuous maintenance workloads.
  • The single-predicate repair strategy is a bottleneck; a multi-predicate extension guided by the trie could yield tighter repaired constraints, at higher enumeration cost.
  • The model assumes clean comparison semantics; null values or non-standard collations would break the direction grouping and would need explicit handling.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit.

Referee Report

2 major / 5 minor

Summary. The paper proposes EviDC, an incremental denial-constraint discovery algorithm for tuple insertions. It organizes the existing DC set into a prefix trie called DCTrie, treats each root-to-leaf path as a potential violation path, and during incremental evidence construction advances only along active trie nodes, pruning contexts that cannot reach any remaining path. It then removes invalid DCs and repairs them by single-predicate extension. Experiments on eleven datasets compare runtime, intermediate evidence size, memory, and scalability against 3DC* and IncDC, reporting substantial savings in most settings, and a brute-force verifier reports exact precision/recall on four datasets.

Significance. If correct, the central idea is worthwhile: using the structure of existing DCs to guide evidence construction is a natural way to avoid materializing evidence that cannot match any DC, and the empirical results suggest the pruning can be effective. The paper provides correctness theorems, a brute-force invalid-DC check on four datasets, and comparisons against re-implemented and public baselines. However, the completeness claim currently fails for a common class of numerical predicates because the trie representation and the refinement directions are not aligned. The contribution is therefore conditional on a corrected representation and re-validated experiments.

major comments (2)
  1. [§IV-B, Algorithms 2/4/5, Theorem 4.1] The refinement procedure is incomplete for numerical predicates. Section IV-B groups the six numerical operators into three direction sets, but Algorithms 4–5 advance only with concrete peq/plt/pgt, and Algorithm 2 stores each DC predicate as an exact node label on one root-to-leaf path. Predicates ≤, ≥, and ≠ are true in more than one direction, so a path stored under one label cannot be reached when refinement follows another satisfying direction; the context is pruned. Concretely, for R(A numeric, B categorical) and φ=¬(t.A≠s.A ∧ t.B=s.B), which holds on r={(1,'a',0),(1,'a',1),(2,'b',2)}, inserting t4=(0,'a',3) violates φ via (t4,t1). The DCTrie path contains A≠, but the less-than refinement calls T.ADVANCE(plt), which does not follow a node labeled ≠, so the violating pair is pruned and Theorem 4.1 fails.
  2. [§V-A, Table IV] The brute-force verification covers only FD15, Hospital, Claim, and Atom. It checks invalid-DC sets, but nothing in the paper indicates that those experiments exercise the numerical operators ≤, ≥, or ≠. Since the completeness bug above concerns exactly those operators, the reported precision/recall cannot validate Theorem 4.1. A targeted correctness test with DCs containing these predicates—or a corrected proof—is needed, and the evidence-size/runtime measurements should be repeated under the fixed representation, since a complete representation may require replicating paths across multiple direction branches.
minor comments (5)
  1. [§IV-B, Algorithm 2] T.ADVANCE is never formally defined. The text says nodes correspond either to a predicate or to a set of simultaneously satisfied predicates, while Algorithm 2 creates nodes labeled by individual predicates. Clarify the mapping between DC predicates, direction groups, and trie labels; the correctness proof depends on this.
  2. [§IV-E, Theorem 4.2] The proof reuses the variable e inconsistently: it first denotes a violating evidence in Eφ and later denotes an arbitrary evidence that falsifies the repaired DC. Rewrite the proof by observing that any evidence containing φ′ also violates φ, so it belongs to Eφ and cannot contain p ∈ Padd.
  3. [Algorithm 2, lines 16–18] If a DC contains more than one predicate from the same attribute group, the recursive insertion places only one of them on each resulting path. State explicitly that minimal DCs are assumed to have at most one predicate per attribute group, or handle multiple same-group predicates in the trie construction.
  4. [Figures 2–3] The node labels D0–D15 and the green nodes in Figure 2 are not explained in the caption or text, making the worked example hard to follow. Also, Figure 1 contains the typo 'DCTire Builder'.
  5. [§V-A] The reimplementation 3DC* is not released. Given the large reported speedups, releasing the artifact (EviDC and the 3DC* reimplementation) would substantially strengthen reproducibility.

Circularity Check

0 steps flagged

No significant circularity: DCTrie-guided pruning is an empirical optimization, not a self-referential prediction.

full rationale

EviDC does not derive a prediction from a fitted input. DCTrie is built deterministically from the existing DC set Σ (Algorithms 1-2), and incremental evidence construction (Section IV-C) is an invariant-based pruning scheme: contexts advance only along trie nodes labeled by the actual refined predicate or inherited wildcards, and a context is pruned only when its active set becomes empty. Theorem 4.1 is a standard completeness invariant, not an assertion that is true merely by definition of the pruning; even if the numerical direction grouping in Section IV-B creates a genuine soundness concern for predicates such as ≤, ≥, or ≠ under the single peq/plt/pgt refinement in Algorithm 5, that is a correctness risk for the soundness pass, not a circular reduction of the result to its inputs. The performance claims are empirical comparisons against external implementations (IncDC; reimplemented 3DC*) and a brute-force verifier; no parameter is fitted to the measured evidence sizes or runtimes. The only plausible self-reference is the IncDC citation, but it is used as a baseline and is not load-bearing. Section V-C even acknowledges DCTrie overhead, so the evidence-reduction claim is falsifiable. No circular step was found.

Axiom & Free-Parameter Ledger

0 free parameters · 3 axioms · 1 invented entities

EviDC introduces no fitted constants. Its load-bearing assumptions are domain-modeling choices about the predicate space: the three-direction partitioning of numerical attributes, the completeness of symmetric insertion into DCTrie, and the safety of early pruning when the Active set is empty. The invented entity (DCTrie) is an algorithmic device rather than a physical postulate. The evaluation design, where violation tuples are generated from the initial DC set, is the main circularity-adjacent choice in the paper.

axioms (3)
  • domain assumption The predicate space is partitioned into attribute groups, with categorical groups containing exactly one equality and one inequality predicate, and numerical groups into three directions: {=,≥,≤}, {>,≥,≠}, {<,≤,≠}.
    Introduced in Section IV-B and used by Algorithm 5. The paper asserts these three directions are the conditions that can be simultaneously satisfied, but for a tuple pair (t,s), the predicates t.A=s.A, t.A≥s.A, t.A≤s.A, t.A>s.A, t.A≠s.A are not all mutually exclusive in a simple way. The direction sets overlap (e.g., = is in all three sets), which the paper handles with masks, but the assumption that three directions suffice for correct evidence refinement is load-bearing for the pruning. A wrong grouping could cause a path to be missed.
  • domain assumption Every DC's violation can be detected by checking a single tuple pair and following a single root-to-leaf path in DCTrie, including the symmetric form.
    Used in Section IV-B (symmetric insertion) and Theorem 4.1. The paper assumes that by inserting both ϕ and ϕ_sym and by initializing evidence in the (t_new, t_old) direction then symmetrizing, no violation is missed. This is plausible for pairwise predicates, but the proof relies on the DCTrie path being complete under the chosen attribute-group order.
  • domain assumption The inserted data and the original dataset are such that the pruning of an evidence context with empty Active set is always safe.
    This is the central invariant of Algorithm 3 and Theorem 4.1. It depends on the DCTrie containing all existing DCs and their symmetric forms, and on the context splitting using exact tuple-value comparisons. If the DCTrie construction or wildcard inheritance is incomplete, the 'if Active becomes empty then prune' rule is unsound.
invented entities (1)
  • DCTrie no independent evidence
    purpose: Prefix tree encoding of all existing DCs (and their symmetric forms) as potential violation paths, with wildcard nodes for attribute groups a DC does not constrain.
    DCTrie is a new data structure introduced by this paper. Its only justification is the experimental speedups; there is no external falsifiable handle other than the reported experiments. This is a legitimate algorithmic device, not an unexplained physical entity, so the graviton-problem framing applies only weakly.

pith-pipeline@v1.3.0-alltime-deepseek · 20918 in / 8528 out tokens · 63842 ms · 2026-07-31T23:13:03.327912+00:00 · methodology

0 comments
Cite this review

Pith. "Pith review of EviDC: A Violation-Guided Algorithm for Incremental Denial Constraint Discovery." pith.science (2026). https://pith.science/paper/TMMMV4YQ

@misc{pith2026260724021,
  author       = {Pith},
  title        = {Pith review of: EviDC: A Violation-Guided Algorithm for Incremental Denial Constraint Discovery},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/TMMMV4YQ}},
  note         = {Machine review of arXiv:2607.24021}
}
Share X Bluesky LinkedIn Reddit HN
read the original abstract

Denial Constraints (DCs) are an important class of integrity constraints and have been widely used in data quality management. In dynamic datasets, newly inserted tuples may invalidate existing DCs and require the constraint set to be updated. Existing incremental DC discovery methods still generate a large amount of intermediate evidence because they do not exploit the structural information of existing DCs during evidence construction. We propose EviDC, a violation-guided incremental DC discovery algorithm. EviDC organizes existing DCs into a prefix tree structure called DCTrie, in which each path from the root to a leaf represents a potential violation path. During incremental processing, evidence is expanded only along reachable violation paths, while irrelevant branches are pruned as early as possible. We evaluate EviDC on real-world and synthetic datasets. The results show that EviDC reduces intermediate evidence and improves runtime efficiency in most scenarios. The performance gain becomes more pronounced as the insertion ratio and dataset size increase, showing the effectiveness and scalability of violation-guided evidence construction.

Figures

Figures reproduced from arXiv: 2607.24021 by Qian Zhou, Xiaolong Wan, Xixian Han.

Figure 1
Figure 1. Figure 1: Overview of EviDC and its components. that is, all predicates in ϕ1 are contained in E1. We can say that the tuple pair (t6, t1) violates ϕ1. Based on the above core concepts, we next give a formal description of the DC discovery problem. Static DC discovery: Given a relational instance r, the goal is to find the set Σ of DCs that hold on r. Incremental DC discovery: Given an initial dataset r, an original… view at source ↗
Figure 2
Figure 2. Figure 2: Structure of DCTrie. C. Incremental Evidence Construction Based on DCTrie After building DCTrie, we utilize it to guide the evidence construction. When handling new tuples, the predicate refine￾ment process is directly advanced along the valid path in DCTrie and dynamically prunes redundant branches. Thus, the algorithm does not need to explicitly generate a large amount of irrelevant evidence, thereby red… view at source ↗
Figure 3
Figure 3. Figure 3: Process of evidence refinement and pruning (taking [PITH_FULL_IMAGE:figures/full_fig_p008_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: Comparison of evidence size under different inserti [PITH_FULL_IMAGE:figures/full_fig_p011_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: Comparison of evidence size under varying original d [PITH_FULL_IMAGE:figures/full_fig_p012_5.png] view at source ↗
Figure 7
Figure 7. Figure 7: Runtime of EviDC on Tax under different dataset sizes [PITH_FULL_IMAGE:figures/full_fig_p012_7.png] view at source ↗
Figure 8
Figure 8. Figure 8: Memory usage comparison of EviDC (DCTrie), 3DC ( [PITH_FULL_IMAGE:figures/full_fig_p013_8.png] view at source ↗
Figure 9
Figure 9. Figure 9: Percentage breakdown of EviDC runtime on different d [PITH_FULL_IMAGE:figures/full_fig_p013_9.png] view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

31 extracted references · 2 linked inside Pith

  1. [1]

    Silberschatz, H

    A. Silberschatz, H. F. Korth, S. Sudarshan et al. , Database system concepts. McGraw-Hill New Y ork, 2002, vol. 5

    2002

  2. [2]

    Discovering denial c onstraints

    X. Chu, I. F. Ilyas, and P . Papotti, “Discovering denial c onstraints.” Proc. VLDB Endow., vol. 6, no. 13, pp. 1498–1509, 2013

    2013

  3. [3]

    Data depend encies for query optimization: a survey,

    J. Kossmann, T. Papenbrock, and F. Naumann, “Data depend encies for query optimization: a survey,” The VLDB Journal , vol. 31, no. 1, pp. 1–22, 2022

    2022

  4. [4]

    Mind your dependencies for semantic query optimization,

    E. Pena, E. H. Pena, E. Falk, J. A. Meira, and E. C. de Almeid a, “Mind your dependencies for semantic query optimization,” Journal of Information and Data Management , vol. 9, no. 1, pp. 3–3, 2018

    2018

  5. [5]

    Improving data quality: Co nsistency and accuracy

    W. Fan, F. GEERTS, and X. Jia, “Improving data quality: Co nsistency and accuracy.” ACM, 2007

    2007

  6. [6]

    Holistic data cleani ng: Putting violations into context,

    X. Chu, I. F. Ilyas, and P . Papotti, “Holistic data cleani ng: Putting violations into context,” in 2013 IEEE 29th International Conference on Data Engineering (ICDE) . IEEE, 2013, pp. 458–469

    2013

  7. [7]

    Data cleani ng: Overview and emerging challenges,

    X. Chu, I. F. Ilyas, S. Krishnan, and J. Wang, “Data cleani ng: Overview and emerging challenges,” in Proceedings of the 2016 international conference on management of data , 2016, pp. 2201–2206

    2016

  8. [8]

    Detect ing unique column combinations on dynamic data,

    Z. Abedjan, J.-A. Quian´ e-Ruiz, and F. Naumann, “Detect ing unique column combinations on dynamic data,” in 2014 IEEE 30th International Conference on Data Engineering . IEEE, 2014, pp. 1036–1047

    2014

  9. [9]

    Tane: An efficient algorithm for discovering functional and approxi mate depen- dencies,

    Y . Huhtala, J. K¨ arkk¨ ainen, P . Porkka, and H. Toivonen, “Tane: An efficient algorithm for discovering functional and approxi mate depen- dencies,” The computer journal , vol. 42, no. 2, pp. 100–111, 1999

    1999

  10. [10]

    Fundamentals of o rder dependen- cies,

    J. Szlichta, P . Godfrey, and J. Gryz, “Fundamentals of o rder dependen- cies,” arXiv preprint arXiv:1208.0084 , 2012

    Pith/arXiv arXiv 2012

  11. [11]

    Abedjan, L

    Z. Abedjan, L. Golab, F. Naumann, and T. Papenbrock, Data profiling. Springer, 2019, vol. 10

    2019

  12. [12]

    Discovering denial c onstraints based on deep reinforcement learning,

    L. Bian, W. Y ang, J. Xu, and Z. Tan, “Discovering denial c onstraints based on deep reinforcement learning,” in Proceedings of the 33rd ACM International Conference on Information and Knowledge Man agement, 2024, pp. 120–129

    2024

  13. [13]

    Efficient denial c onstraint discovery with hydra

    T. Bleifuß, S. Kruse, and F. Naumann, “Efficient denial c onstraint discovery with hydra.” Proc. VLDB Endow. , vol. 11, no. 3, pp. 311– 323, 2017. 14

    2017

  14. [14]

    Discovery o f approximate (and exact) denial constraints,

    E. H. Pena, E. C. De Almeida, and F. Naumann, “Discovery o f approximate (and exact) denial constraints,” Proceedings of the VLDB Endowment, vol. 13, no. 3, pp. 266–278, 2019

    2019

  15. [15]

    An overview of electro nic commerce (e-commerce),

    V . Jain, B. Malviya, and S. Arya, “An overview of electro nic commerce (e-commerce),” Journal of Contemporary Issues in Business and Gov- ernment, vol. 27, no. 3, p. 666, 2021

    2021

  16. [16]

    Fault detection in transmission lines: a deni al constraint approach,

    N. Tamalu, L. A. Ensina, E. C. de Almeida, E. H. M. Pena, an d L. E. S. de Oliveira, “Fault detection in transmission lines: a deni al constraint approach,” in Simp´ osio Brasileiro de Banco de Dados (SBBD) . SBC, 2023, pp. 231–243

    2023

  17. [17]

    Fast incremental disco very of pointwise order dependencies,

    Z. Tan, A. Ran, S. Ma, and S. Qin, “Fast incremental disco very of pointwise order dependencies,” Proceedings of the VLDB Endowment , vol. 13, no. 10, pp. 1669–1681, 2020

    2020

  18. [18]

    Incremental dis covery of denial constraints,

    C. Qian, M. Li, Z. Tan, A. Ran, and S. Ma, “Incremental dis covery of denial constraints,” The VLDB Journal , vol. 32, no. 6, pp. 1289–1313, 2023

    2023

  19. [19]

    Discovering denia l constraints in dynamic datasets,

    E. H. Pena, F. Porto, and F. Naumann, “Discovering denia l constraints in dynamic datasets,” in 2024 IEEE 40th International Conference on Data Engineering (ICDE) . IEEE, 2024, pp. 3546–3558

    2024

  20. [20]

    Bfastdc: A bitwise algor ithm for mining denial constraints,

    E. H. Pena and E. C. de Almeida, “Bfastdc: A bitwise algor ithm for mining denial constraints,” in International Conference on Database and Expert Systems Applications . Springer, 2018, pp. 53–68

    2018

  21. [21]

    Fast algorithms fo r denial constraint discovery,

    E. H. Pena, F. Porto, and F. Naumann, “Fast algorithms fo r denial constraint discovery,” 2022

    2022

  22. [22]

    Fast approximate den ial constraint discovery,

    R. Xiao, Z. Tan, H. Wang, and S. Ma, “Fast approximate den ial constraint discovery,” Proceedings of the VLDB Endowment , vol. 16, no. 2, pp. 269–281, 2022

    2022

  23. [23]

    Discovering denial constraints u sing boolean patterns,

    S. L. Marques Filho, “Discovering denial constraints u sing boolean patterns,” in Companion of the 2023 International Conference on Management of Data , 2023, pp. 281–283

    2023

  24. [24]

    Approximate denial constraints,

    E. Livshits, A. Heidari, I. F. Ilyas, and B. Kimelfeld, “ Approximate denial constraints,” arXiv preprint arXiv:2005.08540 , 2020

    Pith/arXiv arXiv 2005

  25. [25]

    Efficient algorithms for dualiz ing large- scale hypergraphs,

    K. Murakami and T. Uno, “Efficient algorithms for dualiz ing large- scale hypergraphs,” in 2013 Proceedings of the Fifteenth W orkshop on Algorithm Engineering and Experiments (ALENEX) . SIAM, 2013, pp. 1–13

    2013

  26. [26]

    A deep reinforcement l earning framework for denial constraint discovery,

    D. Wu, D. Shen, T. Nie, and Y . Kou, “A deep reinforcement l earning framework for denial constraint discovery,” in Asia-Pacific W eb (APW eb) and W eb-Age Information Management (WAIM) Joint Internati onal Conference on W eb and Big Data . Springer, 2025, pp. 246–260

    2025

  27. [27]

    Discovery of denial constraints with hardware accelerati on,

    S. L. MARQUES FILHO, M. A. Z. AL VES, and E. C. DE ALMEIDA, “Discovery of denial constraints with hardware accelerati on,” 2026

    2026

  28. [28]

    Dynfd: Functional depe ndency discovery in dynamic datasets

    P . Schirmer, T. Papenbrock, S. Kruse, F. Naumann, D. Hem pfing, T. Mayer, and D. Neusch¨ afer-Rube, “Dynfd: Functional depe ndency discovery in dynamic datasets.” in EDBT, 2019, pp. 253–264

    2019

  29. [29]

    Dynamic func tional dependency discovery with dynamic hitting set enumeration ,

    R. Xiao, Y . Y uan, Z. Tan, S. Ma, and W. Wang, “Dynamic func tional dependency discovery with dynamic hitting set enumeration ,” in 2022 IEEE 38th International Conference on Data Engineering (IC DE). IEEE, 2022, pp. 286–298

    2022

  30. [30]

    Incremental discovery of functional dependencies with a bit-vector alg orithm

    L. Caruccio, S. Cirillo, V . Deufemia, G. Polese et al. , “Incremental discovery of functional dependencies with a bit-vector alg orithm.” in SEBD, 2019

    2019

  31. [31]

    Conditional functional dependencies for data cleaning,

    P . Bohannon, W. Fan, F. Geerts, X. Jia, and A. Kementsiet sidis, “Conditional functional dependencies for data cleaning,” in 2007 IEEE 23rd international conference on data engineering . IEEE, 2006, pp. 746–755

    2007