ppt - CIS @ Temple University
Download
Report
Transcript ppt - CIS @ Temple University
ObjectStore Database System
By
C. Lamb, G Landis, J.Orenstein, L. Weinreb
Presentation by
Meghana Chemburkar
December 4, 2002
Instructor: Dr.Vasilis Megalooikonomou
Overview
Introduction
Integration with C++
Application Interface
Architecture & Implementation
Performance
Conclusions
Introduction
ObjectStore is an Object Oriented database management
system(OODBMS) that provides a tightly integrated
language interface to the traditional DBMS features of
persistent storage,transaction management,distributed
data access.
It was designed to provide a unified programmatic
interface to both persistently allocated data and transiently
allocated data,with object-access speed for persistent data
usually equal to that of in-memory deference of a pointer
to transient data.
Target applications are programs like CAD,CAE,
GIS(Geographic Information System) etc that perform
complex manipulation on databases of objects with
intricate structure.
Integration with C++
ObjectStore is closely integrated with the programming
language . C++ was selected as programming language
through which OjectStore can be accessed.
Reasons:
Ease in learning
No translation code
Reusability
Application Interface
In addition to data definition and manipulation facilities
provided by the host language,ObjectStore provides support
for:
Accessing the persistent data inside transactions
Library of collection types
Bi-directional relationship
Optimizing Query Facility
Version Facility for collaborative work.
Tools supporting database schema design,database
browsing ,database administration,application compilation
& debugging etc.
Accessing Persistent Data
#include <objectstore/objectstore.H>
#include <records.H>
main(){
//Declare database and an “entry point”into the database of type “pointer to dept.”
database *db;
persistent<db> department* engineering_department;
//Open database
db = database::open(“/company/records”);
//Start transaction so that database can be accessed
transaction::begin();
//The next 3 statements create and manipulate persistent object representing a person
named Fred
employee *emp = new(db) employee(“Fred”);
engineering_department -> add_employee(emp);
emp->salary=1000;
//Commit all changes to database
transaction::commit();
}
ObjectStore Collections
/*file records.H */
class employee{
public:
char* name;
int salary;
};
class department{
public:
os_Set<employee*> employees;
void add_employee(employee *e){
employees->insert(e);
}
int works_here(employee *e){
return employees->contains(e);
}
}
Relationship Facility
Relationships can be though of as a pair of inverse
pointers,so that if one object points to another,the
second object has an inverse pointer back to the first.
If one participant in the relation is deleted then the
pointer to that object ,from other participant is set to
null.
One to one,one-to-many and many-to-many
relationships are supported.
object1
object2
null
object2
Relationship Facility (contd.)
/*file records.H */
class employee{
public:
string name;
int salary;
department* dept;
inverse_member department::employees;
};
class department{
public:
os_Set<employee*> employees;
inverse_member employee::dept;
void add_employee(employee *e){
employees->insert(e);
}
int works_here(employee *e){
return employees->contains(e);
}
}
Associative Queries
ObjectStore queries are closely integrated with host language.
A query is simply expression that operates on one or more
collections and produces a collection or reference to an object.
[: :] is ObjectStore syntax for queries.
e.g.Suppose all_employee is set of employee objects
os_Set<employee*> all_employees;
The following statement uses query against all_employees to find
employees earning over $100,000 and assign the result to
overpaid_employees:
os_Set<employee*>& overpaid_employee =all_employees[:salary>=100,000:];
Associative Queries (contd.)
The query to find employees who work in the same
department as Fred.(using ObjectStore’s compiler)
all_employees[:dept->employees [:name==‘Fred’ :]:];
The above query (using C++ library interface)
os_Set<employee*>& work_with_fred = all_employees->
query(‘employee*’,”dept->employees[:name==\’Fred’\:]”);
Versions
ObjectStore provides facilities for multiple users to share
data in a cooperative fashion.With these facilities,a user can
check out version of the object,make changes and then
check changes back in to main development project so that
they are visible to other members of team.
Users can control exactly which version to use ,for each
object or group of objects by setting up private workspaces
that specify the desired version.
Architecture & Implementation
Client-Server Communication
Server
cache
Client1
cache
Client2
Architecture & Implementation (contd.)
Cache Coherence
The page can reside in the client cache without being
locked,some other client might modify the
page,invalidating the cached copy. The mechanism for
making sure that transactions see valid copies of pages is
called cache coherence.
Server sends callback message to client and holding client
replies back depending on page’s mode(shared or
exclusive).
Architecture & Implementation (contd.)
Virtual memory mapping
Two independent databases might use same address space for
their own objects. Objectstore solves this problem by
dynamically assigning potions of address space to correspond to
portions of the databases used by application.
Relocation
When database size exceeds the size of available address
space,relocation is done.
When the page is mapped into virtual memory,the
correspondence of objects and virtual addresses may have
changed.The value of each pointer stored in page must be
updated to follow the new virtual address of object.
Performance
The Cattell Benchmark was designed to reflect the access
pattern of engineering applications.The benchmark
consists of several tests,but only transverse tests results
are shown since they best illustrate the performance
benefits of ObjectStore.
The results with client and server on different machines
are shown.The difference between cold and warm cache
times shows that client cache and virtual memory
mapping has significant performance benefit.
Performance (contd.)
Cold Cache is empty cache as would exists when client starts
accessing part of database for first time
Warm Cache is same cache after a number of iterations have been
run.
Warm & cold cache traversal results
100
94
84
80
Time (sec)
Cold Cache
60
Warm Cache
40
27
13
20
0.7
18
0.1
17
1.2
17
1.2
8.4
0
oodb1 ObjectSotre
oodb3 oodb4
System
rdbms1
index
Conclusions
ObjectStore gives the users of its target applications
1.High productivity through ease of use.
2.Tight integration with the host language.
3.High performance.
Features under development
1.Schema evaluation
2.Communication with existing databases.
Questions