22.1. The connection of object-oriented DBMS with the general concepts of object-oriented approach

In the most common and classical setting, the object-oriented approach is based on the following concepts:

• object and object identifier;
• attributes and methods;
• classes;
• hierarchy and class inheritance.

Any entity of the real world in object-oriented languages ​​and systems is modeled as an object. When an object is created, it receives a unique identifier generated by the system, which is associated with the object throughout its existence and does not change when the state of the object changes.

Every object has a state and a behavior. The state of an object is the set of its attribute values. Object behavior is a set of methods (program code) that operate on the state of an object. The value of an object attribute is also some object or set of objects. The state and behavior of the object are encapsulated in the object; the interaction of objects is based on the transfer of messages and the implementation of the corresponding methods.

A set of objects with the same set of attributes and methods forms a class of objects. The object must belong to only one class (if you do not take into account the possibility of inheritance). The presence of primitive predefined classes, instance objects of which have no attributes: integers, strings, etc., is allowed. A class whose objects can serve as attribute values ​​for objects of another class is called the domain of this attribute.

Allowed the generation of a new class based on an existing class - inheritance. In this case, a new class, called a subclass of an existing class (superclass), inherits all the attributes and methods of the superclass. In the subclass, in addition, additional attributes and methods may be defined. There are cases of simple and multiple inheritance. In the first case, the subclass can be determined only on the basis of one superclass, in the second case there can be several superclasses. If the language or system supports single class inheritance, the set of classes forms a tree hierarchy. When maintaining multiple inheritance, classes are connected to a directed graph with a root, called a class lattice. A subclass object is considered to belong to any superclass of this class.

One of the later ideas of the object-oriented approach is the idea of ​​a possible redefinition of the attributes and methods of the superclass in the subclass (method overloading). This possibility increases flexibility, but it creates an additional problem: when compiling an object-oriented program, the structure and program code of an object's methods may not be known, although its class (in general, the superclass) is known. To solve this problem, a so-called late binding method is used, which means, essentially, an interpretative mode of program execution with recognition of the details of the implementation of an object while sending a message to it. The introduction of some restrictions on the method of defining subclasses allows achieving an effective implementation without the need for interpretation.

As can be seen, with such a set of basic concepts, if one ignores the possibility of class inheritance and the corresponding problems, the object-oriented approach is very close to the approach of programming languages ​​with abstract (or arbitrary) data types.

On the other hand, if we abstract from the behavioral aspect of objects, the object-oriented approach is very close to the approach of semantic data modeling (even in terminology). The fundamental abstractions underlying the semantic models are also implicitly used in the object-oriented approach. The aggregation abstraction is based on the construction of complex objects, the attribute values ​​of which may be other objects. Abstraction grouping - the basis of the formation of classes of objects. On the abstractions of specialization / generalization based on the construction of a hierarchy or a lattice of classes.

Apparently, the most important new quality of OODD, which can be achieved by an object-oriented approach, is the behavioral aspect of objects. In applied information systems based on databases with traditional organization (up to those based on semantic data models), there was a fundamental gap between the structural and behavioral parts. The structural part of the system was supported by the entire database engine, it could be modeled, verified, etc., and the behavioral part was created in isolation. In particular, there was no formal apparatus and system support for joint modeling and ensuring the consistency of these structural (static) and behavioral (dynamic) parts. In the OOBD environment, the design, development and maintenance of an application system becomes a process that integrates structural and behavioral aspects. Of course, this requires special languages ​​that allow you to define objects and create an application system based on them.

The specificity of the application of an object-oriented approach to the organization and management of the database required a refined interpretation of classical concepts and some of their expansion. This is determined by the needs of long-term storage of objects in external memory, associative access to objects, ensuring a consistent state of OODB in multi-access conditions, and similar features inherent in databases. There are three aspects that are absent in the traditional paradigm, but are required in OODB.

The first aspect concerns the need for knowledge specification tools when defining a class (integrity constraints, deduction rules, etc.). The second aspect is the need for a mechanism for determining various semantic links between objects, generally speaking, of different classes. In fact, this means the requirement of full dissemination of data semantic modeling tools to OODD. The need to use abstraction association is noted in connection with the use of OODB in the field of computer-aided design and engineering. Finally, the third aspect is related to the revision of the concept of class. In the context of OODD, it is more convenient to consider a class as a set of objects of a given type, i.e. simultaneously support concepts of both type and class of objects.

As we noted in the introduction, there is no complete agreement in the community of OODB researchers and system developers, but in most of the practical work some extension of the object-oriented approach is used.