1 Advanced Databases – Lecture # 11 Object-Oriented Databases Advanced Databases Object Oriented Databases School of Informatics Akhtar Ali

1Advanced Databases – Lecture # 11 Object-Oriented Databases

Advanced Databases

Object Oriented Databases

School of Informatics

Akhtar Ali


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 – 3rd Edition, 2000, Chapter 11 & 12


Object Oriented Concepts

• Object– 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


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


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

propertiesmajor: Stringtutor: Lecturer

operationsregister(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


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.


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


Complex Data


OODBs are more Natural & Direct


An Example Conceptual Schema in ER

Person

Student Lecturer

DepartmentCourseUnit

tutor

N

N 1

enrolledOn

1

offersN 1

worksFor

N

1

partOfN M

takes

d

N

M

teaches

M

N

• 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.


The Conceptual Schema in UML

**

Person

name: stringaddress: stringbirthDate: date

age(): integer

Student

major: string

register(C: Course): booleantakeUnit(U: Unit): boolean

Lecturer

room: stringsalary: floatjoinDate: date

teachUnit(U: Unit): bollean

tutor tutees

* 1

Department

deptId: stringname: string

getCourses(): Set(Course)

worksFor staff

* 1

offers 1

deptpartOf units

*

Course

courseCode: stringname: string

getUnits(): Set(Unit)

Unit

unitCode: stringdescription: string

getCourses(): Set(Course)

takes

*takenBy

enrolledOn

*

students

1

*


OO Representationclass Course

properties

name: String

offeredBy: Department

hasStudents: set(Student)

hasUnits: set(Unit)

end Course

class Student ISA Person properties

major: Stringtutor: LecturerenrolledOn: Coursetakes: set(Unit)

operationsregister(C: Course): BooleantakeUnit(U: Unit): Boolean

end Student

class Lecturer ISA Person properties

room: Integertutees: set(Student)worksFor: Departmentteaches: set(Unit)

operationsteachUnit(U: Unit): Boolean

end Lecturer

class Person

properties

name: String

address: String

birthDate: Date

operations

age(): Integer

end Person

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


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: Departmentteaches: 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.


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.


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.


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.


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?


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.


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.


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


OODB Evolution

Persistent Programming Languagese.g. Napier88, PJama

Extended Relational Systemse.g. UniSQL, Oracle, Illustra

OOPL add db facilities

e.g. C++, Smalltalk-> ObjectStore, Gemstone,POET

Semantic Data Modelse.g. ER, UML, FDM-> OpenODB, ODBII

OODB

Programming Languages Databases

RDBMS

Model based systemsadd language facilities to a new data model.

e.g O2, ODMG


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)


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

Documents

1 Advanced Databases – Lecture # 11 Object-Oriented Databases Advanced Databases Object Oriented Databases School of Informatics Akhtar Ali