III Year I Sem - CSE Distributed Databases - Class Notes 2024-2025

MODULE – V
Distributed object Database Management Systems: Fundamental object concepts and models,
object distributed design, architectural issues, object management, distributed object storage,
object query Processing.
Object Oriented Data Model: Inheritance, object identity, persistent programming languages,
persistence of objects, comparison OODBMS and ORDBMS

1 Explain various elements of Object oriented data model. 4 L2 5

• An object DBMS is a system that uses an “object” as the fundamental modelling and access
primitive.

Object :
• An object represents a real entity in the system that is being modeled.
• Most simply, it is represented as a tiple {OID, state, interface}, in which OID is the object identifier, the
corresponding state is some representation of the current state of the object, and the interface defines the
behavior of the object.
• Object identifier is an invariant property of an object which permanently distinguishes it logically and
physically from all other objects, regardless of its state.
• The state of an object is commonly defined as either an atomic value or a constructed value (e.g., tuple
or set).
Example 1. Consider the following objects:
(i1, Volvo)
(i2, [name: John, mycar: i1])
(i3, [name: Mary, mycar: i1])

Types and Classes:

• The term “class” refer to the specific object model construct and the term “type” refer to a domain of
objects (e.g., integer, string).
• A class is a template for a group of objects, thus defining a common type for these objects that conform
to the template.
• A class describes the type of data by providing a domain of data with the same structure, as well as
methods applicable to elements of that domain.
• The abstraction capability of classes, commonly referred to as encapsulation, hides the implementation
details of the methods, which can be written in a general-purpose programming language.
• Some subset of its class structure and methods make up the publicly visible interface of objects that
belong to that class.

Composition (Aggregation)
• Composition is one of the most powerful features of object models.
• It allows sharing of objects, referred as referential sharing, since objects “refer” to each other by their
OIDs as values of object-based attributes.

Assume that c1 is one instance of Car type.

If the following is true:
(i2, [name: John, mycar: c1])
(i3, [name: Mary, mycar: c1])
1 P. V Ramana Murthy
LEE; B.E(Comp); M.Tech(CS); (Ph.D(CSE));
Malla Reddy Engineering College (Autonomous)
 III Year I Sem - CSE Distributed Databases - Class Notes 2024-2025

then this indicates that John and Mary own the same car.

• A restriction on composite objects results in complex objects.

• The difference between a composite and a complex object is that the former allows referential sharing
while the latter does not.
• For ex, Car type may have an attribute whose domain is type Tire.

Subclassing and Inheritance

• Object systems provide extensibility by allowing user-defined classes to be defined and managed by the
system.
• This is accomplished in two ways:
➢ by the definition of classes using type constructors or
➢ by the definition of classes based on existing classes through the process of subclassing.
• Subclassing is based on the specialization relationship among classes (or types that they define).
• A class A is a specialization of another class B if its interface is a superset of B’s interface.
• Thus, a specialized class is more defined (or more specified) than the class from which it is specialized.
• A class may be a specialization of a number of classes; it is explicitly specified as a subclass of a subset
of them.

• Declaring a class to be a subclass of another results in inheritance.

• If class A is a subclass of B, then its its properties consist of the properties that it natively defines as well
as the properties that it inherits from B.
• Inheritance allows reuse.
• A subclass may inherit either the behavior (interface) of its superclass, or its implementation, or both.
• Single inheritance and multiple inheritance based on the subclass relationship between the types.
• Obviously, Vehicle is a generalization of Car.
• Car can now be defined as follows:
type Car as Vehicle
attributes
bumpers : {Bumper}
tires : [LF: Tire, RF: Tire, LR: Tire, RR: Tire]
capacity : Integer
• Even though Car is defined with only two attributes, its interface is the same as the definition for veficle.
• This is because Car is-a Vehicle, and therefore inherits the attributes and methods of Vehicle.

2 Discuss architectural issues in distributed object DBMS. 4 L2 5

•
The preferred architectural model for object DBMSs has been client/server.
•
The design issues related to these systems are somewhat more complicated due to the characteristics of
object models.
The major concerns are listed below.
1. Since data and procedures are encapsulated as objects, the unit of communication between the clients
and the server is an issue.
The unit can be a page, an object, or a group of objects.
2. Closely related to the above issue is the design decision regarding the functions provided by the clients
and the server.

2 P. V Ramana Murthy
LEE; B.E(Comp); M.Tech(CS); (Ph.D(CSE));
Malla Reddy Engineering College (Autonomous)
 III Year I Sem - CSE Distributed Databases - Class Notes 2024-2025

This is especially important since objects are not simply passive data, and it is necessary to consider the
sites where object methods are executed.
3. In relational client/server systems, clients simply pass queries to the server, which executes them and
returns the result tables to the client. This is referred to as function shipping.
• In object client/server DBMSs, this may not be the best approach, as the navigation of
composite/complex object structures by the application program may dictate that data be moved to
the clients (called data shipping systems).
• Since data are shared by many clients, the management of client cache buffers for data consistency
becomes a serious concern.
• Client cache buffer management is closely related to concurrency control, since data that are cached
to clients may be shared by multiple clients, and this has to be controlled.
• Most commercial object DBMSs use locking for concurrency control, so a fundamental architectural
issue is the placement of locks, and whether or not the locks are cached to clients.

4. Since objects may be composite or complex, there may be possibilities for prefetching component
objects when an object is requested.
• Relational client/server systems do not usually prefetch data from the server, but this may be a valid
alternative in the case of object DBMSs.

Describe in detail cache consistency and object identifier management

3 4 L2 5
in object management.
cache consistency:
• Cache consistency is a problem in any data shipping system that moves data to the clients.
• The study of DBMS cache consistency is very tightly coupled with the study of concurrency control,
since cached data can be concurrently accessed by multiple clients, and locks can also be cached along
with data at the clients.
• The DBMS cache consistency algorithms can be classified as avoidance-based or detection-based.

Avoidance-based algorithms prevent the access to old cache data by ensuring that clients cannot update an
object if it is being read by other clients.
• So they ensure that old data never exists in client caches.

Detection-based algorithms allow access of old cache data, because clients can update objects that are being
read by other clients.
• However, the detection-based algorithms perform a validation step at commit time to satisfy data
consistency requirements.

Avoidance-based and detection-based algorithms can, in turn, be classified as synchronous, asynchronous

or deferred, depending upon when they inform the server that a write operation is being performed.
• In synchronous algorithms, the client sends a lock escalation message at the time it wants to perform a
write operation, and it blocks until the server responds.
• In asynchronous algorithms, the client sends a lock escalation message at the time of its write operation,
but does not block waiting for a server response (it optimistically continues).
• In deferred algorithms, the client optimistically defers informing the server about its write operation until
commit time.
• In deferred mode, the clients group all their lock escalation requests and send them together to the server
at commit time.

3 P. V Ramana Murthy
LEE; B.E(Comp); M.Tech(CS); (Ph.D(CSE));
Malla Reddy Engineering College (Autonomous)
 III Year I Sem - CSE Distributed Databases - Class Notes 2024-2025

• Thus, communication overhead is lower in a deferred cache consistency scheme, in comparison to

synchronous and asynchronous algorithms.

object identifier management:

• Object identifiers (OIDs) are system-generated and used to uniquely identify every object
(transient or persistent, system-created or user-created) in the system.
• Implementing the identity of persistent objects generally differs from implementing transient
objects, since only the former must provide global uniqueness.
• In particular, transient object identity can be implemented more efficiently.
• The implementation of persistent object identifier has two common solutions, based on either
physical or logical identifiers, with their respective advantages and shortcomings.
• The physical identifier (POID) approach equates the OID with the physical address of the
corresponding object.
• The address can be a disk page address and an offset from the base address in the page.
• The advantage is that the object can be obtained directly from the OID.
• The drawback is that all parent objects and indexes must be updated whenever an object is moved
to a different page.
• The logical identifier (LOID) approach consists of allocating a system-wide unique OID (i.e., a
surrogate) per object.
• LOIDs can be generated either by using a systemwide unique counter (called pure LOID) or by
concatenating a server identifier with a counter at each server (called pseudo-LOID).
• Since OIDs are invariant, there is no overhead due to object movement.
• This is achieved by an OID table associating each OID with the physical object address at the
expense of one table look-up per object access.
• To avoid the overhead of OIDs for small objects that are not referentially shared, both approaches
can consider the object value as their identifier.
• Object-oriented database systems tend to prefer the logical identifier approach, which better
supports dynamic environments.

4 Explain in brief about distributed object storage. 4 L2 5

• Among the many issues related to object storage, two are particularly relevant in a distributed
system: object clustering and distributed garbage collection.
• Composite and complex objects provide opportunities, for clustering data on disk such that the I/O
cost of retrieving them is reduced.
• Garbage collection is a problem that arises in object databases due to reference-based sharing.

Object Clustering:
• Object clustering refers to the grouping of objects in physical containers (i.e., disk extents)
according to common properties, such as the same value of an attribute or sub-objects of the same
object.
• Thus, fast access to clustered objects can be obtained.

There are three basic storage models for object clustering:

1. The decomposition storage model (DSM) partitions each object class into binary relations (OID,
attribute) and therefore relies on logical OID.
The advantage of DSM is simplicity.
4 P. V Ramana Murthy
LEE; B.E(Comp); M.Tech(CS); (Ph.D(CSE));
Malla Reddy Engineering College (Autonomous)
 III Year I Sem - CSE Distributed Databases - Class Notes 2024-2025

2. The normalized storage model (NSM) stores each class as a separate relation.
It can be used with logical or physical OID.
However, only logical OID allows the vertical partitioning of objects along the inheritance
relationship.
3. The direct storage model (DSM) enables multi-class clustering of complex objects based on the
composition relationship.
This model generalizes the techniques of hierarchical and network databases, and works best
with physical OID.
It can capture object access locality and is therefore potentially superior when access patterns
are well-known.
The major difficulty, however, is to clustering an object whose parent has been deleted.

Distributed Garbage Collection:

• An advantage of object-based systems is that objects can refer to other objects using object
identifier.
• As programs modify objects and remove references, a persistent object may become unreachable
from the persistent roots of the system when there is no more reference to it.
• Such an object is “garbage” and should be de-allocated by the garbage collector.
• The basic garbage collection algorithms can be categorized as reference counting or tracing-based.
• In a reference counting system, each object has an associated count of the references to it.
• Each time a program creates an additional reference that points to an object, the object’s count is
incremented.
• When an existing reference to an object is destroyed, the corresponding count is decremented.
• The memory occupied by an object can be reclaimed when the object’s count drops to zero and
become unreachable (at which time, the object is garbage).
• In reference counting, a problem can arise where two objects only refer to each other but not
referred to by anyone else;
• in this case, the two objects are basically unreachable (except from each other) but their reference
count has not dropped to zero.

5 Outline Persistent Programming languages in details. 4 L4 5

Persistent Programming languages

• Persistent Data – Data that continues to exist even after the program is terminated
Example : Relation in a database , tuples in a relation
• Persistent programming language – is a lang that is extended with constructs to handle persistent data
• Persistent Programming languages from other languages with embedded sql can be Distinguished in
two ways
1. With an embedded language ( that means the language in which sql code is written within the
normal traditional programming lang like c++ or java ) here the type system of the host lang(eg
c++) does not match with the type system of data- manipulation language (eg : sql) so
programmer converting these can cause errors.
In Persistent Programming languages the query lang is integrated with the host lang so both has
the same data types.
Objects can be created and stored in the database without explicit type or format changes
2. In embedded query languages, programmers must write explicit code to fetch and update data in
the database.
5 P. V Ramana Murthy
LEE; B.E(Comp); M.Tech(CS); (Ph.D(CSE));
Malla Reddy Engineering College (Autonomous)
 III Year I Sem - CSE Distributed Databases - Class Notes 2024-2025

In persistent programming languages, data manipulation is more seamless, requiring no explicit

code for fetching or storing persistent data.

Differentiate Horizontal Class Partitioning with respect to Distributed

6 4 L4 5
Object Database Management

• There are analogies between horizontal fragmentation of object databases and their relational
counterparts.
• It is possible to identify primary horizontal fragmentation in the object database case identically to the
relational case.
• Derived fragmentation shows some differences, however.
• In object databases, derived horizontal fragmentation can occur in a number of ways:

1. Partitioning of a class arising from the fragmentation of its subclasses.

• This occurs when a more specialized class is fragmented, so the results of this fragmentation should
be reflected in the more general case.
• Clearly, care must be taken here, because fragmentation according to one subclass may conflict with
those imposed by other subclasses.
• Because of this dependence, one starts with the fragmentation of the most specialized class and
moves up the class lattice, reflecting its effects on the superclasses.
2. The fragmentation of a complex attribute may affect the fragmentation of its containing class.
3. Fragmentation of a class based on a method invocation sequence from one class to another may need to
be reflected in the design.
This happens in the case of complex methods as defined above.

• Let fragmentation of a class with simple attributes and methods.

• In this case, primary horizontal partitioning can be performed according to a predicate defined on
attributes of the class.
• Partitioning is easy: given class C for partitioning, we create classes C1, . . . , Cn, each of which takes
the instances of C that satisfy the particular partitioning predicate.
• If these predicates are mutually exclusive, then classes C1, . . . , Cn are disjoint.

Ex. Consider the definition of the Engine class

Class Engine as Object

attributes
no_cylinder : Integer
capacity : Real
horsepower: Integer

In this simple definition of Engine, all the attributes are simple. Consider the partitioning predicates
p1: horsepower ≤ 150
p2: horsepower > 150

• In this case, Engine can be partitioned into two classes, Engine1 and Engine2, which inherit all of their
properties from the Engine class, which is redefined as an abstract class (i.e,. a class that cannot have any
objects in its shallow extent).

6 P. V Ramana Murthy
LEE; B.E(Comp); M.Tech(CS); (Ph.D(CSE));
Malla Reddy Engineering College (Autonomous)
III Year I Sem - CSE Distributed Databases - Class Notes 2024-2025

• The objects of Engine class are distributed to the Engine1 and Engine2 classes based on the value of
their horsepower attribute value.

7 Describe the term object migration with example. 4 L2 5

• One aspect of distributed systems is that objects move, from time to time, between sites. This raises
a number of issues.
• First is the unit of migration. It is possible to move the object’s state without moving its methods.
The application of methods to an object requires the invocation of remote procedures.
• This issue was discussed above under object distribution.
• Even if individual objects are units of migration, their relocation may move them away from their
type specifications and one has to decide whether types are duplicated at every site where instances
reside or the types are accessed remotely when behaviors or methods are applied to objects.
• Three alternatives can be considered for the migration of classes (types):
1. the source code is moved and recompiled at the destination,
2. the compiled version of a class is migrated just like any other object, or
3. the source code of the class definition is moved, but not its compiled operations, for which a
lazy migration strategy is used.
• Another issue is that the movements of the objects must be tracked so that they can be found in
their new locations.
• A common way of tracking objects is to leave surrogates, or proxy objects .
• These are place-holder objects left at the previous site of the object, pointing to its new location.
• Accesses to the proxy objects are directed transparently by the system to the objects themselves at
the new sites.
• The migration of objects can be accomplished based on their current state.
• Objects can be in one of four states:
1. Ready: Ready objects are not currently invoked, or have not received a message, but are
ready to be invoked to receive a message.
2. Active: Active objects are currently involved in an activity in response to an invocation or a
message.
3. Waiting: Waiting objects have invoked (or have sent a message to) another object and are
waiting for a response.
4. Suspended: Suspended objects are temporarily unavailable for invocation.

• Objects in active or waiting state are not allowed to migrate, since the activity they are currently
involved in would be broken.
• The migration involves two steps:
1. shipping the object from the source to the destination, and
2. creating a proxy at the source, replacing the original object.

• Two related issues must also be addressed here. One relates to the maintenance of the system
directory.
• As objects move, the system directory must be updated to reflect the new location.
• This may be done lazily, whenever a surrogate or proxy object redirects an invocation, rather than
eagerly, at the time of the movement.
• The second issue is that, in a highly dynamic environment where objects move frequently, the
surrogate or proxy chains may become quite long.
7 P. V Ramana Murthy
LEE; B.E(Comp); M.Tech(CS); (Ph.D(CSE));
Malla Reddy Engineering College (Autonomous)
III Year I Sem - CSE Distributed Databases - Class Notes 2024-2025

• It is useful for the system to transparently compact these chains from time to time.
• However, the result of compaction must be reflected in the directory, and it may not be possible to
accomplish that lazily.
• Another important migration issue arises with respect to the movement of composite objects.
• The shipping of a composite object may involve shipping other objects referenced by the
composite object.

8 Compare OODBMS and ORDBMS. 4 L4 5

OODBMS ORDBMS
It stands for Object Oriented Database Management It stands for Object Relational Database
System. Management System
Object-oriented databases, like Object Oriented An object-relational database is one that is based on
Programming, represent data in the form of objects both the relational & object-oriented database
and classes models data in the form of relations which contains
rows and columns
In OODBMS, relationships are via the object In ORDBMS, relationships are represented by
identifier (OID) foreign key attributes.
It handles larger and complex data than RDBMS. It handles comparatively simpler data.
In OODBMS, the data management language is IN ORDBMS there are data manipulation languages
typically incorporated into a programming language such as SQL.
such as C++, C#.
Stored data entries are described as objects. Stored data entries are described as tables.
OODBMSs support ODL/OQL. ORDBMS adds object-oriented functionalities to
SQL
Every object-oriented system has a different set of Keys, entity integrity, and referential integrity are
constraints that it can accommodate. constraints of an object-oriented database.
The efficiency of query processing is low. The efficiency of query processing is quite high.

8 P. V Ramana Murthy
LEE; B.E(Comp); M.Tech(CS); (Ph.D(CSE));
Malla Reddy Engineering College (Autonomous)