Onject-oriented Database

Prof. Sin-Min Lee

Department of Computer Science

History of data models:

Weaknesses of RDBMSs

Weaknesses of RDBMSs Poor Representation of “Real World” Entities

– Normalization leads to relations that do not correspond to entities in “real world”. Semantic Overloading

– Relational model has only one construct for representing data and data relationships: the relation. – Relational model is semantically overloaded.

Poor Support for Integrity and Enterprise Constraints Homogeneous Data Structure

– Relational model assumes both horizontal and vertical homogeneity. – Many RDBMSs now allow Binary Large Objects (BLOBs).

Limited Operations– RDBMs only have a fixed set of operations which cannot be extended.

Weaknesses of RDBMSs

Weaknesses of RDBMSs Difficulty Handling Recursive Queries

– Extremely difficult to produce recursive queries.– Extension proposed to relational algebra to handle this type of query is unary transitive (recursive)

closure operation. Impedance Mismatch

– Most DMLs lack computational completeness. – To overcome this, SQL can be embedded in a high-level 3GL.– This produces an impedance mismatch - mixing different programming paradigms. 30% of

programming effort and code space is expended on this type of conversion. Other Problems with RDBMSs

– Transactions are generally short-lived and concurrency control protocols not suited for long-lived transactions.

– Schema changes are difficult. – RDBMSs are poor at navigational access.

Object-Oriented Concepts

Object-oriented conceptsTo start with, a brief review of underlying themes…

Abstraction: Process of identifying essential aspects of an entity and ignoring unimportant properties. - Concentrate on what an object is and what it does, before deciding how to implement it.

Encapsulation: Object contains both data structure and set of operations used to manipulate it.

Information Hiding: Separate external aspects of an object from its internal details, which are hidden from outside.

– Allows internal details of object to be changed without affecting apps that use it, provided external details remain same.

– Provides data independence.

Object-Oriented Concepts

Objects and AttributesObject: Uniquely identifiable entity that contains both the attributes that describe the state

of a real-world object and the actions associated with it.– Definition very similar to ‘entity’, however, object encapsulates both state and behavior; – an entity only models state.

Attribute: Contain current state of an object.

Attributes can be classified as simple or complex. Simple attribute can be a primitive type such as integer, string, etc., which takes on literal values. Complex attribute can contain collections and/or references. Reference attribute represents relationship. complex object: contains one or more complex atts

Object-Oriented Concepts

Object IdentityObject identifier (OID) assigned to object when it is created that is:

– System-generated.– Unique to that object.– Invariant.– Independent of the values of its attributes (that is, its state).– Invisible to the user (ideally).

Advantages: •They are efficient.•They are fast.

•They cannot be modified by the user. •They are independent of content.

- RDBMS: object identity is value-based, primary key provides uniqueness.- Primary keys do not provide type of object identity required in OO systems:

–key only unique within a relation, not across entire system–key chosen from atts of relation, making it dependent on object state.

Object-Oriented Concepts

Methods and messagesMethod: Defines behavior of an object, as a set of encapsulated functions.

Message: Request from one object to another asking second object to execute one of its methods.

(a)

(b)

(a) Object showing atts and methods(b) Example of a method

Object-Oriented Concepts

ClassesClass: Blueprint for defining a set of similar objects.

-Objects in a class are called instances.

-Class is also an object with own class attributes and class methods.

Object-Oriented Concepts

Subclasses, Superclasses and inheritanceInheritance allows one class of objects to be defined as a special case of a more

general class.

Special cases are subclasses and more general cases are superclasses.

Generalization: process of forming a superclass Specialization: forming a subclass •Subclass inherits all properties of its superclass and can define its own unique properties. •Subclass can redefine inherited methods. •All instances of subclass are instances of superclass. •Principle of substitutability: instance of subclass can be used whenever method/construct expects instance of superclass.•A KIND OF (AKO): Name for relationship between subclass and superclass

4 Types ofinheritance: 1. single2. multiple3. repeated 4. selective

Types of inheritance

(a)

(b)

(c)

(a) Single(b) Multiple(c) Repeated

(b)

Overriding and overloadingOverriding: Process of redefining a property within a subclass.

Overloading: Allows name of a method to be reused with a class or across classes.

Overriding Example:Might define method in Staff class to increment salary based on commission

method void giveCommission(float branchProfit) {

salary = salary + 0.02 * branchProfit; }

May wish to perform different calculation for commission in Manager subclass:

method void giveCommission(float branchProfit) {

salary = salary + 0.05 * branchProfit; }

Polymorphism and dynamic bindingPolymorphism: Means ‘many forms’.

Three types:

1. operation

2. Inclusion

3. parametric.

Dynamic Binding: Runtime process of selecting appropriate method based on an object’s type.

Example: With list consisting of an arbitrary no. of objects from the Staff hierarchy, we can write: list[i]. print

and runtime system will determine which print() method to invoke depending on the object’s (sub)type.

Complex ObjectsComplex Objects: An object that consists of subobjects but is viewed

as a single object.

•Contained object can be encapsulated within complex object, accessed by complex object’s methods.

•Or have its own independent existence, and only an OID is stored in complex object.

•Objects participate in a A-PART-OF (APO) relationship.

Storing objects in relational databases

Storing Objects in Relational Databases

One approach to achieving persistence with an OOPL is to use an RDBMS as the underlying storage engine.

Requires mapping class instances (i.e. objects) to one or moretuples distributed over one or more relations.

To handle class hierarchy, have two basics tasks to perform:(1) design relations to represent class hierarchy;(2) design how objects will be accessed.

Storing objects in relational databases

Storing Objects in Relational Databases

Sample inheritancehierachy for staff

Storing objects in relational databases

Mapping classes to relationsNo. of strategies for mapping classes to relations, although each results in a loss of semantic information.

1. Map each class or subclass to a relation:Staff (staffNo, fName, lName, position, sex, DOB, salary)Manager (staffNo, bonus, mgrStartDate)SalesPersonnel (staffNo, salesArea, carAllowance)

2. Map each subclass to a relationManager (staffNo, fName, lName, position, sex, DOB, salary, bonus, mgrStartDate)SalesPersonnel (staffNo, fName, lName, position, sex, DOB, salary, salesArea, carAllowance)

3. Map the hierarchy to a single relationStaff (staffNo, fName, lName, position, sex, DOB, salary, bonus, mgrStartDate, salesArea, carAllowance, typingSpeed, typeFlag)

Next Generation Database SystemsFirst Generation DBMS: Network and Hierarchical

–Required complex programs for even simple queries.–Minimal data independence.–No widely accepted theoretical foundation.

Second Generation DBMS: Relational DBMS–Helped overcome these problems.

Third Generation DBMS: OODBMS and ORDBMS.

Object-oriented databases

Object-oriented database = a database constructed by applying the object-oriented paradigm– Each data entity stored as a persistent object– Relationships indicated by links between objects– DBMS maintains inter-object links

The associations between objects in an object-oriented database

OODB 

Some people felt the word object-oriented is too close to OOPL

ODB is more generic

Different approaches to designing ODB

1. Applications written in extension of existing OOPL (1st generation OODB)

language, compiler, execution environment, etc. extended to incorporate 

– DB functionality – store and manage objects created by OOPL 

Selling point - unified programming and DB language but need query optimization, etc. 

– Gemstone (Smalltalk), Poet (C++)

Designing cont’d

2. Extend relational DB to include OO features:

OID, type hierarchy, inheritance, encapsulation, arbitrary data types, nested objects, etc.

Already familiar with DBMS but performance decreased  

Postgres - extended Ingres, Oracle

Designing cont’d

3. Start entire process from scratch (next generation?)

unify relational and OO system  

Object Data Model

Bring concepts of OOPL into DB systems– Object corresponds to real-world object– Object is data and behavior, object has attributes

and operations– Data object has OID - immutable– Group data objects into classes - abstract

mechanism, share same structure and behavior

ODM

Class has:– instances– methods and data - encapsulation for information hiding -

access only through methods– composite classes - composed of multiple types– nested objects - contains another object– complex objects - set of objects      – class hierarachy (ISA) – specialization - define new classes

from existing ones– inheritance of attributes and methods - reuse

ODM

Completeness DBS needs to be computationally complete

(Turing) SQL not computationally complete - unless

embedded SQL - impedance mismatch, since sets

connections with DML and OOPL in ODB more acceptable

ODM

Add features such as: – concurrency – recovery – schema evolution– Versions– What about query language?– Performance?

ODM

Object identity OID correspondence between real-world and

database objects used to refer to objects in application

programs and in references between objects (relationships) 

unique identity to each independent object

OID vs. primary key

identity based vs. value-based unique over entire DB and even over distributed DB (if primary

key changes, still same real-world object) immutable - values of OID for object should not change

- OID not assigned to another object

- not dependent on any attribute values

- not use physical address       system generated OID not visible to user

Advantages of object-oriented databases

Matches design paradigm of object-oriented applications

Intelligence can be built into attribute handlers– Example: names of people

Can handle exotic data types– Example: multimedia

Can store intelligent entities

Desires of the software industry

More functionalityLess codeReduced internal complexityStandard interfacesReduced duplication of effort

Hope with Objects

Objects have been shown to satisfy all five of these desires…

Objects satisfy desires…

Development effort is reduced– 2 to 1 reductions are common– 5 to 1 frequent– 20 to 1 possible with relevant libraries

Continued…

Objects satisfy desires

Projects tend to meet specs 3 to 1 reduction in control flow complexity Messages allow clean interfaces Objects promote reusability (6 to 1)

Traditional Development

Real World Design Implementation

model developed by designers gets lost in implementation

Developing with Objects

Real World DesignImplementation

Design and implementation model directly reflect real world

Design remains visible in source code

Code Reuse Statistics

Project Total Code

New Code

% Reuse Savings

HPMS 3,926K 1,960K 50% $117,000

OSA 1,950K 327K 83% $119,000

SPC 1,815K 130K 92% $248,000

Profit 1,940K 412K 78% $80,000

Benefits: Reuse

Benefits: Bulk Reduction

Benefits: Quality Improvement

Objects in a Nutshell…

1. Objects encapsulate data within the set of procedures which can access that data.

2. Programming is done by requesting an object to perform some desired behavior.

Objects in a Nutshell…

3. Objects determine at run-time the particular procedure to execute in response to a request.

4. Objects are grouped into classes which describe the common structure and behavior of that class of objects.

Objects in a Nutshell

5. Classes are organized hierarchically in order to factor out generic capabilities; thus, eliminating redundancy.

6. Programmers no longer write programs; they develop models of their application or system environment using classes.

Objects Encapsulate Data

message procedures procedures

Objects encapsulate their local data within procedures which have access to that data

data data

Instances

Every object is an instance of a generic class of objects

An instance describes a single concept or models a real world entity

Classes of Objects

A class contains – Class’ data template– Class’ available procedures

Relating an Object to its Class

inherits

from

Object Class

name

Unique Data

Values

DataTemplates

+Procedures

Dynamic Binding

Objects determine at run-time which procedure to execute

The cost is more modest than expected; thus viability of Smalltalk.

Time critical applications can combine dynamic and static binding as required (in hybrid languages).

Objects Share Classes

inherits

from

Object Class

name

UniqueData

Values

Data Templates

+Procedures

Classes Inherit Classes

A class has state information and performs predefined functions

A subclass may add or alter the function or state defined in its superclass(es).Integer

Number

Object

Lineage of Object Languages

Modula Eiffel

Pascal

Ada C++

C Objective-C

Smalltalk/V

Algol Simula Smalltalk

Actor

Lisp Loops CLOS

Inheritance

Often shown using a hierarchy diagram

Implies that integer is a subset of Number which is a subclass of the Object class

Data and procedures are inherited from superclasses

Object

Number

Integer Real

The Power of Inheritance

Powerful capabilities can be developed near the root of the inheritance tree

The root of the tree is the Object class which includes methods such as:

size: size in bytes of any objectstoreOn: to store on diskcopy: to make a copy of any

object in memory

Features / Benefits…

Encapsulation Behavior without the burden; reduces side effects

Message passing Incapsulates user from the implementation

Inheritance Code bulk reduction; modification by specialization

continued…

Features / Benefits

Dynamic binding Replaceable components; enables iterative development

Classes Packaging systems into domain

meaningful components

Modeling language Readability of code; code reflects real world being modeled

Pure Object Environments

Smalltalk-80 from ParcPlace Systems

Smalltalk/V from DigitalkActor from Whitewater Group

Objective-C

A small language which allows details of C to be hidden

Default is dynamic; static binding also available

Interpreter and libraries are available

C++

A large but direct extension to CDefault is static binding; dynamic

also availableMinimizes time and space

Failures with OOP

Designs with too fine grained use of objects

Performance – a design failureBleeding edge – select tools

carefullyMemory cannot be ignored

Futures

Visual programming techniques will become commonplace

Objects may provide the long awaited key to effective distributed processing – enormous computing power now sits idle on desktops

Object oriented databases will become commercial products in the 2000’s

Conclusions

Objects will change the way software is built, sold and used

Objects will take as long as semiconductors to become pervasive