Object oriented DataBase

Prof. Sin-Min Lee

Department of Computer Science

Object Database Systems

• Not a new concept – research dates back to the mid-1970s

• As the technology matured, a number of commercial ODBMSs appeared in the 80s and early 90s

• To compete with RDBMSs, it became clear that a standard for ODBMSs, analogous to SQL, was needed

Object-Oriented and Multimedia Databases

• The object-oriented database (OODB) contains both the text data of traditional databases plus information about the set of actions that can be taken on the data fields.

• Many OODBs are multimedia databases that include graphics, audio information and animation.

Object Orientation

• Modeling and development methodology

• A set of design and development principles based on objects

• Objects – self-contained, reusable modules that contain data as well as their procedures

OOP – Object oriented Programming

• OO concepts in Ada, Algol, LISP, SIMULA• OOPLs – Smalltalk, C++, Java• Provide for –

– SW development environment– SW modeling tool– Reduce the amount of code– Reusable code

Objects

• Data and procedures bound together form an Object

• Data is no longer passive

• The object can act on itself (recursive)

OOP Terminology

• Object Identity (OID)

• Attributes (Instance variables)

• Object State

• Messages and Methods

• Encapsulated Structure – The ability to hide the object’s internal details

OOP Terminology• Object Class

– the logical structure of an object (name, attributes, methods)

• Object Class Library – a group of object classes

• Object– an instance of an object class

• Protocol – – collection of messages

OOP Terminology

• Superclasses

• Subclasses

• Inheritance– Single – Multiple

OOP Terminology

• Polymorphism – situation in which one name can be used to invoke

different functions

• Inheritance – automatically assuming the attributes and methods of

another object at a higher class

Object Classification

• Simple object

• Composite object

• Compound object

• Hybrid object

• Associative object

OOP Example

PERSONNAME SADDRESS SDOB SSEX SAGE I

Instancevariables John Smith

123 Easy St23-Nov-1970M32

Object Instances

Instance VariablesADTs

NAMEFIRST_NAME SMIDDLE_NAME SLAST_NAME S

ADDRESSSTREET_NUM SSTREET SAPARTMENT SCITY SSTATE SZIP I

DOBDAY IMONTH IYEAR I

PERSON

Employee Student

SuperClass

Subclasses

Representing 1:M Relationships(Premiere Products Example)

CustomerSS#NameAddressBalanceCred_Lim

Sales_Rep 1

Sales_RepNameAddressTot_CommCom_Rate

Customer M

Representing M:M Relationships

Manufacturer CodeNameAddressContact:

Person 1

ItemCodeDescriptionQuantityUnit_PriceManufacturers:

Manufacturer MItems:

Item M

Late Binding

‘A desirable characteristic of OO development is its ability to let any object’s attribute contain object that define different data types (or classes) at different times. ‘

Late binding

Attributes RDBMSItem_Type NumericDescription CharVendor NumericWeight NumericPrice Numeric

Instance variables OODBItem_Type Inv_TypeDescription String_of_charVendor VendorWeight WeightPrice Money

OODBMS

OODBMS

Object-OrientedFeatures

Conventional DBMS

OO ConceptsOO data modelsOOPLGUI

Data accessibilityPersistenceBackup and RecoveryTransaction ProcessingConcurrencySecurity/IntegrityAdministration

13 Rules for an OODBMSfrom the OODBS Manifesto

• System must support complex objects

• Object identifier must be supported

• Objects must be encapsulated

• Systems must support types or classes

• System must support inheritance

• System must avoid premature binding

• System must be computationally complete

• System must be extensible

Object Database Systems

• The vendors formed a consortium, the Object Database Management Group (ODMG), to define a standard

• Current standards specification is ODMG 2.0

• Architecture has four major components – a data model, a specification language, a query language, and language bindings

Object Data Model

• Based upon the (Object Management Group) OMG Object Model

• OMG is another consortium of vendors instituted to create standards

• Besides an object model, they oversee standards for UML and CORBA (Common Object Request Broker Architecture)

Object Model

• Two basic modeling primitives – objects and literals

• An object has a unique identifier

• A literal has no identifier

• Every object and every literal is categorized by its type – a set of values and a set of supported operations

Object Model

• An object’s state is characterized by a set of properties

• An object property can be either an attribute or a relationship to another object

• The set of operations that can be executed on or by an object defines the behavior of an object

Object Model

• An operation may have input and/or output parameters, and may return a value

• The type of each parameter and the returned value must be specified

• A database stores objects, which can be shared by multiple users and applications

• A database is based on a schema, defined in the object definition language (ODL)

Types

• There are two facets to the definition of a type – an external specification and one or more implementations

• The specification of a type corresponds to what is visible to a user – operations that can be applied to instances, its properties, or state variables, and any exceptions that can be raised by the operations

Types

• An implementation of a type defines the internal aspects of the objects of a type – how the operations access or modify the properties of an object

• A class definition and an interface definition may specify both the abstract behavior and the abstract state of an object

Types

• A literal definition specifies only the abstract state of a literal type

• An implementation of an object type consists of a representation and a set of methods

• The representation is a data structure realizing the abstract state of an object or literal, expressed in a language binding

Types

• Each property is represented by an instance variable

• The operations of an object type are implemented as procedures expressed in a language binding

• The internal details of an implementation are invisible to the user

Inheritance

• Inheritance is a second important characteristic of object orientation

• The data model supports two constructs supporting inheritance – interfaces and classes

• Interfaces permit the definition of subtypes• A subtype represents the specialization of a

more general type (the supertype)

Inheritance

• The generalization/specialization relationship is often called an “is-a” relationship

• Interfaces are abstract types – they cannot be instantiated

• The data model supports multiple inheritance of interfaces

Inheritance

• Classes support a second form of inheritance, described as the “extends” relationship

• A class can extend the behavior and state of another class

• Classes can be instantiated

• An object is an instance of a class

Inheritance

• Classes support only single inheritance

• An interface can inherit from another interface, but not from a class

• A class can inherit from multiple interfaces and can extend a single class

• Objects have a number of characteristics – identifiers, names, lifetimes, and structures

Identifiers

• Unlike the relational model, objects within a database are assigned unique identifiers

• An identifier is generated by the database system when the object is created

• They are immutable – although the properties of a object may change, its identifier remains the same throughout its lifetime

Names

• Object identifiers are commonly used for one object to refer to another

• An object may also have a name

• Applications typically refer to some objects by a user-defined name

• The database internally maps names to identifiers

Lifetimes

• The lifetime of an object is specified when it is created

• The are two possible lifetimes – persistent and transient

• A transient object is allocated memory by an application’s runtime system

• A transient object’s lifetime is the lifetime of the procedure or process that creates it

Lifetimes

• Persistent objects are allocated memory and secondary storage that is managed by the ODBMS runtime system

• A persistent object exists after the process that created it terminates

• Persistent objects also called database objects

• Object types and lifetimes are independent

Collection Objects

• The data model supports a number of container types to store collections of objects

• All elements of a collection must be of the same type

• Set object – an unordered collection with no duplicates

Collection Objects

• Bag object – an unordered collection that may contain duplicate objects

• List object – an ordered collection of elements

• Array object – another kind of ordered collection of objects

• Both lists and arrays are position-oriented

Collection Objects

• The insertion and removal operations take argument specifying the position at which the element is to be inserted or deleted

• Both collections are zero-based• Removing an element from a list changes

the positions of elements in the list tail• Removing an element from an array simply

replaces the element with a null value

Modeling an Object’s State

• Two kinds of properties – attributes and relationships

• An attribute is defined to be of a single type• Its type may be either a literal or a class• Relationships define associations between

two types• The data model supports only binary

relationships

Modeling an Object’s State

• Relationships are defined implicitly by specifying traversal paths

• Traversal paths are always declared in pairs

• This permits bidirectional traversal from either object in the association

• The ODBMS is responsible for maintaining the referential integrity of a relationship

Modeling an Object’s State

• The connectivity of a relationship may be one-to-one, one-to-many, or many-to-many

• The connectivity is always clear from the syntax of the declaration of a relationship

• To represent arbitrary n-ary relationships, a designer would create a new class type, each instance of which would representan n-tuple

Object Definition Language

• The Object Definition Language (ODL) is used to define the specification of object types

• Roughly corresponds to the DDL of SQL

• A designer uses ODL to define a database schema

Structured Types

struct Address { string street; string city; string state; string zip;};

Interfacesinterface Person { attribute string name; attribute Address personAddress; relationship Person spouse

inverse Person::spouse; relationship set<Person> children

inverse Person::parents; relationship list<Person> parents

inverse Person::children; boolean marrriage(in Person newSpouse); void move(in Address newAddress);};

Classesclass Salary{

attribute float base;attribute float overtime;

};

class Employee : Person( extent employees){ attribute short empID;

attribute Salary annual_salary;void raise(in float new_base);void fire();

};

Classes

class Professor extends Employee( extent professors){

attribute enum Rank {full, associate, assistant} rank;relationship set<Section> teaches

inverse Section::is_taught_by;};

LAST 5 RULES

• System must be able to remember data locations

• System must be able to handle very large databases

• System must support concurrent users

• System must be able to recover from hardware and software

• Data query must be simple

OODBMS• ObjectStore ………….. Object Design, Inc.

• Objectivity/D ………… Objectivity Inc.

• Versant OODBMS …. Versant Corp

• ONOS*Integrator ….ONTOS, Inc

• FastObjects…………….. Poet Software

Why not use a Traditional Relational DBMS?

• The traditional Relational DBMS stores data in tables, rows, and columns

• Objects have several complex structures that cannot be represented in tables, rows, or columns.– These structures include executable statements (i.e.,

methods) and pointers

How are the Relational Database (RDBMS) Manufacturers

Responding?• The manufacturers of RDBMS are

incorporating additional features to allow for the storage of more complex items. Oracle has been particularly active in incorporating these features.– The term object-relational DBMS has been coined to

describe this classification of DBMS.

•Still developing•Lack of standards•Is there a sufficient theoretical foundation?

What’s Wrong With ODBMSs?

• Relationships among objects use object identifiers and must be explicitly designed

• Critics of the object model refer to the use of object identifiers to implement relationships as “pointer spaghetti”

• Reminiscent of the older CODASYL network model

• Difficult to perform ad hoc queries

What’s Wrong With ODBMSs?

• Vendors don’t support the ODMG standard

• Only one vendor currently supports OQL

• There is no capability to create views

• Robustness, scalability, and fault-tolerance do not measure up to RDBMSs

• Still an immature field – these problems should be corrected in the future