Database programming in object-oriented systems can be supported by combining data modelling and programming technologies such that a data model supports the management of collections of objects where those objects are as specified by the underlying object-oriented programming language. This approach is the basis of the object data management services (ODMS) of the Comandos system. The ODMS data model provides constructs for the representation of both entities and their relationships and further supports rich classification structures. To complement the structural model, there is an operational model based on an algebra over collections of objects. 1 Introduction Object-oriented technologies are gaining in popularity as the basis for software development platforms. Meanwhile the family of entity-relationship data models retain their wide-spread use and popularity for conceptual modelling. How then can these two successful technologies be combined to support the development of ...

Abstract | This paper tells the story of OQL, the standard query language of the Object Database Management Group (ODMG) [30]. The story starts in 1988, at INRIA in the Alta r Group y. The objective of that group was to develop an object-oriented database system [41]. This objective was reached: in September 1991 the O2 database system started its commercial career as the main product of a company called O2Technology [6]. As opposed to its competitors, O2 featured a full- edged query language named O2SQL [22]. The story goes on with the creation of the ODMG in 1991 and the adoption of O2SQL as the standard object query language under its new and nal name: OQL. During the following years, OQL went through some modi cations, the most important ofwhich resulted in OQL 1.2 that o ers some level of compliance with SQL92. On top of providing the expressive power of the SQL92 query language [54], OQL allows objects to be queried. This is a claim also supported by the upcoming SQL3. However, due to its adequacy to the object oriented type system and its functional nature, OQL is much simpler to learn, use and implement. A goal of this paper is to demonstrate this. This paper tells about the mistakes and pertinent choices we made while designing and implementing OQL. I hope it also conveys the great pleasure I had to be part of this adventure. Key words: Object-oriented database, query language 1.

This paper addresses the problem of defining views that span several objectbases. Views are expressed in terms of an object algebra. We are interested in the degrees of coupling and in the degrees of integrity maintained through multi-objectbase views. A key issue is the problem of global object identity. Each local system has its private object identifiers (OIDs) to represent objects. Globally, however, we need other mechanisms to uniquely refer to objects. We propose a technique that is based on the definition of (updatable) views: Queries to other objectbases are used as a referencing mechanism. The mechanism is useful as a formal basis for (partial or complete) schema integration in multi-objectbase systems. 1 INTRODUCTION Object-orientation is supposed to offer advantages in the context of multi-database systems. The advanced modeling capabilities of object models provide generalizations and the possibility to include computations (in the form of methods) in schema definitions. T...

We survey the fundamental problems of designing general purpose, descriptive query languages for object-oriented database systems. Structural aspects of object models are investigated and their implications on the query language capabilities are analyzed and summarized as requirements that should be met by a `good' object-oriented query language. The type system of an OODB model has to distinguish atomic types (such as basic data types -- numbers, strings, -- or abstract object types) and constructed types (such as sets and tuples). Each of the type constructors should be supported by an adequate set of generic access and manipulation operators. The query language should allow orthogonal combination of operators according to the nesting structure of type constructors, the model should be closed against its operators, and the language should be adequate. The latter criterion ensures, for instance, that queries can be expressed that return objects instead of just data about objects ("object preservation"). Several recent proposals for query languages are evaluated against these criteria.

Object-oriented databases (OODBs) are believed to more naturally reflect the behavior and organization of complex application domains. The schema consists of a collection of classes, organized into hierarchies which nicely organize abstractions over the domain. Objects are created as instances of classes, encapsulating data and interpretation of data together. An important characteristic is the support for evolutionary programming, and so that existing programs may be extended with new classes without affecting other parts of the system.

this paper we give an overview of research on extensions of relational database technology. In order to systematically classify different ways to extend the data model we take a programming language point of view of data models: a data model consists of a set of basic (predefined) types, a set of type constructors (or structuring primitives), and a set of operators (for the predefined as well as constructed types). Extensions to each of of these data model constituents are possible and have indeed been investigated in the past. Our presentation focuses on extensions to the type system (primitives and constructors) and those extensions to the operators that are implied by them. During the 1980's, there has been a significant trend in database research addressing the problem of supporting non-traditional database applications. Though relational database systems (RDBMSs) entered the commercial marketplace in the early eighties, it seemed clear that, at least without major enhancements, they would not be appropriate for non-business applications. Several research groups started out to either enhance RDBMS technology in several ways or to develop completely different models and systems. Throughout this paper we limit our scope to those investigations that tried to keep some of the characteristics of the relational model and/or systems. Attempts to make semantic data models operational, for instance, Entity-Relationship models, have already been discussed in this volume before. Also, extensions in query languages' expressive power to deal with recursion, will be surveyed in a subsequent series of articles, as will the object-oriented approaches. Therefore, we will take a more "conservative" approach, that is, stay closer within the original relational framework. The relationa...