Transcript Object Oriented Database - Department of Computer Science

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
Object Instances
PERSON
Instance
variables
NAME
ADDRESS
DOB
SEX
AGE
S
S
S
S
I
John Smith
123 Easy St
23-Nov-1970
M
32
Instance Variables
ADTs
NAME
FIRST_NAME
S
MIDDLE_NAME S
LAST_NAME
S
ADDRESS
STREET_NUM
STREET
APARTMENT
CITY
STATE
ZIP
S
S
S
S
S
I
DOB
DAY
I
MONTH I
YEAR
I
PERSON
Employee
SuperClass
Student
Subclasses
Representing 1:M Relationships
(Premiere Products Example)
Customer
SS#
Name
Address
Balance
Cred_Lim
Sales_Rep
Sales_Rep
Name
Address
Tot_Comm
Com_Rate
1
Customer
M
Representing M:M Relationships
Manufacturer
Code
Name
Address
Contact:
Person
1
Item
Code
Description
Quantity
Unit_Price
Manufacturers:
Items:
Item
Manufacturer
M
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
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
Weight
Price
Money
OODBMS
Object-Oriented
Features
OO Concepts
OO data models
OOPL
GUI
OODBMS
Conventional
DBMS
Data accessibility
Persistence
Backup and Recovery
Transaction Processing
Concurrency
Security/Integrity
Administration
13 Rules for an OODBMS
from 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 represent
an 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;
};
Interfaces
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);
};
Classes
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();
};
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