22.2. Object Oriented Data Models

The first formalized and generally accepted data model was the Codd relational model. In this model, as in all the following, three aspects were singled out - structural, holistic and manipulative. The data structures in the relational model are based on flat normalized relations, integrity constraints are expressed using first-order logic tools and, finally, data is manipulated on the basis of relational algebra or its equivalent relational calculus. As many researchers have noted, the success of the relational data model is largely due to the fact that it was based on a rigorous mathematical apparatus of the theory of sets, relations, and first-order logic. The developers of any particular relational system considered it their duty to show the conformity of their specific data model to a general relational model, which acted as a measure of the "relationality" of the system.

The main difficulties of object-oriented data modeling stem from the fact that there is no such well-developed mathematical apparatus on which a common object-oriented data model could be based. To a large extent, therefore, there is still no basic object-oriented model. On the other hand, some authors argue that the general object-oriented data model in the classical sense cannot be determined due to the unsuitability of the classical concept of the data model to the paradigm of object orientation.

One of the most well-known theorists in the field of data models, Beeri offers a general outline of the formal framework of OODB, which is far from complete and is not a data model in the traditional sense, but allows researchers and developers of OODB systems to at least speak the same language (if, of course, Beeri will be developed and will receive support). Regardless of the further fate of these proposals, we consider it useful to briefly retell them.

First, following the practice of many OODBs, it is proposed to distinguish two levels of object modeling: lower (structural) and upper (behavioral). At the structural level, complex objects are supported, their identification and the "isa" type of communication. A database is a collection of data elements that are related by a "belongs to a class" or "is an attribute" relationship. Thus, a DB can be considered as a directed graph. The important point is to maintain, along with the concept of the object, the concept of meaning (we will see later how much on this is built in one of the successful object-oriented O2 DBMS).

An important aspect is the clear separation of the database schema and the database itself. Types and classes act as primary concepts of the OOBD circuit level. It is noted that in all systems using only one concept (either type or class), this concept is inevitably overloaded: type assumes the presence of a certain set of values ​​determined by a data structure of this type; the class also assumes that there are many objects, but this set is user-defined. Thus, types and classes play a different role, and rigor and unambiguity require the simultaneous support of both concepts.

Beeri does not represent a complete formal model of the structural level of OODB, but expresses confidence that the current level of understanding is enough to formalize such a model. As for the behavioral level, only a general approach to the logical apparatus required for this is proposed (first-level logic is not enough).

An important, though insufficiently substantiated, assumption by Beeri is that the two traditional levels — schema and data — are not enough for OODB. To accurately define OODB, a meta-schema level is required, the contents of which should determine the types of objects and relationships allowed at the schematic database level. The meta scheme should play the same role for OODB as the structural part of the relational data model for relational database schemas plays.

There are many other publications related to object-oriented data models, but they either touch on quite specific questions or use a mathematical apparatus that is too serious for this review (for example, some authors define an object-oriented data model based on category theory).

To illustrate the current state of affairs, we briefly consider the features of a particular data model used in an object-oriented O2 DBMS (this, of course, is also not a data model in the classical sense).

O2 supports objects and values. An object is a pair (identifier, value), and the objects are encapsulated, i.e. their values ​​are available only through methods - procedures associated with objects. Values ​​can be atomic or structural. Structural values ​​are constructed from values ​​or objects represented by their identifiers, using set constructors, tuples, and lists. Elements of structural values ​​are accessible using predefined operations (primitives).

Two types of data organization are possible: classes whose instances are objects that encapsulate data and behavior, and types whose instances are values. Each class is assigned a type describing the structure of the class instances. Types are defined recursively based on atomic types and previously defined types and classes using constructors. The behavioral side of a class is determined by a set of methods.

Objects and values ​​can be named. The name of an object or value is associated with its long-term storage (persistency): any named objects or values ​​are long-term; any object or value that is included as part of another named object or value is permanent.

With the help of special instructions given in the definition of a class, you can achieve long-term storage of any object of this class. In this case, the system automatically generates a set value, the name of which coincides with the name of the class. This set is guaranteed to contain all objects of this class.

Method - program code tied to a specific class and applicable to objects of this class. The method definition in O2 is made in two stages. First the method signature is declared, i.e. its name, class, types or classes of arguments, and the type or class of the result. Methods can be public (accessible from objects of other classes) or private (accessible only within a given class). At the second stage, the class implementation in one of the O2 programming languages ​​is determined (languages ​​are discussed in more detail in the next section of our review).

The O2 model supports multiple class inheritance based on the supertype / subtype relationship. In a subclass, the addition and / or redefinition of attributes and methods is allowed. In case of multiple inheritance, ambiguities (by naming attributes and methods) are resolved either by renaming, or by explicitly specifying the source of inheritance. A subclass object is an object of each superclass, on the basis of which the given subclass is generated.

The predefined class "Object" is supported, which is the root of the class lattice; any other class is an implicit inheritor of the Object class and inherits the predefined methods ("is_same", "is_value_equal", etc.).

A specific feature of the O2 model is the ability to declare additional "exclusive" attributes and methods for named objects. This means that a particular named class representative object may have a type that is a subtype of the class type. Of course, standard class methods do not work with such attributes, but additional (or standard) methods for which additional attributes are already available can be defined specifically for the named object. It is emphasized that additional attributes and methods are attached not to a specific object, but to a name, after which, at different times, different objects can stand. The implementation of exceptional attributes and methods requires the development of a late binding technique.

In the next section, we will consider, among other things, the features of programming languages ​​and O2 system queries, which, of course, are closely related to the specifics of the data model.