Object Identity, and Objects versus Literals

DBMS supports object-oriented data. It ensures direct correspondence between real-world objects and their representations in the database. This correspondence ensures that objects retain their integrity and identity. It enables easy identification and manipulation. Object Data Management System (ODMS) assigns unique identity to each independent object stored in the database.

This unique identity is implemented through a system-generated object identifier (OID). This OID serves as distinct value assigned to each object by the system. It is not visible to external users. However it is internally utilized by the system to ensure the unique identification of each object and to establish and manage references between objects. When required, the system assigns the OID to program variables of the appropriate type, operations involving the objects.

Immutability and Uniqueness

Primary requirement for an Object Identifier (OID) in an Object Data Management System (ODMS) is immutability. It is crucial that the OID value assigned to a specific object remains unchanged, ensuring the preservation of the object's identity in the real world. ODMS must incorporate mechanisms for generating OIDs and enforcing their immutability. It is desirable for each OID to be unique and used only once. Even if an object is removed from the database, its OID should not be reassigned to another object.

To fulfill these requirements, OID should not depend on any attribute values of the object. This is necessary because attribute values may change or be corrected over time. In the relational model, each relation requires primary key. If the value of the primary key is altered, tuple will consider new identity. In different relations, real-world object may have different names for its key attributes. It can create challenges in determining if the keys represent the same real-world object. For example, the object identifier may be represented as "Emp_id" in one relation and as "Ssn" in another relation.

Efficient Retrieval with Object Identifiers (OIDs)

Object Identifier (OID) on the physical address of the object in storage is deemed inappropriate in a Database Management System (DBMS). This is because the physical address can change following a physical reorganization of the database. However, some early Object Data Management Systems (ODMSs) have employed the physical address as the OID in order to enhance the efficiency of object retrieval.

To accommodate scenarios where the physical address of an object changes, a mechanism involving an indirect pointer can be utilized. This pointer is placed at the former address and provides the new physical location of the object. Nonetheless, in modern practice, it is more common to assign long integers as OIDs. Subsequently, a hash table or a similar data structure is employed to map the OID value to the current physical address of the object in storage. This approach ensures that the OID remains unaffected by any physical reorganization, while still enabling efficient retrieval of objects.

Early Approaches and Challenges with OIDs

In early Object-Oriented (OO) data models, there was a requirement that all entities, including simple values and complex objects, be represented as objects. Consequently, each basic value like an integer, string, or Boolean value was assigned an Object Identifier (OID). This approach allowed identical basic values to possess different OIDs, which could be advantageous in certain situations. For instance, the integer value 50 could represent the weight in kilograms in one context and the age of a person in another context. By creating two distinct basic objects with separate OIDs, both objects could represent the integer value 50. However, while this approach held theoretical value, it proved impractical as it resulted in the generation of a large number of OIDs.

To address this limitation, most Object-Oriented database systems now support the representation of both objects and literals (or values). Every object must have an immutable OID assigned to it, ensuring its unique identification. In contrast, a literal value does not possess an OID and simply represents its own value. Typically, a literal value is stored within an object and cannot be referenced by other objects. Furthermore, in many systems, complex structured literal values can be created without the need for a corresponding OID, if necessary.

Updated on: 18-May-2023


Kickstart Your Career

Get certified by completing the course

Get Started