22.5. Examples of object-oriented DBMS

22.5. Examples of object-oriented DBMS

Currently there are a lot of experimental and production work in the field of object-oriented DBMS. Most of the university works that are mainly of a research nature. But a few years ago, at least thirteen commercially available OODD systems were noted. Among them are the O2, ORION, GemStone and Iris systems already mentioned in our review.

Consider the features of the organization of two of them - ORION and O2.

22.5.1. ORION project

The ORION project was carried out from 1985 to 1989 by the MCC company under the guidance of Won Kim, who was also known for his work in the System R project. The name ORION actually hides a family of three DBMSs: ORION-1 is a single-user system; ORION-1SX, intended for use as a server in the local network of workstations; ORION-2 is a fully distributed object-oriented DBMS. All systems were implemented using Common Lisp language on workstations (and their local networks) Symbolics 3600 with Genera 7.0 and SUN-3 OS in the UNIX OS environment.

The main functional components of the system are memory management subsystems, objects and transactions. In ORION-1, all components are naturally located on the same workstation; in ORION-1SX, they are separated between different workstations (in particular, objects are managed on a client workstation). The use of the remote procedure call mechanism in the ORION-1SX for client-server interaction allowed using many ORION-1 modules in this system with virtually no rework. Network interactions were based on standard operating system tools.

The functions of the memory management subsystem include the allocation of external memory, the movement of pages from memory buffers to external memory and vice versa, the search and placement of objects in memory buffers (as is customary in object-oriented systems, two representations of objects are supported — disk and memory ; when you move an object from the page buffer to the object buffer and back, the representation of the object changes). In addition, this subsystem is responsible for maintaining auxiliary index structures designed to speed up the execution of queries.

The object management subsystem includes subcomponents of query processing, schema management, and object versioning. Versions are supported only for objects, during the creation of which such a need was explicitly indicated. For the database schema, versions are not supported; When a schema changes, the effect of this change on other components of the schema and on existing objects is monitored. When processing requests, an optimization technique similar to that used in relational systems is used (that is, a set of possible plans for fulfilling a query is formed, the cost of each of them is estimated and the cheapest one is selected for execution).

The transaction management subsystem provides the traditional serializability of transactions, and also supports the means of logging changes and restoring the database after failures. To serialize transactions, a kind of two-phase synchronization capture protocol is used with varying degrees of granularity. Of course, the synchronization takes into account the specifics of OODB, in particular, the presence of a class hierarchy. The change log provides rollback of individual transactions and recovery of the database after soft failures (archival copies of the database for recovery from disk failure are not supported).

22.5.2. O2 project

The O2 project was carried out by the French company Altair, which was formed specifically for the purpose of designing and implementing an object-oriented DBMS. The beginning of the project dates back to September 1986, and it was designed for five years: three years for prototyping and two years for developing an industrial design. After successful completion of the project, a new purely commercial company O2 was organized to support the system and its further development.

The prototype of the system functioned in the client / server mode in the local network of SUN workstations with the corresponding division of functions between the server and the clients.

The main components of the system (apart from the developed set of interface tools) are the query interpreter and the subsystems for managing the circuit, objects and disks. Disk Management, i.e. Maintaining a persistent storage environment is provided by the WiSS system, which O2 developers moved to the UNIX environment.

The greatest functional load is borne by the object management component. The functions of this subsystem include:

• management of complex objects, including the creation and destruction of objects, the selection of objects by name, support for predefined methods, support for objects with an internal set structure, list and tuple;
• control of message passing between objects;
• transaction management;
• management of the communication environment (based on TCP / IP transport protocols on an Ethernet LAN);
• tracking of long-term stored objects (recall that in O2 an object is stored in external memory as long as it is reachable from any long-term stored object);
• management of memory buffers (similar to ORION, the representation of an object in memory differs from its presentation on disk);
• management of object clustering in external memory;
• index management.

A few words about transaction management. The modes differ when parallel execution of transactions that change the database schema is allowed, and when only transactions that change the database interior are executed in parallel. The first mode is usually used at the stage of development of the database, the second - at the stage of application execution. Database recovery tools after failures and rollbacks of transactions can also be turned on and off. Finally, a mode is supported in which all permanently stored objects are loaded into RAM at the start of a transaction to increase the speed of the application system.

The database schema management component is implemented over the object management subsystem: the system supports several classes that are invisible to programmers, including the "Class" and "Method" classes, the instances of which are, respectively, the objects defining the classes and the objects defining the methods. (As you can see, the situation is reminiscent of relational systems, in which service relations-directories describing the database schema are also usually maintained.) Deleting a class that is not a list of class hierarchy or is used in another class or signature of any method is prohibited.

Even the brief description of the features of two object-oriented DBMS shows the pragmatism of the modern approach to the organization of such systems. Their developers do not aspire to the full observance of the purity of the object-oriented approach and use the most simple solutions to problems. While in the community of developers of object-oriented database systems, there is no work that could play a role in this direction, similar to the role of System R in relation to relational systems. Truth and problems OOBD are much more complex than those solved in relational systems.