Object-oriented Database Programming Language Research Articles

On type systems for object-oriented database programming languages

The concept of an object-oriented database programming language (OODBPL) is appealing because it has the potential of combining the advantages of object orientation and database programming to yield a powerful and universal programming language design. A uniform and consistent combination of object orientation and database programming, however, is not straightforward. Since one of the main components of an object-oriented programming language is its type system, one of the first problems that arises during an OODBPL design is related to the development of a uniform, consistent, and theoretically sound type system that is sufficiently expressive to satisfy the combined needs of object orientation and database programming.The purpose of this article is to answer two questions: "What are the requirements that a modern type system for an object-oriented database programming language should satisfy?" and "Are there any type systems developed to-date that satisfy these requirements?". In order to answer the first question, we compile the set of requirements that an OODBPL type system should satisfy. We then use this set of requirements to evaluate more than 30 existing type systems. The result of this extensive analysis shows that while each of the requirements is satisfied by at least one type system, no type system satisfies all of them. It also enables identification of the mechanisms that lie behind the strengths and weaknesses of the current type systems.

Extending object-oriented systems with roles

In many class-based object-oriented systems the association between as instance and a class is exclusive and permanent. Therefore these systems have serious difficulties in representing objects taking on different roles over time. Such objects must be reclassified any time they evolve (e.g., if a person becomes a student and later an employee). Class hierarchies must be planned carefully and may grow exponentially if entities may take on serveral independent roles. The problem is even more servere for object-oriented databases than for common object-oriented programming. Databases store objects over longer periods, during which the represented entities evolve. This article shows how class-based object-oriented systems can be extended to handle evolving objects well. Class hierarchies are complemented by role hierarchies, whose nodes represent role types an object classified in the root may take on. At any point in time, an entity is represented by an instance of the root and an instance of every role type whose role it currently plays. In a natural way, the approach extends traditional object-oriented concepts, such as classification, object identity, specialization, inheritance, and polymorphism in a natural way. The practicability of the approach is demonstrated by an implementation in Smalltalk. Smalltalk was chosen because it is widely known, which is not true for any particular class-based object-oriented database programming language. Roles can be provided in Smalltalk by adding a few classes. There is no need to modify the semantics of Smalltalk itself. Role hierarchies are mapped transparently onto ordinary classes. The presented implementation can easily be ported to object-oriented database programming languages based on Smalltalk, such as Gemstone's OPAL hierarchies are complemented by role hierarchies, whose nodes represent role types an object classified in the root may take on. At any point in time, an entity is represented by an instance of the root and an instance of every role type whose role in currently plays.

Fibonacci: A programming language for object databases

Fibonacci is an object-oriented database programming language characterized by static and strong typing, and by new mechanisms for modeling databases in terms of objects with roles, classes, and associations. A brief introduction to the language is provided to present those features, which are particularly suited to modeling complex databases. Examples of the use of Fibonacci are given with reference to the prototype implementation of the language.

Making C ++ a persistent OOPL

Persistence of objects is the basis for implementing object-oriented database programming languages. We have developed XDPC ++, a persistent OOPL based on C ++, XDPC ++ keeps strictly the type orthogonality and completeness principles. This paper gives a brief explanation of our design ideas for XDPC ++. Some relevant implementation techniques are also outlined.

Notes toward a standard object-oriented DDL and DML

Software developers seek a standard object-oriented database management system as a substrate on which to build object-oriented products. Convinced of the real value of object-oriented benefits, independent software vendors seek a platform to minimize development risk. A minimalist position is compared to the object-oriented database programming language position and the latter is shown to to be the cleanest but pragmatic considerations may intervene.

Model instantiation for query driven simulation in active KDL

The focus of this paper is on how Active KDL can be used to provide a very powerful simulation support environment. Active KDL (Knowledge/Data Language) is an object-oriented database programming language, which provides access to integrated model, knowledge , and data bases . Simulation inputs and outputs can be stored by Active KDL since it supports complex objects. More importantly, Active KDL also allows users to specify rules to capture heuristic knowledge and methods to specify procedural behavior. Finally, Active KDL provides a simple mechanism for specifying concurrent execution, namely tasks embedded in active objects. These facilities provide a powerful mechanism for building simulation models out of pre-existing model components. These capabilities provide a tight coupling between a SIMODULA-like simulation system and a knowledge/database system, supporting query driven simulation, where model instantiation is used for information generation.

Contexts and metamessages in object-oriented database programming language design

VISION is an object-oriented database system currently used commercially to develop investment analysis and other large statistical applications. Characteristic of these applications, beside the standard issues of structural and computational richness, is the need to handle time, versions, and concurrency control in a manner that does not produce combinatoric complexity in object protocol. This paper describes the approach taken by VISION in addressing these issues.

Issues in the design of object-oriented database programming languages

We see a trend toward extending object-oriented languages in the direction of databases, and, at the same time, toward extending database systems with object-oriented ideas. On the surface, these two activities seem to be moving in a consistent direction. However, at a deeper level, we see difficulties that may inhibit their ending up at the same point. We feel that many of these difficulties are a result of the underlying assumptions that are inherent in the fields of programming language and database systems research. Many of these assumptions are historical and contribute to a set of cultural biases that often prevent the two communities from interacting as effectively as possible. The purpose of this paper is to try to uncover some of the cultural presuppositions that have inhibited development of a fully integrated database programming language. We have identified database and language features that seem to be difficult to reconcile. We try to uncover the basic problems in these two areas that these features were intended to solve. In order to resolve these problems, we attempt to distinguish fundamental differences from historical artifacts.