Prof. Sin-Min Lee
Department of Computer Science

• 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

• The
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
that include graphics, audio information and animation.

• 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

• 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

• Data and procedures bound together form an Object
• Data is no longer passive
• The object can act on itself (recursive)

•
Object Identity (OID)
•
Attributes (Instance variables)
•
Object State
•
Messages and Methods
•
Encapsulated Structure
– The ability to hide the object ’ s internal details

•
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

• Superclasses
• Subclasses
• Inheritance
– Single
– Multiple

•
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

• Simple object
• Composite object
• Compound object
• Hybrid object
• Associative object

Instance variables
PERSON
NAME S
ADDRESS S
DOB S
SEX S
AGE I
Object Instances
John Smith
123 Easy St
23-Nov-1970
M
32

NAME
FIRST_NAME S
MIDDLE_NAME S
LAST_NAME S
ADDRESS
STREET_NUM S
STREET S
APARTMENT S
CITY S
STATE S
ZIP I
DOB
DAY I
MONTH I
YEAR I

Employee
PERSON
SuperClass
Student Subclasses

Customer
SS#
Name
Address
Balance
Cred_Lim
Sales_Rep 1
Sales_Rep
Name
Address
Tot_Comm
Com_Rate
Customer M

Manufacturer
Code
Name
Address
Contact:
Person 1
Items:
Item M
Item
Code
Description
Quantity
Unit_Price
Manufacturers:
Manufacturer M

‘
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. ‘

Attributes RDBMS
Item_Type Numeric
Description Char
Vendor Numeric
Weight Numeric
Price Numeric
Instance variables OODB
Item_Type Inv_Type
Description String_of_char
Vendor Vendor
Weight
Price
Weight
Money

OODBMS
Object-Oriented
Features
OO Concepts
OO data models
OOPL
GUI
Conventional
DBMS
Data accessibility
Persistence
Backup and Recovery
Transaction Processing
Concurrency
Security/Integrity
Administration

• 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

• 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

• 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)

• 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

• 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

• 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)

• 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

• 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

• 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

• 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 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 )

• 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

• 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

• 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

• 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

• 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

• 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

• 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

• 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

•
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

• 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

• 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

• 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

• 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 represent an n-tuple

• 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

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

interface 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);
};

class 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();
};

( class Professor extends Employee extent professors)
{ attribute enum Rank {full, associate, assistant} rank; relationship set<Section> teaches inverse Section::is_taught_by;
};

• 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

• ObjectStore …………
.. Object Design, Inc.
• Objectivity/D …………
Objectivity Inc.
• Versant OODBMS …
. Versant Corp
• ONOS*Integrator …
.ONTOS, Inc
• FastObjects ……………
.. Poet Software

• 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

• 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?

• 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

• 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