Object Oriented Database Management Systems

Dr.A.Kannan Professor Dept of CSE, CEG Anna University Kannan@annauniv.edu

Database Evolution

What is an OODBMS?
Database incorporating object-oriented programming features.
Most significant characteristic
Combining object-oriented programming technology with database for an integrated application development system.

Marriage of object-oriented programming and database technologies.

Object Orientation Weds DBMS

Proposed Required Characteristics of OODBMS

DBMS
Persistence Secondary storage management Concurrency Recovery Ad hoc query facility

Object-oriented system
Consistency with OO programming languages. Complex objects Object identity Encapsulation Classes or types Inheritance Overriding with late binding Extensibility Computational completeness
5

DBMS Requirements
Persistence
Ability of data to survive execution of processes for reuse

Secondary storage management

Index management, data clustering, data buffering, access path selection and query optimization; transparent to user. Independence between logical and physical levels of system.

Concurrency
Accommodate multiple simultaneous users of database.

Recovery
Coherently recover data from hardware or software failures.

Ad hoc query facility

Allowance of simple queries of database by users.
6

OO Requirements 1 - 4
Complex objects
Not easily identified; typically in many-to-many relationships.

Object identity
Objects exist independent of their value.

Encapsulation
distinguish between object implementation and interface.

Classes or types
Set of objects with common attributes.

OO Requirements 5 - 6
Inheritance
Common attributes and operations inherited from parent class
4 types: substitution, inclusion, constraint, specialization.

Overriding, overloading, & late binding

Operations defined at type level
Overriding - redefine the operation for each sub-type. Overloading single/same name denoting different programs for each sub-type. Late-binding operations translated into specific program at run-time vice compile time.
8

OO Requirements 7 8
Extensibility
A method exists to define new object types. No distinction in usage between systemdefined types and user-defined types.

Computational completeness
Any computable function can be expressed using the DML of the database system.
9

Proposed Optional Characteristics of OODBMS 1 - 2

Enhance system, but not required.
Multiple inheritance
Child node inherits attributes and operations from multiple parent nodes. No consensus on multiple inheritance in OO community.
Pro: powerful, increased flexibility. Con: increase model complexity, inheriting same-name or incompatible attributes or services.

Type checking and inferencing

Degree of declaring and validating types or classes.
10

Proposed Optional Characteristics of OODBMS 3 - 5

Distribution
Distributed database decision irrelevant to OO methodology.

Design transactions
Support for transaction model of business databases.

Versions
Most new applications involve design activities requiring versioning.
11

Proposed Open Characteristics of OODBMS

Designer or developer can choose options.
Programming paradigm
Choice of which programming method(s) to use.

Representation system
Types available of representing objects in system.

Type system
Formation of types.

Uniformity
Storage of types, objects, methods. User view of type, objects, and methods.
12

Switch To Object-Oriented Database?

When might a switch become necessary?
Lack of unique identification of data.
Data lacking unique identifications like feelings, sounds etc.

Frequent use of type codes

Common way of data classification in a relational schema.

Large potential of many-to-many relationships

Books and authors: one author of several books or several coauthors of one book.

13

Hybrid Object-handling Systems

Relational DBMS Object Systems
Tuples converted to objects upon retrieval from database. Objects converted to tuples upon storage in database. Typically high development and performance costs. Many simultaneous users, but data complexity is very low.

Object-Relational Mapping Systems

Reduced development costs relative to Relational DBMS Object Systems
Conversion of tuples and object already done. Tuples mapped to objects, and vice versa.

Major potential problem

Lot of data requires conversion, yet only used for short time. Longer usage time would reduce performance costs.
14

Hybrid Object-handling Systems

Products that use Object Manager DBMSs
Slightly more efficient handling of complex data
Objects are stored directly on disk.
Transparent integration with object programming languages.

Higher performance, lower development costs. Somewhat limited handling of complex data.

Object-Relational DBMSs
Combines both Relational DBMS and Object-Oriented DBMS.
Stores both objects and tuples in DBMS. Advantages and disadvantages of both systems.

15

OOD-RBMS Project Architecture

16

Mapping an Object to a RDBMS

17

Mapping Classes for Inheritance

18

Current Commercial OODBMS

Objectivity/DB ONTOS DB VERSANT ObjectStore GemStone ObjectStore PSE Pro IBM San Francisco

19

Where is OODBMS currently used?

Computer Integrated Manufacturing (CIM). Computer Aided Design (CAD). Computer Aided Manufacturing (CAM). Computer Aided Software Engineering (CASE) tools. Advanced office and factory automation systems. Hospital patient care tracking systems.
20

Evolution of OODBMS

21

Object Database Management Group (ODMG)

Special interest group to develop standards that allow ODBMS customers to write portable applications Standards include:
Object Model Object Specification Languages
Object Definition Language (ODL) for schema definition Object Interchange Format (OIF) to exchange objects between databases

Object Query Language

declarative language to query and update database objects

Language Bindings (C++, Java, Smalltalk)

Object manipulation language Mechanisms to invoke OQL from language Procedures for operation on databases and transactions

22

Object Oriented Databases

Evolved as persistent Object Oriented Programming Languages: Start with an OO language (e.g., C++, Java, SMALLTALK) which has a rich type system Add persistence to the objects in programming language where persistent objects stored in databases

23

Persistence
Objects created may have different lifetimes:
transient: allocated memory managed by the programming language runtime system.
E.g., local variables in procedures have a lifetime of a procedure execution global variables have a lifetime of a program execution

persistent: allocated memory and stored managed by ODBMS runtime system.

Classes are declared to be persistence-capable or transient. Different languages have different mechanisms to make objects persistent:
creation time: Object declared persistent at creation time (e.g., in C++ binding) (class must be persistent-capable) persistence by reachability: object is persistent if it can be reached from a persistent object (e.g., in Java binding) (class must be persistentcapable).

24

Persistent Object-Oriented Programming Languages

Persistent objects are stored in the database and accessed from the programming language. Classes declared in ODL mapped to the programming language type system (ODL binding). Single programming language for applications as well as data management.
Avoid having to translate data to and from application programming language and DBMS
efficient implementation less code

Programmer does not need to write explicit code to fetch data to and from database
persistent objects to programmer looks exactly the same as transient objects. System automatically brings the objects to and from memory to storage device. (pointer swizzling).

25

Challenges In Building Persistent Languages Efficient caching of objects in client address space.
Cache coherence.

In OODB data migrates to clients unlike relational client

server systems where query migrates to server. Given a large number of clients each with the cache of objects ensuring consistency of object across multiple clients is a challenge.

26

The Return of the Relations POSTGRES

Relational model evolved into ORDBMSs that include best of object-oriented concepts

The very first ORDBMS prototype built @ Berkeley

POSTGRES commercialized

Illustra

bought by

Informix IUS

Has had major impact on major commercial DBMS which have all migrated to
ORDBMS model. SQL3 supported by modern databases adapted many of the concepts developed in Postgres

27

POSTGRES Combinations
Introduced object orientation into relation DBMSs. Fundamental Concepts.
Each record has an OID. Access to data though:
query language POSTQUEL. navigation through OIDs.

Classes:
Inheritance: Types: rich set of types available for columns. Functions: can be called within POSTQUEL.

28

Classes And Inheritance

Class analogous to relation User can create new class
create Emp (name = c12, salary = float, age = int)

Classes can inherit from others

create Salesman (quota = float) inherits Emp Multiple inheritance permitted. If new class causes ambiguity it is not created.

Classes:
real: base classes or relations derived: views version: maintained differentially compared to parent class

29

Types In POSTGRES
Standard base types
float, int, charac. Strings, etc. Abstract data type (ADT) facility to create new base types

e.g.;

crate type point (x = int, y = int) create type polygon

ADTs can be used in class definitions.

Crate Dept( dname = c10, mgr = c12, floorspace = polygon mailstop = point )

mailstop

30

Other Features Of POSTGRES

Allowed creation of new indices by user. To an extent pioneered the approach of extensible database technology. Where is prevalent with vendors today Supported transitive closure in query. Remove* init ans (paarent. older)

from a in answer where. Parent. younger = John or parent. younger = a. older Supported rules
31

POSTQUEL functions with class as argument

define function neighbors (Dept) returns Dept as retrieve (Dept. all) where Dept. floor = $. floor retrieve (Dept. name) where neighbors (Dept). name = Shoe

32

POSTQUEL Functions
Any collection of commands in POSTQUEL.
query = POSTQUEL function. define function high-pay returns Emp as retrieve (Emp. all) where Emp. salary > 50k

POSTQUEL function with parameters.

define function Sal-lookup (c12) returns float as retrieve (Emp. Salary) where Emp. name = $1

Usage of POSTQUEL function

retrieve Emp. name where Emp. Salary = Sal-lookup (Joe)
33

Operators
Arbit C-functions are not optimized by query optimizers.
Special functions - operators can utilize indexes for their evaluation.

Operator: function with 1 or 2 operand

retrieve (Dept. name)
Area Greater Than where Dept. floor space-AGT (0,0), (1,1), (0,2)

Index (e.g.; B-tree) defined properly can be used to speed up evaluation of operators such as AGT.

34

Functions In POSTGRES
Three types: (1) C functions
(2) Operators (3) POSTQUEL functions

C-functions
any C-function over base types or composite type
retrieve (Dept. name) where area (Dept. floorspace) > 500

retrieve (Emp. name)

where overpaid (Emp)

Function over a class or method

35

Composite Types In POSTGRES

POSTQUEL:
Composite types accessed via path expressions, using nested dot notation. remove (Emp mgr age)

where (Emp name = joe)

Prevents having to specify a join.

36

Composite Types In POSTGRES

Attributes can have a class name as a type resulting in complex objects with structure.
Create Emp ( name = c12,

salary = float [c12],

age = int, mgr = Emp, coworker = Emp
Refers to 0 or more references of Emp class.

A set type that can hold elements of

Add to Emp (hobbies = set)

Could be elements of anyclass any class.

37

Types In POSTGRES
Array type (constructor)
crate Emp ( name = c12, salary = float [12], age = intSalary for each month. )

POSTQUEL query
retrieve (Emp name)

where (Emp salary [4] = 1000)

Array in query usage.

38

Conclusion
OOP festures DBMS features AI features to get Intelligent Databases

39