Report on the OBJECT-ORIENTED DATABASE WORKSHOP Held in conjunction with the OOPSLA '88 Conference on Object-Oriented Programming Systems, Languages and Applications 1 26 September, 1988 San Diego, California, U.S.A. John Joseph, Satish Thatte, Craig Thompson, and David Wells Information Technologies Laboratory Texas Instruments Incorporated P.O. Box 655474, M/S 238 Dallas, IX 75265 Net: Thatte@ti-csl Introduction Object-oriented database (OODB) systems com- and two universities (Brown University and Uni- bine the strengths of object-oriented program- versity of Massachusetts) served as panelists. ming systems and data models, with those of Three months ahead of the workshop date, each database systems. This one day workshop was panel member was given a set of four issues to organized and chaired by Satish Thatte of Texas study and was asked to prepare a brief position Instruments. It was a sequel to a similar work- statement. shop held in conjunction with the OOPSLA '87 To encourage vigorous interactions and exchange conference at Orlando, FL, on October 5,1987. of ideas among the participants, the workshop Based on the comments received from the atten- was limited to participants based on the submis- dees at the OODB Workshop/OOPSLA '87, this sion of an abstract describing their work related year's workshop was organized as a sequence of to OODBs. The workshop announcement drew a four panels: Architecture, Transactions for Co- very enthusiastic response. Forty abstracts were operative Design, Schema Evolution and Version submitted. A total of 55 people (18 panel mem- Management, and Query Processing. bers and 37 participants) attended the workshop. Researchers from three companies selling OODB This report is organized in 6 major sections. Sec- products (Ontologic, Servio Logic, tions 2 through 5 present panel proceedings. Sec- and Graphael), three companies with large inter- tion 6 concludes the report. nal OODB R&D efforts (Digital Equipment Cor- poration, Hewlett Packard, Texas Instruments), 78 SIGMOD RECORD, Vol. 18, No. 3, September 1989 2 Panel on Architecture Patriee Anota (Graphael): All modules in Graphael's G-base are written in one language, Panelists: Patrice Anota (Graphael), Craig Da- Lisp; in that sense G-base design is seamless. mon (Ontologic), Patrick O'Brien (DEC), Tom I see two bottlenecks in achieving good perfor- Ryan (HP), Jacob Stein (Servio Logic), and mance: disk I/O speed, and the time to trans- David Wells (TI). late between in-memory and disk representations Issues: of objects. In G-Base, there is a difference be- tween in-memory and disk representationsof ob- • OODB subsystems: What are the ma- jects. The translation time dominates the disk jor subsystems of an OODB, and how are I[O time! they interconnected or layered? Candidate Connectivity between OODBs and conventional subsystems are: disk-resident object man- databases is important, as so much of today's agement, in-memory object management, information resides in conventional databases. object translation service which translates Graphael has connected G-Base to Oracle's re- objects between in-memory representation lational DBMS. Graphael is pushing a federated and disk-resident representation, transac- database approach to connect OODBs to rela- tion manager, version manager, and query tional databases. processor. Craig Damon (Ontologic): Ontologic's Vbase • Seamlessness: Is it possible to develop an OODB has three basic subsystems: Abstrac- object-oriented data model that is a seam- tion Manager for message dispatching and ab- less extension of the host object-oriented straction creation, the Cache Manager, and the programming language? If so, how, and Transaction Manager. The cache manager deals what are the advantages? A seamless with segraent.s (units of clustering and disk trans- object-oriented data model should be con- fers). Object representations in memory and on trasted with object-oriented data models disk are the same, hence no translation is re- that have different type systems from the quired. The transaction manager deals with all type system of the object-orientedprogram- the concurrency and recovery issues. ruing language. Integration with host language can be done al- • Performance issues: What is a good perfor- most seam!essly. Of course, there are some prob- mance metric for OODBs (navigational,i.e., lems in trying to be seamless within an existing pointer chasing speed, or query throughput, language. For example, if the existing language or query response time?) What are the has no notion of versions, clustering, indices, and major performance bottlenecks in OODB transaction, introduction of such concepts will systems, and what are potential solutions? create a seam. We do not want a dual type sys- What is the potential of using parallelpro- tem, one for persistent objects and one for tran- cessors and massive amounts of main mem- sient objects. It is very important to be able to ories to improve OODB performance? deal with persistent and non-persistent objects in exactly the same way. However, this would • Connectivity issues: Are stand alone require development of the right new language; OODBs really viable? And if not, how an most existing object-oriented languages, unfor- OODB should be connected to conventional tunately, were not designed for that. databases? SIGMOD RECORD, Vol. 18, No. 3, September 1989 79 A good metric for an OODB depends on the minimum number of disk I/O's. This is done by type of applications. There are three good per- transferring chunks of data as it is not eifllcient formance benchmarks for OODBs: Rick Cattell to fault on each object. To do any of this well, of the SUN Database Group wrote one that is one has to figure out how to cluster objects. towards relational model, but did allow the ob- We have looked at several applications where ject model to come through; Jim Skein of SUN stand-alone OODB's are going to be useful. improved the benchmark; and Arne Berre devel- CAD and CASE now usually use home-grown oped a benchmark at Oregon Graduate Center. DBs, so they'd be quite happy to replace them. Performance bottlenecks in OODBs are: object- Applications like CAD do need to talk to other oriented abstractions, dereferencing of pointers databases for product information, etc. To allow to persistent objects, disk I/O, and inter-process this, we have written a relation type in our lan- communication overhead. guage. I do not think that federated databases Patrick O'Brien (DEC): Trellis/OWL OODB are a priority for OODBs. has three major components: persistent ob- Tom Ryan (HP): My remarks axe from a ject repository, language interfaces, and a co- database perspective, not from an object- operative programming environment. Seamless- oriented programming language perspective. I hess is very hard to retrofit (such is the case am assuming that client and server environments with C++). On the other hand, some languages are perwsive. I think there will always be a (like Trellis/OWL) allow a tighter seamless inte- database interface of some sort, at the least some gration with the repository. An important goal code was written by the database company and to achieve is seamless integration for some lan- some was written by the application develop- guages. Languages like C and Modula can call ers. The heart of the system is query process- Trellis types, so they can use Trellis as their DDL ing. Something that the database community and DML. Having two different type systems is has learned is to not be chasing pointers, but a major loss. to state queries declaratively and let the system At the top level is a simple language-independent compile and optimize them. The bottom level model of objects with slots and methods. Each is where we do buffer management, concurrency, object has a type; but there is no concept of and recovery. We have learned that it is nice to a type hierarchy or of an extendable type sys- break out the schema manager. Since schema tem. Compiler writers integrate to this; applica- data tends to be high level and is used a lot for tion programmers never see it. On disk, objects query processing, there needs to be special access are grouped into segrnen~ of large uninterpreted paths through it. byte strings. For performance, the model keeps Even in what appears to be stand-alone systems, the same structure for objects in memory and eventually there is need for inter-connectivity. I on disk and accesses them without translation. see external access through the query processor, Locking at the granularity of a Trellis object has primarily to get things optimized. If the appli- too much overhead, so the segment is the unit of cation chases pointers, typically there is an n- concurrency control. The memory object man- squared algorithm for retrieval across a network; ager provides object abstraction. For the ap- but if the retrieval is formulated as a query, the plication, pointer chasing is the primary perfor- query processor can understand where the data mance metric. If the object being referenced is live using the schema and optimize. not in memory, it needs to be brought in with gO SIGMOD RECORD, Vol. 18, No. 3, September 1989 In a traditional environment, the semantics of time, code is hard to maintain, and reuse of com- an operation tends to be iterative and spread ponents is hardly supported. The low level per- out through the code; with a declarative query formance problem is the disk, even with clus- language, the database is free to organize the tering. If clustering is static, only one class of iteration the way it wants. Our contribution is applications can be optimized for disk access. OSQL - Object-Oriented Extension to Sequel. For a long time, I thought that since the exe- Performance should be measured by save and re- cution model and the data language are com- trieve of complex states by object ID, bulk oper- bined, prefetching is possible.