[The following is the latest version of my public survey into the schema evolution and database conversion support exhibited by known research and commerical DB and OODBMS. Entries prefixed with asterisks denote possibly-evolving systems whose entry has not been updated specifically for this (major) version. I would very much appreciate any current information on those systems. The most recent copy of this summary will be available indefinitely at URL:ftp://ftp.cs.cmu.edu/afs/cs/user/clamen/OODBMS/evolution-summary.gz I am particularly grateful for all of you who have contributed information appearing here. I solicit continuous updates to the systems listed herein, and request information on additional entries. -- SMC ] Version: 3.4 Last update: 28Oct94 --------------------*-*--------------------- Direct quotes are attributed by including the email address of the poster directly following the information. Prose written by the poster, but with primary information provided by email are so identified. Information gleaned from publications is so noted. The information included here is not intended to completely describe the systems addressed, but rather, to describe what support, if any, is provided by the system for the evolution of schemas and the conversion of database objects (class instances) resulting from the schema change. Stewart M. Clamen ----------*-*---------- TABLE OF CONTENTS Extended Relational Database Model Research Systems POSTGRES Object-Oriented Data Model Research Systems AVANCE ConceptBase CLOSQL COOL/COCOON Encore Exodus Machiavelli NO2 in CoOMS OBST Orion [see also Itasca] OTGen Commercial Systems Common Lisp Object System (CLOS) EasyDB (Objective Systems, Sweden) GemStone The IDB Object Database (Persistent Data Systems) Itasca Matisse Montage O_2 * Objectivity/DB ObjectStore Ontos * Statice Versant Other Models Research Systems IRIS Commercial Systems Kala * Pick ----------*-*---------- <<< EXTENDED RELATIONAL DB MODEL >>> << Research Systems >> >> POSTGRES (Berkeley) You ask explicitly about type evolution. We support schema modification on all classes, including user classes. This means that you can add attributes (instance slots) and methods at any time. Further, since postgres is a shared database system, such changes are instantly visible to any other user of the class. The language syntax supports attribute deletion, but the system won't do it yet. Since all data is persistent, removing attributes from a class requires some work -- you need to either get rid of or ignore all the values you've already stored. ADDITIONAL REFERENCES: M. Stonebraker and G. Kemnitz. "The POSTGRES Next-Generation Database Management System." Appeared in "Communications of the ACM", 34(10):78-92, October 1991. The POSTGRES system is available via anonymous FTP at: FTP: s2k-ftp.CS.Berkeley.EDU:/pub/postgres/postgres-v4r1 Due to Mike Olson , but recently verified by: [Paul M. Aoki ] <<< OO DATA MODEL >>> << Research Systems >> >> AVANCE (SYSLAB) An object-oriented, distributed database programming language. Its most interesting feature is the presence of system-level version control, which is used to support schema evolution, system-level versioning (as a way of improving concurrency), and objects with their own notion of history. System consists of programming language (PAL) and distributed persistent object manager. REFERENCES: Anders Bjornerstedt and Stefan Britts. "AVANCE: An Object Management System". Proceedings of OOPSLA88. [clamen] >> CLOSQL (University of Lancaster) CLOSQL is a prototype object environment written on top of CLOS [c.f. CLtL II]. CLOSQL implements a class versioning scheme (like ENCORE), but employs a conversion adaptation strategy. Instances are converted when there is a version conflict, but unlike ORION, CLOSQL can convert instances to older versions of the class if necessary. REFERENCES: Simon Monk and Ian Sommerville. "A Model for Versioning Classes in Object-Oriented Databases." Proceedings of the Tenth British National Conference on Databases (BNCOD10). Aberdeen, Scotland. July, 1992. [clamen, srm@computing.lancaster.ac.uk] >> ConceptBase We have developed a deductive object base manager called ConceptBase where everything (tokens, classes, meta-classes, meta-meta-classes, attributes, instantiations, specializations) is treated as an object. That means that you may update the "schema" classes at any time just as any other object. The systems has user-defined and builtin integrity constraints that prevent inconsistency (e.g. violation of referential integrity). Integrity constraints in ConceptBase are static, i.e., they are conditions that each database "state" must satisfy. The data model we use does not distinguish schema level information (i.e. classes) from instance level information. If you change for example some classes and this change violates some integrity constraints, e.g. some instances now don't have the right attribute types anymore, then you have the choice either to reject the update or to change the existing DB. Currently, ConceptBase simply rejects such updates. ADDITIONAL INFORMATION: The system and the data model is described in: M. Jarke, S. Eherer, R. Gallersdorfer, M.A. Jeusfeld, M. Staudt. "ConceptBase -- a deductive object base manager." Aachener Informatik-Berichte 93-14, 1993. An application of the system for schema evolution is described in: M. Jarke, M.A. Jeusfeld, P. Szczurko. "Three aspects of intelligent cooperation in the quality life cycle." Appears in "International Journal of Intelligent and Cooperative Information Systems", also appeared as Aachener Informatik-Berichte 93-21, 1993. The reports are available via anonymous ftp from : FTP: ftp.informatik.rwth-aachen.de/pub/reports/1993 Visit the World Wide Web page at: http://www.informatik.rwth-aachen.de/I5/CBdoc/cbflyer.html The system is available for research purposes. Contact CB@picasso.informatik.rwth-aachen.de for more information. [Manfred A. Jeusfeld ] >> COOL/COCOON (Ulm Universitaet) Project goals are: - to develop a general formal framework for investigations of all kinds of schema changes in object-oriented database systems (including schema design, schema modification, schema tailoring, and schema integration); - to find implementation techniques for evolving database schemas, such that changes on the logical level propagate automatically to adaptations of the physical level (without the need to modify all instances, if possible). In a recent paper [TS:ES92], schema evolution is used as example of a general framework for change in OODBs, supporting change on three levels of database objects: data objects, schema objects, and meta-schema objects. REFERENCES: [ST:ISAI94] M.H. Scholl, M. Tresch, and H.-J. Schek. Evolution towards, in, and beyond Object Databases. In Proc. 3rd GI-Workshop on Information Systems and Artificial Intelligence, Hamburg, Germany, March 1994. Springer, LNCS, to appear. [TS:DASFAA93] M. Tresch and M.H. Scholl. Schema transformation processors for federated objectbases. In Proc. 3rd Int'l Symp. on Database Systems for Advanced Applications (DASFAA), Daejon, Korea, April 1993. [TS:SIGMODRec93] M. Tresch and M.H. Scholl. Schema transformation without database reorganization. ACM SIGMOD Record, 22(1), March 1993. [SST:DOM92] M.H. Scholl, H.-J. Schek, and M. Tresch. Object algebra and views for multi-objectbases. In M.T. "Ozsu, U. Dayal, and P. Valduriez (Eds). Distributed Object Management. Morgan Kaufmann, California, 1993. [TS:ES92] M. Tresch and M.H. Scholl. Meta object management and its application to database evolution. In Proc. 11th Int'l Conf. Entity-Relationship Approach, Karlsruhe, Germany, October 1992. Springer, LNCS 645. Contact Markus Tresch for more information. The papers referenced above can be found at the following location: URL: ftp://ftp.informatik.uni-ulm.de/pub/papers/dbis/cocoon file names: .ps.Z >> Encore (Brown University) Objects are never converted, rather, classes are versioned, and the user can specify filters to make old-style instances appear as new instances to new applications (and vice versa). REFERENCES: Andrea H. Skarra, and Stanley B. Zdonik. "Type Evolution in an Object-Oriented Database." In the book, "Research Directions in Object-Oriented Programming", by Shriver and Wegner. (An earlier version of the paper appears in the proceedings to OOPSLA86.) [clamen] >> Exodus (University of Wisconsin) No solution for the problem of schema evolution is provided. Emulation is rejected by the authors, who claim that the addition of a layer between the EXODUS Storage Manager and the E program would seriously reduce efficiency. Automatic conversion, whether lazy or eager, is also rejected, as it does not mesh well with the C++ data layout. To implement immediate references to other classes and structures, C++ embeds class and structure instances within its referent. The resulting change in the size of the object might invalidate remote pointer references. Joel E. Richardson and Michael J. Carey. "Persistence in the E langauge: Issues and Implementation." Appeared in "Software -- Practice and Experience", 19(12):1115-1150, December 1989. [clamen] >> Machiavelli (University of Pennsylvania) Machiavelli is a statically-typed programming language developed at the University of Pennsylvania. Its most outstanding innovation is the use of conditional typing scheme in its type inference system. It does not address type evolution. [communication with limsoon@saul.cis.upenn.edu] [Ed. Note: Machiavelli is included in this summary because it previously incorporated persistence in its data model.] >> NO2 in CoOMS We have a technical report on schema evolution issues in the CoOMS DBMS. CoOMS is currently developed as a part of the ESPRIT project called ITHACA. CoOMS features the NO2 data model, one would call structurally object-oriented, i.e. features no methods (yet) but provides a rich value and object construction system. Here's the abstract of the report "Schema Evolution in NO2" "This paper gives an overview of the schema evolution capabilities of the structurally object-oriented data model NO2. The overview starts with a survey of the inherent in tegrity constraints of NO2 (schema invariants) which have to be preserved by any schema change. A taxonomy of possible schema changes is given. For each possible change, a short description is given which illustrates the effects to parts of the schema, and, equally important, to possible databases corresponding to the respective schema. Moreover, different strategies for the realization of schema changes are presented." Note that emphasis was on the taxonomy, i.e. no extensions to the data definition language are proposed in this paper. The taxonomy served as basis for a discussion of schema evolution issues with our partners at Siemens. ADDITIONAL INFORMATION: A. Geppert, K.R. Dittrich, V. Goebel, S. Scherrer. "The NO2 Data Model", IFI Report 93.09 FTP: claude.ifi.unizh.ch:/pub/techreports/ifi-93.09.ps.Z A. Geppert, K.R. Dittrich, S. Scherrer. "Transaction Management in CoOMS", IFI Report 93.10. FTP: claude.ifi.unizh.ch:/pub/techreports/ifi-93.10.ps.Z S. Scherrer, A. Geppert, K.R. Dittrich. "Schema Evolution in NO2", IFI Report 93.12. FTP: claude.ifi.unizh.ch:/pub/techreports/ifi-93.10.ps.Z Andreas Geppert, Stefan Scherrer, Klaus R. Dittrich. "Derived Types and Subschemas: Towards Better Support for Logical Data Independence in Object-Oriented Data Models", IFI Report 93.27. FTP: claude.ifi.unizh.ch:/pub/techreports/ifi-93.27.ps.Z [Stefan Scherrer ] >> OBST (FZI [Forschungszentrum Informatik], Karlsruhe, Germany) The current version of OBST (3-3.4) does not provide much support for schema evolution. Users may access the meta-database and modify its contents in order to adapt an application schema, but they do so at their own risk and without any kind of support. Existing instances are not adapted automatically; therefore only class interfaces (class/attribute/method names, parameters, ...) should be modified. The next major release (OBST3-4), which is currently undergoing tests, will provide new functionality to make schema modifications more comfortable. This release will also be equipped with a graphical environment for schema design and modification, built with the tclOBST interface. A log of all schema updates will be maintained, from which instance adaptation functions can be generated. In a later release, user defined adaptation functions will also be supported. A first prototype of a view concept for ooDBS that does not require the availability of stored classed extents has also been implemented and will be released together with OBST3-4. [obst@fzi.de] ADDITIONAL INFORMATION: Bernhard Schiefer, "Supporting Integration & Evolution with Object-Oriented Views", FZI-Report 15/93, July 1993. Available via anonymous ftp via: ftp.fzi.de:/pub/DBS/stone-reports/Integration_with_Views.ps.gz The OBST system itself is available by anonymous FTP from ftp.fzi.de:/pub/OBST Contact obst@fzi.de for more information. >> ORION (MCC) ORION was a prototype OODBMS developed at MCC, an American consortium. (NOTE: It is now marketed as Itasca by Itasca Systems in Minnesota, see entry below.) ORION is built on top of Common Lisp, and is intended to support applications such in the CAD/CAM, AI, and OIS domains. Advanced functions supported include [object] versions, change notification, composite objects, dynamic schema evolution, and multimedia data. For schema evolution, ORION identifies a list of database-consistency constraints that must be preserved across any class evolution operation. They then list the type of evolution operations you can perform, and how the relevant instances can be converted. Conversion is performed as the instances are accessed. REFERENCES: I have found nearly a dozen papers published by the ORION folks. The most recent and general one is: W. Kim, N. Ballow, H-T. Chou, J.F. Garza, D. Woelk, and J. Banerjee. "Integrating an Object-Oriented Programming System with a Database System." Proceedings of OOPSLA88. [Pointers to the previous papers documenting each of the advanced features listed above are cited therein.] The paper most relevant to the issue of schema evolution is the following: J. Banerjee, W. Kim, H.J. Kim, H.F. Korth. "Semantics and Implementation of Schema Evolution in Object-Oriented Databases." Proceedings of SIGMOD87. You might also like to look at Kim's book: Won Kim. _Introduction to Object-Oriented Databases_. MIT Press, Cambridge, Mass., 1990. [clamen] >> OTGen (Carnegie Mellon University/UMass Amherst) OTGen describes a scheme for computer-assisted schema evolution. A wide variety of changes (wider than those supported by Orion) be expressed in the evolution "mini-language", which describes a procedure for transforming instances from their new to old representations. Objects are converted as databases (which in the invisioned OTGen system are rather small) are opened. REFERENCES: Barbara Staudt Lerner and A. Nico Habermann. "Beyond Schema Evolution to Database Reorganization" in Proceedings of OOPSLA/ECOOP '90. [clamen, blerner@cs.umass.edu] << Commercial Systems >> >> Common Lisp Object System Not persistent, but implementations must support redefinition of classes and the conversion (either lazy or eager) of existing instances. [c.f. CLtL II] In spite of this freedom, implementations seem to convert lazily. [communication with gregor@parc.xerox.com, hornig@symbolics.com, dussud@lucid.com] The generic function UPDATE-INSTANCE-FOR-REDEFINED-CLASS discards old slots (and the values of redefined slots). However, the generic can be overriden by the user, allowing for arbitary instance conversion procedures. REFERENCES: [CLtL II] Steele, Jr., Guy L. _Common Lisp: The Language_. Second Edition. Digital Press. 1990. >> EasyDB (Objective Systems, Sweden) EasyDB features a (programming language independent) Data Definition Language (DDL) for the definition of schemas. It relies on the Entity-Attribute-Relationship model combined with object orientation. Data Manipulation Languages (DML) include a Navigational Query language (NQL) embedded in a host language (C and Ada), a generic C++ class library, and an interactive ad-hoc query language. The schema may be freely extended with new items (types, domains, attributes, entities, relationships etc.). Deletion of items is not allowed. Data created with an older schema may co-exist with newer data. Old applications need not be recompiled when the schema is updated. Running applications will not be interrupted during schema changes. Attempts by newer applications to access `older' data in an inconsistent way are detected and reported via an exception handling system. [Jaan Haabma ] >> GemStone (Servio Corporation) As of version 3.2, GemStone supports very flexible dynamic schema modification. Some of the common class creation methods will create new classes as versions of existing classes with the same name. (Other methods allow creating disjoint classes with the same name.) Additional methods allow the user to specify that instances of the old version(s) are to be migrated to the new version, and to perform the migration on demand. Instances can be migrated in bulk or individually. For simple migrations, such as the addition or removal of an instance variable, GemStone provides a default migration mechanism which copies data from each instance variable of the old object to the instance variable of the same name in the new object (if one exists). Users can write methods in the new class to customize this migration on a class-by-class basis. This allows maximum flexibility in specifying migration behavior. GemStone does not perform automatic migration of instances, as in a multi-user production database this can be unnecessarily dangerous for 24x7 applications. The exception is for leaf classes (classes with no subclasses), which can have instance variables added to them with no need for manual migration. Newly added instance variables are given a 'nil' value on access. Since Objectworks Smalltalk and Smalltalk/V permit only one version of a given class to exist at any time, the GemStone interface to these environments provides a compromised interaction between Smalltalk and GemStone. The GemStone Smalltalk Interface attaches to a single version of a given GemStone class. Instances of a different version of that class which need to be replicated into Smalltalk will be presented to Smalltalk in the form of the version it wants to see. If that object is subsequently modified and written back to GemStone, at that point in time the database version of the object will be migrated. [Marc San Soucie ] ADDITIONAL REFERENCES: Robert Bretl, David Maier, Allan Otis, Jason Penney, Bruce Schuchardt, Jacob Stein, E. Harold Williams, Monty Williams. "The GemStone Data Management System." Chapter 12 of "Object-Oriented Concepts, Databases and Applications", by Kim and Lockovsky. [getting old and dusty though -- SMC] >> The IDB Object Database (Persistent Data Systems) The IDB Object Database is a commercial object database available for both personal computers and workstations. We are about to release Version 2.5 (Summer '94). IDB has roots in the IDL (Interface Description Language) technology originally developed at CMU in the early '80's. IDB schemas may be written in a subset/extension of IDL or they may be developed using an interactive schema designer. An IDL translator binds the schema to the data types of a target programming language (currently C) and builds a run-time symbol table. The language binding is used by the programmer to manipulate IDB data; the symbol table is used by the IDB run-time system. The representation of IDB data on disk is very close to its representation in memory and can be read/manipulated/written only using the appropriate schema. However, all IDB data also has an ASCII external representation that is self describing (objects and their attributes are represented as name-value pairs). In the general case, when a developer makes an arbitrary change to an IDB schema, the developer must also write a program to convert existing data. (Read it in using the old schema, transform it, and write it out using the new schema.) In many cases, however, the conversion may be done automatically off-line by converting to and from the ASCII external form. These cases include: - changes to the physical representation of sequences (linked list <-> array) or the sizes of integers - adding a class - adding new boolean, integer or rational-valued attributes to a class - adding new class-valued attributes when the class representation includes nil - removing attributes [borison@persist.com] ADDITIONAL REFERENCES: John R. Nestor. "IDL: The Language and Its Implementation". Prentice Hall. Engelwood Cliffs, NJ., 1989. >> Itasca ITASCA offers the most complete set of dynamic schema change operations in the industry. Taxonomy of schema changes in ITASCA: Changes to the contents of a class Changes to an attribute Add a new attribute Drop an existing attribute Change the name of an attribute Change the domain of an attribute Change the inheritance of an attribute Change the default value of an attribute Changes to a method Add a new method Drop an existing method Change the name of a method Change the code of a method Change the inheritance of a method Changes to a class Add a new class Drop an existing class Change the name of a class Changes to the superclass/subclass relationship Make a class S a superclass of a class C Remove a class S as the superclass of a class C Any of these changes can be performed at run-time without offloading data or recompiling/relinking applications. Instances whose class definition have changed are updated at access time (lazy update). Itasca's schema evolution facilities do not differ significantly from those described in the various ORION papers (see entry above). Contact the address below for more general technical information. [info@itasca.com] >> Matisse With MATISSE, the schema AND meta-schema are objects like any user data. Thus, they are subjected to concurrency, VERSIONING, etc ... One can manipulate these objects with the exact same API used to manipulate data, and see their complete description (including attributes, methods, relationships, inheritance, default values, constraints, trigger, etc...). This allows a user to change the schema and meta-schema dynamically, without any recompilation involved. M.A.T.I.S.S.E. has been designed to support large databases, large applications and large numbers of users. When a schema modification occurs, going over all the instances affected by this change to check them or even convert them would be unacceptable in term of performances for a real-world database application. The approach used by M.A.T.I.S.S.E. is the following: it will allow any schema modification that will not make any existing instance invalid. Here are several examples of possible schema modifications: - Modifying the name of a class, attribute, relationship, message. - Creating a new class, attribute, relationship, message, method. - Removing an attribute from the database. - Adding new attributes, relationships, methods to classes. - Adding super classes to a class. - Removing super classes from a class. When an attribute is removed, the M.A.T.I.S.S.E. DBMS performs lazy updates, for obvious performances reasons. Whenever an object is read, the DBMS will compare its version with the version of its class. If the class is newer, the object is updated. These evolution capabilities coupled with a database-level intrinsic versioning provide a powerful feature to our DBMS: at any time, a user can access a consistent past state of the meta-schema AND schema AND data, as they are part of the same version of the database and they are all stored as objects in the database. For any information, please contact info@adb.com [Laurent Censier >> Montage (Montage Inc.) Montage is a commercialized version of POSTGRES. Montage supports schema modification on all classes, including user classes. This means that you can add attributes (instance slots) and methods at any time. Further, since Montage is a shared database system, such changes are instantly visible to any other user of the class. [Mike Olson ] >> O_2 (INRIA/O_2 Technology) We have implemented in O2 schema updates in our first release but without NO IMPACT on the database (we have a design to implement deferred update, but it is a paper design). However, users manage to convert their instances by hand, using their O_2 programs written themselves, and with the aid of the following tools: 1- There is a set of predefined classes whose instances contain objects representing a schema (i.e., a Meta-schema). These classes may be used in a conversion program, they may even be extended by the programmer. 2- There is a save-restore program that allows to take an O2 database, save it on a file or a tape in a logical way (i.e., independent of the physical format of objects on disk), and restore it again on a (perhaps new release) of the system, in an empty database. Currently, when saving a database its schema is also saved. The next extension to this save/restore program will be to save the database without saving its schema, and then restore the database on a new version of that schema. The restore program will be able to perform automatically some conversions like "add attribute" or "delete attribute". Schema updates with impact on the database will be implemented in future releases. [Fernando Velez ] What is available so far in O2 as far as schema modifications are concerned has already been given by Fernando. (above) [But for the future:] 1) We are working at O2 in order to add the feature of database adaptation to the O2 Object Database after a schema modification has been performed. We will not use versioning for this. The system will be responsible for the restucturing of the objects and to give them default values. O2 will also provide the user the possibility to write down conversion functions for transformations which are not trivial. These conversion functions can read information from the whole database and not only from the object which is under transformation. Since we use a deferred approach for the transformation of objects, a major problem was to mantain the equivalence of results with the immediate approach. The task is part of the ESPRIT III project GOODSTEP. The work will be part of a new product release. 2) At the university of Frankfurt a collegue of mine is adding new so called High Level Primitives for schema evolution to the ones already provided by the system. These High Level Primitives will be more declarative than the ones existing and will give also the new possibility to merge, split classes and so on. The task is part of the ESPRIT III project GOODSTEP, but it is totally implemented on top of O2. If the work done will be part of a next release is a question which has no answer so far. [Fabrizio Ferrandina ] For more information on O_2, consult the following REFERENCES: Francois Bancilhon, Claude Delobel, Paris Kanellakis. "Building an Object-Oriented Database System: The Story of O_2". Morgan Kaufmann Series in Data Management Systems, San Mateo, Calif., 1992. F. Bancilhon, G. Barbette, V. Benzaken, C. Delobel, S. Gamerman, C. Lecluse, P. Pfeffer, P. Richard, and F. Velez. "The Design and Implementation of O2, and Object-Oriented Database System". Advances in Object-Oriented Database Systems, Springer Verlag. (Lecture Notes in Computer Science series, Number 334.) C. Lecluse, P. Richard, and F. Velez. "O2, an Object-Oriented Data Model". Proceedings of SIGMOD88. Also appears in Zdonik and Maier, "Readings in Object-Oriented Database Systems", Morgan Kaufmann, 1990. >> Objectivity/DB (Objectivity) *In the just-released Version 2.0 (shipping Oct 92), schema evolution *is supported via dynamic versioning of type-defining objects [ie. *class versions -- SMC], and via a step-by-step approach that allows *conversion of instance data via user-provided conversion methods. *Also, a full dynamic type manager interface is available for doing *fancier things. [Drew Wade ] >> ObjectStore (Object Design) ObjectStore is an ODBMS produced by Object Design, Inc. Release 3.0 is available now (January 1994). Schema evolution has been available since release 2.0. The kinds of evolution supported include change of a data member's type, addition and removal of data members, and change in inheritance structure. There are default transformations built in, (e.g. from int to float), and user-defined transformations may be run also. [Jack Orenstein, Object Design, Inc. ] >> Ontos ONTOS realizes the importance of managing change and provides schema evolution and instance migration facilities to support changes in an application's object model. Application developers or administrators can easily modify class definitions to add or drop attributes, to change attribute names, to split or merge class definitions, or to change the data type of an attribute. When a class definition is modified, ONTOS DB provides a utility to migrate the instances based on the old class definition to the new class definition. ONTOS DB provides several mechanisms to reflect changes in an application's object model to the database schema stored in ONTOS. First, ONTOS enables schema development through direct definition of C++ classes as defined in an application's C++ header files. Application developers can build a database schema by registering the C++ class definitions to the ONTOS DB using an ONTOS provided utility. At any point in time, an application developer can simply modify the C++ class definitions and reregister the C++ class definitions to the ONTOS DB to reflect the changes in the database schema. Second, ONTOS provides schema development through DBDesigner, a graphical, interactive schema design and browsing tool. DBDesigner allows users to easily browse the classes and instances associated with the application's object model. DBDesigner enables application developers to create and modify application class definitions in the ONTOS DB. DBDesigner also generates C++ header files which can be used to build ONTOS applications. ONTOS DB provides an instance migration utility that migrates instances from an old representation of a type to a new representation of a type. The utility includes the ability to add, remove, change the order of, and change the scope of properties for a given type. ONTOS DB includes the source code for the instance migration utility to afford application developers the ability to enhance the tool beyond the capabilities listed above. Examples requiring customization include changing the name of a property and splitting or merging instances. [Gerard Keating ] >> Statice (Symbolics) I'm familiar with Statice, sold by Symbolics Inc. The Statice command "Update Database Schema" brings an existing database into conformance with a modified schema. Changes are classified as either compatible (lossless, i.e., completely information-preserving) or incompatible (i.e., potentially information-losing in the current implementation). Basically, any change is compatible except for the following: -- If an attribute's type changes, all such attributes extant are re-initialized (nulled out). Note that Statice permits an attribute to be of type T, the universal type. Such an attribute can then take on any value without schema modification or information loss. -- If a type's inheritance (list of parents) changes, the type must be deleted and re-created, losing all extant instances of that type. This is Statice's most serious current limitation. The simplest workaround is to employ a database dumper/loader (either the one supplied by Symbolics or a customized one) to save the information elements and then reload them into the modified schema. [Lawrence G Mayka ] >> Versant (Versant Object Technology) In VERSANT, schema evolution is handled elegantly (and efficiently): 1. When the definition of a class is changed, the LOIDs (Logical Object Identifier) for the instances of the class are not changed. This means that after the class definition has been changed, there is no need to change application code or other objects that reference instances of the changed class. 2. Changes made to the class definition are not applied to all instances at once (lazy update). Changes are applied as instances are individually used in the course of later events. This avoids paralyzing the database(s) by retrieving and altering all instances each time the class definition is changed. This also makes schema evolution very fast. 3. When schema is evolved, the version history is maintained internally. 4. VERSANT can synchronize the definitions of classes in different databases. This feature is especially useful in a multidatabase environment where class definitions may differ across databases. These differences can be resolved at run-time. [Nipun Sehgal ] <<< OTHER MODELS >>> << Research Systems >> >> IRIS (HP Labs) Objects in the Iris system may acquire or lose types dynamically. Thus, if an object no longer matches a changed definition, the user can choose to remove the type from the object instead of modifying the object to match the type. In general, Iris tends to restrict class modifications so that object modifications are not neccssary. For example, a class cannot be removed unless it has no instances and new supertype-subtype relationships cannot be established. REFERENCES: D.H. Fishman, D. Beech, H.P. Cate, E.C. Chow, T. Connors, J.W. Davis, N. Derrett, C.G. Hock, W. Kent, P. Lyngbaek, B. Mahbod, M.A. Neimat, T.A. Tyan, M.C. Shan. "Iris: An Object-Oriented Database Management System". ACM Transactions on Office Information Systems 5(1):48-69, Jan 1987. [clamen] << Commercial Systems >> >> Kala Kala manages an untyped persistent store, implementing the semantics of robust, distributed, secure, changing, and shareable persistent data. Layers built upon the Kala platform can implement the semantics of objects with the same properties. Kala itself provides data transfer and visibility management functionality. As it operates below the schema layer, Kala does not address schema evolution directly. However, It supports the building of schema'ed layers above it and below the application, and those layers can provide for schema evolution conveniently using Kala visibility management primitives. This parts-box approach requires extra work on the part of the developer compared to out-of-the-box solutions, but provides power and flexibility sufficient for relatively low cost solutions in difficult environments (e.g. graph-structured data, dynamic classing) where no out-of-the-box solution is available. For more information, contact Penobscot Development Corp. at Info@Kala.COM. [Ivan Godard ] ADDITIONAL INFORMATION: Sergiu S. Simmel and Ivan Godard. "The Kala Basket: A Semantic Primitive Unifying Object Transactions, Access Control, Versions, and Configurations", Proceedings of OOPSLA'91. The Kala Forum, available via FTP. Table of Contents at: anonymous@world.std.com:pub/kala/TOC >> Pick With Pick and its variants you only have problems if you want to redefine an existing field. Because of the way the data are stored and the separation of the data and the dictionary you can define additional fields in the dictionary without having to do anything to the data - a facility which we have found very useful in a number of systems. There is no general facility to redefine an existing field - you just make whatever changes are required in the dictionary then write an Info Basic program to change the data. We have seldom needed to do this, but it has not been complicated to do. If a field in the database is no longer used, it is often easiest simply to delete the reference to that field in the dictionary, and accept the storage overhead of the unused data. In such cases, while the data cannot be accessed through the query language, (Pick)Basic programs can still access them. [Geoff Miller ] ----------*-*---------- --- Stewart M. Clamen Internet: clamen@cs.cmu.edu School of Computer Science UUCP: uunet!"clamen@cs.cmu.edu" Carnegie Mellon University Phone: +1 412 268 2145 5000 Forbes Avenue Fax: +1 412 681 5739 Pittsburgh, PA 15213-3891, USA (I accept MIME,HTML,Hyperbole,PGP)