Chapter 26Object-Oriented DBMSs - Standards and SystemsTransparencies

Chapter 26 - ObjectivesObject Management Group (OMG) and CORBA.Main features of ODMG Object Standard:Object modelObject Definition Language (ODL)Object Query Language (OQL)Language bindings.Main features of ObjectStore:ArchitectureData DefinitionData Manipulation.

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.

Object Management Group (OMG)Not recognized standards group but aims to develop de facto standards.Defines standard object-based facilities for:Concurrent execution.Distributed transactions.Versioning.Event notification.Internationalization.

Object Management ArchitectureFour 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.

Object Management ArchitectureObject 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.

Object Reference Model

Object Model

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.

CORBA ORB Architecture

Object Data Management GroupEstablished 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.

Object Data Management GroupBetween 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 the Object Database Management Group to the Object Data Management Group to reflect the expansion of its efforts beyond merely setting storage standards for object databases.

Object Data Management GroupUnder its new 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 ODMSs extend programming language with transparently persistent data, concurrency control, recovery, associative queries, and other database capabilities.

Object Data Management GroupMajor 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.

ODMG OM - Basic Modeling PrimitivesBasic 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.

ODMG OM - Basic Modeling PrimitivesProperty 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.

ODMG Object Model - ObjectsObject 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.

Set of Built-in Types for ODMG Object Model

ODL Interface for Objects

ODMG OM - OIDs and Object NamesEach 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.

ODMG Object Model - ObjectsLifetime of an object is orthogonal to its type (persistence is independent of type). Lifetime specified when object is created; may be:Transient: objects memory allocated and deallocated by programming languages runtime system. Persistent: objects storage managed by OODBMS.

ODMG Object Model - LiteralsLiteral is basically a constant, with possibly complex structure.Literal types decomposed as atomic, collections, structured, or null. Values of a literals 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.

ODMG Object Model - Built-in CollectionsContains 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.There are ordered and unordered collections:ordered collections traversed first to last, or vice versa; unordered collections have no fixed order of iteration.

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.

ODL Interface for Collections

ODMG Object Model Atomic ObjectsAny 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.

ODMG Object Model - RelationshipsOnly binary relationships supported.Traversal paths are defined for each direction of traversal. class Branch {relationship set Has inverse Staff::WorksAt}class Staff {relationship Branch WorksAt inverse Branch::Has}

ODMG Object Model - Types, Classes, Interfaces, and InheritanceTwo 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 and 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.

ODMG Object Model - Types, Classes, Interfaces, and InheritanceClass 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.

ODMG Object Model - Types and ClassesClass 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).

ODMG Object ModelObject model also specifies:

Exceptions.Metadata.Transactions.Databases.Modules.

Object Definition Language (ODL)module DreamHomeClass Branch(extent branchOffices key branchNo){attribute string branchNo; .relationship Manager ManagedBy inverse Manager::Manages;void takeOnPropertyForRent(in string propertyNo)raises(propertyAlreadyForRent);}

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();}

Object Definition Language (ODL)class Manager extends Staff(extent managers){relationship Branch Manages inverse Branch::ManagedBy;}

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.

Object Query Language (OQL)OQL can be used for both associative and navigational access:Associative query returns collection of objects. How these objects are located is responsibility of ODMS, rather than the application program.Navigational query accesses individual objects and object relationships used to navigate from one object to another. Responsibility of the application program to specify procedure for accessing the required objects.

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.

Object Query Language (OQL)Expression can take several forms:

Elementary- ConstructionAtomic type- ObjectCollection- Indexed collectionsBinary set- ConversionQuery consists of a (possibly empty) set of query definition expressions followed by an expression.Result is object with or without identity.

Example 26.2 OQL: Extents & Traversal Paths(1) Get set of all staff (with identity):

staff

(2) Get set of all branch managers (with identity):

branchOffices.ManagedBy

Example 26.2 OQL: Extents & Traversal Paths(3) Find all branches in London:

SELECT b.branchNoFROM b IN branchOfficesWHERE b.address.city = London;This returns a literal of type bag.

Example 26.2 OQL: Extents & Traversal Paths(4) Assume londonBranches is named object (from last query). Find all staff who work at that branch:

londonBranches.WorksAt

This returns set.

Example 26.2 OQL: Extents & Traversal PathsBecause of ambiguity over return result, cannot access sales staff salaries using:

londonBranches.WorksAt.salary

Result may be set or bag. Instead use:SELECT [DISTINCT] s.salaryFROM s IN londonBranches.WorksAt;

Example 26.3 - OQL: Use of DEFINEGet set of all staff who work in London (without identity):

DEFINE Londoners ASSELECT sFROM s IN salesStaffWHERE s.WorksAt.address.city = London;SELECT s.name.lName FROM s IN Londoners;

This returns a literal of type set.

Example 26.4 OQL: Use of structures(1) Get structured set (without identity) containing name, sex, and age for all staff who live in London:

SELECT struct (lName:s.name.lName, sex:s.sex, age:s.age)FROM s IN StaffWHERE s.WorksAt.address.city = London

This returns a literal of type set.

Example 26.4 OQL: Use of structures(2) 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 bagDeputies;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.

Example 26.4 OQL: Use of structures(3) 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.

Example 26.5 OQL: Use of aggregatesHow 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);

Example 26.6 OQL: GROUP BYDetermine number of sales staff at each branch:SELECT struct(branchNumber, numberOfStaff:COUNT(partition))FROM s IN salesStaffGROUP BY branchNumber: s.WorksAt.branchNo;

Result is of type: set

Note use of keyword partition to refer to each partition.

OQL - Creating ObjectsA 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: date1945-10-01, salary: 30000)

Language BindingsSpecify 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.

Language Bindings - Creating a Working Application

Language BindingsFeatures 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.

Language BindingsRelationships 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 Has;const char _WorksAt[] = WorksAt;and to represent same relationship in SalesStaff class:d_Rel_Ref WorksAt;const char _Has[] = Has;

Language Bindings - OMLnew 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 tempSalesStaff = new SalesStaff; and to create a persistent object:d_Database *myDB;d_Ref s1 = new(myDb, John White) SalesStaff;

Language Bindings - OQLOQL 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 wellPaidStaff; SaleStaff->query(wellPaidStaff, salary > 30000);

d_OQL_Query q(SELECT s.WorksAt FROM s IN SalesStaff WHERE salary > $1);

d_Bag branches;q

ObjectStore - ArchitectureBased 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 the transaction log, among other tasks. A client can contact ObjectStore server on its host or any other ObjectStore server on any other host in network.

ObjectStore - ArchitectureFor each host machine running one or more client applications there is an associated cache manager process whose primary function is to facilitate concurrent access to data by handling callback messages from server to client applications. Also, each client application has its own client cache, which acts as a holding area for data mapped (or waiting to be mapped) into physical memory.

ObjectStore Architecture

ObjectStore ServerResponsible for:storage and retrieval of persistent data;handling concurrent access by multiple client applications;database recovery.

Client ApplicationObjectstore 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.

Client CacheClient 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.

Virtual Memory Mapping Architecture (VMMA)C++ object is stored in database in its native format with all pointers intact (as opposed to swizzling them to OIDs). Basic idea of ObjectStore VMMA is same as for virtual memory management in operating systems. References to objects are realized by virtual memory addresses. If an 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).

Virtual Memory Mapping Architecture (VMMA)If required page is not in memory, a 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.

ObjectStore manages this process by reserving a range of unmapped virtual memory for persistent objects, thereby ensuring that this range will be used for no other purpose than database pages.

Data Definition in ObjectStoreObjectStore can handle persistence for objects created in C/C++ and Java through separate class libraries, and there is facility for objects created in one language to be accessed in other. For C++, ObjectStore uses C++ as a schema language so that everything in database must be defined by C++ class. In ObjectStore, persistence is orthogonal to type and persistent object support is achieved through overloading new operator.

Data Definition in ObjectStoreAlso 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. In fact, pointers to persistent memory always take form of virtual memory pointers.

Data Manipulation in ObjectStoreFollowing 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.

Roots and Entry Point ObjectsDatabase root provides way to give an object a persistent name, thereby allowing the object to serve as an 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).

Roots and Entry Point Objects

Access Based on a Named RootaBranch = (Branch*)(db1->find_root(Branch3_Root)->get_value(WorksAtType);cout

Iteration of Collections using Cursorsos_Cursor c(aBranch->Has);cout

Lookup of Single Object Based on Value of one or more Data MemberssalesStaffExtent = (os_Set*)(db1->find_root(salesStaffExtent_Root)->get_value(salesStaffExtentType);aSalesPerson = salesStaffExtent->query_pick(SalesStaff*,!strcmp(staffNo,\SG37\), db1); cout

Lookup of Single Object Based on Value of one or more Data Membersos_Set &highlyPaidStaff = salesStaffExtent->query(SalesStaff*, salary > 30000, db1); cout