CSIS22H

Advanced Database Systems

Lecture 2
Object-Oriented Databases
Main Concepts
Lecture Resources
• Ramez Elmasri and Shamkant B. Nafathe,
Fundamentals of Database Systems, 5th Ed, Book
Slides.

• Dr. Michael Grossniklaus, , Object-Oriented

Databases, Lecture slides published online on
ODBMS.ORG
 Lecture Outline
• Brief Data Modeling History
• Reasons for OOBD
• Commercial OO Database products
• OODB Manifesto
• ODB vs. RDB
 History of OO Models and Systems
▪ Traditional Data Models

▪ Hierarchical & Network (since mid-60’s)

▪ Relational (since 1970 and commercially since 1982)

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

Copyrights @ 2007 Ramez Elmasri and Shamkant B. Nafathe

 Reasons for Creation of Object-
Oriented Databases
◼ OO databases try to maintain a direct correspondence
between real-world and database objects so that
objects do not lose their integrity and identity.
▪ Need for more complex applications

▪ Need for additional data modeling features

▪ Increased use of object-oriented programming languages

 Commercial OO Database products
◼ Several in the 1990’s, but did not make much impact on
mainstream data management

◼ Second growth period in 2004, when open source object

databases emerged.

◼ Easy to use, because they are entirely written in OOP

• Simula (1960’s)
• Smalltalk (1970’s)
• C++ (late 1980’s)
• Java (1990’s and 2000’s)

Copyrights @ 2007 Ramez Elmasri and Shamkant B. Nafathe

 Object-Oriented Databases

▪ Combine features and properties of

▪ Object-oriented systems and languages
▪ Database management systems

▪ Diverse focus of object-oriented database systems

Systems

▪ making object-oriented programming languages persistent

▪ managing and storing object data

▪ Avoid object-relational impedance mismatch

Michael Grossniklaus , Object-Oriented Databases, Lecture slides published online on ODBMS.ORG

 Defining Object-Oriented Databases

▪ The object-oriented database manifesto

▪ 13 mandatory features

▪ 5 optional characteristics

▪ 4 open choices

Michael Grossniklaus , Object-Oriented Databases, Lecture slides published online on ODBMS.ORG

 The Object-Oriented Database Manifesto
1. Object identity
2. Complex objects
3. Encapsulation
Object-oriented 4. Types and classes
systems 5. Type and class hierarchies
6. Overriding, overloading and late binding
7. Computational completeness
8. Extensibility
9. Persistence
10. Efficiency
Database 11. Concurrency
management systems 12. Reliability
13. Declarative query language

Michael Grossniklaus , Object-Oriented Databases, Lecture slides published online on ODBMS.ORG

 1. Object 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 be immutable

▪ Should not change,
▪ Should be used only once
▪ Shouldn’t depend on any attribute value.
▪ Shouldn’t depend on the object’s physical address.
▪ The value of OID is not visible to the external user, but it is used
internally by the system to indentify each object uniquely and
to create and manage inter-object reference.
Copyrights @ 2007 Ramez Elmasri and Shamkant B. Nafathe
1. Object Identity
 2. Complex Objects
▪ Complex object formed from simpler ones by constructors

▪ One formal way to represent objects is to view each object as

a triple (i, c, v)

▪ i : is the unique object identifier OID

▪ c : is a type constructor (how the object state is constructed)
▪ v : the object current state
▪ Constructor Orthogonality

▪ Any constructor should apply to any object. Constructs

should behave the same regardless of the context.

Michael Grossniklaus , Object-Oriented Databases, Lecture slides published online on ODBMS.ORG

 2. Complex Objects (Type Constructors )
▪ The three most basic constructors are:
▪ Atom: atomic value from a specific domain
▪ Tuple: a set of attributes
▪ Set: distinct set of object identifiers of the same type
▪ Other commonly used constructors include
▪ List: ordered set of arbitrary number of OIDs
▪ bag: non-distinct set of object identifiers of the same type
▪ Array: single dimensional array of OIDs.
▪ The only case where an actual value appears is in the
state of an object of type atom. (Simple Object)
Copyrights @ 2007 Ramez Elmasri and Shamkant B. Nafathe
Copyrights @ 2007 Ramez Elmasri and Shamkant B. Nafathe
Copyrights @ 2007 Ramez Elmasri and Shamkant B. Nafathe
 Literals (atom)
Object
Properties
Tuples
Set

Object
behavior

Copyrights @ 2007 Ramez Elmasri and Shamkant B. Nafathe

Objects Identity and Equality

▪ two objects are identical if they have the same OID

▪ two objects are equal if they have the same state
▪ Example:
▪ o1 = (i1, tuple, <a1:i4, a2:i6>)
▪ o2 = (i2, tuple, <a1:i5, a2:i6>)
▪ o3 = (i3, tuple, <a1:i4, a2:i6>)
▪ o4 = (i4, atom, 10)
▪ o5 = (i5, atom, 10)
▪ o6 = (i6, atom, 20)
 Objects Identity and Equality
▪ In this example, The objects o1 and o2 have equal states, since
their states at the atomic level are the same but the values are
reached through distinct objects o4 and o5.
▪ However, the states of objects o1 and o3 are identical, even
though the objects themselves are not because they have
distinct OIDs.
▪ Similarly, although the states of o4 and o5 are identical, the
actual objects o4 and o5 are equal but not identical, because
they have distinct OIDs.

Copyrights @ 2007 Ramez Elmasri and Shamkant B. Nafathe

 3. Encapsulation
▪ Object consists of interface and implementation

▪ Interface defines signatures of public methods

▪ Implementation includes object data and methods

▪ Object state is only modified through public methods

Michael Grossniklaus , Object-Oriented Databases, Lecture slides published online on ODBMS.ORG

 3. Encapsulation
Class Interface

Michael Grossniklaus , Object-Oriented Databases, Lecture slides published online on ODBMS.ORG

3. Encapsulation
Class Implementation
3. Encapsulation
 4. Types and Classes

Michael Grossniklaus , Object-Oriented Databases, Lecture slides published online on ODBMS.ORG

 5. Type and Class Hierarchies
▪ Advantages
▪ Powerful modelling tool
• move objects between hierarchy levels
• object specialisation (↓) and generalisation (↑)
• class instance versus class member

▪ Guarantee semantic complexity

▪ Reuse of specification and implementation

▪ Inheritance
▪ Objects of subclass belong automatically to superclass
▪ Attributes, methods, and relationships are inherited from superclass
▪ Subclass can introduce new attributes, methods, and relationships

Michael Grossniklaus , Object-Oriented Databases, Lecture slides published online on ODBMS.ORG

 6. Overriding, Overloading and
Late Binding
▪ Method overriding
▪ It appears in subclasses
▪ They have the same name, parameter as a
superclass method in the same order.
▪ They have the same return type as a superclass method
▪ Method overloading
▪ They appear in the same class or a subclass.
▪ They have the same name but, have different
parameter lists, and can have different return types

▪ Late binding
▪ Appropriate version of overloaded method selected at run time
▪ Also known as virtual method dispatching
Michael Grossniklaus , Object-Oriented Databases, Lecture slides published online on ODBMS.ORG
 6. Overriding, Overloading and
Late Binding
▪ Method overriding
class student
{ attribute st_no int;
Attribute st_name string;
Void calc_grade (string year);};

class senior_student
(Extend student)
{Void calc_grade (string year);};

▪ Method overloading
class senior_student
(Extend student)
{Void calc_grade (int year);};

Michael Grossniklaus , Object-Oriented Databases, Lecture slides published online on ODBMS.ORG

 7. Computational Completeness
and Extensibility
▪ Computational completeness
▪ Requirement for the method implementation language

▪ Any computable function can be expressed

▪ Can be realised through connection with existing language

▪ Extensibility
▪ Database has a set of predefined types
▪ Developers can define new types according to requirements
▪ no usage distinction between system and user types

Michael Grossniklaus , Object-Oriented Databases, Lecture slides published online on ODBMS.ORG

 9. Persistency
▪ Persistent Programming languages allow objects to be
created and stored in a database, and used directly from
a programming language
▪ allow data to be manipulated directly from the programming
language
• No need to go through SQL.

▪ No need for explicit format (type) changes

• Without a persistent programming language, format changes becomes a
burden on the programmer

Copyrights @ 2007 Ramez Elmasri and Shamkant B. Nafathe

 9. Persistency
▪ Drawbacks of persistent programming languages
▪ 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 as well as relational
databases

Copyrights @ 2007 Ramez Elmasri and Shamkant B. Nafathe

 9. Persistency
▪ Approaches to make transient objects persistent
▪ Persistence by Class – declare all objects of a class to be
persistent; simple but inflexible.
▪ Persistence by Creation – extend the syntax for creating objects
to specify that an object is persistent.
▪ Persistence by Marking – an object that is to persist beyond
program execution is marked as persistent before program
termination.
▪ Persistence by Reachability - declare (root) persistent objects;
objects are persistent if they are referred to (directly or
indirectly) from a root object.

Copyrights @ 2007 Ramez Elmasri and Shamkant B. Nafathe

 9. Persistency
▪ How to access 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 objects.
▪ Expose object identifiers or persistent pointers to the
objects
• Can be stored externally.
• 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.

Copyrights @ 2007 Ramez Elmasri and Shamkant B. Nafathe

 10. Efficiency
▪ Secondary storage management

▪ Index management

▪ Data clustering

▪ Data buffering

▪ Access path selection

▪ Query optimisation

Michael Grossniklaus , Object-Oriented Databases, Lecture slides published online on ODBMS.ORG

 11. Concurrency Control and Recovery
▪ Concurrency
▪ Management of multiple users concurrently interacting
▪ ACID: Atomicity, Consistency, Isolation and Durability
▪ Serialisability of operations: Complete Isolation

12. Reliability
▪ Resiliency to user, software and hardware failures

▪ Transactions can be committed or aborted

▪ Restore previous coherent state of data

▪ Redoing and undoing of transactions

▪ Logging of operations

Michael Grossniklaus , Object-Oriented Databases, Lecture slides published online on ODBMS.ORG

 13. Declarative Query Language
▪ High-level language
▪ express non-trivial queries concisely
▪ text-based or graphical interface
▪ declarative
▪ Efficient execution
▪ possibility for query optimisation

▪ Application independent
▪ work on any possible database
▪ no need for additional methods on user-defined types

Michael Grossniklaus , Object-Oriented Databases, Lecture slides published online on ODBMS.ORG

 13. Optional Characteristics
and Open Choices
▪ Optional characteristics

▪ multiple inheritance

▪ distribution

▪ design transactions, long transactions, nested transactions

Michael Grossniklaus , Object-Oriented Databases, Lecture slides published online on ODBMS.ORG

 Identity: RDB vs.. ODB

Can you explain??

 Relationships: RDB vs.. ODB
Relationships in RDB
▪ Relationships among tuples are specified by
attributes with matching values (via foreign keys)

▪ Foreign keys are single-valued

▪ M:N relationships must be presented via a

separate relation (table)

Copyrights @ 2007 Ramez Elmasri and Shamkant B. Nafathe

 FIGURE 7.2
Result of mapping
the COMPANY ER
schema into a
relational schema.

Copyrights @ 2007 Ramez Elmasri and Shamkant B. Nafathe

 Relationships: RDB vs. ODB
Relationships in ODB
▪ Relationships are handled by reference attributes
that include OIDs of related objects

▪ Single and collection of references are allowed

▪ References for binary relationships can be

expressed in single direction or both directions via
inverse operator

Copyrights @ 2007 Ramez Elmasri and Shamkant B. Nafathe

 Inheritance: RDB vs. ODB

Inheritance in RDB
▪ RDB has no built-in support for inheritance
relationships; there are several options for mapping
inheritance relationships in an RDB

Copyrights @ 2007 Ramez Elmasri and Shamkant B. Nafathe

 FIGURE 4.7
EERD for a University
Database

Copyrights @ 2007 Ramez Elmasri and Shamkant B. Nafathe

 FIGURE 7.5
Mapping the EER specialization lattice in Figure 4.7 using
multiple options.

Copyrights @ 2007 Ramez Elmasri and Shamkant B. Nafathe

 Inheritance: RDB vs. ODB

Inheritance in ODB
▪ Inheritance structures are built in ODB (and
achieved via “:” and extends operators)
 Specification of Operations : RDB vs. ODB

RDB
▪ Operations specification may be delayed until
implementation

ODB
▪ Operations specified during design (as part of
class specification)

Copyrights @ 2007 Ramez Elmasri and Shamkant B. Nafathe

 Current Status
▪ OODB market growing very slowly these days.
▪ OO ideas are being used in a large number of
applications, without explicitly using the OODB
platform to store data.
▪ Growth
▪ OO tools for modeling and analysis, O-O Programming
Languages like Java and C++
▪ Compromise Solution Proposed
▪ Object Relational DB Management (Informix Universal
Server, Oracle 10i, IBM’s UDB, DB2/II …)

Copyrights @ 2007 Ramez Elmasri and Shamkant B. Nafathe