Chapter 1

Concepts for
Object Oriented Databases

1
Chapter Outline

1. Overview of O-O Concepts

2. O-O Identity, Object Structure and Type Constructors

3. Encapsulation of Operations, Methods and Persistence

4. Type and Class Hierarchies and Inheritance

2
Introduction
• Traditional Data Models:

– Hierarchical (1960)

– Network (since mid-60’s)

– Entity-relationship Model

– Relational (since 1970 and commercially since 1982)

• Object Oriented (OO) Data Models since mid-90’s

• Reasons for creation of Object Oriented Databases

– Need for more complex applications

– Need for additional data modeling features

– Increased use of object-oriented programming languages

1.1 Overview of Object-Oriented Concepts(1)
• Main Claim:
– OO databases try 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 upon
• Object: A uniquely identifiable entity that contains both the attributes that describe the
state of a ‘real world’ object and the actions that are associated with it. (Simula 1960s)
• Object:
– Two components:
• state (value) and behavior (operations)
– Similar to program variable in programming language, except that it will typically
have a complex data structure as well as specific operations defined by the
programmer
Overview of Object-Oriented Concepts (2)
• In OO databases, objects may have an object structure of arbitrary
complexity in order to contain all of the necessary information that describes
the object.

• 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.
Overview of Object-Oriented Concepts (3)
• The internal structure of an object in OOPLs includes the specification of
instance variables, which hold the values that define the internal state of
the object.

• An instance variable is similar to the concept of an attribute, except that

instance variables may be encapsulated within the object and thus are not
necessarily visible to external users
Overview of Object-Oriented Concepts (4)
• Some OO models insist that all operations a user can apply to an object must
be predefined. This forces a complete encapsulation of objects.

• To encourage encapsulation, an operation is defined in two parts:

– signature or interface of the operation, specifies the operation name and

arguments (or parameters).

– method or body, specifies the implementation of the operation.

Overview of Object-Oriented Concepts (5)
• Operations can be invoked by passing a message to an object, which
includes the operation name and the parameters.

– The object then executes the method for that operation.

• This encapsulation permits

– modification of the internal structure of an object, as well as the

implementation of its operations, without the need to disturb the
external programs that invoke these operations
9
Overview of Object-Oriented Concepts (6)
• Some OO systems provide capabilities for dealing with multiple versions of
the same object (a feature that is essential in design and engineering
applications).

– For example, an old version of an object that represents a tested and

verified design should be retained until the new version is tested and
verified:

– very crucial for designs in manufacturing process control, architecture ,

software systems …..
Overview of Object-Oriented Concepts (7)
• Operator polymorphism:
– This refers to an operation’s ability to be applied to different types of
objects; in such a situation, an operation name may refer to several
distinct implementations, depending on the type of objects it is applied to.

• This feature is also called operator overloading

1.2 Object Identity, Object Structure, and Type Constructors (1)

• Unique Identity:

– An OO database system 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, or OID

• The main property required of an OID is that it should be immutable

– Specifically, the OID value of a particular object should not change.

– This preserves the identity of the real-world object being represented.

1.2 Object Identity, Object Structure, and Type Constructors (2)

• the object identifier, which does not change and is not reused when the
object is deleted.

• an object may also be given one or more names that are meaningful to the
user, provided each name identifies a single object within a database.

• Object names are intended to act as ‘root’ objects that provide entry points
into the database.

13
Object Identity, Object Structure, and Type Constructors (3)
• Type Constructors:
– In OO databases, the state (current value) of a complex object may be
constructed from other objects (or other values) by using certain type
constructors.
• The three most basic constructors are atom, tuple, and set (The minimal set of
constructors that the system should have ).
• Other commonly used constructors include list, bag, and array.
• The atom constructor is used to represent all basic atomic values, such as integers,
real numbers, character strings, Booleans, and any other basic data types that the
system supports directly.
Object Identity, Object Structure, and Type Constructors (4)
• The atom constructor is used to represent all basic atomic values, such as
integers

• Sets are critical because they are a natural way of representing collections
from the real world.

• Tuples are critical because they are a natural way of representing properties
of an entity.

• Lists or arrays are important because they capture order

15
Object Identity, Object Structure, and Type Constructors (5)
1.3 Encapsulation of Operations, Methods, and Persistence (1)

• Encapsulation
– One of the main characteristics of OO languages and systems

– Related to the concepts of abstract data types and information hiding in

programming languages

• An Abstract Data Type (ADT) is an abstract concept defined by axioms which

represent some data and operations on that data.
1.3 Encapsulation of Operations, Methods, and Persistence (2)

• The concept of encapsulation means that an object contains both a

data structure and the set of operations that can be used to
manipulate it.

• The concept of information hiding means that the external aspects

of an object are separated from its internal details, which are
hidden from the outside world.

18
Encapsulation of Operations, Methods, and Persistence (3)
• Specifying Object Behavior via Class Operations (methods):

– The main idea is to define the behavior of a type of object based on the
operations that can be externally applied to objects of that type.

– 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.
Encapsulation of Operations, Methods, and Persistence (4)
• Specifying Object Behavior via Class Operations (contd.):

– For database applications, the requirement that all objects be completely

encapsulated is too stringent.

– One way of relaxing this requirement is to divide the structure of an

object into visible and hidden attributes (instance variables).
Encapsulation of Operations, Methods, and Persistence (6)
• Specifying Object Persistence via Naming and Reachability:

– Naming Mechanism:

• Assign an object a unique persistent name through which it can be

retrieved by this and other programs.

– Reachability Mechanism:

• Make the object reachable from some persistent object.

• An object B is said to be reachable from an object A if a sequence of

references in the object graph lead from object A to object B.
1.4 Type and Class Hierarchies and Inheritance (1)
• Type (class) Hierarchy

– A type in its simplest form can be defined by giving it a type name and then
listing the names of its 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

– Example:

• PERSON: Name, Address, Birthdate, Age, SSN

Type and Class Hierarchies and Inheritance (2)

• Subtype:

– When the designer or user must create a new type that is similar but not
identical to an already defined type

• Supertype:

– It inherits all the functions of the subtype

Type and Class Hierarchies and Inheritance (3)

Example (1):

– PERSON: Name, Address, Birthdate, Age, SSN

– EMPLOYEE: Name, Address, Birthdate, Age, SSN, Salary, HireDate,

Seniority

– STUDENT: Name, Address, Birthdate, Age, SSN, Major, GPA

OR:

– EMPLOYEE subtype-of PERSON: Salary, HireDate, Seniority

– STUDENT subtype-of PERSON: Major, GPA

Type and Class Hierarchies and Inheritance (4)
Example (2):

• Consider a type that describes objects in plane geometry, which may be defined as
follows:
– GEOMETRY_OBJECT: Shape, Area, ReferencePoint

• Now suppose that we want to define a number of subtypes for the GEOMETRY_OBJECT
type, as follows:
– RECTANGLE subtype-of GEOMETRY_OBJECT: Width, Height

– TRIANGLE subtype-of GEOMETRY_OBJECT: Side1, Side2, Angle

– CIRCLE subtype-of GEOMETRY_OBJECT: Radius