Object-Oriented Language Features:
abstract data types
inheritance
object identity
Object-Oriented Database Features:
persistence
support of transactions
simple querying of bulk data
concurrent access
resilience
security
WHY OBJECT-ORIENTED DATABASE?
Industry Trends:
Integration and Sharing
Seamless integration of operating systems,
databases, languages, spreadsheets,
word processors, AI expert system shells.
Sharing of data, information, software
components, products, computing
environments.
Referential sharing:
Multiple applications, products, or
objects share common sub-objects.
(Hypermedia links are then used to
navigate from one object to another)
Object-oriented databases allows
referential sharing through the support
of object identity and inheritance.
Fundamentals of Object-Oriented Approach
The object-oriented paradigm is illustrated below:
Objects and Identity
The following figure shows object with state and behavior. The state
is represented by the values of the object's attributes, and
the behavior is defined by the methods acting on the state of the object.
There is a unique object identifier OID to identify the object.
Complex Objects
Complex objects are built by applying constructors to simpler
objects including: sets, lists and tuples.
An example is illustrated below:
Encapsulation
Encapsulation is derived from the notion of Abstract Data Type (ADT).
It is motivated by the need to make a clear distinction between the
specification and the implementation of an operation.
It reinforces modularity and provides a form of logical data independence.
Class
A class object is an object which acts as a template.
It specifies:
A structure that is the set of attributes of the instances
A set of operations
A set of methods which implement the operations
Instantiation means generating objects,
Ex. 'new' operation in C++
Persistence of objects: Two approaches
An implicit characteristic of all objects
An orthogonal characteristic - insert the object into a
persistent collection of objects
Inheritance
A mechanism of reusability, the most powerful concept of OO programming
Association
Association is a link between entities in an application
In OODB, associations are represented by means of references between objects
a representation of a binary association
a representation of a ternary association
reverse reference
ADVANTAGES OF OODB
An integrated repository of information
that is shared by multiple users, multiple
products, multiple applications on
multiple platforms.
It also solves the following problems:
1. The semantic gap: The real world and the
Conceptual model is very similar.
2. Impedance mismatch: Programming languages
and database systems must be interfaced
to solve application problems. But the
language style, data structures, of a
programming language (such as C) and the
DBMS (such as Oracle) are different. The
OODB supports general purpose programming
in the OODB framework.
3. New application requirements: Especially in
OA, CAD, CAM, CASE, object-orientation is
the most natural and most convenient.
COMPLEX OBJECT DATA MODELS
Complex object data model is non-1NF
data model. It allows the following
extensions:
1. Sets of atomic values
2. Tuple-valued attributes
3. Sets of tuples (nested relations)
4. General set and tuple constructors
5. Object identity
Formal definition:
1. Every atomic value in A is an object.
2. If a1, ..., an are attribute names in N,
and O1, ..., On are objects, then
T = [a1:O1, ..., an:On] is also an
object, and T.ai retrieves the value Oi.
3. If O1, ..., On are objects, then
S = {O1, ..., On} is an abject.
Example:
{[Name:John, Age: 30],
[Name:Mary, Friends:{Mark, Vicki}]}
An object is defined by a triple (OID, type constructor, state)
where OID is the unique object identifier, type constructor is
its type (such as atom, tuple, set, list, array, bag, etc.) and
state is its actual value.
Example:
(i1, atom, 'John')
(i2, atom, 30)
(i3, atom, 'Mary')
(i4, atom, 'Mark')
(i5, atom 'Vicki')
(i6, tuple, [Name:i1, Age:i3])
(i7, set, {i4, i5})
(i8, tuple, [Name:i3, Friends:i7])
(i9, set, {i6, i8})
Semantic Data Models
The following figure shows different types of nodes in GSM.
The different types of links (relationships) in GSM are shown below.
A semantic model for the sales office automation example is shown below.
An entity-relationship model for the sales office automation example is shown below.
OBJECT-ORIENTED DATABASES
OODB = Object Orientation + Database Capabilities
FEATURES TO BE CONSIDERED:
persistence
support of transactions
simple querying of bulk data
concurrency control
resilience and recovery
security
versioning
integrity
performance issues
DATA MODELS TO BE CONSIDERED:
Complex object model
Semantic data model
such as Extended ER (EER) model, OPM model
NOT ALL OODB SUPPORTS SAME OBJECT-ORIENTATION,
SAME DATA MODEL AND SAME SET OF FEATURES
RESEARCH PROTOTYPES
ORION: Lisp-based system, built at MCC 1987.
Handles schema evolution and complex
object locking.
IRIS: Built at HP 1987. Functional data
model, version control, object-SQL.
Galileo: Built at Univ Pisa 1985. Strong
typed language, complex objects.
PROBE: CCA 1986.
POSTGRES: Univ. California, Berkeley 1990.
Extended relational database supporting
objects.
COMMERCIAL OODB
O2: O2 Technology.
Language O2C to define classes, methods
and types. Supports multiple inheritance.
C++ compatible.
Supports an extended SQL language O2SQL
which can refer to complex objects.
G-Base: Graphael 1987. Lisp-based
system, supports ADT, multiple
inheritance of classes.
CORBA: Standards for distributed objects.
GemStone: Servio Logic 1987, Beaverton,
Oregon. Earliest OODB supporting
object identity, inheritance,
encapsulation. Language OPAL is
based upon Smalltalk.
Ontos: Ontologic, 1988, Berlington,
Mass. C++ based system, offers C++
clients library. Ontos has a predecessor
called Vbase. Ontos model supports
encapsulation, inheritance, ability
to construct complex objects.
Object Store: Object Design Inc.
C++ based sustem. A good feature is that
it supports the creation of indexes.
Statics: Symbolics 1988. Supports
entity types, set valued attributes,
and inheritance of entity types
and methods.
COMMERCIAL OODB (continued)
SIM: Semantic Information Manager,
UNISYS 1987. Supports semantic data
model. Core system of the InfoExec
Environment of UNISYS. Uses the Semantic
Data Model of Hammer and McLeod 1981.
User can define entity types that can
inherit from one another. Attributes
of entities are like functions from
one entity to another.
Relational DB Extensions: Many relational
systems support OODB extensions.
1. User-defined functions (dBase).
2. User-defined ADTs (POSTGRES)
3. Very-long multimedia fields (BLOB or
Binary Large Object). (DB2 from IBM,
SQL from SYBASE, Informix, Interbase)
ALTERNATIVE OODB STRATEGIES
1. Develop novel database data model
or data language (SIM)
2. Extend an existing database language
with object-oriented capabilities.
(IRIS, O2 and VBASE/ONTOS extended SQL)
3. Extend existing object-oriented
programming language with database
capabilities (GemStone OPAL extended
SmallTalk)
4. Extendable object-oriented DBMS
library (ONTOS)
OODB QUERY LANGUAGE
ONTOS (from Ontologic), O2 (from O2 Technology) and IRIS
(from HP) all offer object-oriented
extension of SQL.
IRIS has Object SQL. Each entity
type specifies one or more properties.
Properties are functions that apply
to the instances of the type.
Entity types have extensions and
can inherit from one another.
Example: The type PERSON can be
created by:
Create Type Person (
Name char(20),
Age integer
Address address)
where address is another type.
In IRIS, Name, Age and Address are
called properties (functions) and
apply to instances of type Person.
OODB QUERY LANGUAGE (continued)
Object SQL Query: retrieve the name and
state of all people who are older than 21:
Select Name(p), State(Address(p)
for each Person p
where Age(p) > 21
(Here we assume address has another property
called "state")
The user can compose the function application:
P5(P4(...P1(P))...)
in the select statement.
EXAMPLE:
Employee is a subtype of Person
SalesPerson is a subtype of Employee
Addresses have street names
Salespeople have sales managers
sales managers have secretaries
secretaries are employees
Retrieve the street name of the address
of the secretary of the manager of each
salesperson whose salary is more than 50,000:
Select
StreetName(Address(Secretary(Manager(0))))
for each SalesPerson p
where Salary(p) > $50,000
WHY EXTENDING SQL?
SQL is the most popular relational
query language
SQL is also the only relational language
that has a standard.
SQL is being promoted by many
companies as the interface language
for database engines and database
servers. New applications developed
in SQL extensions can easily call
these servers for remote access.