1. Object-Oriented DBMSs - Standards and Systems Transparencies
Chapter 27
Object-Oriented DBMSs - Standards and Systems
Transparencies
© Pearson Education Limited 1995, 2005

2. 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.
© Pearson Education Limited 1995, 2005

3. 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.
© Pearson Education Limited 1995, 2005

4. 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 to make/receive requests/responses from a provider.
© Pearson Education Limited 1995, 2005

5. 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.
© Pearson Education Limited 1995, 2005

6. Object Reference Model
© Pearson Education Limited 1995, 2005

7. Object Model
© Pearson Education Limited 1995, 2005

8. 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.
© Pearson Education Limited 1995, 2005

9. CORBA ORB Architecture
© Pearson Education Limited 1995, 2005

10. 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.
© Pearson Education Limited 1995, 2005

11. CWM Sub-Metamodels
© Pearson Education Limited 1995, 2005

12. CWM Relational Data Metamodel
© Pearson Education Limited 1995, 2005

13. 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.
© Pearson Education Limited 1995, 2005

14. 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.
© Pearson Education Limited 1995, 2005

15. 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

16. Model-Driven Architecture (MDA)
© Pearson Education Limited 1995, 2005

17. 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.
© Pearson Education Limited 1995, 2005

18. 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

19. 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

20. 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.
© Pearson Education Limited 1995, 2005

21. 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.
© Pearson Education Limited 1995, 2005

22. 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.
© Pearson Education Limited 1995, 2005

23. 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.
© Pearson Education Limited 1995, 2005

24. Set of Built-in Types for ODMG Object Model
© Pearson Education Limited 1995, 2005

25. ODL Interface for Objects
© Pearson Education Limited 1995, 2005

26. 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.
© Pearson Education Limited 1995, 2005

27. 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.
© Pearson Education Limited 1995, 2005

28. 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.
© Pearson Education Limited 1995, 2005

29. 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.
© Pearson Education Limited 1995, 2005

30. 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.
© Pearson Education Limited 1995, 2005

31. ODL Interface for Collections
© Pearson Education Limited 1995, 2005

32. 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.
© Pearson Education Limited 1995, 2005

33. 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}
© Pearson Education Limited 1995, 2005

34. 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.
© Pearson Education Limited 1995, 2005

35. 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.
© Pearson Education Limited 1995, 2005

36. 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).
© Pearson Education Limited 1995, 2005

37. ODMG Object Model Object model also specifies: Exceptions. Metadata.
Transactions.
Databases.
Modules.
© Pearson Education Limited 1995, 2005

38. 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); }

39. 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();
© Pearson Education Limited 1995, 2005

40. Object Definition Language (ODL)
class Manager extends Staff
(extent managers) {
relationship Branch Manages
inverse Branch::ManagedBy; }
© Pearson Education Limited 1995, 2005

41. 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.
© Pearson Education Limited 1995, 2005

42. Object Query Language (OQL)
Can be used for associative and navigational access:
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.
© Pearson Education Limited 1995, 2005

43. 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 with name Q given query expression e.
© Pearson Education Limited 1995, 2005

44. Object Query Language (OQL)
Expression can take several forms:
Elementary - Construction
Atomic type - Object
Collection - Indexed collections
Binary set - Conversion
Query consists of a (possibly empty) set of query definition expressions followed by an expression.
Result is object with or without identity.
© Pearson Education Limited 1995, 2005

45. 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
© Pearson Education Limited 1995, 2005

46. 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>.
© Pearson Education Limited 1995, 2005

47. 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>.
© Pearson Education Limited 1995, 2005

48. 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;
© Pearson Education Limited 1995, 2005

49. 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>.
© Pearson Education Limited 1995, 2005

50. 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”);
© Pearson Education Limited 1995, 2005

51. 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>.
© Pearson Education Limited 1995, 2005

52. 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.
© Pearson Education Limited 1995, 2005

53. 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>.
© Pearson Education Limited 1995, 2005

54. 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”);
© Pearson Education Limited 1995, 2005

55. 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.
© Pearson Education Limited 1995, 2005

56. 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“ ”, salary: 30000)
© Pearson Education Limited 1995, 2005

57. 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.
© Pearson Education Limited 1995, 2005

58. Language Bindings - Creating a Working Application
© Pearson Education Limited 1995, 2005

59. 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.
© Pearson Education Limited 1995, 2005

60. 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”;
© Pearson Education Limited 1995, 2005

61. 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;
© Pearson Education Limited 1995, 2005

62. 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

63. 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.
© Pearson Education Limited 1995, 2005

64. 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>.
© Pearson Education Limited 1995, 2005

65. 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.
© Pearson Education Limited 1995, 2005

66. 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.
© Pearson Education Limited 1995, 2005

67. 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.
© Pearson Education Limited 1995, 2005

68. ObjectStore Architecture
© Pearson Education Limited 1995, 2005

69. ObjectStore Server Responsible for:
storage and retrieval of persistent data;
handling concurrent access by multiple client applications;
database recovery.
© Pearson Education Limited 1995, 2005

70. 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.
© Pearson Education Limited 1995, 2005

71. 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.
© Pearson Education Limited 1995, 2005

72. 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).
© Pearson Education Limited 1995, 2005

73. 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.
© Pearson Education Limited 1995, 2005

74. Building an ObjectStore Application
© Pearson Education Limited 1995, 2005

75. 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.
© Pearson Education Limited 1995, 2005

76. 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];
© Pearson Education Limited 1995, 2005

77. 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.
© Pearson Education Limited 1995, 2005

78. 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;
© Pearson Education Limited 1995, 2005

79. 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.
© Pearson Education Limited 1995, 2005

80. 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).
© Pearson Education Limited 1995, 2005

81. Roots and Entry Point Objects
© Pearson Education Limited 1995, 2005

82. 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”;
© Pearson Education Limited 1995, 2005

83. 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”;
© Pearson Education Limited 1995, 2005

84. 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”;
© Pearson Education Limited 1995, 2005

85. 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”;
© Pearson Education Limited 1995, 2005