Constraint-generating dependencies

Abstract

Traditionally, dependency theory has been developed for uninterpreted data. Specifically, the only assumption that is made about the data domains is that data values can be compared for equality. However, data is often interpreted and there can be advantages in considering it as such, for instance obtaining more compact representations as done in constraint databases. This paper considers dependency theory in the context of interpreted data. Specifically, it studies constraintgenerating dependencies. These are a generalization of equality-generating dependencies where equality requirements are replaced by constraints on an interpreted domain. The main technical results in the paper are a general decision procedure for the implication and consistency problems for constraint-generating dependencies, and complexity results for specific classes of such dependencies over given domains. The decision procedure proceeds by reducing the dependency problem to a decision problem for the constraint theory of interest, and is applicable as soon as the underlying constraint theory is decidable. The complexity results are, in some

Analyses and Validation of Conditional Dependencies with Built-in Predicates

“…Traditional dependencies (fds, inds; see, e.g., [1]) and conditional dependencies (cfds, cinds [14,8]) on the data include the following: cfd 1 : item (id → name, type, price, shipping, sale) cfd 2 : tax (state → rate) cfd 3 : item (sale = 'T' → shipping = 0) These are cfds: (a) cfd 1 assures that the id of an item uniquely determines the name, type, price, shipping, sale of the item; (b) cfd 2 states that state is a key for tax, i.e., for each state there is a unique sale tax rate; and (c) cfd 3 is to ensure that for any item tuple t, if t[sale] = 'T' then t[shipping] must be 0; i.e., the store provides free shipping for items on sale. Here cfd 3 is specified in terms of patterns of semantically related data values, namely, sale = 'T' and shipping = 0.…”

“…A variety of extensions of fds and inds have been studied for specifying constraint databases and constraint logic programs [3,6,19,20]. While the languages of [3,19] cannot express cfds, constraint-generating dependencies (cgds) of [3] and constrained tuple-generating dependencies (ctgds) of [20] can express cfd p s, and ctgds can also express cind p s. The increased expressive power of ctgds comes at the price of a higher complexity: both their satisfiability and implication problems are undecidable.…”

“…While the languages of [3,19] cannot express cfds, constraint-generating dependencies (cgds) of [3] and constrained tuple-generating dependencies (ctgds) of [20] can express cfd p s, and ctgds can also express cind p s. The increased expressive power of ctgds comes at the price of a higher complexity: both their satisfiability and implication problems are undecidable. Built-in predicates and arbitrary constraints are supported by cgds, for which it is not clear whether effective sql queries can be developed to detect errors.…”

Increasing the Expressivity of Conditional Functional Dependencies without Extra Complexity

“…Closer to eCFDs are dependencies of [12], [13], [14], [15] developed for constraint databases. Constraints of [13], also referred to as conditional functional dependencies, are of the form (X → Y ) → (Z → W ), where X → Y and Z → W are standard FDs.…”

Incorporating cardinality constraints and synonym rules into conditional functional dependencies

“…Algorithms have been developed for discovering CFDs [11,16] and for repairing data based on CFDs [13]. There have also been a variety of extensions of FDs [6,8,19] (see [14] for a detailed discussion about the differences between these extensions and CFDs). To the best of our knowledge, no previous work has studied how to extend CFDs or FDs to express cardinality constraints, abbreviations and conventions.…”