We propose a novel formalism, called Frame Logic (abbr., F-logic), that accounts in a clean and declarative fashion for most of the structural aspects of object-oriented and frame-based languages. These features include object identity, complex objects, inheritance, polymorphic types, query methods, encapsulation, and others. In a sense, F-logic stands in the same relationship to the objectoriented paradigm as classical predicate calculus stands to relational programming. F-logic has a model-theoretic semantics and a sound and complete resolution-based proof theory. A small number of fundamental concepts that come from object-oriented programming have direct representation in F-logic; other, secondary aspects of this paradigm are easily modeled as well. The paper also discusses semantic issues pertaining to programming with a deductive object-oriented language based on a subset of F-logic.

Object-oriented databases have been introduced primarily to ease the development of database applications. However, the difficulties encountered when, for instance, trying to restructure data or integrate databases demonstrate that the models being used still lack flexibility. We claim that the natural way to overcome these shortcomings is to introduce a sophisticated view mechanism. This paper presents such a mechanism, one which allows a programmer to restructure the class hierarchy and modify the behavior and structure of objects. The mechanism allows a programmer to specify attribute values implicitly, rather than storing them. It also allows him to introduce new classes into the class hierarchy. These virtual classes are populated by selecting existing objects from other classes and by creating new objects. Fixing the identify of new objects during database updates introduces subtle issues into view design. Our presentation, mostly informal, leans on a number of illustrative examples meant to emphasize the simplicity of our mechanism. 1

We propose a database logic which accounts in a clean declarative fashion for most of the “object-oriented” features such as object identity, complex objects, inheritance, methods, etc. Furthermore, database schema is part of the object language, which allows the user to browse schema and data using the same declarative formalism. The proposed logic has a formal semantics and a sound and complete resolution-based proof procedure, which makes it also computationally attractive.

A temporal database contains time-varying data. In a real-time database transactions have deadlines or timing constraints. In this paper we review the substantial research in these two heretofore separate research areas. We first characterize the time domain, then investigate temporal and real-time data models. We evaluate temporal and real-time query languages along several dimensions. Temporal and real-time DBMS implementation is examined. We conclude with a summary of the major accomplishments of the research to date, and list several research questions that should be addressed next. Keywords: object-oriented database, relational databases, query language, temporal data model, time-constrained database, transaction time, user-defined time, valid time 1 Introduction Time is an important aspect of all real-world phenomena. Events occur at specific points in time; objects and the relationships among objects exist over time. The ability to model this temporal dimension of the real worl...

A language for databases with sets, tuples, lists, object identity and structural inheritance is proposed. The core language is logic-based with a fixpoint semantics. Methods with overloading and methods evaluated externally providing extensibility of the language are considered. Other important issues such as updates and the introduction of explicit control are discussed. 1 INTRODUCTION The success of the relational database model [19, 38, 27] is certainly due to technological advances such as fast query processing or reliable concurrency control. However, we believe that a major factor in that success has been the existence of simple-to-use languages allowing the definition and manipulation of data. This has to be remembered while considering future generations of database systems. Object-oriented database systems are now being developed, e.g., [15, 12, 22, 39, 36]. An object-oriented approach [24] is used to answer the needs of a much wider variety of applications. Most of th...

When a database is shared by many users, updates to the database schema are almost always prohibited because there is a risk of making existing application programs obsolete when they run against the modified schema. This paper addresses the problem by integrating schema evolution with view facilities. Each user is assigned his or her own database view, and develops application programs against the view. When new requirements necessitate schema updates for a particular user, then the user specifies schema changes to his personal view rather than to the shared base schema. Our view schema evolution approach then computes a new view schema that reflects the semantics of the desired schema change, and replaces the old view with the new one. This approach provides the means for schema change without affecting other views (and thus without affecting existing application programs). The persistent data is shared by different views of the schema, i.e. by both old as well as newly developed app...

We address the problem of clustering complex data on disk to minimize the number of I/O operations in data intensive applications. We first focus on the problems related to the design and implementation of clustering strategies. We then propose a set of clustering strategies as well as an algorithm which implements them for the O 2 system. 1 Introduction New developments, both in the database field and in the programming languages field, have led to the design of new database management systems [Ba88], [Ki89], [Deux90]. These systems have the following characteristics: a complex object model [LR89a], a persistent programming language [AB87], and an object management system [VBD89]. Object management systems have to fulfill the following requirements: (i) efficient management of large amount of (large) objects; (ii) object sharing and versioning; (iii) and usual database functionality such as transaction management, concurrency control and recovery. In this paper, we are intereste...

Abstract not found

The author will not pretend to be unbiased in the matter of comparing the deductive and object-oriented approaches to new database systems; he believes that despite some important concepts originating with the object-oriented approach, the deductive family of systems will ultimately dominate. We shall explore some of the reasons why the two approaches do not mix well. Fortunately, most of the features of object-oriented database systems can be incorporated in deductive systems (but not vice-versa). Then we argue that declarativeness is important for at least some of the new applications, and that declarative languages cannot be object-oriented in a nontrivial way. We next contrast the approaches with regard to the way they classify data elements. We close with an examination of the prospects for "classless" data, which is motivated by the prospect of databases where the number of distinct classes would be too large to name systematically. There are a number of challenges to implementin...

The need to transform data between heterogeneous databases arises from a number of critical tasks in data management. These tasks are complicated by schema evolution in the underlying databases, and by the presence of non-standard database constraints. We describe a declarative language, WOL, for specifying such transformations, and its implementation in a system called Morphase. WOL is designed to allow transformations between the complex data structures which arise in object-oriented databases as well as in complex relational databases, and to allow for reasoning about the interactions between database transformations and constraints. integrating the US Cities-and-States and European-Citiesand-Countries databases shown in Figures 1 and 2. The graphical notation used here is inspired by [2]: the boxes represent classes which are finite sets of objects; the arrows represent attributes, or functions on classes. name str