Chapter 11

Object and
Object-
Relational
Databases

Copyright © 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley

 Chapter 11 Outline
▪ Overview of Object Database Concepts
▪ Object-Relational Features:
Object Database Extensions to SQL
▪ The ODMG Object Model and the Object
Definition Language ODL
▪ Object Database Conceptual Design
▪ The Object Query Language OQL
▪ Overview of the C++ Language Binding in
the ODMG Standard
Copyright © 2011 Ramez Elmasri and Shamkant Navathe
 Object and Object-Relational
Databases
▪ Object databases (ODB)
▪ Object data management systems (ODMS)
▪ Meet some of the needs of more complex
applications
▪ Specify:
• Structure of complex objects
• Operations that can be applied to these objects

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 Overview of Object Database
Concepts
▪ Introduction to object-oriented concepts
and features
▪ Origins in OO programming languages
▪ Object has two components:
• State (value) and behavior (operations)
▪ Instance variables
• Hold values that define internal state of object
▪ Operation is defined in two parts:
• Signature or interface and implementation

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 Overview of Object Database
Concepts (cont’d.)
▪ Inheritance
• Permits specification of new types or classes that
inherit much of their structure and/or operations
from previously defined types or classes
▪ Operator overloading
• Operation’s ability to be applied to different types of
objects
• Operation name may refer to several distinct
implementations

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 Object Identity, and Objects
versus Literals
▪ Unique identity
▪ Implemented via a unique, system-generated
object identifier (OID)
▪ Immutable- that is, the OID value of a particular
object should not change.
▪ Most OO database systems allow for the
representation of both objects and literals
(or values)

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 Complex Type Structures for
Objects and Literals
▪ Structure of arbitrary complexity
▪ Contain all necessary information that describes object
or literal
▪ Nesting type constructors
▪ Construct complex type from other types
▪ Most basic constructors:
▪ Atom- This includes the basic built-in data types of the object
model - integers, strings, floating point numbers, enumerated types,
Booleans, and so on. They are called single-valued or atomic types
▪ Struct (or tuple) - record typesstruct Name<FirstName: string,
MiddleInitial: char, LastName: string>, struct CollegeDegree<Major:
string, Degree: string, Year: date>
▪ Collection -multivalued
Copyright © 2011 Ramez Elmasri and Shamkant Navathe
 Complex Type Structures for
Objects and Literals (cont’d.)
▪ Collection types:
▪ Set - will create objects or literals that are a set of distinct elements
{i1 , i2 , ..., in}, all of the same type.
▪ Bag- is similar to a set except that the elements in a bag need not
be distinct.
▪ List - will create an ordered list [i1, i2, ..., in] of OIDs or values of the
same type.
▪ Array- creates a single-dimensional array of elements of the same
type. array typically has a maximum size.
▪ Dictionary - 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.
▪ Object definition language (ODL) Used to define object
types for a particular database application
Copyright © 2011 Ramez Elmasri and Shamkant Navathe
Copyright © 2011 Ramez Elmasri and Shamkant Navathe
Encapsulation of Operations and
Persistence of Objects
▪ Encapsulation
▪ Related to abstract data types and information hiding in
programming languages
▪ Define behavior of a type of object based on
operations that can be externally applied
▪ External users only aware of interface of the
operations. The interface part of an operation is sometimes
called the signature, and the operation implementation is
sometimes called the method
▪ objects be completely encapsulated is too stringent.
One way to relax this requirement is
• Divide structure of object into visible and hidden attributes

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 Object Behavior/Operations
▪ See figure 11.2

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 Encapsulation of Operations
▪ Object constructor
▪ Used to create a new object
▪ Destructor operation
▪ Used to destroy (delete) an object
▪ Modifier operations
▪ Modify the states (values) of various attributes
of an object
▪ Retrieve information about the object
▪ Dot notation used to apply operations to
object
Copyright © 2011 Ramez Elmasri and Shamkant Navathe
 Persistence of Objects
▪ Transient objects
▪ Exist in executing program
▪ Disappear once program terminates
▪ Persistent objects
▪ Stored in database and persist after program
termination
▪ The typical mechanisms for making an object
persistent are
• Naming mechanism - 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.
• Reachability- The reachability mechanism works by making the
object reachable from some other persistent object.

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

▪ X`

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 Type Hierarchies and Inheritance
▪ Inheritance
▪ Definition of new types based on other predefined
types
▪ Leads to type (or class) hierarchy
▪ Type: type name and list of visible (public)
functions
▪ Format:
• TYPE_NAME: function, function, ..., function
• PERSON: Name, Address, Birth_date, Age, Ssn
In the PERSON type, the Name, Address, Ssn, and
Birth_date functions can be imple mented as
stored attributes, whereas the Age function can
be implemented as an operation
Copyright © 2011 Ramez Elmasri and Shamkant Navathe
Type Hierarchies and Inheritance
(cont’d.)
▪ Subtype
▪ Useful when creating a new type that is similar
but not identical to an already defined type
▪ Example:
• EMPLOYEE: Name, Address, Birth_date, Age, Ssn, Salary, Hire_date,
Seniority
• STUDENT: Name, Address, Birth_date, Age, Ssn, Major, Gpa

• EMPLOYEE subtype-of PERSON: Salary,

Hire_date, Seniority
• STUDENT subtype-of PERSON: Major, Gpa

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

Type Hierarchies and Inheritance
(cont’d.)
▪ Extent
▪ Store collection of persistent objects for each
type or subtype
▪ Extents are subsets of the extent of class
OBJECT
▪ Persistent collection
▪ Stored permanently in the database
▪ Transient collection
▪ Exists temporarily during the execution of a
program
Copyright © 2011 Ramez Elmasri and Shamkant Navathe
Other Object-Oriented Concepts
▪ Polymorphism of operations
▪ Also known as operator overloading
▪ Allows same operator name or symbol to be
bound to two or more different implementations
▪ Depending on type of objects to which operator
is applied
▪ Multiple inheritance
▪ Subtype inherits functions (attributes and
methods) of more than one supertype

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

Other Object-Oriented Concepts
(cont’d.)
▪ Selective inheritance
▪ Subtype inherits only some of the functions of
a supertype

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 Summary of Object Database
Concepts
▪ Object identity
▪ Type constructor
▪ Encapsulation of operations
▪ Programming language compatibility
▪ Type hierarchies and inheritance
▪ Extents
▪ Polymorphism and operator overloading

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 Object-Relational Features:
Object Database Extensions to
▪ Type constructors
SQL
▪ Specify complex objects (row type, array type, set, list, and bag
constructors)
▪ Mechanism for specifying object identity - through the use of
reference type is included
▪ Encapsulation of operations
▪ Provided through user-defined types (UDTs) – abstract datatype
▪ Inheritance mechanisms
▪ Provided using keyword UNDER

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 User-Defined Types and
Complex Structures for Objects
▪ UDT syntax:
▪ CREATE TYPE TYPE_NAME AS
(<component declarations>);
▪ ROW TYPE
▪ Directly create a structured attribute using the
keyword ROW
phone_no ROW (
area_code char (3),
prefix_no char (3),
number char (4),
),
Copyright © 2011 Ramez Elmasri and Shamkant Navathe
 Only if there are no operations

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

Copyright © 2011 Ramez Elmasri and Shamkant Navathe
Copyright © 2011 Ramez Elmasri and Shamkant Navathe
 User-Defined Types and
Complex Structures for Objects
(cont’d.)
▪ Array type
▪ Reference elements using [ ]
▪ CARDINALITY function
▪ Return the current number of elements in an array (or
any other collection type). For example,
▪ PHONES[CARDINALITY (PHONES)] refers to the last
element in the array.
▪ PHONES[1] refers to the first location value in a
PHONES attribute

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 Object Identifiers Using Reference
Types
▪ Reference type
▪ Create unique system-generated object identifiers
▪ Examples:
• REF IS SYSTEM GENERATED- indicates that whenever a
new PERSON_TYPE object is created, the system will
assign it a unique system-generated identifier. It
is also possible not to have a system-generated
object identifier and use the traditional keys of
the basic relational model if desired.
• REF IS <OID_ATTRIBUTE> <VALUE_GENERATION_METHOD> ;
• Generation methods: SYSTEM GENERATED or DERIVED
In the former case, the system will automatically generate a unique
identifier for each tuple. In the latter case, the traditional
method of using the user-provided primary key value to identify
tuples is applied.

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 Creating Tables Based on the
UDTs
▪ INSTANTIABLE
▪ Specify that UDT is instantiable
▪ Causes one or more tables to be created -11.4(d), where we
create a table PERSON based on the PERSON_TYPE UDT.
▪ Notice that the UDTs in Figure 11.4(a) are noninstantiable
and hence can only be used as
▪ types for attributes, but not as a basis for table creation.
▪ In Figure 11.4(b), the attribute PERSON_ID will hold the
system-generated object identifier whenever a new
PERSON record (object) is created and inserted in the
table.

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 Only if there are no operations

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 Encapsulation of Operations
▪ User-defined type
▪ Specify methods (or operations) in addition to
the attributes
▪ Format:
CREATE TYPE <TYPE-NAME> (
<LIST OF COMPONENT ATTRIBUTES AND THEIR TYPES>
<DECLARATION OF FUNCTIONS (METHODS)>
);
For example, in Figure 11.4(b), we declared a method Age() that
calculates the age of an individual object of type PERSON_TYPE

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 Encapsulation of Operations
(cont’d.)
▪ Constructor function TYPE_T( )
▪ Returns a new object of that type and every attribute is initialized
to its default value.
▪ Observer function A implicitly created for each attribute A
▪ A(X) or X.A return the of attribute A
▪ A Mutator function for updating an attribute sets the value
of the attribute to a new value.
▪ User defined functions can internal (SQL) or external
▪ External functions written in a host language

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

In general, a UDT can have a number of user-defined functions
associated with it.
The syntax is
INSTANCE METHOD <NAME> (<ARGUMENT_LIST>) RETURNS
<RETURN_TYPE>;

Two types of functions can be defined: internal SQL and external.

Internal functions are written in the extended PSM ( Persistence
Stored Module) language of SQL . External functions are written in a
host language, with only their signature (interface) appearing in the
UDT definition. An external function definition can be declared as
follows:
DECLARE EXTERNAL <FUNCTION_NAME> <SIGNATURE>
LANGUAGE <LANGUAGE_NAME>;
Attributes and functions in UDTs are divided into three categories:
■ PUBLIC (visible at the UDT interface)
■ PRIVATE (not visible at the UDT interface)
■ PROTECTED (visible only to subtypes)
It is also possible to define virtual attributes as part of UDTs, which
are computed and updated using functions.
Copyright © 2011 Ramez Elmasri and Shamkant Navathe
 Specifying Inheritance and
Overloading of Functions
▪ Inheritance rules:
▪ All attributes inherited
▪ Order of supertypes in UNDER clause
determines inheritance hierarchy
▪ Instance of a subtype can be used in every
context in which a supertype instance used
▪ Subtype can redefine any function defined in
supertype
▪ NOT FINAL: subtypes are allowed to be
defined
Copyright © 2011 Ramez Elmasri and Shamkant Navathe
 Specifying Inheritance and
Overloading of Functions
(cont’d.)
▪ When a function is called, best match selected
based on types of all arguments
▪ For dynamic linking, runtime types of
parameters is considered

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 Specifying Relationships via Reference
▪ Component attribute of one tuple may be a reference to a
tuple of another table
▪ Specified using keyword REF
▪ Keyword SCOPE: Specify name of table whose tuples
referenced (e.g, FK)
▪ Dot notation: Build path expressions that refer to the
component attributes of tuples and row types.
▪ –> the symbol - Used for dereferencing
the query below retrieves employees working in the company named
‘Microsoft’ by querying the EMPLOYMENT table:
SELECT E.Employee -> Name
FROM EMPLOYMENT AS E
WHERE E.Company -> Name = ‘Microsoft’;

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 The ODMG Object Model and the Object
Definition Language ODL
▪ ODMG object model
▪ Data model for object definition language (ODL) and object query
language (OQL)
▪ Objects and Literals
▪ Basic building blocks of the object model
▪ Object has five aspects:
▪ Identifier, name, lifetime, structure ( atomic/collection), and creation ( new)
▪ Literal
▪ Value that does not have an object identifier -Atomic literals- basic data types of
the object model include long, short, and unsigned integer numbers.
▪ Structured literals-include Date, Interval, Time, and Timestamp
▪ Collection literals - dictionary<K, V>, type generators set<T>, bag<T>, list<T>,
and array<T>,

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 The ODMG Object Model and
the
▪ Behavior refers ODL
to operations
(cont’d.)
▪ State refers to properties (attributes and relationships).
▪ Interface
▪ Specifies only behavior of an object type
▪ Typically noninstantiable -(that is, no objects are created
corresponding to an interface). Although an interface may
have state properties (attributes and relationships) as part of
its specifications, these cannot be inherited from the
interface.
▪ Class
▪ Specifies both state (attributes) and behavior (operations) of an
object type
▪ Instantiable

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

Figure 11.5(a); these include operations such as copy (creates a
new copy of the object), delete (deletes the object), and same_as
(compares the object’s identity to another object). For example,
given an object O, to compare it with another object P, we write
O.same_as(P) , The result returned by this operation is Boolean
and would be true if the identity of P is the same as that of O, and
false otherwise. Similarly, to create a copy P of object O, we write
P = O.copy() ., An alternative to the dot notation is the arrow
notation:
O–>same_as(P) or O–>copy().

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 Inheritance in the Object Model of ODMG
▪ Behavior inheritance
▪ Also known as IS-A or interface inheritance
▪ Specified by the colon (:) notation
▪ EXTENDS inheritance
▪ Specified by keyword extends
▪ Inherit both state and behavior strictly among
classes
▪ Multiple inheritance via extends not permitted
multiple inheritance is allowed for behavior inheritance via the
colon (:) notation. Hence, an interface may inherit behavior from
several other interfaces

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 Built-in Interfaces and Classes in the Object Model
▪ Collection objects
▪ Inherit the basic Collection interface
▪ I = O.create_iterator()
▪ Creates an iterator object for the collection ,
▪ operation I = O.create_iterator() creates an iterator
object I for the collection object O, which can iterate
over each element in the collection. The I.reset()
operation sets the iterator at the first element in a
collection and I.next_position() sets the iterator to the
next element. The I.get_element() retrieves the current
element, which is the element at which the iterator is
currently positioned
▪ Collection objects further specialized into:
▪ set,
Copyright list,
© 2011 bag,
Ramez Elmasri array,
and Shamkant Navathe and dictionary
Built-in Interfaces and Classes in
the Object Model (cont’d.)

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 Atomic (User-Defined) Objects
▪ Specified using keyword class in ODL
▪ Attribute
▪ Property; describes some aspect of an object
▪ Relationship
▪ Two objects in the database are related
▪ Keyword inverse
• Single conceptual relationship in inverse directions
▪ Operation signature:
▪ Operation name, argument types, return value
Copyright © 2011 Ramez Elmasri and Shamkant Navathe
 Extents, Keys, and Factory
Objects
▪ Extent
▪ Contains all persistent objects of class
▪ Key
▪ One or more properties whose values are
unique for each object in extent
▪ Factory object
▪ Used to generate or create individual objects
via its operations

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

The Object Definition Language
ODL
▪ Support semantic constructs of ODMG
object model
▪ Independent of any particular programming
language

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

Copyright © 2011 Ramez Elmasri and Shamkant Navathe
 Object Database Conceptual
Design
▪ Differences between conceptual design of
ODB and RDB, handling of:
▪ Relationships
▪ Inheritance
▪ Philosophical difference between relational
model and object model of data
▪ In terms of behavioral specification

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 Mapping an EER Schema to an
ODB Schema
▪ Create ODL class for each EER entity type
▪ Add relationship properties for each binary
relationship
▪ Include appropriate operations for each
class
▪ ODL class that corresponds to a subclass
in the EER schema
▪ Inherits type and methods of its superclass in
ODL schema
Copyright © 2011 Ramez Elmasri and Shamkant Navathe
 Mapping an EER Schema to an
ODB Schema (cont’d.)
▪ Weak entity types
▪ Mapped same as regular entity types
▪ Categories (union types)
▪ Difficult to map to ODL
▪ An n-ary relationship with degree n > 2
▪ Map into a separate class, with appropriate
references to each participating class

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 The Object Query Language
OQL
▪ Query language proposed for ODMG object
model
▪ Simple OQL queries, database entry points,
and iterator variables
▪ Syntax: select ... from ... where ... structure
▪ Entry point: named persistent object
▪ Iterator variable: define whenever a collection
is referenced in an OQL query

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 Query Results and Path
Expressions
▪ Result of a query
▪ Any type that can be expressed in ODMG
object model
▪ OQL orthogonal with respect to specifying
path expressions
▪ Attributes, relationships, and operation names
(methods) can be used interchangeably within
the path expressions

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 Other Features of OQL
▪ Named query
▪ Specify identifier of named query
▪ OQL query will return collection as its result
▪ If user requires that a query only return a single
element use element operator
▪ Aggregate operators
▪ Membership and quantification over a
collection

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 Other Features of OQL (cont’d.)
▪ Special operations for ordered collections
▪ Group by clause in OQL
▪ Similar to the corresponding clause in SQL
▪ Provides explicit reference to the collection of
objects within each group or partition
▪ Having clause
▪ Used to filter partitioned sets

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 Overview of the C++ Language
Binding in the ODMG Standard
▪ Specifies how ODL constructs are mapped
to C++ constructs
▪ Uses prefix d_ for class declarations that
deal with database concepts
▪ Template classes
▪ Specified in library binding
▪ Overloads operation new so that it can be used
to create either persistent or transient objects

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 Summary
▪ Overview of concepts utilized in object
databases
▪ Object identity and identifiers; encapsulation of
operations; inheritance; complex structure of
objects through nesting of type constructors;
and how objects are made persistent
▪ Description of the ODMG object model and
object query language (OQL)
▪ Overview of the C++ language binding

Copyright © 2011 Ramez Elmasri and Shamkant Navathe