On the Complexity of View Update Analysis and Its Application to Annotation Propagation

Abstract

This paper investigates three problems identified in [1] for annotation propagation, namely, the view side-effect, source side-effect, and annotation placement problems. Given annotations entered for a tuple or an attribute in a view, these problems ask what tuples or attributes in the source have to be annotated to produce the view annotations. As observed in [1], these problems are fundamental not only for data provenance but also for the management of view updates. For an annotation attached to a single existing tuple in a view, it has been shown that these problems are often intractable even for views defined in terms of simple SPJU queries [1]. We revisit these problems by considering several dichotomies: 1) views defined in various subclasses of SPJU, versus SPJU views under a practical key preserving condition; 2) annotations attached to existing tuples in a view versus annotations on tuples to be inserted into the view; and 3) a single-tuple annotation versus a group of annotations. We provide a complete picture of intractability and tractability for the three problems in all these settings. We show that key preserving views often simplify the propagation analysis. Indeed, some problems become tractable for certain key preserving views, as opposed to the intractability of their counterparts that are not key preserving. However, group annotations often make the analysis harder. In addition, the problems have quite diverse complexity when annotations are attached to existing tuples in a view and when they are entered for tuples to be inserted into the view.Index Terms-Annotation, view updates, view maintenance, SPJU queries.

A dichotomy in the complexity of deletion propagation with functional dependencies

“…A classical problem in database management is that of view update [1,[4][5][6][10][11][12]: translate an update operation Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.…”

“…If only the undesired tuple gets to be deleted from the view, then the solution is side-effect free. A solution that is side-effect free does not necessarily exist, and therefore, the task is relaxed to that of minimizing the side effect [3][4][5]14]. That is, the goal is to delete tuples from the base relations so that the undesired tuple disappears from the view, but as many as possible other tuples remain.…”

View determinacy for preserving selected information in data transformations

“…A third topic is to identify practical cases of VDet(CQ, CQ) and QPre(CQ, CQ, CQ) that are tractable. In particular, our conjecture is that the analyses would become simpler for key preserving CQ views, i.e., views that retain the keys of base relations involved [22]. Data transformations in practice are either key preserving or can be naturally extended to preserve keys.…”

Descriptive and prescriptive data cleaning

“…Second, considering the entire lineage for explanation discovery will not help in finding meaningful explanations. Unfortunately, it is known that computing all the possible subsets of such lineage is a NP problem even in simpler settings with one SPJU query [5]. We can easily see from the example how the number of subsets can explode.…”

“…The side-effect free variant of this problem is related to our rewriting from target to source. Unfortunately, the problem is intractable even for views defined in terms of simple SPJU queries [5]. This intractability motivated our scoring scheme; we drop the requirement to solve the view update in an exact fashion and opt for scores that can be computed efficiently.…”