Paolo Atzeni (Ed.)
LOGIDATA+'. Deductive Databases with Complex Objects
Springer-Verlag Berlin Heidelberg NewYork London Paris Tokyo Hong Kong Barcelona
Budapest
Series Editors Gerhard Goos Universit~it Karlsruhe Postfach 69 80 Vincenz-Priessnitz-Straf3e 1 D-76131 Karlsruhe, FRG
Juris Hartmanis Cornell University Department of Computer Science 4130 Upson Hall Ithaca, NY 14853, USA
Volume Editor Paolo Atzeni Dipartimento di Informatica e Sistemistica Terza Universit?~ di Roma and Universit~ di Roma "La Sapienza" Via Salaria, 113, 1-00198 Rome, Italy
CR Subject Classification (1991): H.2.1, H.2.3
ISBN 3-540-56974-X Springer-Verlag Berlin Heidelberg New York ISBN 0-387-56974-X Springer-Verlag New York Berlin Heidelberg
This work is subject to copyright. All rights are reserved, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, re-use of illustrations, recitation, broadcasting, reproduction on microfilms or in any other way, and storage in data banks. Duplication of this publication or parts thereof is permitted only under the provisions of the German Copyright Law of September 9, 1965, in its current version, and permission for use must always be obtained from Springer-Verlag. Violations are liable for prosecution under the German Copyright Law. 9 Springer-Verlag Berlin Heidelberg 1993 Printed in Germany Typesetting: Camera ready by author 45/3140-543210 - Printed on acid-free paper
Preface
This book presents a collection of coordinated scientific papers describing the work conducted and the results achieved within the L O G I D A T A + project, a research action funded by C N R (Consiglio Nazionale delle Ricerche - - the Italian National Research Council), within "Progetto Finalizzato Sistemi Informatici e Calcolo Parallelo." The aim of the L O G I D A T A + project is the definition of advanced database systems that significantly extend the functionalities of the current systems, with specific reference to the application areas for which relational systems are not considered satisfactory. These new systems will allow the definition of d a t a with complex structures, the representation of semantic relationships between objects, and the use of powerful query and update languages. They will be based on a combination of techniques originating from relational databases and logic programming, with contributions from object-oriented programming. Attention will be devoted to the representation of isa-hierarchies and to taxonomic reasoning. The specific goal of the project is the definition, design, and prototype implementation of a database management system with complex structures and a class hierarchy, to be accessed through a rule-based language. The project is now at the conclusion of the first phase, with significant researcl~ work done on the definition of the features of the systems and their theoretical foundations. The second phase will be mainly concerned with the implementation of prototypes. This book presents a homogeneous, integrated view of the scientific results of the project, with respect to all the features of the system. The L O G I D A T A + group involves teams from the following institutions: - CNR, Centro per l'Interazione Operatore-Calcolatore, Bologna - CNR, Istituto di Analisi dei Sistemi ed Informatica, R o m a - CRAI, Rende (Cosenza) Politecnico di Milano, Dipartimento di Elettronica e Informazione Sintesi S.r.l., Modena - Systems & Management S.p.A., Torino - Universits dell'Aquila, Dipartimento di Matematica P u r a e Applicata Universits della Calabria, Cosenza, Dipartimento di Elettronica, Informatica e Sistemistica - Universits di Firenze, Dipartimento di Sistemi e Informatica Universits di Modena, Dipartimento di M a t e m a t i c a - Universits di R o m a La Sapienza, Dipartimento di Informatica e Sistemistica -
-
-
vI The book is organized in four parts. Part I contains two papers, the first giving an overview of the LOGIDATA+ project and the second presenting a general discussion on the combination of deductive and object-oriented features in the database field. Part II is concerned with the description of the LOGIDATA+ model and language: the first and second papers present the data model and the rule-based language, respectively; the third paper illustrates the concepts by means of the detailed description of an application. Parts III and IV report on research results about a number of issues that can lead to significant extensions of the LOGIDATA§ system. Each of them concentrates on some features of the model and language. Specifically, Part III contains results on problems related to structural issues (updates over classes, taxonomic reasoning, and integrity constraints in object-oriented databases) and Part IV deals with deductive issues, essentially extensions of logic programming. Finally, Part V presents the experimental results of the project, with the existing prototypes. I would like to thank all those who have made this book possible. Bruno Fadini, Director of "Progetto Finalizzato Sistemi Informatici e Calcolo Parallelo," and Domenico Sacc~, Coordinator of "Sottoprogetto 5: Sistemi evoluti per basi di dati," have encouraged the LOGIDATA+ action since its inception. The authors of all the papers deserve my gratitude for their timely cooperation in the preparation of the volume and for their help in the revision process. My graduate students Giovanni Barone, Luca Cabibbo, and Gianni Mecca helped in the reviewing process and in the organization of the material. Alfred Hofmann at Springer-Verlag was very efficient in the management of our project.
May 1993
Paolo Atzeni
Table o f C o n t e n t s
P a r t I: T h e F r a m e w o r k
LOGIDATA+: Overview Paolo A i z e n i . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
Bridging Objects with Logical Rules: Towards Object-Oriented Deductive Databases Stefano Ceri and Letizia Tanca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
P a r t II: T h e Model and the Language
The LOGIDATA+ Model Paolo A l z e n i , Filippo Cacace, Stefano Ceri, and Lelizia Tanca . . . . . . . . . . . .
20
The LOGIDATA+ Language and Semantics Paolo A t z e n i , Luca Cabibbo, Giansalvalore Mecca, and Letizia Tanca . . . . . 30
Travel Agency: A LOGIDATA+ Application Luca Cabibbo and Giansalvatore Mecca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
P a r t III: Complex Objects
Management of Extended Update Operations Luigi Palopoli and Riccardo Torlone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
Taxonomic Reasoning in LOGIDATA+ D o m e n i c o B e n e v e n l a n o , Sonia Bergamaschi, Claudio Sartori, Alessandro Artale, Francesca Cesarini, and G i o v a n n i Soda . . . . . . . . . . . . . . . .
79
Introducing Taxonomic Reasoning in LOGIDATA+ Alessandro Artale, Francesca Cesarini, and Giovanni Soda . . . . . . . . . . . . . . . .
85
Taxonomic Reasoning with Cycles in LOGIDATA+ D o m e n i c o B e n e v e n t a n o , Sonia Bergamaschi, and Claudio S a r t o r i . . . . . . . .
105
Modeling Semantic Integrity Constraints in Object-Oriented Database Schemas A n n a Formica and Michele M i s s i k o f f . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
129
VIII
Part IV: Deductive Databases
Evaluation of Negative Logic Programs Sergio Greco, Massimo Romeo, and Domenico Sacc~ . . . . . . . . . . . . . . . . . . . .
148
Effective Implementation of Negation in Database Logic Query Languages Nicola Leone, Massimo Romeo, Pasquale Rullo, and Domenico Saceh . . . . 159 Modules in Logic Programming: A Framework for Knowledge Management Annalina Fabrizio, Maurizio Capaccioli, and Sandra Valeri . . . . . . . . . . . . . .
176
Part V: P r o t o t y p e s
LOA: The LOGIDATA+ Object Algebra Umberto Nanni, Silvio Salza, and Mario Terranova . . . . . . . . . . . . . . . . . . . . . .
195
The LOGIDATA+ Prototype System Umberto Nanni, Silvio Salza, and Mario Terranova . . . . . . . . . . . . . . . . . . . . . .
211
MOOD*: An Architecture for Object-Oriented Access to a Relational Database Marco Lugli, Luca Nini, and Sr Ceri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
233
Prototypes in the LOGIDATA+ Project Alessandro Arlale, Jean-Pierre Ballerini, Sonia Bergamaschi, Filippo Cacace, Stefano Ceri, Francesca Cesarini, Anna Formica, Herman Lain, Sergio Greco, Giorgio Marrella, Michele Missikoff, Luigi Palopoli, Luigi Pichetli, Domenico Sacc~, Silvio Salza, Claudio Sartori, Giovanni Soda, Letizia Tanca, and Marco Toiali . . . . . . . . 252
LOGIDATA+: Overview* Paolo Atzeni Dipartimento di Informatica e Sistemistica, Universitk di Roma "La Sapienza," Via Salaria 113, 00198 Roma, Italy
A b s t r a c t . LOGIDATA+ is part of the subproject "Advanced Database Systems" of the project "Information Systems and Parallel Computation", of the Italian research council. The aim of LOGIDATA+ is the definition of advanced database systems, which significatively extend the functionalities of the current systems, with specific reference to the application areas for which relational systems are not considered satisfactory. These new systems will allow the definition of data with complex structures, the representation of semantic relationships between objects, and the use of powerful query and update languages. They will be based on the combination of techniques originating from relational databases and logic programming, with contributions from object-oriented programming. Attention will be devoted to the representation of isa-hierarchies and to taxonomic reasoning. The specific goal of LOGIDATA+ is the definition, design, and prototypal implementation of a database management system with a complex structure and a class hierarchy, to be accessed through a rule-based language. Extensions of the core are also considered, in various directions: management of various forms of negation, both in the body and in the head of the rules; management of updates, especially with respect to intensionally defined predicates or to rules; modularization; constraints; taxonomic reasoning.
1
Introduction
L O G I D A T A + is a research action aimed at the definition of advanced database systems, which significatively extend the functionalities of the current systems, with specific reference to the application areas for which relational systems are not considered satisfactory. These new systems will allow the definition of data with complex structures, the representation of semantic relationships between objects, and the use of powerful query and update languages. They will be based on the combination of techniques originating from relational databases and logic programming, with contributions from object-oriented programming. Attention will be devoted to the representation of isa-hierarchies and to taxonomic reasoning. The specific goal of L O G I D A T A + is the definition, design, and prototypal implementation of a database management system with a complex structure and a class hierarchy, to be accessed through a rule-based language. * Work supported by CNR, "Progetto Finalizzato Sistemi Informatici e Calcolo Parallelo." The author is now with Terza Universitk di Roma.
LOGIDATA§ is part of a larger national project, on Information Systems and Parallel Computation (officially, "Sistemi Informatici e Calcolo Parallelo, " abbreviated as SICP). More specifically, it is part of a subproject on Advanced Database Systems of the SICP Project. This paper gives a brief overview of the LOGIDATA§ action and of the framework in which it operates. First we describe the SICP Project (Section 2) and its subproject on databases (Section 3). Then we discuss the motivation and the goals of the LOGIDATA§ action, and finally we describe its organization and the way its results are descrbed in the subsequent papers of this book (Section 4).
2
The P r o j e c t "Sistemi Informatici e Calcolo Parallelo"
In the Italian system, a Progetto Finalizzato del CNR is "a set of research activities aimed at reaching goMs that have a significant social and economic interest at the national level, with the involvment of all the components of the scientific system of the country." A Progetto Finalizzato is funded by the national government and administered by Consiglio Nazionale delle Ricerche (CNR, the Italian research council). The Project Sistemi Informatici e Calcolo Parallelo (SICP) was approved by the government in 1987 together with other nine projects. Their general goal is to support the national industry in the development and acquisition of new technology, in order to increase its competitiveness on the international market and to reduce the need for technology import. They also involve the development of prototypes, the study and evaluation of existing system and the definition of proposals for the governmental acitivity in various fields. The total budget of the SICP Project (throughout the five-year length) is 63 billion Lire (about 40 million US dollar, at the current exchange rate). The project is organized in seven subprojetcs, over various areas of computer science and engineering, plus a support initiative for the coordination of laboratories: SP1 SP2 SP3 SP4 SP5 SP6 SP7 SP8
Scientific computation for large systems Dedicated processors Parallel architectures New generation languages Advanced database systems Methods and tools for system design Support systems for intellectual work Support initiative
The Director of the project is Bruno Fadini, Universit~ di Napoli "Federico II." The specific goals of each subproject include both research results that contribute to the advancement of knowledge in the field and more practical results, such as methodsl systems, and services. The activities have been divided in two phase: the first three-year period had mainly research goals with some experimental work whereas the final two year (just started) will mainly be devoted to the finalization of the results, with significant prototypes.
3
The Subproject "Advanced Database Systems"
The goals of the subproject are based on the observation that, although database systems have achieved significant technological and methodological advances in the last two decades, it can be claimed that current systems present various limitations. In fact, a new generation of database systems is under definition and development with the goal of expanding application domains and improving usability. Within this framework, the subproject has launched a research program based on the following issues: (1) intelligent databases; (2) logic query languages for databases; (3) management of multimedia data; (4) integration of heterogeneous databases; (5) tools and methodologies for the end user. Among the responses to the call for proposals, five self-contained research actions were selected, each of which refers to one or more of the above issues and involves teams from both academia and industry: DATABASE++ aims at defining and developing the most significant layers of an object-oriented database system where data model abstraction is integrated with programming language issues. LOGIDATA+ deals with the problem of enhancing database technology by means of the management of complex data items, the representation of semantic relationships among data, and the use of a powerful query and update language, based on a suitable extesion of logic programming. MULTIDATA has two main goals: (a) the definition of a conceptual model with object-oriented flavour forthe representation of multimedia data, and (b) the design and implementation of a multimedia database system for geographic information systems. MULTI+ is mainly concerned with integrating heterogeneous multimedia databases in a distributed context. FIRE aims at defining and developing a user-friendly, flexible interface to information retrieval systems. The coordinator of the Subproject "Advanced database systems" is Domenico Saccg, Univeritg della Calabria.
4
Motivation for the LOGIDATAq- Action
Relational database management systems are currently a "de facto" standard and there is a general agreement that they satisfy the needs of most business oriented applications. On the other hand, during the last few years the need for systems with the database capabilities (management of large sets of persistent data in a shared, reliable, efficient, and effective manner) has emerged in other application areas, such as computer-aided design, computer-aided software engineering, knowledge based, office, and multimedia systems. These areas have a number of common requirements, which are essentially not fulfilled by relational systems:
1. the involved data often have complex structures, which cannot be represented in a natural way in the relational model; 2. the semantics of the data and their mutual relationships are crucial, and need to be expressed in a more explicit way than just by means of values; 3. the operations require an expressive power that is not provided by the traditional languages for relational database systems. In response to each of these needs a research trend has been developed: 1. models that generalize the relational one have been defined, relaxing the first normal form constraint [9,7,12]: values need not be atomic - - they may sets or tuples or combination thereof; 2. models with richer semantics have been studied, based not only on values, but also on the notion of identity, which allows the representation of explicit relationships between objects, of isa hierarchies, and of object sharing; starting points for this trend have been the semantic models, originally developed to be used in the analysis and design phases of application development, and object-oriented languages [2,4,8,11,13]; 3. techniques for the efficient and effective coupling and integration of databases and logic programming languages have been studied, initially referring to the relational model and later to more general models [3,5,6,14,15]; The LOGIDATA+ Action will respond to these needs by means of a system whose model and language have the following features: - the data model is a compatible extension of the relational model, capable of handling complex structures; - the data model allows the representation of semantic relationships by means of object identifiers [10], is-a links, and data functions [1]. - the language is rule based, being an extension of logic programming languages.
5
Achievements
of the LOGIDATA%
Action
Three years after the beginning, the project is now at the conclusion of the first phase, with significant research work done on the definition of the features of the systems and their theoretical foundations. The second phase (two years) will be mainly concerned with the implementation of prototypes. The scientific activity of the project, reported in this book, has been organized along two main directions. The first direction had the goal of a definition of set of basic features, which could set the framework for subsequent research work and for experimental effort. It has included the specification of the data model and of the associated rule-based language, and the definition of a proposal for the architecture of a prototype. The model has been defined with a large variety of construct, in order provide a flexible framework for the definition and
experimentation (at least at the conceptual level) of different, and possibly independent features. In fact, the second direction has dealt with a number of issues arising in the LOGIDATA+ framework or in subsets thereof. Because of their inherent complexity (and because the second direction was started before the end of the first and so before the complete definition of the framework), some of the problems have been studied in more traditional contexts, such as logic programming (without complex structures) or complex-object models (without rule-based language). Both directions have involved some experimental activity, with the development of prototypes. The organization of this book partially reflects the organization of the project. Part II describes the model and language (in the papers by Atzeni et al.), including an extensive example (in the paper by Mecca nad Cabibbo). Parts III and IV concern the advanced issues. More specifically, the papers in Part III describes the results that are mainly related to structural issues: Palopoli and Torlone study the problem of updating a complex-object database; the three papers by Beneventano et al. and by Artale et al. discuss how the LOGIDATA+ model can be extended with taxonomic reasoning, an inference technique for reasoning about is-a relationships; Formica and Missikoff describe how integrity constraints can be handled in a complex-object database. Part IV deals with a number of logic programming issues that can be eventually integrated in the LOGIDATA+ framework: Greco et al. and Leone et al. study advanced forms of negation; Fabrizio et al. describe a proposal for knowledge modularization. Finally, Part V describes the experimental work conducted in both sections of the project. The two papers by Nanni, Salza, and Terranova describe an algebra to used at an intermediate level for the implementation of the LOGIDATA+ language and the general architecture of the prototype system. The paper by Lugli, Nini, and Ceri describes another implementation effort aimed at the contruction of C + + programs that access relational databases. The final paper, by Artale et al., coordinated by Palopoli, contains brief reports on a number of independent implementation efforts correlated with various issues studied in the project.
References 1. S. Abiteboul and S. Grumbach. Col: A logic-based language for complex objects. In EDBT'88 (Int. Con/. on Extending Database Technology), Venezia, Lecture Notes in Computer Science 803, pages 271-293. Springer-Verlag, 1988. 2. S. Abiteboul and R. Hull. IFO: A formal semantics database model. A C M Trans. on Database Syst., 12(4):297-314, December 1987. 3. S. Abiteboul and P. Kanellakis. Object identity as a query language primitive. In A C M SIGMOD International Con/. on Management o/ Data, pages 159-173, 1989. 4. A. Albano, L. Cardelli, and R. Orsini. Galileo: a strongly typed interactive conceptual language. A C M Trans. on Database Syst., 10(2), June 1985. 5. S. Ceri, G. Gottlob, and L. Tanca. Logic Programming and Data Bases. SpringerVerlag, 1989. 6. D. Chimenti, R. Gamboa, R. Krishnamurti, S. Naqvi, S. Tsur, and C. Zaniolo. The LDL system prototype. IEEE Trans. on Knowledge and Data Eng., 2(1):7690, March 1990.
7. R. Hull. A survey of theoretical research on typed complex database objects. In J. Paredaens, editor, Databases, pages 193-256. Academic Press, 1988. 8. R.B. Hull and R. King. Semantic database modelling: Survey, applications and research issues. ACM Computing Surveys, 19(3):201-260, September 1987. 9. G. Jaeschke and H.-J. Schek. Remarks on the algebra for non first normal form relations. In ACM SIGACT SIGMOD Syrup. on Principles of Database Systems, pages 124-138, 1982. 10. S. Khoshafian and G. Copeland. Object identity. In ACM Syrup. on Object Oriented Programming Systems, Languages and Applications, 1986. 11. G.M. Kuper and M.Y. Vardi. A new approach to database logic. In Third ACM SIGACT SIGMOD Syrup. on Principles of Database Systems, 1984. 12. A. Makinouchi. A consideration on normal form of not necessarily normalized relations. In Third International Con]. on Very Large Data Bases, Tokyo, 1977. 13. J. Mylopoulos, P.A. Bernstein, and E. Wong. A language facility for designing database-intensive applications. ACM Trans. on Database Syst., 5(2):185-207, June 1980. 14. S. Naqvi and S. Tsur. A Logical Language ]or Data and Knowledge Bases. Computer Science Press, Potomac, Maryland, 1989. 15. J.D. Ullman. Implementation of logical query languages for databases. A C M Trans. on Database Syst., 10(3):289-321, September 1985.
Bridging objects with logical rules: towards object oriented deductive databases S. Ceri and L. Tanca Dipartimento di Elettronica e Informazione Politecnico di Milano Piazza L. Da Vinci, 32 1-20133 Milano, Italy
A b s t r a c t . A recent direction of database research has been focused on integrating logic programming and object orientation. The rationale of such integration stems from two arguments; on one hand, object-orientation brings powerful data modeling capabilities by adding semantic and structural complexity to value-based relational databases. On the other hand, logic programming languages provide means for expressing queries and updates on a database with a declarative style; further, they provide the ideal language paradigms for expressing constraints and integrity rules. The integration of these two worlds has been investigated theoretically; firm bases for the coexistence of value-based and identity-based concepts within a unique data model have been established, and novel features have been added to logic programming languages in order to give them full power on semantically enriched data models. However, while structural and semantic complexity have been introduced without difficulty in the deductive context, the object oriented concepts that are more related to the data abstraction notion are more difficult to introduce. Therefore, the introduction of structurally and semantically complex objects in the logic programming area is the first step towards full object orientation. Concurrent with the deepening of the theory, several prototypes are currently being designed and implemented; the LOGIDATA§ project is one of these attempts, and the research efforts within this projects will be extensively described in this book.
1
Introduction
Many recent papers have been focused on the problem of integrating objectoriented databases with logic programming [10,24,25,4,14,16,6,21,22]. This integration is very reasonable, as either world provides useful concepts to the other one. Indeed, we argue that each world can give contribution to strenghten the weakest features of the other one. Object-orientation and logic programming have shown different trends of evolution. While the theoretical foundations of logic programming (LP) were firmly established since its introduction, with a universally acknowledged syntax and well-defined semantics (see for example [30]), the object oriented (OO) world has not shown the same uniformity; this situation has propagated from
object-oriented programming languages to object-oriented databases (OODB). The shop-list of concepts that should be provided by any OODB system has already been presented in two "manifestos", which show some overlap, but disagree definitely on many points [t, 33], thus demonstrating the difficulty of providing a standard view. Thus, we view object-orientation more as a programming style (like, for instance, structured programming) than as a programming paradigm. Key features of this style include the concepts of object identity, structural and semantic complexity of objects, the encapsulation principle, and a strong integration between data and their behavior. The absence of a strict programming language standard for OODBs makes LP a possible candidate for programming OODB systems; indeed, we argue that it is possible to use LP while keeping an object-oriented style. The advantages provided by LP include declarativeness and uniformity in the treatment of queries, updates, views, and constraints. The effort of extending LP in order to support an object-oriented style has been most successful for structural features: complex structures, object identity, typing and class hierarchies have been introduced in LP without serious difficulty. The integration process has surely captured the structural and semantic complexity of objects, thus we may refer to the integrated systems and languages as logical languages for complex object dalabases, rather than for fully object oriented databases. Instead, much has yet to be done for behavioral features: fundamental principles of object-oriented programming (such as encapsulation) still have to be supported by LP languages and systems. Table 1 presents a list of classical OODB concepts and indicates how they can be mapped to "equivalent" LP concepts. In the next section, we discuss the data modelling concepts that can be usefully transferred from the OODB to the LP world; in Section 3, we discuss the so-called dynamical or behavioral aspects of OODB's, i.e. those that have to do with data abstraction; then, in Section 4, we examine the advantage of an LP approach, namely, the features which make LP a suitable programming paradigm for OODB's. Section 5 will draw the conclusions.
2 Introduction LP world
of OODB
data
modeling
concepts
to the
The integration between LP and databases moved in the late seventies and early eighties from the observation that the predicative structure of information within LP corresponds to the simple record-based structure of tuples in the relational model. To amplify similarity, the first proposed experimental deductive language, Datalog, was very simple: structured terms of Prolog were eliminated, leaving only constants and variables as the language terms. As a consequence, Datalog literals had the same fiat structure as relational tuples [18].
Logic Programming Object Oriented complex terms complex objects OIDs and surrogates object identity surrogate-based object sharing predicate reference generalization hierarchies generalization hierarchies for predicates for classes unification through inheritance generalizations functions or methods adorned predicates built-in predicates support for aggregation and sorting external predicates control structures and procedures Table 1. OODB concepts that can be supported by LP
2.1
Structural complexity
Approximately at the time when Datalog was first introduced, the relational data model was extended in order to include more sophisticated structures, called nested or N F 2 relations [23, 17]. Such extension was motivated by the need of modelling complex data in the fields of geographical databases, engineering databases, and office automation (among others). The natural step on the Datalog side was to extend the data model accordingly, allowing complex terms, built up by the use of record and set lype construclors [35, 2, 28]. Another source of complexity was the introduction of functional constructs [2, 28], also based on a value-driven approach. Finally, data model complexity was enriched through the use of additional type constructors such as sequences and multisets [17]. In this way, the LP world has developed the theoretical basis for the support of structural complexily, one of the two main directions in OODB data models. This development is far from being successfully solved for practical systems, since the main difficulty is now at the technological level, and consists of providing suitable data structures and operators for efficient data manipulation and access. We believe that progress in providing structural complexity will equally apply to "canonical" OODB systems and to LP-based systems; as a matter of fact, it will probably be achieved by commercial database systems as well, through progressive enhancement of the relational data model. From now on, we refer to the relational data model as enhanced by the use of type constructors, thereby providing support for complex relations. This model is also called value-based, because all elements of the data model represent values.
10
2.2
Object Identity
The fundamental difference between the relational model and the OODB model is the concept of object identity. Each object of the OODB corresponds to one real-world object, and exists regardless of the value of its properties. Objects in OODB with the same structure have the same type; objects with the same type existing in a specific state of the OODB form a class. Objects may refer to other objects explicitly, without mentioning their properties; in particular, one object may be shared by two or more objects which include it as a component. This is the essence of the so-called identity-based data models. In value-based models, the identity of elements is expressed by the use of integrity constraints, in particular by defining a collection of attributes to be a key of a relation. Sharing can also be supported somehow artificially by appropriate design of relations, and the correctness of sharing requires the addition of referential integrity constraints to the schema. The notion of surrogates or tuple identifiers was introduced in many practical relational systems mainly for efficiency reasons, but never accepted as a concept of the relational theory. The extension of LP in order to support object identity has been performed by adding the notion of class; this addition may be achieved in several different ways. In most cases, predicate extensions define classes, and a class predicate has one special argument for the OlD variable, which satisfies the uniqueness property (each object has a unique, distiguished OID). In most realizations, the creation and manipulation of OlD variables is under the control of the system and not of the user. Several methods for manipulating OlD variables are possible, in particular for the creation of new objects. One possibility is OID invention: special rules are used for this purpose, having all LHS arguments bound, except the OlD variable. When the rule is executed, a new object is created for each tuple of LHS arguments satisfying the conditions on the RHS. Another possibility for object creation is the introduction of an explicit new built-in predicate, whose arguments are the class name and attributes of the new object to be created. The implementation of OIDs in such LP systems may be based on the use of surrogates, thus providing an identity-based data model on top of a value-based system implementation. However, defining classes as predicate extensions is only one way of implementing objects. Other approaches [11,29] define objects as logical theories. A logical theory (set of facts and rules) defines an object, a set of constraints (also represented by rules) defines a class, and specializations of these constraints define a class hierarchy. In this case, object identity is nothing else than a name for the theory defining the object. As an example, consider the program:
Name(tom). marriedto(tom, sue). wifeof(W,M)
marr, edto(M, W).
toma y(M, W) *--
ma, i dto(M, W), + marriedto(M,W).
This program defines the object Tom. The two facts are proper of the object,
11 while the two rules are shared by all the objects of the same class (for instance Person). Note that the second rule defines an object update method. Some researchers [40] argue that a strict interpretation of object identity is incompatible with the logic programming style, by showing that if "everything is an object with identifier" many simple logic programs lose their obvious and intuitive semantics. Again, it must be said that the problem is mainly felt when DOOD languages are realized by identifying classes with predicate extensions, and thus objects coincide with ground facts. In systems as above [11] traditional logic programs are objects themselves, thus a new way of programming in logic is invented, in which interaction and cooperation between objects is some kind of interaction between logic programs, and derivation of new ground facts does not necessarily coincide with derivation of new object instances. However, in languages where classes are predicate extensions, we agree with the observation, and advocate the need of including the concept of identity in the LP world without eliminating value based constructs. There are various reasons for this [14]: identity based data items introduce object sharing and inheritance in a natural way; on the other hand, not all data items deserve the status of an object: in particular, database applications often need the definition of ad-hoc queries, and results of queries are well represented as values. Finally, since elements of a class are always distinguished by their identities, we do not have the possibility of removing undesired duplicates: we need values for those computations where elimination of duplicates is needed (e.g. fixpoint computations). 2.3
Semantic complexity
The two key dimensions of semantic complexity in the OODB approach are class hierarchies and objecl sharing. The concept of class hierarchy has long been present in database design [12, 8] or used by persistent database programming languages [34, 7]. Overall methodologies for database design, as presented for instance in [9], give evidence of the need for semantic complexity in data modeling. During the early, conceptual phase of database design, major emphasis is placed on the use of generalization, thereby enhancing the clarity and correctness of conceptual schemas with respect to the real world. However, during the following phase of logical database design, generalization hierarchies are transformed according to the data structures available in the commercial database that has been selected, whose data model normally lacks the notion of generalization. Class hierarchies are supported by all OODB data models; typically, the subclass relationship is any acyclic graph. In some OODB models, all classes are descendent of the same class, the generic object class; in other cases, the class hierarchy has instead multiple roots. The notion of inheritance may be seen in many different ways. In the typical database design tradition, the fundamental property associated to class hierarchies is that each subclass inherits all properties of its superclasses: the whole
12 structure of the superclass is inherited, thus this point of view is generally called structural inheritance. According to this philosophy, subclass extensions are always subsets of superclass extensions. However, other semantics of inheritance have been proposed [15]: the most liberal one establishes that subclasses inherit only procedures attached to superclasses. Superclass extensions do not necessarily include subclass extensions. Moreover, the data structures may differ. The inheritance of procedures (methods) is implemented by overloading procedure names: if the subclass structure is different from the superclass structure, the inherited procedure is redefined for the subclass, but this is totally transparent to the user. This notion of inheritance is similar to that of some OO programming languages. In our opinion, the database environment needs the first kind of inheritance, since in most concrete cases the user must be able to rely on the similarity of the data structures of classes in a hierarchy. Moreover, implementing such a mechanism is less complex, especially in a deductive environment, where a particular type of unification must be defined, that "traverses" class hierarchies. An example of such unification is considering two classes: PERSON, with attributes NAME and ADDRESS, and STUDENT, subclass of PERSON, inheriting its attributes plus the attributes STUDENT-NO and FACULTY. There must be the possibility for two elements of these two classes to unify, since a student can be seen also as a simple person. Consider the query: Who are the persons that live in Milano, at Piazza L. Da Vinci?. Of course we intend that a student living at that address should be included into the answer. Thus object identifiers of persons and students must unify, and the common attributes must unify as well. Another possible variant to the inheritance mechanism is that classes may or may not have multiple superclasses; if this is allowed, then the OODB data model supports multiple inheritance. A typical OODB model constraint may state, in such cases, that all classes with multiple inheritance descend from a unique root. Noticeably, all these OODB concepts can be easily supported by LP, given that it supports class predicates. As already mentioned, the main difficulty in supporting inheritance in LP has to do with the required interpretation of unification for OlD variables; this must be supported not only between terms in subsumption relationship, but also between terms in generalization relationship. Such extended unification may be easily implemented if we suppose that all object instances descending from the same object in a root class are the same, thus sharing the same OlD. This approach requires that all classes inheriting from multiple classes have the same root class. In this way, OID unification is reconducted to conventional term subsumption; at the implementation level, object unification corresponds to surrogate-based equi-joins. Object sharing (and, in general, support of the aggregation abstraction by establishing the part-of relationship between classes) is the other dimension of semantic complexity; again, this may be easily modeled by enabling LP class predicates to mention other classes. Such correspondence may be implemented by allowing some arguments of a class predicate to be OIDs of other classes.
]3
3 Introduction of O O D B behavioral concepts into the LP world In the LP environment, data are retrieved and manipulated by Horn clause programs, that consist of collections of rules; each rule has one literal in the LHS and several literals in the RHS. In the early versions of Datalog, the structure of these literals was very simple; in particular, only positive literals without function symbols are Mlowed in either side of the rules; predicates are partitioned into intensional (IDB) and extensional (EDB) predicates; the latter are extensively stored in the database and are disallowed in the LHS of rules [39, 18]. The distinguishing feature of Datalog with respect to conventional query languages is the ability to express recursion, thus extending their computational power. The original Datalog, however, was very poor with respect to other features, such as aggregation, sorting, computation of standard functions and other classical query language features. This core language has been progressively extended, by adding complex terms, negation in the body and in the head of rules, built-in and externally defined predicates, and various ways to express updates to EDB relations. Rule semantics has also been extended and clarified, dealing with negation and nondeterminism. Such an extended LP language can now be considered as a full-power database programming language [16].
3.1
Methods
Roughly speaking, methods are procedures attached to objects; in virtue of the encapsulation principle, they are the only means to retrieve or manipulate data in OODB's. The interface of methods is provided by their signature, which gives the structure of input and output parameters; the body of the method is the code that actually implements it. Encapsulation dictates that the method user only knows its signature, and has no access to its code. Late binding is used to enable method specialization, namely, the run-time choice of the most suited version of a method, which comes from the most specialized class of the object to which the method is applied. Functions have been chosen in [6, 19] as the LP concept that most immediately corresponds to methods. Conceptually, functions are really appropriate to represent methods in OODB's. In fact, object attributes may be seen as functions that return an extensional value, while object methods are functions that return a computed value, or produce some side effect. Functions have distinguished input and output parameters; their structure is dictated by the function's signature. The function's computation is defined by one or more rules, which constitute the function's body. Another way of simulating methods in LP, especially when the functional construct is not available, is through the use of adorned predicates. A static adornment corresponds to a fixed mapping of each predicate argument to either
14 bound or free. Predicate adornments enable distinguishing input (bound) parameters from output (free) parameters; thus, a predicate may correspond to several methods, each one with a different static adornment. For each given value (binding) of the input arguments, the rules associated to the predicate produce the bindings for the output (free) arguments. Therefore, also in this case rules are used to implement the bodies of methods. An example of this use of adornments is the following rule:
gr-par(G-PAR:X, G-CHILD: Y) -: par(P:X, CHILD:Z), par(P:Z, CHILD: Y). Such a rule can be used for computing the grandparents of a certain person, by binding (i.e. giving an input value to) the Y variable and expecting the X as an answer, or to compute the grandchildren by binding the X variable.
3.2
Built-in and External Predicates
Built-in and external predicates are basic ingredients for adding essential features of query languages to LP. Built-in predicates enable aggregation (nesting and unnesting of structures), the evaluation of aggregate and scalar functions, and the sorting of results. Typically, built-in predicates are not strongly typed and can be computed only when some of their arguments are bound; for instance, consider the mid predicate having as first argument a set and as second argument the minimum element. In this case, the first argument must be bound to a given set of elements, that can be either of type integer or of type real; the second element may be either free (so that it gets bound as result of the predicate evaluation) or bound to a value before evaluation (so that the predicate evaluation returns a truth value). Externally defined predicates provide the ability of invoking general procedures, written in a conventional programming language [26]. This is most useful in practice, for instance for integrating the language with screen management or report formatting procedures, or for enabling the use of mathematical software libraries. Externally defined predicates may be viewed by the logic program as extensional predicates. Thus, they do not completely violate LP declarativeness, and make the language more suited for practical use. On the OODB side, the encapsulation principle is not violated. Indeed, external predicates may easily be seen as methods attached to particular classes, thus allowing the user to see only the signatures, that correspond to the predicate name and arguments.
3.3
Encapsulation and information hiding
Encapsulation is not yet well understood in the context of LP. In principle, encapsulation may be achieved by enabling the manipulation of classes only through the use of functions; information hiding may be achieved by disabling the inspection of the classes' structure and of the functions' bodies. In practice, usually LP programmers have a a fully transparent view of predicates and rules. Controlling side effects due to addition and deletion of rules within rule-based systems may be very difficult. More in general, due to the lack of modularization concepts, it is difficult to create clear interfaces among pieces of programs.
15 To overcome this difficulty, several notions of modularization within LPs are currently being proposed by the research community. For instance, a notion of modularization is currently supported in LOGRES [14]. Modules are used to add or delete rules of a LOGRES database; the application of a given module to a database state is controlled by specifying the mode of application of (sequences of) modules. Another notion of modularization is proposed in [29]. In this case, modules are applied to database states according to a temporal partial ordering, and rule interpretation reflects the time of their creation; rules can be overridden by other rules, thus enabling the modeling of specialization and exceptions. Though the data abstraction and encapsulation principles that underlie the use of methods may be appropriate for many applications, they may prove ineffective in many database applications [40]. Indeed, the theory and practice of database systems has taught us to look for formal properties of the operations we define on data, in order to exploit them during data access optimization. For instance, commutativity of selections with joins is very useful for reducing useless mass memory accesses. These optimization means were fully transferred from the relational to the deductive world, and actually augmented to cope with the increased expressive power of deductive languages (see for instance the magic set optimization method [39], and others [36]). However, supposing to implement database operations by methods, we easily lose this facility. Indeed, a method is typically known either at a very high level of abstraction, through its signature, or by analyzing its code, which is often an arduous task, especially if we want to do it automatically. In a sense, in pure OODB systems we lack an intermediate level of abstraction, which should allow us to ignore implementation details, while exploiting useful formal properties of operations. One should instead consider that methods written through rules are more easily inspectable, and composable automatically; after composition, optimization may apply to them to improve access efficiency while not compromising encapsulation.
4
The LP Advantage
We now turn to examining the "advantages" that can be achieved when LP is used within a OODB style. We argue that LP presents interesting features with respect to C + + - or SmallTalk- like languages which are conventionally used as representative programming languages for OODBs. 4.1
Declarativeness
The obvious difference between conventional programming languages and LP concerns the declarative programming style: in essence, computations are declared based on their meaning (what should be achieved) and disregarding all
]6 procedural features (howit should be achieved). In practice, some degree of procedurality cannot be avoided when LP is used to express database updates or with externally defined or built-in predicates. For instance, the module mechanism of LOGRES [14] allows to concentrate all the procedurality and control which is needed for database evolution in determining the sequence and modes of application of modules, whereas each module execution has a declarative semantics. The use of LP as a database programming language requires a rather deep change in programming habits; such a transition may be made smoother if conventional query language constructs are added to LP languages and if a rich collection of externally defined predicates becomes available as a library. Once programs are written with a declarative style, their optimization, evolution and reverse engineering is much easier; this implies large pay offs in the long run. 4.2
Set-oriented Processing
LP is suited for set-oriented computation, while most OODB languages ar.e suited for tuple-oriented, navigational computation. In this sense, LP is "in the tradition" marked by relational query languages. Conversely, OODB navigational languages are "in the tradition" marked by Codasyl-like, pointer-based languages. A set-oriented query facility has long been recognized as a necessary feature for databases; therefore, most OODB systems are presenting also a set-oriented query language. However, there are some queries that are most efficiently expressed through navigational languages, especially when the expected result of a query is one single element and not an entire set. Nondeterministic semantics, discussed in the following, may give an effective way of expressing computations where the user is satisfied by any solution selected among many possible alternatives. 4.3
Nondeterminism
Nondeterministic computation is required for solving problems which are nondeterministic in nature; in such computations, any possible solution among a set of alternatives is equally acceptable as an answer. Typical examples are configuration problems, which are solved by one of several alternative assignments satisfying appropriate integrity constraints. In this case, the computation of all solutions is superfluous, and therefore a nondeterministic semantics is most efficient. Nondeterministic semantics can be given naturally to LP languages [5, 16]. 4.4
Views and Integrity-preserving Rules
LP provides uniform treatment of views, which are defined as intensional predicates, and integrity-preserving rules, which may be automatically generated by the system as a consequence of structural constraints of the data model (see, for instance, [16]).
17
Such integrity perserving rules can keep the coherence of a database instance with the schema, and ease unification. For instance, consider again the PERSON/STUDENT example of Subsection 2.3. A rule:
person(X) : - student(X). says that all objects of the class STUDENT are also PERSONS. Thus, the answer to the proposed query should automatically include students among the inhabitants of Piazza L. Da Vinci. Other integrity-preserving rules may be semi-automatically generated from general constraints (see [20]). For instance, by the selfanc constraint we require that a person never appears as an ancestor of him/herself:
selfanc : error(X) : -- anc(X,X). In this way, the system will generate a fact error(a) for each individual a that violates the constraint. A query ? - error(X) will display the violating individuals. A rule-based approach to integrity preserving is becoming an essential ingredient of new generation databases, as integrity checking is being moved from database applications into the database system. It is worth noticing that such ingredient is provided for free by LP-based systems [38], where integrity-preserving rules may be interleaved with all other rules, and executed by the same general mechanisms.
5
Conclusions
We have discussed the integration of deductive databases with object orientation. We consider this integration as feasible and desirable, since object-orientation brings powerful data modeling capabilities by adding semantic and structural complexity while logic programming languages provide means for expressing queries, updates, constraints and integrity rules in a declarative style. However, while structural and semantic complexity have been introduced without difficulty in the deductive context, research is still to be done for modeling in logical terms the behavioral concepts of the object oriented world, and the introduction of structurally and semantically complex objects in the logic programming area is only the first step towards full object orientation.
6
Acknowledgments
We thank the anonymous referees for their useful comments and suggestions.
18
References 1. Atkinson, M., F. Bancilhon, D. De Witt, K. Dittrich, D. Maier, S. Zdonik: The Object-Oriented Database System Manifesto. Proc. First Int. Conf. on Deductive and Object-Oriented Databases, Kyoto, 1989. 2. Abiteboul, S., S. Grumbach: COL: a Logic-based Language ]or Complex Objects. Proc. 1988 EDBT. 3. Abiteboul, S.: Updates, a New Frontier. Proc. 1988 ICDT. 4. Abiteboul, S., P.C. Kanellakis: Object Identity as a Query Language Primitive. Proc. 1989 SIGMOD. 5. Abiteboul, S., E. Simon, V. Vianu: Non-deterministic Languages to Express Deterministic Transformations. Proc. 1990 PODS. Bases de Donn~es Avanc6s, September 1989. 6. Abiteboul, S. Towards a Deductive Object-Oriented Database Language. Data and Knowledge Engineering, 1991. 7. Albano, A.: Type Hierarchies and Semantic Data Models. ACM SIGPLAN 83: Symposium on Programming Language Issues in Software Systems, San Francisco, 1983. 8. Atkinson, M.P., P. Buneman, R. Morrison: Data Types and Persistence. SpringerVerlag, 1989. 9. Batini, C., S. Ceri, S.B. Navathe: Database Design using the Entity-Relationship Approach. Benjamin-Cummings, 1991. 10. Beeri, C.: Data Models and Languages for Databases. Proc. 1988 ICDT. 11. Bertino, E. and M. Montesi: Towards a logical object oriented programming language ]or databases, Proc. EDBT '92, Vienna, 1992. 12. Cardelli, L.: A semantics of multiple inheritance. Information and Computation, 76:138-164, 1988. 13. Cacace, F.: Implementing an Object-Oriented Data Model in Relational Algebra: Choices and Complexity. PdM Report n. 90-009. 14. F. Cacace, S. Ceri, S. Crespi-Reghizzi, L. Tanca, R. Zicari: Integrating ObjectOriented Data Modeling with a Rule-Based Programming Paradigm.Proc. 1990 SIGMOD. 15. Ceri, S., F. Cacace, S. Danforth, E. Simon, L. Tanca The language RL and its semantics Report of Esprit Project STRETCH, 1990. 16. F. Cacace, S. Ceri, L. Tanca: Consistency and non-determinism in the Logres language, MFDBS 1991, Lecture Notes in Computer Science, Springer Verlag. 17. Ceri, S., S. Crespi-Reghizzi, G. Lamperti, L. Lavazza, R. Zicari: ALGRES: An advanced database system for complex applications, IEEE-Software, 1990. 18. Ceri, S., G. Gottlob, L. Tanca: Logic Programming and Databases, Springer Verlag, Berlin, 1990. 19. Cacace, F. and L. Tanca: Concurrency in Deductive Object Oriented Databases, Internal Report, Politecnico di Mflano, 1991. 20. Ceri, S., J. Widom: Deriving Production Rules for Constraint Maintenance. Proc. VLDN, Sydney, August 1990. 21. Proc. DOOD 89, Kyoto, Lecture Notes in Computer Science, Springer Verlag, 1989. 22. Proc. DOOD 91, Munich, Lecture Notes in Computer Science n. 566, Springer Verlag, 1991. 23. Fischer, P.C., S.J. Thomas: Operators]or Non First Normal Form Relations. Proc. of the IEEE Computer Software and Applications Conf. 1983, 464-475. 24. Ma.ier, D. :A logic for objects. Oregon Graduate Center Technical Report CS/E86-012, Nov. 1986.
19 25. Kifer, M., J. Wu: A Logic for Object Oriented Programming (Maier's O-Logic Revisited). Proc. 1989 PODS. 26. Krishnamurthy, R., C. Zaniolo: Optimization in a Logic Based Language for Knowledge and Data Intensive Application, in Advances in Database Technology, Proc. 1988 EDBT, Springer Verlag. 27. Kuper, G.M., M.Y. Vardi: A New Approach to Database Logic. Proc. 1984 PODS. 28. Lambrichts, E., P. Nees, J. Paredaens, P. Peelman, L. Tanca:lntegration of Functions in Logic Database Systems, Data and Knowledge Engineering, 1990. 29. Laenens, E., D. Sacca', and D. Vermeir:Eztending Logic Programming, Proc. ACM SIGMOD 1990, Atlantic City, N J, May 1990. 30. LLoyd, J.: Foundations of Logic Programming, Second Extended Edition, Springer Verlag, 1987. 31. Lecluse, C., P. Richard and F. Velez: 02, an Object-Oriented Data Model. Proc. 1988 SIGMOD. 32. Maier D.: A Logic for Objects. Proc. Workshop on Foundations of Deductive Databases and Logic Programming, Washington USA, 1986. 33. The Committee for Advanced DBMS Functions: Third-Generation Data Base System Manifesto. Mem. UCB/ERL M90/28, April 1990. 34. Mylopulos, J., P.A. Bernstein, H.K.T. Wong: A Language Facility for Designing Database-Intensive Applications. ACM Transactions on Database Systems, Vol. 5, No. 2, June 1980, pp. 185-207. 35. Naqvi, S., S. Tsur: A Logical Language for Data and Knowledge Bases. Computer Science Press, New York, 1989. 36. Ramakhrishnan, R. and S. Sudarshan, Aggregation and Relevance in Deductive Databases, Proceedings of the VLDB 1991, Barcelona, Sept. 1991. 37. Schmidt, J.W.; Type Concepts for Database Definition. In Database: Improving their usability and responsiveness, Academic Press, 1978. 38. Tanca, L.; (Re-)Action in Deductive Databases, Proc. 2nd International Workshop on Intelligent and Cooperative Information Systems, Como, Italy, 1991. 39. Ullman, J.D.: Principles of Databases and Knowledge-Base Systems. Volume I, Computer Science Press, Potomac, MD, 1988. 40. Ullman, J.D.: A comparison between deductive and object oriented database systents, Proc. DOOD 91, Munich, Lecture Notes in Computer Science n. 566, Springer Verlag, 1991.
The LOGIDATA-b
Model*
Paolo Atzeni 1, Filippo Cacace 2, Stefano Ceri 2, and Letizia Tanca 2 1 Dipartimento di Informatica e Sistemistica, Universits di Roma "La Sapienza," Via Salaria 113, 00198 Roma, Italy 2 Dipartimento di Elettronica e Informazione, Politecnico di Milano, Piazza Leonardo da Vinci 32, 20133 Milano, Italy
A b s t r a c t . The LoGIDATA+ data model is presented. It is value-based, object-based, and functional at the same: it involves classes (with objectidentity), relations (value based), and functions. Classes can be referred to in relations and functions. Is-a relationships can be defined on classes. Complex values can be built by means of the recursive use of set, tuple, and sequence constructors. As usual in database frameworks, the model has an intensional level (with the notion of scheme) and an extensional level, (with the notion of instance). A data definition language for the description of LOGIDATA+ schemes is also presented.
1
Introduction
This and the following paper in this collection [4] present the LOGIDATA+ data model and language, respectively. The subsequent paper [7] is entirely devoted to the description of a.n application. For this reason, this paper does not contain examples. The central concepts in the data model are the notions of LOGIDATAqscheme and L OGIDATA-I- instance, respectively corresponding to the structure and the current values of a LOGIDATA+ database. With reference to the use of the model as a basis for a deductive language, it is important to note that instances contain both base values, actually stored on physical devices, and derived values, generated by means of rules. However, the basic notions of the model are static in the sense that they are not sensitive to the distinction between base and derived values. The model is similar in spirit to the model in the IQL proposal [3] (and therefore to the model of the 02 system [5]). Some ideas are inherited from other models, including the Logical Data Model [11], COL [1], IFO [2], and LOGRES [8]. The model involves three main constructs, classes, relations and functions. A LOGIDATA+ class is a set of objects, entities for which value equality does not imply identity; this is implemented by means of object identifiers (old's), which are not visible to the users. A LOGIDATA+ relation is a relation as in the nested relational model, with the further possibility of including references * Work supported by CNR, "Progetto Finalizzato Sistemi Informatici e Calcolo Parallelo." The first author is now with Terza Universit~ di Roma.
21 to classes (which are implemented by means of oid's). A LOGIDATA+ function is a (partial) function in the usual sense; its domain and range may have nested structures. Whereas the structures (and instances) of relations and functions may involve references to classes (and objects), the converse is not possible because relations and functions are value-based, and so their elements have no oid. The inclusion of three different structures in the model was motivated mainly by the need for a framework that allowed investigations in various directions, including the interaction between constructs and paradigms. In fact, the LOGIDATA+ model is at the same time value-based, object-based, and functional. This is redundant in many cases, because most applications can be modeled by means of only a few constructs; however, this often requires rather involved or artificial techniques. In a deductive language especially, the availability of a range of constructs can provide the necessary flexibility and ease of use; at the same time, redundant structures may be defined as derived items, by means of rules. In fact: - classes model the sets of identifiable objects (entities in the Entity-Relationship or other semantic models, classes of objects in Object-Oriented models); generalizations or is-a relationships can be naturally defined on them; - relations can handle value-based data (for example, the results of queries that have to be provided as output to a user or to another system are tables of data - - with no oid's) and relationships between classes (relationships in the E-R model); - functions can be used to: 9 define in an orthogonal way relationships between classes (as it is done in the Functional Data Model [6,14]), or those between classes and their attributes [9]; 9 embed built-in functions in rules, regardless of the actual implementations of functions; with suitable restrictions on boundednes of arguments, functions can be used to define interfaces to imperative or functional programming languages; 9 attach procedures to classes; 9 manipulate the structures of complex objects [1]; specifically, they are fundamental in the manipulation of sets and sequences. Tuples in relations, objects in classes, and elements in domains and ranges of functions may have complex structures, built by means of the recursive use of the tuple, set, and sequence constructors. Type names are provided in order to simplify declarations, as in many programming languages. Complex generalization hierarchies can be built by means of is-a relationships with inherited properties. Multiple inheritance is allowed: it is possible that a class be a subset of two or more incomparable classes; some technical restrictions are needed here to guarantee well-definedness. This paper contains three sections, beside this Introduction. Section 2 is concerned with the extensional level of the model, with the notion of scheme. Section 3 presents the data definition language. Section 4 deals with the intensional level, with the notion of instance.
22 2
The
Intensional
Level:
LOGIDATA+
schemes
We fix a countable set 1: of labels (or attribute names) and a finite set B of base type names; associated with each B E B there is a set of base values v(B); the sets of base values are pairwise disjoint. 3 A LOGIDATA+ scheme is a six-tuple S = (T, C, R, F, TYP, ISA), where T, C, It, F are finite, disjoint sets of symbols called type names, class names, relation names, function names, respectively. Before defining the other components of a scheme, an auxiliary, important notion is needed. The type descriptors (or simply types) of S are defined as follows:
-
1. 2. 3. 4. 5. 6.
-
-
if B is a base type name in B, then B is a type of S; if T is a type name in T, then T is a type of S; if C is a class name in C, then C is a type of S; if r is a type of S, then {r} is also a type of S, called a set type; if r is a type of S, then (r) is also a type of S (sequence type); if r l , . . . , rk, with k > 0, 4 are types of S and L1, .., Lk are distinct labels in /:, then (L1 : 7.1,..., Lk : rk) is also a type of S (tuple type); since the labels are distinct, the order of components is immaterial, and so we may assume that, for every permutation i l , . . 9 ik of the first k naturals, (L1 : 7.1,...,Lk :rk) is the same type as (Li, : r i , , . . . , L i k : r/k); 7. nothing else is a type of S. We can now continue with the definition of the components of a LOGIDATA+ scheme. TYP is a function defined on T U C U R U F such that: $ for each T E T, TYP(T) is a type descriptor; 9 for each symbol S E (3 U R, TYP(S) is a tuple type descriptor; 9 for each F E F, TYP(F) is a pair (7"1,7"2) (usually written as 7"1 --* 7"2), where 7"1 (called the domain of F ) is a tuple type descriptor and 7"2 (the range of F ) is a type descriptor; if the range 7"2 is a set type (or a type name that corresponds to a set type) then we say that F is a multivalued function, otherwise that it is a monovalued function, with the condition that the relationship U among type names is a partial order, where T1 _ T2 if T1 occurs in TYP(T2), for T1, T2 E T
- ISA is a partial order over C, with the following conditions: 1. if (C1, C2) E ISA (often written in infix notation, CIlSAC2 and read "C1 is a subclass of C2"), then TYP(C1) and TYP(C2) are constrained as follows: TYP(C1) = (L1 : 7"1,...,Lh : 7"h,...,Lh+p : 7"h+p), TYP(C2) = (L1 : 7"~,...,Lh : r~), with h _> 0, p _> 0, and, for 1 < i _< k, 7"i is 3 This guarantees that the type of each constant is uniquely defined. Moreover, in almost every language the base types are disjoint. 4 That is, we allow the empty tuple; this may be useful for technical reasons.
23
a refinement of r/, according to the following definition. A type 7" is a refinement of a type 7"' (in symbols r _ 7-') if and only if at least one of the following conditions holds: (a) r = r';
7- e T and TYP(r) _~ 7"; 7", 7"' 9 T and TYP(7") ____.TYP(7"'); r, 7"' 9 C and (r, 7"') 9 ISA; 7" = {7"1} and 7"'= {7"~}, with 7"1 -4 7"I; 7" = (7"1) and 7 " = (7"~), with I"1 "~ 7-~; 7- = (L1 : r i , . . . , n k : 7"~), 7"' = (L1 : v ~ , . . . , n k : 7-~) and 7-i -4 r', for l , then/9(t) = < /9(tl),...,/9(th) > ; = t'.A is a t e r m involving a dot operator, then/9(t'.A) =/9(t').A, m e a n i n g value of the first-level a t t r i b u t e A of the valuation of t'.
T h e notion of valuation is extended in the n a t u r a l way to atoms, literals and sets of literals. Given a valuation 0 and a literal L we say t h a t 0 is ground on L if O(L) contains no variables. Given an interpretation 5 , a literal L, and a valuation 0 t h a t is ground on L, we define the notion of satisfaction: - if L is a relation atom, a class a t o m or a function a t o m whose predicate symbol is a monovalued function, then 9r satisfies L under valuation O, written 5 ~ O(L), if O(L) e 5; 5 satisfies -,L under valuation 0 if O(L) ~ 5; - if L is a function a t o m of the form t IS F(A1 : t l , . . . , Ak : tk) whose predicate symbol is a multivalued function, let us define the set v = {O(x) [ .T O(Z IN F(A1 : t l , . . . , A k : tk))}; then 5 satisfies L under valuation 0, if v = O(t); ~ satisfies -~L under valuation 0 if v r O(t); - in general, if L involves built-in predicates and functions, U ~ O(L) if O(L) is true in ~" according to the ordinary sense of the built-in predicate in L. Given a clause p and a valuation O, we can consider the application of 0 to the literals of p. Then, we say t h a t :T ~ O(BODY(p))if ~" satisfies all the literals in the b o d y of p, under valuation O. Given an interpretation U and a set of clauses P , we define the valuation domain VD(P, ~ ) as follows: vD(P, 5)
=
{(p, O) I P e P , 0 is a valuation on :T such that, 5 ~ O(BODY(#)), and there is no O' such t h a t O' is an extension of 0 and :T ~ O'(HEAD(p))}
36 The valuation domain is the set of pairs composed of a clause and a ground valuation that participate in the derivation of new facts. If one thinks of jr as the "current state" after a certain computation step, then we are interested in the pairs (p, 0) that contribute to deriving the ground facts for the next computation step. The ground facts can be derived either by using old oid's and constants, or by inventing new oid's. Given a set of clauses P, and a valuation domain VD(P, ~'), a valuation map 7/ is a function that associates, with each of the elements (p, 0) of VD(P, ~r), a valuation ~}(p,0) of the variables in the head of p in the following way:
- for each variable X occurring both in HEAD(p) and BODY(p), r/(p,0)(X) equals 0(X); if p is an old-invention clause and X is its oid-invention variable, then ~/(p,0)(X) is a new object identifier (old) not present in ~'. Moreover, if X is the oid-invention variable of a clause p, X' is the oid-invention variable of a clause pt, (p, 0) and (pC,0t) are elements of the valuation domain, with p ~ p' or 0 ~ 0', then rl(p, O)(X) ~ r}(p', O')(X'). This means that inventions happen in parallel, producing distinct oid's for each clause and each ground substitution. -
Note that, by definition of valuation map and valuation domain, once a clause p has generated an old for a certain substitution, that clause cannot generate any more oid's for the same substitution. We now define the set of new facts produced by a deduction step. Given a program P and interpretation ~', and chosen a valuation domain VD(P, ~-), we have:
NEW(P,3 r) -- {r/(p,9)(HEAD(p)) I (p, 8) E VD(P,.T')} We define the one-step operator 7 p by means of the function NEW. Given a set of clauses P, an interpretation ~r and a valuation domain vD(P, ~), we define: 7 p ( ~ ) = JrUNEW(P,~') The operator 7 p is clearly non-monotonic, because of the presence of negated literals and set-valued functions in LOGIDATA+ clauses. However, for a growing, finitary and stable [13] operator 7 p , we define the fixpoint operator 7~ as follows. Given a set of clauses P and an interpretation ~r, let: .~.o = ~.;
yi = 7p(.Ti-1), for i > O; jr~ = 7~(~') = ~.k such that j r k =
.~-k-1,
if it exists.
37 4.2
Set of facts associated with an instance
An important step in the definition of the semantics of a L O G I D A T A + program P over an instance s of a scheme S = ( C , R , T , F , TYP,ISA) consists in the characterization of a function r that trasforms the input instance s into a set of L O G I D A T A + ground facts, that is, an interpretation over with S. The function r associates a set of facts with each instance s -- (c, r, f, o) of S in the following way. Let r he the set of facts containing: - a fact R(A1 : V l , . . . , A k : ok), for each R E R and each tuple (A1 : v l , . . . ,Ak :ok) in the relation r(R); - a fact C(OID : o, A1 : v l , . . . , A k : ok), for each o E O and for each class C such that o E c(C), where A 1 , . . . ,Ak are the attributes of C and (A1 : v l , . . . ,Ak :ok) is the restriction of o(o) to A 1 , . . . ,Ak; - a f a c t v IS F ( A 1 : V l , . . . , A k : Vk), for each monovalued function F E F and each tuple (A1 : v l , . . . , A k :vk) such that v is the value associated to (A1 : v ~ , . . . , A k :vk) by the function f ( F ) ; -- a fact v IN F ( A 1 : v l , . . . ,Ak : vk), for each multivalued function F E F and each tuple (A1 : v l , . . . , Ak : vk) such that v is the set of values associated to (A1 : v l , . . . , A k :vk) by the function f ( F ) , and v E v. In plain words, r contains: one fact for each tuple in each relation; as m a n y facts for an object o as the number of different classes which o belongs to; 5 one fact for each tuple on which a monovalued function is defined; as m a n y facts for each tuple on which a multivalued function is defined as the number of elements in the corresponding set of values. The function r is defined for every instance, but it can be shown that is not surjective: there are sets of facts that are not in the image of r There are several conditions that can be violated. We sketch some of t h e m informally: - (well-typedness): for each fact, all attributes of the predicate symbol appear and the corresponding terms have the appropriate type. - ( c o n t a i n m e n t ) : for each oid o and each fact C I ( O I D : O , . . . ) , there is a fact C2(OID : o , . . . ) for each class C2 such that C1 IsA C2. This condition requires the satisfaction of the containment constraints corresponding to isa hierarchies. - (disjointness): for each oid o and each pair of classes C1, C2, if both facts CI(OlD : o , . . . ) , and C2(OlD : o , . . . ) appear, then C1 and C2 have a common ancestor in S. - (old-coherence): if an oid o occurs as a value in a fact for an attribute whose type is a class C, then there is a fact C(OlD : o , . . . ) . This condition rules out dangling references. - (functionality): there cannot be two different facts C'(OID : o , . . . , A : v ' , . . . ) and C~(OID : o , . . . , A : v'~,...), with v' # v% T h a t is, two facts for the 5 Note how each of the facts involves only the attributes that are relevant for the corresponding class.
38 same oid have respectively identical values for the common attributes. This happens for monovalued function as well: there cannot be two different facts v Is F(A1 : v l , . . . , A k : vk) and v' Is F(A1 : v ~ , . . . , A k : v~), with vl = v~, 9.., vk = v~, and v • v'. Since the function r is not surjective, its inverse r is not defined for every set of facts. Given a set of facts ~', if r is defined over ~', we will denote with r the instance corresponding to 5 . 4.3
Management
o f isa r e l a t i o n s h i p s
In order to define the semantics of a LOGIDATA+ program it is necessary to deal with hierarchies; in fact isa relationships require generation of facts for the satisfaction of containment constraints - - intuitively, these facts correspond to the propagat!on of oid's along isa relationships. The solution we adopt consists in adding to each program clauses that enforce the isa relationships defined over the corresponding scheme (as it is done in the LOGRES language [9]). Specifically, given a scheme S = (C, R, T, F, TYP, ISA), we define the isa-clauses ff'S for S as follows: {C2(OID : xo,A1 : x l , . . . ,Ak :k) ~ CI(OID : xo,A1 : x l , . . . ,Ak+h : Xk+h)l C1 ISA C2, with TYP(C2) = (A1 : r l , . . . , Ak : rk) and TYP(Cl) ~- (A1 : r l , . . . ,Ak+h : rk+h)} 4.4
Stratification
In order to cope with negation and set-valued functions, we introduce a stratification policy for LOGIDATA+ sets of clauses. Given a clause p, we call head symbol of p the predicate symbol of HEAD(p). Given a LOGIDATA+ set of clauses P, we define the Dependency Graph extended with Negation and Functions, called DGNF, of P as follows: - the set of nodes N(DGNF) is the set of predicate symbols occurring in P; an edge (u, v) belongs to the set of edges E(DGNF) if there is a clause p in P such that u is its head symbol, and such that v occurs in its body; - an edge (u, v) 9 E(DQNF) is marked if there is at least one clause p in P with head symbol u such that either: 1. v is a symbol occurring negatively in the body of p; or 2. v is a multivalued function symbol, appearing in the body o f p in a simple function atom of the form t IS v( .... ). -
A LOGIDATA+ set of clauses P is stratified if it is partitionable into subsets P 1 , . . . ,P,~ such that: - if u E Pi, v 9 P j , (u, v) 9 E(DGNP), then i >_ j; if u 9 Pi, v 9 P j , and (u, v) is a marked edge in E(DGNF), then i > j. -
39 P 1 , . . . , Prn is called a stratification of P. A necessary and sufficient condition for the stratification of a L O G I D A T A + set of clauses P is t h a t the DGNF associated with P has no cycle with a marked edge. Not all sets of clauses are stratified, but detecting stratification is quite easy [1]. It is well known that each s t r a t u m Pi produces a growing, finitary and stable operator [4] 7 p , . This allows for the definition of a fixpoint operator 7 ~ , associated with each Pi. 4.5
Semantics of a program
Given a program P over a scheme S, it is therefore possible to build the L O G I D A T A + set of clauses P P , S = P U gts , obtained by adding to the clauses in P the isa clauses associated with S. If the L O G I D A T A + set of clauses P P , S is stratified, let us denote with P l , 9.., Prn one of the possible stratifications. Given an instance s of S, let ~-s = r be the set of ground facts associated with s. Let us define a set of facts for each stratum:
:r0 = f s ; f'i = 7~,(3ri-1), for i = 1 , . . . , m -
We define the
1;
semantics Yp of the program P over the instance s as follows:
- if the inverse r of the function r is defined over the set of facts 9rrn, let us call s t the instance of S such that s t = r we say t h a t s t is the semantics/~p of the program P over the instance s; - if the function r 1 is not defined over Urn, we say that the semantics f ' p of the program P over the instance s is undefined. There can be various reasons for which the semantics for a stratified program P over an instance s is not defined. They correspond to various extensions of the model and language with respect to the traditional Datalog framework, where the semantics of a program is always defined. - Since the language is not strongly typed, type mismatch may be generated by the program, thus bringing ill-typedness. Typing of the language represents an issue to be further investigated. - Recursion through oid invention can lead to the generation of infinite sets of facts. For example, given a class C, whose tuple type is (Crel : C), and the rule p : C(01D : X , Crel : Y ) *-- C(OID :Y, Crel : Z), the program made of this rule has clearly no model unless the class C is e m p t y in the input instance. - The presence of isa hierarchies and specialization clauses allows for multiple and inconsistent specializations of an object from a superclass to a subclass: this brings to non functional relationships from oid's to object values. Consider the following scheme:
40
CLASS person : TUPLE name:string END; CLASS husband ISA person : TUPLE wife:person END; RELATION marriage : TUPLE husband:person, wife:person END; Suppose we know all the persons and want to fill the class of the husbands, on the basis of the relation marriage, using the following rule:
husband(olD:X, name:H, spouse:Y)*-- marriage(husband:X, wife:Y), person(OID:X, name:H), person(oID:Y, name:W) The problem of inconsistent multiple specializations for the same object arises if persons with more than one wife are allowed in the input instance. In this case, the rule has clearly no defined semantics. - In a similar way, the presence of monovalued functions and functions clauses allows for multiple and inconsistent definition of a function over the same tuple: this brings to non functional relationships from tuples to function values.
5
Conclusions
This paper has presented the LOGIDATA+ language. Syntax and semantics of the language have been introduced. The most interesting issues of the language are related to the novel features of the LOGIDATA+ model, that are: complex structures; classes with oid invention and hierarchies; data functions and grouping constructs used as set constructors; stratified semantics with respect to negation and grouping rules. Some of the proposals, such as old-inventions and language typing, need to be further investigated. We claim that the introduction of Skolem functors, in the spirit of [5,12] would make the semantics of inventions truly declarative. Future work will be devoted to exploring the use of functors in the management of old-inventions. References 1. S. Abiteboul and S. Grumbach. A rule-based language with functions and sets. ACM Trans. on Database Syst., 16(1):1-31, January 1991. 2. S. Abiteboul and P. Kanellakis. Object identity as a query language primitive. In ACM SIGMOD International Con]. on Management o] Data, pages 159-173, 1989. 3. S. Abiteboul and V. Vianu. Datalog extensions for database queries and updates. Journal o] Comp. and System Se., 43(1):62-124, August 1991. 4. K. Apt, H. Blair, and A. Walker. Toward a theory of declarative knowledge. In J. Minker, editor, Foundations of Deductive Databases and Logic Programming, pages 89-148. Morgan Kaufmann, San Mateo, California, 1988. 5. P. Atzeni, L. Cabibbo, and G. Mecca. IsaLog: A declarative language for complex objects with hierarchies. In Ninth IEEE International Con]erence on Data Engineering, Vienna, 1993. 6. P. Atzeni, F. Ca~ace, S. Ceri, and L. Tanca. The LOGIDATA+ model. This volume.
41
7. C. Beeri. A formal approach to object-oriented databases. Data and Knowledge Engineering, 5:353-382, 1990. 8. L. Cabibbo and G. Mecca. Travel agency: a LOGIDATA+ application. This volume. 9. F. Cacace, S. Ceri, S. Crespi-Reghizzi, L. Tanca, and R. Zicari. Integrating object oriented data modelling with a rule-based programming paradigm. In ACM SIGMOD International Conf. on Management of Data, pages 225-236, 1990. 10. L. Cardelli. A semantics of multiple inheritance. Information and Computation, 76(2):138-164, 1988. 11. S. Ceri, G. Gottlob, and L. Tanca. Logic Programming and Data Bases. SpringerVerlag, 1989. 12. R. Hull and M. Yoshikawa. ILOG: Declarative creation and manipulation of object identifiers. In Sixteenth International Conference on Very Large Data Bases, Brisbane, pages 455-468, 1990. 13. J.W. Lloyd. Foundations of Logic Programming. Springer-Verlag, second edition, 1987. 14. S. Naqvi and S. Tsur. A Logical Language for Data and Knowledge Bases. Computer Science Press, Potomac, Maryland, 1989. 15. J.D. Ullman. Principles of Database and Knowledge Base Systems, volume 1. Computer Science Press, Potomac, Maryland, 1988.
Travel Agency: A LOGIDATA + Application L u c a C a b i b b o and Giansalvatore M e c c a Dipartimento di Informatica e Sistemistiea, Universit/t di Roma "La Sapienza" Via Salaria 113, 00198 Roma, Italy
Abstract. Expressive power and flexibility of the LOGIDATA+ model and language are explored. We analyze a program for travel agencies: the problem we consider is concerned with the construction of travels on the basis of the client's specifications. The program queries the database and generates a report with all the available choices in terms of transfers and aeeomodations. The scheme and the clauses use a wide range of language functionalities, as complex objects, object identifiers, classes, relations, functions, is-a relationships and reeursion.
1 Introduction The LOGIDATA + model, introduced in [6], is an object oriented data model with complex structures. It provides several constructs in order to organize data: *
relations, that are sets of tuples built by means of the record, set and sequence constructors; classes, essentially sets of objects, each of them associated with an object identifier (oid); each object may have a complex structure and isa hierarchies are allowed among classes;
9
functions, that associate values to tuples; both monovalued and multivalued functions are allowed.
The L O G I D A T A + language, presented in [5], is a declarative language capable of handling complex structures and objects. It is a suitable extension of ordinary declarative languages, such as Datalog [9], that allows for: 9
creation and management of oid's, through the notion of oid invention;
* grouping constructs used as set constructors for multivalued functions; 9
built-in predicates and functions;
43 9
negation in the body of rules.
The semantics proposed is deterministic and stratified with respect to negated atoms and multivalued functions. In this paper we present an application of the L O G I D A T A + model and language. The problem we focus on is concerned with the construction of travels based on a set of specifications supplied by a client of a travel agency. The client draws a list of towns he wants to visit, with related arrival and departure dates. Upon this, the application program queries the database and, if the specifications are feasible, it generates a report containing information on transfers and accomodations. Each transfer may be performed either by plane or by car. In the latter case, the client needs to rent a car in a rent-a-car agency. Accomodations will be provided by hotels. The database contains all the information about towns, hotels, flights and rental companies. The result we generate is a report for the client, in which are presented all the available options for him, that are: a list of hotels for each town in which an accomodation is needed; a list of the flights available for each Night transfer; a list of the rental companies where a car can be rented for each driving transfer. The paper is organized as follows: in section 2 the input scheme is described, along with the instance stored in the database; section 3 introduces the strategy of the program and a set of clauses and type declarations that define some preliminary transfbrmations; in section 4 the various components of the final report are analized; finally, in section 5 and 6 the creation of the travel and the generation of the report are presented.
2 Input scheme and instance The proposed scheme contains information on the structure of data permanently stored in the database; the relative instance - intuitively - describes a town connections' graph. The graph nodes are towns which represent possible travel destinations. Each town is associated with a hotel set, an airport set and a rent-a-car set; each rent-acar belongs to a rental company in agreement with our travel agency. Arcs of the graph are represented by objects of the class t r a n s f e r ; in this class all the existing links between towns are stored. Each transfer is associated with the departure ( f r o m ) and arrival ( t o ) town, that form a key for the class. A transfer may be either a f l i g h t _ t r a n s f e r , that is a set of flights offered by various air companies, or a d r i v i n g _ t r a n s f e r , that is a transfer "on the road", for which the client needs to rent a car. As you can see in the scheme, there is an "is-a" link between the class t r a n s f e r and the two more specific classes flight_transfer and d r i v i n g _ t r a n s f e r . The latter are disjoint classes that wholly cover the father. We state some simplifying hypothesis on the problem domain. For example, we suppose that rented car daily cost is fixed for each rental company, and it does
44 not depend from the particular rent-a-car and from car models. Futhermore, we
suppose that the attribute name is a key for the class t o w n . The scheme is described by means of the LOGIDATA+ Data Definition Language (DDL) [6], that is quite self-explanatory.
TYPE TYPE TYPE TYPE TYPE TYPE
d a t e = TUPLE d , m , y : i n t e g e r END; time = TUPLE h,m : i n t e g e r END; category = string; cost = integer; mileage = integer; airport = string;
CLASS toMn : TUPLE name : s t r i n g ; state : string; a i r p o r t _ s e t : SET OF a i r p o r t ; h o t e l _ s e t : SET OF h o t e l ; r e n t - a - c a r set : SET OF r e n t - a - c a r
END; CLASS h o t e l
: TUPLE name : s t r i n g ; category : category; d a i l y _ c o s t : cost
END; CLASS r e n t - a - c a r
: TUPLE name : s t r i n g ; company : rental_company
END; CLASS rental_company : TUPLE name : s t r i n g ; d a i l y _ c o s t : cost
END; CLASS t r a n s f e r
: TUPLE from, t o : toNn
END; TYPE schedules = SET OF TUPLE id : string; air_con~any : s t r i n g ; departure, a r r i v a l : time; cost : c o s t ; END CLASS f l i g h t _ t r a n s f e r ISA t r a n s f e r : TUPLE from a i r p , t o _ a i r p : a i r p o r t ; schedules : schedules
END;
45
CLASS d r i v i n g _ t r a n s f e r ISA t r a n s f e r mileage : mileage
: TUPLE
END;
An istance fragment of this scheme portion may be as follows:
CLASS town OlD #1:1
name 'Rome'
state 'Italy'
#t2
'Milan' 'Paris' 'Verona' 'Venice'
'Italy' 'France' 'Italy' 'Italy'
#t3 #t4 #t5
airport set {'Leonardo da Vinci', ' Ciampino' } {'Linate'0 'Malpensa')
{'De Gaulle', 'Orly'} {} {'Marco Polo')
hotel set {...)
rent-a-car set {...}
{ # h l , #h2, #h3} {...) {...} {#h4, #h5, #h6}
(#reel, #rat2) {...) {...} {#rac3, #rac4)
CLASS hotel OlD
name ' Mitano Hilton' 'Grand Hotel Duomo' 'Raffaello' 'Danieli' ' Metropole' 'Londra Palace'
#hl #h2 #h3 #h4 #h5 #h6
category 'lux'
'lUX' 'first' 'Iux' ' first' 'first'
daily cost 350000 280000 270000 420000 250000 180000
CLASS rent-a-car OlD #rac 1 #rac2 #rac3 #rac4
name 'Milano Car' 'Euro Rental' 'Rent-a-car' 'Euro Rental'
company #rco 1 #rco 2 #rco2 #rco3
CLASS rental company OID #rco I #rco2 #rco3
name 'HERTZ' 'AVIS' ' ItalyByCar'
daily cost 50000 80000 6OOO0
CLASS transfer OlD #trl #tr2 #tr3 #tr4 #tr5 #tr6
from #1:1 #t5 #t2 r #1:3 #t4
to #1:2 #tl #t3 #t4 #t2 #t5
46
CLASS flight_transfer OlD
from_airp
to airp
Itrl
'Linata'
#tr2
'Laonardo de Vinci' "Marco Polo'
#tr3
'Linate'
~ da Vinci' 'De Geulle'
~lPtr5
'De Gaulle'
' Linate'
schedules id {('AZ061' ('AZO47' {('AZ214' ('AZ174' {('AZ227' ('AF829' {('AZ226' ('AF828 ~
air company 'Alitalia' 'Alitalla' 'Alita|ia' 'Alitalia' 'Alitalia' 'Air France' 'Alitalia' 'Air France'
departure 08:00 19:00 08:00 21:05 09:00 19:55 07:15 19:50
arrival 09:05 20:05 09:05 22:10 10:35 21:20 08:50 21:15
co=t 180000) 186OOO) } 156000) 141000) I 150000} 180000)} 1500001 176000)}
CLASS driving_transfer
H~176 I m'"' #tr4 #tr6
164 120
!
We shall now comment on the tabular description used. First of all, note how for every class, a column o s has been introduced. It represents the object identifier for the elements of that class. The values of the oid's have been expressed by means of the conventional format #XXnn. We recall that oid's are not visible to users, namely we can use them only as indirect references to elements of classes. It is worth noting that oid's are not constants of the language like elements of base types. We use the proposed format only with the purpose of highlighting the semantic links between objects. For objects that belong to more than one class (i.e. elements of subclasses in isa hierarchies), the corrispondent class table shows the values relevant to that class and not shown in its superclasses, besides the object identifier; the inheritance of the other properties is clearly understood. For the sake of space, values for the types d a t e and t:J.rae have been compacted. Only the information needed to satisfy the proposed specifications are expressed, so that insignificant values are shown with dots ( ' . . . ' ) or left out. Let us consider the following scheme definitions:
TYPE j o u r n e y = TUPLE date : date; transfer : transfer END;
47 RELATION spec : TUPLE id : string; client : string; hotel_category : category; stages : SEQUENCEOF TUPLE town: s t r i n g ; a r r i v a l , d e p a r t u r e : date END END; CLASS t r a v e l :
TUPLE spec_id : s t r i n g ; journeys : SEQUENCE OF j o u r n e y ;
END;
The relation s p e c appears in the scheme: it is used for the client's specifications data entry. The class t r a v e l appears too: reasonably travels invented on the basis of client specifications will be permanently stored in the database.
3 Preliminary transformations We query the database by means of a program application over the current instance. The program consists of a structural part and a behavioural part, namely of a set of type declarations along with a set of clauses. In this and the following sections we comment on the various parts of the program. We have chosen to keep each data definition close to the related clauses in order to make the transformations more readable. From this point of view, a client's travel specification may be easily feeded in with a ground fact such as:
spec (id: 'Rossi/45', client: 'Mario Rossi', hotel_category: ' f i r s t ' , stages: { (town: 'Rome', arrival: 10/12/91, departure: I0/12/91), (town: 'Milan', arrival: 10/12/91, departure: 13/12/91), (town: 'Paris j, arrival: 13/12/91, departure: 13/12/91), (town: 'Milan', arrival: 13/12/91, departure: 15/12/91), (town: 'Verona', arrival: 15/12/91, departure: 15/12/91), (town: 'Venice', arrival: 15/12/91, departure: 19/12/91), (town: ,Rome', arrival: 19/12/91, departure: 19/12/91) )). Note that facts like this are allowed in programs, since the language does not require disjointness between the input and the output schemes. The hypothesis that object identifiers are not visible to users is one of the LOGIDATA + model features; this implies that input and output of data should occur only by means of value based (visible) relations (i.e. relations with no oid's). This is the reason why the specifications are modeled by means of the relation s p e c , that has a value key i d .
48 In the following sections we will often resort to the "dot" operator, applied not only to tuples, as defined in [5], but also to oid's. Given a variable X that represents an oid of a class c, and an attribute A appearing in the type of C, the term X. A refers to the value of the attribute A in the object associated to the old corresponding to X. The program realizes an input-output transformation - with the output scheme obtained from the input one along with the program type declarations - through the use of a set of intermediate transformations. Let us analyze them. The first trasformation performs the construction of the class specifications, that is a more suitable representation of information stored in the relation s p e c . This class will let us manipulate specifications directly by means of the associated object identifiers: this is a helpful feature of the language. In order to build a class from the original relation, we need to invent an object for each tuple in the original relation. The function b u i l d e r performs the construction.
TYPE stage = TUPLE town : town; arrival, departure : date
END;
: TUPLE id : s t r i n g ; client : string;
CLASS s p e c i f i c a t i o n s
hotel_category : category; stages : SEQUENCE OF stage END; s p e c i f i c a t i o n s (OlD:NEW, i d : I D , c l i e n t : C , hotet_category:HC, stages:ST) 30000$,DBL1 ( w o r k e r ( X ) ) , worker (W. [job :taxi-driver] ).
If after the execution of the deletion there is not a taxi-driver stored, the postcondition fails and the update has a null overall effect, otherwise one person earning more than 300005 is removed from the database. Up to this point we presented updates whose syntax is much similar to ordinary logic goals. More generally, updates will be organized in the form of rules
64 which implement complex manipulations. Rules are activated calling the execution of the corresponding head predicates. The head predicate of an update rule may include variables in its arguments which are used to supply input data to the transaction - note that, since oid's are not directly visible to the user, input data can not include oid's. Moreover, once an update predicate has been defined (writing a rule in which it occurs as the head), it can be used in the body of other update rules. In particular, the head update predicate can be used in the body of some rule transitively associated with it, henceforth obtaining a set of recursive update rules. In general, the execution of a set of update rules proceeds as follows. One of the rules associated with the update predicate is activated nondeterministically, and its body is executed. On fail (when some guard condition is not satisfied), another update rule associated with the called update predicate is tried, and so on until no more executions can be activated. The possibility of using recursion in programming the updates gives our language a good expressivity. The following examples should give the reader a hint on this.
Ezample ~. Assume we have decided to raise the salary of a category of .workers of a certain amount for each son. This can be accomplished by a recursive update, as follows: r a i s e ( J , A ) ~ - - w o r k e r ( X , [ j o b : J , s o n s : S ] ) , S ~ { } , p e r s o n ( Y ) , Y E S, MODl(worker(X,[salary:Sal,sons:S1])l
[salary:Sal+A,sons:Sl-{Y}]), raise(J,A),MODl(.orker(X,[sons:S2])l[sons:S2U{Y}]). raise(J,A) ~-~(.orker(X,[job:J,sons:S]),S ~ {}),SKIP(). Intuitively, the update works s follows: first a worker with at least one son is searched for; if it does not exist, then the transaction is terminated; otherwise, one of his/her sons is selected; next, this son is temporarily deleted from those of the selected worker, and the salary is raised by the requested amount; the transaction is recursively called to perform the same set of operations again (notice that the next group of operation will process one worker having some sons, possibly the one processed in the current step); on exit of the recursive call, the set of sons of the currently manipulated worker is reset to the correct value, adding back again the previously deleted sons. For instance, if we want to raise the salary of the taxi-drivers of 10005 for each son, then the transaction can be activated using § 10005). We point out that we have decided to treat updates as denoting pure "dbstate transformations", and therefore, update literals do not produce bindings. Before closing this section, it is worth giving one example regarding integrity enforcement. Consider, for instance, the classes s t u d e n t and c o u r s e of Fig. 2. The execution of a delete operation +---DEL 1 ( t o u r s e(X)) could cause an integrity error to arise, if the removed course were followed by some student (dangling reference). It is interesting to note that this situation can be easily managed using our update language. For instance, the following update could be executed
65 by the system in the place of ,--DELt(course(X)) , which guaratees referential consistency: ~- course(X) ,DELl (course(X)) ,MODqb ( s t u d e n t ( Y , [follows:Z] [ [folio,,: Z-{X}] ) ). 3
A Model
for Complex
Objects
with
Identity
For a formal definition of the update languages we shall refer to a simple d a t a model, which we call CO (a short hand for Complex Objects), deriving from the model of reference of Logidata+. CO is a purely object-oriented database model as the only allowed structure construct is the class. A CO class is a set of objects, complex entities for which value equality does not imply identity this is implemented by means of object identifiers, which are not visible to the user. Also, generalization hierarchies among classes can be built by means of is-a relationships with inherited properties. It should be said that several concepts in this models derive from analogous concepts in the L o g i d a t a + model with slight differences. However, for sake of convenience, in this section we completely present the CO model. Then, in the following sections, we will formally present the update language for this model. We fix a countable set .A of attribute names and a finite set /3 of base type names; associated with each B G B there is a set of base values v ( B ) ; the sets of base values are pairwise disjoint. A CO scheme is a triple S = (12, TYP, ISA) with associated a set TYPBS(S) of type descriptors, where: - C is a set of symbols called class names; - A type descriptor (or simply a type) of S is one of the following: 1. if B is a base type name in B, then B is a type of S; 2. if C is a class name in 12, then C is a type of $ (note t h a t classe names are types so that classes can be used in constructing other types, which may therefore refer to the objects in the classes). 3. if ~- is a type of S, then {r} is also a type of S, called a set type; 4. if rl,...,~-h, with k > 0, are types of $ and A 1 , . . . , A k are distinct attribute names in .A, then [A1 : v , , . . . , A k : vk] is also a type of S (called a tuple type) in which the order of components is immaterial; 5. {} and [] are types of S, called the empty set type and the empty tuple type respectively 3. is a function t h a t associates to each symbol in C a tuple type of S (that is, the top level constructor for classes is the tuple one); - ISA is a partial order over C, with t h e condition that if C1 ISA C2, then TYP(C1) is a refinement of TYP(C2) according to the definition given below.
--
T Y P
The definition of refinement for tuple types expresses the idea t h a t a type 7- is a refinement of another type 7-' if ~- has at least the components of r ' , and possibly some more. It can be formally defined as follows. 3 They are useful for technical reasons.
66 A type r is a refinement of a type r ' (in symbols r - 1, be a sequence of literals such that ;31 is a sequence of static literals and c~j a sequence of basic dynamic literals, for 1 < i < n + 1, 1 < j < n. Then, we say that the goal ~ /~ is applicable to an instance s of S if, for 1 < i < n and So = s, there exists a valuation ei of ;3ie, . . . e i - 1 in si-1, such that ; 3 i + 1 e l . . . e l is true in si, where si is a potential solution for the application of ~ c,i e l . . . e l to si_,. If ,---/~ is applicable, there is associated to it a notion of set of potential solutions for the application 4-- # to s. Thus, for each set of dynamic literals in the sequence, the set of static literals preceding t h e m are evaluated in the current state; if t h e y are true the corresponding bindings are passed to the dynamic literals that are executed if the static literals following them are true in a potential solution of their application - in this case, it becomes the current state. Let P be a / / C O program for S and G = ~ L 1 , . . . ,L,~ be a goal for P; an ezpansion G* of G with respect to P is the last element of a sequence of goals G = Go, G 1 , . . . , Gk = G ~ such that: if Uj is an update literal occurring in Gi-1 (i > 0) and there is a rule R in P such t h a t Uj and the head of R unify with unifier a, then Gi is obtained from Gi_ 1 by replacing the literal Uj with the body of R, and by applying cr to the obtained goal. If G * does not contain update
73 literals, then we say that it is a full expansion of G with respect to P. Note that every full expansion can be viewed as a goal of the form *---p, where p is a sequence as defined previously. Finally, let s be an instance of S, if there exists a full expansion G ~ of G with respect to P that is applicable to s, then a (possible) result for the application of P U ~G} to s is a potential solution for the application of G* to s, otherwise the result is s itself. T h e o r e m 4. Let s be a coherent instance of S, then a result for the application of P U ~G~ to s is a potential instance of S.
Proof. If there does not exist a full expansion of G with respect to P that is applicable to s, the claim is trivial. So, let G* be such a goal; it has in general the form ,--- /31, a1,/32,...,/3m-l,C~,n,/3m+l, m > 1, where /3i is a sequence of static literals and c~i a sequence of basic dynamic literals, for 1 < i < m. Since G* is applicable, then by definition, the application of G ~ to s corresponds to the application of the goal *---B 1 , . . . , B,~, where, for 1 < i < n, Bi is a workable dynamic literal of the form Bjk01 ...0j, where Bjk belongs to a i , for 1 < j < m, and 8 1 , . . . , 8j are the valuations of the positive object literals preceding c~j in G *. Therefore, it is sufficient to show that the potential solution for the application of a workable goal of basic dynamic literals to an instance of S is a potential instance of S. Consider the definition of potential solution for the application to s of a goal G of this form, and note that L e m m a 3 is still valid if the argument of TD is a potential instance instead of a coherent instance; then, the claim follows by L e m m a 3 and by induction on the number of basic dynamic literals in G. [] It should be noted that: (i) for simplicity, but by abuse of notation, the same punctuation symbol "," is used here with two meanings; it stands for sequential composition if it preceeds or follows a dynamic literal, it stands for logical ' a n d ' otherwise; and (ii) in general the result of the application of an update goal to a coherent instance is not a coherent instance. Before closing this section, we point out that, in verifing for applicability of a sequence of literals, some problems may arise. In particular it may be the case that at a certain point an object literal needs to be evaluated but is not closed, or that a potential solution for the application of a basic dynamic literal needs to be found but the literal is not workable. To capture this notion we say that a generic literal is feasible i f : (1) it is an object literal and it is closed, (2) it is a built-in literal and it is ground, (3) it is a basic dynamic literal and it is workable; and that a goal is always feasible if it is never the case that in verifing for applicability, at some point all the literals that need to be computed are not feasible. It turns out that this property can be achieved by means of syntactical restrictions, as stated by the following result. We say that a variable is left-bound if it occurs to the right of a positive object literal, in which the same variable occurs in a closed argument; and that a goal (a rule) is safe if every variable that occurs in a function term, or in a built-in literal, or in an update literal, (either occurs in the head or) is left-bound. A program P is safe if every rule in P is safe.
74 P r o p o s i t i o n 5. If P and G are safe, then every full ezpansion of G with respect
to P is always feasible. Proof. We prove the claim by showing that a safe goal is always feasible and that if P and G are safe, then any expansion of G with respect to P is safe. By way of contradiction assume that a goal G' is safe and, in verifing for applicability, at same point a literal Lj needs to be computed and it is not feasible. By definition, it means that a variable, say X, occurs in Lj (if Lj is a built-in literal) or in a function term occurring in Lj (if Lj is an object literal or a basic dynamic literal). Since the goal is safe, X is left-bound and therefore it also occurs in a closed argument of a positive object literal, say Lk, occurring to the left of Lj in G r. By definition, when Lj needs to be computed, Lk has been already evaluated and so the valuation of Lk (that is ground for X ) has been applied t o Li, and therefore such a variable does not exist - a contradiction. Now, let G' be a safe goal and G" be a goal derived from G I and a safe rule R. Then, by the safety conditions, each variable which is not left-bound occurs in the head of R and therefore it becomes left-bound in G", it follows that G" is safe. From this fact, if G* is an expansion of G with respect to P, by induction on the length of the sequence of goals computed in deriving G, it follows that G* is safe, and so the claim follows, n Actually, some of the safety conditions above could be relaxed, but in this form they are easy to check and also, they are useful in defining a simple interpreter, as shown in Section 6.
6
Implementation
Issues
In this section we give some hints on how a I2CO program can be implemented. It is not our intent to define a complete interpreter, we rather present some results that can be used in a practical implementation. Let S be a CO scheme; by the given semantics, an interpreter for a / ~ C O program P for S and a goal G for P consists of a procedure that takes as input P, G and an instance s for S, and attemps to construct a full expansion of G with respect to P that is applicable to s. We say that a computation of P U ~G} with respect to s is an attempt to construct such an expansion. A computation can be implemented by means of a sequence of pop and push operations in the stack of five-tuples < G~., s~, r g~., 5~ >, which we call states of the computation, where: G~ is a goal, sx is a potential instance (the current instance of the state), r is a set of substitutions, 7~. is a set of rules in P, and ,S~ is a set of instances of S. The stack is initialized by pushing in it the initial state < G, s, r r >, The generic step of the computation consists in examining the leftmost literal, say Lj, of the goal in the state at the top of the stack, which we call the top state and denote with < Gt, st, ~t,7~t,,St >. Then, if one of the following conditions is verified, the corrisponding operations are performed, otherwise a sequence of pop occurs until the leftmost literal in Gt is
?5 a non built-in literal (in the sequel, if G is a goal and L a literal in G, G - L denotes the goal obtained by eliminating L from G). -
-
-
- -
if Lj i s a positive object literal and there exists a valuation 8 of Lj in st such that 0 r Or, then: (1) Ot := Ot U{$}, (2) push < (Gt - Lj)O, st,@,@,@ > in the stack; if Lj is a static literal different from a positive object one and it is true in st, then push < Gt - Lj, st, @,@,@> in the stack; if Lj is an update literal and there is (a variant of) a rule R in P (in such a way that R does not have any variable which already appears in Gt), such that R ~ 7~t and Lj and the head of R unify with unifier a, then: (1) Rt := 7~t U {R}, (2) push < G', st, @,@,@> in the stack, where G' is the goal derived from Gt and R using or; if Lj is a basic dynamic literal and there is a potential instance s' E TLj(st) such that s' r &, then: (1) St := St U {s'}, (2) push < Gt - Lj, s', @,@> in the stack.
The computation ends when the stack is empty (in this case we say that the computation is failed) or when a point is reached where Gt is empty (in this case we have a successful computation). T h e o r e m 6. / f there emists a successful computation of P U {G} with respect to s, then (i) there is a full ezpansion of G with respect to P that is applicable to s, and (ii) st is a result of the application of P U {G} to s. Proof. Consider a successful computation of P U { G } and assume that the length of the stack s of this computation is l + 1. We can build a g o a l G t inspecting the goals G, Gt, . . . , Gi in the elements of s as follows: initially Go = G, then, for i = 1 , . . . , 1, if G~ is obtained from Gi-1 and a rule R using an unifier a, then Gi is also obtained from Gi-1 and R using cr (in fact, by induction on l, it is possible to show that ~ is also an unifier of G and R), otherwise Gi = Gi-1. By construction, for 1 < i < l, the goals Gi are all expansions of G with respect to P. Moreover, the final goal Gz is a full expansion, that is it does not contain update literals, since otherwise, by the given computation and by construction of GI,Asuch literals would be also in Gz, which instead is empty. Now we claim that Gt is applicable to s. In fact, by construction, Gz contains all the static literals that are examined during the computation and, since it is successful, they are all true in the current instances in the states of the computation. But the current instance in a state of the computation is just a potential solutions for the application of the last basic dynamic literals computed, that i~. the first basic dynamic literal which appears to the left of each static literal in Gt. So, for each static literal Li in Gz, let sk be a potential solutions for the application of the first basic dynamic literals occuring to the left of L~; we have that: (i) if Li is an positive object literal, then an instantiation of L~ with the valuation of the previous positive object atom in true in sk, (ii) Li is a static literal different from a positive object literal and an instantiation of it is true in sk. Then, the claim
76 follows by induction on the number of literals in Gz. In particular the final state st is a potential result for the application of the rightmost basic dynamic literal in G, and therefore, by definition, it is a result of the application of P U {G} to s. [] In general, with a procedure as above, termination is not guaranteed because of recursion, but an algorithm like that is simple and easy to implement. In drawing a computation it may be the case that the leftmost literal of the top goal is not 'computable', because, for instance, it is a basic dynamic literal and it is not workable. We say that a computation flounders if at same point, the leftmost literal of the goal in the top state is not feasible. Again, this situation can be avoided by means of syntactical restriction, as stated by the following proposition. P r o p o s i t i o n 7. I / P and G are 8ale, then a computation/or P LJ {G} never flounders.
Proo/. By way of contradiction assume that G is safe and, during a computation, the leftmost literal Lj of the goal Gt in the top state is not feasible. By definition, it means that a variable, say X, occurs in L i (if Lj is a built-in literal) or in a function term occurring in Lj (if L i is an object literal or a basic dynamic literal). Since G is safe, (a renaming of) the variable X is left-bound and therefore it also occurs in a closed argument of a positive object literal, say Lk, occurring to the left of Lj in G. By the given computation of P U {G}, if the leftmost literal of Gt is L.r it means that Lk has been already eliminated from Gt and the valuation of Lk (that is ground for X) has been applied to all the literal of Gt, therefore such a variable does not exist - a contradiction. [] From a practical point of view, several improvement can be made to the procedure described above: for instance incremental instances can be used at each step instead of entire instances and opportune valuations for the object literals can be chosen looking ahead in the goal. We will not discuss further this point because it is beyond of the scope of this paper. 7
Conclusions
In this paper, extended update operations have been studied in the framework of a rule based non-deterministic update language for complex object databases. The language, called HCO, is built around a set of basic update operations which, we argue, correspond to a reasonable set of basic manipulations of data stored in a complex object database. The managed data are always in the form of objects, and thus identity on values do not imply identity (this is obtained using object identifiers). This fact had strongly impacted on the choice of basic update operations. Basic update operations can be used to build complex transactions, which are declared in the form of rules, and which are activated by calling the corresponding head literal. The defined update literals can in turn be used in other update
77 rules bodies, even recursively. Thus, the language has a procedure-call based (i.e., top-down) computational model, as opposed to other languages which use a b o t t o m - u p model [6, 14]. Rule bodies are executed strictly from left to right. In rule bodies, conditions can be specified which serve the two purposes of controlling computation a n d constructing unifications. The language is non-determinstic in the following sense: (i) basic insertions semantics uses oid invention; (ii) three out of seven basic u p d a t e operations are non deterministic, since they apply just to one of the selected objects, chosen arbitrarily; (iii) all literals in conditions can be partially specified; (iv) the non basic u p d a t e literals call mechanism is non deterministic in that if there is more than one applicable rule, one of t h e m is chosen and executed. To conclude, let us briefly discuss some further points. We notice t h a t to allow more complex conditions in rule bodies would improve language naturalness. In particular, it should be useful to take advantage of the full power of logic programnfing, using (ordinary logical) goals to activate complex enquiring (and unification building) transactions on the database. This extention of HCO can be carried out without so much difficulty. Other issues related to the design of a top-down oriented updated language for complex object databases merit attention. In particular, the relationships between update transaction execution and the presence of (inherent and/or defined) integrity constraints is to be studied. Second, the expressibility of the language is to be investigated. These points will be the object of future research activities.
References 1. S. Abiteboul. Towards a deductive object-oriented database language. Data and Knowledge Engineering, 5:263-287, 1990. 2. S. Abiteboul. Updates, a new frontier. In ICDT'88 (Second International Conference on Data Base Theory}, Brutes, Lecture Notes in Computer Science J26, pages 1-18, Springer-Verlag, 1988. 3. S. Abiteboul and G. Grahne. Update semantics for incomplete databases. In Eleventh International Conf. on Very Large Data Bases, Stockolm, 1985. 4. S. Abiteboul and S. Grumbach. A rule-based language with functions and sets. A C M Trans. on Database Syst., 16(1):1-30, March 1991. 5. S. Abiteboul and R. Hull. IFO: a formal semantics database model. ACM Trans. on Database Syst., 12(4):297-314, December 1987. 6. S. Abiteboul and P. Kanellakls. Object identity as a query language primitive. In ACM SIGMOD International Conf. on Management of Data, pages 159-173, 1989. 7. S. Abiteboul and V. Vianu. Datalog extensions for database queries and updates. Journal of Comp. and System Sc., 43(1):62-124, August 1991. 8. S. Abitebout and V. Vianu. Procedural and declarative database update languages. In Seventh ACM SIGACT SIGMOD SIGART Syrup. on Principles of Database Systems, pages 240-250, 1988. 9. P. Atzeni and R. Torlone. Efficient updates to independent schemes in the weak instance model. In ACM SIGMOD International Conf. on Management of Data, pages 84-93, 1990. SIGMOD Record 19(2).
78 10. P. Atzeni and R. Torlone. Updating relational databases through weak instance interfaces. ACM Trans. on Database Syst., 17(4):718-746, December 1992. 11. F. BancUhon, D. Maler, Y. Sagiv, and J.D. Ullman. Magic sets and other strange ways to implement logic programs. In Fifth ACM SIGACT SIGMOD Syrup. on Principles of Database Systems, 1986. 12. F. BancUhon and R. Ramakrishnan. An amateur's introduction to recursive query processing strategies. In A CM SIGMOD International Conf. on Management of Data, pages 16-52, 1986. 13. F. BancUhon and N. Spyratos. U p d a t e semantics of relational views. ACM Trans. on Database Syst., 6(4):557-575, 1981. 14. F. Cacace, S. Cerl, S. Crespi-Reghizzi, L. Tanca, and R. Zicari. Integrating object oriented d a t a modelling with a rule-based programming paradigm. In ACM SIGMOD International Conf. on Management of Data, pages 225-236, 1990. 15. W. Chen and D.S. Warren. C-logic for complex objects. In Eigth ACM SIGACT SIGMOD SIGART Syrup. on Principles of Database Systems, pages 369-378, 1989. 16. C. de Malndreville and E. Simon. Modelling non-deterministic queries and updates in deductive databases. In Fourteenth International Conf. on Very Large Data Bases, Los Angeles, pages 395-406, 1988. 17. R. Fagin, J.D. Ullman, and M.Y. Vardi. On the semantics of updates in databases. In Second ACM SIGACT SIGMOD Syrup. on Principles of Database Systems, pages 352-365, 1983. 18. K.B. Hull and C.K. Yap. The format model: a theory of database organization. Journal of the ACM, 31(3):518-537, July 1984. 19. G.M. Kuper and M.Y. Vardi. A new approach to database logic. In Third ACM SIGACT SIGMOD Syrup. on Principles of Database Systems, pages 14-15, 1984. 20. S. Manchanda and D.S. Warren. A logic-based language for database updates. In J. Minker, editor, Foundations of Deductive Databases and Logic Programming, pages 363-394, Morgan Kauffman, Los Altos, 1988. 21. S.A. Naqvi and R. Krishnamurthy. Database updates in logic programming. In Seventh ACM SIGACT SIGMOD SIGART Syrup. on Principles of Database Systems, pages 251-262, 1988. 22. L. Palopoli. Testing logic programs for local stratification. Theoretical Computer Science, 103(2):205-234, 1992. 23. D. Sacc~ and C. Zaniolo. The generalized counting method of recursive queries for database. Theoretical Computer Science, 62(3):187-220, 1987. 24. M. Winslett. A framework for the comparison of update semantics. In Seven& ACM SIGACT SIGMOD SIGART Syrup. on Principles of Database Systems, pages 315-324, 1988. 25. C. Zaniolo. Database relations with null values. Journal of Comp. and System Sc., 28(1):142-166, 1984.
T a x o n o m i c R e a s o n i n g in L O G I D A T A + Domenico Beneventano 1 and Sonia Bergamasehi 1 and Claudio Sartori 1 Alessandro Artale 2 and Francesca Cesarini 2 and Giovanni Soda s 1 CIOC-CNR- Universita di Bologna - Italia 2 Dipartimento di Sistemi e Informatica - Universita di Firenze - Italia A b s t r a c t . Taxonomic reasoning is a typical inference task performed by many AI knowledge representation systems. We illustrate the effectiveness of taxonomic reasoning techniques as an active support to knowledge acquisition and schemas design in the advanced database environment LOGIDATA +, supporting complex objects and a rule-based language. The developed idea is that, by extending complex object data models with defined classes, it is possible to infer ISA relationships (i.e. compute subsumption) between classes on the basis of their descriptions. From a theoretical point of view, this approach makes it possible to give a formal definition of consistency to a schema, while, from a pragmatic point of view, it is possible to automatically classify a new class in the correct position of a given taxonomy.
1
W h a t is Taxonomic Reasoning?
Taxonomic Reasoning is an inference technique, introduced by the object-centered knowledge representation systems, developed in the Artificial Intelligence research area from the KL-ONE model [BS85], which permits the automatic classification, i.e. determination of the precise place for a class in a given taxonomy. A taxonomic reasoner finds all the isa relationships between a new class description and the classes' taxonomy already given, by discovering the implicit isa relationships hidden in the classes' descriptions. These systems propose to model intensional knowledge by means of the so-called terminological logic languages [PATEg0] which permit a class structure (type) to be described by a composition of terms to which a precise extensional semantics is associated. Further, classes can be distinguished as primitive classes, where the class structure is interpreted as a set of necessary conditions and defined classes, where the class structure is interpreted as a definition, i.e. a set of necessary and sufficient conditions. Thus, the extension of a defined class corresponds to the domain object set whose structure conforms to that description. In this way, subsumption relationships between classes can be computed by syntactically comparing class descriptions in a fashion similar to subtype relationship c o m p u t a t i o n [CARDS4] [LRV88] [LR89a] and implicit isa relationships can be discovered. Unfortunately, it has been proved that subsumption computation can give rise to tractability problems for m a n y developed languages [BL84] [BL87] [NEBE90] [FATE89] [NEBE90a] [DHLMNN91] [DLN91] [SCH89] [NEBE88] and particular attention must therefore be given to studying the relationships existing between
80 languages expressive power and the related algorithms' complexity, in order to obtain efficient systems. The main result has been obtained for languages which not allow cyclic class descriptions in [DLNN91] by precisely individuating the boundary of tractable languages. Further, [NEBE91], has dealt with languages allowing cyclic class descriptions. The semantics of defined classes is the basis for taxonomic reasoning and has effect on both intensional and extensional levels: -
-
a class can be automatically recognized as subsumed by a defined class; an individual can be automatically recognized as a member of a defined class.
For example, without any world knowledge, we can determine that the class Person subsumes the defined class of those persons that have only friends among doctors" : ( Person w i t h e v e r y friend isa Doctor) which in turn subsumes the class ( Person w i t h e v e r y friend isa (Doctor w i t h a speciality is surgery)) and any object that is a person and whose friends are all doctors can be automatically recognized as a member of the more specialized class described above. Further, any object that is a person and whose friends are all doctors with a speciality in surgery, only if the last described class is defined, can be most precisely recognized as a member of the last class. Traditionally database models assume a class description as a set of necessary conditions, to be satisfied by any individual belonging to that class: the individual will be checked and manually inserted in the class. In addition, only the ISA relationships explicitly declared (and their transitive closure) are known. This semantics is captured by primitive classes. Notice t h a t defined classes capture the semantics of database views. It is the authors' opinion that extending complex object data models semantics by defined classes can be profitable for many database research topics as we argue in the following. The effectiveness of taxonomic reasoning for supporting schema design has been shown in previous works on conceptual models [BCST89] [BS92]; we can here summarize some advantages: 1. the isa relationships which can be inferred from class descriptions are made explicit; in other words, the user's taxonomy is enriched with implicit isa relationships; 2. the user isa relationships are checked with respect to the subsumption relationship; 3. the schema consistency is checked by discovering ISA cycles and incoherent classes (i.e. classes with always empty extension); 4. the schema can be transformed into a minimal form where the redundancies with respect to inheritance are removed.
81
Results 2. and 3. have already been achieved in Object Oriented Database Systems (OODB) [LRV88] [LR89a] by computation of the refinement relationships. However, in spite of the similarity of syntactic type checking techniques, the purpose is quite different. In fact, the refinement computation provides a passive consistency check on types, as the relationships computed are all the possible isa relationships between classes. The subsumption algorithm, if it is complete, has a more active role: it computes all ISA relationship which are implied by user's descriptions, even if not explicitly stated (1.) and allows computation of the minimal description of a class with respect to specialization ordering (4.). Thus, the more active role of building a minimal class taxonomy can be played. Furthermore, the relevance of this technique for other main topics in database research, such as recognition of objects and query validation as well as optimization [BGN89] [BBMR89] is outstanding, and will be briefly explained in section 2. The present work applies Taxonomic Reasoning to the LOGIDATA + model, but is also appliable to many popular complex object models such as [KV84] [LRV88] [AK89] [LR89a]. As explained above, taxonomic reasoning requires an extended semantics with respect to the tradition of database environment. For this reason, our reference model LOGIDATA* extends the LOGIDATA + model as follows: - defined class semantics; - set type with cardinality boundaries. By the second extension the knowledge about cardinalities, which is usually expressed in database models as an integrity constraint, can be integrated in the object description and hence used for consistency check.
2
Related works
The related works to be considered come from both the database and the AI areas. We can identify a first group of works dealing with conceptual schema validation (with some contribution based on subsumption) and a second group of works exploiting subsumption for other database research topics. Most of the works of the first group differ substantially from the author's approach since they do not consider defined classes [AH87] [AP88b] [DBL89] [LR89a] [LRV88]. In this perspective, the main activity is to check concept description consistency with respect to the explicit given specialization ordering. Our approach, together with [AK86] [FS86] [BCST89] [DD89] [BS92] provides a more active role, allowing computation of the specialization ordering on the basis of concepts descriptions. In particular, in [BS92] the authors, by extending semantic models with defined classes and exploiting taxonomic reasoning, propose a general formal framework for the validation/restructuration of schemas. In this work, taxonomic reasoning techniques are extended to deal with the new expressive capabilities of complex object data models, such as object identifiers, sets, sequences and cyclic definitions (in the second paper). The capability of dealing
82 with both defined classes and cyclic definitions takes hints from [NEBE91] and [BN91]. The other important group of works includes the application of subsumption computation to instances validation, instances recognition and query processing [BBMR89] [BGN89] [Brar The novel feature is that DDL and DML are identical, thus providing uniform treatment of data objects, query objects and view objects. The classification algorithm finds the correct placement for a query object in a given object taxonomy and the fundamental criterion for this placement is the subsumption relationship between two object classes (union of the instances of the descendant object classes satisfy the query). In [BGN89] the proposed model CANDIDE presents, by a n6tation more familiar to the database researcher, an extension of KANDOR [PSS4] [PS86] (a Frame Description Language, or FDL) representing standard data types of database environments (range, set, composition). In [BBMR89], the proposed model, CLASSIC, has a notation more in the FDLs tradition, query processing is tractable as the subsumption algorithm is polynomial and complete. Furthermore, the paper shows how, thanks to the semantics of defined concepts, recognition of an object of an application domain as an instance of a class is automatic. Finally, the effectiveness of classification for intensional query answering is shown. To summarize, CANDIDE proposes itself as a new conceptual model, while CLASSIC presents a system based on an FDL (coming from AI environment) and its feasibility for database objectives. The present work does not face these topics, but the general formal framework given can constitute a valid support to extend the above results to a database environment supporting OODM. The two following papers of this volume present taxonomic reasoning techniques in LOGIDATA+ with different features. Introducing taxonomic reasoning in LOGIDATA+ by A. Artale, F. Cesarini, G. Soda supports incomplete object descriptions, presents a complete subsumption algorithm and provides a proof of its polynomial complexity. Taxonomic reasoning with cycles in LOGIDATA+ by D. Beneventano, S. Bergamaschi, C. Sartori supports cyclic class descriptions, presents a complete subsumption algorithm and provides a definition of consistency with respect to inheritance of a database schema.
References [ACCT90]
[AH871 [AK861
P. Atzeni, F. Cacace, S. Ceri, and L. Tanca. The LOGIDATA+ model: Technical Report 5/20, CNR- Progetto Finalizzato Sistemi Informatici e Calcolo Parallelo - $5, 1990. S. Abiteboul and R. Hull. IFO: A formal semantic database model. ACM Transactions on Database Systems, 12(4):525-565, 1987. H. Ait-Kaci. Type subsumption as a model of computation. In L. Kershberg, editor, 1st Int. Workshop on Expert Database Systems, pages 115-140. The Benjamin-Cimmings Publishing Company Inc., 1986.
83 [AK89]
S. Abiteboul and P. Kanellakis. Object identity as a query language primitive. In SIGMOD, pages 159-173. ACM Press, 1989. [AP88a] P. Atzeni and D.S. Parker. Formal properties of net-based knowledge representation schemes. Data and Knowledge Engineering, 3:137-147, 1988. [AP88b] P. Atzeni and D.S. Parker. Set containment inference and syllogisms. Theoretical Computer Science, 62:39-65, 1988. [BBMR89] A. Borgida, R.3. Brachman, D.L. McGuinness, and L.A. Resnick. CLASSIC: A structural data model for objects. In SIGMOD, pages 58-67, Portland, Oregon, 1989. ACM. [BCST89] S. Bergamaschi, L. Cavedoni, C. Sartori, and P. Tiberio. On taxonomical reasoning in E/R environment. In C. Batini, editor, 7th Int. Conf. on the Entity Relationship Approach - Roma - 1988, pages 443-454, Amsterdam, 1989. Elsevier Science Publisher B.V. (North-Holland). H.W. Beck, S.K. Gala, and S.B. Navathe. Classification as a query [BGN89] processing technique in the CANDIDE data model. In 5th Int. Conj. on Data Engineering, pages 572-581, Los Angeles, CA, 1989. [BL87] R.J. Braehman, and H.J. Levesque. Expressiveness and Tractability in Knowledge Representation and REasoning. Computational Intelligence, 3:78-93, 1987. R.J. Brachman, and H.J. Levesque. The tractability of Subsumption in [BL84] Frame-Based Description Languages. A A A I , 34-37, 1984. S. Bergamaschi and B. Nebel. The complexity of multiple inheritance [BN91] in complex object data models. Workshop on A I and Objects - I J C A I '91, Sidney - Australia, August 1991 (also available as Technical Report 74 CIOC- CNR, Viale Risorgimento,2 Bologna, Italia, December 1991). R.3. Brachman, D.L. McGuiness, P.F. Patel-Schneider, L. Alperin [Brac91] Resnick, A. Borgida. Living with Classic: when and how to use a KLONE language, in [Sowa91] [BS85] R.J. Brachman and J.G. Schmolze. An overview of the KL-ONE knowledge representation system. Cognitive Science, 9(2):171-216, 1985. [BS92] S. Bergamaschi and C. Sartori. On taxonomic reasoning in conceptual design. A C M Transactions on Database Systems, Vol.17, N.3, Sept, 1992. [CARD84] L. Cardelli. A semantics of multiple inheritance, em Semantics of Data Types - Lecture Notes in Computer Science N. 173, 1984, pages 51-67, 1984. Springer-Verlag. [DBL89] G. Di Battista and M. Lenzerini. A deductive method for EntityRelationship modelling. In 15th Int. Conf. on Very Large Databases, pages 13-21, Amsterdam - NL, August 1989. [DD89] L.M.L. Delcambre and K.C. Davis. Automatic validation of objectoriented database structures. In 5th Int. Conf. on Data Engineering, pages 2-9, Los Angeles, CA, 1989. [DHLMNN91] F.M. Donini and B. Hollunder and M. Lenzerini and A. Marchetti Spaccamela and D. Nardi and W. Nutt. The Complexity of Existential Quantification in Concept Languages. rap.01.91, Dipartimento di Informatica e Sistemistica, Roma, 1991. [DLN91] F.M. Donini, M. Lenzerini, D. Nardi and W. Nutt. The Complexity of Concept Languages. In J. Allen and R. Fikes and E. Sandewall, editors, KR '91 - 2nd Int. Con] on Principles of Knowledge Representation and
84
[DLNN91] [FS86]
[KV84] [LRS9a] [LR89b] [LRV881 [NEBE881 [NEBE90] [NEBE91]
[NEBE90a] [PS841
[PS861 [PATE89] [PATEg0 l [PS861 [SCH891
[Sowa91]
Reasoning, pages 151-162, 1991. Morgan Kauffmann Publishers, Inc., Cambridge - MA. F. M. Donini, M. Lenzerini, D. Nardi and W. Nutt. Tractable Concept Languages. In IJCAI 91, Sidney, Australia,1991. T. Finin and D. Silverman. Interactive classification as a knowledge acquisition tool. In L. Kershberg, editor, Expert Database Systems, pages 79-90. The Benjamin/Cummings Publishing Company Inc., 1986. G.M. Kuper and M.Y. Vardi. A new approach to database logic. In PODS '84, pages 86-96. SIGACT-SIGMOD-SIGART, ACM Press, 1984. C. Lecluse and P. Richard. Modelling complex structures in objectoriented databases. In Syrup. on Principles of Database Systems, pages 362-369. ACM SIGACT-SIGMOD-SIGART, 1989. C. Lecluse and P. Richard. The 02 data model. In Int. Conf. On Very Large Data Bases, 1989. C. Lecluse, P. Richard, and F. Velez. 02, an object-oriented data model. In SIGMOD, pages 424-433, Chicago - IL, June 1988. ACM. B. Nebel. Computational complexity of terminological reasoning in BACK.. In Artificial Intelligence. vol. 34, n.3, 1988. B. Nebel. Terminological reasoning is inherently intractable. In Artificial Intelligence. vol. 43, n.2, 1990. B. Nebel. Terminological cycles: semantics and computational properties. In J. Sowa, editor, Principles of Semantic Networks. Morgan Kaufmann, 1991. B. Nebel. Reasoning and Revision in Hybrid Representation Systems. Lecture Notes in Artificial Intelfigence, n. 422, 1990. P.F. Patel-Schneider. Small can be beautiful in knowledge representation. In Workshop on Principles of Knowledge-Based Systems, pages 11-16, Denver- Colorado, December 1984. IEEE. P.F. Patel-Schneider. A four-valued semantics for frame-based description languages. In AAAI, pages 344-348, 1986. P.F. Patel-Schneider. Undecidability of Subsumption in NIKL. Artificial Intelligence, 39:263-272, 1989. P.F. Patel-Schneider. Pratical Obiect-Based Knowledge Representation for Knowledge-Based System. In/ormation System, vol.15, n.1, 1990. P.F. Patel-Schneider. A four-valued semantics for frame-based description languages. In AAAI, pages 344-348, 1986. M. Schmidt-Schauss. Subsumption in KL-ONE is undecidable. In Brachmann, R.J. and Levesque, H.J. and R. Reiter, editors, KR '89 - 1st Int. Conf. on Principles of Knowledge Representation and Reasoning, pages 421-431, Morgan Kauffmann Publishers, Inc.,TorontoCanada. Sowa J.F. editor Principles of Semantic Networks, Morgan Kaufmann Publishers.
Introducing T a x o n o m i c Reasoning in LOGIDATA + Alessandro Artale and Francesca Cesarini and Giovanni Soda Dipartimento di Sistemi e Informatica - Universit~ di F i r e n z e Via S . M a r t a , 3 - 5 0 1 3 9 F i r e n z e - Italia e-mail: giovanni~ingfi 1.cineca.it A b s t r a c t . In this paper we give a syntax and define a denotational semantics for describing classes in LOGIDATA*, and give a s u b s u m p t i o n algorithm that is sound, complete, and polynomial. The syntax allows us to describe both primitive and defined acyclic classes by means of t h e tuple and set type constructors; in particular, it is also possible to state cardinality constraints on sets. Semantics is defined by means of an interpretation function that maps the descriptions given at an intensional level into the value domain. This interpretation also takes t h e undefined element n i l into account, thus allowing us to deal with a form of incomplete knowledge in a way that is semantically correct. After introducing defined classes and the notion of interpretation function, it is possible to formally define the concept of subsumption, an inference technique that makes it possible reasoning about objects and classes on the basis of their descriptions.
1
Introduction
This paper deals with introducing in LOGIDATA + [3] the paradigm of taxonomic reasoning. The characteristics of taxonomic reasoning and its relevance for a database environment are outlined in [2]. In particular, taxonomic reasoning is based on the concept of defined classes (i.e., classes whose structural description gives necessary and sufficient conditions for the objects t o belong to them); therefore, it is possible to infer specialization relationships among classes, besides the ones explicitly stated by ISA clauses, and recognize instances. Furthermore, taxonomic reasoning is also useful for answering at both an extensional and intensional level and optimizing query execution. The introduction of taxonomic reasoning in LOGIDATA + provides for a deductive capability that is limited with respect to some logical languages but that provides a well-founded and uniform inferential service with computational tractability that can be exploited for all the above mentioned features. For this purpose, we define a formal framework suitable for dealing with defined classes and give a sound, complete, and polynomial algorithm for computing specialization among classes. In our work we do not consider recursive definitions of classes, because our study moves from suggestions derived from terminological languages that usually do not allow this possibility. However, our framework supports incomplete object descriptions, allowing us to deal with incomplete knowledge.
86
The LOGIDATA* schema and a syntax by means of which it is possible to describe primitive and defined acyclic classes is defined in section 2, this syntax provides for tuple and set type constructors and cardinality constraints on sets can be stated. A denotational semantics that supports a kind of incomplete knowledge about objects is described in section 3. For this purpose the functions associating values to tuple labels and object identifiers are suitalbly extended in order to take a null value into account; furthemore, the interpretation function is explicitly linked to the class definition syntax in order to obtain legal instances. Some examples of deductions on the extensional level of the Knowledge-Base are illustrated in section 4. Section 5 is devoted to characterize the notions of schema coherence and subsumption, and the syntactic constraints for coherence are illustrated in section 6. Section 7 discusses the computational complexity of the subsumption algorithm. We make our concluding remarks in section 8. The Appendix A shows an example of schema definition and interpretation, while in the Appendix B the soundness and completeness of the subsumption algorithm are proven.
2
Schema
Definition
Language
The LOGIDATA* model derives from LOGIDATA+ but contains some important differences in order to fit taxonomic reasoning. The main structure of LOGIDATA* is the class that denotes sets of objects, each of which is identified by an Object Identifier (old). Objects in classes can have complex structures obtained by repeatedly using the tuple and set constructors 1. Furthermore, type names are provided to simplify user declarations. Further, set types with cardinality constraints are introduced, integrating in the object description a kind of integrity constraint in the database environment, and classes are distinguished as primitive and defined. We consider, as base types B, the two countable, non-finite set of strings and integers, which are disjoint. Let C p be a countable set of primitive class names, CD a countable set of defined class names, (3 = C p U C o , T a countable set of type names, L a countable set of labels; sets B, Cp, C o and T are pairwise disjoint, CD including the universal class, which will be denoted by the symbol T. We indicate by T ( L , B, C, T ) (often abbreviated simply as 7") the whole set of type descriptors, over L, B, C, T defined as follows: - each base type name B E B is a type; - each class name C E (3 is a type; - each type name T E T is a type; if t is a type, then {t}(,,~in,max) is also a type called set type, where min is a not-negative integer, max is a positive integer or oo, and m a x >_ rain; - e m p t y s e t is the empty set type; if t l , . . . , t k , with k > 0, are types and l l , . . . , l ~ are distinct labels, then [11 : t l , . . . , lk : tk] is also a type, called tuple type. -
-
1 The sequence type (0) can be easily added.
87 Let ISA be a partial order over C: C ISA C' states that each object belonging to class C also belongs to class C', i.e., class C is a subclass (or a specialization) of C'. Let TYP be a function from T U C to the set of type descriptors in 7"(L, B, C, T). TYP is such that: for each T E T, TYP(T) is a tuple or set type descriptor of 7-; - for each C E C, TYP(C) is a tuple type descriptor of 7"; T Y P ( T ) is the empty tuple [ ], i.e. the tuple type with no labels. -
D e f i n i t i o n 1 L O G I D A T A * S c h e m a . A LOGIDATA* schema is a five-tuple S : ( C p , C D , T , TYP, ISA) where T, Cp, CD, ISA and TYP are defined as above. A LOGIDATA* schema can be defined by means of the syntax illustrated below. We note that we don't take any recursive definitions into account, in accordance with the approach usually used by the Knowledge-Representation-Models we refer to [11]. The ISA clause allows the system to exploit the mechanism of inheritance; multiple inheritance is allowed, with some restrictions on the legal schema declarations assuring type compatibility (see sect. 6). <declaration> := I := t y p e = := TI class <prim-def> ISA *: < t y p e - i d > ] class <prim-def> ISA * := I <set-type> < t y p e > := I I I := [*] < c o m p o n e n t > := < l a b e l > : < t y p e > <set-type> := { }<mi~>,<max> l EmptySet := string I integer <prim-def> := < m i n > := "not-negative integer" < nlax> : : "positive integer" I "*" indicates 0 or more repetitions. This syntax allows for instance to describe the concept of father as the set of all "individuals who are persons with at least one child and all children are persons" : class Father :- ISA Person [child:{Person}l,oo] We show a more detailed example of schema definition in the Appendix A.
88 3
A Semantics
Dealing
with
Incomplete
Knowledge
We design our database system LOGIDATA* in such a way that it supports incomplete information about objects [4]. Thereafter, information about an object is added incrementally, allowing us to create an object about which nothing is known except that it belongs to the universal class T or to assert that it is an instance of some classes without necessarily specifying values for the fillers of its properties. D e f i n i t i o n 2 Values. A set 12 of values
is
I~'
-
:D l.J {91.1 12T U 12S where
:D = t.l~=l:Di and /)i are the sets of values associated with the base type names Bi E B. Each element v E / ) is a basic value. O is a countable set of symbols, called object identifiers, disjoint from ~ . - 12T is the set of tuple values: 12T = {v, I vt is a mapping, vt : L ~ 12t9 { n i l } } . L is a set of labels. We denote with [Ix : V l , . . . , l k : v~] the total mapping defined on {11,..., lk} such that v, (ll) = vi E 12 t9 { n i l } , i = 1 , . . . , k. - 12s is the set of set-values: 12s = {vs I v, C 12}. A set-value is denoted by { v l , . . . , v ~ } , with vi E 12, i = 1 , . . . , k . -
We note that the object identifiers are values, too. Since objects are usually considered to be pairs of identifiers and values, we assume the existence of a function that assigns values to object identifiers. D e f i n i t i o n 3 V a l u e A s s i g n m e n t a n d D o m a i n . Value assignment is a total mapping, denoted by 6, that associates a tuple value with each object-identifier: 6 : 0 - - ~ 12T t.J { n i l } . The d o m a i n ~ is the couple E = (O, 6). We assume that: - 6(0) = nil when an object is created but is not assigned to any class because nothing is known about its properties (in this case o is a member of the universal class T); - vt (l) = nil for labels with undefined value.
The nil element makes it possible to treat incomplete knowledge maintaining vt and 6 total mapping. D e f i n i t i o n 4 I n t e r p r e t a t i o n . Given a LOGIDATA* schema S, let 7" be the type descriptors in S. Given a domain ,U, the interpretation f u n c t i o n I of S over 12 is a function from 7" to 212 such that: 2~(Si) = 2)i,
2:(C) C O,
2:(W) C_ 12 - O.
The interpretation is extended to types in 7" as follows: Z([ll : t l , . . . , l k
:tk]) = { v t e
12T I vt is defined atleast on { l l , . . . , l k } and v, (li) e Z ( t , ) , i 1,...,k}.
Z ( e m p t y s e t ) = {$}.
z ({t}cn,m)) = {v. e VS I n --) = 2-([11 : tl...lk: tk]) = {Yt E 12T { Vt is defined at least on { l l . . . l k } and
v,(li) 6 2-(ti),i = 1,...,k} 3. 2-(<set-type>) = :T-.({t}m,n) = {Us ~ 12s ] m _~) = 2-(type type-id = ) = 2 ; ( < t y p e > ) 5. 2-() = 37(C) C_ O, and: (a) 27(T) ~ O (b) :/:(class Ca -- ISA C ~ . . . C , < t u p l e - t y p e > ) =
= :/:(Ca). = f'li"=12-(Cj ['] {o 6 0 (c) 27 (class Cp < ISA C 1 . . . C n
I 6(0) e Z(TYP(Cd))}
< tuple-type >) =
= 2-(Cp) C_ Nin=12-(Ci) N {o 6 0 [ 6(0)
E
2-(TYP(Cp))}
For the interpretation of TYP(C) we have the following recursive definition. D e f i n i t i o n 6 I n t e r p r e t a t i o n of T Y P ( C ) . Given the class declarations: c l a s s Co < prim-def> < tuple-type >0 c l a s s C1 <prim-def> ISA Co < t u p l e - t y p e > l c l a s s Cn+l <prim-def>
we have 77 (TYP(Co)) Z (TYP(C1))
ISA Co...Cn
n+l
= 2: (< tuple-type >o) = Z (TYP(C0)) N 2"(< tuple-type>l)
2-(TYP(C.+I)) " , (-~n , i = t Z(TYP(CI)) N 2-(n+x)
90 This semantics, allows us to consider the ISA relationship as an inclusion between classes. Moreover, each value can have more than one type [5]: when a value is of type t, then it is of type t', too, in the case that 2: (t) C I(t'). Remark that the interpretation of a class is a set of objects which have a value according to the type of the class; furthermore, these objects must also belong to the interpretation of the classes appearing in the ISA clause. As regards the concept of primitive/defined class, the interpretation of a defined class consists of all the objects verifying the above-mentioned constraints, while the interpretation of a primitive class is a subset of them. For example, in the case of class Person _< [name:string birthdate:Date] class Project - [proj-code:string description:string/ class Student - ISA Person [regist-num:int enrolled:College enrolled-course: {string} 1,10] the interpretation of Person is a subset of the objects having a name and a birthdate, while the interpretation of Project is the set of all the objects having a proj-code and a description. Thus, an object having a name and a birthdate must be explicitly asserted belonging to the Person class, while an object having a proj-code and a description always belongs to Project. The interpretation of Student consists of all the objects that belong to Person, have a regist-num, are enrolled to a College, and are enrolled to some courses. Because of the recursive definition of the TYP's interpretation, these objects also have a name and a birthdate (inherited from Person); as a matter of fact, the tuple values of the Student objects are given by the intersection of the tuple values defined at least on the name and birthdate labels, and the tuple values defined at least on the regist-num, enrolled and enrolled-course labels. In the Appendix A we show a complete example of schema interpretation.
4
Deductions
on Instances
The above introduced semantics provides the LOGIDATA* database with a powerful means for manipulating the explicit information about the domain (extensional level) and thus allows the system to have an active role in deducing new relationships rather than being just a passive repository of data. The fact that, for a fixed schema S, a set of values 1/, a domain E = (O, 8) and an interpretation for the primitive classes, the set of instances of a defined class is unambiguously determined, allows a LOGIDATA* database to recognize new instances of a class. So, for example, given the schema specification reported in Appendix A, if # J o h n is defined in such a way that: #John E I (Person) b(#John) = [name:John birthdate:[day:25 month:7 year:1953] emp-code:I23435 salary:2000 works-at:#Ote prj:#LogDB budget:[prj-amount: 1500]] then the system recognizes the object # J o h n as an Employee and a PrjLeader without explicitly asserting these facts and includes # J o h n in the answer to a
91
query about the instances of Employee and PrjLeader. In addition, our system deals with incompletely specified objects in a way that is semantically coherent. For example, we can assert that: #Mary E Z(Student), with attributes: regist-num = 876362 enrolled = #Yale enrolled-course = {mathematics,physic} without specifying the fillers for the name and birthdate attributes of the # M a r y object (see in the Appendix A the description of the Student class) and without any explicit assertion about the #Yale object. Then, given that the fillers of the enrolled attribute in the Student class must belong to the College class, LOGIDATA* includes the #Yale object in the College class and assignes an undefined value to the unspecified properties of both # M a r y and #Yale objects: #Yale E 2-(College) 6(#Yale) = [name:nil address:nil courses:nil] 6(#Mary) = [name:n//birthdate:nil regist-num:876362 enrolled:#Yale enrolled-course: {mathematics,physic}] Therefore, LOGIDATA* deals with incrementally evolving descriptions, allowing the user to maintain a partial view of the domain of discourse; incomplete information may be gradually eliminated as new knowledge is acquired. 5
Schema
Coherence
and
Subsumption
An interesting property of classes is disjointness [6], i.e., whether two class descriptions denote necessarily mutually exclusive sets. In LOGIDATA* two class descriptions can be disjoint because of non-overlapping restrictions over the same label. In the following schenm: class Person ~ [name:string birthdate:string telephone:string] class Childless-Person - ISA Person [children:EmptySet] class Fertile-Parent - ISA Person [children:{Person}l,5] class Successful-Parent--' ISA Person [children:{Person}620] Childless-Person, Fertile-Parent and Successful-Parent are disjoint classes given that, for the children label:
I ({Perso,,}l,5) fq Z ({Person}6,2o) = 2- (EmptySet) fq Z ({Person}l,5) = Z (EmptySet) M Z ({Person}6,2o) = 0 In general, the following definition holds. D e f i n i t i o n 7 D i s j o i n t t y p e s . Given a schema S, two types tl and t2 are disjoint if and only if for each domain S and for each interpretation function 2" defined over V, 2 ( t l ) CI2"(t-_,) = 0 . An incoherent type description contains two or more disjoint types. For example, the following class descriptions are incoherent: class C1 - ISA Fertile-Parent Successful-Parent class C2 - ISA Person [telephone:int]
92 D e f i n i t i o n 8 I n c o h e r e n t t y p e . Given a schema S a type t is incoherent if and only if for each domain S and for each interpretation function 2: defined over V, z (t) = 0. We say that a schema S is coherent if it does not contain incoherent types. LOGIDATA* does not permit to create such types in order to always enforce a consistent knowledge state (see sect. 6, where the above definitionition is translated into syntactic constraints). The introduction of the interpretation function, together with the notion of defined class, allows us to formalize the concept of subsumption between classes and define an algorithm for its computation. D e f i n i t i o n 9 S u b s u m p t i o n . Given classes C1 and C2, C2 subsumes C1 (C2 C1) or suBs(C2, C1)) if and only if for each domain X' and for each interpretation function/: defined over V, 7: (C1) C_ 2: (C2) holds. In our framework, every ISA clause corresponds to a subsumption relationship: if C1 ISA C2 then C2 subsumes C1. The opposite is not necessarily true; a class can subsume another one even if subsumption is not esplicitly defined by means of an ISA clause. Because our interpretation function is totally based on structural characteristics, the meaning of a structured description is only determined by its internal structure. This allows us to make an algorithm to deduce all the subsumption relationships among classes implicitly given by the structural conditions appearing in the class descriptions. For this purpose we introduce an ordering on T ( L , B, C , T ) called refinement (in symbols _ p and n_ 0; therefore iT.(EmptySet) C_2" ({t i }0,m)). R 3 c t a n d t ' E C w i t h t ' E C D and: - ~(t') g ~ ( t )
- REF(TYP(t),TYP(t'))=TRUE Therefore, by induction 2"(TYP(t)) _C 2.(TYB(t')); then, due to point 5.5 of the interpretation definition, 2" (t) C 2" (t').
102
The completeness of the SOBS algorithm can be proven on the basis of the following two lemmas. The first lemma allows us to construct an interpretation function in such a way that a particular value vl is in the interpretation of each tuple type except for a particular exception. L e m m a 18. Let L be a set of labels, l* G L; t a generic type; 12 a set of values. Moreover, let 27 be an interpretation function over l~; vl and v* E !) such that: -
v* e 2 7 ( t )
vl is a tuple value - vl(li) -" nil Vii E L, for li ~ l ~ -
-
o1(1 ~ = v ~
Then, for every tuple type: x - - ~1 : t l , . . . , l k
:tk]
if :c does not.contain l ~ : u, with u such that REF(t, u)=FALSE, then v~ E 27(x). Proof. There are two cases. 1. The 1~ label is not present in z. Due to our construction, Vl is surely defined over all the labels appearing in x and vl (li) e 9 (ti)U {nil} V i = l , ... ,k. Then, for point 2 of the interpretation definition, vl E 27(z). 2. The I~ label is present in z: x = [ll : tl . . . l ~ : s . . . l k : t~] with s generic type such that t < s. It is enough to prove that vl(i ~ E 27(s). Due to our construction, vl(l*) = v~ E 27(t); but we have 27(t) C Z(s) because t < s, then Vl(l*) E 27(s). Therefore, Vl E 2" (x). L e m m a l 9 . For each t E T ( L , B , C , T ) it is possible to find n distinct values v l , . . . , v n E Y and an interpretation function 27 defined over l~ such that vx,...,
v , e :~ (t).
Proof. The proof follows from the consideration that, for each basic type Bi, 27(Bi) is a countable set. Therfore, it's easy to show by induction that the lemma holds. Now we can prove tile completeness of the subsumption algorithm. T h e o r e m 20 C o m p l e t e n e s s o f t h e S U B S A l g o r i t h m . Given two classes C1 and C~, if27 ( e l ) C 27(6~) , for every set of values ]] and for every interpretation function Y. over V, then SUBS(C2, C1)=TRUE.
Proof. Given that SUBS(C2, C1) is true if and only if REF(C1, C2) is true, we show that, given two generic types x and y, if R E F ( z , y)=FALSE, it is always possible to find a set 1~ and an interpretation function 27 over 12 such that: 27(~) r 27(y).
103
1. If x, y have different types (for example, x is a tuple type and y a set type), then Z ( x ) N 27(y) = O because the sets D , O , 1;T, 1;S are pairwise disjoint; therefore, 27(x) r 27(y). 2. If x, y e B (they are base types), REF(x, y ) - F A L S E r x ~ y. Then 27 (x) :2"(y), because the base types are pairwise disjoint. 3. If x, y are tuple types, we have two different cases. (a) y contains l ~ : u, while x does not contain the l ~ label. We build a tuple value vl defined exclusively on L - {i.} and such that vl(li) = nil Vii E L - {lO}. Let Vl E Y and 27 be an interpretation function over V, then vl e 27(x) but vl r Z (y). (b) y contains l ~ : u, x contains l ~ : t but t is not a refinement of u. Since REF(t, u)=FALSE, by induction, there are 27*, Y* and v* E V* such that v* e 27* (t) but v* • Z* (u). Now we build a tuple value vl such that Vl(li) = nil Vii E L - {lO} and vl(i ~ = v*. Let V = V* U{vl} (with Vl # v*); let 2" be an interpretation function over 1; such that, for every type s, 2"(s) _C I* ( s ) U {Vl}, and in particular v* E Z(t). Then vl(l ~ = v* ~ 2-(u); therefore, vl t/ 27(Y). On the other hand, assuming v ~ = v*, the conditions of Lemma 14 (case 2) are satisfied, indeed vl E Z (x). Then Z (x) ~ Z (y). 4. If x , y are set types with x -- {t},,,m and y = {u}p,q and re,p>0, we have two different cases: (a) REF(t, u)--FALSE. By induction, there are 2-*, V*, and v* E V* such that v* E 2"* (t) but v* ~ 2-*(u). Let v0 be a set value such that v o = { v * , v l , . . . , V n _ l } ; V = V*U {Vo,Vl,...,Vn-1}; let 2" be an interpretation function over V such that vl E Z(t) Vi=l . . . . ,n-1 (follows from lemma 15) and for every type s, 2-(s) C Z* (s) U {v0, v l , . . . , v n - i } . Then v* E Z i t ), while v* ~ 2-(u). Therefore, since v0 = { v * , v l , . . . , v n - i } C 2-(t) and II v0 II= n then, due to the interpretation of set type, Vo 9 27(x) but vo ~. Z(y). Then 27(x) r 27(y). (b) n
q. Let n0
4 The dependence of k~t on L' will be left unexpressed. 5 We note that, for all type t, if 2"~ ___ 2" then :T~(t) C_ 2"(t) V,U, i.e. the relation E_ can be extended to all types.
119
Proof. First of all, we show any increasing chain Z0 E lub({F(Ei);i > 0]). In fact, be the interpretation defined
that function F is upward w-continuous, i.e., for 1:1 _ Z~ E ... we have F(iub({Zi;i>O])) = let X = { Z 1 , . . . , Z , } , a subset of ~P~, and let Z by:
(C) :
5
~k (C)
k--I
C e -C D
Then, for all t E 7": Z (t) - N~=IEk (t). Furthermore, from the definition of F it is easy demonstrate that we have ~t
= n r(zk) k--I
Hence mapping F is downward w-continuous, thus the following result holds: gfp(C) = glb ({C (T); n _ 0}).
W e are now able to give the algorithm for the computation of greatest legal instance. First of all, we recall that C ~ (IT) = IT, C { (T) = F (C {-I (T)); F is monotonic, hence by induction C i-1 (ZT) _~ C i (ET). Consequently, from the expression of proposition I 1 it follows that: gfp(C) = C ~ (ZT)
where ~ is the least natural number such that F 7+I (ZT) = FT(ET). In order to simplify the algorithm it is convenient to find another expression for the greatest fixed-point of C. The notion of atomic primilive generalizations is introduced as follows:
Gp(C) -- {Cp I C ISAe Cp] In other words, Gp(C) is the set of atomic primitive classes reached with the ISAs relationship. Hence a possible instance can be expressed, according to the equation of the possible instance of defined classes, as follows:
Z(C) =
~
I(Cp~) n {o e O I 6(0) 6 Z (Y-Y-P(C))} n
(4)
cj , ap (c) C ISAE C{
where Z is the initial partial interpretation, as introduced in section 5. By observing the above equation it is naturM to choose, as the initial interpretation, the intersection of the ancestor primitive atomic classes, that is:
z+(c) =
N Cp,eGp (C)
+(+,)
120
Obviously, for any fixed-point 77 of r we have 27* _ 77; hence, g y p ( F ) is the greatest fixed-point of r which is less than or equal to 27*. Then g y p ( F ) can be expressed as glb ( { r n (27*); n > 0}); thus, by the above considerations, we have g y p ( r ) = r ~ (27*) where ~ is the least natural number such that r ~+1 (77*) = r z (27*). Finally, in table 4 we show the algorithm for the computation of greatest legal instance. As an example of computation, let us consider the following :~:
9 Initialitazion and iteration - class types:
If i = 0 then 2"o(C) =
N
t(C--pp~)
C p j e G p (C)
If i > 0 then Z, (C) = Z0 (C) n {o e O I ~(o) e z,_~ (YV-P(c)) } n
C ISAB Cr -
-
-
base types: Ii (Bk) = 79k ; set types: Z~ ({t}(.,m~) = {v. 9 Vs I " -- C < C'. P r o o f S k e t c h The proof follows immediately from the definition of 2" (C). [] The inverse does not generally hold, as we will show by computing that Typist < Secretary, Typist _< Clerk and Office < Department even if not expliciy stated.
7
Coherent
and
Consistent
Schemata
One of the main objectives of taxonomic reasoning in a database environment is the validation of a schema. In a L O G I D A T A ~ y c schema there are two possible sources of validity problems: type definitions and ISA relationships. For this reason we will provide two definitions related to validity: coherence, with respect to types, and consistence, with respect to ISA and inheritance. Coherence and consistence can be violated independently. Nevertheless, we are interested in schemata which are both coherent and consistent, and it is possible to give a unique syntactical characterization for the two properties.
122
D e f i n i t i o n 14 ( C o h e r e n t t y p e s ) . Given a schema S = (Cp, CD, T, TYP, ISAu), a type t in S is coherent if and only if:
3 ~ ~z over •, z (t) ~
{}
A schema S is coherent if and only if it contains only coherent types. As mentioned in section 4, the type specification of class C must agree with the type specifications of superclasses of C. We are now able to formally specify this agreement by means of the notion of consistent schema. Definition15
(Consistency and inheritance).
Given a schema S = (Cp,
CD, T, TYP, ISAu) a class C E C is consistent with respect to inheritance if and only if: TYP(C)__TYP(C')
VC I C ISA~ C'
A schema S is consistent if and only if it contains only consistent classes. In a consistent schema we do not allow two related classes (C ISAu C') to have arbitrary associated types; the type associated to a class describes the internal structure of the instances of the class. An instance of a class (say Employee) being also an instance of its superclass Person, we want the instances to share common structures. It is worth noting that the concepts of consistence and coherence are independents. For example, let us consider the classes Wide-Division, Recorder and Middle-Division with the following descriptions: class Wide-Division = isa Division[employs: {Employee}(30,40)] class Recorder = isa Employee[work-in : Wide-Division] class Middle-Division = isa Division[employs: {Employee}(lo,30)] and with the following types: TYP(Wide-Division) = [name : string, employs : {Employee}(ao,40), turnover : integer] TYP(Recorder) = [name: string, birth-date : Date, salary : integer,1 work-in : Wide-Division, emp--code : integer] TYP(Middle-Division) = [name: string, employs : {Employee}(10,30), turnover : integer] In LOGIDATA~y c the incoherence can derive from the redefinition of common labels. The Wide-Division class, is not coherent, as the employs label is redefined on a type obviously disjoint from the corresponding type of Division, and is not consistent (TYP(Wide-Division) ~ TYP(Division)). The Wide-Divisibn class is not consistent (TYP(Wide-Division) ~ TYP(Division)) but is coherent (in fact, it admits the objects of the Division class with n employees, where 10 < n < 20). Finally, as TYP(Recorder) is not coherent and thus subsumed by any other type, the Recorder class is not coherent but is consistent.
123
7.1
C o m p u t a t i o n of t h e Legal I n s t a n c e
In this section, we will show how computation of the legal instance can be simplified when the schema is coherent and consistent. Intuitively, by comparing equation 4 and definition 15 it can be seen that the following set: (
N
{o e O ] 8(o) e Z (TYP(Ci))})
C IsAB Ci does not influence any legal instance 2" (C) if the schema is coherent and consistent. The effect of coherence is not obvious due to the presence of the cyclic defined classes, as shown in the following example. Let us consider the defined classes C1 , C2 and C3 with C2 ISAo C1, TYP(CI) = [a:inleger], TYP(C2) = [a : C3], TYP(C3) = [b : C2]. The class C2 is consistent but not coherent, as 2"(TYP(C~)) is disjoint from Z(TYP(C1)); we cannot then simplify 2"(C2) by eliminating the set {o E O ] 3(o) E 2"(TYP(C1))}. For this reason, we will consider a simplified schema, say S, derived from -S, where the ISAE assertions between defined classes are ignored, since they are implicitly contained in function TYP. The portion of schema of part b) of figure 2 is thus transformed as shown in figure 3. We will then prove the equivalence of the computation of the legal instance in S and in S. Let S = (Cp, CD, T, TYP, ISAu) be a coherent and consistent schema and be the associated schema defined as in section 5. It is already proved that the computation of a legal instance of S is equivalent to computation of a legal instance of S. In the simplified schema S = (Cp, CD,T, TYP, IS~-'Av) the ISAu relationship is defined as follows: C ISAu Cp
iff C ISA~ Cp,
VC E CD,
VCp E Cp
P r o p o s i t i o n 16. Let S be a coherent and consistentschema, I a primitive assignment and E the corresponding legal instance of S and ~ the corresponding legal instance of'S. Then
z (c) = i (c)
vc e
~D
Proof. The proof is in [Ben91]. The new formulation of the legal instance allows to be simplified algorithm 1 by rewriting the computation for class types as follows: -
class types: - If i = 0 then 2"0 (C) = [~CpjeGp (C):~(Cpj); - I f / > 0 then 2"i (C) = 2"0 (C) N{o E O ] 6(0) e 1i-1 (TYP(C))}
124
person*
person
employee
clerk
Fig. 3. Trasformation of the schema S into schema
7.2
Subsumption Computation
The purpose of this section is to give a syntactical characterization for the subsumption relationship and for the coherence and consistency checks. In the following we will show how the computation of subsumption for a consistent and coherent schema can be performed by the boolean function s u b s on the basis of a syntactical comparison of type descriptions 6. The same function s u b s can be used to check if a syntactically correct schema S is coherent and consistent. Notice that we cannot adopt an algorithm like the one presented in Introducing taxonomic reasoning in LOGIDATA*, as the presence of cyclic defined classes could lead to endless loops. As an example, consider the case of the classes Office and Department: the computation of Office < Department leads a new computation of some comparison Office < Department. The structure of the algorithm is strictly related to that of algorithm 1. In s The algorithm considers only types in canonical form, the extension to types with names is straightforward.
125
particular, the initialization step for classes takes, as a s t a r t i n g point, the subs u m p t i o n s which immediately follow from the user-provided ISA hierararchy. T h e implications which are not compatible with type descriptions are then discarded.
s u b s is a function s u b s : T x T --* {true, f a l s e } defined as: * Initialitazion and iteration class types:
-
-
-
-
If i = 0 then subsi(C',C) = true iff G p (C') C_ G p (C); If i > 0 then subsi(C',C) = true iff (subs0(C',C) = true) A (subsi_l (TYP(C'),TYP(C)) = true); base types:
subsi(B',B) = true iff B = B'. -
set types:
- subsi({t'}( .... ),{t}(p,q)) = true iff (subsi(t',t) = true ^ n < p A m >_ q); - subsi({t'}( .... ) , e m p t y s e t ) = true iff n = 0; - subs, ( e m p t y s e t , e m p t y s e t ) = true; - tuple types:
subs,([...,lk:
tk . . . .
],[ ....
l',: t'j,...]) =
true
iff Vk 3 j :
= Z;) ^ t
(subsi (tk,ti) = true); . Stop - subsi+l = subsiC3.
T a b l e 6. A l g o r i t h m 2 [Computation of subsumption]
T h e algorithm stops after a finite n u m b e r of steps; in fact, the initialization sets a finite n u m b e r of relationships and subsequent steps can only exclude relationships (if s u b s / = f a l s e then s u b s j = f a l s e for j > i), there exists a n a t u r a l n u m b e r i such t h a t s u b s / = s u b s i + l and we set s u b s = s u b s / . Theorem
17. Given two types t and t' o f a coherent and c o n s i s t e n t s c h e m a S ; t < t'
r
subs(t',t) = true.
Proof. T h e proof is in [Ben91].
An i m m e d i a t e consequence of this result is a partial inverse for proposition 13, valid only for primitive classes. C o r o l l a r y 1 Given a coherent and consistent schema S and two classes Cp ECp andC EC: C _~ C p ,r
C ISAu C p .
126
The following theorem shows how the checking coherence and the checking consistence of a schema can be performed by algorithm 2. T h e o r e m l 8 . A schema S is coherent and consistent iffVC: subs(TYP(Ci),TYP(C)) = true
VCi I C ISAo Ci[3
Proof. The proof is in [Ben91].
8
E x a m p l e s of Taxonomic Reasoning
Table 7 shows an example of computation of the function subs for the schema introduced in section 1. The table includes only the most significant results.
subs(C, C')
subs0
sUbSl
subs2
subs3
subs4
subs
(Clerk, Employee) (Clerk, Typist) (Typist, Clerk) (Clerk, Secretary) (Secretary, Clerk) (Typist, Employee) (Typist, Secretary) (Secretary, Typist) (Department, Division) (Department, Office) (Office, Department) (Department, Section) (Office, Division) (Office, Section
true
true
true true true true true true true true true true true true true
true false true false false false true false true true true false true
false true false false false false false true false true false true false false
false true false false false false false true false true false false false false
false true false false false false false true false true false false false false
false true false false false false false true false true false false false false
Table 7. Selected values for function subs
It is easy to extend the results of table 7 in order apply theorem 18 and to verify that the given schema is coherent and consistent. Consequently, we can say that subs computes the subsumption for the given schema. Besides the most intuitive subsumptions, subs computes the following relations: Typist < Secretary, Typist < Clerk and Office < Department. As an example of the effectiveness of subsumption computation for schema consistency checks, we add the following class definition: class Adm-Department = isa Department[employs: {Typist}(1,5)]
127
If the consistency check is performed only by explicit isa relationships, AdmDepartment would be detected as inconsistent with respect to strict inheritance, as the redefined property employs has value Typist which has not been explicitily declared as a specialization of Clerk. By subsumption, Typist is computed as a specialization of Clerk, therefore the class Adm-Department is recognized as consistent with respect to the schema and automatically classified as a specialization of the Department class. Further, by subsumption computation, we can detect equivalence between classes with different explicit descriptions, thus detecting synonymous ones and avoiding redundancies. Suppose the following classes X and Y be given: class X
isa Employee, Secretary [work-in :Y]
class Y = isa Department [head: X, employs: {X}(1,5)] The following equivalences are detected: X _~ Typist Y "-" Office. Therefore, X and Y can be simply stored as synonymous. It is worth noting that all three semantics (greatest, descriptive and least) mentioned in section 4 produce legal instances which can be considered valid (i.e. useful at some respect). Our choice for the greatest fixed-point pushes objects down in the hierarchy (i.e. towards more specific classes) and this allows a set of inferences which are, in our opinion, more interesting. Algorithm 2 can be used to restructure a schema and the result is a schema which is equivalent to the original one only with respect to the greatest fixed-point. Roughly speaking, this leads to computation of a greater set of ISA relationships and, possibly, to considering equivalent classes which, with other, more conservative semantics could be different.
References Baader, F. Terminological cycles in KL-ONE-based KR-languages. In Proeeedings of the 8th National Conference of the American Association for Artificial Intelligence, Boston, Mass., 1990. Computation of Subsumption with Cycles in [Ben91] Beneventano, D. LOGIDATA+. Technical Report 80, CIOC - CNR, Bologna, October 1991. [BeBe92] Beneventano, D., and Bergamaschi, S. Subsumption for Complex Object Data Models. Proceedin9s of the International Conference on Database Theory, Berlin -1992, Springer Verlag Publisher. Bergamaschi, S., and Nebel, B. Theoretical fondations of complex object [BN91] data models Technical Report 5/91, CNR, Progetto Finalizzato Sistemi Informatica e Calcolo Parallelo, Sottoprogetto 5, January 1992. [KV84] Kuper, G.M., and Vardi, M.Y. A new approach to database logic. In PODS '84, pages 86-96. SIGACT-SIGMOD-SIGART, ACM Press, 1984. Lecluse, C., and Richard, P. The O~ data model. In Int. Conf. On Very [LR89] Large Data Bases, 1989. Lloyd, J.W. Foundations of Logic Programming. Springer Verlag, Berlin, [Llo87] 1987. [Baa90]
128
[Neb91] [Sch86]
B. Nebel. Terminological cycles: semantics and computational properties. In J. Sowa, editor, Principles o.f Semantic Networks. Morgan Kaufmann, 1991. D.A. Schmidt. Denotational Semantics: A Methodology ]or Languages Development. Allyn and Bacon, Boston, 1986.
Modeling Semantic Integrity Constraints in Object-Oriented Database Schemas Anna Formica, Michele Missikoff IASI CNR - Viale Manzoni 30, 1-00185 Rome, Italy
A b s t r a c t . Recent years have witnessed a continuous evolution models towards richer and more expressive paradigms. Along
of database the line of enriching the modeling capabilities, Object-Oriented databases (OODBs) have been introduced. In this paper, we propose a further enhancement to OODB models aiming at enriching the database s c h e m a by explicitly declaring semantic integrity constraints therein. In the paper, we present an Object-Oriented data definition language, referred to as TO~. It allows the construction of an OODB schema using the well known data structuring mechanisms, such as NF2 attributes, complex types, and multiple inheritance in class (type) hierarchies. In addition, TO,,L allows the further enrichment of the schema by expressing explicit integrity constraints. The proposal includes the definition of the formal semantics of TO~, according to a denotational approach, and the notion of correctness of schemas, with particular emphasis on the legality of ISA hierarchies. The proposed language is the basis of the prototype MOSAICO, an environment for the design and rapid prototyping of OODB applications developed at IASI.
1 Introduction Object-Oriented database (OODB) systems appear to be the candidate successors of relational database systems. With respect to the latter, the former are characterized by richer functionalities and more expressive data languages [8], [2], [15], [30]. In particular, an OODB system is a DBMS and an Object-Oriented system [6]. Being a DBMS, it is characterized by persistence and advanced data management functions, such as secondary storage management, concurrence, ad hoc query facility. Being an Object-Oriented system, it is endowed with the following features: object identity, complex objects (possibly recursively built), inheritance and hierarchical organization of types and classes, encapsulated methods, overriding combined with late binding, extensibility and computational completeness. The field of OODB systems appears, at present, characterized by a strong experimental activity which contrasts with the lack of a unifying view of the data
This research has been partially supported by "Progetto Finalizzato Sistemi Informatici e Calcolo Parallelo" of CNR, Subproject 5, Group Logidata+, and Subproject 6, Group Infokit.
130
model and formal foundations. It appears difficult to reach large consensus on a clear and formal specification of the model, on a declarative data manipulation language (something similar to SQL for relational databases), and on techniques for enhancing performance in data retrieval with query optimization. Furthermore, most of current Object-Oriented database systems lack direct support for formulating complex semantic integrity constraints. Nevertheless the existence of facilities to handle such constraints is an essential premise to improve the development and management of complex applications. In a data model, constraints are required for semantic and integrity reasons. In terms of semantics, they allow to enhance the expressiveness of the model by defining schemas which capture the real world situations in a more detailed way. In terms of integrity, they prevent certain iypes of inconsistencies, caused by misunderstanding or inaccuracy, by restricting the possible database states to those that satisfy such constraints.
1.1 Related Work
In contrast with the great demand for data integrity in database applications, there are only few OODB systems that provide explicitly this type of capabilities, and, in particular, that provide a declarative constraint language. This issue has been mainly investigated for traditional database systems [33], and in particular in relational and deductive databases areas. The latter, in particular, has been influenced by logic programming and, more recently, by Constraint Logic Programming [24]. Let us briefly survey the literature in these areas. In relational models, this problem has been widely studied. For example, in [11], [14], integrity constraints have been formalized providing a general purpose Constraint Specification Language which is a natural extension of the data definition language. In [31], a model of integrity control is presented, that addresses both validity and completeness of a relational database, also dealing with the integrity of the answers produced by the queries. Integrity constraints have been also studied in logic programming area. Constraint Logic Programming (CLP) [24], [13] is an extension of logic programming, where mechanism of unification is replaced by the more general notion of solvability of a set of constraints. Deductive databases have been developed taking advantage of the two above mentioned research areas: relational databases and logic programming [19]. The aim of this approach is to use logical languages to reason and query about database content. In this area, integrity constraints are closed first order formulas that database is required to satisfy [22], [3], [29]. As said before, the problem of expressing declarative constraints in an ObjectOriented data model has been analyzed by only a few authors. We recall, for example, the ALICE language [36], [34], that is used to express complex constraints by means of Horn logic expressions. Another proposal is related to the PIROL project [20], that is devoted to support complex objects and explicit semantic integrity constraints. Similarly, the ODE [21] system allows the definition of constraints, focusing on
131
actions to be taken in presence of violations. These proposals are very rich. However, their complexity precludes the possibility of investigating theoretical aspects of database schemas and, in particular, to define a clear declarative semantics needed to support the design of correct database schemas. In this paper, we propose a formal model for Object-Oriented databases which allows the definition of a schema in terms of types and constraints. The goal is to supply a uniform frame for the database designer, to define at intensional level not only the structural component (essentially the types) but also to enrich it with semantic integrity constraints. The intensional component of the model is presented by means of the language TO~ (Typing as Query Language). TO.,6represents the synthesis of the work carded out both at a theoretical [18], [16] and experimental [25] levels, within the project MOSAICO, at IASI-CNR, and the national research activity LOGIDATA+ [5], which aims at extending the functionalities of the Object-Oriented database systems in the direction of deductive databases. The guide lines of TOJ~ have been influenced by existing OODB systems, such as 0 2 [26], [27], [28], ORION [7], ODE [21], and by theoretical researches in the field [9], [ 12], [4]. The main features of TO,6model are: (i) clear separation between types and classes (and, therefore, between intensional and extensional components of the database), (ii) formal definition of class as a collection of objects, extension of a type in the schema, (iii) possibility of expressing explicit integrity constraints within the database schema, (iv) complex types modeling as sets of necessary and sufficient conditions for the corresponding objects. These characteristics are formalized using a pure denotational semantics and represent new issues with respect to existing proposals in the fields [27], [21], [7]. Existing systems present characteristics such as: (a) use of class names to define types, (b) semantics informally defined or, eventually, defined following an operational approach, (c) the notion of class derived from programming languages, i.e. as a structure encapsulating data and behaviour, rather than databases, i.e. as extension of a type declared in the schema, (d) absence of mechanisms associating integrity constraints to types in the schema, and integrity enforcement performed by methods, (e) complex types considered, essentially, for structuring purposes rather than for semantic integrity. The rest of the paper is organized as follows. Section 2 gives an overview of the main static characteristics of Object-Oriented data models, focusing on specific TO.# features. In Section 3, the innovative features of the TO.~ data model are introduced: the uniform view of type structure with ISA hierarchy and integrity constraints. Section 4 presents the formal syntax of TO,L and the notion of TO.,L schema. Furthermore, the definition of legal ISA hierarchy is given, and the normal form of types is introduced. In Section 5, the formal semantics of TO~ types and integrity constraints is shown, followed by the definitions of interpretation and model of a Tt2L schema. Finally, conclusions are given.
132
2 Main Features of Object-Oriented Data Models In this section, the main features of the static component of an Object-Oriented database model are presented [6]. It is agreed that a desirable feature of a database model is a clear separation between the intensional (i.e. schema) and extensional (i.e. data) components of the database [35]. This goal is not easily achieved in OODB model, due to its origin rooted in programming languages and the complexity of the model itself. For example, in the 0 2 data model, types are defined in terms of classes and their semantics are tightly interwoven. A second point is the co-existence of objects and values: what are their respective roles, when to use one or the other. We believe that avoiding their mixing will substantially increase the simplicity of the model, without loss of expressiveness. Let us briefly analyze both these issues. In TO~ data model, the intensional component (i.e. the schema) is represented by type-definitions. Type-definitions are T0.,6 formulas that can be composed without referring to database classes, objects, values, nor to any other extensional element. Classes and objects are not expressible in TO~ they belong to the realm of data. With this approach, we reach a complete separation between intensional and extensional components of the database. In this respect, the approach is closely related to logical theories, where types correspond to logical formulas and classes to their interpretations. About the dichotomy between objects and values, we agree with [9] and, in particular, with the notion of abstract object. Abstract objects represent any conceivable conceptualization of real (and sometimes unreal) world entities, from a simple integer or string, such as 27 or "ferrafi", to complex entities, such as persons and cars. Objects are denoted by a special class of names, called identifiers, or oids for short. There is a special class of "built-in" objects, on which the system is able to perform well defined manipulations, such as integers or strings. For those "fully axiomatized" objects, referred to as values, the state corresponds to the oid. In this perspective, values are reduced to a special case of oids, i.e. identifiers of fully axiomatized objects. Complex values do not exist, we have complex objects instead. Here, the Object-Oriented features of the TO~ data model are briefly presented. They are illustrated following the points exposed by [6], with few modifications due to the specificity of our proposal. Obiects and Values - Objects are the basic entities of an OODB, which is essentially seen as a collection of them. All objects are atomic and, unlike other proposals, they are not endowed with an "internal" state. Nevertheless, we distinguish elementary and complex objects essentially on the base of the relationships with other atomic objects. In this view, we can use the term state, for a complex object, to indicate the set of relationships with other objects. Such a state is associated to a complex object, and is represented by a tuple of labeled oids. Values are just special objects: they are elementary objects known to the system, and they do not need to be defined by an associated tuple. Obiect identity - This is a central notion for OODB models. Every object has an identity, given to it when it is created. Such an identity is unique within the database
133
and immutable throughout its lifetime. Oids give the possibility to specify the relationships that complex objects have with other objects. Object sharing is a desirable characteristic that originates from the use of complex objects within tuples. Comolex obiects - Complex objects are represented by those oids that have an associated tuple. Tuple constructors can be nested to any (finite) depth. Since we restrict the components to be only oids, we obtain complex objects inherently different from complex values [1], [23]. For example, elementary objects (values) are: 34, ted, fiat, john, 21, math, 150. Complex objects are: #per 12, #car3, #stud 1, and their corresponding tuples are: [name:ted, age:34, vehicle:#car3], [maker:fiat, speed: 150], [name:john, age:21, vehicle:#car3, dept: math]. Note that, to increase readability, oids of complex objects start with the character # (pound). Recursive obiects - This is a feature common to expressive Object-Oriented data models. The use of oids of complex objects in a tuple allows the reference to another tuple which, in turn, can reference the former. There are no limitations in the use of this mechanism, having also oids referencing their own structures (i.e. self-recursive objects) or participating in a circular chain of arbitrary length. Below, two recursive objects are given. mgr: (#empl2, [name:john, salary:50K$, head_of: #d3]) dept: (#d3, [name:toys, floor: 4, manager: #empl2]) Type - A type is an abstract representation of the characteristics common to a set of objects. Given an object, it is always possible to decide whether it satisfies a type or not. Type-definitions are sentences of TO,6 having a label, a definition expressed as a tuple of typed properties and, eventually, one or more integrity constraints associated to them. A database schema consists of a collection of type-definitions which, therefore, represents the first information to be given when creating a database. Then objects can be entered according to the types in the schema (unlike other systems, such as ORION [7], untyped objects are not allowed in TO# databases). The presence of type labels plays a primary role, allowing the definition of recursive types and, very desirable feature, avoiding the use of class names in type definitions. In the following, two type-definitions are illustrated. mgr := [name:string, salary:string, head_of: dept] dept := [name:string, floor:integer, manager: mgr]
134
Nested Tuoles - In a tuple, a property can be typed using a type label or another tuple. The former allows object sharability at extensional level, the latter allows the definition of nested tuple types whose instances will be represented by nested tuples of objects not sharable by other objects. For example: person := [name:string, address: [street:string, city:string]]. Recursive Types -TO~ allows a rich mechanism for recursion. We have a selfrecursive type when at least a property is typed using the same label of the typedefinition. In general, recursion is achieved when a type has a property typed with the label of a type-definition that, in turn, has a property typed with the former. The following is an example of recursive type-definition (note the use of curly brackets to indicate multi-valued properties): person := [name:string, age:integer, child:{person}]. Subtyping - Types are organized according to a generalization hierarchy, using the very powerful relationship of subsumption[10], also referred to as refinement [5]. The semantics of T0.~ subsumption includes the three kinds of structured inheritance inclusion, constraint, and specialization inheritance [6] - introduced in existing OODB systems. Essentially, subtyping implies the inclusion between the corresponding extensions of types, i.e. between the sets of objects that satisfy such types (classes). Therefore, subtyping is a partial order relationship over the set of types. Class - Classes form the extensional component of the database. There is one class for each type-definition in the schema. Classes are the repositories for objects, therefore, they represent an extensional notion. The notions of type and class are disjoint: they correspond, respectively, to the notion of formula and interpretation in a logical theory. In this view, the schema of a database is seen as a theory and the database as an interpretation. A database update represents a transition from an interpretation to another one. Extensibilitv - The set of types is extensible, in the sense that, given a database, new types can be defined, and there is no distinction between existing and newly defined types [6]. In the next section, we introduce the two main features of the TOJ~data model: the ISA hierarchy, based on strict refinement, and semantic integrity constraints. Their rigorous formulation and formal foundation are not common to existing ObjectOriented database [6].
3 Enriching OODB Schemas with Constraints The TO_Ldata model allows the definition of implicit and explicit constraints. Implicit constraints are expressed inside the tuple of the type definitions as, for example, cardinality constraints or domain constraints. Explicit constraints are associated to
135
tuples. They enrich the expressiveness of the model adding declarative knowledge to the schema, thus allowing the reduction of the procedural component of the database. We also consider inherent constraints, i.e. constraints that are imposed by the model itself, such as refinement constraints, related to the ISA construct, or aggregation constraints, related to tuples of typed properties. In this paper, T0,,6 refinement constraint will be analyzed only for what concerns the structural component of the language. Refinement is briefly introduced below, followed by a description of implicit and explicit integrity constraints. The next section will focus on refinement in a more detailed way.
3.1 The ISA Hierarchy In TO~, the ISA construct is used to define a type in terms of its supertypes. This construct can be followed by a tuple of typed properties. This represents the structural definition of the type (the dynamic definition, represented by methods, will not be tackled in this paper). A type defined by means of the ISA construct inherits the typed properties of its supertypes (it inherits explicit constraints as well, but here we concentrate on the structural aspects only). For each typed property, inheritance can be absolute, composed or refined. Inheritance is absolute if the property belongs to only one supertype and is not re-defined in the subtype. Inheritance is composed if the property belongs to at least two supertypes. Finally, inheritance is refined if the property belongs to supertypes and to the definition of the subtype. If inheritance is absolute, the typed property is inherited without any modification. In the second case, a composition of typing for properties having the same name is required. As we will show in Section 4, such a composition is obtained by considering a type (if there exists) that is subsumed [18] by the given ones. Finally, in case of refined inheritance, an overriding is required. In particular, the typed properties of the supertypes will be overridden by the one specified in the definition, if the latter is a refinement of the former. In case of properties belonging to more than one supertype and also to the definition of the type, composition is applied before overriding. The above conditions determine the legality of ISA hierarchies. This issue will be formally tackled in Section 4. In this subsection, some examples are provided. The following ISA hierarchy is legal: person := [name:string, age:integer] parent := ISA person [age:(10..150), child:{person} 1,5]. Note that TO~ allows the typing of properties by explicitly defining a range of values in parenthesis. Furthermore, in the example, cardinality constraints are associated to the multi-valued property child. In applying the refined inheritance to the property age, the condition of refinement between the type integer and the set of values specified in the tuple is satisfied. Refinement is violated in the following type-definitions:
136
vehicle := [maker:string, color: {(red,blue,green) }1,3] car := ISA vehicle [maxspeed:integer, color: {(yellow,red)} 1,2] , because the types of the property color are not in subsumption relationship. In the following, we sketch the TOoLrefinement rules, that have been developed in a first version in [18], on the line of [12]. Two types are in refinement (subsumption) relationship if the subtype is obtained from the supertype by: (i) adding one or more properties to the properties of the supertype, or (ii) refining the cardinality constraints of one or more multi-valued properties of the supertype, or (iii) refining one or more properties of the supertype by defining subsets of enumerated types, or (iv) refining one or more properties of the supertypes by typing them with labels of refined types. A type-definition which is not defined by means of the ISA construct is said to be in normal form. In the next section, the problem of the legality of the ISA hierarchy is analyzed in detail, and the related problem of normal form reduction of a typedefinition will.be addressed.
3.2 Implicit Constraints Being expressed in the tuple, implicit constraints are introduced through the flexible typing mechanism for properties. Implicit constraints can be classified into the following four cases. - Tvnin~ constraints In the preceding section, we have seen that properties can be typed using type labels. For example, in the type-definition: person := [name:string, age:integer, vehicle: {car }] car is a type label which needs to be defined in terms of a TO.# sentence. It imposes a typing constraint on the property vehicle, requiring that the vehicles of a person, whenever they are present, have to be cars.
- Domain constraints TO,# properties can be typed also using enumeration or an interval specification. Domain constraints have the form of a list, or an interval (in case of well ordered domains), defined using constant symbols. In the following example: car := [maker:(Fiat,Ford,BMW), m_speed:(120..200), owner:person] the instances of the type car will be only objects produced by one of the three listed firms. Furthermore, the maximal speed will be any integer falling in the specified interval. - (Tardinalitv con,traints As already mentioned, multi-valued properties allow the association of a set of objects to another object. In TO.#, it is possible to express constraints on the (minimal and maximal) cardinality of the sets denoted by multi-valued properties. For example:
137
person := [name: {string }1,3, age:integer, vehicle:{ car} +]. If m,M represent the interval extremes, in TO,t2sentences the absence of curly brackets is a short-hand for m -- M = 1, while curly brackets without cardinality constraints or followed by the + symbol are short forms for m = 0, M = o~, and m = 1, M -- oo, respectively. - Referential constraints A referential constraint is obtained combining typing and cardinality constraints. For example, in the following type-definition:
person := [name:string, age:integer, vehicle:car] each person is required to have one (and only one) vehicle, and this vehicle must be a car .
3.3
Explicit
Constraints
TO,L explicit constraints are comparisons over properties, expressed using the dotnotation formalism. They are specified in the schema, being part of the typedefinition. They are referred to as "0-constraints", where "0" stands for arithmetic comparators, such as "=", ";e", ">", ">". Comparisons are declared between values and, more generally, oids. For example: person := [name:string, age:integer, ssn:integer, child: {person} 1,5], icl: this.ssn ~ person.ssn teacher := ISA person [student: {person }+], ic2: this.student ;e this.child employee := ISA person [salary:integer, boss:employee], ic3: this.salary < this.boss.salary In the above schema, three explicit constraints are given. Note that, the first has the right hand side defined using a type-label, while the other ones use the keyword "this". In particular, the constraint icl states that the social security number (ssn) of a person must be different from the one of all the other persons. The second, expresses that teachers cannot teach to their children. The third states that an employee has to earn less than the salary of his boss. From this example follows that, in explicit integrity constraints, a type label denotes an entire class, while the keyword "this" refers to a single object. Note that, when the right hand side of the comparison starts with the type label of the type being defined, as for the integrity constraint icl, the type label denotes the corresponding class, less the object denoted by "this". In Section 5, we will see that a "0-constraint" is assumed to be universally quantified on the denoted sets (universal quantification on paths). For instance, in the above example, ic2 requires that all the students of a teacher have to be different from all his/her children. Furthermore, in TOj2, given a type-definition, explicit integrity constraints must be satisfied by every object in the associated class (universal quantification on classes). In this sense, all the teachers have to satisfy the constraint
138
ic2. With this assumption, the keyword "this" stands for a pseudo-variable ranging over the entire class.
4 F o r m a l Issues on D a t a b a s e Definition In this section, the syntax of the language TO~ is formally presented. The language is a direct derivation of 00.6, developed to analyze the relationships between ObjectOriented systems and the Frame-based systems proposed in Artificial Intelligence [32], [18]. Previous proposals of T0~ have been presented in [16], [17]. In the second subsection, the formal definition of TO~ schema is given. Finally, the legality of the ISA hierarchy is formally introduced and, successively, the normal form reduction of a type-definition, that is not in normal form, is illustrated. These notions are the basis of the static verification performed to check the correctness of TO~ schemas.
4.1 T0~ Syntax In TO~, we have terms and sentences. Terms can be tterms, p_terms, and c_terms. A t_term is a type label. A p_term is a property name. A c_term is a constant, or a sequence of p_terms (path) preceded by a t_term or the keyword "this". Sentences can be atomic, type-sentences, constraint expressions and type-definitions. An atomic sentence is simply a name, e.g. car, person, color, integer, or an enumerated set, e.g. (4,8,9,22) or (red,green,yellow). A type-sentence is defined using two basic constructors (not mutually exclusive): ISA and tuple. A constraint expression is a binary comparison predicate, taking two c_terms as arguments. A type-definition associates a t_term to a type-sentence or to an atomic sentence and, eventually, to one or more constraint expressions. In the following boxes, the formal syntax of TO~ is presented: non-terminal symbols are in small plain characters, while terminal symbol are in bold. Symbols in italics are user-defined strings.
Definition 4.1 Syntax of T0~. ::= t t e r m := [, ..... ] ::= IISA t t e r m ... t_term ::= t_term I I (value_set) I [<tp>,...,<tp>] ::= integer I real I boolean I string I T O P <tp> ::= p_term:{}m, M
m,M ~ 1~0 u {~}, m < M
The following box shows, in particular, how the value_set construct can be expressed. It canbe enumerated, or an interval specification. The interval can be open or closed.
139
Definition
4.1 continued: the (value_set) construct.
9 Enumerated Example : (red, green, yellow) (1,4,7,12) 9 Interval Stw,cification - (n..N) n,N are included - (n I t_term.<path> I k <path> ::= p_term .... .p_term ::= < 1 > 1 < 1 > 1 = 1 ~
4.2 TO# Schemas
In this subsection, we define the properties that a set of type-definitions must satisfy in order to be a TO/: schema. A non empty set of type-definitions S is fully defined (defined for short) if and only if all the t_terms used to form type-sentences and constraint expressions in S are
140
left hand side of type-definitions in S. Then, we have the following definition of T0os schema. Definition 4.2 TQL schema. A TO~ schema is a defined set of type-definitions,n Consider the set of To~ type-definitions: person := [name: {string} 1,2, age:integer, child: {person}] student := ISA adult [age:(18..40), college:university] This is not a schema because the t_terms adult and university do not appear in the left hand side of any type-definition, nor are they basic types. On the contrary, the set: person :-- [name: {siring }1,2, age:integer, child: {person }] student := ISA person [age:(18..40), college:string] is a TO,L schema.
4.3 Legality of the ISA Hierarchy In Section 3, we have seen that a type, defined by means of the ISA construct, inherits the definition of its supertypes. Typed properties of supertypes are inherited as they are (absolute inheritance), by composition (composed inheritance), or by refinement (refined inheritance). We have also anticipated that, the legality of the ISA hierarchy is related to the refinement of types of common properties. In this subsection, we give the formal definition of legal ISA hierarchy. Then, some examples, related to it, follow.
Definition 4.3 Legal ISA hierarchy. Given a schema, the ISA hierarchy of such a schema is legal iff ISA is not cyclic, and for each type-definition with ISA, the following conditions are verified.
1) Comoosed inheritance: for each property p_termh belonging to at least two supertypes (eventually belonging also to the definition of the type), as in the following: t_term := ISA t_terml ... t_termr [...] t_terml := [.... p-termh:{bodyl}ml,M1 .... ] t_termn := [.... p_termh:{bodyn}mn,Mn.... ] where 2 < n < r, there exists bodyh such that: if bodyi, i -- 1..n, are basic types or sets of values, than bodyh = N i bodyi r O if bodyi, i = i..n, are type labels or tuples, than bodyh is a type label of the schema, that is the greatest lower bound (glb) of bodyi, i = 1..n, according to the partial order induced by the subsumption relationship over types. Furthermore, there exists an interval of cardinality, [m h, Mh], such that,
141
for i = 1..n: [mh, Mh] = 0 i [mi, Mi] ~ O. Then, the inherited typed property, will be the following one: p-termh: {b~ }mh,Mh"
2) Refined inheritance: for each property p_term h belonging to supertypes and to the definition of the type, as in the following: t_term := ISA t terml ... t__termr [ .... p_termh:{bodyh}mh,Mh .... ] t_termi := [.... p_termh:{bodyi}mi,Mi .... ] where 1 < i < r, it results: bodyh is subsumed by bodyi. mi_< mh and Mh < Mi. The inherited typed property will be the following one: p_termh: {bodyh }mh,Mh. -
[] Note that, as already mentioned in Section 3, when a typed properly must be inherited by composition and by refinement, composed inheritance will be performed before than the refined one. Therefore, conditions related to refined inheritance will be verified on the typed properties inherited by composition. For example, the ISA hierarchy of the following schema is legal: vehicle := [maker:string, color:(red,green,blue)] car := ISA vehicle [colon(red)]. In fact, the property color has to be inherited by refinement, and the conditions related to types and cardinality intervals of such a property are satisfied. Also the following ISA hierarchy is legal: young := [name:string, age:(0..30)] mother := [name:string, sex:(female), age:(10..150)] youngmother := ISA young mother [age:(10..25)] because the property age is inherited first by composition, with typing (10..30), and then by refinement, with typing (10..25) specified in the tuple. On the contrary, the following ISA hierarchy: person := [name:string, age:(0..150), vehicle: {car}2, 3] student := [name:string, age:(18..40), vehicle: {car }0,1 ] gr_student := ISA person student [age:(23..40)] car := [maker:string, color:string] is not legal, because the conditions for composed inheritance are not satisfied. In fact, even if the property age is correctly inherited first by composition and then by refinement, for what concerns the property vehicle, the intervals of cardinality have empty intersection, Also the following ISA hierarchy:
142
student := [name:string, age:(18..40)] mother := ISA student [age:(20..150)] is not legal. In fact, the type of the property age is not a refinement of the corresponding type in the supertype student. However, these are patterns easy to correct; in fact, in order to obtain a legal ISA hierarchy, it is sufficient to consider the intersection (or a subset of it) of the types of the property age. For the example, the system will suggest to the designer to modify the type of the property age of a mother, with the interval (20..40). Similarly, consider the example: person := [name:string, age:(0.. 150)] teenager := ISA person [age:(13.. 19)] young := ISA teenager [age:(18..25)]. Also in this case, the system notifies the illegality and suggests, for example, the following correction: young:= ISA teenager [age:(18.. 19)].
4.3.1 Normal Form Reduction
In this subsection, we deal with the problem of reducing in normal form a typedefinition expressed by means of the ISA construct. To this end, inheritance is thoroughly applied (we consider schemas having legal ISA hierarchies) and typedefinitions are re-written by using only typed properties. In the following, it is shown how this problem is related to the possibility of verifying subtyping between types on the basis of their typed properties only. We show that this happens if the typedefinitions with ISA are normal form reducible. Let us introduce the following definition. Definition 4.4 Normal form reducible type-definition.
A type-definition with the ISA construct is normal form reducible iff, applying inheritance, it can be transformed into a semantically equivalent type-definition that is in normal form. ra Note that, two type-definitions are semantically equivalent iff they denote the same set of objects for all the interpretations. The above definition states that, if a type-definition is normal form reducible, then there exists another type-definition, in normal form, semantically equivalent to it. Normalized type-definitions are then used to verify subtyping. On the contrary, if the type-definition is not normal form reducible, subtyping is axiomatic, and cannot be proven. In such cases, the ISA construct represents more than inheritance. It represents an axiomatic set containment constraint that cannot be modeled by any structural component. For example, consider the following schema:
143
person := [name:string, age:(0..150)] student := ISA person [age:(18..40), friend:student]. In this case, the second type-definition is normal form reducible because it can be transformed into the following type-definition, semantically equivalent to it: student := [name:string, age:(18..40), friend:student]. Therefore, in this case, it is possible to verify that person is a supertype of student also using the last type-definition, i.e. only on the basis of their respective typed properties. Consider now the schema: person := [name:slxing, friend:person] student := ISA person [friend:student]. The ISA hierarchy of this schema is legal since student is a subtype of person. However, if we apply inheritance, and we override the property friend, we obtain the following type-definition: student := [name:string, friend:student] that is not semantically equivalent to the original one since student is not a refinement of person any more. In this case, the ISA conslluct is axiomatic and, therefore, it is not possible to establish that a student is a subtype of person on the ground of theh' structure, i.e. their typed properties. In this sense, we say that, if a type-definition is not normal form reducible, then the refinement relationship between types and supertypes is not effectively computable. Finally, we introduce the following definition. Definition 4.5 ISA certifiable schema. A schema containing at least one type-definition with ISA is ISA certifiable iff all its type-definitions with ISA are normal form reducible. [] Therefore, in a ISA certifiable schema, the system is able to verify the hierarchical relationships between type-definitions on the ground of their structure, and no axiomatic set containment relationships are given.
5 Formal
Semantics
of TQL
The semantics of TO~ given here follows a pure denotational approach [10]. With this approach, a type is a formula and a class is simply one of its possible extensions. Given an interpretation, there is a tight and immutable association between types and classes: given a type, there is only one class that corresponds to it. In this perspective, a class update causes a transition from an interpretation to another one. An interpretation is represented by a database state. Preliminary work, in this direction, has been carried out by comparing OODB systems and knowledge representation systems [32], [18].
144
Definition 5.1 The semantics of T0,# types and integrity constraints. Let 5", be a finite set of oids representing a given state of the Application Domain, T the set of T0,,6 sentences, and P ( c T ) the set of p_terms. Consider a function ~ from T to the powerset ~o(~): ~ : T ---> ~o(~) and a function I'I from P to the powerset ~o(Y, x Y,): 11: P-->
~(XxX).
Then, 8 is an extension function over Y. with respect to the type-definition:
t_terma := type [, c_expr ..... c_expr] iff the values of 8 on the type and integrity constraints are constructed starting from the values of their components as follows. Given a path = p_term 1.... .p_term n, we define the set Spath,x as follows:
S~path,x = { x } , ath,x = { Y ~ Y-[ <x,y> ~ Ilt p_term 1 ~ } Spath,x = { y ~ ~ l 3 (Yl .... Y n - 1 ) : ( x , y l ) ~ I I t P termlY, (Yl,Y2) r I-ltp_term2[ ..... (Yn-I,Y) ~ 1-Itp_te~mn[ }
if n = 0; ifn = 1; if n > 2 .
The extensions of types and an integrity constraints are computed following the structure of the syntax. Extension
of
tVDeS:
a) ~ b o d y [ b) ~ t I S A t_term...t_term body[ = (A i ~t_termi[) n ~tbody[ ~ body [ = c) ~ t t term [ e) ~t (value set) [ = {value set} n Z 0 gt[tp,..._tp][: Oj g t [ 6 j ] [ g~bt[ =
g) ~ intei~er ~ = Z n Z h) ~ r e a l ? = R n Z i) ~ b o o l e a n ~ = {true,false} n Z
1) ~ s t r i n g [ = $ m) ~ T O P ~ = Z
nZ
~ [tp] ~ = ~ [p_term:{bodY}m,M] [ = E 1 n E 2 where: E l = { X ~ 5".[ V y ~ Sn t e r m , x ~ y ~ E2={x~ X l m 3 Exceptions are added without changing the structure of the original program. Two mainly extensions have been proposed in the literature. The first one extends standard logic programming with a new form of negation, called classical negation [6, 10]. This approach permits two different negations: negation as default (denoted by not) and classical negation (denoted by -~). Programs consist of rules where negation by default can appear only in the body while classical negation can appear only in the head. The second approach considers only one form of negation and, therefore, allows for a uniform treatment of negation. Moreover, following this approach, it is possible to recognize a large class of programs, stratified negative programs, for which the definition of the intended model is a natural extension of the notion * Work supported by the CNR project "Sistemi Informatici e Calcolo ParMlelo" subproject "Logidata+'.
149
of stratified model as given for classical program. In this paper we present an algorithm for the efficient computation of the stratified model for a negative program and a technique for extending the magic set method to restrict this computation to those elements that are relevant in answering a query. The rest of the paper is organized as follows. In sections 2 we review some basic definitions and results concerning negative programs. In section 3 we present the class of stratified negative programs and we describe an algorithm for computing their stratified models. In section 4, we present an extension of the magicset optimization technique for negative logic programs. Finally, in section 5, we present our conclusions.
2
Negative
Programs
In this section we present our language, that is logic p r o g r a m m i n g without function symbols where negation may arise not only in the body but also in the head of rules. This language is an extension of I)ATALOG-' [15, 4, 11] and will be here called "DATALOG . An atom is a formula of the language of the form p(tl, ...,tin) where p is a predicate symbol of a finite arity m _> 0 and t92 ...,tin are variables or constants (arguments of the atom). A literal is either an a t o m (positive literal ) or its negation (negative literal ). An a t o m A, and its negation (i.e., the literal --A) are said to be the complement of each other. Moreover, if/3 is a literal, then --,B denotes the complement of B. A negative rule (or, simply, a rule) is of the form: A0 *-- A1, ..., An. where A0 is a literal (head of the rule) and A1, ..., A,, is a conjunction of literals (body of the rule). If A0 is positive then the rule is a seminegalive rule; moreover, if also A1,..., Am are all positive then the rule is a positive rule (or Horn clause). A rule with empty body is a fact. Given a rule r, H ( r ) and B(r) denote respectively the head and the body of r. With a little abuse of notation and whenever no confusion arises, we shall also see B(r) as a set of literals, i.e., B(r) = {A1,..., A,~}. A rule is a fact if it has an e m p t y body and is ground if it is variable free. A term, atom, literal or rule is ground if it is variable free. A -'I)ATALOG program is a set of rules. If all rules are seminegative (resp., positive) then the program is called seminegative or a DATALOG-'p r o g r a m (resp., positive or a DATALOGprogram). Let 79 be a "DATALOG program. 79+ (resp., 79-) denotes the set of all seminegative (resp., non-seminegative) rules in 79. The Herbrand's Universe of 79 (denoted by H~,) is the set of all constants occurring in 79. The Herbrand's Base of 79 (denoted by B~,) is the set of all possible ground predicates whose predicate symbols occur in 79 and whose arguments are elements of H~,. As there are no function symbols, both H~, and B~, are finite.
150
A ground instance of a rule r in 7) is a rule obtained from r by replacing every variable X in r by ~b(X), where ~ is a mapping from the set of all variables occurring in 7) to H r . The set of all ground instances of all rules in 7) is denoted by ground(7)). Let X be a set of ground literals whose atoms are in B~, ; then -~X denotes the set {-~AIA ~ X } , X + (resp., X - ) denotes the set of all positive (resp., negative) literals in X. Moreover, X" denotes all elements of the Herbrand Base which do not occur in X, i.e., X" = {AIA E B~, and neither A nor -,A E X}. A set of literMs X is said to be consistent if there not exist a literal A E X such that --,A E X. An (partial) interpretation for 7) is any consistent subset of B~, O -~B~,. An interpretation I is total if 7 is empty. Let I be an interpretation. Given a ground literal A, we say that A is true in I (resp., false in I) if A E X (resp., -~A E I). A conjunction A1, ...,An of ground literals is true in I if each Ai is true in I, and is false in I if there exists some Ai that is false in I. If a literal (or a conjunction) is neither true nor false then it is undefined in X. An interpretation I for 7) is a (partial) model for 7) if 1. for each A in I + and for each r in ground(7)) with H(r) = -~A, B(r) is false in I, and 2. for each --A in I - , either there exists r in ground(7)) with H(r) = -~A such that B(r) is true in I or for each rule r in ground(P) with H(r) = A, B(r) is false in I. Moreover, if 7 is empty then the model I is total. The existence of a total model is not guaranteed. In other words, given a model M, a ground literal may occur in M only if there is no rule that could contradict it (possibly by assigning suitable values to undefined literals in M-). However, a negative literal can be contradicted if it is reconfirmed by an non-seminegative rule. This corresponds to say that non-seminegative rules represent a refinement of the knowledge supplied by seminegative rules, thus they are a kind of exceptions to a theory. It turns out that a rule r in P - is meaningful only if there exists al least one rule in P+ whose head predicate symbol is is equal to that of r. From now on, we assume that P only contains meaningful rules. The problem of selecting the "intended" model for a "DhTtLOG program, i.e., the model which captures the semantics of the program, has been discussed in [7] suitable extensions of founded [14] well-founded [lS] and stable model semantics [5] have been proposed. In this paper we shall only consider the intended model only for the class of stratified "DATALOG programs, that are defined in the next section. To this end, we need to extend the classical immediate consequence transformation Tp [9] to negative programs. For each interpretation I, we define
7"p(I) = { A [ r E ground(P) A U(r) = A A B(r) is true in I } { A I r E ground(P)- A U(r) = -~A A B(r) is not false in I }
151
Recall that, according to our notation, ground(P)- contains all non-seminegative rules in ground(P). If P is a DATAL0(I" program then Tp coincides with Tp. We have that T~, is monotonic in the finite lower semi-lattice < I , C_>, where 2; is the family of all interpretations of P. T h e r e f o r e the least fixpoint of T~, denoted by T~r exists and there exists a natural i, i ~ 0 such that ~ ( 0 ) -As proven in [7], T ~ ( 0 ) is a model for P but not a total model; it is indeed a rather poor model as it contains only those negative elements that can be derived from the rules and such elements are not in general sufficient to derive all possible positive elements because of negative literals in the rule bodies. Nevertheless, as shown in the next section, a particular use of Tp(0) will eventually allow to determine the intended model of stratified "DATALOG programs. 3
Stratified
Negative
Programs
Let us first extend the concept of dependency graph as given for D A T A L O G ~ programs [15]. Given a -'DATALOG program P , the dependency graph of P , denoted by Gp, is a directed graph < N , A > such that N is the set of all predicate symbols occurring in P and A is defined as follows. Given two predicate symbols p and q, there exists an arc from q to p in A if there exists a rule r in P such that (i) the head predicate symbol of r is p, and (ii) one of the literals in the body of r, say Q, has q as predicate symbol. Moreover, the arc is marked if either Q is positive and H(r) is negative or Q is negative and H(r) is positive. Given two predicate symbols p and q we say that q such that 15 is a partition of the set of nodes of G~,, A is: {(Ni, Nj)INi, Nj E 15/~ 3k E Ni and i G Njs.t.(k, i) E G~,} and the following two conditions holds: (1) for each Ni E 15, there exist no p, q in Ni such that p < q, and (2) for each Ni, Nj E 15, if there exist p E Ni and q E Nj for which p < q, then for each iOE Ni and q G Nj, ~ , such that for each Ni, 1 < i < rn, whenever there are p, q for which q < p and p G Ni, then q is in some Nj with j < i. A topological sort < N1, N2, ..., Nm > represents a stratification of the predicate symbols in 79. Note that in general a program has several stratified dependency graphs; moreover, given a stratified dependency graph, there are several stratifications. In case of seminegative programs, the above definitions coincide with the definitions of stratified programs and stratification as given in [1].
Ezample 2. Consider the stratified program 793 that is shown in Figure 3) together with its dependency graph. p(X)
~--r(X,Y), q(Y).
~p(X) ( X, Y, V) ,) , p(Y). ~q(Y). q(X) ~ s~(rX -p(X)
+-r(X,Y).
I
P 9
l
q
"1
1
r
s
- - F i g u r e 3. Stratified Program 793 --
There are three stratified dependency graphs for 793 that are shown in Figure 4. The first graph gives the stratifications: Sx = < {r}, {s}, {p, q} > and $2 = < {s}, {r},{p,q} >. The second and third graph gives the stratification $3 = < {r}, {s,p, q} > and $4 = < {r, s}, {p, q} >, respectively. Note that the each node of the first stratified dependency graph corresponds to the set of nodes of a strong component of the dependency graph; moreover, the stratificatitions induced by this graph are the finest stratifications.
153
{p,q}
/
{r}
\
{p.q,s}
{p,q}
t{r}
t-
{s}
- - F i g u r e 4. Stratified Dependency Graphs
-
-
$3 = < {r}, {s}, {p, q} > and $4 = < {s}, {r}, {p, q} >. The topological orders $3 and $4 contain the elements corresponding to the strong components of the dependency graph. Let < N1,...,Nm > be a stratification of P and for each i, 1 < i < m, let 7)i = {rlr E 7) and the head predicate symbol of r is in Ni} and B~ = {AIA E Bp and the predicate symbol of A is in Ni}. Then we define:
M+= M~- =
it=
M~= .
~
1
7
- M +)
M t LJ J ' ~ ( M I ) M 1- U--,(B~ - i + )
6
+
Mm_ 1 I.J -p~(.rV/rn--1) M(
_I
- M,+).
M,~ is the stratified model of 7). Note that the stratified model is total and unique, thus it is independent from the stratified dependency graph and the stratification that have been chosen. In Figure 5 we present an algorithm for computing the stratified model of 7) . This algorithm first reads the program and, then, calls the procedure construct_dependency_graph that returns the dependency graph. Using the definition of dependency graph, this procedure can be easily implemented in such a way that its time complexity is linear in the size of the program. Then the algorithm calls the procedure strong_components which computes the strong components of the dependency graph. As the strong components define a partition of nodes that satisfy the conditions of a stratified dependency graph, the procedure also determines a topological sort for this partition (if any) and, then, it returns an ordered list of sets of predicate symbols, which represents a stratification of the program. If there exists no topological sort, then the procedure notifies that the program is not stratified through the boolean variable stratified. Using well-known graph algorithms, this procedure can be easily implemented in such a way that its time complexity is linear in the number of arcs and, therefore, in the size of the program. Once a stratification < C1, ..., Crn > is available, the computation of the positive literals in the stratified model is started, according to the order of the stratitification; this order coincides with order of the list C. First of all, the function sub_program returns the subprogram /5 that is obtained from P by taking all rules whose head predicate symbols are in (~. Then we compute N + = M + applying the naive method to a transformation T that is much simpler than J~. In fact T is evaluated in the following way:
T~,(X +) = {AIA = U(r), ,'E ground(75), B(r) is true in X + }
154
A l g o r i t h m Stratified.Model; Var P, #: Program;G:Graph;stratified: boolean; Q,M,N:set of Literal;
~ :set of Predicate.Symbol; C:list o] set of Predicate..Symbol; begin input(P);
construct_dependency-graph(P, G) ; strong_components(G, C, stratified); if stratified t h e n M + := $; for each C E C d o N + := P := sub_program(P, ~) Repeat
Q+ := N + ; N := T ( P , M + u Q + ) ; N + := N + - - , N until N + =
Q+;
M + := M + o N + endfor;
output('The stratified model is", M +) else
Output (" The program is not stratified") endlf
end; - - Figure 5. Algorithm Stratified_Model - -
where a positive literal B is true in X + if B E X + and a negative literal -~B is true in X + if B ~ X +. Thus T, as the classical transformation T, is independently applied to each rule, without having to check possible contradictions as it is instead required by 7~. This means that ~ can be computed in time linear on the size of the ground program. Possible negative literals that are derived by T are used to remove complementary positive literals. This subtraction can be done in O(h x !o9 h) where h is the size of the Herbrand Base. The number of iterations is obviously bound on the size of the Herbrand Base since at least a new positive literal is to be derived in every step. It turns out that the overall time complexity of the algorithm is O(h x loeh x l) where ! is the size of the ground program 9 . The algorithm can be improved by using hash indices for the subrtaction replacing the naive method with the semi-naive one in the computation of the fixpoint of T [16]; however, the application of the semi-naive method needs some attention for taking care of subtraction and, for the sake of brevity, it is not reported here. For the sake of the presentation, the actual implementation of the various procedures used in the algorithm are not described either. Note that the algorithm makes use of suitable data structures such as Literal, (i.e., a predicate symbol followed by a list of bound arguments), Program (i.e., a set o f lists of literals, where each list represents a rule), and Graph (i.e., the nodes are predicate symbols and the arcs are represented by adjacency lists).
155
4
Query
Answers
The algorithm of Figure 4 computes the whole set of the positive literals in the stratified model. This computation becomes exuberant in the case of answering queries, where only a subset of the stratified model is required. In the case of seminegative programs, this drawback is removed by using program rewriting techniques such as magic sets [2, 3], counting [2, 12, 3], magic counting [13] and others [16]. We claim that rewriting techniques can be also applied to stratified "DATALOG programs using simple adjustments for passing the binding on rules with negative heads. We next show how this can be done for the case of the magic set method, that is assumed to be familiar to the reader. Let 79 be a stratified "DAThL06 program, M + be the set of the positive literals in the stratified model of P, and Q be a positive literal (query). The answer of the query Q, denoted by AO, is the set of all elements in M + which unify with Q. We compute A O as follows: 1. Find the strong components of the dependency graph of 79; 2. Construct the program 75 by taking each seminegative rule in 79 without any modification and by replacing each other rule r into § as follows: H(~) = --,H(r) and for each B in B(r), "-,B is in B(f) if the predicate symbols of B and H(r) belong to the same strong components or B is in B(f) otherwise; 3. Rewrite the program 75 for the query Q by applying the magic set method; let Magic(790) and Modified(75) be the sets of magic rules and of modified rules in the rewritten program, respectively; 4. Construct the program Modified(79Q) by taking the rules in Modified(75) derived from seminegative rules of 79 and by modifying each other rule r as follows: the head H(r) is replaced by --,H(r) and each body atom B which is mutually recursive with H(r) with -,B; (this corrresponds to do the reverse substitution of step 2); 5. If the program 790 = Magic(79o)UM~ is stratified then use the algorithm of Figure 4 for computing the stratified model M+Q and A O consists of all literals in M+Q which unify with Q.
Example3. Consider the followin~l program 79 with the query Q = p(1,Y) : p(X,Y) +-- a(X,Y). p(X,Y) +-- a(X,Z), p(Z,Y). ~p(X,Y) +-- q(X,Y). q(X,Y) +-- B(X,Y). q(X,Y) +-- b(X,Z), q(Z,Y).
I
p,
q
The dependency graph G~, pictured above does not contain cycles with marked arcs and then 79 is stratified. In order to generate the rewritten program we first replace the non-seminegative rule -,p(X,Y)~--q(X, u with the seminegative rule p(X, Y),---q(X, Y) (step 2) and then we apply the standard magic-set method to the program (step 3). The magic-set method generates among other the modified
156
rule p(X, Y) ~- magic..p(X), q(X, Y) that is derived from the non-seminegative rule. Then we replace this rule with the modified rule --,p(X, Y),--,*agie..p(X), q(X, Y) (step 4). The rewritten program 79c,~is still stratified and is as follows:
magic..p(a) -magic..p(Z) ',-- magic..p(X), a(X, Z).
q(X, Y) ~-- magic_q(X), b(X, Y). q(X, Y) ~- .agir b(X, Z), q(Z, V).
.agio_qCX) -.agic.pCX)
I
I l
magic-q(Z) +-- magic_q(X), b(X, Z).
p(x,,) ~-
-asir
~p(X, Y) *---
magic..p(X), q(X, Y).
q
a(x, Y).
l
I "?"-"'7
0
As shown in the next example, it may happen that the program 790 is not stratified. Example,~. Consider the following program P with the query p(1,Y):
p(X,Y) ~-- a(X,Y). p(X,Y) +-- p(X,Z), p(Z,Y). ~p(X,Y) *-- q(X,Y). q(X,Y) ~-- b(X,Y). q(X,Y) ~-- q(X,Z), q(Z,Y).
~ --
q
The rewritten program "190 and its dependency graph are given below. The dependency graph is not stratified because there is a cycle with a marked arc, then the rewritten program 790 is not stratified.
magic-p(1) magic..p(Z) +- magic-p(X), p(X, Z).
q(X, Y) ~ magic..q(X), b(X, Y). q(X, Y) ~- ~,~gi~_q(x), q(x, z), q(z, v).
magic_q(Z) +---magic.q(X),
q(x,z).
p(X, Y) ~-p(X, Y) +-~p(X, Y) '--
~(x,Y). p(x,z), p(z,v). q(x,Y).
0
magic-p(X), magic-p(X), magic-p(X),
P'
q
II II
157
If the program 79Q happens not to be stratified, the only possibility to answer the query is to compute the whole stratified model by applying the algorithm of Figure 4 to :P rather than to PQ. However, the binding propagation of T~Q can be exploited also in the case PQ is not stratified by using the technique described in [8].
5
Conclusion
"DATALOG programs are function-free logic programs where negation m a y arise also in the head of rules and allow to single out exceptions to a theory without having to overload general rules with refinements for special cases. In this paper we have presented efficient techniques for computing the intended model of a stratified "DATALOG program or the part of it that is relevant to answer a query. These techniques do not require to transform a -'DATALOG p r o g r a m into an equivalent logic program without negated rule heads (serninegative version) as they are directly applied to the original program. This is very i m p o r t a n t since the seminegative version of a stratified -~DATALOG program m a y loose stratification so that finding the intended model becomes much more complex.
References 1. K. Apt, H. Blair, A. Walker, Towards a Theory of Declarative Knowledge, In Foundations of Deductive Databases and Logic Programming, Minker, J. (ed.), Morgan Kaufman, Los Altos, pages 88-148, 1988. 2. F. Bancilhon, D. Mayer, Y. Sagiv, and J.F. Ullman. Magic sets and other strange ways to implement logic programs. In Proceedings of the Fifth ACM Symposyum on Principles of Database Systems, pages 1-15, 1986. 3. C. Beeri and R. Ramakrisnhan. On the power of magic. In Journal of Logic Programming, 10 (3 & 4), pages 255-299, 1991. 4. S. Ceri, G. Gottlob, L. Tanca, Logic Programming and Databases, Springer-Verlag, 1990. 5. M. Gelfond and V. Lifschitz. The stable model semantics of logic programming. In Proceedings of the Fifth Intern. Conference on Logic Programming, pages 10701080, 1990. 6. M. Gelfond, V. Lifschhitz, Logic Programs with Classical Negation, In Proe. of the Seventh Int. Conf. Logic Programming, pages. 579-597, 1990. 7. S. Greco, D. Sacck, Negative Logic Programs, In Proc. of the North American. Conf. on Logic Programming, pages 480-497, 1990. 8. S. Greco, D. Sacck, Magic Set Transformation for Negative Logic Programs, Technical Report, 1992. 9. J.W. Lloyd, Foundations o/Logic Programming, Springer Verlag, Berlin, 1987. 10. R.A. Kowalski, F. Sadri, Logic Programming with Exeptions, In Proc. of the Seventh Int. Conf. Logic Programming, pages 598-616, 1990. 11. N. Leone, M. Romeo, P. Rullo, D. Sacck, Effective Implementation of negation in Database Logic Query Languages, In this volume. 12. D. Sacch and C. Zaniolo, The generalized counting method of recursive logic queries for databases. In Theoretical Computer Science, No. 62, pages 187-220, 1989.
158
13. D. Sacc~ and C. Zaniolo, Magic-counting methods. In Proceedings o] the 1987ACM SIGMOD Int. Conf. on Management o] Data, pages 149-59, 1987. 14. D. Sacc~t, C. Zaniolo, Stable models and Non-determinism for logic programs with negation, In Proc. A CM SIGMOD-SIGACT Syrup. on Principles o] Database Systems, pages 205-217, 1990. 15. J.D. Ullman, Principles o] Database and Knowledge-Base Systems, Vol. 1, Computer Science Press, Rockville, Md., 1988. 16. J.D. Ullman, Principles o.f Database and Knowledge-Base Systems, Vol. 2, Computer Science Press, Rockville, Md., 1989. 17. A. Van Gelder, Negation as Failure Using Tight Derivations for Logic Programs, in Foundations of Deductive Databases and Logic Programming, Minker, J. (ed.), Morgan Kaufman, Los Altos, pages 88-148, 1988. 18. A. Van Gelder, K.A. Ross, and J.S. Schlipf. The well-founded semantics for generM logic programs. In Journal o] ACM, Vol. 38, No. 3, pages 149-176, 1991.
Effective Implementation of Negation in Database Logic Query Languages * Nicola Leone 1 , Massimo Romeo 2, Pasquale Rullo 3 and Domenico Sacc~ 1 1 DEIS-UNICAL, 87030 Rende, Italy 2 ISI-CNR, 87030 Rende, Italy 3 Dip. di Matem~tica-UNICAL, 87030 Rende, Italy
A b s t r a c t . Total stable models provide a powerful semantics for D A T A L O ~ ~ programs which increases the expressive power of current database query l~nguage by means of non-determinism. An efficient algorithm for determining one of stable models of a DATAL0(I"programs, if any, is presented
so that stable models may have also a practical interest.
1
Introduction
is a logic programming language with negation in the rule bodies but without functions symbols. It is used as a database query language that, because of recursion, has an expressive power greater than relational algebra. The semantics of a DATALOG-~ program without negation is rather simple: the meaning of the program, i.e., the intended model, is given by the m i n i m u m model, that is the intersection of all total models. As soon as there are negative goals in some rule, the selection of the "intended" model becomes more complex and is a key issue of the current research. Total stable models have been recently proposed as the semantics for logic programs with negation and, then, also for DATAL06-~ programs. However, the existence of multiple stable models for the same program (or, on the other side, the lack of total stable) has caused some conceptual difficulties to researchers as the canonical meaning of a logic program is traditionally based on a unique model. Our claim is that this anomaly of total stable models is not a drawback but provides the ground for adding non-determinism to logic programming. Total stable models are also criticized because of the lack of an efficient procedure for their computation. In fact computing a stable model for DATALOG" programs is NP-hard. Also for this aspect, our claim that this is not a drawback as long as DATALOG" programs are able to formulate NP-hard problems; indeed, it must be required that finding a stable model be polinomyal only if the p r o g r a m formulates a polynomial problem. In this paper we present an effective algorithm for computing a stable model of a DATALOG" program. This algorithm is based on a backtracking search strategy and on some new interesting characterizations of stable models. DATALOG"
* Work partially supported by the CNR project "Sistemi Informatici e Calcolo Parallelo', subproject "LOGIDATA+".
160
The paper is organized as follows. In section 2 we give the preliminary definitions and basic notation and we present the theoretical results for characterizing stable models in Section 3. Finally we describe the algorithm in Section 4.
2
DATALOG
with
Negation
Let us first review the basic concepts and notation of the database logic query language DATILOGwith negation (or simply DATALOG") [16], that is Horn clauses plus negated goals in rules but without function symbols [7]. An atom is a formula of the language of the form p(tl, ..., tin) where p is a predicate symbol of a finite arity m > 0 and tl, ..., tm are variables or constants (arguments of the atom). A literal is either an atom (positive literal ) or its negation (negative literal ). An atom A, and its negation (i.e., the literal -~A) are said to be the complement of each other. Moreover, if B is a literal, then -,B denotes the complement of B. A rule is a formula of the language of the form A ~ A1,...,An. where A is an atom (head of the rule) and A1,...,An is a (possibly, empty) conjunction of literals (body of the rule). Given a rule r, we shall denote the head of the rule by H ( r ) and the body by B(r), i.e., H ( r ) = A and B(r) = A1,..., An. With a little abuse of notation and whenever no confusion arises, we shall also see B(r) as a set of literals, i.e., B(r) = {A~, ...,An}. A rule with empty body is called a fact. A rule without negative literals in the body is positive, i.e., it is a Horn clause. A term, atom, literal or rule is ground if it is variable free. A DATALOG-' program is a finite set of rules. A DATALOG" program is positive if all its rules are positive; in this case it is also called a DITALOG program. Let a DATALOG"program 79 be given. The Herbrand universe for 79, denoted H~, is the set of all constants occurring in 79. If there is no constant in the program then one is added arbitrarily. The Herbrand Base of 79, denoted BT~, is the set of all possible ground atoms that can be constructed using the constants in HT, and the predicate symbols occurring in 79. Note that both H~, and B~, are finite. A ground instance of a rule r in 79 is a rule obtained from r by replacing every variable X in r by r where r is a mapping from all variables occurring in r to H~,. The set of all ground instances of all rules in 79 is denoted by ground(79). Let X be a set of ground literals whose atoms are in B~,; then -,X denotes the set {-~AIA E X}, X + (resp., X - ) denotes the set of all positive (resp., negative) literals in X. Moreover, X denotes all elements of the Herbrand Base which do not occur in X, i.e., -X = {AIA E B~, and neither A nor -,A E X}. Given a ground literal A, we say that A is true in X (resp., false in X) if A E X (resp., -,A E X). A conjunction A1,..., A , of ground literals is true in X if each Ai is true in X, and is false in X if there exists some A / t h a t is false in X. Note that
161
a literal (or a conjunction) can be both true and false in X or, even, neither true nor false; in the latter case, it is undefined in X. Given X C_ B~,U~BT~ and Y C_ B~,, Y is an unfounded set w.r.t. X if for each rule r in ground(7)) with H ( r ) E Y, B(r) is false in X or B(r) A Y # 0 [18, 19]. The union of all unfounded sets w.r.t. X, is also an unfounded set w.r.t. X , is called the Greatest Unfounded Set, and is denoted by GUS~,(X). As pointed out in [18, 19], GUS~, is a monotonic transformation from 2 B ~ u ' ~ to 2 B ' . Let us now introduce another important transformation from 2 BT'~ to 2 BT', called the immediate consequence transformation and denoted by T~,[7]. This transformation is defined as follows: for each X C B~, O --B~,, T~,(X) = {AIA = H ( r ) , r E ground(7)) and B(r) is true in X}. Observe that T~, is monotone in a finite complete lattice and, then, the least fixpoint of T~,, denoted by T~~ exists and coincides with T~(0), for some natural k, where T~(0) = 0, and for each i > O, T~(O) = T~,(T~-I(O)) [15]. Let us now introduce the important notions of interpretation and model in the domain of partial interpretations. Given I C_ Bp U -~Bp, I is a (partial) interpretation of 7) if it is consistent, i.e., I + A - - I - : 0 so that a ground literal cannot be, at the same time, true and false in [. Moreover, if 7 = 0, the interpretation I is called total and, in this case, any ground literal will be either true or false in I. As far as the notion of model is concerned, we first recall the classical definition of model for total interpretations: a total interpretation M of 7) is a total modelofT) if for each r in ground(P), (1) H(r) is true in M or (2) B ( r ) is false in M. As shown in [14], such models have the following characterization: a total interpretation M is a total modelifand only i f - - , M - is an unfounded set w . r . t . M . We point out that there are several alternative views on how this definition model is to be extended to the domain of partial interpretations [4, 11, 13, 14, 18, 19]. Following [13, 14], we shall say that an interpretation M of 7) is a (partial) model ofT) if for each r in ground(7)), (1) H(r) is not false in M (thus it is true or undefined), or (2) B ( r ) is false in M. Note that, in case M is a total interpretation then the above condition (1) reduces to H(r) is true in M. Thus, this definition of model is a rather natural extension of the definition of total model. This is confirmed by the fact that models preserve the same characterization in terms of unfounded sets as total models: an interpretation M is a model if and only if --,M- is an unfounded set w . r . t . M . A DATALOG" program 7) has in general several models but only one of them, the so-called "intended" model, represents the natural meaning of it. It is wellknown that if 7) is positive then the intended model is the total model M7 whose set of positive literals M + coincides with T ~ (0), thus M + contains all literals that can be inferred from the rules of the program. Note that MT is also the m i n i m u m model of 7), i.e., for each total model M of 7) M + C_ M +. On the other hand, in case 7) is not positive, MT is not any-more guaranteed to be a model as M T = --,(B~, - T ~ (0)) is not necessarily an unfounded set. Therefore, the issue of what model to base the semantics of a DATAL0(]-" program becomes much more complex and alternative definitions of the intended model have been
162
made in the literature, e.g., negation by failure [3], stratified model [1, 2, 9, 17], locally-stratified model [10], well-founded model [18, 19], total stable models [6], and various extensions of stable model in the domain of partial interpretations [12, 13, 14]. As discussed in the next section, we shall take the total stable model as the intended model of a DATALOG"~ program. 3
Total
Stable
Models
A first common requirement of the various proposals of semantics for nonpositive programs is justifiability[20], i.e., the positive literals of the intended model must be inferred from the rules of the program through the immediate consequence transformation as for positive programs, but possibly using negative literals as additional axioms for the inferences. This requirement is found under several names in the work of several authors (e.g., the notion justifiability used in [20] is similar to that of 'stability' [6] or that of 'founded models' [13]), and can be formalized by the following condition: D e f i n i t i o n 1. Given a model M of T~, the stability condition holds for M if there
exists X C_ M - such that S~,x($ ) = M +, where the transformation ST,,x : 2 n'u-'B" ---* 2 n" is defined as follows: for each Y C_ B~ U ",BT,, ST,,x(Y) = T~ ( X U Y). Thus the negative literals in X are used to infer the positive literals in M +. Obviously if such an X exists then we can use also M - instead of X for such inferences; so we could have used directly M - in Definition 1. The reason we have stressed that the whole M - is not necessary in the definition will become clear later in the paper when we shall use a suitable subset of M - to compute a justified model. A second requirementi s minimal undefinedeness, i.e., the intended model M may not retain literals in M that could be otherwise included in M + or M - . This requirement can be implemented in different ways, each of them resulting in an alternative definition of intended model. The strictest implementation requires that M be empty, thus M is a total model; this requirement together with the one of Definition 1 provides the following definition of total stable model that is equivalent to the original definition given in [6]: D e f i n i t i o n 2 . A model M of'P is a (total) stable model of 1) if both M is total
and the stability condition holds for M . In this paper we shall assume that the intended model of a DATALOG-"program be a total stable model that, from now on, we shall call stable model for short. We point out that a DATALI36"program could have several alternative stable models or even none. Therefore, as uniqueness and existence have been a basic requirement for any classical definition of intended models, it would seem that our choice for intended models has a serious drawback. Instead our claim is that the lack of the two above properties is an actual advantage as it increases the
163
expressive power of DhTALOG"~. Indeed, the existence of several intended models entails for the implementation of a powerful non-deterministic choice mechanism as demonstrated by the following two examples taken from [14]. On the other hand, the lack of stable models means that the problem has no solution (see Example 2). Example 1. The following program states that glasses must be colored with one of the available colors but two glasses cannot share the same color. Colors and glasses are defined by a number of facts. colored(G, C) ~-- color(C), glass(G),-,diffChoice(C, G). di f fChoice(C, G) +-- colored(C, 1~), G r G. d i f f C h o i c e ( C , G) +-- colored(C, G), C r C. Note that the non-determinism is here used to perform a "don't care" choice. This program admits at least one stable model, thus the problem has a solution no matter is the base of facts for colors and glasses. In particular, if the number of available colors is less than the number of glasses then some glass will have assigned no color. ! Example 2, Consider the following program that computes a kernel of a directed graph whose nodes and edges are defined by a number of facts with predicate symbol n and e, respectively. A kernel is a subset of nodes such that no two nodes in the kernel are joined by an edge whereas every node that is not in the kernel is joined to some node of the kernel. Finding a kernel of a graph is an NP-complete problem [5].
a(x) joined_to_iV(X) disconnectedY_f rom~ conneded_N kernel kernel
.(x),-,n(x). ,+- e(Y, X), fi(Y). ,--- ~( X ) , - , j o i n e d J o . ~ (X ) . ,-- h( X ), joined_to_N ( X ). ~ --,disconnected.T_from_N , --,connected_IV. ~-- --,kernel.
The first two rules realize a partition of the nodes into two classes 2V and -N. In a stable model of the program the former class 2V will represent the kernel, while the latter will collect all nodes outside the kernel. If M is a stable model of the program then kernel is in M+ ; in fact, because of the last rule, --,kernel cannot be in M, as the falsity of kernel would falsify the rule kernel 0 such that W ~ ( 0 ) = W~(0). Thus W ~ ( 0 ) i s the least fixpoint of W~, and is called the well-founded model of P [18, 19]. The following property holds. F a c t 2 The well-founded model of a DATALOG" program 7) is a model of 79 and is contained in any stable model of 7~. O We point out that, as a stable model is total, it is sufficient to return just the positive literals of it. Therefore, negative literals need not be computed unless they are necessary to perform inferences of positive literals. This means that, in order to efficiently compute a stable model, the transformation W~, should be modified by replacing the (3US with a subset of it containing only those literals in the (:;US whose falsity is useful to draw positive conclusions. This subset is called the Greatest Useful Unfounded Set ((3UUS).
Example 3. Consider the program ae-b. C 4--- -'~d~
and let M - 0. It is easy to see that GUS(M) - {a,b,d}. However, only the element d is useful for positive derivations; so GUUS(M) : {d}. We next give a formal definition of the GUUS. To this end, we first need to introduce the important notion of Possibly Unfounded Conjunction. D e f i n i t i o n 3. Let 7) be a DATALOG" program and X C_ B~ U'~B~,. A non-empty subset Y o f ' X is a possibly unfounded conjunction w.r.t. X if there exists a rule r in ground(P) such that:
1. 2. 3. ~.
H(r) qL X +, and ~ Y C B(r), and all positive iiterals in B(r) are true in X , and no negative literal in B(r) is false in X .
165
The set of all possibly unfounded conjuctions w.r.t. X is denoted by PUCST~(X). Moreover, given Z C_ B~,, the restriction of PUCS~(X) to Z, denoted by I:UCS~,(X/Z), is PUCS~(X/Z) = {CIC ~ PgCS~(X) ^ C C Z}.
0 Example 4. Consider the program a~--b. c 4--- -~d. e *-- -~e,-~b. and let M = O. It is easy to see that t ~ C S p , M ( M ) -" {{d},{b,e}}. Note that, given Y = {b, d}, PUCS~,.M(M/Y) = {{d}} since the possibly unfounded conjunction {b, e} is not contained in Y. We are now ready to give the definition of GUUS. D e f i n i t i o n 4 . Let a D A T A L O G ~ program 79 and X C Bp U -~BT~ be given. The Greatest Useful Unfounded Set of 79 w.r.t. X is
6vus (x) :
U
(c).
ce ~ c s ~ (x/c~s~ (x))
Example 5. Consider the program of Example 4. For M = 0, we have that GUST~(M) = {a, b, d}. Since the only possibly unfounded conjunction that is contained in {a, b, d} is {d}, GUUST~(M) = {d}. We next show that the well-founded model can be determined by replacing the (3US with the GUUS in the transformation W~,. D e f i n i t i o n 5. Given a DATALOG~ program 79, the transformation VT~ is defined
as follows: for each X C_ B~, tO -,BT~
v~,(x)
= T ~ ( x ) u ~ a ~ ; s ~ ( T ~ (x) u x - ) u x -
The transformation V~, is not monotone. Nevertheless, the sequence V~(O), i > O, V~(O) = V~,(V~-I(O)), is a monotonic sequence of models. Hence, the fixpoint V~~ exists and, as the Herbrand base is finite, there is a natural i such that V ~ ( 0 ) = Vr Now we are in a position to state a fundamental result that has been proven in [8]. F a c t 3 Let 79 be a DATALOG" program and Mwl be the well-founded model of 79. Then, M = V~(O) is a model of 79, M + = MgI,+ and M U -,GUS~,(M) =
M~I.
O
166 From the above fact, it follows that the positive literals of the well-founded model can be found using the transformation V~,. Note that if the well-founded model is total then it is also stable; therefore, in this case, no further computation is needed. Recognizing whether the well-founded is total or not can be easily done using the following result of [8]. F a c t 4 Let 7" be a DATAL0fl" program and M = V~~ Then the wellfounded model ofT" is total (i.e., it is a stable model) if and only if PUCS~,(M) =
!
O. Example 6. Let us compute the stable model for the following program c
~-.. --le.
a~-.-c. b+--~a.
d,.-b. e+...-f,
As V~,(O) = O, we have T ~ ( V # ( O ) ) = 0, PUCS~,(O) = { { a } , {e}}, GUS-p(O) = {e, f } and, then, GUUS~,(O) = {e}; so V~,(O) = V~(V#(O)) = {--,e}. NowT~(V~,(O)) = {a, c} and ~ V S ~ ( { a , c,-,e}) = 0 as m C S ~ ( { ~ , e,-,e}) = O; so V#(O) = V~,(V~(~)) = {a, e,-,e}. As V#(O) = V~,(V~>(O)) = {a, c, ~e} = V~>(O), V~>(O) is the fixpoint of V~,. Therefore, {a,c} is the set of positive literals in the well-founded model Mw! of 7'. Since PUCS~,(V~,(O)) = 0, the well-founded model is total, thus {--,b,-~d-,e,--,f} = M~, 1 . If the test of Fact 4 fails, we have to perform further computation to deter, mine a stable model. To this end, we have to move beyond the fixpoint V ~ ( 0 ) . Let us show how this can be done using first an example.
Example 7. Consider the following program: |
a ~ - -nO, "aC. C *--- "na.
b *--- -~a. a~--c.
We can easily see that O is the well.founded model Mtoi that is obviously partial and coincides with V~~ We have that PUCS~,(Mwl) = {{a}, {b, c}}. Now, in order to move beyond the well-founded model M~ol , we assume the falsity of all literals in one of the elements of PUCS~,( Mw l ) to draw new inferences. For instance, if we add both ",b and --% we get that a is true, i.e., we obtain M = {a, c, -~b}, that is a stable model (Note that selecting b or e alone is not sufficient to draw new inferences.) On the contrary, adding -~a leads to a contradiction, as a will be then derived. O We now formalize the above intuition by introducing an extension of V~,.
167
D e f i n i t i o n 6 . Let P be a DhTALOG~ program and C be a choice function, i.e., a function which selects an arbitrary element from a set. Then the transformation Vp,c : 2BT"u'B~ ---+2 BT"u'B~ is defined as follows: for each X C BT~ U "-,B~,, V~,e(X) = f V~(X) ifV~(X) # X [ x o { - ~ c ( P u c s ~ , ( x ) ) } otherwise
D There are as many transformations V~',c as the number of different functions C. Furthermore, for any choice function C, the sequence Vr i > 0, is a monotonic increasing sequence of subsets of B~, U -~B~, and the least fixpoint of it, denoted by r ~ , c ( 0 ) , coincides with some element of the sequence. The following result holds. F a c t 5 Let P be a D A T A L O G program. Then 1. for each choice function C, V~(O) C_ (/~,c(O), 2. if for some choice function C, M = (/~,c(0) is an interpretation of 79 and PUCS.p(M) = 0, then M is a model of 79, and M U--,M is a stable model of 79; 3. if N is a stable model of 79 then there exists a choice function C such that N = M U-~'ff, where M = 9~,c(0 ).
D Facts 3, 4 and 5 provide the ground for constructing an efficient algorithm for computing a total stable model. This algorithm is described in the next section.
4
Computing the Total Stable Model
A l g o r i t h m Stable_Model; var M : Literals; P : Program; stable : Boolean begin i n p u t (P); Compute_V ~176 (P, M); Compute_V ~ ( P, stable, M); if stable t h e n o u t p u t ("A stable model of :P', M +) else o u t p u t ("no stable model for P") endlf end Stable_Model. Fig. 1. Algorithm Stable_Model
168
In this section we present an algorithm for computing a stable model that is based on the results of the previous section. This algorithm, described in Figure 1, takes a DATALOG"~program P in input and first fires the function Compute_Voo which computes the fixpoint V ~ (0). Then, it calls the procedure Compute_Voo which searchs for a choice function C satisfying the conditions of Part (2) of Fact 5. In case of a successful search, the procedure Compute_Voo notifies that a choice function C has been found by assigning the value true to the boolean variable stable and returns M = r~.c(0); the algorithm then outputs M + which coincides with the set of positive literals of a total stable model. (Because of totality, there is no need to output negative literals.) On the other hand, a possible search failure is indicated by the value false for the variable stable; in this case, the algorithm reports that the program admits no total stable models. Finally, observe that Program and Literals are data types for storing sets of rules and of ground literals, respectively.
P r o c e d u r e Compute_Vcc(P : Program; var M : Literals); var 57/: Literals; begin M := ~; repeat
~1 := T~176 M-; M := .~f U -~(7~]US(P,,~I) until M = / f / end Compute_Vet; Fig. 2. Procedure Compute_V ~162
The procedure Compute_Voo is shown in Figure 2 and performs the computation of V~'(@) using a simple iteration scheme. Note that the procedure makes use of two functions: T ~ and GUUS. The function T ~ simply computes the fixpoint T ~ ( M ) ; for instance, it can make use of relational algebra and of an additional fixpoint operator [16]. For the sake of presentation, we assume that Too is a built-in function. The function GUUS computes tim GUUS and will be described later in this section. Note that, by Fact 3, the procedure Compute_Voo computes the set of all positive literals of the well-founded model. After computing M = V~~ the procedure Compute_f z~ of Figure 3 is called. This procedure tests whether PUCST,(M) = @. If this test succeeds, then M + is the set of positive literals of a total stable model by Fact 4 and, therefore, the procedure returns the value true for the variable stable as the well-founded model is also stable. Otherwise, by Part (2) of Fact 5, the procedure has to find a choice function C such that M is an interpretation of T' and PUCSv(M) = 0, where M = fz~,c(@). The procedure is essentially based on a backtracking strategy (from which the name Backtracking Fixpoint [13]). To this end, the function make_list stores the elements of PUCSv(M) into a list L of possibly unfounded
169
Compute_f'~ : Program; var stable : BOOLEAN; v a r M : Literals); v a r N, M : Interpretation; L : List of Literals; Y : Literals; begin if PUCS(P, M) = ~ t h e n stable := true Procedure
else
stable := false; L := make_list(P, trdCS(P, M)); N := M; while not stable a n d (L ~ ~) do Y := pop(L); (* pop the first possibly unfounded conjunction from L *) M := N U -~Y; r e p e a t (* compute the next fixpoint of Vv *) ~I := TCc(P,M) U M-; M := h;/U -~GUUS(P, l~l) until (M = J~/) or (M N ~M ~ 0); if M A-.M = 0 t h e n (* M is an interpretation *) Cornpute_l/'~ (P, stable, M) endif endwhile endif e n d Compute_f/~ ; Fig. 3. Procedure Compute_V ~
conjunctions, that is ordered by according to any predefined ordering of the Herbrand Base. We construct the choice function by taking the first element of L; M is stored into N in order to possibly backtrack to the next element. Then we move to a new fixpoint M of V~,. Of course as soon as we realize that M becomes non-consistent (i.e., it is not an interpretation) we try with the next possibly unfounded conjunction of the list. If the are no other elements left in the list, the procedure stops returning the value false for the variable stable. In case no contradiction arises then the procedure Cornpute_V ~ is recursively called to test whether PUCSp(M) is e m p t y for the fixpoint M of V~. It the test succeeds then M + is the set of positive literals of a stable model by Part (2) of Fact 5 and, therefore, the procedure returns the value true for the variable stable as a total stable model has been found. Otherwise, we move to a next fixpoint of V~,. In sum, if a choice function C satisfying the condition of Part (2) of Fact 5 exists, it will be eventually found by the backtracking search strategy. On the other side, if such a function does not exists, the program has no stable model by Part (3) of Fact 5; so the procedure correctly reports this situation by returning the value false for the variable stable. Note that the procedure makes use of the functions PUCS and (:~US, that will be defined later in the next section, and of the simple functions make_list and pop that can be thought of as a built-in functions.
170
Example 8. Consider the following program: a+--b. c~--~a.
d +---c, ~e, ~ f . e *--~d.
f *-- - d . g +---e,-,g. The procedure of Figure 1 works as follows. First, the procedure Compute_V ~176 returns M = {c, ~a}; then the procedure Compute_~/~ is invoked for the first time. Since PUCST~(M) ~ 0, stable is set to false and, by selecting the alphabetic order, L 1 is set to < { d } , { e , f } >; moreover, N 1 -- M - {c,-~a}. (We use a superscript for identify local variables of different instances of the proce. dure Compute_~/~.) Then {d} is taken from L 1 so that L 1 becomes < {e, f } > and M = {c, e, f , - a , ",d} is computed. Since M is an interpretation, the procedure Compute_f/~ is invoked for the second time. Since again t~CS~,(M) 0, the list L 2 = < {g} > is created; so, by taking the first element, M be. comes {c, e, f, g, -,a,',d, - g } and, then, is not consistent. So the next possibly unfounded conjunction of L 2 is to be considered. But L 2 is empty; so the procedure stops and the first instance of the procedure Cornpute_~/~ is resumed. Since stable is false, the possibly unfounded conjunction {e, f } is taken from L 1 and M = {c, d, ~a,'-,e, ",f} is obtained. Since M is an interpretation, the procedure Cornpute_V ~ is invoked again. This time FUCS~,(M) = 0; so stable is set to true and the procedure stops. The first instance of the procedure Compute_f/~ resumes and, as stable is true, it stops so that the main program can take over and it outputs M + = {c, d}. A stable model is indeed {c, d, ",a, "~b, ",e, - f , ~g}. Let us finally show how the functions for computing the PUGS and the GUUS can be implemented. Definition 3 can be immediately used to devise a simple algorithm for computing the / ~ C S . We present this algorithm as a function (see Figure 4) that makes use of the special predicate symbol not that is evaluated as follows: given X C B~, U-,B~, and a ground literal A, not(A) is true in M if A is not in M, otherwise it is false. The function constructs a program/~ by taking all the rules of P with negative literals in the body and restructuring them so that the above negative literals are moved to the rule heads. The head of a rule is actually a conjunction; if the body is true in M (i.e., all positive literals are true, no negative literal is false and the head is undefined) then the whole conjunction is derived by applying the immediate consequence transformation. Possible non-undefined literals in the conjunction are removed in the next iteration. Example 9. Consider a program having { a, b, c, d} as Herbrand Universe and containing the following rule:
p(X)
171
F u n c t i o n PUCS(P : Program; M : Literals) : Set o] Literals; vat PUCS1, PUCS2 : Set o] Literals;C : Literals; P : Program; begin
P := 0; for e a c h r E P s.t.
B(r)- # 0 d o
(* let B ( r ) - = -~A1, ...,--A, *) P := Pt.J {-~B(r)- ~-- B(r) +, not(-~B(r)-), not(H(r)), not(-~H(r)).} endfor PUCS~ := T(P, m); PUCS2 := 0; for e a c h C E PUCS1 d o C := C - "-M-; if C # 0 t h e n PUC9~ := PUCS2 u {C} endlf; endfor; return ~ C S 2 end PUCS;
Fig. 4. Function PUGS
This rule in transformed by the function PUCS of Figure 4 into the following rule: {s(X), u ( X ) } ~-- q(X), not(s(X)), not(u(X)), not(p(X)), not(-~p(X)).
Let M = {q(a), q(b), q(c),-,s(b), ~u(a), ~u(b), p(c),--p(d)}. By applying the transformation T to the above rule, we obtain PUCSx - {{s(a), u(a)}, {s(b), u ( b ) ) ) . Let us now construct IrdCS2. In the first conjunction {s(a), u(a)}, u(a) is in - , M - ; so only {s(a)} is added to FUCS,. As both s(b) and u(b) are in - , M - , the next conjunction is removed. Therefore, I=UCS1 = {{s(a)}}. Definition 4 is not very effective as it is based on the definition of the GUS whose c o m p u t a t i o n we want to avoid. Therefore we shall next give a different definition of the GUUS. To this end, we need to expand the t=UCS to include all undefined a t o m s t h a t can be useful to prove the unfoundness of elements in the FUCS.
Example 10. Consider the program rl : f ~-- a,~b. r 2 : g ~ C, ~d. r3:b~---e. r4:e~---b.
172
and let M = {a}. Now, observing rule rx, it is easy to see that proving that b is unfounded is useful for the derivation of f (i.e., {b} is a possibly unfounded conjunction). The same reasoning does not apply to d, as c is not true in M (see rule r2). On the other hand, as b depends positively on e (see rule r3), the unfonndness ore is needed to prove the nnfoundness orb (and vice versa). We now formalize the intuition of the preceding discussion by giving the definition of closure of PUCS. D e f i n i t i o n 7 . Given a D A T A L O G program P and X C_ B~, U",B~, , the closure of m C S ~ , ( X ) , denoted by m C S ; , ( X ) , is defined as follows:
1. A is in PUCS~,(X) if it is in some element of PUCS~,(X), and e. A E "X is in PUCS~,(X) if there exists r E ground(P) with head in PUCS.},(X) such that B(r) is not false in X and A e B(r) +.
Example 11. Given the program in the Example 10 and the model M = {a}, it is immediately recognized that I~CS~,( M ) = {b, e}. Following [11], given X C_ B~, U -,By, we define the transformation F'p,x as follows: for each Y C_ B~,,
F~,,x(Y) = {A G YiVr e ground(P), H(r) # A V B(r)is false inX U -~Y} The following important property is proven in [8]. F a c t 6 Let P be a DATALOG" program and X C_ B~, U "~B~,. Then,
6UUS~, ( X ) = PUCS~ ( X / F~,,x ( t:UCS~ ( X ) ) ) .
Thus Fact 6 is a constructive definition of the GUUS that is suitable for a simple and efficient implementation as shown in the function GUUS of Figure 5. Note that in this function we construct rules whose body is of the form < Q1 > < Q2 >, where Q1 and Q2 are two conjunctions of literals. Moreover we introduce a function T which is applied to a program and a pair of set of literals, say X and Y, so that for every rule of the program, Q1 is evaluated w.r.t. X whereas Q2 is evaluated w.r.t.Y. Finally, F p , M ( Y ) is computed as Y - ~'P,M(Y) where
P~',M(Y) = {A E Y l 3 r G g r o u n d ( P ) , H ( r ) = A and B ( r ) is not false in M U - , Y } .
173
F u n c t i o n (3UUS(P : Program; M : Literals) : Literals; var/5, ~ : Program; PUCS.P : Set of Literais; PUCSO, I ~ C S . , Y, GUUSO : Literals; begin PUCS_P := PUCS(P,-M); PUCSO := 0; (*Compute first all elements of the possibly unfounded conjunctions*) for each C 6 PUCS_P do PUCSO :=/~dCS0 U {C} endfor; 15 := 0; (* Construct/5 for computing the PUCS* *) for each r 6 P do for each A 6 B(r) + do /5 :=/5 U {A ~---< H ( r ) > < not(-~B(r)), not(A) > .} endfor endfor; PUCS* := t~CSO; (* Compute the I=UCS* *) repeat Y : : PUCS*; PUCS* := 7~(/5, Y, M) until Y = PUCS*; P := 0; (* Construct P for computing F~,M(PUCS* ) *) for each r E P do (* let B ( r ) + = A1,..., A, and B ( r ) - = -~B1,...,-~B,~ *) P := PU {H(r) ~---< H(r)) > < not(-~B(r)) > .} endfor; (* Compute F~,M(PUCS. ) *) repeat Y := PUCS*; PUCS* := PUCS * - T ( P, PUCS* , -~t=UCS * UM) until Y = PUCS*; GUUS0 := 0; (* Compute the GUUS *) for each C E PUCS-P do if C C PUCS* t h e n GUUS0 : : GUUS0 W C endif; endfor; r e t u r n GUUS0 e n d (~7]S; ^
Fig. 5. Function ~ S
-
-
174
Example 12. Consider the followin 9 program: a 6.- .-.nb, "~c. a +-- " a d . C ~
-rid, -no.
d~e,f. e~---d. Let M = O. The function (Z/US starts computing trUCS-P = {{b, c}, {d}, {d, c}}. Then it sets I:UCS* = {b, e, d} and constrncts the program P consisting of the following rules: e *--< d > < not(~e), not(-~f), not(e) > . f ~--< d > < not(-ne), not(-nf), n o t ( f ) > . d *---< e > < not(--,d), not(d) > .
At this point PUCS* is saturated through a fizpoint computation. At the f r s t step, 7"(P, {b, c, d},O) gives the set {b, c, d, e , f } ; this set is recomputed, in the next step so that it is the fixpoint. Thus FUCS* = {b, c, d, e, f}. Next the function constructs the program P consisting of the following rules: a ,--< a > < not(b), not(c) > . a , - < a > < not(d) > . c , - - < c > < not(d), not(d), not(c) > . d ,---< d > < not(--,e), not(--,f) > . e ~---< e > < not(",d) > .
Another fizpoint computation is started. At the first step T ( ~ , {b, c, d, e, f}, { - b , - c , ~ d , - e , - f } ) = {c}
thus c is to be removed from t~CS*. As in the next step T ( ~ , {b, d, e, f}, {-,b,-,d,-,e,-~f}) = 0 {b, d, e, f} is the fixpoint. Finally, the function computes the GUUS by restricting PUCS-P to {b, d, e, f } . The only possibly unfounded conjunction that is contained in {b, d, e, f} is {d}; so the ~ S is {d}. B References
1. Apt, K., Bair, H., and Walker, A., "Towards a Theory of Declarative Knowledge", in Foundations of Deductive Databases and Logic Programming , J. Minker (Ed.), Morgan Kauffman, pp. 89-148, 1988. 2. Chandra, A., and D. Hard, "Horn Clauses and Generalization", Journal at Logic Programming 2, 1, pp. 320-340, 1985. 3. Clark, K.L., "Negation as Failure", in Logic and Data Bases, (Gallaire and Minker, eds), Plenum Press, New York, pp. 293-322, 1978.
175
4. Fitting, M., and M. Ben-Jacob, "Stratified and Three-valued Logic Programming Semantics", Proc. 5th Int. Conf. and Syrup. on Logic Programming, MIT Press, Cambridge, Ma, pp. 1054-1068, 1988. 5. Garey, M. R., and Johnson, D.S., Computers and Intractability, W.H. Freeman and Company, 1979. 6. Gelfond, M., and Lifschitz, V., "The Stable Model Semantics for Logic Programming", Proc. 5th lnt. Conf. and Syrup. on Logic Programming, MIT Press, Cambridge, Ma, pp. 1070-1080, 1988. 7. Lloyd, J. W., Foundations of Logic Programming, Springer-Verlag, 1987. 8. Leone, N., Rullo, P., "Safe Computation of the Well-Founded Semantics of DATALOG Queries", Information System 17, 1, 1992. 9. Naqvi, S.A., "A Logic for Negation in Database Systems", in Foundations ol Deductive Databases and Logic Programming, (Minker, J., ed.), Morgan Kaufman, Los Altos, 1987. 10. Przymusinski, T.C., "On the Declarative Semantics of Stratified Deductive Databases and Logic Programs", in Foundations ol Deductive Databases and Logic Programming, (Minker, J. ed.}, Morgan Kaufman, Los Altos, pp. 193216, 1987. 11. Przymusinski, T.C., "Every logic program has a natural stratification and an iterated fixed point model", Proc. ACM Syrup. on Principles of Database Systems, pp. 11-21, 1989. 12. Przymusinski T.C., "Extended stable semantics for normal and disjunctive programs", Proc. of the 7th lnt. Conf. on Logic Programming, MIT Press, Cambridge, 1990, pp. 459-477. 13. Sacca, D. and Zaniolo, C., "Partial Models, Stable Models and NonDeterminism in Logic Programs with Negation", Proc. ACM Syrup. on Principles of Database Systems, pp. 205-218,1990. 14. Sacca, D. and Zaniolo, C., "Determinism and Non-Determinism in Logic Programs with Negation", unpublished manuscript, 1992. 15. Tarski, A., "A Lattice Theoretical Fixpoint Theorem and its Application", Pacific Journal of Mathematics 5, pp. 285-309, 1955. 16. Ullman, J, D., Principles of Database and Knowledge-Base Management System , Academic Press, 1988. 17. Van Gelder, A., "Negation as Failure Using Tight Derivations for Logic Programs", Proc. 3rd IEEE Syrup. on Logic Programming, Springer-Verlag, pp. 127-138, 1986. 18. Van Gelder A., Ross K., and J.S. Schlipf, "Unfounded Sets and Well-Founded Semantics for General Logic Programs", A CM SIGMOD-SIGA CT Symp. on Principles of Database Systems, pp. 221-230, 1988'. 19. Van Gelder A., Ross K., and J.S. Schlipf, "The Well-Founded Semantics for General Logic Programs", Journal of the ACM 38, 3, pp. 620-650, 1991. 20. You,J-H. and L.Y. Yuan, "Three-Valued Formalization in Logic Programs: is it really needed?", A CM SIGMOD-SIGA CT Syrup. on Principles of Database Systems, pp. 172-181, 1990
Modules in Logic Programming: a Framework for Knowledge Management* Annalina Fabrizio, Maurizio Capaccioli, Sandra Valeri Systems & Management ~ via Vittorio Alfieri 19 10121 Torino, Italy
Abstract. This paper describes a proposal for knowledge modularization in a logic language. Our aim is to define structuring mechanisms for the integration and composition of modules in order to provide software reusability, clean problem definition and non-standard programming techniques. The proposed mechanisms include the ability to define modules and connections between them. A program module can be combined with other modules (by using the link mechanism) to offer a programming paradigm based on the separation of the problem in independent subproblems. A suitable set of operators on logic modules offers a kernel for a rational reconstruction of knowledge representation and programming-inthe-large techniques. Modules can be represented by using different technologies: a module can be a data base or a C language program.
1
Introduction
The purpose o f this paper is to describe a structuring mechanism for logic programming languages. Prolog is a rule based logic language, hence showing characteristics o f syntax simplicity that, on one hand allow a highly declarative description, on the other show the problem o f code understanding. The lack o f structuring results in little readable programs, so it is difficult to maintain and to reuse them. A structuring mechanism is required to organise a complex program in smaller, interrelated units. By describing the problem through separated and cooperating program modules, it is possible to specify problems o f a high degree o f complexity. Because each module is designed to solve a particular part o f the problem, it is easier to write and to reuse it. Interesting features o f this approach are simplicity o f description, flexibility of use and readability. There is another important issue that deserves more attention: the integration of the logic language with other programming * Work partially mpported by CNR, "PF Sistemi lnformatici e Calcolo Parallelo, Sottoprogelto 5, LRC LOGIDATA+" o Work completed by tile authors actually employed in other companies.. You can contact: Annalina Fabrizio, via U. Viale I/A 56124 Pisa Italy.
177
languages, programming paradigms and representation technologies, in particular with a relational DBMS. The proposal has been realised through the metaprogramming approach [2], which provides a powerful and conceptually neat technique for the definition and implementation of new formalisms. Metaprograms treat other programs as data. The writing of metaprograms is particularly easy in Prolog [3,14] due to the equivalence of programs and data: both are Prolog terms. In the paper we present our modularization mechanisms. Three different points of view are considered: the structuring of a logic program in related typed modules, the composition of logic modules and the integration with modules that use different representation technologies. Some of the ideas on modularization, structuring and integration among different modules of knowledge are based on the Epsilon system [8,9,15,16] and are presented in [10]. In order to define knowledge composition we based our work on the studies for the definition of operators defining an algebra on theories and hierarchical operators among theories [4,12,13]. A first version of this proposal can be found in [11]. In the follow we sketch the paper contents. In the second section we present the basic concept of our knowledge structuring that are link and module, then the structured program shape and four different types of link are presented and the practical use is shown by an example. In the third section we show the algebraic operators on which the operators we propose are based, then we describe the operators we propose and how construct a new module with them. The fourth section deals with the integration of logic modules with C program and a relational database. The C module and the database module are shown. Then you can find conclusion and references in the fifth and sixth section respectively.
2
Knowledge
Structuring
The proposed structuring mechanisms include the ability to define modules and connections between them. A program module can be combined with other modules (by using the link mechanism) to offer a programming paradigm based on the separation of the problem in independent sub-problems. To describe our proposal we consider Prolog rules.
2.1
Logic Modules and Links
A logic module is a set of logic rules and has a name. A logic module contains Prolog rules. To start up the resolution of a goal it is necessary to specify in which module the goal itself has to be evaluated. The metapredicate
query(M, G) represents the evaluation of goal G inside the module M. For example, if M is defined as follows:
178
M: p(X):- q(X).
q~a). the request query(M, p(a)) will be successful. A module can be related to other modules, meaning that the knowledge contained into a module is used "together" with the knowledge of another one. To this purpose we define a mechanism called link. A link is a semantic relation between modules whose effect is to define an "extended" knowledge, obtained from the cooperation of the knowledge belonging to the involved modules. Suppose we have modules M, N related by a link from M to N. Let M defined as above and N as follows:
N: q(b).
p(c). A link from M to N implies that to solve a goal inside module M it is possible also to refer to the knowledge in N. The knowledge contained in module M is extended with the knowledge contained in module N. We provide a set of links (see section 2.3) in order to support several ways for extending the knowledge of a module. It is worthwhile to note that a link has a "direction" from M to N, representing an order in the consultation of M and N: the module M is first consulted and then N is consulted. So a link is graphically represented by an arrow connecting the source module and the destination module of the link. The direction of a link is even more important in a "chain" of modules. In the example shown in figure 1, the consultation of the knowledge for the solution of a query passes through the chain of modules until the answer is found or when all modules have been consulted.
M1
~link-->
I I M2
~link~>
...
~link~>
I
Mn
Fig. 1. Chain of modules Several links having the same source module and different destination modules can be defined. In order to find a solution of a query, in the example shown in figure 2, the knowledge in M1 is extended with the knowledge in M2 or in M3.
179
lin' lM21 '
link - - >
I
M3
I
Fig. 2. M1 knowledge is extended with the knowledge in M2 or in M3 Moreover, several source modules can exploit the same destination module as shown in figure 3. The destination module represents the knowledge shared among the source modules.
M,I, link --> M3
link -->
I M2 [/ Fig. 3. M1 and M2 share the knowledge in M3
2.2 Programs A program is defined by a pair <M, L>, where M represents a set of modules and L represents a set of links. The knowledge base dictionary describes the modules and the links among them through a set of metapredicates of the form module(A) and link(A, B, Type), where A and B are module names and Type is a predefined link Type. It is possible to create/delete a link from a module M1 to a module M2 adding/removing the metapredicate link(M1, M2, Type) to/from the dictionary. To allow the dynamic creation and deletion of links at run time the metapredicates makelink(M1,M2, Type) and dellink(M1,M2, Type) can be used. These metapredicates can be used as any other predicate inside a clause. For example, rules contained in a module can be accessed just under a condition. Let be P = a program where M1, M2 are defined as follows:
180
MI:
q(X):-
p(X), makelink(M1,M2,Type), fiX), dellink(M1,M2,Type).
q(b). p(a). M2:
p(b). r(a).
r(b). Consider the following query to be solved: query(Ml, q(X)) The link from M1 to M2 is created only if the goal p(X) is successful, hence making M2 accessible for the resolution of r(X) predicate. Note that, during the evaluation of r(X), the program is P' = ; the metapredicate dellink(M1,M2, Type), establishes that the link existence is restricted to the whole resolution of the goal r(X). Finally it is worthwhile to note that modules can exchange knowledge by using explicitly the query metapredicate. The query metapredicate can appear inside a clause in a module, so it is possible to solve a goal in a given module independently of the structure of the program induced by the links.
2.3
Link Types
Different ways can be identified to relate two or more modules [10]. By means of different types of links it is possible to combine the knowledge of distinct modules by using each time the appropriated link type for a specified problem interaction. The cooperation of rules contained in different modules rise from two kinds of orthogonal modalities: open~close and use/consultance. They state in which manner we can refer to the knowledge of a related module, to evaluate a goal in a source module. Open/Close Modality. The open~close cooperation modality between modules deals with visibility: it states which part of knowledge in the destination module has to be consulted.
open modality: all the predicates defined in the destination module are visible from the source module; by this way the knowledge contained in a module is extended with the whole knowledge contained in the related module.
close modality: only the predicates of the destination module that are not defined in the source module are visible; by this way the knowledge contained in a module is extended with the knowledge contained in the related module only for predicates that are not already defined.
181
Use/Consultance Modality. The use/consultance cooperation modality between modules deals with how a goal is evaluated inside a related module, namely how to consult the knowledge of the destination module. 9
consultance modality: the goal evaluation in the destination module takes
place, eventually with a return value. The destination module is a "black box": it takes a goal and returns failure or success, together with the bindings for variables. The evaluation process in the destination module is hidden. 9
use modality: the goal evaluation in the destination module starts up the search of the goal definition in the module; the first found definition is evaluated in the source module, observing the same evaluation rule. In this case the source and destination modules have to be written in the same language.
The combination of the above cooperation modalities originates four types of knowledge structuring represented by four link types between modules: openuse, closeuse, openconsultance, closeconsultance.
For example, let be P=< {M1, M2}, {link(M1,M2,Type)} >, where M1 and M2 are defined as follows and Type represents a generic link type: MI: p(a). q(X):-r(X). M2: qCo). r(X):-p(X). Consider the query: query(M1, q(X)). The following table summarises the answers that could be obtained with the combination of the two different m(~.lalities: modality
open
close
use
{ q(a), q(b) }
{ q(a) }
consultance
{ q(b) }
{}
table 1 If the link from M1 to M2 is o p e n u s e , the solutions are { q(a), q(b) }. The answers obtained by using an openuse link are the same achievable from a "sorted"
182
union of the rules contained in M1 and M2, but by using an openuse link we can have best results in efficiency and modularity. In fact we can use the two modules both alone and together and, in addition, they can be dynamically disconnected and connected with others. Moreover, if a goal is obtained only exploiting M1 rules, the search is done on a less number of rules. If the link from M1 to M2 is closeuse the solution is { q(a) }. In this case the clause q(b) in M2 is not used in the resolution because a clause defining q is already existing in M1. In any case with the use modality, any clause is interpreted starting from the source module, even though its definition resides in a different module. If the link from M1 to M2 is openconsultance the solution is { q(b) }, in this case q(a) is not a solution because the evaluation of r(X) considers only the rules in M2 and it fails. If the link is closeconsult the solution is { }. In this case q(a) is not a solution as already seen for the openconsultance link, and q(b) is not a solution since the close modality hide the additional definition of q in M2. In any case, with the consultance modality the evaluation takes place inside the destination module. 2.4
An Example
The proposed knowledge structuring mechanisms permit to define the knowledge concerning an entity into a module and to extend it, through links, by using additional knowledge contained into separate and distinct modules. By this way is possible to deal with specialisation and generalisation of subjects and to support the exception handling. It is also possible to solve directly a given query in a specified module by using an explicit call, thus ignoring the structure of the program given by the links. Suppose the program P is defined as follows: P =< {vialli, football_player, person, gullit, matches, teams}, { link( vialli, football_player, openuse). link( vialli, person, openuse). link( gullit, footballplayer, closeuse). link( gullit, person, openuse). link( football_player, matches, closeconsultance). }> Figure 4 shows a graphical representation of P
vialli
I enue l, payol
I
1"
openuse
closeuse
$
i
cloecon
matches
teams
Fig. 4. Graphical representation of P
183
Suppose the modules are so defined: football player: nationality(italian). address(X):- team(T), query(teams,address(T,X)). gain(X,Y):- match(Y), percentage(Y, Z), takings(Y,W), X is W*Z. teams: address(juventus, "via... Torino"). colours(milan, rossonero). address(milan, "via... Milano")) colours 0uventus, bianconero). person: address(X):- age(Y), Y < 18, father(F), query(F, address(X)). address(X):- wife(Y), query(Y, address(X)). age(X):- bornyear(Y), currentyear(Z), X is Z-Y. vialli: team(juventus). match0uventus-milan). percentage(juventus-milan, 0.001) percentage(X, 0.005):- awaymatch(X). gullit: bomyear(.. ). team(milan). matchOuventus-milan). nationality(dutch). percentage(... ). matches: takings(X,Y)... gain(X,Y)...
football__player describes players of italian football teams, person contains private data of people. We define particular characteristics of two football players, i.e. Vialli and Gullit, respectively in vialli and gullit modules. The openuse link between vialli and football_player will express that anything valid for italian players is also valid for Vialli; for example the fact of being an italian person. The closeuse link from gullit tofootball__player can be used to describe that Gullit has general characteristics of an italian football player, but he has same properties different from the general ones, e.g. he is not italian. With the use modality
184
it is possible to describe the knowledge for generalisation/specialisation, while the
close modality can be used to manage the exceptions. To know how much Vialli earns we can require the evaluation of the goal
query(viaUi, gain(X, Y)) In the vialli module is not defined gain, so the evaluation refers to the knowledge offootball__player where gain(X, Y) is defined, gain(X, Y) representing profits X of a football player on the basis of his percentage on the takings of the match Y. The resolution in module vialli of the clause defining gain(X, Y) will bind the variable Y to "juventus-milan" and the variable Z to 0,001. At this point, since in vialli is not present any information on takings, the resolution of takings( 'Tuventus-milan", W) considers thefootball_.player module knowledge. The module does not contain that information and then the matches module is consulted, yielding the goal solution. It is worthwhile to note that in this example a consultance link is used to relate the matches module, so the takings definition is not provided because we are interested only in the answer provided by the module and takings is solved only inside the matches module rather than in the chain of modules starting from the vialli module. Moreover, the link to matches is close so it is possible to redefine gain, also defined in football..player, with a different meaning because it can only be used locally. We can execute query(gullit, address(X)) to know the address of Gullit. This query starts the search for address in guUit and then infootball_.player. The evaluation of the body of address will bind the variable T to "milan" and therefore the metapredicate query(teams, address(milan, X)) is called: so address is explicitly activated in teams, giving back as a result the team address. Note that if another solution for address is requested, we could obtain the Gullit wife address. The explicit use of the knowledge of a module through the query metapredicate can be obtained also by using the makelink and dellink predicates. For example in football__players the clause defining address could be substituted as follows: address(X):- team 03, makelink(football_players, teams, closeconsultance), address(T,X), dellink(football_players, teams, closeconsultance). By this way, the search of a definition for the Gullit address will start from the gullit module, while by using the query metapredicate, the evaluation is immediately made active in teams.
3
Module Composition Operators
A suitable set of operators on logic modules offers a kernel for a rational reconstruction of knowledge representation and programming-in-the-large techniques. It is possible to compose the knowledge of two logic modules in a single module. This can be obtained introducing in the language operators on modules whose
185
effect is to produce a new module. The user can explicitly query the new module referring a specific operator through the query metapredicate: query(lVll operator M2, Goal) A module which result from the evaluation of M1 operator M2 will be created and the query Goal will be evaluated in this module. To define our operators we refer to [12,13] where a set of operators defining an algebra on logic theories is provided, and to [4] where hierarchical operators between theories are defined based on these algebraic operators. We propose operators based on the algebraic operators shown in the following. The intersection operator produces a new module that contains intuitively the shared knowledge of the argument modules. If M1, M2 contain a common predicate p" MI: p(tl ..... m):--Bodyl . . .
M2: ~ 1 7 6
p(sl ..... sn):-Body2 . ~
then the module M obtained by the operation intersection(M1, M2) contains: p((tl ..... m)~t) :- (Bodyl, Body2)~ where kt is the most general unifier between (tl ..... tn) and (sl ..... sn). The union operator produces a new module whose clauses are given by the union of the clauses of the two arguments. The negation operator produces a new module containing the definition of new predicates that are the negation of the predicates of the argument. An example is in the follow. Suppose program P = < ({ uefa, champions, cups }, { }) >, where: uef~ participate(X):- won(X, uefa, 89). participate(X):- classified (2, championship, 89). participate(X):-... regular_team(X):- players(X,Y), Y>=I 1, Y N a m e ( ) ) ;
~
Having an object of some database type, one can access the attributes of it via C + + methods (as in s --. Name()). One interesting feature of this model of operations (thanks to a standard feature of the C + + language) is that, in order to follow a path through part_of relations, one has just to use C + + pointerfollowing as if exploring an in-memory structure. For instance, in the following code fragment we indicate how the name of the director of a department m a y be printed:
242
Department d; .
.
.
d = .... ; printf (. . . . ~
.
4.3
~
9
9
d->Director()->Name()
...
);
~
MOOD Primitives
The following primitives are part of the standard MOOD library. We describe each of them, including some fragments of C + + / M O O D code to exemplify their use.
Foreach(Variable); Follow(Attribute, Variable); Clear(Variable); Sql( V ariable, " whereclause" ) ; And(Vres, V1, V2);
Or(V~, v~, V2); Not(Yr,,, V); Join(Join_Condition, V1, V2); BuildRel(Result, l~, ..., Vn);
Foreach. This primitive implements iteration over a set of Tuples, contained in Variable (a NAVIGATION_NODE ); for instance, in the following program fragment it selects all persons currently in the navigation node AlIPersons; their names and ages are subsequently printed.
NAVIGATION_NODEAIIPersons(PERSON_DB); .
o ~
while (AllPersons.Forsach~)) { printf("...", AllPersons.Current()->Nams(), AllPersons.Current()->Age() ); } At each iteration through the loop, the 'current object' of AllPersons will return a different object contained in AllPersons (the order of iteration is not specified). Follow. The Follow primitive may be used to navigate in the database through part_of relations. Follow is normally used in conjunction with Foreach, as exemplified by the following code fragment which connects each director to the departments he directs.
243
NAVIGATION_NODE AIIDepartments(DEPARTMENT_DB); NAVIGATION_NODE AIIDirectors(PERSON_DB); Person p; while (AllDirectors.Foreach()) AllDirectors.Follow("Directs",
AllDepartments);
The Follow primitive has a source and a target navigation node variables; as effect of executing the primitive, the target variable contains all the objects that are connected to objects in the source variable through the part_of link. Note that one could navigate along part_of links through the corresponding methods, hut without instantiating the target navigation node; further, the Follow primitive is more efficient than the use of methods with part_of links of type sequence. Clear. It simply empties a NAVIGATION-NODE variable. It may be used to prepare a NAVIGATION_NODE for the next computation. For instance: NAVIGATION_NODE Persons_Older_Than_20(PERSON_DB);
Persons_Older_Than_20.Clear(); Persons_Older_Than_20.Sql( "age > 20" ); Persons_Older_Than_20.Sql( "age < I0" ); // Persons_Older_Than_20 now contains // the union of the results of both // SQL operations.
A n d , Or a n d Not. This functions implement the obvious boolean operations on the NAVIGATION_NO-DEs; and~or are applied to pairs of navigation nodes and generate their intersection or union; not generates the complement of an instantiated navigation node with respect to the values contained in the database for that node. NAVIGATION_NODE Persons_Older_20(PERSON_DB); NAVIGATION_NODE Toy_Directors(PERSON_DB); NAVIGATION_NODE Toy_Directors_Older_20(PERSON_DB); Persons_O1der_20.Sql( "age > 20" ); Toy_Directors.Sq1( "DepName = Toy* "); And(Toy_Directors_Older_20, Persons_Older_20, Toy_Directors);
244
Sql. Sql executes a query on the table associated to the current navigation node Vamable, and loads it with the resulting tuples, after type coercion. For example, we retrieve all persons more than 20 years old, and print their name, as it follows:
NAVIGATION_NODE Persons_Older_Than_20(PgRSON_DB); .
.
~
Persons_Older_Than_20.Sql( "age > 20" );
while (Persons_Older_Than_20.Foreach()) printf("...", Persons_Older_Than_20.Current()->Name()
);
The query expression can contain complex predicates, i.e. joins with other relations; this primitive, however, selects the result on t h e target table. The predicate may involve condition on attributes of subobjects, but in doing so the programmer must know the underlying relational schema. Full joins can be obtained with the primitive Join described later in this section. J o i n . In order to execute efficiently a relational full join operation, MOOD provides the primitve Join. Given a join condition (which, as in the Sql primitive, may be any legal SQL predicate) and two NAVIGATION_NODE s, MOOD executes a query on the relational database joining the relations associated with the NAVIGATION..NODEs. Consider for example the following program fragment:
NAVIGATION_NODE Directors (PERSON_DB) ; NAVIGATION_NODE Departments (DEPARTMENT_DB) ; , . .
Join("Person. Oid = Department.Director", Directors, Departments) ; .
.
.
To execute the join, MOOD will execute the following SQL query: select * from person, department where person.oid = department.director
After the execution of a Join primitive, MOOD loads selected objects into the corresponding NAVIGATION_NODE Directors and Departments, and sets up additional information between objects related by the join (as after the execution of a Follow primitive) to support a possible, subsequent execution of the BuildRel primitive. B u i l d R e l . This function must be preceded by a series of navigations with F o l low and Foreach, or with Join. Its effect is to build a relation that describes
245
all selected navigations. More precisely, the relation contmns one tuple for each distinct path ~ o m all selected objects in V1 to all selected objects in V~ (n is limited to a given max value, MOOD-implementation dependent). The only constraint is that all navigation nodes re~renced by the ~ must have been previously instantiated, through, Foreach, Follow, and Join primitives.
// Link each director with the department he directs NAVIGATION_NODE AIIDepartments(DEPARTMENT_DB); NAVIGATION_NODE AllDirectors(PERSON_DB); Person p; 9
.
,
.hile (AllDirectors.Foreach()) AllDirectors.Follow("Directs",
AllDepartments);
// Generate a relation linking departments // to their directors, called // "persons_departments" .
.
.
BuildRe1( "persons_departments", A11Persons, AliDepartments );
4.4
I m p l e m e n t i g t h e Isa H i e r a r c h y
The isa hierarchy C1 < C2, defined in a MOOD schema, is translated as follows:
1. Relational Schema. Each class corresponds to a different relation; therefore, R1 and R2 are generated. However, their Old attributes take values from the same domain D. If objects O1 E C1 and 02 E C2 are hierarchically related (O1 < O~), then the corresponding tuples tl E R1 and t2 E R2 have the same Old value. 2. C § 2 4 Data 7 Structures. We use the default C + + inheritance; thus, subclasses automatically inherit all methods of the superclass. Since we want to be able to use an object at each level in the isa hierarchy, we must store the representations of the attributes of all the subclasses in the top object. By doing so, all the objects in the hierarchy are the same length, and we may have a single pointer to an object, independently to the class to which it belongs; we may use a simple C + + type cast to change the class of the object 4. On the contrary, if we store the attributes in the object to which they belong, then objects at different level in the hierarchy would have different 4 Though a normal cast would suffice, the macro AS_class should always be used since it checks if the object really belongs to the class we are casting it to. Objects mantain a record of their identity, and trying to use an object with the wrong identity (i.e. asking the marks of a Person which is not a Student) would cause a Runtime Error.
246
length, and we couldn't have the same pointer to the objetct regardless of the class. 4.5
Building a Mood Application
We now detail the steps which are needed to run MOOD applications. First of all, the user must compile the MOOD schema. Let us assume that it is contained in a file named school.too, then the following commands are executed (mc is the
mood compiler): 7. m c -s s c h o o l . m o 7. mc -c s c h o o l . m o
The first command produce a file school.sql that should be run on the relational database for table creation. The second command produces, for each MOOD class~ one file with the .cc extension, containing C + + methods source code, and one with the .h extension, containing declarations to be imported in each user program. It also produces the files school.cc and school.h which contain general definitions about the schema. In our example, the produced files are: person.cc, department cc, student, cc, person.h, department.h, student h, school.cc, schooi.h. They are next compiled in a library, using the conventional C + + compiler and utilities. Finally, the programmer can write his application. This is a normal C + + program, which imports the MOOD definitions, defines appropriate navigation nodes, and uses the MOOD primitives. When the program is completed, it must be compiled and linked with the library just created. It can then be normally executed.
5
Example
A sample (real) program which queries the database for various operations is the following: I 2 3 4 5 6 7
#include #include #include #include #include #include #include
8
Database *SchoolDatabase =
9 I0
11
<stream.h> <School.h> <Student.h>
new InformixDatabase("School"); NAVIGATION_lODE
Persons_Older_Than_25(SchoolDatabase,
PERSON_DB),
247
Directors(SchoolDatabase, PERSON_DB), Departments(SchoolDatabase, DEPARTMENT_DB), Student_1OO(SchoolDatabase, STUDENT_DB);
12 13 14
15
main(int argc, char **argv)
16
{
17 18
SchoolDa~abase->LogOn(); Persons_Older_Than_25.Sql("age
19 20
//Sql - pers cout
