Causality in Databases, Database Repairs, and Consistency-Based Diagnosis (extended abstract).

When querying a database, a user may not always obtain the expected results, and the system could provide some explanations. Explanations that could be useful to further understand the data or check if the query is the intended one. Actually, the notion of explanation for a query result was introduced in [19], on the basis of the deeper concept of actual causation. Intuitively, a tuple t is an actual cause for an answer a to a conjunctive query A from a relational database instance D if there is a “contingent” set of tuples Γ, such that, after removing Γ from D, removing/inserting t from/into D causes a to switch from being an answer to being a non-answer. Actual causes and contingent tuples are restricted to be among a pre-specified set of endogenous tuples, which are admissible, possible candidates for causes, as opposed to exogenous tuples.(For a formalization of non-causality-based explanations for query answers in DL ontologies, see [3].) Some causes may be stronger than others. In order to capture this observation,[19] also introduces and investigates a quantitative metric, called responsibility, which reflects the relative degree of causality of a tuple for a query result. In applications involving large data sets, it is crucial to rank potential causes by their responsibility [20, 19].Actual causation, as used in [19], can be traced back to [11, 12], which provides a model-based account of causation on the basis of the counterfactual dependence. Responsibility was also introduced in [8], to capture the degree of causation. Apart from the explicit use of causality, research on explanations for query results has focused mainly, and rather implicitly, on …