ODIn/paper-BagRelationalPDBsAreHard
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Abstract pass

Browse source
This commit is contained in:
Oliver Kennedy 2020-12-15 10:52:58 -05:00
parent 4d04f1f3c5
commit 3c37847847
Signed by: okennedy
GPG key ID: 3E5F9B3ABD3FDB60
1 changed files with 7 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

8
abstract.tex
View file

@ -1,6 +1,12 @@
%root: main.tex
\begin{abstract}
The problem of computing the marginal probability of a tuple in the result of a query over a probabilistic databases (PDBs) can be reduced to calculating the probability of the \emph{lineage formula} of the result which is a Boolean formula whose variables represent the existence of tuples in the database. Under bag semantics, lineage formulas have to be replaced with provenance polynomials. For any given possible world, the polynomial of a result tuple evaluates to the multiplicity of the tuple in this world. In this work, we study the problem of calculating the expectation of such polynomials (a tuple's expected multiplicity) exactly and approximately. For tuple-independent databases (TIDBs), the expected multiplicity of a query result tuple can trivially be computed in linear time in the size of the tuple's provenance polynomial if the polynomial is encoded as a sum of products. However, using a reduction from the problem of counting k-matchings, we demonstrate that calculating the expectation for factorized polynomials is \sharpwonehard. More importantly, the problem stays hard even for polynomials generated by conjunctive queries (CQs) if all input tuples have a fixed probability $p$ (where $p \neq 0$ and $p \neq 1$). We then proceed to study polynomials of result tuples of union of conjunctive queries (UCQs) over TIDBs and for a non-trivial subclass of block-independent databases (BIDBs). We develop an algorithm that computes a $1 \pm \epsilon$-approximation of the expectation of such polynomials in linear time in the size of the polynomial.
The problem of computing the marginal probability of a tuple in the result of a query over set-probabilistic databases (PDBs) can be reduced to calculating the probability of the \emph{lineage formula} of the result, a Boolean formula over random variables representing the existence of tuples in the database's possible worlds.
The analog for bag semantics is a natural number-valued polynomial over random variables that evaluates to the multiplicity of the tuple in each world.
In this work, we study the problem of calculating the expectation of such polynomials (a tuple's expected multiplicity) exactly and approximately.
For tuple-independent databases (TIDBs), the expected multiplicity of a query result tuple can trivially be computed in linear time in the size of the tuple's lineage if this polynomial is encoded as a sum of products.
However, using a reduction from the problem of counting k-matchings, we demonstrate that calculating the expectation is \sharpwonehard when the polynomial is compressed, for example through factorization.
The problem stays hard even for polynomials generated by conjunctive queries (CQs) if all input tuples have a fixed probability $p$ (where $p \neq 0$ and $p \neq 1$).
We then proceed to study polynomials of result tuples of union of conjunctive queries (UCQs) over TIDBs and for a non-trivial subclass of block-independent databases (BIDBs). We develop an algorithm that computes a $1 \pm \epsilon$-approximation of the expectation of such polynomials in linear time in the size of the polynomial.
% \AH{High-level intuition}
% \BG{Most people think that computing expected multiplicity of an output tuple in a probabilistic database (PDB) is easy. Due to the fact that most modern implementations of PDBs represent tuple lineage in their expanded form, it has to be the case that such a computation is linear in the size of the lineage. This follows since, when we have an uncompressed lineage, linearity allows for expectation to be pushed through the sum.}
% \AH{Low-level why-would-an-expert-read-this}