Object Oriented Databases Advanced Database Technologies

1
Object Oriented DatabasesAdvanced Database
Technologies

• School of Informatics
• by Dr. 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 3rd Edition, 2000, Chapter 11
  12

3
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 (e.g. name, address, birthDate
  of a Person)
• Behaviour operations (e.g. 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 usually 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.

11
The Conceptual Schema in UML
12
OO Representation
class Lecturer ISA Person properties room
Integer tutees set(Student) worksFor
Department teaches set(Unit)
operations teachUnit(U Unit) Boolean end
Lecturer
class Person properties name
String address String birthDate Date
operations age() Integer end Person
class Course properties name
String offeredBy Department hasStudents
set(Student) hasUnits set(Unit) end Course
class Unit properties name String code
String takenBy set(Student) taughtBy
set(Lecturer) partOf set(Course) end Unit
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
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 dont.
• 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 dont.
• 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 dont.
• 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 models 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 -gt
ObjectStore, Gemstone,POET
Semantic Data Models e.g. ER, UML, FDM -gt
OpenODB, ODBII
Model based systems add language facilities to a
new data model. e.g O2, ODMG
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