has to choose. Important questions are: which relations should be dened intensionally,

Transcription

1 Automated Design of Deductive Databases (Extended abstract) Hendrik Blockeel and Luc De Raedt Department of Computer Science, Katholieke Universiteit Leuven Celestijnenlaan 200A B-3001 Heverlee, Belgium Keywords: Deductive Databases, Inductive Logic Programming, Articial Intelligence 1 Introduction As computational logic is a very powerful representation mechanism, there are often many dierent ways of designing a deductive database, among which the designer has to choose. Important questions are: which relations should be dened intensionally, how should this be done, and which integrity constraints should be added? Using Inductive Logic Programming (ILP), it is possible to induce logical clauses that hold in an example database instance. These clauses can be considered good candidates for use in the design of the database. This way, part of the design of a database can be automated. In this paper, we present an algorithm for doing this. 2 Deductive Database Design In deductive databases (see [Gallaire et al., 1984] for an introduction), relations can be dened extensionally (as a set of facts) or intensionally (as a set of logical clauses, from which each fact in the relation is derivable). Furthermore, a set of integrity constraints can be specied, also in the form of logical clauses. These constraints have to be true in every instance of the database. Deductive databases oer the database designer a lot of exibility: there are many ways of designing a database. With this exibility inevitably comes the problem of choosing the best design, amongst the many possibilities. In this section, we discuss some of the issues. 2.1 Intensional and extensional denitions A rst question is which relations should be dened intensionally, and which should be dened extensionally. For instance, in a database with relations male/1, female/1, parent/2, father/2 and mother/2, the designer can choose between dening parent extensionally, and mother and father as female, respectively male parent; or dening mother and father extensionally, and parent intensionally as the disjunction of the other two. Both designs have advantages and disadvantages (storage space, rule complexity, : : : ), which have to be weighed against each other. 1

2 2.2 Building intensional denitions Apart from deciding which relations should be dened intensionally, there is also the problem of deciding how they should be dened. One can prefer the least complex denition, or the most \natural" one, or use some other criterion. For instance, in a database that contains information about a graph, the path relation can be dened in the following ways: path(x,y) :- arc(x,y). base clause path(x,y) :- arc(x,z), path(z,y). recursive clause 1 path(x,y) :- path(x,z), arc(z,y). recursive clause 2 path(x,y) :- path(x,z), path(z,y). recursive clause 3 The rst denition will usually be preferred, because it also works if a Prologlike evaluation mechanism is used, while the other recursive rules only work with bottom-up evaluation. 2.3 Adding integrity constraints In addition to denitions of relations, a deductive database can also contain integrity constraints. Many constraints become redundant by using good intensional denitions, but some relationships between relations cannot be expressed by means of intensional denitions. For instance, in the typical family database, the constraint male(x); female(x) must be satised for every X. The constraint male(x) father(x) is redundant if father is dened using male and parent (if we make the closed world assumption, i.e. the denition of father is considered to be complete), but not if father is dened extensionally. So, an extra criterion for choosing intensional denitions may be the number of integrity constraints that become redundant with this rule. 3 Inducing Logical Clauses From Data Using Inductive Logic Programming (ILP) [Muggleton and De Raedt, 1994; Lavrac and Dzeroski, 1994], it is possible to analyse a set of data and discover regularities holding on the data, which are written in clausal form. If the set of data is an (purely extensional) instance of a database, then the clauses that are found can be used to nd intensional denitions and integrity constraints for the database. For our application, we have used the ILP system Claudien[De Raedt and Bruynooghe, 1993; Van Laer et al., 1994]. This system takes as input a database D (which can contain intensional as well as extensional denitions), a background knowledge B and a language bias L. It then induces clauses that are true in the least Herbrand model of D[B and that belong to L. In our application, D contains only extensional denitions, and B is empty. L has to be chosen according to which kind of clauses the user is interested in (e.g. it is possible to specify L in such a way that only functional dependencies are found). We have used a very general language, so that any integrity constraint that can be written as a logical clause in which only the database relations occur, can be induced. 4 Automated Database Design As it is possible to automatically induce valid clauses from a purely extensional database instance, it would be interesting to have an algorithm that, based on this set of clauses, proposes a good design for the database. We will now present such an algorithm. The following steps can be distinguished: 2

3 1. run Claudien to discover clauses 2. build intensional denitions for relations 3. add a set of constraints The rst step is trivial, as all the work is done by the Claudien system. The other steps will now be explained in more detail. 4.1 Finding intensional denitions First of all, it is checked which relations can at all be dened intensionally. For each relation, the subset containing all denite clauses with that predicate in the head is selected from the set of clauses returned by Claudien. If there are facts that can't be derived using all the clauses in the set, the relation can't be dened intensionally. We call the set of relations that can't be dened intensionally E. In the family example, the relations male and female belong to E, as a clause such as male(x) :- father(x,y) doesn't completely dene the relation male (not every man is a father), and there are no other relations from which male might be derived. The relations that are not in E can be dened intensionally. However, some of them can only be dened intensionally if certain other relations are dened extensionally. In the aforementioned example, parent can be dened intensionally i mother and father are dened extensionally, and vice versa. If we know that certain relations will have to be dened extensionally, then it is possible to nd a set of relations that will certainly be dened intensionally, irrespectively of what is done with the other relations. We will call this set I. It is easy to see that every relation that can be dened using only relations in E [ I is in I itself. Finally, the set of relations that are not in I or E will be called M. We then have a partition of the set of relations into three parts: relations that will certainly be dened extensionally (E), relations that will certainly be dened intensionally (I), and relations for which we don't know yet whether they will be dened intensionally or extensionally (M). To decide which relations in M will be dened intensionally, and what the intensional denitions will look like, the compaction of the database is used as a criterion. When a large set of facts is replaced by a set of clauses, the size of the database is reduced (as a few clauses usually suce to replace a set of facts, no matter how large it is). An intensional denition is considered a good one if it is simple (i.e. contains few clauses, and few literals) and replaces many facts. The algorithm that nds intensional denitions is shown in gure 1. For every relation in I [ M, it tries to nd the best intensional denition. The relation where the greatest compaction is achieved is then chosen. For this relation, the extensional denition is replaced by the intensional denition. Then for the relations in M the best denitions are recomputed (as the old denitions may have become invalid). This procedure is repeated until no more relations can be dened intensionally. The best intensional denition of a predicate is computed using a hill climbing procedure. Clauses are added one by one to the intensional denition (the clause that is added is always the one that makes the largest number of facts redundant), until all facts for this relation are implied. 4.2 Adding integrity constraints It is clear that before adding integrity constraints, those constraints that are already redundant because of the intensional denitions should be removed. As intensional denitions are supposed to be complete, we should use completion semantics to test this redundancy. For instance, with the intensional denition of parent: 3

4 compute E, M, I repeat for each relation p in I [ M : Compute the best intensional denition for p, if it exists call the relation where the greatest compaction is achieved, p best dene p best intensionally and remove its extensional denition until no more relations can be dened intensionally Compute the best intensional denition for p: (let R be the set of all clauses returned by Claudien and R p the set of all denite clauses in R with p in the head) D p := while D p is not complete choose a rule R from R p that leads to the greatest compaction for p add R to D p return D p Figure 1: The main algorithm parent(x,y) :- father(x,y). parent(x,y) :- mother(x,y). we know that the following constraints are always satised: parent(x; Y ) father(x; Y ) parent(x; Y ) mother(x; Y ) father(x; Y ) _ mother(x; Y ) parent(x; Y ) Therefore, every constraint that follows from this theory is redundant and can be removed. This includes the third constraint itself; there is no explicit representation of this constraint in the database. From the other constraints, a minimal set should be derived such that all the constraints in the original set are implied by this minimal set. The easiest way to construct such a set is by starting with the whole set and removing those constraints that are redundant. This, however, can lead to a set that is larger than necessary, as the removal of one constraint may preclude the removal of n other constraints, and vice versa. In such a case, it is of course better to keep the 1 constraint and remove the n others. This implies that the order in which the constraints are removed is important. A good order can not easily be chosen, however. Our current implementation solves this problem by using a hill climbing approach. For each constraint it is checked how many other constraints are made redundant when it is added to the current database. The constraint that makes the most other constraints redundant is eectively added. This is repeated until all constraints are implied. 4.3 Example We have performed some experiments on a small family database containing extensional denitions for father/2, mother/2, parent/2, parents/3, male/1 and female/1 (all together, 47 facts). It is clear that much redundancy exists within these relations. Allowing a maximum of three literals per clause, Claudien found 286 clauses. Using this set of clauses, our system proposed the following denitions: 4

5 parent(a,b) :- father(a,b). parent(a,b) :- mother(a,b). father(a,b) :- parents(b,a,c). mother(a,b) :- parents(b,c,a). % male, female, parents: extensional and 14 constraints, which assure that everyone is either male or female, mothers are female and fathers male, no-one can be a parent of his/her own parents, if X and Y have one parent in common, they have the same parents, children of the same parent can't be each others parents, father and mother can't have the same parents, and so on. One constraint, stating that the parent of a father does not have parents, is clearly due to overtting. 5 Conclusion With the help of ILP techniques, it is possible to partially automate the design of a deductive database. We have presented an algorithm that, given a set of clauses, nds intensional denitions and integrity constraints for the database. Experiments show that, if the sample database is suciently representative, this usually leads to a good design. Our criteria for choosing \good" intensional denitions are still rather simple; for instance, the time complexity of a denition is not taken into account. Also, several heuristics and search strategies can be experimented with, for nding intensional denitions as well as for minimizing the number of integrity constraints. And nally, it may be possible to netune Claudien for this task, so that it nds better (more relevant) clauses instead of generating a large set of clauses from which the design algorithm chooses the interesting ones. Acknowledgements This research is nanced with a grant from the Flemish Institute for the Advancement of Scientic-Technological Research in the Industry (IWT). Luc De Raedt is supported by the Belgian National Fund for Scientic Research. The authors would like to thank Wim Van Laer for proof-reading this paper. References [De Raedt and Bruynooghe, 1993] L. De Raedt and M. Bruynooghe. A theory of clausal discovery. In Proceedings of the 13th International Joint Conference on Articial Intelligence, pages 1058{1063. Morgan Kaufmann, [Gallaire et al., 1984] H. Gallaire, J. Minker, and J.M. Nicolas. Logic and databases: a deductive approach. ACM Computing Surveys, 16:153{185, [Lavrac and Dzeroski, 1994] N. Lavrac and S. Dzeroski. Inductive Logic Programming: Techniques and Applications. Ellis Horwood, [Muggleton and De Raedt, 1994] S. Muggleton and L. De Raedt. Inductive logic programming : Theory and methods. Journal of Logic Programming, 19,20:629{ 679, [Van Laer et al., 1994] W. Van Laer, L. Dehaspe, and L. De Raedt. Applications of a logical discovery engine. In Proceedings of the AAAI Workshop on Knowledge Discovery in Databases, pages 263{274,