OO databases

1

Object Oriented databases

OO databases

2

Developing OODBMS - motivation

motivation more and more application areas require systems that offer

support (implement) for both traditional language programming and database capabilities

OO databases

3

Traditional programming languages

procedural control data abstraction functional abstraction

OO databases

4

Persistent programming languages

definition: a language that provides the ability to preserve data across successive executions of a program (or even by many different programs)

• the user can make volatile data permanent in a transparent manner (no translations are required, such as transforming data structures in file structures)

• impedance mismatch - disappears; however, if some data is available, then it is only available for a specific language

no other features beyond persistence are available• such as transaction management, concurrency control and

recovery

OO databases

5

Database systems

support a data model provide data persistence provide data sharing (includes concurrent access) provide a higher degree of reliability (includes

recovery control) support scalability support security and integrity suitable for distribution

OO databases

6

Database programming languages

incorporate features beyond persistence• transaction management, concurrency control, data recovery

database programming DB language (e.g. SQL) - computationally incomplete therefore, a DB language is usually embedded into a high

level programming language• SQL92 can be embedded in C, Pascal, Fortran, Ada ...

• communication: set of variables in the host language + call to DBMS routines (a pre-processor translates SQL statements into calls)

OO databases

7

Drawbacks of existing approaches to database programming

impedance mismatch• the programmer has to write code to translate between the host

language’s data model and the DB’s language data model

additional type-checking• while manipulated in the host language the data objects are strongly

typed; they are then stored in a traditional DBMS; they can be accessed from another language, not strongly typed! when retrieved in the host language type checks must be performed

read and write data on persistent storage• it is always the programmer’s responsibility to decide WHEN to read

and write on secondary space (for instance, when some data is required the programmer should not have to specify whether this data is to come from secondary space or from the main memory - this should be transparent at the level of the language)

OO databases

8

Cause of drawbacks

2 level storage model

persistent memory

conceptual / external

SQL

tra

nsf

orm

ati

on

s +

ty

pe

ch

eck

ing

application program

main or virtual memory

physical

OO databases

9

Possible solution

single level storage model (pointer swizzling - OID - next slide)

persistent memory

application program

main or virtual memory

OO databases

10

OO concepts

classes and instances object identity; object identifier OID

• not a pointer, but a logical identifier (an object can exist at different addresses, but the OID remains the same through the life time of the object)

hierarchies attributes methods and messages abstraction encapsulation information hiding polymorphism and dynamic binding (overloading)

OO databases

11

OO DBMS - Khoshafian and Abnous, 1990

OO DBMS = object orientation + database capabilities

OO databases

12

OO DBMS - Kim 1991

OODM (data model)• a logical data model that captures the semantics of objects

supported in OO programming languages

• NO UNIQUE DATA MODEL

OODB (database)• a persistent and sharable collection of objects defined by an

OODM

OODBMS• the manager of an OODB

OO databases

13

OO DBMS- Zdonic and Maier

definition through features provided database functionality support object identity provide encapsulation support objects with complex state

OO databases

14

OO DBMS - Parsaye, 1989

definition through features provided high level query language + optimisation capabilities support for persistent and atomic transactions support for complex object storage + mechanisms of

efficient access OODBMS = OO system + the above characteristics

OO databases

15

Strategies for developing OO DBMS (languages)

extend an existing OO language with DB capabilities provide OO DBMS libraries

• in the first approach the language is extended, whereas in the second approach a set of libraries is provided

embed OO DB constructs into a conventional language extend an existing DB language with OO capabilities

• SQL3 (Object SQL) - supported by both camps

develop a novel data model / database language

OO databases

16

Issues in OO DBMSs

transactions versioning schema evolution

OO databases

17

Transactions

support for long (duration) transaction required locking for long term - unsatisfactory

in OO DBMSs - unit of transaction = object coarser granularity may be required for efficiency

solutions versions advanced transaction models

• e.g. nested transactions

OO databases

18

Versioning

solutions to long term transactions also, required “per se” versioning

get a copy of current version in the private work space - check out

establish a given object as the current version - check in• merge distinct versions

delete / archive obsolete versions interrogate about version history of an object

OO databases

19

Schema evolution

database schema must be easily modifiable e.g. for design applications

changes needed changes to class definition (modify definitions of attributes or

methods) changes to the inheritance hierarchy changes to the set of classes (adding / deleting classes)

schema invariant rules e.g. resolution of conflicts

• e.g. precedence of subclasses over superclasses (definitions in subclass take precedence)

OO databases

20

Advantages

enriched modelling capabilities extensibility removal of impedance mismatch more expressive query language support for schema evolution support for long duration transactions applicability to advanced database applications improved performance

OO databases

21

Disadvantages

lack of a universal data model lack of experience lack of standards query optimisation compromises encapsulation locking at object level may have repercussions on

performance high complexity lack of support for views lack of support for security

OO databases

22

Towards standardisation

Object Oriented Datanase Systems Manifesto (1989) 13 mandatory features proposed

the Object Model proposed by the Object Database Management Group ODMG 2.0 adopted in September 1997 “de facto” standard