Building Relational Circuits
Abstract
We review two algorithms which allow to build a factorized representation of the answers set of join queries. In a nutshell, the representation builds a circuit representing the answers set of a join query by starting from atomic relations and iteratively combine them by either constructing the Cartesian product or the disjoint union of previously computed relations. The first one can be seen as the trace of the celebrated Yannakakis algorithm, building the answer set from the inputs to the output of the circuit while the second adopts a top-down approach which can be seen as a generalization of the exhaustive DPLL algorithm, originally designed to solve the #SAT problem.
Keywords and phrases:
Conjunctive queries, factorized databases, knowledge compilationCategory:
Invited Talk2012 ACM Subject Classification:
Information systems Relational database modelFunding:
This work was supported by KCODA project, ANR-20-CE48-0004.Editors:
Balder ten Cate and Maurice FunkSeries and Publisher:
Leibniz International Proceedings in Informatics, Schloss Dagstuhl – Leibniz-Zentrum für Informatik
1 Introduction
From the seminal paper by Codd [19], it has been quite clear that organizing data as relations is a powerful abstraction, leading to a clear and intuitive separation of the data itself, its structure and how it can be queried. In a way, a query can be seen as a succinct way of specifying a relation. Yet, this succinctness comes at the price of making the relation harder to manipulate and most of the time, one ends up materializing it, which can be costly [18], before using the results. A notorious result by Yannkakis identified a class of queries for which this materialization was not necessary to decide whether the query has at least one answer, namely, the class of acyclic queries [50] (called acyclic scheme in the original paper), a large body of work has focused on finding other tractable tasks that can be efficiently solved on acyclic join queries, beyond simply deciding whether it has at least one answer. For example, it has been observed that one can efficiently enumerate the answers of an acyclic join query [7], compute their number [44], aggregates the answer over different semirings [1, 31] etc. Following the line of research on factorized databases [42, 43, 40] having its root in the field of knowledge compilation [23, 40] which focuses on efficient representations of knowledge bases, we argue in this paper that this tractability can be seen as the fact that the answer sets of acyclic queries can be efficiently represented in a factorized, yet tractable data structure, namely, a relational circuit.
This paper contains notes related to my invited ICDT lecture. It aims at giving an introduction to relational circuits (see Section 3.1), how to use them (see Section 3.2) and how to construct them (see Section 4), either by adapting Yannakakis algorithm (see Section 4.1) or by using an algorithm originally designed for solving #SAT (see Section 4.2). We then explore the consequences of these constructions regarding several known tractability results from the literature(see Section 5). It does not aim at giving full formalization and voluntarily stays high level. We also tried to give many pointers to related literature but many other relevant and interesting results and research are still unfortunately missing.
2 Preliminaries
Tuples and relations.
We let to be the set of mapping from a set of attributes to a set called the domain. An element is called a tuple over attributes and domain . For , we let to be the attributes of . Given a set of attributes , we let to be the tuple defined over attributes and defined as for every . If are two tuples such that where , we say that and are consistent and write . In this case, we let to be the tuple defined over as if and otherwise. We write when to insist on the fact that they have disjoint attributes. We write tuple between angle brackets and with a list of couples of the form where is an attribute and a domain value, meaning that the tuple assigns value to . For example is the tuple over attributes such that and . We denote by the empty tuple (that is, the only tuple whose attributes are , and the identity of ).
A relation on attributes and domain is a set of tuples. We extend notations of tuples to relations: we define to be the attributes of , the projection of over attributes to be the relation over defined as . The natural join of two relations and is defined as . Again, if , we write instead of . In this case, we say that is the Cartesian product of and . Observe in this case that . Given two relations over attributes , we write for the union of relations and , seen as sets of tuples. Now when and are not defined over the same attributes, we define the extended union of and over domain , denoted by , to be . We simply write when is clear from context. Given a relation over attributes and a tuple over attributes , we denote by the relation over attributes containing the tuple such that . Despite the notation being non standard, we think it is natural: the “” symbol here is to be interpreted as the inverse of the Cartesian product .
Join and conjunctive queries.
In this paper, we focus on join queries (also known as full conjunctive queries or quantifier-free conjunctive queries). A join query is traditionally defined only over relation names, and the content of each relation, the data, is defined outside of the query itself, in a database. To ease notations and concepts, we slightly deviate from this point of view in this paper and we define a join query as a finite list of relations, called the atoms of , over a finite domain and finite sets of attributes .
The variables of a join query are defined as . A join query implicitly represents a relation over attributes and domain which is defined as performing the natural join of each relation it contains. Formally, we define the answers set of as
We consider two notions of sizes for join queries, inherited from the original separation between the logical layer and the data layer. The query size of , denoted by is defined as . The query size does not take into account the content of the relation, but only their structure. The data size of , denoted by , is defined as . The data size is sensible to the number of tuples in each relation, while the query size only depends on the number of relations and their arities.
A conjunctive query is defined as a pair where is a join query and is a subset of attributes of called the free variables of . We often simply write it as to make the free variables explicit. The answers set is defined as , that is, . We extend the query size and data size to conjunctive queries, where is defined as and as .
Model of computation.
We use the word-RAM model of computation where registers contain bits, where is the size of the input and arithmetic operations over two registers can be done in constant time. Observe that in this model, we can perform arithmetic operations and comparisons over integers bounded by in polynomial time in (actually, in time ) [29]. In the case of join queries over variable and domain , we will often use numbers of size up to (for example, when counting tuples), which means that this number can be manipulated in time . Using radix sort, we can also sort such values or tuples in time [20, Section 6.3]. In other words, we can sort the tuples of a relation in time linear in .
3 Relational Circuits
In this section, we introduce a succinct way of describing relations using circuits whose syntactic properties make them suitable for further analysis.
3.1 Main definitions
From a general point of view, a relational circuit is a circuit whose inputs are labeled by atomic relations and gates are functions building new relations from its input relations. In this setting, we can see a join query as a flat relational circuit, with relations being inputs of a single -labeled gate. We show how one can use factorization and syntactic restrictions to design representations that are both succinct and tractable.
Join circuits.
We start with a very general definition that serves as a starting point before restricting it into more interesting classes of circuits. A on attributes and domain is defined as a labeled direct acyclic multi-graph (that is, there may be more than one edge between two vertices of the graph) with one distinguished vertex called the output of and denoted by . The vertices of the underlying DAG of are called gates. If two gates are connected by a directed edge , we say that is an input of and that is an output of . The gates of are labeled as follows:
-
Every gate without input (that is, without any incoming edge) is called an input of the circuit and is labeled by either , or for some attribute and domain value . If is labeled by or , we say that is a constant input.
-
Every other gate (that is, every gate with at least one input) is labeled by either or .
The attributes of a gate of are defined to be the set of attributes appearing in at least one input of the subcircuit rooted at . In other words, if is labeled by or , if is labeled by for some , and if are the inputs of .
Each gate computes a relation defined inductively as:
-
If is an input then: either it is labeled by and , or by and , or by then .
-
If has input and is labeled by then .
-
If has input and is labeled by then .
The relation computed by is defined as where . If is not made explicit, we simply let .
The size of a is defined as the number of edges of its underlying graph. Sometimes, the size of circuits is defined as the number of gates, but this definition is often less natural. Indeed, an algorithm visiting every edge of the circuit is linear in the size of the input but no necessarely linear in the number of gates in the circuit since there may be edges in a circuit with nodes.
The family of s is not interesting from a complexity point of view as they are more general than join queries. We now restrict s in order to find representations of relations that are more tractable than join queries.
Cartesian products.
The main syntactic restriction that we impose on relational circuits is the following: in a , we say that a -gate is a Cartesian product gate, or -gate for short, if for every distinct input of . Observe that in this case, if are the inputs of , then . A is a where every -gate is a -gate. Obviously, given a , we can check whether it is a in time by computing for every .
Union gates.
Another useful restriction regarding relational circuits is to restrict how -gates are operating. Indeed, -gates are cumbsersome to use because they force us to keep track of the attributes of each gate and to be explicit about the domain. We hence define a as a such that for every -gate with input , we have . In this case, one can easily check that .
Disjoint unions.
While s allow for enumeration, one can observe that they do not allow to efficiently compute statistics on . Indeed, one can easily see that it is #P-hard to compute when is a given on the input, by a direct reduction to the problem #DNF, though, if one is interested in approximation, this problem admits an FPRAS [36]. The hardness of counting mainly stems from the fact that unions of relations in the circuit may overlap, which makes the cardinality of the union hard to estimate.
To avoid it, we need an extra property: given a , we say that a -gate with inputs is deterministic111We keep here the usual terminology from knowledge compilation [22] and from seminal work on factorized databases [43], though the naming is slightly misleading, as it is not deterministic in the usual sense. “Unambiguous” would be a better term. if for every , we have . In this case, observe that is a disjoint union, denoted by . A deterministic -gate will be denoted by . As for union, we also have to denote the union of relations on different attributes but having no common tuple on their shared attributes. A is then a where every -gate is deterministic.
Given a , we can now compute with arithmetic operations using a straightforward dynamic programming, see Section 3.2 for details.
Decision-gates.
One can see that checking whether a given -gate is deterministic is not easy. Indeed, it is a semantic property on the relation computed by each gate and not an easy-to-check syntactic property. In practice, we know that a -gate is deterministic because the algorithm which built the circuit formally guarantees that this is the case. While in some cases, determinism may depend on complex reasons, in every algorithm we will describe in this document, determinism is ensured because some attribute has a different value in each subcircuit. To model this very specific case, we introduce the notion of decision-gate: a decision-gate is a gate labeled by a variable and each incoming edge of is labeled by a value . Moreover, if are the incoming edges of respectively labeled by , then for every , and . We define . Clearly, by definition, we could rewrite every decision-gate with incoming edges using only -gates and -gates222Observe that for this, we need the condition that . and at most edges, hence decision-gates is only a useful syntactic sugar. A is a circuit whose every gate are either Cartesian products or decision-gates.
Ordered -circuitdec.
Different paths of decision-gates in a may use different order. For example, we could have a path testing variable then then and another path testing then then . That said, the algorithm we give in Section 4 will always test variables in the same order, and we will actually use this fact to recover some results on direct access. Let be an order on . We say that a on attributes respects order if for every decision-gate labeled by and an input of , we have .
We observe here that some -gates are not decision-gates. For example, let be gates such that and , then a -gate with input is deterministic because only contains tuples with an even number of ones and with an odd number of ones but it cannot be seen as a decision-gate since both and can take values and in and in . In this case, determinism is witnessed by a parity argument. Actually, this idea forms the base of the argument to show that are exponentially more succinct than [9].
Example 1.
We illustrate the previous definitions on Figure 1. We give two circuits computing the same relation . Observe that the output of the first circuit is a -gate which is not a -gate because the relation computed by its two input gates both contain the tuple . The second circuit only has decision-gates.
Constants elimination and smoothing.
While we can be flexible on the syntax of relational circuits, useless gates may induce complexity. In particular, constant gates (-gates and -gates) may induce hidden costs. We observe that we can remove them in the circuit with a linear time procedure as follows: we remove every input of -gates labeled by and every input of -gate labeled by without changing the relation they compute. We also replace a -gates with a -labeled input by a -gate and a -gate with a -labeled input by a -gate. Each change reduces the size of the circuit by at least one, hence applying these transformations iteratively finishes and returns a circuit without constant gates.
We also observe here that s may also be transformed into in time : we can indeed precompute for every gate of and, for each -gate of with input , we can add a -gate between and a circuit computing where and plug into instead of . This operation is known as smoothing in knowledge compilation [23] and can sometimes be costly if the number of variables is high. One can avoid it in some cases [46, 4]. In this work, the algorithm we will present naturally build so we will not focus much on nor .
3.2 Tractable tasks
In this section, we show how we can exploit properties of relational circuits to get insights on the relation they compute. This approach is akin to the one used in knowledge compilation [23]: for each class of circuits, we try to understand the tractable tasks and their complexity.
Enumeration.
Given a on attributes and domain , one of the first tasks one can do is to list every tuple of . To measure the complexity of such algorithm, it is customary to analyze the time spent between two outputs of the algorithm, which we call the delay. Sometimes, we need to precompute some values on the circuit before starting. This time will be accounted for as preprocessing time.
It is easy to see that we can find a tuple in in time by inductively constructing for each , a tuple in for every gate in the circuit, or report that . But we can even output every tuple in with delay as follows. The main idea is to observe that giving a tuple over and , we can find in time the subset such that is the set of domain values for which can be extended to a full tuple of . This can be done by plugging every variable in to their value (ie, replace input by if and by otherwise) and every input in by . It gives a on variable whose computed relation is exactly . By propagating constants in the circuit in time , it simplifies to a circuit where can be read directly as the remaining input of the form . This is enough to implement a flashlight search to enumerate by constructing each tuple one variable at a time, without never exploring partial tuples that cannot be extended to full solutions: we start by computing every possible values that can take in , then pick and find every value of can take when is set to etc. This method ensures that every partial tuple we built can be extended to a full tuple in . Once such a tuple is found, we backtrack to the last variable for which it remains at least one unexplored value. Between two outputs, we do at most oracle calls to the previously describe procedure, hence a delay of . This method can even be extended to the case where one wants to output the tuples by increasing weights, see [3] for details.
The delay of this algorithm may be too high to recover the existing enumeration bounds from the database literature, as we would like to have a complexity that only depends on the number of variables of . We show that in the case of , we get better bounds. Indeed, to enumerate when is a -gate with inputs , one only needs to successively enumerate for every . The delay is thus where is the delay to enumerate . To enumerate where is a -gate with input , we enumerate one tuple from , then every tuple from . The delay between two outputs is since it is the time needed to find the first tuple. If we again ensure that each -gate has no trivial input, we can show that the delay is where is the depth of the circuit and the number of variables. Observe that in the worst-case, the depth could be of the order of . We can however always rewrite into a circuit with depth at most by ensuring the every -gate has no other -gate as input. Doing it naively may however increase the size of the circuit quadratically. Amarilli, Bourhis, Jachiet and Mengel proposed a work-around in [4] to quickly find the gates that could be reached from a -gate in linear time allowing for enumeration with delay after linear preprocessing.
Observe that in the particular case of , the previous algorithm directly gives delay as long as for every -gate with input , we have , which can be ensured with linear time preprocessing by simply removing constants in the circuit.
Counting.
Given a , we can now compute with arithmetic operations using a straightforward dynamic programming. For each gate , we compute inductively: if is an input, then if is a -gate and otherwise. If is a -gate with input , then . If is a -gate with input then . Hence, we can compute with arithmetic operations. For every , does not exceed , where is the domain of and its attributes. Hence, each number can be stored in at most registers in a RAM machine, and each arithmetic operation can be performed in time , resulting in a final complexity of . For , we have a similar result but we need to precompute for every gate . If is a -gate, we have where .
Sampling.
Interestingly the previous algorithm can be leveraged into a uniform sampling algorithm. Assume has been precomputed for every gate of . If one wants to draw a tuple uniformly, we can do this simple procedure:
-
If is a -gate, then fail (this case should not happen unless ).
-
If is a -gate or a gate labeled by , then return the only tuple in .
-
If is a -gate with input , then draw with probability and uniformly sample in .
-
If is a -gate with input then return where is sampled uniformly from .
In the case of , without further assumptions, we can show that this procedure runs in time where is the depth of the circuit, that is, the longest path from the output to an input of . If is a and if we have removed trivial inputs from -gate (that is, for every -gate , ), then we can show that this procedure runs in time .
Direct Access.
We can go one step further and compute a numbering on so that we can efficiently access , as if it was a table. This kind of algorithm have been called “direct access algorithm” [8, 16, 25, 17, 14]. We define an order on by inductively defining, for every gate of , a one-to-one mapping where . We call an index on . We first assume for every gate , its input are listed in some arbitrary order. We now define the index functions inductively.
-
If is an input, not labeled by , we define , for the only assignment in .
-
If is a -gate with input , let . We define where for every and is the only value in such that . In other words, we order by first taking every tuple from , then etc.
-
If is a -gate with input , let . Let and . We by for every . We define
that is is the rank of in ordered lexicographically.
Interestingly , we can revert this indexing structure. Indeed, given , we can efficiently compute , that is, the tuple such that . Indeed, assume we have precomputed, for every -gate with input and , the value and stored them in an ordered table . We also precompute for every -gate .
First assume is a -gate and let . To find the tuple of , we need look for the smallest such that which can be done via a binary search with comparisons, each comparison being on integers smaller than . Then we inductively output the tuple of .
Now assume is a -gate with input and let . We are looking for such that
where has been precomputed already. Observe that since every other term of the sum can be divided by . Similarly, where is the quotient of the division of by . We similarly have . Hence we can compute inductively as .
Hence, after a precomputation step of , we can, on input , fail if , and otherwise, output with comparisons or arithmetic operations on integers smaller than , where is the depth of . Hence, in total time .
This direct access algorithm has interesting consequences. It allows to enumerate in a uniformly chosen order, or, equivalently, perform sampling without replacement: we sample or randomly enumerate values in , and output the corresponding tuple in . This can be done efficiently by adapting the Fisher-Yates shuffle algorithm in a lazy way, as in [17].
We again get better complexity bounds for s. Indeed, in this case, we can bound the arity of -gates (in the form of decision-gates) by the size of the domain and we can show that we can recover the element of with arithmetic operations because each recursive call is done on gates having strictly less attributes, hence a total time of . More interestingly, if the circuit respects order , then we can actually solve the direct access problem for the lexicographical order induced by on with a slightly more involved access technique that can still be executed with arithmetic operations and comparisons. Indeed, in this case, given a tuple over attributes with , we can find how many tuple from are smaller than in the lexicographical order. We can use it to build the element of by discovering it one variable at a time, using counting queries to find the value of the next variable with a binary search, see [14] for details.
We conclude this section by summarizing the results we will use the most in the context of databases:
Theorem 2.
Given an ordered on attributes and domain respecting order , we can:
-
Enumerate with preprocessing and delay ,
-
Compute in time ,
-
Uniformly sample after preprocessing ,
-
Find the element of according to the lexicographical order induced by in time after preprocessing.
3.3 Previous work
Factorized databases.
Relational circuits originated under the name factorized databases in the seminal paper by Olteanu and Závodný [42]. In this document, we decided to use the name relational circuits to describe the object used to represent the relation, in contrast to the term factorized databases which, in our opinion, describe a set of techniques covering, in particular, the notion of relational circuit. In this work, the class of s appears under the name factorized representation with definitions, or d-representations, while have been introduced as deterministic d-representations. In [43], the definition explicitly enforces unions to be defined over gates having the same attributes. We decided to deviate from the original terminology because we think that is more natural than d-representation and it allows to be more precise on the syntactic restriction we want to enforce on the circuit, where the term d-representation is too general.
We want to clearly distinguished in this paper between the syntactic properties of relational circuits and the algorithm constructing the circuits. This is why, in this work, we decided to separate the notion of relational circuits that simply represent relations, sometimes with specific semantics or syntactic restrictions, and how such relational circuits are produced.
NNFs and Relational circuits.
Syntactically restricted Boolean circuits have been used for representing Boolean functions since the 80s, at first through the lens of ordered binary decision diagrams [13] (which can be seen as -circuits) and then later generalized to restricted Boolean circuits under the name Decomposable Negation Normal Form (DNNF) [23, 21, 22] with decomposable -gates, corresponding to -gates, and deterministic -gates, corresponding to -gates on domain . The similarity of knowledge compilation and factorized databases has been observed in [40] but the connections between classes of circuit is not covered. We provide a comparison in Table 1 using the circuit notations from the previous sections and the main classes studied in knowledge compilation. Previous work have been using DNNF in many areas of computer for enumeration by encoding database queries answers into DNNF [4, 3], probabilistic databases by representing the Boolean provenance a query with DNNFs [41, 10, 9, 48], for computing Shapley scores [6, 11], see [5] for a more detailed introduction on the applications of circuits in databases.
We do not include definitions of the Boolean counterpart of relational circuits and refer to [23]. that one can also recover them by simply taking the corresponding class of relational circuit and specializing them over domain : indeed each line illustrates the correspondence between a Boolean circuit and relational circuits as follows: when considering circuits on the right column on domain , it corresponds exactly to the Boolean circuit on the left.
The correspondence actually works both ways: for non-binary domain , we can encode with bitstrings over bits by representing with the binary representation of over bits. Hence, given a over attributes and domain , we can convert it into an NNF over variables by replacing every input by a circuit over variables accepting only the assignment encoding in binary. This can easily be done by -circuit of size . It can be encoded in any NNF subclass from Table 1, showing that every relation circuit on attributes and domain from the right column can be naturally casted into an NNF from the left column with an additional increase of at most increase.
We conclude this section by observing that most relational circuits, with relevant syntactic restrictions, can be understood as automaton on finite language. For example, ordered -circuits correspond to finite state automaton without loop, hence on a finite language, while Context-Free grammar could be associated to restricted where -gates are only allowed to split variables according to some total order. Other syntactic restriction of not presented in this paper can also be shown to correspond to tree automaton. These connections have been studied in [33, 2].
| KC | Relational circuits |
|---|---|
| NNF circuit | if smooth, -circuit otherwise. |
| DNNF circuit | if smooth, otherwise. |
| d-DNNF circuit | if smooth, otherwise. |
| dec-DNNF circuit | if smooth, otherwise. |
| FBDD | -circuit if smooth, -circuit otherwise. |
4 Algorithms for Building Circuits
Now that we have introduce relational circuits as a handy way of representing relations, we turn our attention on two main algorithms to build them. The first one can be seen as revisiting the celebrated Yannakakis Algorithm [50] while the second one is a generalization, to the database setting, of the exhaustive DPLL algorithm [45] which has originally been devised for solving #SAT, but which is known to implicitly build decision-DNNF, the Boolean counterpart of [30] and which is used in practice by many knowledge compilers such as d4 [35] or (a modification of) SharpSAT-TD [34, 32].
4.1 Bottom-up compilation and Yannakakis Algorithm
Yannakakis algorithm has originally been devised to check for consistency of acyclic database schemes in time linear in the size of the data [50], which is the same as checking whether an acyclic join query has at least one answer. It has quickly been observed that the same idea allows to also efficiently find every answer of the acyclic queries [7] or count them [44]. In this section, we explain how it could also be used as a way of constructing an ordered computing of size linear in for any acyclic join query .
A join query is acyclic if there exists a tree , called a join tree, such that:
-
The vertices of are in one to one correspondence with , and for a node of , we let be the relation labeling it.
-
For every variable , is connected in (we call this property the connectedness of ).
It is known that we can decide whether is acyclic and if so, construct a join tree of in linear time in [47]. Yannakakis algorithm exploits the properties of join tree to propagate just the right information along it, in order to decide whether is empty or not. In the rest of this section, we generalize this algorithm into a circuit construction establishing:
Theorem 3.
Let be an acyclic join query. We can construct a computing of size in time . Moreover, respects an order on .
Circuit construction.
Let be a join query and a join tree for . Assume is rooted at an arbitrary node, and let be a node of . We let be the subtree of rooted in and to be the join query whose atoms are exactly the atoms appearing in . The crux of Yannakakis algorithm is the following observation: if are two children of , then . Indeed, every path from to must go through . Hence if appears on both side, by connectedness, it must be in too.
Let be the children of in . An answer of have the following shape:
-
Projected over , they must be equal to some tuple in .
-
Projected over , they must be an answer of that extends .
In other words, an answer of is of the form where where . In other words, we have established:
| (1) |
If we further develop each term of the previous Cartesian product and if we let , we have: µ
| (2) |
In the original Yannakakis algorithm, these relations are used to dynamically maintain the following information: does have an answer extending ? Indeed, Equation 1 tells us that has an answer extending if and only if for every , has an answer extending , which by Equation 2 is equivalent to the fact that has an answer extending for some with . In Yannakakis algorithm, the latter has been precomputed and hence, we can quickly decide in time whether has an answer extending for every . When the algorithm reaches the root of , and we can decide whether has an answer.
But Equations 1 and 2 can also be seen as a way to build for every from the relations for every , by using decision-gates and one Cartesian product gate. The circuit is build in a bottom-up fashion from the leaves of to its root. We build a circuit having the following property: for each node of and , there is a gate computing . If is a leaf of , only has one atom . Hence, for every , is the relation containing only the empty tuple. Hence, we define as a -gate.
Now if has children , we let . We first create gates to compute . By Equation 2, we can build a tree of decision-gates on attributes , rooted in a gate whose leaves correspond to assignment for every such that . Each leaf is connected to the gate that has been inductively constructed and computes, by induction, . By Equation 2, computes . Now, we simply define as a Cartesian product gate , and by Equation 2, it computes .
To be efficient, observe that if and , then , hence we can use for both, without duplicating the gates.
At the root of , we have for every , a gate computing . We hence add a tree of decision-gates rooted in a gate whose leaves correspond to for every and plug it to directly. Gate computes and we choose it to be the output of .
Example 4.
We illustrate the previous algorithm on the example given on Figure 2. In this example, we assume we have performed the construction in the subtrees rooted in and respectively. Hence, we have constructed gates and corresponding to every tuple of and respectively. The only common attribute between and is which has been grayed in the figure. Hence, the first step of the construction starts by grouping every tuple in having the same projection on and build a decision tree for them. In the example, it means that we group and together and hence built a decision tree for the relation . This decision tree is depicted on the bottom left corner of Figure 2. Observe its leaves are connected to and respectively. The same is done for and but we connect the leaves to and . Observe that we built twice the same decision tree because the tuples of where projected on are the same as the tuples of where projected on . Yet, we do not identify the subtree because below they may have used in different ways.
We proceed similarly with . Observe that in this case, despite having we have distinct values of in , we only construct decision-trees for three of them because the case has no possible extension in .
Now, for each , we introduce a Cartesian product gate and connect it to the corresponding decision-gates below. For example, for , we introduce the -gate whose inputs correspond to the roots of the previously constructed decision-tree for tuples of and where . Observe in this case that and have the same inputs, this is where the factorization happens.
Observe that the case is interesting because it both has corresponding tuples in and but not in . In this case, we know that because . Hence, we set to be a -gate and the root of the join tree corresponding to is dangling in the circuit and will never be used. This is a typical case of the over computation performed by many dynamic programming algorithm: we precompute some values that may have relevance locally but not later in the circuit. The same happens to the tuple where . Neither nor has such tuples, hence, we have a dangling tuple again (observe that in this case, we do not even construct the decision-tree). Observe that we can always postprocess the circuit in to remove dangling gates and -input propagating constants and removing gates without outputs.
Finally, if is also the root of the join tree, then it remains to project out the attribute and in the circuit, which is done in the last layer of the circuit.
Properties of the circuit.
A careful analysis reveals that the number of gates in this circuit is bounded by and can be built in time .
Moreover, if we are consistent in the ordering used to built every tree of decision-gates, we can see that the resulting circuit is ordered. It can actually be made to respect any completion to a total order of the following partial order: given , let be the last node of such that . That is, no ancestor of contain . Then for , we write if and only if is below in . It defines a partial order on that intuitively corresponds to ordering the variables from their order of appearance from the root of to its leaves. Let be an order on completing into a full order. Then, in the construction previously described, we can force the circuit to respect order . For example, in Example 4, the circuit respects order , but also .
Beyond acyclic join queries.
If a join query is not acyclic, we can still use Yannakakis algorithm but with worse guarantees. We first have to generalize the notion of join tree. A tree decomposition of is a tree such that every node of is labeled with and such that for every atom of , there exists such that and such that for every , the set is connected in . Now let be the join query whose atoms are for every atom of such that and let . We define to be the join query whose atom are . By definition, is a join tree of , hence is acyclic and has the same answers as and we can use Yannakakis algorithm to build a computing and of size . We can always normalize to have at most nodes where , hence . Hence, if we know that and if we can compute in time , then we can construct a computing in time .
The challenge is now to find a relevant upper bound on . The first idea is to bound the number of atoms covering . Indeed, assume contains atoms whose union of variables is equal to , then and we can compute the join of these atoms and filter the tuples not in in time . The number of atoms of needed to cover is called the cover number and the hypertree width of with respect to [27] is defined as . From what precedes, we can hence construct a computing in time .
We can actually relax the covering notion into a fractional version of it, offering better size guarantees and, using appropriate join algorithms[38, 49, 37, 39, 15], the corresponding time complexity, leading to the more general notion of fractional hypertree width of with respect to [28] allowing to construct a computing in time .
We now explain how to handle a conjunctive query . After having compiled a for , we can project every attributes that are not in . This is possible in any by replacing, for every , every input labeled by with . However, doing so comes at the price of loosing determinism, that is, the resulting circuit is now a , which does not support model counting nor would it give constant delay enumeration. This is not surprising, as it is known that enumerating or finding the number of answers of acyclic conjunctive queries may not be doable with linear preprocessing [7, 24]. The increased complexity from join to conjunctive queries mostly comes from how the free variables interact with the other. We have a similar phenomenon with ordered : indeed, assume that appears at the end of the order, then projecting them preserves determinism, which leads to a smaller ordered representing , hence the tractability results of transfer to .
From the point of view of tree decompositions, this assumption on the order respected by the circuit translates informally into the fact that, in the tree decomposition, the “free variables should be above the projected variables”. This can be formalized as the notion of free-connex tree decomposition [7], where there is a connected subset of nodes of whose variables are exactly the free-variables. Given a free-connex tree decomposition of fractional hypertree width of a conjunctive query , the previous paragraph shows that we can construct a computing in time . Another way of seeing this is that from a free-connex tree decomposition, we can construct an acyclic join query with , by proceeding similarly as before. The free-connexity ensures that we are able to project out variables in .
4.2 Top-down compilation and Exhaustive DPLL
We now explain another algorithm that can be used to construct an ordered computing . It can be applied to any query but if has fractional hypertree width , then using the right variable ordering will construct the circuit in time .
The algorithm is based on a recursive procedure which picks a variable , add a decision-gate on , and for every value , recursively computes . To avoid blow-up, we add two ingredients: (i) caching, where at each recursive call with parameters , we detect whether there already exists a gate in the circuit computing , (ii) connected component analysis, where we detect if , in which case, we create a Cartesian product gate and recursively construct circuits for .
To be efficient, we need to perform caching in a syntactic way only. We formalize it as follows: let be a tuple of . If there exists an atom of such that , then no answer of extends . In this case, we say that is inconsistent with . Otherwise, if , then is the same as where has been removed from . We hence denote by where is the join query obtained by removing every atom in such that and . For example, if and , then because has been removed from and is no longer a variable in the remaining query. Because of this, instead of writing as a couple, we simply write . Observe that if , then and . This kind of equivalence can be check purely syntactically, hence in time . For this reason, once we have build a gate in the circuit computing , we cache with key . Hence, if at some point, another recursive call on happens and , then we can directly pull from the cache instead of redoing the same computation.
Connected components analysis is also a purely syntactical analysis of the query. Given a join query and a tuple over variable , we consider the graph whose vertices are the atoms of and there is an edge between two atoms if they share a variable not in (that is, not yet assigned by ). If this graph has more than connected components , it splits into and into such that , and .
We now describe the Exhaustive DPLL algorithm. It takes as input a join query , a tuple and an order on and returns a gate in an ordered respecting such that computes .
-
1.
If is inconsistent with , then return a -gate. It is correct since .
-
2.
If assigns every variable of , then return a -gate. It is correct since .
-
3.
If is mapped in the cache to a gate , then return . It is correct since by induction, the cache is correct and hence computes .
-
4.
Otherwise, split into connected components :
-
(a)
If : create a -gate and for , let which recursively constructs a gate computing . Add as an input of . Now computes which is what desired. The algorithm then updates the cache to map with and returns .
-
(b)
If : let be the smallest variable in according to that is not set by . We add a new decision-gate on variable . For every , we let where to recursively construct a gate computing and add an edge labeled by between and . By definition, computes . The algorithm updates the cache to map with and returns .
-
(a)
On input , Exhaustive DPLL clearly outputs an ordered respecting and computing .
Example 5.
We now give an example333An interactive version of this example can be found at https://florent.capelli.me/algorithms/dpll/ with others.. We consider with given on Figure 3. With , produces the circuit given on Figure 3. Each gate is labeled by the number of recursive call which produced it. For example, is produced by the first recursive call on input . Observe that has two connected components: the first one being and the second one being . Hence a -gate is created and linked to the result of the first recursive call producing circuits rooted in and .
The edge between and is also interesting because it corresponds to a cache hit. Indeed, the recursive call producing is done with parameters . Since there is exactly one connected component, a decision-gate on is created and a recursive call with input is made, leading to the creation of the circuit rooted at . Then, another recursive call is made with input which is the recursive call which produced since it had parameters . Hence, is directly upon reading the cache after call with parameter .
| 0 | 1 | |
| 1 | 0 | |
| 1 | 1 |
| 0 | 1 | |
| 1 | 0 | |
| 1 | 1 |
| 0 | 0 | |
| 1 | 1 |
The size of the circuit produced by mostly depends on . Interestingly, if is acyclic with a join tree and is chosen as for Yannakakis, that is, by ordering the variables from the root of to its leaves, then produces a circuit of size , matching the guarantee of the top-down construction of Yannakakis. This is because once every variable in the root of have been set, it splits into as many connected component as has children in . Moreover, if is a child of in and if two assignments of the variables in have the same value over the variables in node , then a cache hit will occur. In a way, we can see Exhaustive DPLL as a mean of constructing a similar circuit as Yannakakis but from the output to the inputs of the circuit, while Yannakakis approach goes from the inputs to the output.
If is extracted from a tree decomposition of whose fractional hypertree width is , then produces a circuit of size , see [14] for details, as the analysis is a bit convoluted. Observe that for running , we do not need to know the tree decomposition, this comes handy only in the complexity analysis. In a way, is the decomposition. We can hence use to measure how good it is with respect to . This actually corresponds to characterization of fractional hypertree width in terms of elimination orders, see [26, 1, 12] for details.
The version of Exhaustive DPLL described above has however an annoying limitation: when branching on a variable , we brute force over every possible value . Some of these calls will directly return . This leads to a factor of in the time needed to construct the circuit, that is, we construct the circuit in time for an order induced by a decomposition of width . There are two ways of shaving this factor. We can either use a more involved algorithm to explore only relevant values for variable , adapting ideas from worst-case optimal join, such that leapfrog join [49]. Another simpler way is to use the binarization technique described in Section 3.3 to reduce the domain to a domain of size while having variables, hence leading to a construction in time as in [14]. We observe however that the binarization technique is also an implicit way of reducing the number of candidates which can also be used in the design of worst-case optimal join algorithm [15].
Finally, we observe that Exhaustive DPLL is flexible: we can handle more than just join queries, as long as we have a recursive way of representing a query whose answer are and a caching mechanism. In particular, we have used it in [14] to compute ordered representing the answer set of join queries with negated atoms. In this setting, we want to solve a join query but remove answers that satisfy some relations, that we see as negated atoms. It is straightforward to adapt exhaustive DPLL to this kind of queries: we can simply define as before, but also removing negated atoms from for which cannot be extended to a tuple in .
5 Fine-grained consequences
We conclude this paper by spelling out the consequences of the tractability of ordered from Theorem 2 and the circuit construction from Section 4. In this section, we let be a conjunctive query and a free-connex tree decomposition of of fractional hypertree width . We recover the constant delay enumeration of [7] after preprocessing by constructing the circuit for during the preprocessing phase and then enumerating the tuple with delay , which is constant in data complexity. We similarly recover (an extension of) the result from [44] by simply returning after having constructed : the construction of takes time while computing takes . The direct access algorithm from [16, 12] is also recovered directly since after building the circuit, the access time is , hence, in data complexity, it corresponds to from earlier result. DPLL allows to generalize to join queries with negations, see [14].
Finally, we observe that we could have mentioned that the counting algorithm outline in Section 3.2 could be generalized where inputs are labeled with semiring elements and then aggregated over it, allowing to solve FAQ or AJAR types of queries over the circuit with complexity similar to [1, 31], as long as we remain compatible with its underlying order.
References
- [1] Mahmoud Abo Khamis, Hung Q Ngo, and Atri Rudra. Faq: questions asked frequently. In Proceedings of the 35th ACM SIGMOD-SIGACT-SIGAI Symposium on Principles of Database Systems, pages 13–28, 2016. doi:10.1145/2902251.2902280.
- [2] Antoine Amarilli, Marcelo Arenas, YooJung Choi, Mikaël Monet, Guy Van den Broeck, and Benjie Wang. A circus of circuits: Connections between decision diagrams, circuits, and automata. CoRR, abs/2404.09674, 2024. doi:10.48550/arXiv.2404.09674.
- [3] Antoine Amarilli, Pierre Bourhis, Florent Capelli, and Mikaël Monet. Ranked enumeration for MSO on trees via knowledge compilation. In Graham Cormode and Michael Shekelyan, editors, 27th International Conference on Database Theory, ICDT 2024, Paestum, Italy, March 25-28, 2024, volume 290 of LIPIcs, pages 25:1–25:18. Schloss Dagstuhl – Leibniz-Zentrum für Informatik, 2024. doi:10.4230/LIPIcs.ICDT.2024.25.
- [4] Antoine Amarilli, Pierre Bourhis, Louis Jachiet, and Stefan Mengel. A circuit-based approach to efficient enumeration. In Ioannis Chatzigiannakis, Piotr Indyk, Fabian Kuhn, and Anca Muscholl, editors, 44th International Colloquium on Automata, Languages, and Programming, ICALP 2017, Warsaw, Poland, July 10-14, 2017, volume 80 of LIPIcs, pages 111:1–111:15. Schloss Dagstuhl – Leibniz-Zentrum für Informatik, 2017. doi:10.4230/LIPIcs.ICALP.2017.111.
- [5] Antoine Amarilli and Florent Capelli. Tractable circuits in database theory. SIGMOD Rec., 53(2):6–20, 2024. doi:10.1145/3685980.3685982.
- [6] Marcelo Arenas, Pablo Barceló, Leopoldo E. Bertossi, and Mikaël Monet. On the complexity of shap-score-based explanations: Tractability via knowledge compilation and non-approximability results. J. Mach. Learn. Res., 24:63:1–63:58, 2023. URL: https://jmlr.org/papers/v24/21-0389.html.
- [7] Guillaume Bagan, Arnaud Durand, and Etienne Grandjean. On acyclic conjunctive queries and constant delay enumeration. In Jacques Duparc and Thomas A. Henzinger, editors, Computer Science Logic, 21st International Workshop, CSL 2007, 16th Annual Conference of the EACSL, Lausanne, Switzerland, September 11-15, 2007, Proceedings, volume 4646 of Lecture Notes in Computer Science, pages 208–222. Springer, 2007. doi:10.1007/978-3-540-74915-8_18.
- [8] Guillaume Bagan, Arnaud Durand, Etienne Grandjean, and Frédéric Olive. Computing the jth solution of a first-order query. RAIRO-Theoretical Informatics and Applications, 42(1):147–164, 2008. doi:10.1051/ITA:2007046.
- [9] Paul Beame, Jerry Li, Sudeepa Roy, and Dan Suciu. Lower bounds for exact model counting and applications in probabilistic databases. In Proceedings of the Twenty-Ninth Conference on Uncertainty in Artificial Intelligence, 2013.
- [10] Paul Beame, Jerry Li, Sudeepa Roy, and Dan Suciu. Counting of query expressions: Limitations of propositional methods. In Proc. 17th International Conference on Database Theory (ICDT), pages 177–188, 2014. doi:10.5441/002/ICDT.2014.20.
- [11] Leopoldo E. Bertossi, Benny Kimelfeld, Ester Livshits, and Mikaël Monet. The shapley value in database management. SIGMOD Rec., 52(2):6–17, 2023. doi:10.1145/3615952.3615954.
- [12] Karl Bringmann, Nofar Carmeli, and Stefan Mengel. Tight fine-grained bounds for direct access on join queries. In Proceedings of the 41st ACM SIGMOD-SIGACT-SIGAI Symposium on Principles of Database Systems, pages 427–436, 2022. doi:10.1145/3517804.3526234.
- [13] Randal E Bryant. Graph-based algorithms for boolean function manipulation. Computers, IEEE Transactions on, 100(8):677–691, 1986. doi:10.1109/TC.1986.1676819.
- [14] Florent Capelli and Oliver Irwin. Direct access for conjunctive queries with negations. In Graham Cormode and Michael Shekelyan, editors, 27th International Conference on Database Theory, ICDT 2024, Paestum, Italy, March 25-28, 2024, volume 290 of LIPIcs, pages 13:1–13:20. Schloss Dagstuhl – Leibniz-Zentrum für Informatik, 2024. doi:10.4230/LIPIcs.ICDT.2024.13.
- [15] Florent Capelli, Oliver Irwin, and Sylvain Salvati. A simple algorithm for worst case optimal join and sampling. In Sudeepa Roy and Ahmet Kara, editors, 28th International Conference on Database Theory, ICDT 2025, Barcelona, Spain, March 25-28, 2025, volume 328 of LIPIcs, pages 23:1–23:19. Schloss Dagstuhl – Leibniz-Zentrum für Informatik, 2025. doi:10.4230/LIPIcs.ICDT.2025.23.
- [16] Nofar Carmeli, Nikolaos Tziavelis, Wolfgang Gatterbauer, Benny Kimelfeld, and Mirek Riedewald. Tractable orders for direct access to ranked answers of conjunctive queries. ACM Transactions on Database Systems, January 2023. doi:10.1145/3578517.
- [17] Nofar Carmeli, Shai Zeevi, Christoph Berkholz, Benny Kimelfeld, and Nicole Schweikardt. Answering (unions of) conjunctive queries using random access and random-order enumeration. In Proceedings of the 39th ACM SIGMOD-SIGACT-SIGAI Symposium on Principles of Database Systems, pages 393–409, 2020. doi:10.1145/3375395.3387662.
- [18] Ashok K Chandra and Philip M Merlin. Optimal implementation of conjunctive queries in relational data bases. In Proceedings of the ninth annual ACM symposium on Theory of computing, pages 77–90, 1977. doi:10.1145/800105.803397.
- [19] Edgar F Codd. A relational model of data for large shared data banks. Communications of the ACM, 13(6):377–387, 1970. doi:10.1145/362384.362685.
- [20] Thomas H Cormen, Charles E Leiserson, Ronald L Rivest, and Clifford Stein. Introduction to algorithms. MIT press, 2022.
- [21] A. Darwiche. Decomposable negation normal form. J. ACM, 48(4):608–647, 2001. doi:10.1145/502090.502091.
- [22] Adnan Darwiche. On the tractable counting of theory models and its application to truth maintenance and belief revision. Journal of Applied Non-Classical Logics, 11(1-2):11–34, 2001. doi:10.3166/JANCL.11.11-34.
- [23] Adnan Darwiche and Pierre Marquis. A Knowledge Compilation Map. Journal of Artificial Intelligence Research, 17:229–264, 2002. doi:10.1613/JAIR.989.
- [24] Arnaud Durand and Stefan Mengel. Structural tractability of counting of solutions to conjunctive queries. Theory Comput. Syst., 57(4):1202–1249, 2015. doi:10.1007/S00224-014-9543-Y.
- [25] Idan Eldar, Nofar Carmeli, and Benny Kimelfeld. Direct access for answers to conjunctive queries with aggregation. arXiv preprint arXiv:2303.05327, 2023. doi:10.48550/arXiv.2303.05327.
- [26] Johannes K Fichte, Markus Hecher, Neha Lodha, and Stefan Szeider. An smt approach to fractional hypertree width. In Principles and Practice of Constraint Programming: 24th International Conference, Lille, France, August 27-31, 2018, Proceedings 24, pages 109–127. Springer, 2018.
- [27] Georg Gottlob, Nicola Leone, and Francesco Scarcello. Hypertree decompositions and tractable queries. In Proceedings of the eighteenth ACM SIGMOD-SIGACT-SIGART symposium on Principles of database systems, pages 21–32. ACM, 1999. doi:10.1145/303976.303979.
- [28] Martin Grohe and Dániel Marx. Constraint solving via fractional edge covers. ACM Transactions on Algorithms (TALG), 11(1):4, 2014.
- [29] David Harvey and Joris Van Der Hoeven. Integer multiplication in time o(nlog,n). Annals of Mathematics, 193(2):563–617, 2021.
- [30] Jinbo Huang and Adnan Darwiche. DPLL with a trace: From SAT to knowledge compilation. In Proceedings of the Nineteenth International Joint Conference on Artificial Intelligence, pages 156–162, 2005. URL: http://ijcai.org/Proceedings/05/Papers/0876.pdf.
- [31] Manas R Joglekar, Rohan Puttagunta, and Christopher Ré. Ajar: Aggregations and joins over annotated relations. In Proceedings of the 35th ACM SIGMOD-SIGACT-SIGAI Symposium on Principles of Database Systems, pages 91–106, 2016. doi:10.1145/2902251.2902293.
- [32] Rafael Kiesel and Thomas Eiter. Knowledge compilation and more with sharpsat-td. In Pierre Marquis, Tran Cao Son, and Gabriele Kern-Isberner, editors, Proceedings of the 20th International Conference on Principles of Knowledge Representation and Reasoning, KR 2023, Rhodes, Greece, September 2-8, 2023, pages 406–416, 2023. doi:10.24963/KR.2023/40.
- [33] Benny Kimelfeld, Wim Martens, and Matthias Niewerth. A formal language perspective on factorized representations. In Sudeepa Roy and Ahmet Kara, editors, 28th International Conference on Database Theory, ICDT 2025, Barcelona, Spain, March 25-28, 2025, volume 328 of LIPIcs, pages 20:1–20:20. Schloss Dagstuhl – Leibniz-Zentrum für Informatik, 2025. doi:10.4230/LIPIcs.ICDT.2025.20.
- [34] Tuukka Korhonen and Matti Järvisalo. Integrating Tree Decompositions into Decision Heuristics of Propositional Model Counters. In Laurent D. Michel, editor, 27th International Conference on Principles and Practice of Constraint Programming (CP 2021), volume 210 of Leibniz International Proceedings in Informatics (LIPIcs), pages 8:1–8:11, Dagstuhl, Germany, 2021. Schloss Dagstuhl – Leibniz-Zentrum für Informatik. doi:10.4230/LIPIcs.CP.2021.8.
- [35] Jean-Marie Lagniez and Pierre Marquis. An improved decision-dnnf compiler. In Carles Sierra, editor, Proceedings of the Twenty-Sixth International Joint Conference on Artificial Intelligence, IJCAI 2017, Melbourne, Australia, August 19-25, 2017, pages 667–673. ijcai.org, 2017. doi:10.24963/IJCAI.2017/93.
- [36] Kuldeep S. Meel and Alexis de Colnet. #cfg and #dnnf admit FPRAS. CoRR, abs/2406.18224, 2024. doi:10.48550/arXiv.2406.18224.
- [37] Hung Q. Ngo. Worst-Case Optimal Join Algorithms: Techniques, Results, and Open Problems. In Proceedings of the 37th ACM SIGMOD-SIGACT-SIGAI Symposium on Principles of Database Systems, pages 111–124. ACM, 2018. doi:10.1145/3196959.3196990.
- [38] Hung Q. Ngo, Ely Porat, Christopher Ré, and Atri Rudra. Worst-case optimal join algorithms: [extended abstract]. In Michael Benedikt, Markus Krötzsch, and Maurizio Lenzerini, editors, Proceedings of the 31st ACM SIGMOD-SIGACT-SIGART Symposium on Principles of Database Systems, PODS 2012, Scottsdale, AZ, USA, May 20-24, 2012, pages 37–48. ACM, 2012. doi:10.1145/2213556.2213565.
- [39] Hung Q Ngo, Ely Porat, Christopher Ré, and Atri Rudra. Worst-case optimal join algorithms. Journal of the ACM (JACM), 65(3):1–40, 2018. doi:10.1145/3180143.
- [40] Dan Olteanu. Factorized databases: A knowledge compilation perspective. In Adnan Darwiche, editor, Beyond NP, Papers from the 2016 AAAI Workshop, Phoenix, Arizona, USA, February 12, 2016, volume WS-16-05 of AAAI Technical Report. AAAI Press, 2016. URL: http://www.aaai.org/ocs/index.php/WS/AAAIW16/paper/view/12638.
- [41] Dan Olteanu and Jiewen Huang. Using obdds for efficient query evaluation on probabilistic databases. In International Conference on Scalable Uncertainty Management, pages 326–340. Springer, 2008. doi:10.1007/978-3-540-87993-0_26.
- [42] Dan Olteanu and Jakub Zavodny. Factorised representations of query results: size bounds and readability. In Alin Deutsch, editor, 15th International Conference on Database Theory, ICDT ’12, Berlin, Germany, March 26-29, 2012, pages 285–298. ACM, 2012. doi:10.1145/2274576.2274607.
- [43] Dan Olteanu and Jakub Závodný. Size Bounds for Factorised Representations of Query Results. ACM Transactions on Database Systems, 40(1):1–44, March 2015. doi:10.1145/2656335.
- [44] Reinhard Pichler and Sebastian Skritek. Tractable counting of the answers to conjunctive queries. Journal of Computer and System Sciences, 79(6):984–1001, September 2013. doi:10.1016/J.JCSS.2013.01.012.
- [45] Tian Sang, Fahiem Bacchus, Paul Beame, Henry A Kautz, and Toniann Pitassi. Combining component caching and clause learning for effective model counting. Theory and Applications of Satisfiability Testing, 4:7th, 2004.
- [46] Andy Shih, Guy Van den Broeck, Paul Beame, and Antoine Amarilli. Smoothing structured decomposable circuits. In Hanna M. Wallach, Hugo Larochelle, Alina Beygelzimer, Florence d’Alché-Buc, Emily B. Fox, and Roman Garnett, editors, Advances in Neural Information Processing Systems 32: Annual Conference on Neural Information Processing Systems 2019, NeurIPS 2019, December 8-14, 2019, Vancouver, BC, Canada, pages 11412–11422, 2019. URL: https://proceedings.neurips.cc/paper/2019/hash/940392f5f32a7ade1cc201767cf83e31-Abstract.html.
- [47] Robert E. Tarjan and Mihalis Yannakakis. Simple linear-time algorithms to test chordality of graphs, test acyclicity of hypergraphs, and selectively reduce acyclic hypergraphs. SIAM J. Comput., 13(3):566–579, July 1984. doi:10.1137/0213035.
- [48] Timothy van Bremen and Kuldeep S Meel. Probabilistic query evaluation: The combined fpras landscape. In Proceedings of the 42nd ACM SIGMOD-SIGACT-SIGAI Symposium on Principles of Database Systems, pages 339–347, 2023. doi:10.1145/3584372.3588677.
- [49] Todd Veldhuizen. Triejoin: A Simple, Worst-Case Optimal Join Algorithm. Proceedings of the 17th International Conference on Database Theory (ICDT), Athens, Greece, 2014, 17(13):96–106, 2014. doi:10.5441/002/ICDT.2014.13.
- [50] Mihalis Yannakakis. Algorithms for Acyclic Database Schemes. In Proceedings of the Seventh International Conference on Very Large Data Bases - Volume 7, pages 82–94. VLDB Endowment, 1981.
