OODBMS features

Artificial intelligence systems require data storage and processing subsystems and knowledge. The knowledge base should provide storage and processing of a huge amount of information relationships. This requirement is met by databases / knowledge based on the network data model. One of the promising areas to ensure the storage and processing of complexly structured data and knowledge are object-oriented systems. As it was shown in object-oriented databases should be developed taking into account the application in artificial intelligence systems. In this regard, the development of an object-oriented network database management system / knowledge specifically designed for use in artificial intelligence systems is an important scientific task. The purpose of this work is to analyze the internal architecture of the network object-oriented database / knowledge and the possibility of its application in artificial intelligence systems.

Instance identification

The Cerebrum MSSE uses soft pointers. The object identifier can be considered as a pointer to an object in the system memory. However, from launch to launch, the pointer in memory to the object is obviously not constant. In order to avoid the need to modify objects in the database, the system is implemented so that the object identifier does not depend on time. This can be done in different ways, through indexes, double-addressing ... Soft object identifiers are used in Cerebrum. In the same addressing context, the same object always corresponds to the same identifier. The data type for the object identifier is Cerebrum.Runtime.NativeHandle. Object identifier size is 32 bits. Search for an object in the index by its identifier occurs in three stages. 32 bits are broken into 12, 12 and 8 bits. By this value, a 3-level index tree is built. Collections of objects are organized on the basis of the same mechanism. The collection is the same index 12-12-8, which maps one identifier to another identifier.

An important feature of the Cerebrum SSSR is the difference in the addressing of objects as compared to the ODMG object database standard [4]. In Cerebrum, each object, as in ODMG, is addressed using a soft pointer or the object ID Cerebrum.Runtime.NativeHandle. Pointers to instances of objects external to some current object are retrieved within the context of the current object. An object can only address objects with which it has established a connection. Each object associated with the current one has an identifier. Each unique identifier identifies within the current object an instance of its associated object. Within the current object, each identifier can address only one instance. However, an important difference from the ODMG is the possibility of having several different NativeHandles addressing the same instance within a certain object. Within a given object, several different identifiers can refer to the same object instance. Unlike ODMG, where each object has only one unique identifier in Cerebrum, the same object can have different identifiers. If we consider not one copy, but the entire base, then, by analogy with the phenomena of the natural language of synonymy and homonymy, the phenomenon of synonymy and homonymy of object identifiers arises in the Cerebrum CSP. In different contexts defined by different instances of objects, the same NativeHandle object identifier can address both different instances and the same instance. This phenomenon can be called homonymy of object identifiers. As in natural language with homonymy, the same identifier in different contexts of the same database can address both different and identical instances of objects. As in the same context, and in different contexts, different identifiers can refer to the same object instance. In this case, the phenomenon of synonymy of object identifiers arises, when one copy can have many different identifiers - synonyms within the base. This feature is convenient to use for building semantic and hierarchical semantic networks.

Garbage collection

Currently, there are 3 garbage collection subsystems operating at the Cerebrum CSRMS. The first two subsystems provide the assembly of objects in memory, the third subsystem - in storage. Given the different goals and requirements facing the .NET Framework and Cerebrum, the ideology of the in-memory garbage collection system is significantly different. In .NET, the destruction of an object is possible only after there is no possibility of using it in the current process. This is done by determining the reachability of this object using pointers to the root objects. In contrast, in the Cerebrum core, garbage collection in RAM is performed when the memory allowed for object allocation is exhausted. In this case, unnecessary objects are pushed onto the long-term storage device. The first garbage collection subsystem is built into the Microsoft .NET Framework. It is used in Cerebrum to build non-persistent user objects. For persistent objects, this subsystem is blocked by installing links to the OODB kernel to such an object. The second and third subsystems are implemented in the OODB kernel. The second garbage collection subsystem is used to save instances of user-persistent objects that are not used at the moment. This subsystem is based on the Win32 Memory Block Allocation API. It keeps track of instantiated objects and the number of their locks. Locking / unlocking updates the list of last recently used objects. When the specified number of allocated blocks or the maximum size of allocated memory is exceeded, this subsystem tries to unload unlocked objects to disk storage. First of all, an attempt is made to unload objects that fall into the tail of the list of the most frequently used objects. This hosting system only works for kernel objects that accompany user instances. Manual saving of user objects is not necessary.

The least frequently used objects are automatically pushed onto the long-term storage system, freeing up RAM. Therefore, at any time it is possible to force out and destroy any unlocked user object. If the user has received a pointer to an object and has not performed a lock operation, then the Cerebrum garbage collector may consider this object unused and forcefully push it out of RAM. As a result, a destroyed instance of the object will be in memory on this pointer. To prevent such a phenomenon, a pointer to the IConnector shell object is returned instead of pointers to instances of user objects. In the constructor of the wrapped object, the lock counter of the object is increased, in the destructor, the lock counter is reduced. As long as at least one shell is in memory, the blocking counter is not equal to 0 and the object corresponding to this shell is protected from destruction. This prevents the user instance from being preempted during use. You cannot use pointers to a user instance without saving a pointer to the IConnector shell. An important feature of this system is the need to call the Dispose method on all shell objects to prevent excessive memory consumption.

The IConnector shell object has a Component property through which a user instance is accessible. In most cases, the pattern of working with an object is as follows:

using (IComposite composite =

this.m_Connector.Workspace.AttachConnector (h))

{

ISomeInterface node =

(ISomeInterface) composite.Component;

result = node.SomeMethod (connector, ...);

...

}

When the addressing is done by the h identifier of the object in the this_m_Connector.Workspace.AttachConnector method, its IConnector shell is returned. After completing the object, the shell must be destroyed by calling Dispose. C # using () language directives are needed to ensure that an object is kept in memory during a call to its methods, and then to guarantee a call to Dispose after the object is finished working. Upon exiting from using, Dispose is automatically called and destroys the wrapped object. At destruction, the wrapper object will reduce the lock count. When all the shells are destroyed and the lock counter reaches 0, an instance of the user object will be available to be wiped out of RAM. If for some reason using is not applicable, and the user has forgotten or was unable to call Dispose, then the .NET Framework itself will call Dispose during the garbage collection process. As a result, a memory leak will not occur even with programmer errors.

The third garbage collection subsystem is designed to remove persistent objects from storage. The operation of this subsystem is based on a reference counter. Each persistent object has an incoming pointer count. When an object is not pointed to by any persistent pointer, the object is deleted from the system upon completion of the transaction or during garbage collection, if it is outside the transaction. When an object within a transaction changes to this object, a pointer is created from the current transaction object. As long as there is at least one link to the object, it will exist in the repository. Installing an additional object reference from the transaction object allows you to delay the physical deletion of the object until the end of the transaction and, if necessary, allow you to undo this deletion. If all user links from the object were removed, and at the end of the transaction a link from the transaction object was removed from the object, then the object is marked with a special flag. This flag is valid within RAM. The object is unloaded from the RAM if the object has no locks left. When unloading an object from RAM based on this flag, it is decided whether the object will be permanently destroyed. This allows you to first remove all references to this instance of the object in the repository, leaving it in RAM. Then, using the pointer to the object in RAM, to establish a link with this object from another object, without allowing its physical deletion. Due to the presence in Cerebrum of only operations of installing / removing references to an object and the absence of forced deletion of objects, logical paradoxes do not occur.

Compiling persistent garbage based on reference counting has a drawback: the inability to detect unreachable objects from the database root. Other disadvantaged systems with garbage collection based on reference counting, such as Microsoft COM, also have this disadvantage. Development in this case requires special care when deleting references to objects. The programmer must avoid circular references unreachable from the root of the database. In the future, it is possible to make the fourth garbage collection subsystem in the Cerebrum Prototype Collection Facility that will work based on the accessibility of an object from the database root. Due to the very high computational costs of such a garbage collection mechanism, it should be launched during the "sleep" or inactivity of the system.

Data model

The data model in the SSSR Cerebrum is a graph with colored edges, the nodes of the graph are objects. The object can also be a graph with colored edges at the nodes of which there are other objects. Each edge has only one "color". The color is not an object, the color is of the same type as the object identifier (Cerebrum.Runtime.NativeHandle). The color of the edge corresponds to the type of connection between the nodes. If you need to match the color of the edge with any object, you need to create some object and take its NativeHandle as the “color” for coloring the edge. Thus, it is possible to color edges in the "colors" of instances of objects. Or in other words: create objects that match the colors of the edges. If you want to imitate the coloring of an edge with a set of colors, then you need to make several edges, each of a different “color”.

Within a node, it is possible to create child objects that are addressed within this node by some unique NativeHandle. These identifiers may be the same for different child objects within different parent objects. This allows you to establish a relational relationship (by value) between children of different levels of different parent objects.

A node in Cerebrum is an aggregation of several objects. The first is the Kernel Object. KernelObjectClass kernel object type defines the role of this node in the data model. Kernel Object is a native VNPI Object implemented in C. The application developer does not have direct access to this object. Work with Kernel Object is carried out through a shell object. The type of the wrapper object that is returned during an addressing depends on the type of kernel object. Directly in Cerebrum.Runtime.dll 3 different types of kernel objects are available for use. This is Scalar, Stream and Warden. Scalar objects are used to create nodes that store scalar values, such as System.Int32 or System.String. Such nodes cannot communicate with other nodes as parent objects. Or, equivalently, such nodes cannot be sources of connections. Nodes of the Scalar type can only act as child objects. Stream type nodes are similar to Scalar nodes, but in the place of scalar values ​​they store byte streams by analogy with the BLOB field in the RDBMS.

Nodes of the Warden type can be connected to other nodes using unidirectional links. Each link must be assigned an identifier. From the node of the source of communication it is possible to detect an instance associated with it. However, from the node to which the link points, it is impossible to determine either the nodes from which the links emanate, nor the fact of the link itself. It can be said that the node of the source of communication is the parent object, and the node of the communication receiver is a child. In this case, it is impossible to determine the parent object for some specific object. Each instance may have several such parent nodes. For compatibility with the lightweight pattern, the nodes in Cerebrum do not store references to the parent nodes, and it is also impossible to determine the identifier of the current object from the internal context of this object.

The second object in the aggregate is an instance that implements the IConnector interface. An instance of this object is created and provided by the PASS. This instance is passed to the user object when it is initialized. Through the IConnector.Workspace property, the user object has access to the instance that implements the IWorkspace interface.

The third object in the aggregate is an instance of a user persistent object. Special restrictions on this object are not imposed. It can be an instance of any class of the .NET Framework inherited from System.Object. If the user object is a reference type, then it will be rational to implement IComponent interfaces in this object and, if necessary, IPersistent / IDiscovery. It is recommended to inherit custom reference type objects from Cerebrum.Integrator.GenericComponent. If the parent object received by the identifier the address of the shell object of the child object, then an instance of the child user object is available through the IConnector.Component property.

In order to get a pointer to an instance of a user object, you must call the AttachConnector method in the context of the parent object, passing as the parameter the instance identifier addressing the child object within the parent context. As a result of calling this method, the system will return a new instance of a wrapper object that implements the IConnector and IComposite interfaces. The type of the wrapper object depends on the type of Kernel Object located in this node. The wrapper object also provides interfaces for the Kernel Object functionality to the application programmer. If the Warden object was specified as the kernel object, the shell additionally implements the IContainer interface.

The network does not have a clear concept of hierarchy. In the database, any object can act as a parent and as a child, moreover, objects can be their own parent and child objects. It is also allowed to have cycles when object A is the parent of object B and object B is the parent of object A. This makes it difficult to determine the “beginning” of the database with which you need to start working immediately after the system starts. For this, a special object root instance is implemented in the database - Sector. Sector is a separate instance of the Warden core object. If necessary, a pointer to its shell can be obtained as IWorkspace.GetSector (); however, for convenience and efficiency, its IContainer interface is combined with the IWorkspace interface and is available directly through IWorkspace.

For convenience, Cerebrum implements collections of objects called tables [2]. A table consists of two collections of objects — attributes and user instances. It automates the process of assigning attribute values ​​to objects based on attribute identifier identifiers.When creating attributes, instances of AttributeDescriptor objects are created as children of the root database object. These objects are assigned unique identifier values ​​within the root object of the database, which are obtained with the help of vector.NextSequence (). Using these identifiers as names, attribute instances are created for user objects that have identifiers equal to the corresponding identifier descriptor identifiers.

findings

The proposed method of identifying instances of objects includes generally accepted in OODB as a special case and allows you to get rid of some of the problems inherent in existing OODB. The support of the network data model in the Cerebrum kernel allows for the implementation of such models as hierarchical semantic networks and semantic network frames. Support for methods in stored objects allows you to implement active semantic networks and artificial neural networks. Due to the presence of automatic garbage collection, the management of the lifetime of objects and resources takes over the SUBZ. The developer is left to initialize the database and continue to focus on solving the problem. This makes Cerebrum's network object-oriented knowledge / data environment a very convenient and promising tool for the development of artificial intelligence systems.