Currently, object-oriented database systems (OODBS) are receiving a lot of attention from both experimental and theoretical standpoints, and there has been considerable debate about the definition of such systems.
Three points characterize the field at this stage: (i) the lack of a common data model, (ii) the lack of formal foundations and (iii) strong experimental activity.
Whereas Codd's original paper [Codd 70] gave a clear specification of a relational database system (data model and query language), no such specification exists for object-oriented database systems [Maier 89]. We are not claiming here that no complete object-oriented data model exists, indeed many proposals can be found in the literature (see [Albano et al. 1986], [L\'ecluse and Richard 89], [Carey et al. 88] as examples), but rather that there is no consensus on a single one. Opinion is slowly converging on the gross characteristics of a family of object-oriented systems, but, at present, there is no clear consensus on what an object-oriented system is, let alone an object-oriented database system.
The second characteristic of the field is the lack of a strong theoretical framework. To compare object-oriented programming to logic programming, there is no equivalent of [Van Emdem and Kowalski 76]. The need for a solid underlying theory is obvious: the semantics of concepts such as types or programs are often ill defined. The absence of a solid theoretical framework, makes consensus on the data model almost impossible to achieve.
Finally, a lot of experimental work is underway: people are actually building systems. Some of these systems are just prototypes [Bancilhon et al. 88], [Nixon, et al. 87], [Banerjee et al. 87], [Skarra et al. 86], [Fishman et al. 87], [Carey et al. 86], but some are commercial products, [Atwood 85], [Maier, et al. 84], [Caruso and Sciore 87], [G-Base 88]. The interest in object-oriented databases seems to be driven by the needs of design support systems (e.g., CAD, CASE, Office Information Systems). These applications require databases that can handle very complex data, that can evolve gracefully, and that can provide the high-performance dictated by interactive systems.
The implementation situation is analogous to relational database systems in the mid-seventies (though there are more start-ups in the object-oriented case). For relational systems, even though there were some disagreements on a few specific points, such as the form of the query language, or whether relations should be sets or bags, these distinctions were in most cases superficial and there was a common underlying model. People were mainly developing implementation technology. Today, we are simultaneously choosing the specification of the system and producing the technology to support its implementation.
Thus, with respect to the specification of the system, we are taking a Darwinian approach: we hope that, out of the set of experimental prototypes being built, a fit model will emerge. We also hope that viable implementation technology for that model will evolve simultaneously.
Unfortunately, with the flurry of experimentation, we risk a system emerging as the system, not because it is the fittest, but because it is the first one to provide a significant subset of the functionality demanded by the market. It is a classical, and unfortunate, pattern of the computer field that an early product becomes the de facto standard and never disappears. This pattern is true at least for languages and operating systems (Fortran, Lisp, Cobol and SQL are good examples of such situations). Note however, that our goal here is not to standardize languages, but to refine terminology.
It is important to agree now on a definition of an object-oriented database systems. As a first step towards this goal, this paper suggests characteristics that such systems should possess. We expect that the paper will be used as a straw man, and that others will either invalidate or confirm the points mentioned here. Note that this paper is not a survey of the state of the art on OODBS technology and do not pretend to assess the current status of the technology, it merely proposes a set of definitions.
We have separated the characteristics of object-oriented database systems into three categories: mandatory (the ones that the system must satisfy to deserve the label), optional (the ones that can be added to make the system better but which are not mandatory) and open (the places where the designer can select from a number of equally acceptable solutions). In addition, there is some leeway how to best formulate each characteristic (mandatory as well as optional).
The rest of this paper is organized as follows. Section 2 describes the mandatory features of an OODBS. Section 3 describes its optional features and Section 4 presents the degrees of freedom left to the system designers.