22.3. Object-Oriented Database Programming Languages

As many researchers and developers point out, an object-oriented database system is a combination of a programming system and a DBMS (an alternative, but no more clarifying point is that an object-oriented DBMS is a DBMS based on an object-oriented data model ).

22.3.1. Loss of correspondence between programming languages ​​and query languages ​​in relational DBMS

We have already said that the main practical need for RDBD is related to the need for building an integrated information systems in some integrated environment. In this environment, there should be no contradiction between the structural and behavioral parts of the project, and effective management of complex data structures in external memory should be supported. Unlike the case of relational systems, where creating an application, you have to simultaneously use a procedural programming language that works on scalar values ​​and a declarative query language oriented on working with sets (this is commonly referred to as impedance mismatch), the OODB language environment is oriented programming system, of course including tools for working with long-term objects. The "naturalness" of the inclusion of tools for working with databases in a programming language means that working with long-term (stored in an external database) objects should be based on the same syntactic constructions (and with the same semantics) as working with temporary ones that exist only during work program objects.

This side of OOBD is closest to the related area of ​​database programming languages. Programming languages ​​OOBD and DB in its many features differ only terminologically; the only significant difference is the maintenance of the class inheritance approach in the first class languages. In addition, second-class languages ​​are, as a rule, more developed with respect to both the type system and the control structures.

Another aspect of the OOBD language environment is the need for query languages ​​that could be used interactively. If access to external database objects in OODB programming languages ​​is mainly navigational in nature, then the declarative style is more convenient for query languages. Declarative query languages ​​to OODB are less developed than programming languages ​​OODB, and with their implementation there are significant problems. In the next section, we will look at the available approaches and their limitations in more detail. But let's start with the OODB programming languages.

22.3.2. Programming languages ​​OODB as object-oriented languages ​​with the support of stable (persistent) objects

To date, we do not know any programming language OODB, which would have been designed entirely from scratch, starting with zero. A natural approach to building such a language was to use (with the necessary extensions) some existing object-oriented language. The beginning of the heyday of the OOBD direction coincided with the peak of the popularity of the Smalltalk-80 language. This language has had a great influence on the development of the first OODB systems, and, in particular, was used as a programming language. It relies heavily on Smalltalk and the well-known commercially available GemStone system.

Difficulties with effective practical implementation of the Smalltalk language prompted the OODB system developers to search for alternative basic languages. The well-known proximity of object-oriented and functional approaches to programming allows us to rather successfully rely on functional programming languages. In particular, Common Lisp is the basis of the ORION project. In this project, Lisp is both an instrumental language and the base of an object-oriented programming language in the ORION environment.

The need for even more efficient implementation forces us to use lower-level languages ​​as the basis of an object-oriented language. For example, in the VBASE system, along with a specially developed TDL language intended for defining types, an object-oriented extension of the C language (C Object Processor) is used. In the already mentioned O2 project, along with the functional object-oriented programming language, two object-oriented extensions of the BASIC and C languages ​​are used. At the same time, as far as can be judged by publications, the most common among users of this system (it is already commercially available) received the CO2 language, which is an extension of the C language. Perhaps this is due only to the wide (and ever increasing) popularity of the C language (and its object-oriented C ++), which has become the true motto of "real programmers." The reasons may be deeper (for example, higher-level languages ​​are too restrictive for professional programmers; it’s not for nothing that most modern implementations of higher-level languages ​​are written in C). Nevertheless, the current situation is exactly like this, and we consider it useful to provide a brief description of the main features of the CO2 language.

22.3.3. Examples of programming languages ​​OOBD

First of all, CO2 is not a completely separate language. This language is part of the O2 multilingual environment and is intended for programming methods of previously defined classes. Classes, method signatures (in fact, prototypes of functions in C terminology) and the names of constantly stored values ​​and objects are defined using a separate database schema definition language.

The name of any object is interpreted as a pointer to the value of this object; the name is made using the usual C operator '*'. Access to the value of an object is possible only from the method of its class, unless the operator '*' is declared explicitly public when enumerating the methods.

The operation of generating a new object of the specified class is supported. Unlike C ++ language in CO2, it is impossible to combine the creation of a new object with its initializations (the concept of the constructor method of the initial value of an object in CO2 is not supported). For initialization, you must either explicitly refer to the appropriate class method with the newly created object (the corresponding "message transfer" mechanism is supported, meaning actually a function call), or use the '*' operator and explicitly assign a new value if '*' is public operator for this class.

CO2 includes tools for constructing tuple values, sets, and lists. The concept of a tuple value is actually equivalent to the concept of the structure of a conventional C language (with the difference that the elements of a tuple can be objects, sets, and lists). For set values ​​and lists, the operations of adding and removing elements as well as a set of set-theoretic operations (and concatenations for lists) are supported.

The basis for manipulating objects stored in the database is an iteration tool that is extended compared to the C language. The iterator is applicable to set-values ​​or lists. In fact, it means the sequential application of the loop body operator to all elements of a set or list. If we recall that a class of objects with the same name implicitly corresponds to the object class of this class implicitly correspond to a stored class of objects for a long time, it becomes clear that the CO2 language iterator provides explicit navigation in the classes of objects. The only thing that remains of the query languages ​​familiar to DBMS users is the limited ability to specify the characteristics of the objects required in the cycle (this is done by using the unmasking operator and explicitly specifying attribute conditions; of course, this requires the '*' operator to be declared public in given class).

O2 developers emphasize that they deliberately made CO2 poorer in possibilities than, for example, C ++, because much of the management of objects is assumed by the general object manager of the system, which is explicitly called from the work program.