Transcript ch27

Chapter 27
Object-Oriented DBMSs - Standards
and Systems
Transparencies
© Pearson Education Limited 1995, 2005
1
Chapter 27 - Objectives
Object Management Group (OMG), CORBA,
and other OMG standards.
 Main features of ODMG Object Standard:

–
–
–
–

Object model
Object Definition Language (ODL)
Object Query Language (OQL)
Language bindings.
Main features of ObjectStore:
– Architecture
– Data Definition
– Data Manipulation.
2
© Pearson Education Limited 1995, 2005
Object Management Group (OMG)
 International
non profit-making consortium
founded in 1989 to address object standards.
 Several hundred member organizations including
many platform and major software vendors.
 Primary aims of OMG are:
– Promotion of object-oriented approach.
– Development of standards in which location,
environment, language, and other characteristics of
objects are transparent.
 Not
recognized standards group but aims to
develop de facto standards.
3
© Pearson Education Limited 1995, 2005
Object Management Architecture
Four areas identified for reference model:
Object Model (OM) - Design-portable abstract model for
communicating with OMG-compliant object-oriented
systems.
Object Request Broker (ORB) - Handle distribution of
messages between application objects in a highly
interoperable manner.
Like distributed ‘software bus’ enabling objects
make/receive requests/responses from a provider.
to
4
© Pearson Education Limited 1995, 2005
Object Management Architecture
Object Services - Provide main functions for
realizing basic object functionality. Many of these
services are database-oriented.
Common Facilities - Comprise a set of tasks that
many applications must perform but are
traditionally duplicated within each one.
5
© Pearson Education Limited 1995, 2005
Object Reference Model
6
© Pearson Education Limited 1995, 2005
Object Model
7
© Pearson Education Limited 1995, 2005
Common Object Request Broker Architecture
(CORBA)
 Defines
architecture of ORB-based environments.
 Basis of any OMG component, defining parts that
form ORB and associated structures.
 Some elements of CORBA are:
–
–
–
–
Interface Definition Language (IDL).
Type model.
Interface Repository.
Methods for getting interfaces/specifications of objects.
 Provides
static and dynamic mechanism for clients
to issue request to objects.
8
© Pearson Education Limited 1995, 2005
CORBA ORB Architecture
9
© Pearson Education Limited 1995, 2005
Other OMG Specifications
 UML
provides common language for describing
software models.
 Meta-Object Facility (MOF), defines common,
abstract language for specification of metamodels.
 XML Metadata Interchange (XMI) maps MOF to
XML. XMI defines how XML tags are used to
represent MOF-compliant models in XML.
 Common Warehouse Metamodel (CWM) defines
metamodel representing both business and
technical metadata commonly found in data
warehousing and business intelligence domains.
10
© Pearson Education Limited 1995, 2005
CWM Sub-Metamodels
11
© Pearson Education Limited 1995, 2005
CWM Relational Data Metamodel
12
© Pearson Education Limited 1995, 2005
Model-Driven Architecture (MDA)
 OMG
hoped OMA would be common OO
middleware standard. However:
– Microsoft produced DCOM (Distributed Common
Object Model),
– Sun developed Java, which came with its own ORB,
Remote Method Invocation (RMI),
– another set of middleware standards emerged with
XML and SOAP (Simple Object Access Protocol).
 Also
e-Business increased pressure on companies
to integrate their corporate databases. Enterprise
Application Integration (EAI) is one of current
key challenges for companies and, rather than
helping, middleware may be part of problem.
13
© Pearson Education Limited 1995, 2005
Model-Driven Architecture (MDA)
 MDA
is an approach to system specification and
interoperability building upon 4 specifications
discussed above.
 Based on premise that systems should be specified
independent of all hardware and software details.
 Thus, while software and hardware may change
over time, the specification will still be applicable.
 MDA addresses complete system lifecycle from
analysis and design to implementation, testing,
component assembly, and deployment.
14
© Pearson Education Limited 1995, 2005
Model-Driven Architecture (MDA)
 To
create an MDA-based application, a Platform
Independent Model (PIM) is produced that
represents only business functionality and
behavior.
 PIM can then be mapped to one or more Platform
Specific Models (PSMs) to target platforms like
CORBA Component Model (CCM), Enterprise
JavaBeans (EJB), or Microsoft Transaction Server
(MTS).
 Both the PIM and the PSM are expressed using
the UML.
 MDA covers full range of pervasive services
already specified by OMG, such as Persistence,
Transactions, and
Security.
© Pearson
Education Limited 1995, 2005
15
Model-Driven Architecture (MDA)
16
© Pearson Education Limited 1995, 2005
Object Data Management Group
 Established
by vendors of OODBMSs to define
standards.
 Have produced an Object Model that specifies a
standard model for the semantics of database
objects.
 Design of class libraries and applications using
these semantics should be portable across
various OODBMSs.
17
© Pearson Education Limited 1995, 2005
Object Data Management Group
 Between
release 2.0 (1997) and 3.0 (late 1999),
ODMG expanded its charter to cover the
specification of universal object storage standards.
 At same time, ODMG changed its name from
Object Database Management Group to Object
Data Management Group to reflect expansion of
its efforts beyond merely setting storage
standards for object databases.
 The Java binding was submitted to JCP as basis
for Java Data Objects (JDO).
 In 2001, ODMG completed its work and
disbanded.
© Pearson Education Limited 1995, 2005
18
Object Data Management Group
Under its extended charter, ODMG specification
covers both OODBMSs that store objects directly
and Object-to-Database Mappings (ODMs) that
convert and store the objects in a relational or other
database system representation.
 Both types of products are referred to generically as
Object Data Management Systems (ODMSs).
 ODMSs
make database objects appear as
programming language objects in one or more
existing OOPLs, and extend programming language
with transparently persistent data, concurrency
control, recovery, associative queries, and other
database capabilities.

© Pearson Education Limited 1995, 2005
19
Object Data Management Group
 Major
components of ODMG architecture for an
OODBMS are:
–
–
–
–
Object Model (OM).
Object Definition Language (ODL).
Object Query Language (OQL).
C++, Smalltalk, and Java Language Binding.
20
© Pearson Education Limited 1995, 2005
ODMG OM - Basic Modeling Primitives
 Basic
modeling primitives are object/literal.
 Only an object has a unique identifier.
 Objects/literals can be categorized into types.
 All objects of given type exhibit common
behavior and state. A type is itself an object.
 Behavior defined by set of operations that can be
performed on or by object.
 State defined by values objects carry for a set of
properties.
21
© Pearson Education Limited 1995, 2005
ODMG OM - Basic Modeling Primitives
 Property
may be either an attribute of object or
relationship between object and one or more
other objects.
 ODMS stores objects, enabling them to be shared
by multiple users and applications.
 ODMS based on a schema defined in ODL.
22
© Pearson Education Limited 1995, 2005
ODMG Object Model - Objects
Object types decomposed as atomic, collections,
or structured types.
 Structured types as defined in ISO SQL
standard.
 Objects created using new() of corresponding
factory interface provided by language binding.
 Each object has a unique identity, the object
identifier, which does not change and is not
reused when the object is deleted.
 May be given one or more names by user.

23
© Pearson Education Limited 1995, 2005
Set of Built-in Types for ODMG Object Model
24
© Pearson Education Limited 1995, 2005
ODL Interface for Objects
25
© Pearson Education Limited 1995, 2005
ODMG OM - OIDs and Object Names

Each object is given a unique identity by ODMS,
the object identifier, which does not change and
is not reused when object is deleted.

Object may also be given one or more names
that are meaningful to the user, provided each
name identifies a single object within a database.

Object names act as “root” objects that provide
entry points into the database.
26
© Pearson Education Limited 1995, 2005
ODMG Object Model - Objects
Lifetime of an object is orthogonal to its type
(persistence is independent of type).
 Lifetime specified when object is created:
– Transient: object’s memory allocated and
deallocated by programming language’s
runtime system.
– Persistent: object’s storage managed by
OODBMS.

27
© Pearson Education Limited 1995, 2005
ODMG Object Model - Literals
 A constant,
with possibly complex structure.
 Literal types decomposed as atomic, collections,
structured, or null.
 Values of a literal’s properties may not change.
 Do not have their own identifiers and cannot
stand alone as objects.
 Embedded in objects and cannot be individually
referenced.
 Structured literals contain fixed number of
named heterogeneous elements.
28
© Pearson Education Limited 1995, 2005
ODMG Object Model - Built-in Collections
Contains arbitrary number of unnamed
homogeneous elements; each can be instance of
atomic type, another collection, or a literal type.
 Only collection objects have identity.
 Use iterator to iterate over collection.
 Ordered and unordered collections:

– ordered: traversed first to last, or vice versa;
– unordered: no fixed order of iteration.
29
© Pearson Education Limited 1995, 2005
ODMG Object Model – Built-in Collections
Set: unordered collections without duplicates.
Bag: unordered collections that do allow duplicates.
List: ordered collections that allow duplicates.
Array: 1D array of dynamically varying length.
Dictionary: unordered sequence of key-value pairs
with no duplicate keys.
30
© Pearson Education Limited 1995, 2005
ODL Interface for Collections
31
© Pearson Education Limited 1995, 2005
ODMG Object Model – Atomic Objects
 Any
user-defined object that is not a collection
object is called an atomic object.
 Atomic objects are represented as a class, which
comprises state and behavior.
 State represented by set of properties (attribute or
relationship).
 Attribute is not a “first class” object (i.e. not an
object and so no OID).
 Atomic
objects can be related in a
supertype/subtype lattice.
32
© Pearson Education Limited 1995, 2005
ODMG Object Model - Relationships
 Only
binary relationships supported.
 Traversal paths are defined for each direction of
traversal.
class Branch {
relationship set <Staff>Has inverse Staff::WorksAt}
class Staff {
relationship Branch WorksAt inverse Branch::Has}
33
© Pearson Education Limited 1995, 2005
ODMG Object Model - Types, Classes, Interfaces,
and Inheritance
 Two ways to specify types: interfaces and classes.
 Interface is a specification that defines only
abstract behavior of an object type, using operation
signatures.
 Behavior inheritance allows interfaces to be
inherited by other interfaces/classes (but properties
cannot be inherited from the interface).
 Interface also noninstantiable – cannot create
objects from an interface
 Normally, interfaces used to specify abstract
operations that can be inherited by classes or by
other interfaces.
34
© Pearson Education Limited 1995, 2005
ODMG Object Model - Types, Classes, Interfaces,
and Inheritance
Class defines both the abstract state and
behavior of an object type, and is instantiable.
 Thus, interface is an abstract concept and class
an implementation concept.
 Can specify single inheritance between classes
using extends keyword.
 Multiple inheritance not allowed using extends
but is allowed using behavior inheritance.

35
© Pearson Education Limited 1995, 2005
ODMG Object Model - Types and Classes
 Class
definition specifies its extent and its keys:
Extents - set of all instances of given type. May
request ODMS maintain index to members of
this set.
Keys - uniquely identifies the instances of a type
(similar to the concept of a candidate key).
36
© Pearson Education Limited 1995, 2005
ODMG Object Model
 Object
–
–
–
–
–
model also specifies:
Exceptions.
Metadata.
Transactions.
Databases.
Modules.
37
© Pearson Education Limited 1995, 2005
Object Definition Language (ODL)
module DreamHome
Class Branch
(extent branchOffices
key branchNo)
{
attribute string branchNo;
….
relationship Manager ManagedBy
inverse Manager::Manages;
void takeOnPropertyForRent(in string propertyNo)
raises(propertyAlreadyForRent);
}
38
Object Definition Language (ODL)
class Person {
attribute struct Pname {string fName, string lName} name;
}
Class Staff extends Person
(extent staff
key staffNo)
{
attribute staffNo;
attribute date DOB;
….
short getAge();
}
39
© Pearson Education Limited 1995, 2005
Object Definition Language (ODL)
class Manager extends Staff
(extent managers)
{
relationship Branch Manages
inverse Branch::ManagedBy;
}
40
© Pearson Education Limited 1995, 2005
Object Query Language (OQL)
 Provides
declarative access to object database
using SQL-like syntax.
 Does not provide explicit update operators leaves this to operations defined on object types.
 Can be used as a standalone language and as a
language embedded in another language, for
which an ODMG binding is defined (Smalltalk,
C++, and Java).
 OQL can also invoke operations programmed
in these languages.
41
© Pearson Education Limited 1995, 2005
Object Query Language (OQL)
 Can
be used for
navigational access:
associative
and
– Associative query returns collection of objects.
How these objects are located is responsibility
of ODMS.
– Navigational query accesses individual objects
and object relationships used to navigate from
one object to another. Responsibility of
application program to specify procedure for
accessing the objects.
42
© Pearson Education Limited 1995, 2005
Object Query Language (OQL)
 An
OQL query is a function that delivers an
object whose type may be inferred from operator
contributing to query expression.
 Query definition expressions is of form:
DEFINE Q as e
 Defines
query
expression e.
with
name
Q given
query
43
© Pearson Education Limited 1995, 2005
Object Query Language (OQL)
 Expression
–
–
–
–
can take several forms:
Elementary
Atomic type
Collection
Binary set
- Construction
- Object
- Indexed collections
- Conversion
 Query
consists of a (possibly empty) set of query
definition expressions followed by an expression.
 Result is object with or without identity.
44
© Pearson Education Limited 1995, 2005
Example 27.2 OQL: Extents & Traversal Paths
Get set of all staff (with identity)
staff
Get set of all branch managers (with identity)
branchOffices.ManagedBy
45
© Pearson Education Limited 1995, 2005
Example 27.2 OQL: Extents & Traversal Paths
Find all branches in London
SELECT b.branchNo
FROM b IN branchOffices
WHERE b.address.city = “London”;
This returns a literal of type bag<string>.
46
© Pearson Education Limited 1995, 2005
Example 27.2 OQL: Extents & Traversal Paths
Assume londonBranches is named object (from
last query). Find all staff who work at that
branch.
londonBranches.Has
This returns set<SalesStaff>.
47
© Pearson Education Limited 1995, 2005
Example 27.2 OQL: Extents & Traversal Paths
Because of ambiguity over return result, cannot
access sales staff salaries using:
londonBranches.Has.salary
Result may be set<float> or bag<float>.
Instead use:
SELECT [DISTINCT] s.salary
FROM s IN londonBranches.Has;
48
© Pearson Education Limited 1995, 2005
Example 27.3 - OQL: Use of DEFINE
Get set of all staff who work in London (without
identity).
DEFINE Londoners AS
SELECT s
FROM s IN salesStaff
WHERE s.WorksAt.address.city = “London”;
SELECT s.name.lName FROM s IN Londoners;
This returns a literal of type set<string>.
49
© Pearson Education Limited 1995, 2005
Example 27.3 - OQL: Use of DEFINE
Can generalize this:
DEFINE CityWorker(cityname) AS
SELECT s
FROM s IN salesStaff
WHERE s.WorksAt.address.city = cityname;
CityWorker(“London”);
CityWorker(“Glasgow”);
50
© Pearson Education Limited 1995, 2005
Example 27.4 OQL: Use of structures
Get structured set (without identity) containing
name, sex, and age of all staff who live in London.
SELECT struct (lName:s.name.lName, sex:s.sex,
age:s.age)
FROM s IN Staff
WHERE s.WorksAt.address.city = “London”
This returns a literal of type set<struct>.
51
© Pearson Education Limited 1995, 2005
Example 27.4 OQL: Use of structures
Get structured set (with identity) with name, sex,
and age of all deputy managers over 60:
class Deputy {attribute string lName; attribute
sexType sex; attribute integer age;};
Typedef bag<Deputy>Deputies;
Deputies (SELECT Deputy (lName:s.name.lName,
sex:s.sex, age:x.age)
FROM s IN salesStaff
WHERE position = “Deputy” AND s.getAge > 60)
This returns a mutable object of type deputies.
52
© Pearson Education Limited 1995, 2005
Example 27.4 OQL: Use of structures
Get structured set (without identity) containing
branch number and set of all Assistants at
branches in London.
SELECT struct (branchNo:x.branchNo, assistants:
(SELECT y FROM y IN x.WorksAt
WHERE y.position = “Assistant”))
FROM x IN (SELECT b FROM b IN branchOffices
WHERE b.address.city = “London”)
This returns a literal of type set<struct>.
53
© Pearson Education Limited 1995, 2005
Example 27.5 OQL: Use of aggregates
How many staff work in Glasgow.
COUNT (s IN CityWorker(“Glasgow”);
OQL aggregate can be applied within SELECT or
to result of SELECT.
 Following equivalent:

SELECT COUNT(s) FROM s IN salesStaff
WHERE s.WorksAt.branchNo = “B003”;
COUNT(SELECT s FROM s IN salesStaff
WHERE s.WorksAt.branchNo = “B003”);
54
© Pearson Education Limited 1995, 2005
Example 27.6 OQL: GROUP BY
Determine number of sales staff at each branch.
SELECT struct(branchNumber,
numberOfStaff:COUNT(partition))
FROM s IN salesStaff
GROUP BY branchNumber: s.WorksAt.branchNo;
Result is of type: set<struct(branchNumber: string,
partition: bag<struct(s:SalesStaff)>)>
Note use of keyword partition to refer to each
partition.
55
© Pearson Education Limited 1995, 2005
OQL - Creating Objects
A type name constructor is used to create an
object with identity.
Manager(staffNo: “SL21”,
fName: “John”, lName: “White”,
address: “19 Taylor St, London”,
position: “Manager”, sex: “M”,
DOB: date“1945-10-01”, salary: 30000)
56
© Pearson Education Limited 1995, 2005
Language Bindings
 Specify
how ODL/OML constructs are mapped
to programming language constructs.
 Basic design principle is that programmer
should think there is only one language being
used.
 C++ class library provided containing classes
and functions that implement ODL constructs.
Also, OML is used to specify how database
objects are retrieved and manipulated within
application program.
57
© Pearson Education Limited 1995, 2005
Language Bindings - Creating a Working
Application
58
© Pearson Education Limited 1995, 2005
Language Bindings
 Features
that implement interface are prefixed
d_ (e.g. d_Float, d_String, d_List, d_Set, and
d_Bag).
 Also
class d_Iterator a class d_Extent.
 Template
class d_Ref(T) defined for each class
T in database schema that can refer to both
persistent and transient objects of class T.
59
© Pearson Education Limited 1995, 2005
Language Bindings
 Relationships
handled by including either a
reference (for 1:1) or a collection (for 1:*). For
example, to represent 1:* Has relationship in
Branch class:
d_Rel_Set<SalesStaff, _WorksAt> Has;
const char _WorksAt[] = “WorksAt”;
 and
to represent same relationship in SalesStaff
class:
d_Rel_Ref<Branch, _Has> WorksAt;
const char _Has[] = “Has”;
60
© Pearson Education Limited 1995, 2005
Language Bindings - OML
 new
operator overloaded so that it can create
persistent or transient objects.
 To create a persistent object, a database name
and a name for the object must be provided.
For example, to create a transient object:
d_Ref<SalesStaff> tempSalesStaff = new SalesStaff;
 and
to create a persistent object:
d_Database *myDB;
d_Ref<SalesStaff> s1 = new(myDb, “John White”)
SalesStaff;
61
© Pearson Education Limited 1995, 2005
Language Bindings - OQL
 OQL
queries can be executed from within C++
in one of following ways:
– using query member function of the d_Collection
class;
– using d_OQL_Query interface.
d_Bag<d_Ref<SalesStaff>> wellPaidStaff;
SaleStaff->query(wellPaidStaff, “salary > 30000”);
d_OQL_Query q(“SELECT s.WorksAt
FROM s IN SalesStaff WHERE salary > $1”);
d_Bag<d_Ref<Branch>> branches;
q << 30000;
d_oql_execute(q, branches);
© Pearson Education Limited 1995, 2005
62
Mapping Conceptual Design to Logical OO Design
 Step
1 Mapping classes
– Map each class or subclass to an ODL class, including
all appropriate attributes and methods.
– Map composite attributes to a tuple constructor using a
struct declaration.
– Map any multivalued attributes as follows:
»
»
»
if values are ordered, map to a list constructor;
if values contain duplicates, map to a bag constructor;
otherwise, map to a set constructor.
 Create
an extent for each class that will be iterated
over. Specify EXTENDS for each ODL class that
represents a subclass to inherit attributes and
methods of superclass.
63
© Pearson Education Limited 1995, 2005
Mapping Conceptual Design to Logical OO Design
 Step
2 Mapping binary relationships
– Add a relationship property (or reference attribute)
into each class that participates in relationship.
– If supported, use inverse relationships where possible to
ensure system automatically maintains RI; otherwise
program this functionality into class methods.
– If 1:1, each relationship property will be single-valued.
– If 1:*, relationship property will be single-valued on one
side and collection type (list or set) on the other.
– If *:*, each side will be a collection type.
– Create tuple constructor (struct) for relationships
attributes of form <relationship reference, relationship
attributes>.
64
© Pearson Education Limited 1995, 2005
Mapping Conceptual Design to Logical OO Design
 Step
3 Mapping n-ary relationships
– For each relationship with degree greater than 2, create
separate class to represent relationship and include
relationship property (based on a 1:* relationship) to
each participating class.
 Step
4 Mapping categories
– For each category (union type), create class to represent
category and define a 1:1 relationship between category
class and each of its superclasses.
– Alternatively, a union type can be used if OODBMS
supports it.
65
© Pearson Education Limited 1995, 2005
ObjectStore - Architecture
 Based
on multi-client/multi-server architecture,
with each server responsible for controlling
access to an object store and for managing
concurrency control (locking-based), data
recovery, and transaction log, among others.
 A client can contact ObjectStore server on its
host or any other ObjectStore server on any
other host in network.
66
© Pearson Education Limited 1995, 2005
ObjectStore - Architecture
 For
each host machine running one or more
clients there is an associated cache manager
process to facilitate concurrent access to data by
handling callback messages from server to
clients.
 Also, each client has its own client cache, which
acts as a holding area for data mapped (or
waiting to be mapped) into physical memory.
67
© Pearson Education Limited 1995, 2005
ObjectStore Architecture
68
© Pearson Education Limited 1995, 2005
ObjectStore Server
 Responsible
for:
– storage and retrieval of persistent data;
– handling concurrent access by multiple client
applications;
– database recovery.
69
© Pearson Education Limited 1995, 2005
Client Application
 Objectstore
client library is linked into each
client application, allowing it to:
– map persistent objects to virtual addresses;
– allocate and deallocate storage for persistent objects;
– maintain a cache of recently used pages and the lock
status of those pages;
– handle page faults on addresses that refer to
persistent objects.
70
© Pearson Education Limited 1995, 2005
Client Cache
 Exists
to improve access to persistent objects.
 When client application needs to access a
persistent object, then a page fault is generated
when:
– object is not in physical memory and not in client
cache;
– object is in client cache but has not yet been
accessed;
– object is in client cache but has been previously
accessed with different read/write permissions.
71
© Pearson Education Limited 1995, 2005
Virtual Memory Mapping Architecture (VMMA)
 C++
object is stored in database in its native
format with all pointers intact (unswizzled).
 Basic idea of VMMA is same as for virtual
memory management in operating systems.
 References to objects are realized by virtual
memory addresses. If object has to be
dereferenced and the page object resides on is in
memory, there is no extra overhead in
dereferencing this object (dereferencing is as fast
as for any C/C++ program).
72
© Pearson Education Limited 1995, 2005
Virtual Memory Mapping Architecture (VMMA)
 If
required page not in memory, page fault
occurs and page is brought into same virtual
memory address it originally occupied.
 Thus, pointers to this object in other
transferred objects are valid virtual memory
pointers referring to their original target.
 Unmapped range of virtual memory reserved
for persistent objects, thereby ensuring that this
range will be used for no other purpose than
database pages.
73
© Pearson Education Limited 1995, 2005
Building an ObjectStore Application
74
© Pearson Education Limited 1995, 2005
ObjectStore Databases
 ObjectStore
supports two types of databases:
– file database, a native operating system file that
contains an ObjectStore database;
– rawfs (raw file system) database, a private file system
managed by the ObjectStore server, independent of file
system managed by operating system.
 Database
divided into clusters and segments. A
cluster is basic unit of storage allocation. When a
persistent object is created storage is allocated
from a cluster. Clusters are divided into segments.
75
© Pearson Education Limited 1995, 2005
Data Definition in ObjectStore
 Can
handle persistence for objects created in
C/C++ and Java through separate class libraries,
and objects created in one language can be
accessed in other.
 For C++, ObjectStore uses C++ as a schema
language so that everything in database must be
defined by C++ class.
 Persistence is orthogonal to type and persistent
object support achieved through overloading new
operator.
branchNo = new(DHomeDB, os_typespec::get_char(), 4) char[4];
76
© Pearson Education Limited 1995, 2005
Data Definition in ObjectStore
 Also
a version of C++ delete operator to delete
persistent objects and free persistent memory.
 Once persistent memory has been allocated,
pointers to this memory can be used in same
way as pointers to virtual memory.
77
© Pearson Education Limited 1995, 2005
Creating Relationships in ObjectStore
 Relationship
between Branch and SalesStaff
handled by declaring two data members that are
inverses of each other.
 RI automatically maintained.
 Macros provided for defining relationships:
os_relationship_1_1; os_relationship_m_m;
os_relationship_1_m; os_relationship_m_1.
os_relationship_1_m(SalesStaff, WorksAt, Branch, Has, Branch*)
WorksAt;
os_relationship_m_1(Branch,
Has,
SalesStaff,
WorksAt,
os_Set<SalesStaff*>) Has;
78
© Pearson Education Limited 1995, 2005
Data Manipulation in ObjectStore
 Following
operations must be performed before
persistent memory can be accessed:
– a database must be created or opened;
– a transaction must be started;
– a database root must be retrieved or created.
79
© Pearson Education Limited 1995, 2005
Roots and Entry Point Objects
 Database
root provides way to give an object a
persistent name, thereby allowing object to
serve as entry point into the database.
 From there, any object related to it can be
retrieved using navigation (i.e., following data
member pointers) or by a query (i.e., selecting
all elements of a given collection that satisfy a
specified predicate).
80
© Pearson Education Limited 1995, 2005
Roots and Entry Point Objects
81
© Pearson Education Limited 1995, 2005
Access Based on a Named Root
aBranch = (Branch*)(db1->find_root(“Branch3_Root”)
->get_value(WorksAtType);
cout << “Retrieval of branch B003 root: ” <<
aBranch->branchNo << “\n”;
82
© Pearson Education Limited 1995, 2005
Iteration of Collections using Cursors
os_Cursor<SalesStaff*> c(aBranch->Has);
cout << “Staff associated with B003: \n”
for (p = c.first(); c.more(); p = c.next())
cout << p->staffNo << “\n”;
83
© Pearson Education Limited 1995, 2005
Lookup of Single Object Based on Value of one or
more Data Members
salesStaffExtent = (os_Set<SalesStaff*>*)
(db1->find_root(“salesStaffExtent_Root”)
->get_value(salesStaffExtentType);
aSalesPerson = salesStaffExtent
->query_pick(“SalesStaff*”,“!strcmp(staffNo,\“SG37\”)”,
db1);
cout << “Retrieval of specific member of sales staff: ” <<
aSalesPerson.staffNo << “\n”;
84
© Pearson Education Limited 1995, 2005
Lookup of Single Object Based on Value of one or
more Data Members
os_Set<SalesStaff*> &highlyPaidStaff =
salesStaffExtent->query(“SalesStaff*”,
“salary > 30000”, db1);
cout << “Retrieval of highly paid staff: \n”;
os_Cursor<SalesStaff*> c(highlyPaidStaff);
for (p = c.first(); c.more(); p = c.next())
cout << p->staffNo << “\n”;
85
© Pearson Education Limited 1995, 2005