The Causality/Repair Connection in Databases: Causality-Programs

04/17/2017 ∙ by Leopoldo Bertossi, et al. ∙ Carleton University 0

In this work, answer-set programs that specify repairs of databases are used as a basis for solving computational and reasoning problems about causes for query answers from databases.



There are no comments yet.


page 1

page 2

page 3

page 4

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Introduction

Causality appears at the foundations of many scientific disciplines. In data and knowledge management, the need to represent and compute causes may be related to some form of uncertainty about the information at hand. More specifically in data management, we need to understand why certain results, e.g. query answers, are obtained or not. Or why certain natural semantic conditions are not satisfied. These tasks become more prominent and difficult when dealing with large volumes of data. One would expect the database to provide explanations, to understand, explore and make sense of the data, or to reconsider queries and integrity constraints (ICs). Causes for data phenomena can be seen as a kind of explanations.

Seminal work on causality in DBs introduced in [17]

, and building on work on causality as found in artificial intelligence, appeals to the notions of counterfactuals, interventions and structural models

[15]. Actually, [17] introduces the notions of: (a) a DB tuple as an actual cause for a query result,  (b) a contingency set for a cause, as a set of tuples that must accompany the cause for it to be such, and (c) the responsibility of a cause as a numerical measure of its strength (building on [11]).

Most of our research on causality in DBs has been motivated by an attempt to understand causality from different angles of data and knowledge management. In [6], precise reductions between causality in DBs, DB repairs, and consistency-based diagnosis were established; and the relationships where investigated and exploited. In [7], causality in DBs was related to view-based DB updates and abductive diagnosis. These are all interesting and fruitful connections among several forms of non-monotonic reasoning; each of them reflecting some form of uncertainty about the information at hand. In the case of DB repairs [3], it is about the uncertainty due the non-satisfaction of given ICs, which is represented by presence of possibly multiple intended repairs of the inconsistent DB.

DB repairs can be specified by means of answer-set programs (or

disjunctive logic programs with stable model semantics

) [14], the so-called repair-programs. Cf. [10, 3] for repair-programs and additional references. In this work we exploit the reduction of DB causality to DB repairs established in [6], by taking advantage of repair programs for specifying and computing causes, their contingency sets, and their responsibility degrees. We show that that the resulting causality-programs have the necessary and sufficient expressive power to capture and compute not only causes, which can be done with less expressive programs [17], but specially minimal contingency sets and responsibilities (which can not). Causality programs can also be used for reasoning about causes. Finally, we briefly show how causality-programs can be adapted to give an account of other forms of causality in DBs.

2 Background

Relational DBs.

A relational schema contains a domain, , of constants and a set, , of predicates of finite arities. gives rise to a language of first-order (FO) predicate logic with built-in equality, . Variables are usually denoted by , and sequences thereof by ; and constants with , etc. An atom is of the form , with -ary and terms, i.e. constants, or variables. An atom is ground (aka. a tuple) if it contains no variables. A DB instance, , for is a finite set of ground atoms; and it serves as an interpretation structure for .

A conjunctive query (CQ) is a FO formula, , of the form  , with , and (distinct) free variables . If has (free) variables,  is an answer to from if , i.e. is true in when the variables in are componentwise replaced by the values in . denotes the set of answers to from . is a boolean conjunctive query (BCQ) when is empty; and when true in , . Otherwise, it is false, and .

In this work we consider integrity constraints (ICs), i.e. sentences of , that are: (a) denial constraints  (DCs), i.e. of the form , where , and ; and (b) functional dependencies  (FDs), i.e. of the form . Here, , and is an abbreviation for .111The variables in the atoms do not have to occur in the indicated order, but their positions should be in correspondence in the two atoms. A key constraint  (KC) is a conjunction of FDs:  , with .  A given schema may come with its set of ICs, and its instances are expected to satisfy them. If this is not the case, we say the instance is inconsistent.

Causality in DBs.

A notion of cause as an explanation for a query result was introduced in   [17], as follows. For a relational instance , where and denote the mutually exclusive sets of endogenous and exogenous tuples, a tuple is called a counterfactual cause for a BCQ , if    and  . Now, is an actual cause for if there exists , called a contingency set for , such that is a counterfactual cause for in . This definition is based on [15].

The notion of responsibility reflects the relative degree of causality of a tuple for a query result [17] (based on  [11]). The responsibility of an actual cause for , is , where is the size of a smallest contingency set for . If is not an actual cause, . Tuples with higher responsibility are stronger explanations.

In the following we will assume all the tuples in a DB instance are endogenous.  (Cf. [6] for the general case.) The notion of cause as defined above can be applied to monotonic queries, i.e whose sets of answers may only grow when the DB grows [6].222E.g. CQs, unions of CQs (UCQs), Datalog queries are monotonic. In this work we concentrate only on conjunctive queries, possibly with .

Example 1

Consider the relational DB , and the query  .  It holds, .

is a counterfactual cause for : if is removed from , is no longer true. Its responsibility is . So, it is an actual cause with empty contingency set. is an actual cause for with contingency set : if is removed from , is still true, but further removing makes false. The responsibility of is . and are actual causes, with responsibility .

Database repairs.

Cf. [3] for a survey on DB repairs and consistent query answering in DBs. We introduce the main ideas by means of an example. The ICs we consider in this work can be enforced only by deleting tuples from the DB (as opposed to inserting tuples). Repairing the DB by changing attribute values is also possible [3, 4, 5], [6, sec. 7.4], but until further notice we will not consider this kind of repairs.

Example 2

The DB is inconsistent with respect to the (set of) denial constraints (DCs)  , and  . It holds  .

A subset-repair, in short an S-repair, of wrt. the set of DCs is a -maximal subset of that is consistent, i.e. no proper superset is consistent. The following are S-repairs: and .  A cardinality-repair, in short a C-repair, of wrt. the set of DCs is a maximum-cardinality, consistent subset of , i.e. no subset of with larger cardinality is consistent. is the only C-repair.

For an instance and a set of DCs, the sets of S-repairs and C-repairs are denoted with and , resp.

3 Causality Answer Set Programs

Causes from repairs.

In [6] it was shown that causes for queries can be obtained from DB repairs. Consider the BCQ   that is (possibly unexpectedly) true in :  . Actual causes for , their contingency sets, and responsibilities can be obtained from DB repairs. First, is logically equivalent to the DC:


So, if is true in ,   is inconsistent wrt. , giving rise to repairs of wrt. .

Next, we build differences, containing a tuple , between and S- or C-repairs:


It holds [6]:   is an actual cause for iff .  Furthermore, each S-repair for which gives us as a subset-minimal contingency set for .  Also, if , then .  Otherwise, , where and there is no with .  As a consequence we obtain that is a most responsible actual cause for  iff  .

Example 3

(ex. 1 cont.)  With the same instance and query , we consider the DC  :  , which is not satisfied by .  Here, and , with ,   ,   .

For tuple  ,   . So, is an actual cause, with responsibility .  Similarly, is an actual cause, with responsibility .  For tuple ,   . So, is an actual cause, with responsibility 1, i.e. a most responsible cause.

It is also possible, the other way around, to characterize repairs in terms of causes and their contingency sets. Actually this connection can be used to obtain complexity results for causality problems from repair-related computational problems [6]. Most computational problems related to repairs, specially C-repairs, which are related to most responsible causes, are provably hard. This is reflected in a high complexity for responsibility [6]  (see below for some more details).

Answer-set programs for repairs.

Given a DB and a set of ICs, , it is possible to specify the repairs of wrt. by means of an answer-set program (ASP) , in the sense that the set, , of its stable models is in one-to-one correspondence with [10, 2] (cf. [3] for more references). In the following we consider a single denial constraint .333It is possible to consider a combination of several DCs and FDs, corresponding to UCQs (possibly with ), on the causality side [6].

Although not necessary for repair purposes, it may be useful on the causality side having global unique tuple identifiers (tids), i.e. every tuple in is represented as for some integer that is not used by any other tuple in . For the repair program we introduce a nickname predicate for every predicate that has an extra, final attribute to hold an annotation from the set , for “delete” and “stays”, resp.  Nickname predicates are used to represent and compute repairs.

The repair-ASP, , for and contains all the tuples in as facts (with tids), plus the following rules:

A stable model of the program determines a repair of :   , and every repair can be obtained in this way [10]. For an FD, say , which makes the third attribute functionally depend upon the first two, the repair program contains the rules:

For DCs and FDs, the repair program can be made non-disjunctive by moving all the disjuncts but one, in turns, in negated form to the body of the rule [10, 2]. For example, the rule , can be written as the two rules   and . Still the resulting program can be non-stratified if there is recursion via negation [14], as in the case of FDs and DCs with self-joins.

Example 4

(ex. 3 cont.)  For the DC  :  , the repair-ASP contains the facts (with tids) , and the rules:

Repair is represented by the stable model containing , and .

Specifying causes with repair-ASPs.

According to (2), we concentrate on the differences between the and its repairs, now represented by , for a stable model of the repair-program. They are used to compute actual causes and their -minimal contingency sets, both identified by tids. So, given the repair-ASP for a DC , a binary predicate will contain a tid for cause in its first argument, and a tid for a tuple belonging to its contingency set. Intuitively, says that is an actual cause, and accompanies as a member of the former’s contingency set (as captured by the repair at hand or, equivalently, by the corresponding stable model). More precisely, for each pair of predicates in the DC as in (1) (they could be the same if it has self-joins), introduce the rule  , with the inequality condition only when and are the same.

Example 5

(ex. 3 and 4 cont.)  The causes for the query, represented by their tids, can be obtained by posing simple queries to the program under the uncertain or brave semantics that makes true what is true in some model of the repair-ASP.444As opposed to the skeptical or cautious semantics that sanctions as true what is true in all models. Both semantics as supported by the DLV system [16], to which we refer below. In this case, , where the auxiliary predicate is defined on top of by the rules:   and .

The repair-ASP can be extended with the following rules to compute causes with contingency sets:


For the stable model corresponding to repair , we obtain and , from the repair difference .

We can use the DLV system [16] to build the contingency set associated to a cause, by means of its extension, DLV-Complex [9], that supports set building, membership and union, as built-ins. For every atom , we introduce the atom , and the rule that computes the union of (partial) contingency sets as long as they differ by some element:


The responsibility for an actual cause , with tid , as associated to a given repair (with ), and then to a given model of the extended repair-ASP, can be computed by counting the number of s for which . This responsibility will be maximum within a repair (or model):  , where . This value can be computed by means of the count function, supported by DLV [13], as follows:  , followed by the rule computing the responsibility:  . Or equivalently, via , with .

Each model of the program so far will return, for a given tuple (id) that is an actual cause, a maximal-responsibility contingency set within that model: no proper subset is a contingency set for the given cause. However, its cardinality may not correspond to the (global) maximum responsibility for that tuple. For that we need to compute only maximum-cardinality repairs, i.e. C-repairs.

C-repairs can be specified by means of repair-ASPs [1] that contain weak-program constraints [8, 13]. In this case, we want repairs that minimize the number of deleted tuples. For each DB predicate , we introduce the weak-constraint555Hard program-constraints, of the form  , eliminate the models where they are violated.  . In a model the body can be satisfied, and then the program constraint violated, but the number of violations is kept to a minimum (among the models of the program without the weak-constraints). A repair-ASP with these weak constraints specifies repairs that minimize the number of deleted tuples; and minimum-cardinality contingency sets and maximum responsibilities can be computed, as above.


Computing causes for CQs can be done in polynomial time in data [17], which was extended to UCQs in [6]. As has been established in [17, 6], the computational problems associated to contingency sets and responsibility are in the second level of the polynomial hierarchy (PH), in data complexity [12]. On the other side, our causality-ASPs can be transformed into non-disjunctive, unstratified programs, whose reasoning tasks are also in the second level of the PH (in data). It is worth mentioning that the ASP approach to causality via repairs programs could be extended to deal with queries that are more complex than CQs or UCQs. (In [18] causality for queries that are conjunctions of literals was investigated; and in [7] it was established that cause computation for Datalog queries can be in the second level of the PH.)

Causality programs and ICs

The original causality setting in [17] does not consider ICs. An extension of causality under ICs was proposed in [7]. Under it, the ICs have to be satisfied by the DBs involved, i.e. the initial one and those obtained by cause- and contingency-set deletions. When the query at hand is monotonic666I.e. the set of answers may only grow when the instance grows., monotonic ICs (e.g. denial constraints and FDs) are not much of an issue since they stay satisfied under deletions associated to causes. So, the most relevant ICs are non-monotonic, such as referential ICs, e.g. in our running example. These ICs can be represented in a causality-program by means of (strong) program constraints. In the running example, we would have, for example, the constraint:  .777Or better, to make it safe, by a rule and a constraint:   and  .

Preferred causes and repairs.

In [6], generalized causes were introduced on the basis of arbitrary repair semantics (i.e. classes of preferred consistent subinstances, commonly under some maximality criterion), basically starting from the characterization in (2) and (3), but using repairs of wrt. in a class, , possibly different from or . As a particular case in [6], causes based on changes of attribute values (as opposed to tuple deletions) were defined. In that case, admissible updates are replacements of data values by null values, to break joins, in a minimal or minimum way. Those underlying DB repairs were used in [4] to hide sensitive data that could be exposed through CQ answering; and corresponding repair programs were introduced. They could be used, as done earlier in this paper, as a basis to reason about- and compute the new resulting causes (at the tuple or attribute-value level) and their contingency sets.888Cf. also [5] for an alternative null-based repair semantics and its repair programs.


  • [1] Arenas, M., Bertossi, L., Chomicki, J. Answer Sets for Consistent Query Answers. Theory and Practice of Logic Programming, 2003, 3(4&5):393-424.
  • [2] Barcelo, P., Bertossi, L. and Bravo, L.  Characterizing and Computing Semantically Correct Answers from Databases with Annotated Logic and Answer Sets. In Semantics in Databases, Springer LNCS 2582, 2003, pp. 7-33.
  • [3] Bertossi, L. Database Repairing and Consistent Query Answering. Morgan & Claypool, Synthesis Lectures on Data Management, 2011.
  • [4] Bertossi, L. and Li, L.  Achieving Data Privacy through Secrecy Views and Null-Based Virtual Updates. IEEE Trans. Knowledge and Data Engineering, 2013, 25(5):987-1000.
  • [5] Bertossi, L. and Bravo, L.  Consistency and Trust in Peer Data Exchange Systems. Theory and Practice of Logic Programming, 2017, 17(2):148-204.
  • [6] Bertossi, L. and Salimi, B. From Causes for Database Queries to Repairs and Model-Based Diagnosis and Back. Theory of Computing Systems, 2017, 61(1):191 232.
  • [7] Bertossi, L. and Salimi, B. Causes for Query Answers from Databases: Datalog Abduction, View-Updates, and Integrity Constraints. To appear in Int. J. Approximate Reasoning. Corr Arxiv Paper cs.DB/1611.01711.
  • [8] Buccafurri, F., Leone, N. and Rullo, P. Enhancing Disjunctive Datalog by Constraints. IEEE Tran. Knowledge and Data Engineering, 2000, 12, 5, 845 860.
  • [9] Calimeri, F. Cozza, S. Ianni, G. and Leone, N. An ASP System with Functions, Lists, and Sets. Proc. LPNMR 2009, Springer LNCS 5753, 2009, pp. 483-489.
  • [10] Caniupan-Marileo, M. and Bertossi, L.  The Consistency Extractor System: Answer Set Programs for Consistent Query Answering in Databases”. Data & Know. Eng., 2010, 69(6):545-572.
  • [11] Chockler, H. and Halpern, J. Y. Responsibility and Blame: A Structural-Model Approach. J. Artif. Intell. Res., 2004, 22:93-115.
  • [12] Dantsin, E., Eiter, T., Gottlob, G. and Voronkov, A. Complexity and Expressive Power of Logic Programming, ACM Computing Surveys, 2001, 33(3):374 425.
  • [13] Faber, W., Pfeifer, G., Leone, N., Dell’Armi, T. and Ielpa, G. Design and implementation of aggregate functions in the DLV system. The. Pr. Logic Prog., 2008, 8(5-6):545-580.
  • [14] Gelfond, M. and Kahl, Y.  Knowledge Representation and Reasoning, and the Design of Intelligent Agents. Cambridge Univ. Press, 2014.
  • [15] Halpern, J. and Pearl, J. Causes and Explanations: A Structural-Model Approach: Part 1. British J. Philosophy of Science, 2005, 56:843-887.
  • [16] Leone, N., Pfeifer, G., Faber,W., Eiter, T., Gottlob, G., Perri, S. and Scarcello, F. The DLV System for Knowledge Representation and Reasoning. ACM Trans. Comput. Logic., 2006, 7(3):499-562.
  • [17] Meliou, A., Gatterbauer, W., Moore, K. F. and Suciu, D. The Complexity of Causality and Responsibility for Query Answers and Non-Answers. Proc. VLDB, 2010, pp. 34-41.
  • [18] Salimi, B., Bertossi, L., Suciu, D. and Van den Broeck, G. Quantifying Causal Effects on Query Answering in Databases. Proc. TaPP, 2016.