Object Oriented Databases

tribecagamosisΤεχνίτη Νοημοσύνη και Ρομποτική

8 Νοε 2013 (πριν από 3 χρόνια και 7 μήνες)

101 εμφανίσεις

Object


Oriented Databases

fall 2006


1

Object Oriented Databases


1. The need to Object
-
Oriented Databases:



Data models designed for data
-
processing
-
style applications

are not
adequate for new technologies such as computer
-
aided

design,
computer
-
aided software engineering, multimedia and

image
databases,
and document/hypertext databases.



Th
ese new applications require

the database system to

handle features
such as:

-

complex data types

-

data encapsulation and abstract data structures

-

novel methods for indexing and querying


2
. Object Oriented
Data
Model:



The

object
-
oriented

paradigm

is based on

encapsulating

code

and data
related to an object into a single unit.



Object is Abstract representation of a real
-
world entity
, object h
as:

-

Unique identity

-

Embedded properties

-

set of

variables

that contain
the data for
the object. The

value of each variable
can be
itself an object.

-

Ability to interact with other objects and act upon itself



A set of

messages

to which the object responds; each

message may have
zero, one, or more

parameters.

-

A set of

methods,

each of which is a body of code to

implement a
message; a method returns a value as the

response

to the message
.



Messages and responses provide the only external interface to

an
object.

Object Identity



U
sed to uniquely identify objects




Assigned by system

at moment of object’s creation



An object retains its identity even if some or all of the values of

variables or definitions of methods change over time.



Can be deleted
only
if the object is deleted



Can never be reused



C
an be stored as a field of an object
, to refer to another

object.

-

E.g., the spouse field of a person object may be an identifier of
another person object.

Object


Oriented Databases

fall 2006


2



C
an be system generated (created by database) or external

(such as
social
-
security number)


Attributes (Instance Variables)



Attributes:

K
nown as instance variables in OO environment



Domain
:

Logically groups and describes the set of all possible values
that an attribute can have
.



Object State



Set of values that object’s attributes have at a given time



Can vary
, although its OID remains the same



To change the object’s state, change the values of the object’s
attributes



To change the object’s attribute values, send a message to the object

-

Message will invoke a method


Method
s and messages
:



Methods are programs

that performs a specific operation on object’s
data
;

written in a general
-
purpose language

with the following features
:

-

only variables in the object itself may be referenced directly

-

data in other objects are referenced only by sending

messages



Protects d
ata from direct and unauthorized access by other objects



Used to change the object’s attribute values or to return the value of
selected object attributes

Object


Oriented Databases

fall 2006


3

-

E
very attribute
must be

represented by a variable and two methods, e.g.,
the attribute

NAME
is repres
ented by a variable

NAME

and two

messages

"
get
-
name"

and

"
set
-
address
"
.



For convenience, many object
-
oriented data models permit

direct access
to variables of other objects

Depiction of an Object



Objects Send Messages to Each

Other



Object


Oriented Databases

fall 2006


4

Object Containment:



Each component in a design may contain other components



Can be modeled as containment of objects. Objects containing

other
objects are called

complex

or

composite

objects.



Multiple levels of containment create a

containment

hi
erarchy:

-

Links interpreted as is
-
part
-
of, not is
-
a.


-

Allows data to be viewed at different granularities by different

users


Classes



Collection of similar objects with shared structure (attributes) and
behavior (methods)



Similar objects are grouped into a

class; each such object is

called an

instance

of its class



All objects in a class have the same
:



variable types



message interface



methods


-

They may differ in the values assigned to variables



A Class
Definition

Example:


c
lass

employee

{

/* Var
iables */

s
tring

name;

string

address;

date

start
-
date;

int

salary;

/* Messages */

i
nt

annual
-
salary();

string

get
-
name();

string

get
-
address();

int

set
-
address(string

new
-
address);

int

employment
-
length();

}
;

Notes:

methods to read and set other

variables

are also needed




Object


Oriented Databases

fall 2006


5

OO Summary: Object Characteristics


Class Hierarchy

and
Inheritance



E.g., class of bank customers similar to class of bank

employees: both

share some variables and messages, e.g.,

name

and

address



But there are variables and messages

specific to each class e.g.,

salary

for employees and
credit
-
rating

for customers
.



Every employee is a person; thus

employee

is a specialization

of

person



Similarly,

customer

is a specialization of

person.



Create classes
:
person,

employee

and

customer
:

-

var
iables/messages applicable to all persons associated

with class

person.

-

variables/messages specific to employees associated with

class

employee;

-

similarly for

a class customer










Person

Employee

Customer

Officer

Teller

Object


Oriented Databases

fall 2006


6

Employee Object Representation


Multiple Inheritance
:


Employee Clas
s Hierarchy Method Override


Polymorphism
:



Object


Oriented Databases

fall 2006


7

2.
Characteristics of an Object Oriented Data Model




Support the representation of complex objects



Are extensible:

Capable of defining new data types as well as the
operations to be performed on them



Support e
ncapsulation:

Data representation and method’s implementation
must be hidden from external entities



Exhibit inheritance:

-

Object must be able to inherit properties (data and
methods) of other objects



Support the notion of object identity (OID)

Shared Repr
esentation for All Objects of the Class Person
:




2.1
Referential Object Sharing


Object


Oriented Databases

fall 2006


8

2.2
Interclass Relationships:

Example:




2.2.1
Representing a 1:M Relationship


2.2.2
Representing 1:1 and 1:M Relationships

Object


Oriented Databases

fall 2006


9



Example:
Employee
-
Dependent Relationship



2.2.3
Representing the M:N Relationship



Representing the M:N Relationship with Associated Attributes

Object


Oriented Databases

fall 2006


10



Representing the M:N Relationship with Intersection Class



3. Object
-
Oriented Database Management Systems


The purpose of an ODBMS is to pro
vide persistent object storage. A
persistent object is an object that has been saved to permanent storage,
such as a disk. It survives the execution of a program and can be read back
into memory from storage.

The Rules that make it an OO system:

1.

The syste
ms must support complex objects
:
Data may be stored,
retrieved, and manipulated as complex objects, which consist of sets,
lists, arrays, tuples or relational rows. It must be possible to
construct complex objects from existing objects.

Object


Oriented Databases

fall 2006


11

2.

Object identity mus
t be supported
:
The OID must be independent
of the object's state.

3.

Objects must be encapsulated:
Encapsulation is the combined
storage of both data and the procedures that manipulate them.

4.

The system must support inheritance
:
Objects can be created from
e
xisting objects by using inheritance of properties. This simplifies the
description of complex data. Single or multiple inheritances may be
used. This property ensures code reusability.

5.

The system must avoid premature binding
:
This is also known as late
or

dynamic binding. It allows use of the same methods name in
different classes.




Late binding:
Data type of an attribute is not known until
execution time or runtime



Early binding:
Allows database to check data type for each of the
attribute’s values at com
pilation or definition time

6.

The system must be computationally complete
:
The system must
allow expression of any type of operation in the language.

7.

The system must be extensible
:
The system must be able to define
new types.

8.

The system must be able to mana
ge very large databases
:

OO
systems limit the object space to the amount of primary memory
available. Therefore, an ODBMS must optimize the management of
secondary storage devices by using buffers, indexes, data clustering,
and access path selection

techni
ques
.

9.

Support for Versioning



Allows users to track history of changes in state of an object



If the changes do not yield expected results, they can be undone and
the component restored to its original state



Reason OODBMS is such a strong player in the CAD
and computer
-
aided manufacturing (CAM) arenas


3.1
OODBMS Standards:



The ODMG (Object Data Management Group)

http://www.odmg.org has
created a data model that forms the basis

for an OODBMS in a similar
way that the relational data model

forms the basis for

a RDBMS.



They use
OQL (Object Query Language)

instead of SQL (although it

looks similar).



They use
ODL (Object De
fi
nition Language)

instead of SQL DDL.

Object


Oriented Databases

fall 2006


12

Format for class Declaration using
Object De
fi
nition Language (ODL)
:


class <name> {

<list of element d
eclarations, separated by semi
-
colons>

attribute <type> <name>;

relationship <type> <name> inverse <relationship>;

}


Databases Class Declaration Example

1
:

class Album {

attribute string album;

attribute integer num_tracks;

relationship Artist recorded_b
y inverse Artist::recorded;

}

class Artist {

attribute string name;

attribute int no_members;

relationship Set<Album> recorded inverse Album::recorded_}

Instead of Set<Album>, you can also have Bag<Album>,

List<Album>, Array<Album>.



Object Data Language

-

Example

2:

class Student

{


attribute short id;


attribute string name;


attribute string address;


attribute date dob;


relationship set<Module> takes



inverse Module takenby;


short age();

};

class Module

{


attribute string title;


attribute short s
emester;


relationship set<Student> takenby

Object


Oriented Databases

fall 2006


13



inverse Student takes;

};


class Postgrad extends Student

{


attribute string thesis_title;

};



Commercial OODBMS



ObjectStore, http://www.objectstore.com



Objectivity, http://www.objectivity.com



Jasmine, http:/
/www.ca.com



Versant, http://www.versant.com



Open Source

It is a (relatively) new technology and database vendors support it to

varying extents.

Oracle supports SQL:1999 (with some exceptions).


3.3
Object Orient
ed

Database
Implementation Issues
:



Object ori
ented design requires the database description to include
objects and their data representation, constraints, and operations



Few computerized OODB design tools exist



Lack of standards affects object oriented database design



Object
-
oriented concepts can be
used as a design tool, and be

encoded
into
a relational database (analogous to

modeling data with E
-
R diagram
and then converting to a set of

relations).



The concepts of object orientation can be incorporated into a

programming language that is used to man
ipulate the

database.

-

Object
-
relational systems
:

add complex types and

object
-
orientation
to relational language.

-

Persistent programming languages
:

extend object
-
oriented

programming language to deal with databases by adding

concepts such
as persistence an
d collections.



Persistent programming languages:

-

allow objects to be created and stored in a database

without any

explicit format changes (format changes are

carried out
transparently).

Object


Oriented Databases

fall 2006


14

-

allow objects to be manipulated in
-
memory


do not need to

explicitly
load from or store to the database.

-

allow data to be manipulated directly from the programming

language
without having to go through a data manipulation

language like SQL.

-

Approaches to make
transient objects persistent

include

establishing
persistence by:



Class


declare all objects of a class to be persistent;

simple but
inflexible.



Creation


extend the syntax for creating transient objects

to
create persistent objects.



Marking


an object that is to persist beyond program

execution is
marked as persiste
nt before program

termination.



Reference


declare (root) persistent objects; objects are

pe
rsistent if they are r
eferred to (directly or indirectly) from a

root object.

-

In O
-
O languages such as C++, an object identifier is actually

an in
-
memory pointer.



P
ersistent pointer persists beyond program execution; can be

thought of as a pointer into the database.

-

How to find objects in the database:



Store collections of objects and allow programs to iterate over

the
collections to find required objects.




3.4
How

OO Concepts Have Influenced
the Relational

Model



RDBMS is beginning to reach its limits in a business data environment
that is changing with the advent of mixed
-
media data storage and
retrieval



Extended relational model (ERM), or object/relational model
(O/RM)



Extensibility of new user
-
defined (abstract) data types



Complex objects



Inheritance



Procedure calls (rules or triggers)



System
-
generated identifiers (OID surrogates)


The Next Generation of Database Management Systems

Object


Oriented Databases

fall 2006


15



Likely to incorporate features
borrowed from object oriented database
systems, artificial intelligence systems, expert systems, distributed
databases, and the Internet



Enable future DBMSs to handle more complex problems with both
normalized and nonnormalized data



OODBMS will probably co
ntinue to occupy a niche within the database
market


PROBLEM SOLUTIONS


BASE
TRUCK_NUM
c
BASE:
TRUCK_MILES n
TRUCK_BUY_DATE d
TRUCK_SERIAL_NUM
c
1
TRUCK
M
CTRUCK
BASE_CODE n
BASE_CITY c
BASE_STATE c
BASE_AREA_CODE c
BASE_PHONE c
BASE_MANAGER c
TRUCKS:
BASE
M
CTRUCK
TYPE_CODE n
TYP_DESCRIPTION c
TRUCKS:
TYPE
TYPE
TYPE:
1
Note: c = character data
d = date data
n = numeric data
M
M

STUDENT
STU_NUM C
STU_LNAME
C
STU_FNAME
C
STU_ADDRESS
C
STU_CITY
C
STU_STATE
C
STU_ZIPCODE C
ADVISOR:
STU_CUM_GPA
N
STU_SEM_GPA N
STUDENT
PROFESSOR
SCHEDULE:
CLASS
1
GRADE
N
M
COURSE:
ROOM:
GRADE N
1
1
CLASS
COURSE
PROFESSOR
PROFESSOR:
1
ROOM
STUDENT
ENROLL:
M
CRS_CODE C
CRS_DESCRIPTION C
CRS_CREDIT N
OFFERING:
M
COURSE
CLASS
PROF_NUM C
PROF_NAME C
PROF_DOB
D
DEPT_CODE C
TEACH_LOAD:
M
PROFESSOR
CLASS
M
ADVISEES:
BLDG_CODE C
ROOM_NUM C
RESERVATION:
M
ROOM
CLASS
Note: C = Character
D = Date
N = Numeric

Object


Oriented Databases

fall 2006


16

CLASS
STUDENT
ENROLL
ENROLL
STU_SOC_SEC_NUM
STU_LNAME
STU_FNAME
STU_ADDRESS
STU_CITY
STU_STATE
STU_ZIPCODE
CLASS_TAKEN:
STU_CUM_GPA
STU_SEM_GPA
M
STUDENT
CLASS:
STUDENT:
GRADE
1
1
ENROLL
CLASS_CODE
CLASS_DESCRIPTION
TAKEN BY:
M
CLASS



STU_NUM
C
STU_LNAME
C
STU_FNAME
C
STU_ADDRESS
C
STU_CITY
C
STU_STATE
C
STU_ZIPCODE
C
ADVISOR:
STU_CUM_GPA
N
STU_SEM_GPA
N
1
STUDENT
PROFESSOR
SCHEDULE:
M
COURSE: 1
CLASS
PROFESSOR: 1
Note: C = Character
D = Date
required
required
required
required
required
optional
COURSE
ROOM
STUDENT
CLASS
PROFESSOR
GRADE
N
ROOM:
1
ENROLL:
1
GRADE N
M


Object


Oriented Databases

fall 2006


17

STU_NUM
C
STU_LNAME
C
STU_FNAME
C
STU_ADDRESS
C
STU_CITY
C
STU_STATE
C
STU_ZIPCODE
C
ADVISOR:
1
STUDENT
PROFESSOR
SCHEDULE:
M
COURSE: 1
CLASS
PROFESSOR: 1
Note: C = Character
D = Date
N = Numeric
COURSE
ROOM
STU_REC
STU_REC
PROFESSOR
STU_GPA N
ROOM:
1
ENROLL: M
CLASS
STUDENT: 1
STU_REC
CLASS:
1
STUDENT
GRADE N


1
Note: C = Character
D = Date
N = Numeric
NAME
DOB
ADDRESS
ADVISOR:
STU_GPA
N
STUDENT
PROFESSOR
SCHEDULE:
STU_REC
M
1
STUDENT
NAME
DOB
ADDRESS
DEPT_CODE C
TEACH_LOAD:
M
PROFESSOR
CLASS
M
ADVISEES:
PERSON
NAME
DOB
ADDRESS
Inherited
from
PERSON
Subclass
Subclass
Superclass



Object


Oriented Databases

fall 2006


18

Note: C = Character
D = Date
N = Numeric
REGION_CODE
N
REGION_LOCATION C
M
REGION
STORE
STORE
EMP_CODE N
EMP_TITLE
C
EMP_LNAME C
EMP_FNAME
C
EMP_INITIAL C
EMPLOYEE
MANAGER_OF:
STORE
STORES:
STORE_CODE
N
STORE_NAME C
STORE_YTD_SALES N
REGION:
REGION
1
MANAGER:
EMPLOYEE
1
WORKS_AT:
STORE
1
WORKERS:
EMPLOYEE
M
1

CUS_NUM N
CUS_LNAME
C
CUS_FNAME
C
CUS_INITIAL
C
CUS_CREDIT C
CUS_BALANCE C
CUSTOMER
INVOICES:
INVOICE
INVLINE_UNITS N
INVLINE_PRICE N
INVLINE_TOTAL N
INVOICE
EMPLOYEE
SALESREP:
1
PRODUCT
LINES:
M
EMP_NUM
N
EMP_TITLE
C
EMP_LNAME C
EMP_FNAME C
EMP_INITIAL
C
EMP_HIRE_DATE D
INVOICES:
EMPLOYEE
INVOICE
M
Note: C = Character
D = Date
N = Numeric
INV_ NUM
N
CUSTOMER:
CUSTOMER
INV_ DATE D
INV_SUB
N
INV_TAX
N
INV_TOTAL N
INV_PYMT N
INVLINE_NUM N
1
M
1
PROD_CODE
N
PROD_COST
N
PROD_PRICE
N
PROD_QOH
N
PROD_MIN_QOH
N
PROD_LAST_ORDER D
LINES:
PRODUCT
INVLINE_UNITS N
INVLINE_PRICE N
INVLINE_TOTAL N
INVOICE
INVLINE_NUM N
M
1


EMP_NUM N
EMP_LNAME C
EMP_LNAME C
EMP_FNAME C
EMP_INITIAL
C
EMP_HIREDATE
D
EMPLOYEE
JOB:
JOB
ASSIGN
1
Note: C = Character
D = Date
N = Numeric
ASSIGN_NUM N
ASSIGN_DATE D
PROJ_NUM N
PROJ_NAME C
PROJ_DATE D
PROJECT
PROJECT
1
EMPLOYEE
1
ASSIGN:
ASSIGN
M
ASSIGN_HOURS N
ASSIGN:
ASSIGN
M
JOB
JOB_CODE
N
JOB_DESCRIPTION C
JOB_CHG_HOUR N