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
 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.
12
 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

14
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.

17
 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