Object Oriented Database Systems

1.1 Modern Database Applications involve complex, specialised data structures

1.2 Characteristics of Design Applications

1.3 What Object-Oriented Design is good at:

cf. OODB System Manifesto (Atkinson et al., 1989)

1.4 What Relational Databases are good at:

cf. OODB System Manifesto (Atkinson et al., 1989)

1.5 Requirements of Modern Database Applications

If only relational databases were used, then the complex data structures and the type system would have to be maintained by external programs. These would have to be specially written for each new application.

If object oriented programming languages (without databases) were used, then special procedures would have to be written to store, access, navigate and query the data. Storage management, concurrency and recovery mechanisms would have to be specially written for each new application.

1.6 Relational Database Issues:

Because the relational model is so simple, relational databases ...

But users cannot ...

Users must explicitly ...

Because SQL is not computationally complete ...

1.7 Semantic Data Models

2.1 Object identity (O2)

Entities may not have identifiers:

2.2 Examples

1> a:= 5

2> b:= 5

3> c:= a

4> a:= 6

5> b:= "Hello World"

2.3 Examples - continued

2.4 Identity versus Value (or State)

The Relational Model is Value-Based:

2.5 Object Identity

Object Identifiers ...

2.6 Object Sharing


In Relational Databases:

Object Identity implies:

2.7 Advantages of Object Identity:

But the system has more to do:

3.1 Complex Objects (O1)

Complex objects are built from simple objects using constructors:

3.2 Object Description

Attributes vs. Properties Attribute Values

Attribute Domain

Class Attributes

3.3 Association and Aggregation

Association: is-associated-to relationship

Aggregation: has-attribute and is-part-of relationships

3.4 Operations for Complex Objects

3.5 Sharing Revisited

Sharing parts is dangerous if parts do not have independent existence!

 independent (own existence)dependent (no own existence)
sharable e.g. module, class e.g. public method
not sharablee.g. private classe.g. private method

4.1 Encapsulation (O3)

2 Levels in Object-Oriented Programming:

-> encapsulation, logical data independence

2 Levels in Relational Databases:

-> data independent from programming

4.2 Encapsulation: Pros and Cons



4.3 Overriding, Overloading and Late Binding (O6)

-> hides complexity from application programs

4.4 Computational Completeness (O7)

4.5 Extensibility (O8)

5.1 Types or Classes (O4)

Types (e.g. C++, Java)

Classes (e.g. Smalltalk)

5.2 Natural Types versus Role Types

natural types: e.g. gender, species

role types: e.g. role of employee, customer, family relationships

5.3 Classes/Types: Pros and Cons



6.1 Class Hierarchy

Hierarchy of Classes, Subclasses and Superclasses


6.2 Multiple and Flexible Hierarchies

6.3 Inheritance (O5)

Attribute Inheritance

Complexity of Inheritance

Degree of Inheritance

6.4 Types of Inheritance

6.5 Pros and Cons of Inheritance



6.6 OO Typing System

Can't build a type system with all 4, can choose any 3 - which ever are the most important

7.1 Comparison

Why is it useful
Why is it difficult
How is it implemented in
Object-Oriented Programming
How is it implemented in
Relational Databases
O1 complex objects modularity,
object sharing
operations needed attributes, constructors only system-defined
types (e.g. date)
O2 object identity consistency system must
maintain it
object ID keys,
referential integrity
O3 encapsulation extensibility
software engineering
no ad hoc queries
implementation, specification data separate from program
O4 types or classes modularization,
role types,
is implemented tables, no methods,
no pointers
O5 inheritance code reutilisation name conflicts
attribute and method
O6 overriding,
overloading and
late binding
for user
no compile time
type checking
via class hierarchy ---
O7 computational
Church Turing
--- is complete needs programming
O8 extensibility hide complexity optimization user defined types ---
D1 persistence easier for programmer difficult for
complex structures,
some data must
be transient
--- is implemented
D2 storage
easier for programmer --- memory allocation is implemented
D3 concurrency multiple users many possible application programs threads is implemented
D4 recovery stability, security many possible application programs --- is implemented
D5 ad hoc
query facility
direct data access difficult for
complex structures
--- is implemented

7.2 Summary