Chapter 8: Object-

Object-Oriented Databases Need for Complex Data Types

! Need for Complex Data Types ! Traditional database applications in data processing had
conceptually simple data types
! The Object-Oriented Data Model
! Relatively few data types, first normal form holds
! Object-Oriented Languages ! Complex data types have grown more important in recent years
! Persistent Programming Languages ! E.g. Addresses can be viewed as a
! Persistent C++ Systems " Single string, or
" Separate attributes for each part, or
" Composite attributes (which are not in first normal form)
! E.g. it is often convenient to store multivalued attributes as-is,
without creating a separate relation to store the values in first
normal form
! Applications
! computer-aided design, computer-aided software engineering
! multimedia and image databases, and document/hypertext
databases.

Database System Concepts 8.1 ©Silberschatz, Korth and Sudarshan Database System Concepts 8.2 ©Silberschatz, Korth and Sudarshan

Object-
Object-Oriented Data Model Object Structure

! An object has associated with it:

! Loosely speaking, an object corresponds to an entity in the E-
R model. ! A set of variables that contain the data for the object. The value of
each variable is itself an object.
! The object-oriented paradigm is based on encapsulating code
! A set of messages to which the object responds; each message may
and data related to an object into single unit. have zero, one, or more parameters.
! The object-oriented data model is a logical data model (like ! A set of methods, each of which is a body of code to implement a
the E-R model). message; a method returns a value as the response to the message
! Adaptation of the object-oriented programming paradigm (e.g., ! The physical representation of data is visible only to the
Smalltalk, C++) to database systems. implementor of the object
! Messages and responses provide the only external interface to an
object.
! The term message does not necessarily imply physical message
passing. Messages can be implemented as procedure
invocations.

Database System Concepts 8.3 ©Silberschatz, Korth and Sudarshan Database System Concepts 8.4 ©Silberschatz, Korth and Sudarshan

Messages and Methods Object Classes

! Methods are programs written in general-purpose language ! Similar objects are grouped into a class; each such object is
with the following features called an instance of its class
! only variables in the object itself may be referenced directly ! All objects in a class have the same
! data in other objects are referenced only by sending messages. ! Variables, with the same types
! Methods can be read-only or update methods ! message interface
! Read-only methods do not change the value of the object ! methods
! Strictly speaking, every attribute of an entity must be The may differ in the values assigned to variables
represented by a variable and two methods, one to read and ! Example: Group objects for people into a person class
the other to update the attribute
! Classes are analogous to entity sets in the E-R model
! 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 System Concepts 8.5 ©Silberschatz, Korth and Sudarshan Database System Concepts 8.6 ©Silberschatz, Korth and Sudarshan

Class Definition Example Inheritance

class employee { ! E.g., class of bank customers is similar to class of bank
/*Variables */
string name; employees, although there are differences
string address; ! both share some variables and messages, e.g., name and address.
date start-date;
int salary; ! But there are variables and messages specific to each class e.g.,
/* Messages */ salary for employees and credit-rating for customers.
int annual-salary(); ! Every employee is a person; thus employee is a specialization of
string get-name();
string get-address(); person
int set-address(string new-address); ! Similarly, customer is a specialization of person.
int employment-length();
}; ! Create classes person, employee and customer
! Methods to read and set the other variables are also needed with ! variables/messages applicable to all persons associated with class
strict encapsulation person.

! Methods are defined separately ! variables/messages specific to employees associated with class
employee; similarly for customer
! E.g. int employment-length() { return today() – start-date;}
int set-address(string new-address) { address = new-address;}

Database System Concepts 8.7 ©Silberschatz, Korth and Sudarshan Database System Concepts 8.8 ©Silberschatz, Korth and Sudarshan
 Inheritance (Cont.) Class Hierarchy Definition
class person{
string name;
! Place classes into a specialization/IS-A hierarchy string address:
! variables/messages belonging to class person are };
inherited by class employee as well as customer class customer isa person {
! Result is a class hierarchy int credit-rating;
};
class employee isa person {
date start-date;
int salary;
};
class officer isa employee {
int office-number,
int expense-account-number,
Note analogy with ISA Hierarchy in the E-R model };
..
.
Database System Concepts 8.9 ©Silberschatz, Korth and Sudarshan Database System Concepts 8.10 ©Silberschatz, Korth and Sudarshan

Class Hierarchy Example (Cont.) Example of Multiple Inheritance

! 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
# This is the usual choice in OO systems Class DAG for banking example.
# Can access extents of subclasses to find all objects of
subtypes of employee

Database System Concepts 8.11 ©Silberschatz, Korth and Sudarshan Database System Concepts 8.12 ©Silberschatz, Korth and Sudarshan

Multiple Inheritance More Examples of Multiple Inheritance

! With multiple inheritance a class may have more than one superclass.
! Conceptually, an object can belong to each of several
! The class/subclass relationship is represented by a directed acyclic graph
(DAG) subclasses
! Particularly useful when objects can be classified in more than one way, ! A person can play the roles of student, a teacher or footballPlayer,
which are independent of each other or any combination of the three
" E.g. temporary/permanent is independent of Officer/secretary/teller
" E.g., student teaching assistant who also play football
" Create a subclass for each combination of subclasses
– Need not create subclasses for combinations that are not possible in ! Can use multiple inheritance to model “roles” of an object
the database being modeled
! That is, allow an object to take on any one or more of a set of types
! A class inherits variables and methods from all its superclasses
! But many systems insist an object should have a most-specific
! There is potential for ambiguity when a variable/message N with the
same name is inherited from two superclasses A and B class
! No problem if the variable/message is defined in a shared superclass ! That is, there must be one class that an object belongs to which is
! Otherwise, do one of the following a subclass of all other classes that the object belongs to
" flag as an error, ! Create subclasses such as student-teacher and
" rename variables (A.N and B.N) student-teacher-footballPlayer for each combination
" choose one. ! When many combinations are possible, creating
subclasses for each combination can become cumbersome

Database System Concepts 8.13 ©Silberschatz, Korth and Sudarshan Database System Concepts 8.14 ©Silberschatz, Korth and Sudarshan

Object Identity Object Identifiers

! An object retains its identity even if some or all of the values ! Object identifiers used to uniquely identify objects
of variables or definitions of methods change over time. ! Object identifiers are unique:
! Object identity is a stronger notion of identity than in " no two objects have the same identifier
programming languages or data models not based on object " each object has only one object identifier
orientation. ! E.g., the spouse field of a person object may be an identifier of
! Value – data value; e.g. primary key value used in relational another person object.
systems. ! can be stored as a field of an object, to refer to another object.
! Name – supplied by user; used for variables in procedures. ! Can be
! Built-in – identity built into data model or programming " system generated (created by database) or
language.
" external (such as social-security number)
" no user-supplied identifier is required.
! System generated identifiers:
" Is the form of identity used in object-oriented systems.
" Are easier to use, but cannot be used across database systems
" May be redundant if unique identifier already exists

Database System Concepts 8.15 ©Silberschatz, Korth and Sudarshan Database System Concepts 8.16 ©Silberschatz, Korth and Sudarshan
 Object Containment Object-
Object-Oriented Languages

! Object-oriented concepts can be used in different ways

! Object-orientation 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.
! Each component in a design may contain other components
" Object-relational systems – add complex types and
! Can be modeled as containment of objects. Objects containing; object-orientation to relational language.
other objects are called composite objects.
" Persistent programming languages – extend object-
! Multiple levels of containment create a containment hierarchy oriented programming language to deal with databases
! links interpreted as is-part-of, not is-a. by adding concepts such as persistence and collections.

! Allows data to be viewed at different granularities by different

users.

Database System Concepts 8.17 ©Silberschatz, Korth and Sudarshan Database System Concepts 8.18 ©Silberschatz, Korth and Sudarshan

Persistent Programming Languages Persistent Prog.

Prog. Languages (Cont.)

! Persistent Programming languages allow objects to be created ! Drawbacks of persistent programming languages
and stored in a database, and used directly from a programming
language ! Due to power of most programming languages, it is easy to make
programming errors that damage the database.
! allow data to be manipulated directly from the programming language
! Complexity of languages makes automatic high-level optimization
" No need to go through SQL.
more difficult.
! No need for explicit format (type) changes
! Do not support declarative querying as well as relational databases
" format changes are carried out transparently by system
" Without a persistent programming language, format changes
becomes a burden on the programmer
– More code to be written
– More chance of bugs
! allow objects to be manipulated in-memory
" no need to explicitly load from or store to the database
– Saved code, and saved overhead of loading/storing large
amounts of data

Database System Concepts 8.19 ©Silberschatz, Korth and Sudarshan Database System Concepts 8.20 ©Silberschatz, Korth and Sudarshan

Persistence of Objects Object Identity and Pointers

! Approaches to make transient objects persistent include ! A persistent object is assigned a persistent object identifier.
establishing ! Degrees of permanence of identity:
! Persistence by Class – declare all objects of a class to be ! Intraprocedure – identity persists only during the executions of a
persistent; simple but inflexible. single procedure
! Persistence by Creation – extend the syntax for creating objects to ! Intraprogram – identity persists only during execution of a single
specify that that an object is persistent. program or query.
! Persistence by Marking – an object that is to persist beyond ! Interprogram – identity persists from one program execution to
program execution is marked as persistent before program another, but may change if the storage organization is changed
termination.
! Persistent – identity persists throughout program executions and
! Persistence by Reachability - declare (root) persistent objects; structural reorganizations of data; required for object-oriented
objects are persistent if they are referred to (directly or indirectly) systems.
from a root object.
" Easier for programmer, but more overhead for database system
" Similar to garbage collection used e.g. in Java, which
also performs reachability tests

Database System Concepts 8.21 ©Silberschatz, Korth and Sudarshan Database System Concepts 8.22 ©Silberschatz, Korth and Sudarshan

Object Identity and Pointers (Cont.) Storage and Access of Persistent Objects
How to find objects in the database:
! In O-O languages such as C++, an object identifier is
! Name objects (as you would name files)
actually an in-memory pointer.
! Cannot scale to large number of objects.
! Persistent pointer – persists beyond program execution
! Typically given only to class extents and other collections of
! can be thought of as a pointer into the database objects, but not objects.
" E.g. specify file identifier and offset into the file
! Expose object identifiers or persistent pointers to the objects
! Problems due to database reorganization have to be dealt
! Can be stored externally.
with by keeping forwarding pointers
! All objects have object identifiers.
! 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 System Concepts 8.23 ©Silberschatz, Korth and Sudarshan Database System Concepts 8.24 ©Silberschatz, Korth and Sudarshan
 Persistent C++ Systems ODMG C++ Object Definition Language
! C++ language allows support for persistence to be added without ! The Object Database Management Group is an industry
changing the language consortium aimed at standardizing object-oriented databases
! Declare a class called Persistent_Object with attributes and methods ! in particular persistent programming languages
to support persistence
! Includes standards for C++, Smalltalk and Java
! Overloading – ability to redefine standard function names and
operators (i.e., +, –, the pointer deference operator –>) when applied ! ODMG-93
to new types ! ODMG-2.0 and 3.0 (which is 2.0 plus extensions to Java)
! Template classes help to build a type-safe type system supporting
" Our description based on ODMG-2.0
collections and persistent types.
! Providing persistence without extending the C++ language is ! ODMG C++ standard avoids changes to the C++ language
! relatively easy to implement ! provides functionality via template classes and class libraries
! but more difficult to use
! Persistent C++ systems that add features to the C++ language
have been built, as also systems that avoid changing the
language

Database System Concepts 8.25 ©Silberschatz, Korth and Sudarshan Database System Concepts 8.26 ©Silberschatz, Korth and Sudarshan

ODMG Types ODMG C++ ODL: Example

class Branch : public d_Object {

! Template class d_Ref<class> used to specify references
(persistent pointers) ….
}
! Template class d_Set<class> used to define sets of objects.
class Person : public d_Object {
! Methods include insert_element(e) and delete_element(e) public:
d_String name; // should not use String!
! Other collection classes such as d_Bag (set with duplicates d_String address;
allowed), d_List and d_Varray (variable length array) also };
provided. class Account : public d_Object {
! d_ version of many standard types provided, e.g. d_Long and private:
d_string d_Long balance;
public:
! Interpretation of these types is platform independent d_Long number;
! Dynamically allocated data (e.g. for d_string) allocated in the d_Set <d_Ref<Customer>> owners;
database, not in main memory int find_balance();
int update_balance(int delta);
};

Database System Concepts 8.27 ©Silberschatz, Korth and Sudarshan Database System Concepts 8.28 ©Silberschatz, Korth and Sudarshan

ODMG C++ ODL: Example (Cont.) Implementing Relationships

! Relationships between classes implemented by references

class Customer : public Person { ! Special reference types enforces integrity by adding/removing
public: inverse links.
d_Date member_from; ! Type d_Rel_Ref<Class, InvRef> is a reference to Class, where
d_Long customer_id; attribute InvRef of Class is the inverse reference.
d_Ref<Branch> home_branch; ! Similarly, d_Rel_Set<Class, InvRef> is used for a set of references
d_Set <d_Ref<Account>> accounts; }; ! Assignment method (=) of class d_Rel_Ref is overloaded
! Uses type definition to automatically find and update the inverse
link
! Frees programmer from task of updating inverse links
! Eliminates possibility of inconsistent links
! Similarly, insert_element() and delete_element() methods of
d_Rel_Set use type definition to find and update the inverse link
automatically

Database System Concepts 8.29 ©Silberschatz, Korth and Sudarshan Database System Concepts 8.30 ©Silberschatz, Korth and Sudarshan

Implementing Relationships ODMG C++ Object Manipulation Language

! Uses persistent versions of C++ operators such as new(db)
! E.g.
d_Ref<Account> account = new(bank_db, “Account”) Account;
extern const char _owners[ ], _accounts[ ];
! new allocates the object in the specified database, rather than in
class Account : public d.Object { memory.
…. ! The second argument (“Account”) gives typename used in the
d_Rel_Set <Customer, _accounts> owners; database.
}
! Dereference operator -> when applied on a d_Ref<Account>
// .. Since strings can’t be used in templates … reference loads the referenced object in memory (if not already
const char _owners= “owners”; present) before continuing with usual C++ dereference.
const char _accounts= “accounts”;
! Constructor for a class – a special method to initialize objects
when they are created; called automatically on new call.
! Class extents maintained automatically on object creation and
deletion
! Only for classes for which this feature has been specified
" Specification via user interface, not C++
! Automatic maintenance of class extents not supported in
earlier versions of ODMG

Database System Concepts 8.31 ©Silberschatz, Korth and Sudarshan Database System Concepts 8.32 ©Silberschatz, Korth and Sudarshan
 ODMG C++OML: Database and Object ODMG C++ OML: Example
Functions
! Class d_Database provides methods to
int create_account_owner(String name, String Address){
! open a database: open(databasename) Database bank_db.obj;
Database * bank_db= & bank_db.obj;
! give names to objects: set_object_name(object, name)
bank_db =>open(“Bank-DB”);
! look up objects by name: lookup_object(name) d.Transaction Trans;
! rename objects: rename_object(oldname, newname) Trans.begin();
! close a database (close());
d_Ref<Account> account = new(bank_db) Account;
! Class d_Object is inherited by all persistent classes.
d_Ref<Customer> cust = new(bank_db) Customer;
! provides methods to allocate and delete objects cust->name - name;
! method mark_modified() must be called before an object is cust->address = address;
updated. cust->accounts.insert_element(account);
" Is automatically called when object is created ... Code to initialize other fields

Trans.commit();
}

Database System Concepts 8.33 ©Silberschatz, Korth and Sudarshan Database System Concepts 8.34 ©Silberschatz, Korth and Sudarshan

ODMG C++ OML: Example (Cont.) ODMG C++ OML: Example of Iterators

! Class extents maintained automatically in the database. int print_customers() {

! To access a class extent: Database bank_db_obj;
d_Extent<Customer> customerExtent(bank_db); Database * bank_db = &bank_db_obj;
bank_db->open (“Bank-DB”);
! Class d_Extent provides method d_Transaction Trans; Trans.begin ();
d_Iterator<T> create_iterator()
to create an iterator on the class extent d_Extent<Customer> all_customers(bank_db);
! Also provides select(pred) method to return iterator on objects that d_Iterator<d_Ref<Customer>> iter;
satisfy selection predicate pred. iter = all_customers–>create_iterator();
! Iterators help step through objects in a collection or class extent. d_Ref <Customer> p;

! Collections (sets, lists etc.) also provide create_iterator() method. while{iter.next (p))
print_cust (p); // Function assumed to be defined elsewhere
Trans.commit();
}

Database System Concepts 8.35 ©Silberschatz, Korth and Sudarshan Database System Concepts 8.36 ©Silberschatz, Korth and Sudarshan

Making Pointer Persistence Transparent

ODMG C++ Binding: Other Features
! Declarative query language OQL, looks like SQL ! Drawback of the ODMG C++ approach:
! Form query as a string, and execute it to get a set of results ! Two types of pointers
(actually a bag, since duplicates may be present) ! Programmer has to ensure mark_modified() is called, else
d_Set<d_Ref<Account>> result; database can become corrupted
d_OQL_Query q1("select a ! ObjectStore approach
from Customer c, c.accounts a
! Uses exactly the same pointer type for in-memory and database
where c.name=‘Jones’ objects
and a.find_balance() > 100");
d_oql_execute(q1, result); ! Persistence is transparent applications
" Except when creating objects
! Provides error handling mechanism based on C++ exceptions,
through class d_Error ! Same functions can be used on in-memory and persistent objects
since pointer types are the same
! Provides API for accessing the schema of a database.
! Implemented by a technique called pointer-swizzling which is
described in Chapter 11.
! No need to call mark_modified(), modification detected
automatically.

Database System Concepts 8.37 ©Silberschatz, Korth and Sudarshan Database System Concepts 8.38 ©Silberschatz, Korth and Sudarshan

Persistent Java Systems ODMG Java

! ODMG-3.0 defines extensions to Java for persistence ! Transaction must start accessing database from one of the root
! Java does not support templates, so language extensions are object (looked up by name)
required ! finds other objects by following pointers from the root objects
! Model for persistence: persistence by reachability ! Objects referred to from a fetched object are allocated space in
! Matches Java’s garbage collection model memory, but not necessarily fetched
! Garbage collection needed on the database also ! Fetching can be done lazily
! Only one pointer type for transient and persistent pointers ! An object with space allocated but not yet fetched is called a hollow
object
! Class is made persistence capable by running a post-processor
on object code generated by the Java compiler ! When a hollow object is accessed, its data is fetched from disk.
! Contrast with pre-processor used in C++
! Post-processor adds mark_modified() automatically
! Defines collection types DSet, DBag, DList, etc.
! Uses Java iterators, no need for new iterator class

Database System Concepts 8.39 ©Silberschatz, Korth and Sudarshan Database System Concepts 8.40 ©Silberschatz, Korth and Sudarshan
 Specialization Hierarchy for the Bank Example

End of Chapter

Database System Concepts 8.42 ©Silberschatz, Korth and Sudarshan

Class Hierarchy Corresponding to Figure 8.2 Class DAG for the Bank Example

Database System Concepts 8.43 ©Silberschatz, Korth and Sudarshan Database System Concepts 8.44 ©Silberschatz, Korth and Sudarshan

Containment Hierarchy for Bicycle-

Bicycle-Design Database

Database System Concepts 8.45 ©Silberschatz, Korth and Sudarshan