1. Advanced Databases Object Oriented Databases
School of Informatics
Akhtar Ali

2. References
Barry Eaglestone, Mick Ridley, Object Databases: An Introduction, McGraw-Hill, 1998
R.G.G. Cattell, Douglas K. Barry. Object Database Standard: ODMG 3.0. Morgan Kaufmann Publishers, Inc. 2000
Richard Cooper, Object Databases: An ODMG Approach, ITCP 1997
R. Elmasri and S. B. Navate, Fundamental of Database Systems – 4th Edition, 2003, Chapter 20 & 21

3. Object Oriented Concepts
An object represents a real world entity (Person), a concept (Drama), a logical thing (Licence), a physical thing (Car)
Every object has a unique Object Identifier (OID)
An object is made of two things:
State: properties (name, address, birthDate of a Person)
Behaviour: operations (age of a Person is computed from birthDate and current date)
Object Identifier
Unique for every object
System generated
Never changes in the lifetime of the object
Not visible to the user

4. OO Concepts – continued
Classification
Classification is the process of grouping together objects which have common features.
Programming languages have type systems and database systems have data models to classify object.
The name used for the classificatory group of values is usually either class or type.
class Person
properties
name: String
address: String
birthDate: Date
operations
age(): Integer
end Person

5. OO Concepts – continued
Encapsulation
The integration of the description of data structure and operation is called encapsulation.
Objects are composed of properties (values) and operations.
It introduces a component of computation into the data.
This feature is missing in Relational Databases (RDBs) and is usually coded into the application.
Inheritance
A new class is usually described in terms of one or more previously defined classes from which the new class takes (inherits) properties and operations. For instance, the following defines a new class Student:
class Student ISA Person
properties
major: String
tutor: Lecturer
operations
register(C: Course): Boolean
end Student
Student is sub-type of Person
Person is super-type of Student
A Student is also a Person, but not
every Person is a Student.
A Student has all the properties and
operations same as Person

6. OO Concepts – continued
An object system or object-based system is one which supports the modeling of data as abstract entities, with object identity.
An object-oriented system is an object system in which all data is created as instances of classes which take part in an inheritance hierarchy.
An object-oriented database management system (OODBMS) is a DBMS with an object-oriented logical data model.
An object-oriented database is a database made up of objects and managed by an OODBMS.

7. Why Object Oriented Databases?
Object Oriented Databases (OODBs) are inevitable when:
Data is complex and variable in size
Complex structural and compositional relationships
Data is highly inter-related
Data is evolving rapidly over time
Richer data types
complex objects
inheritance
user extensibility
Behaviour with data
not just a data model but also
operations can be bundled together with data

8. Complex Data

9. OODBs are more Natural & Direct

10. An Example Conceptual Schema in ER
Student and Lecturer are sub-types of Person. ‘d’ means that Student and Lecturer are disjoint.
A Student cannot be a Lecturer at the same time and vice versa.
Attribute names are omitted.
Person
Student
Lecturer
Department
Course
Unit
tutor N 1
enrolledOn
offers
worksFor
partOf M
takes d
teaches

11. The Conceptual Schema in UML

12. OO Representation class Person properties name: String address: String
birthDate: Date
operations
age(): Integer
end Person
class Lecturer ISA Person
properties
room: Integer
tutees: set(Student)
worksFor: Department
teaches: set(Unit)
operations
teachUnit(U: Unit): Boolean
end Lecturer
class Course
properties
name: String
offeredBy: Department
hasStudents: set(Student)
hasUnits: set(Unit)
end Course
class Student ISA Person
properties
major: String
tutor: Lecturer
enrolledOn: Course
takes: set(Unit)
operations
register(C: Course): Boolean
takeUnit(U: Unit): Boolean
end Student
class Department
properties
name: String
staff: set(Lecturer)
offers: set(Course)
end Department
class Unit
properties
name: String
code: String
takenBy: set(Student)
taughtBy: set(Lecturer)
partOf: set(Course)
end Unit

13. OO Representation – continued
No primary keys are required, but keys can be used.
Relationships are represented in a clear manner, no foreign keys used as in case of RDBs. e.g.
As in Lecturer class
worksFor: Department
teaches: set(Unit)
worksFor is not a foreign key but an OID of a Department object.
teaches is collection valued i.e. a set of OIDs of Unit objects.
Relationships are bi-directional in the natural way.
As in Department class
staff: set(Lecturer)
staff is a set of OIDs of Lecturer objects, which is inverse to worksFor in Lecturer class.
Many-to-many relationships are represented directly without introducing a new class or relation as in the case of takes, partOf, and teaches relationships.

14. Comparison RDBs vs. ORDBs
Very easy to compare because both are based on Relational Model.
An RDB does not support abstract data types (ADT), all attribute values must be atomic and relations must be in first normal form (flat relation).
An ORDB supports ADTs, attributes can be multi-valued, and does not require first normal form.
The underlying basic data structures of RDBs are much simpler but less versatile than ORDBs.
Optimization of queries is much easier and efficient in RDBs compared to ORDBs. But this does not mean that RDBs are faster than ORDBs.
ORDBs support complex data whereas RDBs don’t.
ORDBs support wide range of applications.

15. Comparison – continued…
RDBs vs. OODBs.
Not very easy to compare because of philosophical differences.
RDBs have only one construct i.e. Relation, whereas the type system of OODBs is much richer and complex.
RDBs require primary keys and foreign keys for implementing relationships, OODBs simply don’t.
Optimization of queries in OODBs is much complex than RDBs, but is mainly inspired from the Optimization techniques in RDBs.
OODBs support complex data whereas RDBs don’t.
OODBs support wide range of applications.
OODBs are much faster than RDBs but are less mature to handle large volumes of data.
There is more acceptance and domination of RDBs in the market than that for OODBs.

16. Comparison – continued…
OODBs vs. ORDBs.
Both support ADTs, collections, OIDs, and inheritance, though philosophically quite different.
ORDBs extended RDBs whereas OODBs add persistence and database capabilities to OO languages.
Both support query languages for manipulating collections and nested and complex data.
SQL3 is inspired from OO concepts and is converging towards OQL (object query language).
ORDBs carries all the benefits of RDBs, whereas OODBs are less benefited from the technology of RDBs.
OODBs are seamlessly integrated with OOPLs with less mismatch in the type systems;
ORDBs (SQL3) have quite different constructs than those of OOPLs when used in embedded form.

17. Advantages of OODB
Greater semantic expressibility: storing and manipulating complex objects greatly simplifies the model of the application world
Object identity is superior unifying concept than using surrogates (e.g. primary and foreign keys in relational DBMS)
The ease of user extensibility
Behavioural model: programs and data are stored together, unifying conceptually connected features of database
Typing objects provides a more coherent structure for the database
Code re-use through inheritance, over-riding and late binding
A possible pre-requisite to active databases and interoperability?

18. Disadvantages of OODB
No formal semantics, unlike the relational data model.
Pure OO systems do not include the notion of class extents which is of fundamental importance in DB management.
Design methods must be evolved to include behaviour and support for dynamic processes.
Loss of the relational data model’s simplicity.
Optimization / tuning(e.g. indexes) not as well understood and are difficult; the overall record-at-a-time flavour of the OO systems means that relational-style optimization is unlikely.
Transaction management support is not very mature.

19. Current Myths [Won Kim 95]
OODBs are 10 to 100 times faster than RDBs.
OODBs eliminate the need for joins (not altogether).
Object identity eliminates the need for keys.
OODBs eliminate the need for a non-procedural database language (not in reality).
Query processing will violate encapsulation (may or may not).
OODBs can support versioning and long duration transactions.
OODBs support multimedia data.

20. OODBMS Features Object data model
object identifiers, type inheritance, methods, complex objects
Integration with an OO programming language
transparent or semi-transparent retrieval and storage of objects
Declarative query language
usually an SQL like syntax
Advanced data sharing
long transactions; optimistic concurrency; multiple versions of data; private data check-out
Client-server architecture

21. OODB Evolution Programming Languages Databases
Persistent Programming Languages
e.g. Napier88,
PJama
RDBMS
Extended Relational Systems
e.g. UniSQL, Oracle, Illustra
OODB
OOPL add db facilities
e.g. C++, Smalltalk
-> ObjectStore, Gemstone,POET
Model based systems
add language facilities to a new data model.
e.g O2, ODMG
Semantic Data Models
e.g. ER, UML, FDM
-> OpenODB, ODBII

22. Strategies for building OODBMS
Extend OO programming languages to be persistent
popular approach
programming viewpoint rather than a database one
no standard model; one programming language;
ObjectStore, POET, Gemstone
Use an object-oriented data model for the DBMS
database management viewpoint
need language bindings
query languages, transaction management etc
O2, lambda-DB
Standardization of model and services
ODMG 3 Standard; OMG (CORBA)

23. Summary Introduction to OO Concepts
Motivation of why OODBs are inevitable
An Example of OO Schema
Comparison with RDBs and ORDBs
Advantages and Disadvantages of OODBs
Evolution of OODBs
Strategies of building an OODBMS