The VLDB Journal manuscript No. (will be inserted by the editor)
Nilesh Dalvi · Dan Suciu Efficient Query Evaluation on Probabilistic Databases
the date of receipt and acceptance should be inserted later
Abstract We describe a framework for supporting ar- SELECT * FROM Actor A bitrarily complex SQL queries with ”uncertain” predi- WHERE A.name ≈ ’Kevin’ cates. The query semantics is based on a probabilistic and 1995 = model and the results are ranked, much like in Informa- SELECT MIN(F.year) tion Retrieval. Our main focus is query evaluation. We FROM Film F, Casts C describe an optimization algorithm that can compute ef- WHERE C.filmid = F.filmid and C.actorid = A.actorid ficiently most queries. We show, however, that the data and F.rating ≈ "high" complexity of some queries is #P -complete, which im- plies that these queries do not admit any efficient eval- Fig. 1 An Approximate Query uation methods. For these queries we describe both an approximation algorithm and a Monte-Carlo simulation To illustrate the point consider the query in Fig 1. algorithm. It is a structurally rich query, asking for an actor whose name is like ‘Kevin’ and whose first movie with ‘High’ rating appeared in the year 1995. 1 Introduction The two ≈ operators indicate which predicates we Databases and Information Retrieval [3] have taken two intend as uncertain matches. Techniques like edit dis- philosophically different approaches to queries. In data- tances, ontology-based distances [14], IDF-similarity and bases SQL queries have a rich structure and a precise QF-similarity [1] can be applied to a single table: to rank semantics. This makes it possible for users to formu- all Actor tuples (according to how well they match the late complex queries and for systems to apply complex first uncertain predicate), and to rank all Film tuples. optimizations, but users need to have a pretty detailed But it is unclear how to rank the entire query. To date, knowledge of the database in order to formulate queries. no system combines structurally rich SQL queries with For example, a single misspelling of a constant in the uncertain predicates and ranked results. WHERE clause leads to an empty set of answers, frus- In this paper we propose such a system. We show trating casual users. By contrast, a query in Information that, using the concept of possible worlds semantics, data- Retrieval (IR) is just a set of keywords and is easy for base queries with approximate matches can be given casual users to formulate. IR queries offer two important meaning in a principled way and a ranked list of an- features that are missing in databases: the results are swers can be computed. Given a SQL query with uncer- ranked and the matches may be uncertain, i.e. the an- tain predicates, we start by assigning a probability to swer may include documents that do not match all the each tuple in the input database according to how well keywords in the query1. While several proposals exist it matches the uncertain predicates. Then we derive a for extending SQL with uncertain matches and ranked probability for each tuple in the answer, and rank the results [1,20,15], they are either restricted to a single ta- answers accordingly. ble, or, when they handle join queries, adopt an ad-hoc An important characteristic of our approach is that semantics. any SQL query with approximate predicates has a mean- ing, including queries with joins, nested sub-queries, ag- University of Washington, Seattle. gregates, group-by, and existential/universal quantifiers2. 1 Some IR systems only return documents that contain all keywords, but this is a feature specific to those systems, and 2 In this paper we restrict our discussion to SQL queries not of the underlying vector model used in IR. whose normal semantics is a set, not a bag or an ordered list. 2 Nilesh Dalvi, Dan Suciu
p Queries have a probabilistic semantics, which is simple S T p A B C D and easy to understand by both users and implementors. s1 ‘m’ 1 0.8 t1 1 ‘p’ 0.6 While simple, the semantics gives no indication on s2 ‘n’ 1 0.5 how to evaluate the query. The main problem that we Fig. 2 A probabilistic database Dp discuss in this paper is query evaluation. Our approach is to represent SQL queries in an algebra, and modify the operators to compute the probabilities of each output tu- pwd(Dp) = ple. This is called extensional semantics [26], and is quite world prob. efficient. While this sounds simple, the problem is that D1 = {s1, s2, t1} 0.24 it doesn’t work: the probabilities computed this way are D2 = {s1, t1} 0.24 wrong in most cases, and lead to incorrect ranking. The D3 = {s2, t1} 0.06 reason is that, even if all tuples in the base relations are D4 = {t1} 0.06 D = {s , s } 0.16 independent probabilistic events, the tuples in the in- 5 1 2 D6 = {s1} 0.16 termediate results of a query plan have often correlated D7 = {s2} 0.04 probabilities, making it impossible to compute the new D8 = φ 0.04 probabilities precisely. The previous workaround is to use (a) an intensional semantics [29,31,12], which represents tu- ple events symbolically and, hence, tracks tuple correla- tions precisely. However, as we show here, this approach q(u):− Sp(x, y),T p(z, u), y = z is too inefficient to be practical. Our approach is differ- ent: we rewrite the query plan, searching for one where (b) the extensional evaluation is correct. We show however that certain queries have a #P-complete data complexity qpwd(Dp) = under probabilistic semantics, and hence do not admit a answer prob. correct extensional plan. While they are not frequent in 0 0 practice (only 2 out of the 10 TPC/H queries fall in this { p } 0.54 ∅ 0.46 category, and only when all their predicates are uncer- tain), we describe two techniques to address them: using (c) heuristics to chose a plan that avoids large errors, and using a Monte-Carlo simulation algorithm, which is more Fig. 3 (a) The possible worlds for Dp in Figure 2, (b) a expensive but can guarantee arbitrarily small errors. query q, and (c) its possible answers. Outline We give motivating examples in Sec. 2, de- fine the problem in Sec. 3, and describe our techniques in Sec. 4-9. Sec. 11 reports experiments and Sec. 12 de- 0.6 = 0.24, since the instance contains the tuples s1 and scribes related work. We conclude in Sec. 13. t1 and does not contain s2. We now illustrate query evaluation on probabilistic databases. Consider the conjunctive query q in Fig. 3 (b). 2 Examples Its meaning on Dp is a set of possible answers, shown in Fig. 3 (c). It is obtained by applying q to each determin- We illustrate the main concepts and techniques of this istic database in pwd(Dp), and adding the probabilities paper with two simple examples. of all instances that return the same answer. In our ex- 0 0 Probabilistic Database In a probabilistic database ample we have q(D1) = q(D2) = q(D3) = { p }, and each tuple has a certain probability of belonging to the q(D4) = ... = q(D8) = ∅. Thus, the probability of the database. Figure 2 shows a probabilistic database Dp answer being {0p0} is 0.24+0.24+0.06 = 0.54, while that with two tables, Sp and T p: the tuples in Sp have prob- of the answer ∅ is 0.46. This defines the set of possible abilities 0.8 and 0.5, and the unique tuple in T p has answers, denoted qpwd(Dp). Notice that we have never probability 0.6. We use the superscript p to emphasize used the structure of the query explicitly, but only ap- that a table or a database is probabilistic. We assume in plied it to deterministic databases taken from pwd(Dp). this example that all the tuples represent independent Thus, one can give a similar semantics to any query q, probabilistic events. no matter how complex, because we only need to know The meaning of a probabilistic database is a probabil- its meaning on deterministic databases. ity distribution on all database instances, which we call The set of possible answers qpwd(Dp) may be very possible worlds, and denote pwd(Dp). Fig. 3 (a) shows large, and it is impractical to return it to the user. In the eight possible instances with non-zero probabilities, our simple example, there are only two possible answers, which are computed by simply multiplying the tuple since T p has only one tuple. In general, if T p has n tuples, probabilities, as we have assumed them to be indepen- there can be as many as 2n possible answers, and it is dent. For example, the probability of D2 is 0.8∗(1−0.5)∗ impractical to return them to the user. Efficient Query Evaluation on Probabilistic Databases 3
Our approach is to compute for each possible tuple t A B C D prob ‘m’ 1 1 ’p’ 0.8*0.6 = 0.48 a probability rank that t belongs to any answer, and sort ‘n’ 1 1 ’p’ 0.5*0.6 = 0.30 tuples sorted by this rank. We denote this qrank(Dp). In p p our example this is: (a) S 1B=C T D prob D Rank ‘p’ (1 - (1 - 0.48)(1 - 0.3)) = 0.636 qrank(Dp) = ’p’ 0.54 p p (b) ΠD(S 1B=C T )
In this simple example qrank(Dp) contains a single tu- p p ple and the distinction between qpwd and qrank is blurred. Fig. 4 Evaluation of ΠD(S 1B=C T ) To see this distinction clearer, consider another query, p p pwd rank B prob q1(x):− S (x, y),T (z, u), y = z. Here q1 and q1 are given by: 1 (1 - (1 - 0.8)(1 - 0.5)) = 0.9 p (a) ΠB(S ) answer probability B C D prob {0m0,0 n0} 0.24 1 1 ‘p’ 0.9 * 0.6 = 0.54 qpwd(Dp) = {0m0} 0.24 1 p p {0n0} 0.06 (b) ΠB(S ) 1B=C T ∅ 0.46 D prob ‘p’ 0.54
D Rank p p (c) ΠD(ΠB(S ) 1B=C T ) rank p q1 (D ) = ’m’ 0.48 ’n’ 0.30 p p Fig. 5 Evaluation of ΠD(ΠB(S ) 1B=C T ) For example, the rank probability of 0m0 is obtained as P r({0m0,0 n0})+P r({0m0}). While in general qpwd(Dp) may be exponentially large, qrank(Dp) is simply a set of Queries with uncertain matches While query eval- tuples, which are sorted by Rank. The problem in this uation on probabilistic databases is an important prob- paper is now to compute qrank(Dp) efficiently. lem in itself, our motivation comes from answering SQL Extensional Query Semantics A natural attempt queries with uncertain matches, and ranking their re- to compute qrank(Dp) is to represent q as a query plan sults. We illustrate here with a simple example on the then compute the probabilities of all tuples in all inter- Stanford movie database[21]. mediate results. For the query q in Fig. 3 (b), such a SELECT DISTINCT F.title, F.year p p plan is P = ΠD(S 1B=C T ), and the correspond- FROM Director D, Films F ing probabilities are shown in Fig. 4. The formulas for WHERE D.did = F.did the probabilities assume tuple independence, are taken and D.name ≈ ’Copolla’ from [12] and are rather straightforward (we review them and F.title ≈ ’rain man’ in Sec. 4). For example the probability of a joined tu- and F.year ≈ 1995 ple s 1 t is the product of the probabilities of s and t. The predicates on the director name and the movie Clearly, this approach is much more efficient than com- title and year are here uncertain. puting the possible worlds qpwd(Dp) and then computing rank p Our approach is to translate the query into a regular q (D ), but it is wrong ! It’s answer is 0.636, while query over a probabilistic databases. Each tuple in the it should be 0.54. The reason is that the two tuples in table Films is assigned a probability based on how well it Sp 1 T p are not independent events, hence the for- B=C matches the predicates title ≈ ’rain man’ and year mula used in Π is wrong. D ≈ 1995. Several techniques for doing this exist already, However, let us consider an alternative plan, P0 = p p and in this paper we will adopt existing ones: see Sec. 9. ΠD((ΠB(S )) 1B=D T ). The extensional evaluation of The result is a probabilistic table, denoted Filmsp. Sim- this expression is shown in Figure 5, and this time we ilarly, the uncertain predicate on Director generates a do get the correct answer. As we will show later, this probabilistic table Directorp. Then, we evaluate the fol- plan will always compute the correct answer to q, on any p p lowing query, obtained by dropping the similarity pred- probabilistic tables S ,T . In this paper we show how to icates from the original SQL query: find automatically a plan whose extensional evaluation returns the correct answer to a query q. Finding such a SELECT DISTINCT F.title, F.year plan requires pushing projections early (as shown in this FROM Directorp D, Filmsp F example) and choosing join orders carefully. WHERE D.did = F.did 4 Nilesh Dalvi, Dan Suciu
This is similar to the query q considered earlier (Fig- value is a complex event. We add the superscript p to ure 3 (b)), and the same extensional plan can be used to mean “probabilistic”. Thus, Rp denotes a relation name evaluate it. Our system returns: having E among it’s attributes; rp denotes an instance of Rp, i.e. where for each tuple t ∈ rp, t.E is a complex title year rank event; R¯p denotes a database schema where some rela- The Rainmaker (by Coppola) 1997 0.110 tions names have an E attribute; and, finally, Γ p denotes The Rain People (by Coppola) 1969 0.089 a set of functional dependencies over R¯p, where the func- Rain Man (by Levinson) 1988 0.077 tional dependencies may use both regular attributes and Finian’s Rainbow (by Coppola) 1968 0.069 the event attribute. Note that we allow for a probabilis- Tucker, Man and Dream (Coppola) 1989 0.061 tic database schema R¯p to consist of both probabilistic Rain or Shine (by Capra) 1931 0.059 relations and deterministic relations...... As a convenient notation, by dropping the p super- script we mean the deterministic part, obtained by re- 3 Problem Definition moving the event attribute. Thus, R is such that Attr(R) = Attr(Rp)−{E}, while r represents the project of rp on We review here the basic definitions in probabilistic data- all attributes other than E. The intuition is that users bases, based on ideas taken from several papers [32,12, “see” only R, but the system needs to access the event 2], and state our problem. attribute Rp.E in order to compute correctly the proba- Basic Notations We write R for a relation name, bility ranks. For a simple illustration, consider the proba- Attr(R) for the set of its attributes, and r ⊆ U k for a bilistic relation name Sp(A, B, E): then S has attributes relation instance, where k is arity(R) and U is a fixed, A, B. Users care to see a binary table S(A, B), while the finite universe of atomic values. We denote with R¯ = system maintains probabilistic events in Sp(A, B, E). R1,...,Rn a database schema, and write D = r1, . . . , rn We assume that the set of functional dependencies for a database instance of that schema. We consider func- Γ p always contains, or implies the following functional tional dependencies in this paper, and denote with Γ a dependency: set of functional dependencies. We write D |= Γ when Attr(R) → Rp.E D satisfies the functional dependencies in Γ . for every relation Rp: this ensures that we don’t asso- Probabilistic Events In order to represent prob- ciate two different events e and e to the same tuple t abilistic events, we use a set of symbols, AE: each e ∈ 1 2 (instead, we may want to associate e ∨ e to t). AE represents an independent probabilistic event, called 1 2 In addition to this tabular representation of a prob- atomic event. We fix a probability function P r : AE → abilistic relation, we consider a functional representa- [0, 1], associating a probability to each atomic event. A tion, where a probabilistic instance rp, of type Rp, is special symbol ⊥ ∈ AE denotes the impossible event, described by the following function e : U k → E, where and we define P r(⊥) = 0. R k = arity(R). When t occurs in rp and its event is A complex event is an expression constructed from t.E = e, then e (t) = e, otherwise e (t) = ⊥. Con- atomic events using the operators ∧, ∨, ¬. E denotes R R versely, one can recover rp from the function e by col- the set of all complex events. For each complex event e, R lecting all tuples for which e (t) 6= ⊥. let P r(e) be its probability. R The probabilistic databases we consider have only atomic events: complex events are introduced only dur- Example 1 Consider e = (s1 ∧ t1) ∨ (s2 ∧ t1), and as- ing query evaluation. If a probabilistic relation has a sume P r(s1) = 0.8, P r(s2) = 0.5, P r(t1) = 0.6. To com- distinct atomic event for each tuple, we call it a tuple- pute P r(e) we construct the truth table for e(s1, s2, t1) and identify the entries where e is true, namely (1, 0, 1), independent probabilistic relation. For example, both the (0, 1, 1), (1, 1, 1). The three entries have probabilities given relations in Fig. 2 are tuple-independent, where the atomic events are s , s , t respectively. by P r(s1)(1−P r(s2))P r(t1) = 0.8×0.5×0.6 = 0.24, (1− 1 2 1 Possible Worlds Database A possible worlds re- P r(s1))P r(s2)P r(t1) = 0.06 and P r(s1)P r(s2)P r(t1) = 0.24 respectively. Then P r(e) is their sum, 0.54. lation of type R is simply a probability distribution on the set of all deterministic relations of type R. Similarly, This method of computing probabilities generalizes a possible worlds database of schema R¯ is a probability to any complex event e(s1, . . . , sk) which is a function distribution on all possible data instances with the given of atomic events s1, . . . , sk. But it is important to no- schema. tice that this algorithm is exponential in k, the number Semantics of a probabilistic database Now, we of atomic events, because the size of the truth table for give a simple and intuitive meaning to a probabilistic k p p e(s1, . . . , sk) is 2 . This cannot be avoided: it is known relation. Consider a probabilistic relation r of type R that computing P r(e) is #P-complete [36] even for com- and let r be its deterministic part. The meaning of rp is plex events without negation. a possible worlds relation, which we denote pwd(rp) and k Probabilistic Databases A probabilistic relation is is defined as follows. Let eR : U → E be the functional a relation with a distinguished event attribute E, whose representation of rp. Given s ⊆ U k, P r(s) is defined to Efficient Query Evaluation on Probabilistic Databases 5
V V be P r( t∈s eR(t) ∧ t6∈s ¬eR(t)). Intuitively, this is the icates. We convert this problem into evaluating a de- probability that exactly the tuples in s are “in” and all terministic query q, obtained by removing all uncertain P ≈ the others are “out”. One can check that s⊆U k P r(s) = predicates from q , on a probabilistic database, obtained 1. Also, it follows that for s 6⊆ r, P r(s) = 0 because ele- by associating a probability P r(t) to each tuple t based ments not in r have the event ⊥. Similarly, the meaning on how well t satisfies the uncertain predicates. of a probabilistic database Dp is a probability distribu- tion on all deterministic databases D, denoted pwd(Dp). For an instance, D = s , . . . , s and its probability is 1 n 3.1 Representation power of probabilistic databases P r(s1)P r(s2) . . . P r(sn). We discuss next how possible worlds relations inter- We have shown that every probabilistic database has a act with functional dependencies, and focus on a single representation as a possible worlds database. We show relation name Rp. Given a set of functional dependen- here the converse: that probabilistic databases are pow- cies Γ p, denote Γ its projection to the deterministic at- erful enough to represent any possible distribution on tributes of Rp, i.e. let Γ consist of those dependencies databases. Recall that in a probabilistic database, we that can be derived from Γ p and that do not refer to the can only store with each tuple an event that is a boolean event attribute Rp.E. For example, if Rp is Rp(A, B, E) function of independent atomic events. and Γ p = {A → E,E → B}, then Γ = {A → B}. Consider a probabilistic instance rp that satisfies Γ p (in notation: rp |= Γ p), and let P r be the probability distri- Theorem 1 Let W be any possible worlds database, i.e. bution on instances induced by r (the possible worlds a probability distribution on the set of data instances. p Then, there exists a probabilistic database Dp such that relation). The question is if a relation s that does not p satisfy Γ can have a non-zero probability, i.e. P r(s) > 0. W = pwd(D ). The answer is no: if P r(s) > 0, s must be a subset of r (which is rp without the event attribute), and, hence, Proof We have a fixed, finite universe U. Let a1, a2, ··· must also satisfy the functional dependencies in Γ . be the arities of the relations in the schema and let k = a a Query semantics Let q be a query of arity k over |U| 1 +|U| 2 +··· . Thus, k denotes the number of distinct ¯ possible tuples. The number of possible databases is n = a deterministic schema R. We define a very simple and k intuitive semantics for the query. Users think of q as nor- 2 . Let D1, ··· Dn be all possible data instances. W (Di) mal query on a deterministic database, but the database denotes the probability of Di. is given by a probability distribution rather than being We will create n−1 independent events E = {e1, ··· , fixed. As a result, the query’s answer is also a probabil- en−1} with probabilities p(e1), ··· , p(en−1) and a boolean ity distribution. Formally, given a query q and a proba- expression fW (Di) in terms of these events for each data bilistic database Dp: qpwd(Dp) is the following probabil- instance so that the following holds: W (Di) = p(fW (Di)) k for all i, and the events f (D ) are all disjoint. ity distribution on all possible answers, P rq : P(U ) → W i [0, 1]: P2k−1 We do it recursively. Let pL = i=0 W (Di). Con- k X sider the distribution WL that is given by WL(Di) = ∀S ⊆ U , P rq(S) = P r(D) W (D )/p on domain {D , ··· ,D k−1 } and distribution D|q(D)=S i L 1 2 WR given by WR(Di) = W (Di)/(1 − pL) on the domain We call this the possible worlds semantics. This definition {D2k−1+1, ··· ,D2k }. k−1 makes sense for every query q that has a well defined Recursively, represent WL and WR using 2 − 1 semantics on all deterministic databases. independent variables each. Also create a new variable e pwd p It is impossible to return q (D ) to the user. In- with p(e) = pL. Define stead, we compute a probabilistic ranking on all tuples t ∈ k P U , defined by the function: rankq(t) = S{P rq(S) | k k ( k−1 S ⊆ U , t ∈ S}, for every tuple t ∈ U . We denote fWL (Di) ∧ e i ≤ 2 with qrank(Dp) a tabular representation of the function fW (Di) = k−1 fWR (Di) ∧ ¬(e) i > 2 rankq: this is a table with k + 1 attributes, where the first k represent a tuple in the query’s answer while the k last attribute, called Rank is a real number in [0, 1] rep- We see that fW uses 2 − 1 independent variables. It resenting its probability. is easy to verify that W (Di) = p(fW (Di)) and fW (Di) The Query Evaluation Problem This paper ad- are all disjoint events. dresses the following problem: given schema R¯p,Γ p, a Finally, we create a probabilistic database as possible. probabilistic database Dp and a query q over schema R¯, For a relation R in the schema, and for every tuple t, let rank p e (t) = W f (D ). Since the events f (D ) compute the probabilistic rankings q (D ). R {Di|t∈Di.R} W i W i Application to queries with uncertain predi- are all disjoint, one can verify that when this probabilis- cates Consider now a deterministic database D and a tic database is converted to possible worlds database, we query q≈ that explicitly mentions some uncertain pred- get back W . 6 Nilesh Dalvi, Dan Suciu
A B C D E eP (t) if c(t) is true ‘m’ 1 1 ’p’ s1 ∧ t1 e i (t) = σc(P) ⊥ if c(t) is false ‘n’ 1 1 ’p’ s2 ∧ t1 W 0 eΠi (P)(t) = t0:Π (t0)=t eP (t ) A¯ A¯ p i p 0 0 (a) S 1B=C T eP×iP0 (t, t ) = eP (t) ∧ eP0 (t ) D E ‘p’ (s1 ∧ t1) ∨ (s2 ∧ t1) Fig. 6 Intensional Evaluation i p i p (b) ΠD(S 1B=C T ) D Rank 0 4 Query Evaluation ‘p P r((s1 ∧ t1) ∨ (s2 ∧ t1)) = 0.54
rank p rank p i p i p We turn now to the central problem, evaluating q (D ) (c) q (D ) = P r(ΠD(S 1B=C T )) for a query q, and a probabilistic database Dp. Applying the definition directly is infeasible, since it involves iter- p p ating over a large set of database instances. Instead, we Fig. 7 Intensional Evaluation of ΠD(S 1B=C T ) will first review the intensional evaluation of [12], then describe our approach in Sec 4.3. We restrict our discussion first to conjunctive queries, intensional semantics4 of q on the probabilistic database or, equivalently select (distinct)-project-join queries. This Dp. We prove now that it is equivalent to the possible helps us better understand the query evaluation problem worlds semantics, qpwd(Dp). and its complexity, and will consider more complex query expressions in Sec. 8. We use either datalog notation for our queries q, or plans P in the select/project/product Theorem 2 The intensional semantics and the possible algebra3: σ, Π, ×. worlds semantics on probabilistic databases are equiva- lent for conjunctive queries. More precisely, pwd(qi(Dp)) = qpwd(Dp) for every probabilistic database Dp and ev- 4.1 Intensional Query Evaluation ery conjunctive query q.
One method for evaluating queries on probabilistic data- bases is to use complex events. We review it here and discuss its limitations. Start by expressing q as a query Proof Every tuple t in qi(Dp) has a complex event t.E as- plan, using the operators σ, Π, ×. Then modify each op- sociated with it. pwd(qi(Dp)) consists of a set of worlds, erator to compute the event attribute E in each interme- each world assigning a truth value to the set of atomic i i i diate result: denote σ ,Π , × the modified operators. It events. A tuple t belongs to a world in pwd(qi(Dp)) if is more convenient to introduce them in the functional t.E is true in that world. representation, by defining the complex event e (t) for P qpwd(Dp) also consists of a set of worlds, each assign- each tuple t, inductively on the query plan P, as shown ing a truth value to the set of atomic events. The content in Fig 6. of a world in qpwd(Dp) is the output of q on the database The tabular definitions for σi,Πi, ×i follow easily: σi defined by that world. acts like σ then copies the complex events from the input tuples to the output tuples; Πi associates to a tuple t the Given a world W (i.e. a deterministic database W ), which is defined by an assignment of truth values to the complex event e1 ∨ ... ∨ en obtained from the complex atomic variables, let qpwd(Dp)[W ] and pwd(qi(Dp))[W ] events of all input tuples t1, . . . , tn that project into t; and ×i simply associates to a product tuple (t, t0) the denote the set of tuples in the corresponding worlds. complex event e ∧ e0. We will prove, by induction on the size of q, that for all W , qpwd(Dp)[W ] = pwd(qi(Dp))[W ]. This will Example 2 Let us consider the database Dp described in show that both the semantics result in exactly the same p p Fig. 2. Consider the query plan, P = ΠD(S 1B=C T ). possible worlds with same probabilities. Fig. 7 shows the intensional evaluation of the query (we If a query just selects a single relation, this holds triv- i p used the tuple names as atomic events). P (D ) contains ially. If q is a larger query, there are three possibilities: 0 0 a single tuple p with the event (s1 ∧ t1) ∨ (s2 ∧ t1).
i p It can be shown that P (D ) does not depend on 1. q = ΠA(q1). Consider any world W . By induction the particular choice of plan P, and we denote qi(Dp) i p pwd p hypothesis, pwd(q1(D ))[W ] = q1 (D )[W ]. Thus, the value Pi(Dp) for any plan P for q, and call it the
3 Notice that Π also does duplicate elimination 4 In [12] this is the only query semantics considered. Efficient Query Evaluation on Probabilistic Databases 7
P rR(t) = P r(eR(t)) pwd p t ∈ q (D )[W ] ⇔ t.E = true P rP (t) if c(t) is true P rσe(P)(t) = ⇔ (∨ t .E) = true c 0 if c(t) is false t1:ΠA(t1)=t 1 Q 0 P rΠe (P)(t) = 1 − 0 0 (1 − P rP (t )) A¯ t :ΠA¯(t )=t ⇔ ∃t1,ΠA(t1) = t, 0 0 P rP×eP0 (t, t ) = P rP (t) × P rP0 (t ) i p t1 ∈ pwd(q1(D ))[W ] ⇔ ∃t1,ΠA(t1) = t, pwd p Fig. 8 Extensional Evaluation t1 ∈ q1 (D )[W ] ⇔ t ∈ qpwd(Dp)[W ] 4.2 Extensional Query Evaluation 2. q = σc(q1). Consider any world W . Again, we have pwd(qi (Dp))[W ] = qpwd(Dp)[W ] We now modify the query operators to compute proba- 1 1 bilities rather than complex events: we denote σe,Πe, ×e t belongs to pwd(qi(Dp))[W ] iff t.E is true, i.e. t sat- the modified operators. This is much more efficient, since i p isfies σc and t belongs to pwd(q1(D ))[W ]. Similarly, it involves manipulating real numbers rather than event i p t belongs to pwd(q (D ))[W ] iff t satisfies σc and t expressions. We define a number P rP (t) ∈ [0, 1] for each pwd p belongs to q1 (D )[W ]. Therefore, we get tuple t, by induction on the structure of the query plan P. The inductive definitions in Fig 4.2 should be com- i p pwd p pwd(q (D ))[W ] = q (D )[W ] pared with those in Fig 6. Unlike the formulas in Fig. 6, the extensional operators assume that the input tuples 3. q = q1 1 q2. We have have independent events. Recall that eR(t) is the event i p pwd p pwd(q1(D ))[W ] = q1 (D )[W ], associated with tuple t in relation R as defined in Sec 3. i p pwd p Again, the tabular definitions of σe,Πe, ×e follow pwd(q2(D ))[W ] = q (D )[W ] 2 easily: σe acts like σ then propagates the tuples’ proba- Given a tuple t = (t1, t2) belonging to q, t.E = t1.E ∧ bilities from the input to the output, Πe computes the t2.E1. Thus, probability of a tuples t as 1−(1−p1)(1−p2) ... (1−pn) where p1, . . . , pn are the probabilities of all input tuples t ∈ qpwd(Dp)[W ] ⇔ t.E = true that project to t, while × computes the probability of each tuple (t, t0) as p × p0. ⇔ t1.E = true, t2.E = true e p i p We call the result, P (D ), the extensional semantics ⇔ t1 ∈ pwd(q1(D ))[W ], of the plan P. If we know Pe(Dp) = qrank(Dp), then we i p t2 ∈ pwd(q2(D ))[W ] simply execute the plan under the extensional semantics. pwd p But, unfortunately, this is not always the case, as we saw ⇔ t1 ∈ q (D )[W ], 1 in Sec. 2. Moreover, Pe(Dp) depends on the particular pwd p t2 ∈ q2 (D )[W ] plan P chosen for q. Our goal is to find a plan for which ⇔ t ∈ qpwd(Dp)[W ] the extensional semantics is correct. i p pwd p Thus, by induction, pwd(q (D )) and q (D ) are Definition 1 Given a schema R¯p,Γ p, a plan P for a equal. query q is safe if Pe(Dp) = qrank(Dp) for all instances p Theorem 2 allows us to compute qrank(Dp) as follows. D of that schema. First compute qi(Dp), then compute the probability P r(e) We show next how to find a safe plan. for each complex event. Then qrank(Dp) = P r(qi(Dp)). rank p Example 3 Fig. 7(c) shows p (D ) for Ex. 2. P r((s1 ∧ t1) ∨ (s2 ∧ t1)) was shown in Ex. 1. 4.3 The Safe-Plan Optimization Algorithm
It is very impractical to use the intensional semantics Recall that a probabilistic database schema R¯p may con- to compute the rank probabilities for two reasons. First, i p sists both of probabilistic relation names, which have the event expressions in q (D ) can become very large, an event attribute E, and deterministic relation names. due to the projections. In the worst case the size of such Consider a conjunctive query q; we use the following no- an expression can become of the same order of magnitude tations: as the database. This increases the complexity of the query operators significantly, and makes the task of an – Rels(q) = {R1,...,Rk} all relation names occurring optimizer much harder, because now the cost per tuple is in q. We assume that each relation name occurs at not longer constant. Second, for each tuple t one has to most once in the query (more on this in Sec. 8). compute P r(e) for its event e, which is a #P-complete – P Rels(q) = the probabilistic relation names in q, problem. P Rels(q) ⊆ Rels(q). 8 Nilesh Dalvi, Dan Suciu
– Attr(q) = all attributes in all relations in q. To dis- (i.e. Rp.E for some probabilistic relation Rp) occurs ambiguate, we denote attributes as Ri.A. in two of them having different values of Head(q). – Head(q) = the set of attributes that are in the output Thus, the following functional dependency must hold of the query q. Head(q) ⊆ Attr(q). for each Rp.
For a simple illustration, consider the three relations A ,...,A ,Rp.E → Head(q) Rp(A, B, C, E), S(D,F ), T (G, H, K) and the query: 1 k q(A, F ):− Rp(A, B, C),S(D,F ),T (G, H, K), Note that we can replace Rp.E in Eq.( 1) by Attr(Rp), since for tuple-independent relations, Rp.E → Attr(Rp) A = D,D = H,F = K and Attr(Rp) → Rp.E always hold. Then Rels(q) = {Rp, S, T }, P Rels(q) = {Rp}, Attr(q) = Obviously, a plan P consisting of only safe operators {A, B, C, D, F, G, H, K} and Head(q) = {A, F }. is safe. As we prove below, the converse also holds. Let q be a conjunctive query. We define the induced functional dependencies Γ p(q) on Attr(q): Theorem 4 Let P be a safe relational algebra plan for a query q consisting of selects, projects and joins. Then, – Every FD in Γ p is also in Γ p(q). all operators in p are safe. – For every join predicate Ri.A = Rj.B, both Ri.A → p Rj.B and Rj.B → Ri.A are in Γ (q). Proof We will prove the following statement: If P is a – For every selection predicate Ri.A = c, ∅ → Ri.A is p plan for a query q that has at least one unsafe operator in Γ (q). and t is any tuple that can be produced by q, there is a We seek a safe plan P, i.e. one that computes the database Dp such that Pe(Dp) consists of a single tuple probabilities correctly. For that each operator in P must t with incorrect probability. be safe, i.e. compute correct probabilities: we define this First, it is easy to see that for any plan P and database formally next. Dp, Pe(Dp) ≥ qrank(Dp). This is because the only op- Let q1, q2 be two queries, and let op ∈ {σ, Π, ×} be a erators that are unsafe are projects, and it is easy to see relational operator. Consider the new query op(q1, q2) (or that they can only overestimate the probabilities. Thus, e just op(q1) when op is unary). We say that op is safe if there can only be one-sided errors in the probabilities. e i p i p i i p i p op (P r(q1(D )), P r(q2(D ))) = P r(op (q1(D )), q2(D )) We will prove the theorem by induction on the size (and similarly for unary operators), ∀Dp s.t. Dp |= Γ p. of the plan. In other words, op is safe if, when given correct proba- If P returns a single relation, its safe and the assertion bilities for its inputs ope computes correct probabilities holds trivially. for the output tuples. Consider a larger plan P and assume it is safe. There are three cases: Theorem 3 Consider a database schema where all the 0 probabilistic relations are tuple-independent. Let q, q be 1. P = q1 1 q2. Since P is unsafe, at least one of q1 and conjunctive queries that do not share any relation name. q2 is unsafe. W.L.O.G, assume q1 is unsafe. Given Then, any tuple t = (t1, t2), a database can be constructed 1. σe is always safe in σ (q). such that q1 results in a single tuple t1 with incorrect c c probability. Since P r (t , t ) = P r (t ) ∗ P r (t ), 2. ×e is always safe in q × q0. P 1 2 q1 1 q2 2 e p for the final probability to be correct, both P rq (t1) 3. Π is safe in ΠA ,...,A (q) iff for every R ∈ 1 A1,...,Ak 1 k and P r (t ) have to be correct (since errors can only P Rels(q) the following can be inferred from Γ p(q): q2 2 be one-sided). Thus, we have constructed a database p A1,...,Ak,R .E → Head(q) (1) that results in a single tuple t with incorrect proba- bility. Proof 2. P = ΠA(q1). If q1 is safe, the final project operator 1. Follows trivially from definition. must be unsafe and hence, by definition, there exists a 2. Since we assume all relations in the query to be dis- database where the final result is incorrect. If t is any tinct, the complex events in the output of q and q0 tuple in the output whose probability is incorrect, we comprise of distinct atomic events. Thus, given a tu- can restrict the database to produce only the tuple t 0 0 ple tjoin = (t, t ) ∈ q × q , P r(tjoin.E) = P r(t.E ∧ (whose probability is still incorrect). t0.E) = P r(t.E)P r(t0.E). So, the join operator is safe. If q1 is not safe, there is a database on which q1 pro- The independence assumed by the operator indeed duces a single tuple with incorrect probability. Thus, holds. the final project also produces a single tuple whose 3. For each output tuple t of the project, consider the set probability is still incorrect. St of input tuples that map to t. The operator is safe 3. P = σc(q1). Consider any tuple t that satisfies the if for each such t, the complex events corresponding to condition c and create a database on which q1 pro- tuples in St are independent. Thus, among all tuples duces t with incorrect probability. Thus, σc(q1) also having the same value for A1, ··· Ak, no atomic event produces a single tuple with incorrect probability. Efficient Query Evaluation on Probabilistic Databases 9
We explain safe plans with an example below. Algorithm 1 is our optimization algorithm for finding a safe plan. It proceeds top-down, as follows. First, it Example 4 Continuing the example in Sec. 2, assume tries to do all safe projections late in the query plan. that both Sp and T p are tuple-independent probabilistic When no more late safe projections are possible for a p relations. Hence Γ is: query q, it tries to perform a join 1c instead, by splitting q into q 1 q . Since 1 is the last operation in the Sp.A, Sp.B → Sp.E 1 c 2 c query plan, all attributes in c must be in Head(q). Hence, T p.C, T p.D → T p.E Rels(q1) and Rels(q2) must form a separation. Sp.E → Sp.A, Sp.B To find a separation, we construct a graph G(q) which T p.E → T p.C, T p.D we call the constraint graph. The nodes of G(q) are Rels(q) and the edges are all pairs (Ri,Rj) of connected rela- The last two functional dependencies follow from the fact tions, i.e. s.t. q contains some join condition Ri.A = that a tuple-independent relation has a distinct atomic Rj.B with either Ri.A or Rj.B not in Head(q). Find p event for each tuple. Consider the plan ΠD(S 1B=C the connected components of G(q), and choose q1 and p T ). We have shown in Fig. 4 that, when evaluated ex- q2 to be any partition of these connected components: tensionally, this plan is incorrect. We explain here the this defines Rels(qi) and Attr(qi) for i = 1, 2. Define e reason: the operator ΠD is not safe. An intuitive justi- Head(qi) = Head(q) ∩ Attr(qi), for i = 1, 2. If G(q) is a fication can be seen immediately by inspecting the rela- connected graph, then the query has no safe plans (more p i p tion S 1B=C T in Fig. 7 (a). The two complex events on this below). If G(q) has multiple connected compo- share the common atomic event t1, hence they are corre- nents, then we have several choices for splitting q. If q e lated probabilistic events, while the formula for ΠD only has a safe plan at all, then we will show that all these works when these events are independent. We show how choices lead to a safe plan; hence we can deploy any e to detect formally that ΠD is unsafe. We need to check: standard cost based optimizations algorithm that works in top-down fashion to select the cheapest plan among T p.D, Sp.E → Sp.A, Sp.B, T p.C, T p.D several possibilities5. More on this in Sec 6. p p p p p p T .D, T .E → S .A, S .B, T .C, T .D Finally, the algorithm terminates when no more pro- jections are needed. The remaining join and/or selection operators can be done in any order. The first follows from Γ p and from the join condition B = C, which adds Sp.B → T p.C and T p.C → Sp.B. p p p But the second fails: T .D, T .E 6→ S .A. Algorithm 1 Safe-Plan(q) Example 5 Continuing the example, consider now the 1: if Head(q) = Attr(q) then p p e 2: plan ΠD(ΠB(S ) 1B=C T ). We will prove that ΠD 3: return any plan P for q is safe. For that we have to check: 4: (P is projection-free, hence safe) 5: end if T p.D, Sp.E → Sp.B, T p.C, T p.D 6: for A ∈ (Attr(q) − Head(q)) do p p p p p 7: let qA be the query obtained from q T .D, T .E → S .B, T .C, T .D 8: by adding A to the head variables 9: if ΠHead(q)(qA) is a safe operator then 10: e e 11: return Π ( (q )) Both hold, hence ΠD is safe. Similarly, ΠB is safe in Head(q) Safe-Plan A Π (Sp), which means that the entire plan is safe. 12: end if B 13: end for 14: Split q into q 1 q Before we describe our algorithm for finding a safe 1 c 2 15: s.t. ∀R1 ∈ Rels(q1) R2 ∈ Rels(q2) plan, we need some terminology. 16: R1,R2 are separated. 17: Definition 2 (Separate relations) Let q be a conjunc- 18: if no such split exists then tive query. Two relations R ,R ∈ Rels(q) are called 19: i j 20: return error(“No safe plans exist”) connected if the query contains a join condition Ri.A = 21: end if Rj.B and either Ri.A or Ri.B is not in Head(q). The 22: relations Ri,Rj are called separate if they are not con- 23: return Safe-Plan(q1) 1c Safe-Plan(q2) nected.
Definition 3 (Separation) Two sets of relations Ri and Rj are said to form a separation for query q iff Example 6 Continuing the example in Sec. 2, consider 1. They partition the set Rels(q) the original query in Fig. 3 (b), which we rewrite now 2. For any pair of relations R and R such that R ∈ i j i Ri 5 It is also possible to adapt our algorithm to work with a and Rj ∈ Rj, they are separate. bottom-up optimizer. 10 Nilesh Dalvi, Dan Suciu as: 4.4 Completeness of Safe-Plan algorithm q(D):− Sp(A, B),T p(C,D),B = C Here Attr(q) = {A, B, C, D} and Head(q) = {D}. The We have shown that Safe-Plan algorithm is sound. We algorithm first considers the three attributes A, B, C in next prove that it is complete, i.e., if the query is safe, Attr(q)−Head(q), trying to see if they can be projected the algorithm finds a safe plan for it. out late in the plan. A cannot be projected out. Indeed, We start with few basic results about extensional evaluation. the corresponding qA is: p p qA(A, D):− S (A, B),T (C,D),B = C Lemma 1 Under extensional evaluation, for any query q, and Πe is unsafe in Π (q ) because T p.D, T p.E 6→ e e e D D A ΠA(ΠA∪B(q)) = ΠA(q) Sp.A, as we saw in Example 4. However, B and C can be projected out. By successively doing the projections, Proof These two expressions have the same output tu- we get the plan for q as ΠD(ΠBD(qBC )), where: ples. We only have to show that the tuples have the same p p probability in both expressions. qBC (B,C,D):− S (A, B),T (C,D),B = C Consider a tuple t belonging to ΠA(ΠA∪B(q)). Then, Now we process qBC , where Attr(qBC ) = {A, B, C, D}, 1 − P rΠA(ΠA∪B (q))(t) Head(qBC ) = {B,C,D}. No projection is possible, but Y 0 we can split the query into q1 1B=C q2 where q1, q2 are: = (1 − P rΠA∪B (q)(t )) 0 0 p (t |ΠA(t )=t) q1(B):− S (A, B) p Y Y 00 q2(C,D):− T (C,D) = (1 − P rq(t )) 0 0 00 00 0 (t |ΠA(t )=t) (t |ΠA∪B (t )=t ) The split qBC = q1 1B=C q2 is indeed possible since both Y 00 B and C belong to Head(qBC ). Continuing with q1, q2, = (1 − P rq(t )) 00 00 we are done in q2, while in q1 we still need to project (t |ΠA(t )=t) p p out A, q1 = ΠB(S ), which is safe since B,S .E → A. = 1 − P rΠ (q) Putting everything together gives us the following safe A plan: This proves the lemma. P0 = Π (Π ((Π (Sp) 1 T p)) D DB B B=C Lemma 2 Consider a query q and let A be any attribute The plan can be further optimized. For instance, it can in Head(q). If Π(Head(q)\A)(q) has a safe plan, q also has be shown that the projection ΠDB is redundant in the a safe plan. above join. We discuss the optimization of safe plans in details in Sec 6. Proof Let P be a safe plan for query Π(Head(q)−A)(q). By Lemma 1, we can assume that each project operator We state now the soundness of our algorithm: the in P removes exactly one attribute. Consider the project proof follows easily from the fact that all projection op- operator op in P that removes A. Create a new plan P0 erators are safe. We prove in the next section that the with op removed from P. We will now show that this plan algorithm is also complete. is safe for q. Since P is a safe plan, every project operator Proposition 1 The safe-plan optimization algorithm satisfies the condition in Theorem 3 given by Equation is sound, i.e. any plan it returns is safe. (1). For the operators in P0 that are not ancestors of op, Equation (1) remains same. So they are still safe. For the Proof Define the size of the query q to be |Rels(q)| + operators in P0 that are ancestors of op, A gets added to |Attr(q)| − |Head(q)|. We will prove the proposition by the left of equation (1). So the functional dependencies induction on the size of the query. still hold and the operators are still safe. Thus, a safe Algorithm 1 returns a plan in the following three plan exists for q. cases: 1. It returns at line 2. In this case, the plan consists only Lemma 3 Consider a plan P1 = ΠA(q1 1 q2), where of joins and selects, and hence, is safe. q1 and q2 are queries and Heads(q1) ⊆ A. Also, let A contain all the attributes used in the join between q1 and 2. It returns at line 9. Note that qA is smaller in size q2. Let P2 = q1 1 (Π (q2)). Then P1 is safe that q. By induction, Safe-Plan(qA) is safe. Also, A∩Heads(q2) by definition, the final project operator is safe. Thus, implies that P2 is safe. the algorithm returns a safe plan. Proof First, P2 is a valid plan because A contains all the 3. The algorithm returns at line 16. q1 and q2 are both attributes that are used in the final join. smaller that q. By induction, both Safe-Plan(q1) Since ΠA(q1 1 q2) is safe, the following can be in- and Safe-Plan(q1) are safe plans. These plans are ferred from Γ p(q 1 q ) for each Rp ∈ P Rels(q 1 q ): then connected by a join operator, which is always 1 2 1 2 p safe. So the returned plan is safe. A, R .E → Heads(q1 1 q2) Efficient Query Evaluation on Probabilistic Databases 11
The above can be rewritten as 3. The top operator on P is a project. Thus, P can be 0 0 written as ΠA(P ). Let q be the query corresponding to P0. Note that (S, T ) is still a separation for q0. p 0 Heads(q1),A ∩ Heads(q2),R .E → (2) By induction hypothesis, there is a safe plan for q of the form P0 1 P0 . Also, A can be written as the Heads(q1) ∪ Heads(q2) S T disjoint union of AS and AT , where AS are attributes We know that plans q1 and q2 are safe. Thus, to of relations from S and AT are attributes of T . Thus, show that P2 is safe, we only need to show that the the following plan is safe for q: project operator ΠA∩Heads(q2)(q2) is safe. So, for each 0 0 p p Π(AS ,AT )(PS, PT ) R ∈ P Rels(q2), Γ (q2) must imply the following: Using Lemma 1, we get the following equivalent safe p A ∩ Heads(q2),R .E → Heads(q2) (3) plan:
0 0 Π (Π 0 (P 1 P )) Let Γjoin be the set of FDs introduced by the final AS ,AT Heads(PS )∪AT S T join. Then, Γ p(q 1 q ) = Γ p(q )∪Γ p(q )∪Γ . Since A 1 2 1 2 join We observe that Lemma 3 is applicable to the plan contains all the attributes that occur in Γjoin, Γjoin does 0 0 0 p p (ΠHeads(P )∪AS (PS 1 PT )) since (S, T ) is a separa- not help in inferring Equation (2). Thus, Γ (q1)∪Γ (q2) S imply Equation (2) and hence the following: tion. Thus, the following equivalent plan is also safe: 0 0 p ΠAS (PS 1 (ΠAT (PT ))) Heads(q1),A ∩ Heads(q2),R .E → Heads(q2) Another application of Lemma 3 yields the following p But now, since Γjoin is not present, Heads(q1) and Γ (q1) plan p 0 0 have no contribution in the above equation. Thus, Γ (q2) (ΠAS (PS)) 1 (ΠAT (PT )) alone implies Equation (3). 0 0 Setting PS = ΠAS (PS) and PT = ΠAT (PT ), we get This shows that P2 is a safe plan. the required result. Theorem 5 Let q be a query that has a separation (S, T ). The theorem then follows from the principle of induction. Then, if q has a safe plan, there must be another safe Theorem 6 Algorithm Safe-Plan is complete. plan of the form PS 1 PT such that P Rels(PS) = S and P Rels(PT ) = T (where the join may contain a set of Proof Let q be the given query. Suppose it has an at- select conditions). tribute A belonging to Attr(q) − Head(q) such that the operator Π (q ) is a safe operator, where q is as Proof We will prove this by induction on the size of the Head(q) A A defined in the algorithm. Then, by Lemma 2, q has a safe query. The base step corresponding to queries over a sin- plan if and only if q has a safe plan. So the algorithm gle relation holds trivially. Let P be a safe plan for q. A recursively solves for q . On the other hand, suppose There are three cases: A there is no such attribute A. This implies that in any 1. The top operator on P is a join. Thus, P can be writ- safe plan, the final operator cannot be a project opera- ten as P1 1 P2. Let q1 and q2 be the queries corre- tor as it is not safe. So a safe plan must consist of a join sponding to the plans P1 and P2. It is easy to see that of two subplans. These two subplans must form a separa- (P Rels(P1)∩S, P Rels(P1)∩T ) form a separation for tion because after they are joined, there is no projection. q1. By induction, there is a safe plan PS1 1 PT 1 for q1 Hence, there must exist a separation for q. If not, the al- where S1 = P Rels(P1)∩S and T 1 = P Rels(P1)∩T . gorithm correctly returns false. Otherwise, by Theorem Similarly, there is a safe plan PS2 1 PT 2 for q2 where 5, it is sufficient to solve each of the subproblems cor- S2 = P Rels(P2)∩S and T 2 = P Rels(P2)∩T . Thus, responding to the separation separately. This completes the following is a safe plan for q: the proof of completeness of the algorithm.
(PS1 1 PS2) 1 (PT 1 1 PT 2) 5 Complexity Analysis The safety of the about plan follows from the safety of the individual subplans and the safety of the join We show here a fundamental result on the complexity operators. of query evaluation on probabilistic databases. It forms 2. The top operator on P is a select. Thus, P can be a sharp separation of conjunctive queries into queries 0 0 written as σc(P ). Let q be the query corresponding with low and high data complexity, and shows that our to the plan P0.(S, T ) is still a separation for q0. By optimization algorithm is complete. 0 0 0 induction, there is a safe plan PS 1 PT for q . By The data complexity of a query q is the complexity of simply adding the select condition to the top join, we evaluating qrank(Dp) as a function of the size of Dp. If q get a safe plan as required. has a safe plan P, then its data complexity is in PTIME, 12 Nilesh Dalvi, Dan Suciu because all extensional operators are in PTIME. We start 1. The data complexity of q is #P -complete. by showing that, for certain queries, the data complexity 2. The Safe-Plan optimization algorithm fails to re- is #P -complete. #P is the complexity class of some hard turn a plan. counting problems. Given a boolean formula ϕ, counting 3. There exists a sequence of relations R0,R1, ··· Rk, the number of satisfying assignments, denote it #ϕ, is Rk+1, and attributes A1 and A2, with the following #P -complete [36]. (Checking satisfiability, #ϕ > 0, is properties: NP-complete.) The data complexity of any conjunctive (a) R0 and Rk+1 are probabilistic rank p i p 0 0 0 query is #P , since q (D ) = P r(q (D )). The follow- (b) Attr (R0)∩Attr (R1) contains A1 but Attr (R0) ing is a variant of a result on query reliability by Gradel does not contain A2 0 0 0 et al. [13]. (c) Attr (Rk)∩Attr (Rk+1) contains A2 but Attr (Rk+1) does not contain A1 0 0 0 0 Theorem 7 Consider the following conjunctive query (d) Attr (Ri)∩Attr (Ri+1) 6⊆ Attr (R0)∪Attr (Rk+1) on three probabilistic tables: for 1 ≤ i ≤ k − 1 p p q() : −L (x),J(x, y),R (y) Before we give the proof, let is look at some examples. p p Here L ,R are extensional probabilistic tables and J is Example 7 Consider the following four queries: deterministic6. The data complexity for q is #P -hard.
We used here a more standard datalog notation for p p q1() :− L (A),J(B,C),R (D),A = B,C = D conjunctive queries. In our notation the query becomes: p p q : −Lp(A),J(B,C),Rp(D),A = B,C = D. q2(U):− L (A),J(B,C),R (D),A = B,C = D, S(U, U1),U1 = A Proof (Sketch) Provan and Ball [27] showed that com- p p q3() :− R (A),R1(B,C),R2(D,F ),R (H), puting #ϕ is #P -complete even for bipartite monotone 0 3 2-DNF boolean formulas ϕ, i.e. when the propositional A = B,C = D,F = H p p variables can be partitioned into X = {x1, . . . , xm} and q4() :− R0(A, B),R1(C,D),R2(F,G),R3(H,I) Y = {y1, . . . , yn} s.t. ϕ = C1 ∨ ... ∨ Cl where each clause B = D,D = G, G = I,A = C,F = H Ci has the form xj ∧ yk, xj ∈ X, yk ∈ Y . (The satis- fiability problem, #ϕ > 0, is trivially true.). Given ϕ, q1 is exactly the query in Theorem 7, which we know construct the instance Dp where Lp is X, Rp is Y and is unsafe. Let us show that it satisfies the condition (3) J is the set of pairs (xj, yk) that occur in some clause of the above theorem. p Ci. Assign independent probability events to tuples in Since Head(q1) = ∅ and Γ contains only trivial Lp,Rp, with probabilities 1/2. Then qrank(Dp) returns functional dependencies, we have Attr0(L) = {A, B}, a single tuple, with probability #ϕ/2m+n. Thus, com- Attr0(J) = {A, B, C, D}, Attr0(R) = {C,D}, and condi- rank p puting q (D ) is at least as hard as computing #ϕ. tion (3) above follows by taking A1 = A, A2 = D, R0 = p p p p L , R1 = J, and R2 = R . Indeed L and R are prob- We state now the main theoretical result in this pa- abilistic relations, Attr0(L) ∩ Attr0(J) contains A but per. We consider it to be a fundamental property of Attr0(L) does not contain D, and Attr0(J) ∩ Attr0(R) query evaluation on probabilistic databases. First, we contains D but Attr0(R) does not contain A. Also, (d) need some notations. Given a set of attributes S ⊆ Attr(q), holds vacuously because k = 1 here. we denote with S+ = {A ∈ Attr(q) | Γ p(q) ` S → If we modify q1() to q1(A, B, C, D), the query be- A}, i.e. the set of attributes A such that S → A can comes safe, since no projections are needed; this illus- p be inferred from Γ (q). We say that S determines A trates the need to remove the head variables in the defi- + 0 if A ∈ S . For each relation R, denote Attr (R) = nition of Attr0. (Attr(R))+ − (Head(q))+. That is, Attr0(R) consists Let us now look at q2, which is a variation of the of all attributes that are determined by R but not by previous query. Assume that U is a key for the relation Head(q) 7. + S(U, U1). Now, Head(q2) = {U} and (Head(q2)) = {U, U , A, B}, since we have the functional dependency Theorem 8 (Fundamental Theorem of Queries on 1 U → U and the query equates U , A and B. Now, Probabilistic DBs) Consider a schema R¯p,Γ p which 1 1 Attr0(L) = ∅, Attr0(J) = {C,D} and Attr0(L) = {C,D}. consists of a set of probabilistic and deterministic rela- The conditions of Thm. 8 are not satisfied and in fact, tions. Let q be a conjunctive query s.t. each relation oc- the query is safe. It can be verified that the following curs at most once. Assuming #P6=PTIME the following plan is safe: statements are equivalent: e e p e e e p 6 Π (S 1 L 1 (Π (J 1 R ))) Allowing J to be deterministic strengthens the result. The U U1=A A=B B C=D theorem remains true if J is probabilistic. + 7 In general, Attr(R) and Attr0(R) may overlap, without q2 illustrates the need to take Head rather than one of them having to contain the other. Head in the definition of Attr0. Efficient Query Evaluation on Probabilistic Databases 13
Query q3 shows that the length of the sequence of one relation R0 ∈ R¯A that does not determine A2 (oth- ¯ 1 ¯ relations that satisfy condition (3) could be arbitrar- erwise |RA2 | would be strictly greater that |RA1 |). We 8 p ily large . The only probabilistic relations here are R0 claim that the sequence R0,R1,...,Rk,Rk+1 satisfies all p and R1, and the only sequence that satisfies Thm 8 is the four properties. We have R0 and Rk+1 probabilistic, p p R0,R1,R2,R3. This query is unsafe, while if we drop hence (a) holds. (b) and (c) follows from our construc- any relation from the query, it becomes safe. tion. If k = 1, (d) holds vacuously. If k > 1, observe that 0 0 Finally, query q4 shows the need for the property Attr (R0) must be disjoint from Attr (Ri) for i > 1, (d) in condition (3). With A1 and A and A2 as H, the otherwise we can obtain a shorter sequence that con- ¯ 0 0 query satisfies properties (a),(b) and (c) but fails (d). nects RA1 and R . Similarly, Attr (Rk+1) must be dis- 0 This query is safe, with the following safe plan joint from Attr (Ri) for 1 ≤ i ≤ k − 1. (d) follows from these properties. Πe ( Π (Rp 1e R ) 1e {} B 0 A=C,B=D 1 B=D (3) ⇒ (1) We prove this by extending the ideas in e p ΠD(R2 1F =H,G=I R3)) Th. 7. We show a reduction from the problem of counting Theorem 8 provides a sharp separation of feasible the number of assignments of bipartite monotone 2-DNF and infeasible queries on probabilistic databases. It also to evaluating the query q. shows that all the queries that can be evaluated in poly- Let X = {x1, . . . , xm}, Y = {y1, . . . , yn} and ϕ = nomial time can in fact be evaluated using a safe plan. C1∨...∨Cl where each clause Ci has the form xf(i)∧yf(i). Before we give the proof, we need a simple result. We will construct a database as follows. Consider a sin- gle relation RU , which we call the universal table, whose Lemma 4 Let q by any query and A be any attribute not attributes are the union of the attributes of all the rela- in Head(q). Let qA denote the query obtained by adding tions that occur in the query. We partition the attributes e 0 A to the head variables. Then, ΠA(qA) is safe if A ∈ into four sets: SX consists of attributes in Attr (R0) − 0 p p 0 0 0 Attr (R ) for all R ∈ P Rels(q). Attr (Rk+1), SY consists of Attr (Rk+1) − Attr (R0), 0 0 e S0 is (Attr (R0) ∪ Attr (Rk+1)) ∪ (Head(q))+, and SC Proof For ΠA(qA) to be safe, Eq 1 must hold. It holds be- cause for any probabilistic relation Rp, if A ∈ Attr0(Rp), consists of all the remaining attributes. then Attr(Rp) → A and hence, Rp.E → A. We populate RU with l tuples, one corresponding to each clause, as follows: in row i, assign a value of xf(i) Now we prove Thm 8. to all variables in SX , a value of yf(i) to variables in S , a constant value 0 to variables in S and a value of Proof (Theorem 8) Y 0 C to variables in S . From this table, construct indi- (1) ⇒ (2) is obvious, since any safe plan has data i C vidual tables by taking the projections on corresponding complexity in PTIME. columns. For tables R and R , let all events have (2) ⇒ (3) Let us assume that algorithm 0 k+1 Safe-Plan a probability of 0.5 (which we can assign because both fails on q. Then, it must have a sub-query q0 such that of them are probabilistic) and let all other tables have (i) it has no separation and (ii) for every A ∈ Attr(q0) − events with probability 1. The resulting database sat- Head(q0), Πe (q0 ) is not safe where q0 is the query Head(q0) A A isfies all the functional dependencies. To see why, con- 0 q with A added to head. sider any FD, A¯ → A0, where A¯ is a set of attributes 0 0 For each attribute in Attr(q )−Head(q ), by Lemma 4, and A0 is an attribute. For this to be violated, one of there is at least one probabilistic relation that does not 0 the following must hold: (i) A¯ ⊆ S0 and A 6∈ S0, (ii) determine that attribute. Let A be the attribute that 0 1 A¯ ⊆ S0 ∪ SX and A ∈ SY , (iii) A¯ ⊆ S0 ∪ SY and is determined by the largest number of probabilistic re- 0 A ∈ SX . None of the three cases is possible: S0 is equal lations and let R¯ be the set of those probabilistic re- + + + A1 to (Attr(R0)) ∩(Attr(Rk+1)) , S0 ∪SX is (Attr(R0)) lations. There is at least one probabilistic relation not and S ∪ S is (Attr(R ))+, and all of these sets are ¯ 0 0 Y k+1 contained in RA1 . Let R be one such relation. Since the closed under implication. 0 query has no separation, the constraint graph G(q ) (de- Claim: The query q, when evaluated on the above fined in Sec 4.3) is connected. Its easy to see that an 0 database, returns a single tuple with all attributes 0, edge between two relations R1 and R2 in G(q ) implies m+n 0 0 with probability equal to #ϕ/2 . Attr (R1) and Attr (R2) intersect. Thus, there is a se- 0 0 First, since Attr (R0) does not intersect with SC but quence of relations R1, R2 ··· Rk,Rk+1 = R such that ¯ contains SX , the relation R0 will have m tuples corre- R1 ∈ RA1 and sponding to m distinct values of SX attributes. We use 0 0 Attr (Ri) ∩ Attr (Ri+1) 6= ∅ (1 ≤ i ≤ k) (4) the variable names x1, . . . , xm to denote corresponding events. Similarly, the relation Rk+1 will have n distinct Consider the shortest such sequence. Let A2 be any tuples with events denoted by y , . . . , y . Now, consider 0 0 1 n attribute in Attr (Rk) ∩ Attr (Rk+1). There is at least the intensional evaluation of q that first joins everything 8 Cor. 1 says that when the schema contains only proba- and then projects on Head(q). When we join all the ta- bilistic relations, we never need a sequence of relations more bles back using the join conditions in the query, we get than three. back the RU table. This is due to the SC variables. Note 14 Nilesh Dalvi, Dan Suciu
0 0 e e 9 that for 1 ≤ i < k, Attr (Ri) ∩ Attr (Ri+1) must con- Π and 1 do not satisfy the traditional equivalences . e e tain at least one attribute from the set SC because of For instance, Π and 1 do not commute. Therefore, we the property (d). Thus, SC attributes connect a tuple give a set of transformation rules for these operators that xi in R0 with yj in Rk+1 if and only if (xi ∧ yj) is a can be used to search for alternate safe plans. clause in ϕ. The join results in precisely l tuples, with A transformation rule takes a relational algebra plan complex events corresponding to the clauses in ϕ. When consisting of these extensional operators and produces a we project this table on Head(q), since Head(q) ⊆ S0, new plan. We say that a transformation rule is sound if, we get just one tuple whose complex event is the formula when applied to a safe plan, it results in a safe plan10. ϕ. Since all truth assignments have the same probability, Below are some transformation rules: the probability of ϕ is #ϕ/2m+n. Rule 1: [Join Commutativity] Extensional joins are com- mutative Corollary 1 Consider the special case of Thm. 8 where e e all relations are probabilistic, i.e. there are no determin- R 1 S ⇔ S 1 R istic relations. Then, condition (3) of the theorem can be Rule 2: [Join Associativity] Extensional joins are asso- replaced by the following simpler condition: ciative
3’. There exists three relations R0, R1 and R2, and at- R 1e (S 1e T ) ⇔ (R 1e S) 1e T 0 0 tributes A1 and A2, s.t. Attr (R0) ∩ Attr (R1) con- 0 0 tains A1 but not A2, and Attr (R1) ∩ Attr (R2) con- Rule 3: [Cascading Projections] Successively eliminating tains A2 but not A1. attributes from a relation is equivalent to simply elim- inating all but the attributes retained by the last pro- Proof It is easy to check that (30) above implies (3) in jection e e e Thm. 8. To prove in the other direction, consider the ΠA(ΠA∪B(R)) ⇔ ΠA(R) sequence R ,R ,...,R ,R in (3). We will show that 0 1 k k+1 Rule 4: [Pushing Projections Below a Join] A projection R0, R1 and R2 satisfy the properties above. If k = 1, 0 can be pushed below a join if it retains all the at- this holds trivially. If k > 1, let A2 be any attribute 0 0 0 tributes used in the join. in Attr (R1) ∩ Attr (R2) − Attr (R0), which exists by 0 0 property (d). Thus, Attr (R0) ∩ Attr (R1) contains A1 Πe (R 1e S) ⇒ (Πe (R)) 1e (Πe (S)) 0 0 0 0 A A1 A2 but not A2, and Attr (R1) ∩ Attr (R2) contains A2 but not A1. where A1 and A2 are the attributes in R and S re- tained by the projection. When Γ p is empty, i.e. there are no functional depen- dencies expect for the trivial dependencies, Cor. 1 gives Rule 5: [Lifting Projections Up a Join] A Projection can us a very elegant characterization of the queries with not always be lifted up a join. The following trans- #P -complete complexity. A query is #P -complete, if it formation rule can be applied only when the top Πe contains the following pattern (shown in datalog nota- operator in the resulting plan satisfies the Eq. 1 of tion), with x, y 6∈ Head(q) Thm. 3.
e e e e q(...):− R0(x, . . .),R1(x, y, . . .),R2(y, . . .), ··· (ΠA(R)) 1 S ⇒ ΠA∪Attrs(S)(R 1 S)
If such a pattern can not be found in the query, the data Theorem 9 The transformation rules described above complexity of the query is PTIME. are sound. The soundness of rules 1 and 2 can be verified easily, rules 3 and 4 follow from Lemma 1 and Lemma 3 respec- 6 Query Optimization tively, while Rule 5 is sound by definition. We haven’t shown the rules involving σe operator, but it behaves ex- We have shown in Sec 4 that the relational algebra oper- actly like the traditional select operator and commutes ators can be modified to compute the probabilities, and with project, join and other select operators. e e e we introduced three new operators: σ , Π and 1 . Fur- Next, we study the completeness of the rules. Ideally, ther, we saw that different relational algebra plans for the we would like to traverse the space of all safe plans using same query can give different answers under extensional the above transformation rules. Given two plans P1 and semantics, and only a subset of plans are safe, i.e. give correct answers. In this section, we consider the problem 9 Contrast this with the intensional operators σi, Πi and of finding an efficient safe plan using a cost-based opti- 1i defined in Sec 4.1. It is shown in [12] that these operators mizer. Recall that the Safe-Plan algorithm in Sec 4.3 satisfy all the equivalences that traditional operators satisfy 10 A sound transformation rule applied to an unsafe plan only gives us one safe plan. Traditional query optimiz- may result in a plan that is not equivalent to it. We only ers start from one query plan and use relational algebra require that the rule produce equivalent plans when applied equivalences to search for alternate plans. However, σe, to safe plans Efficient Query Evaluation on Probabilistic Databases 15
∗ P2, let P1 ⇒ P2 denote the statement that P2 can be the form PS1 1 PT1 , where PS1 only refers to relations in obtained from P1 by a sequence of the above transfor- S1 and PT1 only refers to relations in T1. By induction ∗ mation rules. Note that rules 1, 2 and 3 can be applied in hypothesis, PS1T1 ⇔ PS1 1 PT1 . Using similar argu- ∗ either direction. Also, if P2 can be obtained from P1 by ment, we get PS2T2 ⇔ PS2 1 PT2 for some plans PS2 applying rule 4, then P1 can be obtained back from P2 and PT2 . We have by applying rule 5. The rule will be applicable because e P2 = PS T 1 PS T P1, being a safe plan, will satisfy the conditions of rule 1 1 2 2 ∗ e e e 5. Hence, we have the following result. ⇔ (PS1 1 PT1 ) 1 (PS2 1 PT2 ) ∗ e e e ∗ ⇔ (PS1 1 PS2 ) 1 (PT1 1 PT2 ) Lemma 5 For two safe plans P1 and P2, if P1 ⇒ P2, ∗ then P2 ⇒ P1. The last equivalence uses the rules 1 and 2 to reorder the joins. We again use induction hypothesis on these sub- This makes ⇒∗ an equivalence relation. To empha- e ∗ e ∗ plans to get (PS1 1 PS2 ) ⇔ PS and (PT1 1 PT2 ) ⇔ PT . size this, we will use the notation P ⇔∗ P to denote ∗ 1 2 This proves that P1 ⇔ P2. that either plan be transformed into the other. We next prove our main result for query optimization which says that the transformation rules are complete, i.e. any safe 7 Unsafe Plans plan can be reached from any other safe plan using these transformations. When a query’s data complexity is #P -complete, then Safe-Plan fails to return a plan. Since this can indeed Theorem 10 Let P1 and P2 be two safe plans for a ∗ happen in practice, we address it and propose two solu- query q. Then, P1 ⇔ P2. tions. Proof First, using rule 3 in the reverse direction in both e P1 and P2, we ensure that every Π operator removes exactly one attribute. Now, we use induction on the size 7.1 Least Unsafe Plans of the plans. e Suppose the topmost operator in P1 is a Π operator Here we attempt to pick a plan that is less unsafe than that removes the attribute A. Let qA be the query ob- others, i.e. minimizes the error in computing the prob- abilities. Recall from Eq.(1) that Πe is safe in tained from q by adding A to the head variables. Then, A1,...,Ak P = Πe (P0 ), where P0 is a safe plan for query Πe (q) iff A ,...,A ,Rp.E → Head(q) for every 1 Heads(q) 1 1 A1,...,Ak 1 k p p p p qA. Consider the operator in P2 that removes the at- R . Let B¯ = {A1,...,Ak,R .E}∩Attr(R ) (hence R .E ∈ 0 ¯ ¯ p p tribute A (it need not be the top operator in P2). Let P2 B) and C = Head(q) ∩ Attr(R ). Define Rfanout to be be the plan obtained by removing this operator from P2. the expected number of distinct values of C¯ for a fixed 0 As shown in the proof of Lemma 2, P2 is a safe plan for value of the attributes B¯. In a relational database sys- 0 ∗ 0 the query qA. By induction hypothesis, P1 ⇔ P2 and tem, it is possible to estimate this value using statis- hence, tics on the table Rp. Define the degree of unsafety of e p e 0 ∗ e 0 Π to be max p (R − 1). Thus, a P = Π (P ) ⇔ Π (P ) A1,...,Ak R ∈P REL(Q) fanout 1 Heads(q) 1 Heads(q) 2 safe project has degree of unsafety 0. Also, the higher e 0 the degree of unsafety, the higher is the expected error Note that Π (P2) is a plan that looks exactly Heads(q) that would result from using the extensional semantics like P2 except that it removes the attribute A as a fi- nal operation. Using successive applications of rule 4, for that project operator. we can push this operation down to its original place in We modify Algorithm 1 to cope with unsafe queries. Recall that the algorithm tries to split a query q into P2 (its always safe to push a projection down). Thus, e 0 ∗ ∗ two subqueries q1, q2 s.t. all their join attributes are in Π (P ) ⇔ P2, which proves that P1 ⇔ P2. Heads(q) 2 Head(q). Now we relax this: we allow joins between q If the topmost operator in P is a Πe, we can again 1 2 and q on attributes not in Head(q), then project out apply the same argument. So lets assume that both of 2 these attributes. These projections will be unsafe, hence them have a 1e as the top operator. Let the top join in we want to minimize their degree of unsafety. To do that, P split the relations into sets S and T , and let the corre- 1 we pick q , q to be a minimum cut of the graph, where sponding subplans be P and P . Thus, P = P 1e P . 1 2 S T 1 S T each edge representing a join condition is labeled with S and T must form a separation for q since there are no the degree of unsafety of the corresponding project op- projections after the join. Similarly, let the top join in eration11. The problem of finding minimum cut is poly- P split the relations into S ∪ T and S ∪ T , where 2 1 1 2 2 nomial time solvable as a series of network flow problems S1,S2 ⊆ S and T1,T2 ⊆ T . Again, S1 ∪ T1 and S2 ∪ T2 e or using the algorithm of Stoer and Wagner [33]. form a separation. Let P2 = PS1T1 1 PS2T2 . Denote qS T the query represented by the plan PS T . S1 and 11 p 1 1 1 1 The estimator of Rfanout should make sure that the esti- T1 form a separation for qS1T1 , since S and T form a sep- mated value is 0 only when the FD holds, otherwise the algo- aration. By Thm. 5, qS1T1 has an equivalent safe plan of rithm may favor ‘expected’ safe plans over truly safe plans. 16 Nilesh Dalvi, Dan Suciu
7.2 Monte-Carlo Approximations final note, if N is very small, an exact algorithm may be applied in place of the simulation. This choice can be As an alternative, we present now an algorithm based made independently for each output tuple. on a Monte-Carlo simulation, which runs in polynomial time and approximates the probabilities to arbitrary pre- cision. 8 Extensions Given a conjunctive query q over probabilistic rela- p p p 0 tions R1,R2 ··· Rk, let q be the query obtained from 8.1 Relations with Repeated Events q by making it return all the variables in its body, i.e. 0 0 0 Head(q ) = Attr(q ) = Attr(q) and q = ΠHead(q)(q ). The various results and the query evaluation technique 0 ¯ p Also, let q return all event attributes E = R1.E, ..., we have described so far assume that all the events in p 0 Rk.E. Evaluate q over the database (without any prob- probabilistic relations are distinct. However, there are ability calculations) and group the tuples in the answer several scenarios that require multiple tuples sharing a based on the values of their attributes Head(q). Consider common event. Consider a relation Casts(actorname, one such group, and assume it has n tuples t1, . . . , tn. filmname) and a query with an approximate predicate The group defines the following complex event expres- Casts.actorname ≈ · · · . Given two tuples with the same Wn sion: i=1 Ci, where each Ci has the form e1 ∧ ... ∧ ek. actor name, the user either wants both of them or none of We need to compute its probability, since this will be them. Thus, a common event should be associated with the probability of one tuple in qrank(Dp). We are back both the tuples, rather than each one of them indepen- to the problem of evaluating the probabilities of complex dently satisfying the predicate. This choice also affects events, but now these events Ci are in disjunctive nor- the probabilities of the resulting tuples. Suppose the user mal form (DNF). Before we describe the techniques to simply wants to return a list of actors (with the predicate evaluate the probabilities of DNF formulas, let us look Casts.actorname ≈ · · · ). If an actor that approximately at an example. matches the predicate appears 100 times in the relation Consider the probabilistic database given in Fig. 2 with independent events, its final probability in the an- and the query in Fig. 3 (b). We have swer would be very high. On the other hand, if the same event is given to all these tuples, the final probability p p q(u): S (x, y),T (z, u), y = z will not depend on how many times the actor appears in
0 the database. We create a new query q that returns all the variables Fortunately, handling repeated events is easy in our in its body, which is as follows: framework. A user can specify them by using functional dependencies involving the event attributes. In the above q(u, x, y, z): Sp(x, y),T p(z, u), y = z example, the query predicate induces the following de- When we evaluate it over the probabilistic database, we pendency: Casts.actorname → Casts.E. For the query get the following result: evaluation algorithms to work, we can use the following four-step procedure: x y z u E 1. Normalize the schema: we create a virtual schema ‘m’ 1 1 ’p’ s1 ∧ t1 ‘n’ 1 1 ’p’ s ∧ t that represents the same data in normalized form, 2 1 such that no probabilistic table has repeated events. Observe that since the new query returns all the variables This is achieved as follows: for each probabilistic table in its body, there are no projections and every event is T P where the events in T P .E are not unique, we a conjunction of atomic events. We do a final projection decompose it into two tables, a deterministic table 0 0 P P at the end, giving us a single tuple { p } whose event is T1 and a probabilistic table T2 . T2 stores all the P the DNF expression (s1 ∧ t1) ∨ (s2 ∧ t1). distinct events of T . It also has an attribute EID The problem of evaluating the probability of a boolean that stores a unique identifier for each distinct event. P expression, even when restricted to DNF formulas, is T1 is the deterministic part of T along with an extra #P -complete [36]. However, it can be approximated ef- attribute EID that refers to the corresponding events P ficiently using the Monte Carlo algorithm described by in T2. Thus, joining T1 and T2 gives us back the Karp [18]: given a DNF formula with N clauses and any original table T P . This decomposition achieves our and δ, the algorithm runs in time O(N/2 ln 1/δ), and objective: the new schema represents the same data guarantees that the probability of the error being greater and further, every probabilistic table in it has unique that is less than δ. events. Note that this is only a virtual schema: we do In our case, N for a given output tuple is the num- not transform the data into the new schema. ber of tuples that got merged during the final projection 2. Translate original query into new schema: this to produce the output tuple. The simulation algorithm is easy, every occurrences of T P in the query is re- P runs in time linear in N and hence, linear in the size of placed by the join T1 1EID T2 (this is done for each the intermediate result before the final projection. As a T P that is decomposed in step 1) Efficient Query Evaluation on Probabilistic Databases 17
3. Find a safe plan: using our query evaluation algo- rithm, we find a safe plan P 0 for the translated query P rp∪ep0 (t) = 1 − (1 − P rp(t))(1 − P rp0 (t)) P r e 0 (t) = P r (t) × (1 − P r 0 (t)) over the new schema. p− p p p P rγe (p)(t, v) = P rΠe (σe (p))(t)× 4. Translate back to original schema: we translate A,¯ min(B) A¯ B=v (1 − P rΠe (σe (p))(t)) the safe plan P 0 into a plan P over original schema. A¯ B
SELECT P1.year, 10 Prototype 1 - PRODUCT(1 - P1.prob * P2.prob) as prob FROM Based on the theory of probabilistic databases that we (SELECT year, filmid, have developed, we return to the problem of building 1 - PRODUCT(1 - MATCH(name, ‘FILM’)) as prob a system that can support complex SQL queries with FROM Films GROUP BY year, filmid uncertain predicates. ) as P1 Our query language is an extension of standard SQL (SELECT filmid, that has an ≈ operator. Figure 1 shows an example. Our 1 - PRODUCT(1 - MATCH(actor, ‘ACTOR’)) as prob system for supporting these queries have several salient FROM Casts features. First, it is implemented as a middleware. It GROUP BY filmid ) as P2 works on top of any off-the-shelf database engine contain- WHERE P1.filmid = P2.filmid ing relational data. Secondly, it does not require altering GROUP BY P1.year either the schema of the data in the database. Finally, Fig. 10 The final SQL rewriting given an uncertain query, it does not create a new in- stance of probabilistic database. Rather, it rewrites the query into a new standard SQL query that is (i) safe, (ii) contains all the probability calculations embedded in the 11 Experiments query using various aggregates and (iii) can be directly executed by any engine to return the tuples along with We performed some preliminary evaluation of our proba- probabilities. bilistic query evaluation framework, addressing four ques- We describe the above process with the help of an tions. How often does the Safe-Plan optimization al- example. Consider the following SQL query gorithm fail to find a plan? What is the performance of safe plans, when they exists? Are naive approaches to SELECT Films.year query evaluation perhaps almost as good as a safe plan? FROM Films, Casts And how effectively can we handle queries that do not WHERE Films.filmid = Casts.filmid have safe plans? and ≈ Films.name ‘FILM’ We did not modify the relational engine, but instead and ≈ Casts.actor ‘ACTOR’ implemented a middleware. SQL queries with approx- Using the uncertain predicate Films.name ≈ ‘FILM’, imate predicates were reformulated into “extensional” we need to convert the Films table into a probabilistic SQL queries, using the techniques described in this pa- table. Assume we have a function MATCH stored in the per, and calls to a TSQL function computing 3-gram database that given two film names outputs a probabil- distances. These queries were then executed by the rela- ity score of their match. Then, the following SQL query tional engine and returned both tuples and probabilities. represents the probabilistic Films relation We used Microsoft SQL Server. We used the TPC-H benchmark, with a database of SELECT Films.year, 0.1GB. We modified all queries by replacing all the predi- MATCH(Films.name, ‘FILM’) as prob cates in the WHERE clause with uncertain matches. The FROM Films constants in the queries were either misspelled or made Similarly, we can create a SQL statement for a prob- vague. For instance, a condition like part.container = abilistic Casts relation. Now, the following plan is a safe ’PROMO PLATED GREEN’ was replace with part.container plan for the query: ≈ ’GREEN PLATE’. When executed exactly, all modified queries returned empty answers. πyear( (π ) 1 (π )) All of the following experiments were carried on the F ilms.year,F ilms.filmid filmid Casts.filmid first 10 of the 22 TPC-H queries. We found other queries We convert this plan back into a SQL query with to be not very interesting for applying uncertain predi- probability calculations as shown in Fig 10. Note that al- cates, since most of them involve complex aggregates. though standard database engines do not have a PRODUCT 1. Frequency of unsafe queries In our first exper- aggregate, it can be implemented using the following iment, we wanted to see how many queries do not have transformation: safe plans. Out of the 10 TPC-H queries, 8 turned out to have safe plans. Q7 and Q8 were the only query that PRODUCT(A) ≡ POWER(10, SUM (LOG (A))) were unsafe. These also become safe if not all of their This technique of SQL rewriting can be applied to any predicates are uncertain. query plan in general. Recursively, a SQL statement is 2. Performance Next, we measured the running generated for each node where the last attribute refers times for the eight queries that have safe plans, shown to the probability of the tuples and parent nodes nest in Figure 11. All times are wall-clock. The first column the SQL queries of their children. is the running time of the safe plan. The second column represents an optimization where at each intermediate 20 Nilesh Dalvi, Dan Suciu
Running Times of Safe TPC-H Queries Clever Plan versus Naive Plan for Q10 30000 0.8 Safe Plan 0.7 25000 Optimized Query Bare Query 0.6 20000 0.5 15000 0.4
Recall 0.3 10000 0.2 Running Time(ms) 5000 0.1 0 0 Q1 Q2 Q3 Q4 Q5 Q6 Q9 Q10 0 100 200 300 400 500 600 700 800 9001000 Queries Number of Answers
Fig. 11 TPC-H Query Running Times Fig. 14 Recall Plot for Q10
Errors on Safe Queries 3. Naive Approaches In the next experiment we 160 calculated the error produced by a naive extensional 140 plan. We considered the naive plan that leaves all project 120 100 operators (and the associated duplicate elimination) at 80 the end of the plan, which are typical plans produced 60 by database optimizers. The error was calculated as be- 40
Average Error(%) low: for each tuple, we measured the percentage error 20 in its probability relative to the correct probability, and 0 Q2 Q3 Q5 Q9 Q10 we took the average over all tuples. Figure 12 shows the Queries percentage relative error of naive plans. We only consid- ered the 8 queries that have safe plans. The naive plans Fig. 12 Errors on Safe TPC Queries for Q1, Q4, Q6 were already safe, hence had no errors (and Safe-Plan indeed returned the same plan): these queries are not shown. Queries Q3, Q5 and Q10 had large Clever Plan versus Naive Plan for Q3 errors with Q5 showing an average error of 150% in the 0.9 tuple probabilities. Queries Q and Q had negligible er- 0.8 2 9 0.7 rors. Thus, while some naive plans were bad, others were 0.6 reasonable. But, in general, naive plans can be arbitrarily 0.5 bad. However, we argue that the low extra complexity of 0.4 Recall 0.3 searching for a safe plan is a price worth paying in order 0.2 to avoid the (admittedly rare) possibility of arbitrarily 0.1 large errors. 0 0 100 200 300 400 500 600 700 800 9001000 However, since we are only interested in ranking the Number of Answers results, not in the actual probabilities, it is worth asking whether high errors in the probabilities translate into Fig. 13 Recall Plot for Q3 high ranking results. We plotted the recall graphs for queries Q3 and Q10 (for which the naive plan produced only medium errors). We defined recall as the fraction stage, tuples with zero probability are discarded. This of answers ranked among top N by the naive plan that optimization does not affect the final answer and as we should actually have been in top N. We plotted this as a can see from the graph, it brings about considerable sav- function of N. Figures 13 and 14 show the recall graphs. ings for some queries. This also suggests the use of other By definition, the recall approaches to 1 when N ap- optimizations like an early removal of tuples with low proaches the total number of possible tuples in the an- probabilities if the user is only interested in tuples with swer. However, as the graphs show, the recall was bad high probability. The third column in the graph shows for small values of N. A user looking for top 50 or 100 the time for running safe queries without taking into ac- answers to Q3 would miss half of the relevant tuples. For count the computation time for the uncertain predicate, smaller values of N (say, 10) the naive approach misses which, in our case, is the 3-gram distance. The graphs 80% of the relevant tuples. show that most of the time is spent in computing the un- 4. Unsafe Queries Finally, we tested our approach certain predicate (for Q3, this accounts for almost all of to handle queries with no safe plans on Q7 and Q8. We the running time). It suggests that significant improve- ran the Monte Carlo simulation to compute their answer ments can be achieved if the predicates are supported by probabilities and used them as baseline. Figure 15 shows the engine itself. the errors in evaluating them with a naive plan and the Efficient Query Evaluation on Probabilistic Databases 21
Errors on Unsafe Queries sional semantics have been used by Sadri [29–32] to com- 30 pute the reliability of answers to the queries, where the Naive Plan 25 Optimal Break information in the database comes from multiple infor- mation sources of varying reliability. In this framework, 20 the system stores a vector with each tuple that iden- 15 tifies the sources contributing to the tuple, and these 10 vectors are manipulated as the query is evaluated. Fuhr Average Error(%) 5 and Rolleke [12] define a probabilistic relational alge- 0 bra that generalizes the standard relational algebra for Q7 Q8 QQ tuples with probabilistic events. Zimanyi [38] formalize Queries probabilistic databases by means of logic theories based on a probabilistic first-order language. In knowledge rep- Fig. 15 Errors on Unsafe Queries resentation, Halpern et al. [10,2] have shown the use of possible worlds semantics to assign degrees of beliefs to least unsafe plan (using min-cut, Sec. 7). The graphs statements based of the probabilities in the knowledge show that the plan chosen by the optimizer was better, or base. Note that intensional semantics are impractical to significantly better than a naive one. Still, from two data use when the number of sources of uncertainties is very points it is hard to judge the improvement over a naive large, which is the case with approximate queries where plan. To see a third data point we wrote a new unsafe every tuple can be viewed as an independent source of query, QQ, where the relation lineitem is joined with uncertainty. Our work, on the other hand, gives a char- orders and suppliers. Here the fanout is larger, and acterization of queries where intensional semantics can the difference between the naive plan and the optimal be replaced by the cheaper extensional semantics. break is more pronounced. There is also work on supporting probabilities in other models of databases. Ng and Subrahmaniam [23] extend deductive databases with probabilities and give fixed poi- nt semantics to logic programs annotated with probabil- 12 Related Work ities, but they use absolute ignorance to combine event probabilities. An alternate model for uncertainty is con- There are various probabilistic systems for relation data- sidered by Cheng et al.[7] that is more suitable for sensor bases that have been proposed in the literature and they databases. They consider attributes (which are typically can primarily be classified into two classes: extensional sensor readings) whose values is given by a probability and intensional. The extensional systems [5,4,8,19] are distribution function and show how simple queries can very efficient when they work, but they have to make be efficiently evaluated over such databases. Probabilis- simplifying assumptions or impose some restrictions to tic models have also been considered for XML data un- get around the problem of high complexity. For instance, der independence [24], under arbitrary distributions [17] Cavallo and Pittarelli [5] start by assuming that tuples and with interval probabilities [16]. There is also work in the same relations represent disjoint events. Barbara on probabilistic object bases [9] and probabilistic logics et. al. [4] generalize Cavallo and Pittarelli’s model, where for schema mappings [25]. tuples are independent and attributes may be inaccurate There are also several non-probabilistic approaches to (leading to disjoint events). However, their system has a imprecise queries. Keyword searches in databases are dis- requirement that every relation must have a set of deter- cussed in [15,6,14]. Fagin [11] gives an algorithm to rank ministic attributes forming the key of that relation. Dey objects based on its scores from multiple sources: this and Sarkar [8] improve upon this model allowing arbi- applies only to a single table. The VAGUE system [20] trary keys, but allow only those projections that contain supports queries with vague predicates, but the query the key. Thus, none of these systems can correctly han- semantics are ad hoc, and apply only to a limited SQL dle arbitrary conjunctive queries. The Probview system fragments. Chaudhuri et al. [1] consider ranking query [19] takes a different approach: it does not assume in- results automatically: this also applies to a single table. dependence while combining probabilities, but requires Theobald and Weikum [34] describe a query language for strategies from users to combine them. Also, it works XML that supports approximate matches with relevance with interval probabilities instead of point probabilities. ranking based on ontologies and semantic similarity. The intensional systems [29,31,32,30,12,38] manip- ulate symbolic events rather than raw probabilities, and are based on the possible worlds semantics. Originally put forward by Kripke for modal logics, possible worlds 13 Conclusions and Future Work semantics is commonly used in AI for representing knowl- edge with uncertainties. Detailed discussions on exten- In this paper, we considered the problem of evaluat- sional and intensional systems can be found in the book ing queries over probabilistic databases according to the by Pearl [26]. In context of relational databases, inten- possible worlds semantics.. We showed that by choosing 22 Nilesh Dalvi, Dan Suciu suitable execution plans for queries, extensional seman- 14. Guo, L., Shao, F., Botev, C., Shanmugasundaram, J.: tics can be used to evaluate a certain class of queries. Xrank: Ranked keyword search over xml documents. In: We further showed that this class is precisely the class of SIGMOD, pp. 16–27 (2003) 15. Hristidis, V., Papakonstantinou, Y.: Discover: Keyword queries that have polynomial time data complexity. Our search in relational databases. In: Proc. 28th Int. Conf. theoretical results capture the fundamental properties of Very Large Data Bases, VLDB (2002) query complexity on probabilistic databases, and lead to 16. Hung, E., Getoor, L., Subrahmanian, V.S.: Probabilistic efficient evaluation techniques. We showed how this ap- interval xml. In: ICDE (2003) 17. Hung, E., Getoor, L., Subrahmanian, V.S.: Pxml: A prob- proach can be used to evaluate arbitrarily complex SQL abilistic semistructured data model and algebra. In: queries with uncertain predicates. ICDE (2003) There are several problems that emerge from this 18. Karp, R., Luby, M.: Monte-carlo algorithms for enumer- work and remain open. Given any conjunctive query that ation and reliability problems. In: STOC (1983) 19. Lakshmanan, L.V.S., Leone, N., Ross, R., Subrahmanian, is allowed to have self joins, can we decide if its data com- V.S.: Probview: a flexible probabilistic database system. plexity is polynomial time? Is there still a dichotomy of ACM Trans. Database Syst. 22(3), 419–469 (1997) queries into PTIME and #P-complete classes when self 20. Motro, A.: Vague: a user interface to relational databases joins are allowed? What is the complexity of query eval- that permits vague queries. ACM Trans. Inf. Syst. 6(3), 187–214 (1988) uation with aggregates like sum, count, min and max 21. Movie database: http://kdd.ics.uci.edu/database- and with having clauses? Apart from these questions, s/movies/movies.html there are engineering issues that need to be resolved. 22. Navarro, G.: A guided tour to approximate string match- We need to examine the implications for a relational en- ing. ACM Computing Surveys 33(1), 31–88 (2001) gine: what functionality does a relational engine need to 23. Ng, R.T., Subrahmanian, V.S.: Probabilistic logic pro- gramming. Information and Computation 101(2), 150– provide for an efficient implementation of probabilistic 201 (1992) databases? Another interesting problem is to develop al- 24. Nierman, A., Jagadish, H.V.: ProTDB: Probabilistic data gorithms for top-K answers to the probabilistic queries. in XML. In: VLDB (2002) 25. Nottelmann, H., Fuhr, N.: Combining DAML+OIL, XSLT and probabilistic logics for uncertain schema map- pings in MIND. In: ECDL (2003) 26. Pearl, J.: Probabilistic reasoning in intelligent systems: References networks of plausible inference. Morgan Kaufmann Pub- lishers Inc., San Francisco, CA, USA (1988) 1. Agrawal, S., Chaudhuri, S., Das, G., Gionis, A.: Au- 27. Provan, J.S., Ball, M.O.: The complexity of counting cuts tomated ranking of database query results. In: CIDR and of computing the probability that a graph is con- (2003) nected. SIAM J. Comput. 12(4), 777–788 (1983) 2. Bacchus, F., Grove, A.J., Halpern, J.Y., Koller, D.: From 28. Ross, R., Subrahmanian, V., Grant, J.: Aggregate op- statistical knowledge bases to degrees of belief. Artificial erators in probabilistic databases. Journal of the ACM Intelligence 87(1-2), 75–143 (1996) 52(1), 54–101 (2005) 3. Baeza-Yates, R., Ribeiro-Neto, B.: Modern Information 29. Sadri, F.: Reliability of answers to queries in relational Retrieval. Addison-Wesley (1999) databases. TKDE 3(2), 245–251 (1991) 4. Barbar´a, D., Garcia-Molina, H., Porter, D.: The man- 30. Sadri, F.: Aggregate operations in the information source agement of probabilistic data. IEEE Trans. Knowl. Data tracking method. Theor. Comput. Sci. 133(2), 421–442 Eng. 4(5), 487–502 (1992) (1994) 5. Cavallo, R., Pittarelli, M.: The theory of probabilistic 31. Sadri, F.: Information source tracking method: Efficiency databases. In: VLDB, pp. 71–81 (1987) issues. TKDE 7(6), 947–954 (1995) 6. Chaudhuri, S., Das, G., Narasayya, V.: Dbexplorer: A 32. Sadri, F.: Integrity constraints in the information source system for keyword search over relational databases. In: tracking method. IEEE Transactions on Knowledge and Proceedings of the 18th Int. Conf. on Data Engineering, Data Engineering 7(1), 106–119 (1995) San Jose, USA (2002) 33. Stoer, M., Wagner, F.: A simple min cut algorithm. 7. Cheng, R., Kalashnikov, D.V., Prabhakar, S.: Evaluating Algorithms–ESA ’94 pp. 141–147 (1994) probabilistic queries over imprecise data. In: SIGMOD, 34. Theobald, A., Weikum, G.: The xxl search engine: ranked pp. 551–562 (2003) retrieval of xml data using indexes and ontologies. In: 8. Dey, D., Sarkar, S.: A probabilistic relational model and SIGMOD, pp. 615–615 (2002) algebra. ACM Trans. Database Syst. 21(3), 339–369 35. Ullman, J.D., Widom, J.: First Course in Database Sys- (1996) tems, 2nd ed. Prentice Hall (1997) 9. Eiter, T., Lu, J.J., Lukasiewicz, T., Subrahmanian, V.S.: 36. Valiant, L.: The complexity of enumeration and reliabil- Probabilistic object bases. ACM Trans. Database Syst. ity problems. SIAM J. Comput. 8, 410–421 (1979) 26(3), 264–312 (2001) 37. Wordnet 2.0: A lexical database for the english language: 10. Fagin, R., Halpern, J.Y.: Reasoning about knowledge and http://www.cogsci.princeton.edu/ wn/ (2003) probability. In: Theoretical Aspects of Reasoning about 38. Zimanyi, E.: Query evaluation in probabilistic databases. Knowledge, pp. 277–293. San Francisco (1988) Theoretical Computer Science 171(1-2), 179–219 (1997) 39. Zobel, J., Dart, P.W.: Phonetic string matching: Lessons 11. Fagin, R., Lotem, A., Naor, M.: Optimal aggregation al- from information retrieval. In: Research and Develop- gorithms for middleware. In: PODS, pp. 102–113 (2001) ment in Information Retrieval, pp. 166–172 (1996) 12. Fuhr, N., Rolleke, T.: A probabilistic relational algebra for the integration of information retrieval and database systems. ACM Trans. Inf. Syst. 15(1), 32–66 (1997) 13. Gradel, E., Gurevich, Y., Hirch, C.: The complexity of query reliability. In: PODS, pp. 227–234 (1998)