Chapter 8: Object-Oriented Databases New Database Applications

'
Chapter 8: Object-Oriented Databases
$
• New Database Applications
• The Object-Oriented Data Model
• Object-Oriented Languages
• Persistent Programming Languages
• Persistent C++ Systems
&
'
Database Systems Concepts
8.1
c
Silberschatz, Korth and Sudarshan 1997
New Database Applications
%
$
• Data models designed for data-processing-style applications
are not adequate for new technologies such as computer-aided
design, computer-aided software engineering, multimedia and
image databases, and document/hypertext databases.
• These new applications requirement the database system to
handle features such as:
– complex data types
– data encapsulation and abstract data structures
&
– novel methods for indexing and querying
Database Systems Concepts
8.2
c
Silberschatz, Korth and Sudarshan 1997
%
'
Object-Oriented Data Model
$
• Loosely speaking, an object corresponds to an entity in the E-R
model.
• The object-oriented paradigm is based on encapsulating code
and data related to an object into a single unit.
• The object-oriented data model is a logical model (like the E-R
model).
• Adaptation of the object-oriented programming paradigm (e.g.,
Smalltalk, C++) to database systems.
&
'
Database Systems Concepts
8.3
c
Silberschatz, Korth and Sudarshan 1997
Object Structure
%
$
• An object has associated with it:
– A set of variables that contain the data for the object. The
value of each variable is itself an object.
– A set of messages to which the object responds; each
message may have zero, one, or more parameters.
– A set of methods, each of which is a body of code to
implement a message; a method returns a value as the
response to the message
• The physical representation of data is visible only to the
implementor of the object
&
• Messages and responses provide the only external interface to
an object.
Database Systems Concepts
8.4
c
Silberschatz, Korth and Sudarshan 1997
%
'
Messages and Methods
$
• The term message does not necessarily imply physical
message passing. Messages can be implemented as
procedure invocations.
• Methods are programs written in a general-purpose language
with the following features
– only variables in the object itself may be referenced directly
– data in other objects are referenced only by sending
messages
• Strictly speaking, every attribute of an entity must be
represented by a variable and two methods, e.g., the attribute
address is represented by a variable address and two
messages get-address and set-address.
&
'
– For convenience, many object-oriented data models permit
direct access to variables of other objects
Database Systems Concepts
8.5
c
Silberschatz, Korth and Sudarshan 1997
Object Classes
%
$
• Similar objects are grouped into a class; each such object is
called an instance of its class
• All objects in a class have the same
– variable types
– message interface
– methods
They may differ in the values assigned to variables
&
• Example: Group objects for people into a person class
• Classes are analogous to entity sets in the E-R model
Database Systems Concepts
8.6
c
Silberschatz, Korth and Sudarshan 1997
%
'
&
'
Class Definition Example
class employee {
/* Variables */
string
name;
string
address ;
date
start-date;
int
salary ;
/* Messages */
int
annual-salary ();
string
get-name();
string
get-address ();
int
set-address (string new-address );
int
employment-length();
};
• For strict encapsulation, methods to read and set other
variables are also needed
• employment-length is an example of a derived attribute
Database Systems Concepts
8.7
c
Silberschatz, Korth and Sudarshan 1997
Inheritance
$
%
$
• E.g., class of bank customers similar to class of bank
employees: both share some variables and messages, e.g.,
name and address But there are variables and messages
specific to each class e.g., salary for employees and and
credit-rating for customers
• Every employee is a person; thus employee is a specialization
of person
• Similarly, customer is a specialization of person.
• Create classes person, employee and customer
&
– variables/messages applicable to all persons associated
with class person.
– variables/messages specific to employees associated with
class employee; similarly for customer
Database Systems Concepts
8.8
c
Silberschatz, Korth and Sudarshan 1997
%
'
$
Inheritance (Cont.)
• Place classes into a specialization/IS-A hierarchy
– variables/messages belonging to class person are inherited
by class employee as well as customer
• Result is a class hierarchy
person
customer
employee
&
'
officer
teller
secretary
Note analogy with ISA hierarchy in the E-R model
Database Systems Concepts
&
Database Systems Concepts
8.9
c
Silberschatz, Korth and Sudarshan 1997
Class Hierarchy Definition
class person {
string
name;
string
address ;
};
class customer isa person {
int
credit-rating ;
};
class employee isa person {
date
start-date;
int
salary ;
};
class officer isa employee {
int
office-number ;
int
expense-account-number ;
};
..
.
8.10
c
Silberschatz, Korth and Sudarshan 1997
%
$
%
'
Class Hierarchy Example (Cont.)
$
• Full variable list for objects in the class officer:
– office-number, expense-account-number: defined locally
– start-date, salary: inherited from employee
– name, address: inherited from person
• Methods inherited similar to variables.
• Substitutability — any method of a class, say person, can be
invoked equally well with any object belonging to any subclass,
such as subclass officer of person.
&
'
• class extent: set of all objects in the class. Two options:
1. Class extent of employee includes all officer, teller and
secretary objects
2. Class extent of employee includes only employee objects
that are not in a subclass such as officer, teller or secretary
Database Systems Concepts
c
Silberschatz, Korth and Sudarshan 1997
8.11
Example of Multiple Inheritance
%
$
Class DAG for banking example.
person
customer
employee
full-time
officer
&
part-time
full-time-teller
Database Systems Concepts
teller
secretary
part-time-teller
8.12
full-time-secretary
part-time-secretary
c
Silberschatz, Korth and Sudarshan 1997
%
'
$
Multiple Inheritance
• The class/subclass relationship is represented by a directed
acyclic graph (DAG) — a class may have more than one
superclass.
• A class inherits variables and methods from all its
superclasses.
• There is potential for ambiguity. E.g., variable with the same
name inherited from two superclasses. Different solutions such
as flag and error, rename variables, or choose one.
• Can use multiple inheritance to model “roles” of an object.
– A person can play the roles of student, a teacher or
footballPlayer, or any combination of the three (e.g., student
teaching assistants who also play football).
&
'
– Create subclasses such as student-teacher and
student-teacher-footballPlayer that inherit from multiple
classes.
Database Systems Concepts
8.13
c
Silberschatz, Korth and Sudarshan 1997
Object Identity
%
$
• An object retains its identity even if some or all of the values of
variables or definitions of methods change over time.
• Object identity is a stronger notion of identity than in
programming languages or data models not based on object
orientation.
– Value – data value; used in relational systems.
– Name – supplied by user; used for variables in procedures.
– Built-in – identity built into data model or programming
language.
∗ no user-supplied identifier is required.
∗ form of identity used in object-oriented systems.
&
Database Systems Concepts
8.14
c
Silberschatz, Korth and Sudarshan 1997
%
'
$
Object Identifiers
• Object identifiers used to uniquely identify objects
– can be stored as a field of an object, to refer to another
object.
– E.g., the spouse field of a person object may be an identifier
of another person object.
– can be system generated (created by database) or external
(such as social-security number)
&
'
Database Systems Concepts
c
Silberschatz, Korth and Sudarshan 1997
8.15
Object Containment
%
$
bicycle
wheel
rim
spokes
tire
brake
lever
gear
pad
frame
cable
• Each component in a design may contain other components
• Can be modeled as containment of objects. Objects containing
other objects are called complex or composite objects.
&
• Multiple levels of containment create a containment hierarchy:
links interpreted as is-part-of, not is-a.
• Allows data to be viewed at different granularities by different
users
Database Systems Concepts
8.16
c
Silberschatz, Korth and Sudarshan 1997
%
'
Object-Oriented Languages
$
• Object-oriented concepts can be used as a design tool, and be
encoded into, for example, a relational database (analogous to
modeling data with E-R diagram and then converting to a set of
relations).
• The concepts of object orientation can be incorporated into a
programming language that is used to manipulate the
database.
– Object-relational systems – add complex types and
object-orientation to relational language.
&
'
– Persistent programming languages – extend object-oriented
programming language to deal with databases by adding
concepts such as persistence and collections.
Database Systems Concepts
8.17
c
Silberschatz, Korth and Sudarshan 1997
Persistent Programming Languages
%
$
• Persistent programming languages:
– allow objects to be created and stored in a database
without any explicit format changes (format changes are
carried out transparently).
– allow objects to be manipulated in-memory – do not need to
explicitly load from or store to the database.
– allow data to be manipulated directly from the programming
language without having to go through a data manipulation
language like SQL.
• Due to power of most programming languages, it is easy to
make programming errors that damage the database.
&
• Complexity of languages makes automatic high-level
optimization more difficult.
• Do not support declarative querying very well.
Database Systems Concepts
8.18
c
Silberschatz, Korth and Sudarshan 1997
%
'
Persistence Of Objects
$
• Approaches to make transient objects persistent include
establishing persistence by:
– Class – declare all objects of a class to be persistent;
simple but inflexible.
– Creation – extend the syntax for creating transient objects
to create persistent objects.
– Marking – an object that is to persist beyond program
execution is marked as persistent before program
termination.
&
'
– Reference – declare (root) persistent objects; objects are
persistent if they are referred to (directly or indirectly) from a
root object.
Database Systems Concepts
8.19
c
Silberschatz, Korth and Sudarshan 1997
Object Identity and Pointers
%
$
• A persistent object is assigned a persistent object identifier.
• Degrees of permanence of identity:
– Intraprocedure – identity persists only during the execution
of a single procedure
– Intraprogram – identity persists only during execution of a
single program or query.
– Interprogram – identity persists from one program execution
to another.
&
– Persistent – identity persists throughout program executions
and structural reorganizations of data; required for
object-oriented systems.
Database Systems Concepts
8.20
c
Silberschatz, Korth and Sudarshan 1997
%
'
Object Identity and Pointers (Cont.)
$
• In O-O languages such as C++, an object identifier is actually
an in-memory pointer.
• Persistent pointer – persists beyond program execution; can be
thought of as a pointer into the database.
&
'
Database Systems Concepts
8.21
c
Silberschatz, Korth and Sudarshan 1997
Storage and Access of Persistent Objects
%
$
How to find objects in the database:
• Name objects (as you would name files) – cannot scale to
large number of objects.
– typically given only to class extents and other collections of
objects, but not to objects.
• Expose object identifiers or persistent pointers to the objects –
can be stored externally.
&
– All objects have object identifiers.
Database Systems Concepts
8.22
c
Silberschatz, Korth and Sudarshan 1997
%
'
Storage and Access of Persistent Objects (Cont.)
$
How to find objects in the database (Cont):
• Store collections of objects and allow programs to iterate over
the collections to find required objects.
– Model collections of objects as collection types
– Class extent – the collection of all objects belonging to the
class; usually maintained for all classes that can have
persistent objects.
&
'
Database Systems Concepts
8.23
c
Silberschatz, Korth and Sudarshan 1997
Persistent C++ Systems
%
$
• C++ language allows support for persistence to be added
without changing the language
– Declare a class called Persistent Object with attributes
and methods to support persistence
– Overloading – ability to redefine standard function names
and operators (i.e., +, −, the pointer dereference operator
->) when applied to new types
• Providing persistence without extending the C++ language is
&
– relatively easy to implement
– but more difficult to use
Database Systems Concepts
8.24
c
Silberschatz, Korth and Sudarshan 1997
%
'
ODMG C++ Object Definition Language
$
• Standardize language extensions to C++ to support
persistence
• ODMG standard attempts to extend C++ as little as possible,
providing most functionality via template classes and class
libraries
• Template class Ref<class> used to specify references
(persistent pointers)
• Template class Set<class> used to define sets of objects.
Provides methods such as insert element and
delete element.
&
'
• The C++ object definition language (ODL) extends the C++
type definition syntax in minor ways.
Example: Use notation inverse to specify referential integrity
constraints.
Database Systems Concepts
8.25
c
Silberschatz, Korth and Sudarshan 1997
ODMG C++ ODL: Example
class Person : public Persistent Object {
public:
String name;
String address;
};
class Customer : public Person {
public:
Date member from;
int customer id;
Ref<Branch> home branch;
Set<Ref<Account>> accounts inverse Account::owners;
};
&
Database Systems Concepts
8.26
c
Silberschatz, Korth and Sudarshan 1997
%
$
%
'
ODMG C++ ODL: Example (Cont.)
class Account : public Persistent Object {
private:
int balance;
public:
int number;
Set<Ref<Customer>> owners inverse Customer::accounts;
int find balance();
int update balance(int delta);
};
&
'
Database Systems Concepts
8.27
c
Silberschatz, Korth and Sudarshan 1997
ODMG C++ Object Manipulation Language
$
%
$
• Uses persistent versions of C++ operators such as new(db).
Ref<Account> account = new(bank db) Account;
new allocates the object in the specified database, rather than
in memory
• Dereference operator -> when applied on a Ref<Customer>
object loads the referenced object in memory (if not already
present) and returns in-memory pointer to the object.
• Constructor for a class – a special method to initialize objects
when they are created; called automatically when new is
executed
&
• Destructor for a class – a special method that is called when
objects in the class are deleted
Database Systems Concepts
8.28
c
Silberschatz, Korth and Sudarshan 1997
%
'
ODMG C++ OML: Example
$
int create account owner(String name, String address) {
Database * bank db;
bank db = Database::open("Bank-DB");
Transaction Trans;
Trans.begin();
Ref<Account> account = new(bank db) Account;
Ref<Customer> cust = new(bank db) Customer;
cust->name = name;
cust->address = address;
cust->accounts.insert element(account);
account->owners.insert element(cust);
... Code to initialize customer id, account number etc.
Trans.commit();
&
'
}
Database Systems Concepts
8.29
c
Silberschatz, Korth and Sudarshan 1997
ODMG C++ OML: Example of Iterators
int print customers() {
Database * bank db;
bank db = Database::open("Bank-DB");
Transaction Trans;
Trans.begin();
Iterator<Ref<Customer>> iter =
Customer::all customers.create iterator();
Ref<Customer> p;
while(iter.next(p)) {
print cust(p);
}
Trans.commit();
}
&
• Iterator construct helps step through objects in a collection.
Database Systems Concepts
8.30
c
Silberschatz, Korth and Sudarshan 1997
%
$
%