Chapter One: Object-Oriented Database Concepts

1. Overview of Object Database Concepts

1.1. Introduction to Object-Oriented Concepts and Features

The term object-oriented—abbreviated OO or O-O—has its origins in OO programming

languages, or OOPLs. Object oriented databases emerged in the mid-80’s in response to the
feeling that relational databases were inadequate for certain classes of applications. Relational
databases do not normally provide us with the ability to define our own data types. In ODB, the
data is represented and stored in the form of objects. Today, OO concepts are applied in the areas
of databases, software engineering, knowledge bases, artificial intelligence, and computer
systems in general.

Object-oriented databases aim to achieve integration of data and programs, but this is now
achieved in an adequate methodical framework, which borrows much from abstract data types.
With object database, we can define arbitrarily complex data types like their programming
language counterpart. Sets, list, and bags (multisets) and other containers are used, among other
things, to represent the result of a query that returns several objects.

An object typically has two components: state (value) and behavior (operations). It can have a
complex data structure as well as specific operations defined by the programmer. Objects in an
OOPL exist only during program execution; therefore, they are called transient objects. An OO
database can extend the existence of objects so that they are stored permanently in a database,
and hence the objects become persistent objects that exist beyond program termination and can
be retrieved later and shared by other programs.

In other words, OO databases store persistent objects permanently in secondary storage, and
allow the sharing of these objects among multiple programs and applications. This requires the
incorporation of other well-known features of database management systems, such as indexing
mechanisms to locate objects efficiently, concurrency control to allow object sharing among
concurrent programs, and recovery from failures. An OO database system will typically interface
with one or more OO programming languages to provide persistent and shared object
capabilities.

Samara University Department of Computer Science Advanced Database System Page 1

 1.2. Object Identity
One goal of an ODMS (Object Data Management System) is to maintain a direct correspondence
between real-world and database objects. So that, objects do not lose their integrity and identity
and can easily be identified and operated. Hence, an ODMS provides a unique identity to each
independent object stored in the database. This unique identity is typically implemented via a
unique, system-generated object identifier (OID). The value of an OID is not visible to the
external user, but is used internally by the system to identify each object uniquely and to create
and manage inter-object references. The OID can be assigned to program variables of the
appropriate type when needed.

The main property required of an OID is that it be immutable; that is, the OID value of a
particular object should not change. This preserves the identity of the real-world object being
represented. Hence, an ODMS must have some mechanism for generating OIDs and preserving
the immutability property. It is also desirable that each OID be used only once; that is, even if an
object is removed from the database, its OID should not be assigned to another object. These two
properties imply that the OID should not depend on any attribute values of the object, since the
value of an attribute may be changed or corrected. We can compare this with the relational
model, where each relation must have a primary key attribute whose value identifies each tuple
uniquely. In the relational model, if the value of the primary key is changed, the tuple will have a
new identity, even though it may still represent the same real-world object. Alternatively, a real-
world object may have different names for key attributes in different relations, making it difficult
to ascertain that 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).

It is inappropriate to base the OID on the physical address of the object in storage, since the
physical address can change after a physical reorganization of the database. However, some early
ODMSs have used the physical address as the OID to increase the efficiency of object retrieval.
If the physical address of the object changes, an indirect pointer can be placed at the former
address, which gives the new physical location of the object. It is more common to use long
integers as OIDs and then to use some form of hash table to map the OID value to the current
physical address of the object in storage.

Samara University Department of Computer Science Advanced Database System Page 2

 1.3 Complex Type Structures for Objects

Another feature of an ODMS (and ODBs in general) is that objects and literals may have a type
structure of arbitrary complexity in order to contain all of the necessary information that
describes the object or literal. In contrast, in traditional database systems, information about a
complex object is often scattered over many relations or records, leading to loss of direct
correspondence between a real-world object and its database representation. In ODBs, a complex
type may be constructed from other types by nesting of type constructors. The three most basic
constructors are atom, struct (or tuple), and collection.
1. Atom constructor: This includes the basic built-in data types of the object model, which
are similar to the basic types in many programming languages: integers, strings, floating
point numbers, enumerated types, Booleans, and so on. They are called single-valued or
atomic types, since each value of the type is considered an atomic (indivisible) single
value.
2. struct (or tuple) constructor: This can create standard structured types, such as the
tuples (record types) in the basic relational model. A structured type is made up of several
components, and is sometimes referred to as a compound or composite type. More
accurately, the struct constructor is not considered a type, but rather a type generator,
because many different structured types can be created. For example, two different
structured types that can be created are:
struct Name<FirstName: string, MiddleInitial: char, LastName: string>, and
struct CollegeDegree<Major: string, Degree: string, Year: date>
To create complex nested type structures in the object model, the collection type constructors are
needed. Notice that the type constructor’s atom and struct are the only ones available in the
original (basic) relational model.
3. Collection (or multivalued) type constructors: this include the set(T), list(T), bag(T),
array(T), and dictionary(K,T) type constructors. These allow part of an object or literal
value to include a collection of other objects or values when needed. These constructors
are also considered to be type generators because many different types can be created.
For example, set(string), set(integer), and set(Employee) are three different types that can
be created from the set type constructor. All the elements in a particular collection value

Samara University Department of Computer Science Advanced Database System Page 3

 must be of the same type. For example, all values in a collection of type set(string) must
be string values.
The other commonly used constructors are collectively referred to as collection types, but have
individual differences among them. The set constructor will create objects or literals that are a
set of distinct elements {i1, i2, .. in}, all of the same type. The bag constructor (sometimes
called a multi-set) is similar to a set except that the elements in a bag need not be distinct. The
list constructor will create an ordered list [i1, i2, ..., in] of OIDs or values of the same type. A
list is similar to a bag except that the elements in a list are ordered, and hence we can refer to the
first, second, or element. The array constructor creates a single-dimensional array of elements
of the same type. The main difference between array and list is that a list can have an arbitrary
number of elements whereas an array typically has a maximum size.

Finally, the dictionary constructor creates a collection of two tuples (K, V), where the value of
a key K can be used to retrieve the corresponding value V. The main characteristic of a collection
type is that its objects or values will be a collection of objects or values of the same type that may
be unordered (such as a set or a bag) or ordered (such as a list or an array).

An object definition language (ODL) that incorporates the preceding type constructors can be
used to define the object types for a particular database application. The type constructors can be
used to define the data structures for an OO database schema. Figure 1.1 shows how we may
declare EMPLOYEE and DEPARTMENT types. In Figure 1.1, the attributes that refer to other
objects—such as Dept of EMPLOYEE or Projects of DEPARTMENT—are basically OIDs
that serve as references to other objects to represent relationships among the objects. For
example, the attribute Dept of EMPLOYEE is of type DEPARTMENT, and hence is used to
refer to a specific DEPARTMENT object (the DEPARTMENT object where the employee
works). The value of such an attribute would be an OID for a specific DEPARTMENT object. A
binary relationship can be represented in one direction, or it can have an inverse reference.

The latter representation makes it easy to traverse the relationship in both directions. For
example, in Figure 1.1 the attribute Employees of DEPARTMENT has as its value a set of
references (that is, a set of OIDs) to objects of type EMPLOYEE; these are the employees who
work for the DEPARTMENT. The inverse is the reference attribute Dept of EMPLOYEE.
define type EMPLOYEE

Samara University Department of Computer Science Advanced Database System Page 4

 tuple ( Fname: string;
Minit: char;
Lname: string;
Ssn: string;
Birth_date: DATE;
Address: string;
Sex: char;
Salary: float;
Supervisor: EMPLOYEE;
Dept: DEPARTMENT;
define type DATE
tuple ( Year: integer;
Month: integer;
Day: integer; );
define type DEPARTMENT
tuple ( Dname: string;
Dnumber: integer;
Mgr: tuple ( Manager: EMPLOYEE;
Start_date: DATE; );

Locations: set(string);
Employees: set(EMPLOYEE);
Projects: set(PROJECT); );

Figure 1.1 Specifying the object types EMPLOYEE, DATE, and DEPARTMENT using type
constructors.

1.4 Encapsulation of Operations and Persistence of Objects

The concept of encapsulation is one of the main characteristics of OO languages and systems. It
is also related to the concepts of abstract data types and information hiding in programming
languages. In traditional database models and systems, this concept was not applied, since it is
customary to make the structure of database objects visible to users and external programs. In
these traditional models, a number of generic database operations are applicable to objects of all
types. For example, in the relational model, the operations for selecting, inserting, deleting, and
modifying tuples are generic and may be applied to any relation in the database. The relation and
its attributes are visible to users and to external programs that access the relation by using these
operations.
a. Encapsulation of Operations
The concepts of encapsulation is applied to database objects in ODBs by defining the behavior
of a type of object based on the operations that can be externally applied to objects of that type.
Some operations may be used to create (insert) or destroy (delete) objects; other operations may
update the object state; and others may be used to retrieve parts of the object state or to apply

Samara University Department of Computer Science Advanced Database System Page 5

some calculations. Still other operations may perform a combination of retrieval, calculation, and
update. In general, the implementation of an operation can be specified in a general-purpose
programming language that provides flexibility and power in defining the operations.

The external users of the object are only made aware of the interface of the operations, which
defines the name and arguments (parameters) of each operation. The implementation is hidden
from the external users; it includes the definition of any hidden internal data structures of the
object and the implementation of the operations that access these structures. The interface part of
an operation is sometimes called the signature, and the operation implementation is sometimes
called the method.

For database applications, the requirement that all objects be completely encapsulated is too
stringent. One way to relax this requirement is to divide the structure of an object into visible and
hidden attributes (instance variables). Visible attributes can be seen by and are directly
accessible to the database users and programmers via the query language. The hidden attributes
of an object are completely encapsulated and can be accessed only through predefined
operations. Most ODMSs employ high-level query languages for accessing visible attributes.

The term class is often used to refer to a type definition, along with the definitions of the
operations for that type. Figure 1.2 shows how the type definitions in Figure 1.1 can be extended
with operations to define classes. A number of operations are declared for each class, and the
signature (interface) of each operation is included in the class definition.
define class EMPLOYEE
type tuple ( Fname: string;
Minit: char;
Lname: string;
Ssn: string;
Birth_date: DATE;
Address: string;
Sex: char;
Salary: float;
Supervisor: EMPLOYEE;
Dept: DEPARTMENT; );
operations age: integer;
create_emp: EMPLOYEE;
destroy_emp: boolean;
end EMPLOYEE;

Samara University Department of Computer Science Advanced Database System Page 6

define class DEPARTMENT
type tuple ( Dname: string;
Dnumber: integer;
Mgr: tuple ( Manager: EMPLOYEE;
Start_date: DATE; );
Locations: set (string);
Employees: set (EMPLOYEE);

Projects set(PROJECT); );
operations no_of_emps: integer;
create_dept: DEPARTMENT;
destroy_dept: boolean;
assign_emp(e: EMPLOYEE): boolean;
(* adds an employee to the department *)
remove_emp(e: EMPLOYEE): boolean;
(* removes an employee from the department *)
end DEPARTMENT;
Figure 1.2 Adding operations to the definitions of EMPLOYEE and DEPARTMENT.
A method (implementation) for each operation must be defined elsewhere using a programming
language. Typical operations include the object constructor operation (often called new), which
is used to create a new object, and the destructor operation, which is used to destroy (delete) an
object. A number of object modifier operations can also be declared to modify the states
(values) of various attributes of an object. Additional operations can retrieve information about
the object.

An operation is typically applied to an object by using the dot notation. For example, if d is a
reference to a DEPARTMENT object, we can invoke an operation such as no_of_emps by
writing d.no_of_emps. Similarly, by writing d.destroy_dept, the object referenced by d is
destroyed (deleted). The only exception is the constructor operation, which returns a reference to
a new DEPARTMENT object. Hence, it is customary in some OO models to have a default name
for the constructor operation that is the name of the class itself, although this was not used in
Figure 1.2. The dot notation is also used to refer to attributes of an object—for example, by
writing d.Dnumber or d.Mgr_Start_date.

b. Specifying Object Persistence via Naming and Reachability

In OOPL, not all objects are meant to be stored permanently in the database. Transient objects
exist in the executing program and disappear once the program terminates. Persistent objects
are stored in the database and persist after program termination. The typical mechanisms for
making an object persistent are naming and reachability. The naming mechanism involves

Samara University Department of Computer Science Advanced Database System Page 7

giving an object a unique persistent name within a particular database. This persistent object
name can be given via a specific statement or operation in the program, as shown in Figure 1.3.
The named persistent objects are used as entry points to the database through which users and
applications can start their database access.

Obviously, it is not practical to give names to all objects in a large database that includes
thousands of objects, so most objects are made persistent by using the second mechanism, called
reachability. The reachability mechanism works by making the object reachable from some
other persistent object. An object B is said to be reachable from an object A if a sequence of
references in the database lead from object A to object B.

If we first create a named persistent object N, whose state is a set (or possibly a bag) of objects
of some class C, we can make objects of C persistent by adding them to the set, thus making
them reachable from N. Hence, N is a named object that defines a persistent collection of
objects of class C. For example, we can define a class DEPARTMENT_SET (see Figure 1.3)
whose objects are of type set(DEPARTMENT). We can create an object of type
DEPARTMENT_SET, and give it a persistent name ALL_DEPARTMENTS, as shown in Figure
1.3. Any DEPARTMENT object that is added to the set of ALL_DEPARTMENTS by using the
add_dept operation becomes persistent by virtue of its being reachable from
ALL_DEPARTMENTS. Notice the difference between traditional database models and ODBs in
this respect.

define class DEPARTMENT_SET

type set (DEPARTMENT);
operations add_dept(d: DEPARTMENT): boolean;
(* adds a department to the DEPARTMENT_SET object *)

Samara University Department of Computer Science Advanced Database System Page 8

 remove_dept(d: DEPARTMENT): boolean;
(* removes a department from the DEPARTMENT_SET object *)
create_dept_set: DEPARTMENT_SET;
destroy_dept_set: boolean;
end DEPARTMENT_SET;
...
persistent name ALL_DEPARTMENTS: DEPARTMENT_SET;
(* ALL_DEPARTMENTS is a persistent named object of type DEPARTMENT_SET *)
...
d:= create_dept;
(* create a new DEPARTMENT object in the variable d *)
...
b:= ALL_DEPARTMENTS.add_dept(d);
(* make d persistent by adding it to the persistent set ALL_DEPARTMENTS *)
Figure 11.3 Creating persistent objects by naming and reachability.
In traditional database models, such as the relational model, all objects are assumed to be
persistent. Hence, when a table such as EMPLOYEE is created in a relational database, it
represents both the type declaration for EMPLOYEE and a persistent set of all EMPLOYEE
records (tuples). In the OO approach, a class declaration of EMPLOYEE specifies only the type
and operations for a class of objects. The user must separately define a persistent object of type
set(EMPLOYEE) or bag(EMPLOYEE) whose value is the collection of references (OIDs) to all
persistent EMPLOYEE objects, if this is desired, as shown in Figure 1.3. This allows transient
and persistent objects to follow the same type and class declarations of the ODL and the OOPL.
In general, it is possible to define several persistent collections for the same class definition, if
desired.

1.5 Type Hierarchies and Inheritance

Another main characteristic of ODBs is that they allow type hierarchies and inheritance. We use
a simple OO model in this section a model in which attributes and operations are treated
uniformly—since both attributes and operations can be inherited.

a. Simplified Model for Inheritance

A type is defined by assigning it a type name, and then defining a number of attributes (instance
variables) and operations (methods) for the type. In the simplified model we use in this section,
the attributes and operations are together called functions, since attributes resemble functions
with zero arguments. A function name can be used to refer to the value of an attribute or to refer
to the resulting value of an operation (method).We use the term function to refer to both

Samara University Department of Computer Science Advanced Database System Page 9

attributes and operations, since they are treated similarly in a basic introduction to inheritance. A
type in its simplest form has a type name and a list of visible (public) functions. When
specifying a type in this section, we use the following format, which does not specify arguments
of functions, to simplify the discussion:
TYPE_NAME: function, function, ..., function
For example, a type that describes characteristics of a PERSON may be defined as follows:
PERSON: Name, Address, Birth_date, Age, Ssn
In the PERSON type, the Name, Address, Ssn, and Birth_date functions can be implemented as
stored attributes, whereas the Age function can be implemented as an operation that calculates
the Age from the value of the Birth_date attribute and the current date.

The concept of subtype is useful when the designer or user must create a new type that is similar
but not identical to an already defined type. The subtype then inherits all the functions of the
predefined type, which is referred to as the supertype. For example, suppose that we want to
define two new types EMPLOYEE and STUDENT as follows:
EMPLOYEE: Name, Address, Birth_date, Age, Ssn, Salary, Hire_date, Seniority
STUDENT: Name, Address, Birth_date, Age, Ssn, Major, Gpa

Since both STUDENT and EMPLOYEE include all the functions defined for PERSON plus
some additional functions of their own, we can declare them to be subtypes of PERSON. Each
will inherit the previously defined functions of PERSON—namely, Name, Address, Birth_date,
Age, and Ssn. For STUDENT, it is only necessary to define the new (local) functions Major and
Gpa, which are not inherited. Presumably, Major can be defined as a stored attribute, whereas
Gpa may be implemented as an operation that calculates the student’s grade point average by
accessing the Grade values that are internally stored (hidden) within each STUDENT object as
hidden attributes. For EMPLOYEE, the Salary and Hire_date functions may be stored attributes,
whereas Seniority may be an operation that calculates Seniority from the value of Hire_date.
Therefore, we can declare EMPLOYEE and STUDENT as follows:

EMPLOYEE subtype-of PERSON: Salary, Hire_date, Seniority

STUDENT subtype-of PERSON: Major, Gpa

Samara University Department of Computer Science Advanced Database System Page 10

In general, a subtype includes all of the functions that are defined for its super-type plus some
additional functions that are specific only to the subtype. Hence, it is possible to generate a type
hierarchy to show the super-type/subtype relationships among all the types declared in the
system.
b. Constraints on Extents Corresponding to a Type Hierarchy
In most ODBs, an extent is defined to store the collection of persistent objects for each type or
subtype. In this case, the constraint is that every object in an extent that corresponds to a subtype
must also be a member of the extent that corresponds to its super-type. Some OO database
systems have a predefined system type (called the ROOT class or the OBJECT class) whose
extent contains all the objects in the system. Classification then proceeds by assigning objects
into additional subtypes that are meaningful to the application, creating a type hierarchy (or
class hierarchy) for the system. All extents for system- and user-defined classes are subsets of
the extent co-responding to the class OBJECT, directly or indirectly.

An extent is a named persistent object whose value is a persistent collection that holds a
collection of objects of the same type that are stored permanently in the database. The objects
can be accessed and shared by multiple programs. It is also possible to create a transient
collection, which exists temporarily during the execution of a program but is not kept when the
program terminates. For example, a transient collection may be created in a program to hold the
result of a query that selects some objects from a persistent collection and copies those objects
into the transient collection. The program can then manipulate the objects in the transient
collection, and once the program terminates, the transient collection ceases to exist. In general,
numerous collections—transient or persistent—may contain objects of the same type. The
inheritance model discussed in this section is very simple.

Samara University Department of Computer Science Advanced Database System Page 11

 1.6 Summary of Object Database Concepts
To conclude this section, we give a summary of the main concepts used in ODBs and object-
relational systems:
 Object identity. Objects have unique identities that are independent of their attribute values and
are generated by the ODMS.
 Type constructors. Complex object structures can be constructed by applying in a nested manner
a set of basic constructors, such as tuple, set, list, array, and bag.
 Encapsulation of operations. Both the object structure and the operations that can be applied to
individual objects are included in the type definitions.
 Programming language compatibility. Both persistent and transient objects are handled
seamlessly. Objects are made persistent by being reachable from a persistent collection (extent)
or by explicit naming.
 Type hierarchies and inheritance. Object types can be specified by using a type hierarchy,
which allows the inheritance of both attributes and methods (operations) of previously defined
types. Multiple inheritances are allowed in some models.
 Extents. All persistent objects of a particular type can be stored in an extent. Extents
corresponding to a type hierarchy have set/subset constraints enforced on their collections of
persistent objects.

Samara University Department of Computer Science Advanced Database System Page 12