Synonymy / Homonymy

An important feature of the Cerebrum SOBRB is the difference in the addressing of objects compared to the ODMG object database standard. By analogy with the natural language, when the same word in different contexts has a different meaning, and when different words in a context have the same meaning, it is also possible to address different instances of objects in different contexts with the same identifier, or, in some context, address the same instance with different identifiers. In this case, each instance of the persistent object defines its own context of assignment. Within any instance, only synonymy is allowed - when different IDs address the same external entity with respect to the current instance of another object (including the same one if we have a link to ourselves). Homonymy within the context of the distribution is not allowed. On the other hand, there are as many contexts in the database as there are instances. Therefore, within the entire database, each instance can have an almost unlimited number of different identifiers, without any contradiction or conflict.

In Cerebrum, each object, as in ODMG, is addressed using the soft pointer or the object ID of 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 object 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 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.

Extended support for object identifier synonymy / homonymy can be used for various purposes. Including for identification of the type of relationships, when building semantic and hierarchical semantic networks, for identifying attributes of objects, implementing object views & joins.

The specific attribute of an object must have an identifier invariant to the object instance. Different instances of a certain class should receive different instances of the value of their attribute when one or the same attribute identifier is distributed. It is also desirable to be able to find meta information describing an attribute by attribute identifier. Consider an example of the implementation of attributes of objects. Let the attribute identifier be 1000 (the attribute 'Name' is the name of the object). Let there be instances with identifiers 1023 (Name = 'Int32') and 1024 (Name = 'Int64'). In this case, in the global context, we are interested in 3 instances of objects with identifiers 1000, 1023 and 1024. Instance with identifier 1000 is the metadescriptor of the 'Name' attribute. Instance with ID 1023 is a meta descriptor of the type 'Int32' and instance 1024 is a meta descriptor of the type 'Int64'. In the context of objects 1000, 1023 and 1024, the addressing identifier 1000 does not depend on the distribution of the same identifier in the global context. In these contexts, it is possible to create child instances of objects with identifier 1000 and storing not the meta description of the attribute but its value. So in the context of 1023, the attribute 1000 will result in an object being received - the “Int32” lines, in the context of 1024 - the “Int64” lines, and in the context of 1000 - the “Name” lines. Special attention should be paid to the addressing of the identifier 1000 in the context of the attribute meta-writer 1000. Such a call-out returns the name of the meta-writer of the attribute 1000 - the string “Name”. Thus, the meta descriptor of the attribute 'object name' also describes its own attribute 'Name'. The value of attribute 1000 of meta attribute writer 1000 - 'object name' is the string 'Name'. From this example, it can be seen that the identifier 1000 in four different contexts refers to 4 different instances of the object, while describing its own name in its own context.

Object representations must provide object connections. For example, if the Employee object attribute is the object identifier of the Organization, in many cases it will be interesting to get a way to refer to the name of the organization to which this employee belongs. This is ensured by navigating from the Employee object by its attribute 'organization identifier' to an instance of the Organization object and further to the attribute 'name of organization'. The resulting aggregate - the Employee object with the additional attribute 'organization name' must have the same identifier as the original Employee object and must provide transparent access to all the properties of the Employee object and the 'organization name' attribute. In an object database that supports the synonymy / homonymy of object identifiers, this problem can be solved in the following way. It is necessary to declare a new attribute 'name of the organization' as the Organization object has the Name attribute and the Employee object also has the Name attribute. If you add to the Worker object a second attribute with the identifier that duplicates the attribute that already exists in this instance, a logical conflict will arise and it will be impossible to determine which value is required to be returned when the identifier is assigned. In each instance of the Employee class, a copy of the attribute of the Name of the Company object is added as a child attribute with the identifier of this attribute 'company name'. As a result, each copy of the company name will have two different identifiers, one - the name in the context of the Company object and the second - the 'company name' in the context of the Employee object. All employees of the same company will have the same instance of the Company object attribute as the value of the 'company name' attribute.