Download Object Query Language

The ODMG Standard 2.0
Focusing On
The ODMG Object Model
Group Members: Chris Parrott, Chris Sinclair, David Tucker and
Andrew Wan
Presentation Date: 10th May 2002
Contents
1.0 Introduction ............................................................................................................................................ 4
2.0 Object Model........................................................................................................................................... 5
2.1 About ODMG Object Model ............................................................................................................... 5
2.2 Database Types .................................................................................................................................... 5
2.2.1 Specifications and Implementations ............................................................................................ 5
2.2.2 Inheritance.................................................................................................................................... 6
2.2.3 Type Keys .................................................................................................................................... 6
2.3 Objects ................................................................................................................................................. 7
2.3.1 Object Identifiers ......................................................................................................................... 7
2.3.2 Object Lifetime ............................................................................................................................ 7
2.3.3 Collections ................................................................................................................................... 7
2.3.4 Literal Values ............................................................................................................................... 9
2.3.5 Object Hierarchy .......................................................................................................................... 9
2.4 Modelling State ...................................................................................................................................10
2.4.1 Introduction .................................................................................................................................10
2.4.2 Object Type Interfaces ................................................................................................................10
2.4.3 Attributes & Relationships: .........................................................................................................11
2.4.4 Names: ........................................................................................................................................11
2.4.5 Metadata......................................................................................................................................12
2.5 Modelling Behaviour ..........................................................................................................................12
2.5.1 Introduction .................................................................................................................................12
2.5.2 Operations ...................................................................................................................................13
2.5.3 Exceptions ...................................................................................................................................13
2.6 Concurrency and Transaction Control ................................................................................................14
2.6.1 ODMG View on Locking and Concurrency Control ..................................................................14
2.6.2 Locking Control ..........................................................................................................................14
2.6.3 Types of Locks ............................................................................................................................14
2.6.4 Concurrency Control ...................................................................................................................15
2.6.5 Transactions ................................................................................................................................15
2.6.6 Event Management .....................................................................................................................16
2.6.7 Managing Logical Databases ......................................................................................................16
3.0 Object Specification Languages ...........................................................................................................16
3.1 Introduction ........................................................................................................................................16
3.2 About Object Specification Languages...............................................................................................16
4.0 Object Query Language ........................................................................................................................18
4.1 About Object Query Languages .........................................................................................................18
4.1.1 Using OQL with O2 ....................................................................................................................18
4.1.2 Using OQL in C++......................................................................................................................18
4.1.3 Using OQL in Smalltalk .............................................................................................................19
5.0 Bindings ..................................................................................................................................................20
5.1 The Idea of Bindings ..........................................................................................................................20
5.2 C++ Binding .......................................................................................................................................20
5.3 Smalltalk Binding ...............................................................................................................................20
5.4 Java Binding .......................................................................................................................................21
6.0 Literature Review ..................................................................................................................................22
6.1 Review 1 .............................................................................................................................................22
6.1.1 Summary .....................................................................................................................................22
6.1.2 Review ........................................................................................................................................22
6.1.3 Conclusion ..................................................................................................................................23
6.2 Review 2 .............................................................................................................................................23
6.2.1 Summary .....................................................................................................................................23
6.2.2 Review ........................................................................................................................................23
6.2.3 Conclusion ..................................................................................................................................24
7.0 The New ODMG 3.0 Standard .............................................................................................................25
7.1 Java .....................................................................................................................................................25
7.2 Object Model ......................................................................................................................................25
7.3 Broadening..........................................................................................................................................25
7.4 The Future ...........................................................................................................................................25
9.0 Conclusion ..............................................................................................................................................26
9.1 The ODMG Standard and Its Real World Application .......................................................................26
9.2 Conclusions and Criticisms of the ODMG Object Model ..................................................................27
References ....................................................................................................................................................29
ODMG Standard 2.0 and Object Model
Presentation Report
1.0 Introduction
The Object Data Management Group (as it is called now) was formed in 1991 as the
Object Database Management Group, an independent organisation to standardise Object
Oriented Database Management Systems. It includes corporate members such as Sun,
Poet and Computer Associates. The first version of the standard arrived in 1993. The
second and major release was in 1997. The current version is 3.0 and is dated 1999. The
standards are published as paperback books.
The group is not a formal standards committee like ISO or ANSII, believing instead that
they can make faster progress than an official standards body. The nearest a formal body
has come to defining a similar standard is ANSI and the ANSI X3H2, but this is more an
extension to existing relational database standards and does not deal exclusively with
OODMS. The ODMG standard was initially focused on defining a common database
interface for the products produced by vendors who were involved in the group so that
their products would be able to support a degree of portability in the applications that
used them and interoperability between their respective products.
The ODMG standard covers the following key areas within Object Database
Management Systems (ODBMSs):
 Object Model (OM)
 Object Definition Language (ODL)
 Object Query Language (OQL)
 C++, Java and Smalltalk bindings
It is the object model that determines the semantics that the OODMS understands and
supports and therefore it is also the object model that allows the porting of applications
and designs between ODMG compliant systems. Hence this report will be focusing on
the object model.
4
ODMG Standard 2.0 and Object Model
Presentation Report
2.0 Object Model
2.1 About ODMG Object Model
The Object Model as defined by the ODMG (Object Data Management Group) standard
is essential as it is a specification of the different semantics which ca be explicitly defined
to an Object Database Management System (ODBMS). This ensures that constructs
defined in Object Definition languages (ODL) are supported by the ODBMS. The
ODMG Object Model also provides a definition of an ODBMS’s functionality.
The semantics of the model identify an object’s characteristics, the naming policies of
objects, how they are identified and the relations between objects. Essentially, the
ODMG Object Model indicates the intension of the objects to be created and the
relationships they will have with each other. In such an example, an application being
developed using constructs from the ODMG Object Model to create the application’s
object model (i.e. database (logical) schema). The model would contain the specification
for different types it would allow such as, Author, Document, Map and Title with the
inclusion of the properties and operations these types could have.
Compared to relational database object models, the ODMG object model has more
complex semantics, especially for matters such as relationship declarations, operation
construction and transactions to support database functionality.
2.2 Database Types
2.2.1 Specifications and Implementations
An object’s type definition always consists of two components; these are the interface
and one or more implementations. The interface describes the external appearance of the
type and the implementation consists of the properties and the methods that implement
the operations. The interface is the public part of the type, while the internals of the
implementations are not visible to the user.
Interface (or abstract) - this is an implementation-independent description of all the
operations and properties that are visible to the users of the type. It is used to describe the
behaviour of the type but the definition of the type’s state is usually defined in the class
specification.
Implementation - the methods are procedure bodies that specify the types behaviour when
in certain states. The code implementations for each of the operations in the interface
appear here and therefore this is the implementation of the visible behaviour of an object
type. These operations made read or modify the object in some way or call on operations
in other objects to be invoked.
5
ODMG Standard 2.0 and Object Model
Presentation Report
U
er
Us
r
se
Interface
v isible to the users of the ty pe
not v isible to the users of the ty pe
Implementation
Class
Us
er
er
Us
Figure 1: Type Specification
2.2.2 Inheritance
The ODMG object model supports the idea of inheritance through type-subtype
relationships. This type-subtype relationship is know as a ISA relationship in the ODMG
standard as it creates a is-a relationship when applied in a ‘real’ world situation (e.g. An
Employee is-a Person, when person is the type (supertype) and employee is the subtype).
The subtypes interface may define characteristics in addition to those defined in its
supertypes. These new states or behaviours can then only be applied to the instances of
the subtype. The ODMG Object Model supports multiple inheritance of object behaviour
and it is therefore possible for objects to inherit two operations of the same name. In this
case, the parameters for the operations must be of different types for the type definition to
be ODMG compliant.
In addition to the ISA relationship the Object Model also defines the use of the Extends
function. This unlike the ISA relationship is not concerned with behaviour but the
inheritance of state. This is a single inheritance relationship where the secondary class
inherits all the properties and behaviours of the class it extends.
2.2.3 Type Keys
Occasionally the individual instances of a type can be uniquely identified by the value
they carry for a certain property or set of properties. These properties are know as keys
with instances having either candidate or compound keys as found in relational systems.
6
ODMG Standard 2.0 and Object Model
Presentation Report
2.3 Objects
2.3.1 Object Identifiers
The ODMG object model standard dictates the most important feature of object-oriented
systems is the identification of the objects. Each object in the system is identified
uniquely using the object identity; this identifier is generated by the system and it is
unique to that object with invariance to the objects lifetime. The identifier is never visible
to the user or the programmer who is using the database.
Object Identifiers are used ensure that software developers are able to map real world
entities into database representations. The principal advantages of object oriented
systems over relational database systems is that objects representing information are kept
collectively rather than spread over a number of tables with foreign keys bringing them
together
2.3.2 Object Lifetime
The lifetime of an object determines how the memory and storage allocated tot the object
is to be managed. This is to be specified at the time the object is created and can be either
transient or persistent.
Objects with transient lifetime are allocated memory by the programming language
system at run-time. If they are transient objects declared in the method of an object then
they will be allocated memory in the stack when the method is invoked. This memory is
later released when the procedure is complete and returns. Other objects created by
processes are allocated either static memory or placed on the heap. When the whole
process terminates only then will the memory area be released.
Persistent objects are allocated memory and stored by the ODBMS run-time system. This
objects will continue to exist after the method or process terminates and can therefore be
referred to as the database objects.
An important feature of the ODMG standard is that object lifetimes are independent of
type. For this reason a type may have some instances that are persistent and others which
are transient. The ODMG feel this is an important feature to be incorporated into all
compliant object databases.
2.3.3 Collections
In an object oriented database environment, multi valued properties require collections.
The ODMG object model standard supports five kinds of collections. Sets, bags, lists,
arrays and dictionary; these five types of collections are constructed as types and then
parameterised on the element type.
2.3.3.1 Collection Objects
These must be composed of distinct elements all of which must be of the same type.
Collection objects can be created by calling upon the operations of the CollectionFactory
interface. The new_of_size operation creates a collection with a given size, this reserves
7
ODMG Standard 2.0 and Object Model
Presentation Report
the specified amount of storage space for its elements. The interface for the collection is
illustrated below:
interface CollectionFactory : ObjectFactory {
Collection new_of_size(in long size);
};
2.3.3.2 Set Objects
A set according to the standard is an unordered collection of elements but no duplicates
of elements are allowed. The Set interface has conventional mathematical operations
such as union, intersection and difference. All these operations return a new Set object
made up of the items in the collection that fit the operation specified.
2.3.3.3 Bag Objects
The Bag is an unordered collection of elements, which may be able to contain duplicates.
It holds the same mathematical operations of the Set interface but has an insert function
that will allow duplicates and thus increases the multiplicity in the bag.
2.3.3.4 List Objects
This is ordered collection of elements with a whole multitude of operations in its
interface. Most of these operations use indices to identify the required item in the
collection or references to the start/end of the List object are used.
2.3.3.5Array Objects
ODMG states that the Array object is:
“A dynamically sized ordered collection of
elements that can be located by position.”
[ODMG 2.0, 1997]
It is a variable length array which has operators in its interface to retrieve and change the
upper bound so its size can be altered.
2.3.3.6 Dictionary Objects
Dictionary objects are an unordered sequence of key-value pairs with no duplicate keys.
Each key-value pair is constructed as an instance of the following structure:
struct Association {Object key; Object value; };
By iterating over a Dictionary collection the resultant action will be to iterate over a
sequence of Associations.
The dictionary collection is often used to carry the class-structure definitions for objects
in the database. The database server must have a dictionary to understand the structure of
the objects stored in the database.
8
ODMG Standard 2.0 and Object Model
Presentation Report
2.3.4 Literal Values
The ODMG object model standard requires distinction between objects and literal values.
Literal values are normally used to facilitate storage but despite their complex structure
with multiple components they do not have an object identity. To find them, the system
needs to know their address, any reference to the literal will be via this address.
In contrast to this, Objects have an object identifier and can be found ultimately by using
the object table. One advantage of this is when objects are shared so that multiple
references to an object exist.
The ODMG Model Supports several literal types these are:



Atomic - these take the form of numbers and characters and they exist implicitly.
Such literals are float, double, boolean, string, long etc.
Collection - type generators similar to collection objects without object
identifiers.
Structured - has a variable name and can contain either a literal value or an
object.
It is important to realise the factors when trying to copy literals. As literals do not have
Object Identities and therefore cannot be shared, literals do have copy semantics. When
iterating through a collection of literals, copies of the elements are returned.
Also the standard implies certain factors which affect the comparing literals. Since
literals are not objects they cannot be compared by identity (same_as operation) they are
compared using the 'equals' equivalence operation. This becomes important for collection
management, when inserting, removing, or testing for membership in a collection of
literals.
Worked example
Two literals, a and g, are only equivalent if they have the same:
 literal type
 if a and g are both atomic
 both contain the same value
2.3.5 Object Hierarchy
In order to create a database schema, a mechanism is required to define the structure of
the data. The ODMG Object Model is very strongly typed and each object/literal must
have a type. This is achieved by relating the interfaces to a set of object types by the use
of a type hierarchy. In order to define a type interface, it is essential to specify the object
name, the name of its super classes, type of properties and attributes of the class.
9
ODMG Standard 2.0 and Object Model
Presentation Report
2.4 Modelling State
2.4.1 Introduction
When developing the schema, the first task is always to provide a description of the data
structure. In an object oriented data model this often means relating the interfaces to a set
of object types in a type hierarchy.
2.4.2 Object Type Interfaces
As mentioned above, the object type interface describes the structure of the data, how the
data can be stored, manipulated and its relations to other types of data. In order to define
an object type interface, it is required to specify a name, attributes belonging to the class,
the names of its super classes, certain type properties and operation interfaces.
Person
-Class Properties
Person_name
Person_bloodty pe
-Class Operations
Employ ee Extends
Person
+returnName()
+getBloodty pe()
-Class Properties
Company
-Class Properties
Employ ee_number
Employ ee_dob
Employ ee_salary
Company _Name
Company _Address
theEmploy ees
-Class Operations
-Class Operations
Work_For
+getName()
+getDOB()
+iSalary (aAmount)
+getName()
+printEmploy ees()
+employ (aEmploy e
e)
Figure 1 type diagram of object type definition
When defining interfaces for objects, there are three kinds of properties that can be
defined, they are: an extent, the key and an indication of the level of persistence among
the instances named persistence indicator.
Extent type property definition is a collection of all the instances collected by the system
which will be automatically maintained by the system. Extent is optional and many types
do not require maintenance. However, it does not mean instances will not be stored or
cannot be stored; simply this task will not be carried out automatically, this also applies
to all instances kept together in a collection. The motivation behind the definition of
extents is to provide a persistent root from where a preparatory point of accessing the
database is provided. This is similar to the names provided on the tables in a relational
database system.
A key property definition is a data value created from properties of a type. There are two
types of keys; the differences between them are in their complexity. A simple key uses
only one property while a compound key uses more than one property. Attributes and
relationships can be used as keys.
10
ODMG Standard 2.0 and Object Model
Presentation Report
The persistence indicator of a type as it name suggests provides a specification of the
expected lifetime of instances by that type. Currently, there can only be two indication,
they are ‘persistent’ or ‘transient’
2.4.3 Attributes & Relationships:
The ODMG data model identifies two kinds of properties, they are attributes and
relationships. Attribute is a property belonging to an object while a relationship is a dual
link between two objects with bi-directional linkage. Neither an attribute nor a
relationship can be isolated on its own; hence attributes cannot be stored independently
from object.
The ODMG object model provides three kinds of binary relationships. They are one-toone, one-to-many and many-to-many.
A one to one relationship provides the pairing of single valued object classes by which it
would pair two instances together. A one-to-many relationship allows the pairing of
single valued classes with a collection class. When pairing with instances, the
relationship pairs an instance with a collection. Many-to-many relationships allow the
pairing of two collection classes while with instances; the relationship pairs up two
collections.
Employee
Company
WorksFor
One To One Relationship
Company
Employee
theEmployees
N
One To Many Relationship
Departments
Manager
N
theManagers
theDepartments
N
Many To Many Relationship
Figure 2 Example of relationships
2.4.4 Names:
The Names provide a useful way to identify individual objects and give them a name to
distinguish them from other objects. Besides this, because names are independent of any
particular database, they are part of the schema rather than the database itself. In the
ODMG model, an object can be given one or more names, though the same name cannot
be applied to more than one object. One of the most important features of named objects
is that they become persistent root objects which can be used for database access. In the
ODMG model, persistent roots can only be extents of object types or named objects.
11
ODMG Standard 2.0 and Object Model
Presentation Report
Employee
Employee
jeff
bob
Name = jeff
Dept_employ=
It_support
Name = bob
Dept_employ=
It_support
Department
It_support
Name = It_support
Employees = jeff, bob….
Figure 3 representation of how object names can be used to represent entities with shared
components
2.4.5 Metadata
Metadata is descriptive information about persistent objects that defines the 'schema' of
an ODBMS. metadata is used by ODBMS to define structure of its object storage, and at
runtime, guide access to ODBMS's persistent objects. Metadata is stored in an 'ODL
Schema Repository', which is also accessible to tools and applications using the same
operations that apply to user-defined types.
Metadata is considered important for object oriented database systems because it permits
the system to generate administration data for the non-specific user interfaces to be built
with out prior knowledge of databases that are to be used. One of the main reason for
using metadata classes is for its operations. An example of this would be an operation
that returns the class of an object.
EmployeeMetaData = William->getClass( )
The above operation will store the description of employee class into EmployeeMetaData.
Thus the EmployeeMetaData will hold information, operations and attributes of employee
class. Hence it is possible to use EmployeeMetaData to print the employee’s name as the
getName function is part of the employee class.
EmployeeName = EmployeeMetaData ->getName( )
2.5 Modelling Behaviour
2.5.1 Introduction
An object’s behaviour is defined by its set of operations, which can be executed on or by
the object. These operations can be parameterized to include input and output data. Each
operation has its specific type defined and can return a typed result. Operations
manipulate data at the lower level and these create foundations from which queries and
12
ODMG Standard 2.0 and Object Model
Presentation Report
transactions are created. Transactions make atomic changes to the database in order to
maintain its consistency.
2.5.2 Operations
Operation is described as a piece of code fragment that manipulates the properties of an
object. Two parts are composed into making an operation; they are the interface and the
implementation which can have more than one. The interface of an object describes the
parameters that it takes and the output it returns, also, the interface is described as the
type interface. Implementation is composed of lines of code which manipulates the data.
The ODMG model makes no mention about operations of updates on data within the
class.
Employee
Void
+salaryIncrease(aAmount)
-Operation salaryIncrease defined in Employee class increases the salary
property with the specified amount entered as a parameter. The operation does
that return anything.
Company
Void
+employ(aEmployee)
Employee
theEmployees
-Operation employ defined in Company class sets a employee instance into
theEmployees. Thus adding a employee to the company. The employee instance
is passed as a parameter to the operation. The operation does not return
anything.
Employee
Date
+dateOfBirth()
-Operation dateOfBirth returns the employee’s date of birth after calculation. The
operation accepts no parameters and returns a date type.
Figure 4 the types of operations
2.5.3 Exceptions
In normal situations, flow of control of an object-oriented program contains sequences of
operations. The program calls an operation from an object which may contain a routine
to call other operations. When the operation is completed, control is returned back to the
object that called the operation and proceeds to the next instruction in the code. This is
known to be a productive way to structure programs; however, the above structure makes
certain programming tasks difficult. One of which is to make operations react differently
to certain situations. Although this can be solved by implementing conditions and tests at
certain areas of the code, it would complicate the program causing errors and difficulty in
debugging due to the complexity of the program. The programming of these conditions
would become tedious if it goes very deep and often requires the aborting of many
surrounding operations which would increase the possibilities of errors.
13
ODMG Standard 2.0 and Object Model
Presentation Report
The solution to the above problem is to care for each sequence of events as an ordinary
one, while others is regarded as exceptional. Each operation is programmed to deal with
only an ordinary case while an exceptional event signalled by the system is used to cope
with other situations and data is passed back which indicates the reason for the exception.
The program will then locate the proper software based on the data returned by the
exception to take charge of the exceptional situation. An exception is made up of three
components, they are event, exception handler and exception data. The event is the cause
of the exceptional situation to occur. Exception data is the structure containing the
information for the reason of the exception and the exception handler is a piece of code
that deals with the exception in some way depending on the exception data returned.
2.6 Concurrency and Transaction Control
2.6.1 ODMG View on Locking and Concurrency Control
The ODMG Object Model uses a conventional lock based approach to concurrency
control. The approach provides a mechanism for enforcing shared or exclusive access to
objects. The ODBMS grants a lock only if no conflicting locks exist. As a result of this
access to persistent objects is coordinated across multiple transactions, and a consistent
view of the ODMS is maintained for each transaction.
2.6.2 Locking Control
Locking is essential in maintaining concurrent data and providing un-interfered multiple
user access. Currently, most OODBMS supports two phase locking, a mechanism that
locks data while it is being accessed and only released when a transaction commits.
Under the ODMG data model standards, it is vital that the transaction also deals with
deadlock detection. This is to prevent access to data from non-terminating waiting
transactions. Other locking procedures such as optimistic locking are also used;
optimistic locking makes modifications to copies of the data thus leaving the source
unlocked. The modified copied data is only moved back to its source when the
transaction commits.
2.6.3 Types of Locks
There are various types of locks outlined in the ODMG standard 2.0. The following locks
are supported in the ODMG Object Model:
1. read locks- allow shared access to an object
2. write locks- indicate exclusive access to an object. Readers of the object do not
conflict with other readers, but writers conflict with both readers and writers.
3. upgrade locks - used to prevent a form of deadlock that occurs when two
processes both obtain read locks on an object and then attempt to obtain a write
locks on that same object. Deadlock is avoided by initially obtaining upgrade
locks, instead of read locks, for all objects that the user intends to modify. This
avoids any potential conflicts when a write lock is later obtained to modify the
object
14
ODMG Standard 2.0 and Object Model
Presentation Report
2.6.3.1 Lock Duration
According to the standard all locks used, whether they are read, write, or upgrade, are
held until the transaction is either committed or aborted. This is outlined so to prevent
dirty reads, non-repeatable reads, and phantoms.
2.6.4 Concurrency Control
The OODBMS has a facility to maintain concurrent data across the database. This is to
allow multiple users to access and manipulate their rights to the data without interference
from the multiple accesses. To achieve concurrent control, each data access is organised
into transactions and each transaction locks the data it is using, whether it would be
update, write or read.
2.6.5 Transactions
All programs that implement persistent objects must be organised into transactions. The
management of these transactions is an important part of the ODBMS functionality and
also play a fundamental role in strict data integrity, shareability, and recovery. The use of
functions such as creation, modification, and deletion of persistent objects must be done
within the scope of a transaction. Once the transaction commits, the ODBMS guarantees
that changes made by the transaction are never lost. The effects of the committed
transactions are then preserved even in the case of failures of storage media, loss of
memory or system crashes. To keep the database consistent a whole transaction must take
the ODBMS from one internally consistent state to another internally consistent state.
This may result in a short amount of time when a state of inconsistency is reached.
However, the isolation of the transaction guarantees that no other users see changes made
by another transaction until it commits.
The ODMG data model supports the traditional ACID (Atomicity, Consistency, Integrity,
and Durability) transactions; this enables transactions to lock the data during access to
maintain high consistency and allow multiple readers but a single writer. The
transactions have five operations, they are: begin, commit, abort, checkpoint and abort to
top level.
The begin operation initiates the transaction with the specification of the control protocol
where it is allowed. The commit operation completes a transaction thus releasing all the
locks held by the transaction and allows the changes made by it accessible to other
transactions. The abort operation quits the transactions and releases all the locks and
undoes any changes made to the data. The checkpoint makes changes permanent but
does not release locks or quit the transaction. Abort to top level quits the transaction and
undoes changes to the current transaction and all the transactions in which the current
contains.
Transactions are started with the begin transaction command and is similar to the new
command when creating objects. Transactions can only be initiated and started
explicitly; they do not start up automatically when a current transaction ends or when the
application starts up.
15
ODMG Standard 2.0 and Object Model
Presentation Report
2.6.5.1Distributed Transactions
A distributed transaction is one which spans multiple processes and/or multiple
databases. Such transactions are not outlined in the ODMG Standard but for compliancy
users are pointed to the OMG Object Transaction Service and ISO XA. Although it is not
necessary to support distributed transactions if used they must be ISO XA-compliant
2.6.6 Event Management
The major advantage of OODMS is the ability to include code which brings about the
execution of effects when certain changes are made to the data. There are many kinds of
events that are managed by the OODMS, they are: object creation, object removal,
property update or in general, any changes which sets a predicate to true. Management of
events allows the trigger of code in order to perform tasks based on the effects of data.
2.6.7 Managing Logical Databases
The ODBMS may manage one or more logical databases, each of which may be stored in
one or more physical persistent stores. All of these logical databases are instances of the
type Database, which are outlined in detail in the ODMG Standard. Instances of the type
Database are created using the DatabaseFactory interface. Once a Database object is
created using the new operation, it can be manipulated by using a whole range of
functions available in the Database interface.
The Database type also supports operations that are designed to aid the administration of
the whole system. Such operations include delete, move, copy, backup and restore all of
which should be used to keep the database in ‘good order’.
3.0 Object Specification Languages
3.1 Introduction
Object specification languages are used in the representation of ODMG compliant object
database management systems. The OSL are independent languages which are used in
the definition of schemas, state of objects in the database and definition of operations.
The main objective of these independent languages is to aid in the service of portability
of databases across ODMG compliant implementations and also provide the
interoperability of OODBMS from different and multiple vendors.
One of the main OSL languages is ODL (Object Definition Language); there is also OIF
(Object Interchange Format).
3.2 About Object Specification Languages
The ODL is used in the definition of specifications of the object types that confirms to the
ODMG object model. ODL is a specification language which has several doctrines that
has helped it in its development. The ODL should support all semantics constructs from
the ODMG object model. ODL’s intention is not to fulfil the role of being a full
programming language; its role is simply for defining object specifications. In order to
16
ODMG Standard 2.0 and Object Model
Presentation Report
provide interoperability, its programming language should be independent and
compatible with the IDL (Interface Definition Language) from OMG (Object
Management Group). The ODMG object model also specifies that ODL should be
extensible; this is to ensure future functionality and physical optimizations.
Traditionally, DBMS have provided utilities that support data definition using a DDL
(Data Definition Language) and DML (Data Manipulation Language). The DDL gives
the users the capability of defining their own data types and interfaces. The DML on the
other hand allows programs to create, delete, move, copy, read and change etc. instances
of those object types.
ODL can also be thought of as a DDL for object types where it handles the definition of
type characteristics, properties and operations. ODL however only provides a definition
of signature of operations and hence does not handle the methods that implement the
operations. To provide interoperability and portability, ODL is used to define object
types that can be implemented in various programming languages hence ODL is not
integrated with any syntax of any specific programming language. ODL is used
independently from any programming language environment, this is so that any schema
defined using ODL is supported by a variety of ODMG complaint ODBMS. The aim is
to allow applications to be run on different ODBMS with absolute least and minimal
modification towards the application code.
The syntax of ODL is extended from IDL. IDL itself was heavily influenced by C++
thus IDL is a deeply flavoured C++ language. The progressed developments of ODL
lead to the addition of constructs which are required to specify the complete semantics of
the ODMG data model. A context used in integrating schemas from multiple
applications and sources is also provided by ODL. These schemas may have been
developed with many object models defined and created using data definition languages.
This common basis for integration of schemas from multiple sources by ODL allows a
common semantics despite the different models.
17
ODMG Standard 2.0 and Object Model
Presentation Report
4.0 Object Query Language
4.1 About Object Query Languages
The query language OQL, has been developed by the ODMG for use with ODMG
databases. A query language provides a mechanism by which a user can request a subset
of the data from a database, such a request being called an ad hoc query. The query
identifies a part of the data either explicitly by naming the parts to be returned or
implicitly by specifying conditions which must be met by any data being returned
Firstly, the Object Query Language (OQL) is part of the SQL family of languages.
Therefore the most frequent query written in OQL has the well-known ‘Select . .From .
.Where . .’ makeup.
OQL is a superset of the ‘Select’ query syntax of SQL and is purely for writing queries.
For this reason it has no facilities for supporting data definition, constraint specification,
data manipulation or any other data management tasks. Like relational SQL it is not
computationally complete but it is declarative and hence optimisable. The result of a
query is usually a collection of values, but a query may instead produce any single value
as its result. Thus a query can return a list, a record, an integer or a single object.
OQL has be designed to support two kinds of usage within OODBMS systems, these are:

Using an OQL interpreter - the querying facility is provided interactively to the
user and the results are displayed immediately.

Embedded in a program - the queries are written as part of the program and the
results returned to the program. Execution of a query now takes the form of a function
call with the results being used by the calling program in whatever way is required.
Although OQL does not provide updates, a query can call upon an operation of an object.
This operation could then cause an update to occur.
OQL is defined as an abstract language, albeit one with a well-defined syntax. Each
OODBMS implementing the ODMG proposal may well provide a slight variant of this
basic syntax.
4.1.1 Using OQL with O2
O2 provides OQL as an incorporated element of its OODBMS. There is not just a single
interface which provides access to an OQL interpreter, improved with an embedded
language processor. Instead, there is a query processor component in O2, which is
accessible from any other tool as required.
4.1.2 Using OQL in C++
To use OQL in a C++ , the function d_oql_execute is used. There are two ways of
including OQL queries in the ODMG standard C++ binding. Firstly, by using the query
operations defined in the class Collection. Also, by using one of a family of free-standing
functions, collected together as the overloaded function ‘oql’.
18
ODMG Standard 2.0 and Object Model
Presentation Report
4.1.3 Using OQL in Smalltalk
Access to OQL within a Smalltalk program is provided via a method defined on the
Database class. The Database class has a special operation, query : withArguments,
which executes a query.
19
ODMG Standard 2.0 and Object Model
Presentation Report
5.0 Bindings
5.1 The Idea of Bindings
A language binding creates a association between the run-time system of a programming
language and the persistent store of a database system. The binding usually takes the
form of a library of functions which access the DBMS functionality. The ODMG
standard implements bindings based on its one fundamental principle that:
“The programmer should perceive the binding as a single
language for expressing both database and programming operations,
not two separate languages with arbitrary boundaries between them.”
[ODMG 2.0, 1997]
5.2 C++ Binding
The ODMG standard for the way in which C++ should be used in an ODMG-compliant
DBMS includes classes for types, collections, databases and transactions. Also there are
more general classes for persistence, syntactic extension for relationship inverses, plus
two ways to use OQL from within the language. Within the standard the appears to be
some differences in the ways in which persistent and non-persistent data are referred to.
Persistence is only implement by using the by reference template class instead of the
usual pointer notation.
This binding standard is by no means rigid and holds a great deal of flexibility, each
compliant system will provide their features in its own individual way. A number of the
features of the ODMG model are not found in the C++ standard binding. This does not
mean that such features will not be supported by C++ in an ODMG-compliant system,
merely that there is no standard recommendation for how to achieve this. It also does not
provide facilities for creating databases or indexes. But, the standard does provide
features for using databases once they have been created and for defining queries .
The C++ binding of the Object Definition Language (OML) is expressed as a library, this
provides classes and functions to implement the concepts defined in the ODMG object
model. OML is the language used for retrieving objects from the database and modifying
them. ODL and OML do not discuss the physical storage of objects. For this reason, it
does not address the clustering or memory management issues of objects or access
structures; like indices used to speed up object retrieval. An additional set of constructs
called physical pragmas are used to give the programmer some direct control such
storage issues.
5.3 Smalltalk Binding
While no ODMG Smalltalk language standard exists at this time, the member
organisations do participate in the ANSI Smalltalk standards committee. It is expected
that once these standards are agreed to and commercial implementations become
available then an ODMG Smalltalk binding will evolve to accommodate them.
20
ODMG Standard 2.0 and Object Model
Presentation Report
5.4 Java Binding
This is the binding between the ODMG Object Model and the Java programming. There
is a single unified type system shared by the Java language and the object database;
individual instances of these common types can be persistent or transient.
The binding standard respects the Java language syntax, meaning that the Java language
will not have to be modified to accommodate this binding. It also appreciates the
automatic storage management semantics of Java. This is that objects will become
persistent when they are referenced by other persistent objects. Java binding also
provides persistence by reachability, meaning on database commit, all objects reachable
from database root objects are stored in the database.
The ODMG standard supports both pre/post processor and interpreter implementations.
These are ways to declare persistence-capable Java classes . As standard supports full
Java syntax, the Java binding must be able to use special classes understood by the
database system. These classes are called persistence-capable classes. They can have both
persistent and transient instances. Only instances of these classes can be made persistent.
There are a number of groups working on creating persistent versions of Java, since the
World Wide Web access mechanisms are increasingly being created in Java. Because of
this, Java is the next language for which the ODMG is intending to create a standard
binding.
21
ODMG Standard 2.0 and Object Model
Presentation Report
6.0 Literature Review
6.1 Review 1
[Alagic, Suad. (1997) The ODMG Object Model: Does it Make Sense? OOPSLA (ACM
Conference on Object-Oriented Programming, Systems, Languages, and Applications)
USA]
6.1.1 Summary
This highly technical article criticises many aspects of the ODMG object model version
1.2 and version 2.0. Topics covered include the type-checking system, the formality of
the language bindings and its discrepancies with the object model and non-orthogonal
persistence. The first half of the paper consists of the highlighted problems and proposed
solutions. The second half documents formal language schemas for the specification of
the bindings.
6.1.2 Review
Suad Alagic clearly states in his introduction what he considers to be the shortcomings of
the ODMG object model and where it fails to clearly define issues involving type
checking. He attributes the problems of the model to its intent of providing a common
platform to languages that vary widely in their type system, specifically C++ and
Smalltalk.
After the introduction the author’s first target is the type “any”, which is listed
everywhere in the object model, and he indicates straight away that references to “any”
should be replaced with references to Object. He continues by highlighting the issues that
arise from the use of “any”. I agree with him on this point wholeheartedly and would like
to see a resolution to this ambiguous type as it is not present in Java or C++.
Next up is a criticism of persistence in the model and how it s not orthogonal. Mr Alagic
devotes nearly three pages to this important subject. He talks about the C++ and Java
bindings giving one or two simple examples to illustrate his argument and suggests that
all objects should inherit persistence capability and be query-able through a simple
“is_persistant” message interface. He goes on to criticise the namespace, declaring it to
be inefficient and lambastes object identifiers. It is at this point that he seems to barely
hide his contempt for the ODMG standard.
The following section deals with self-types and how they are used to get around strong
typing. Here, Alagic says the model is too rigid and that although the model supports
self-types it is flawed because of the copy constructor. This section is hard to follow as it
covers several sub-topics with boundaries that blur.
The fifth section on parametric interfaces or class templates, which the object model does
not support, is quite complicated. This is an issue for Java as it does not have parametric
classes in the language specification whereas C++ does. A fair amount of code snippets
are used to push his argument that a generic and parameterised interface should be
22
ODMG Standard 2.0 and Object Model
Presentation Report
explicitly supported. This seems to make sense, but the underlying reasons become more
complicated and are discussed in the next section, which unfortunately leaves the reader
unclear as to the conclusion on this particular point.
And the passages on higher order typing that follow loose this reviewer completely as
Alagic goes on about F-bounded polymorphism. I think this part requires further
explanation and could well have enough scope for a separate paper because of the
complex references given.
The seventh part is about reflection; something that is present in Java. This is split into
two areas covering type reflection and linguistic reflection. Whereas most of the paper
comments on ODMG version 2.0, here it does not owing to “time constraints” as the
author puts it. This is a shame because a major enhancement in 2.0 is the meta objects
which may or may not influence the discussion presented.
The rest of the paper (7 pages) present schemas that formalise the solutions presented in
the article. I cannot comment on the schemas as they are beyond my present knowledge,
however they look complete and if they are as forthright as the rest of the paper then they
will probably be concise.
6.1.3 Conclusion
I found the article difficult reading mostly due to its technical nature but also in part to
the author’s confidence. I think that the gravity of Suad Alagic’s reasoning requires
greater explanation with more comparisons against commercially available ODBMSs.
His style was very confrontational which I found off-putting and condescending and
which may detract from his important contribution to the ODMG standard.
6.2 Review 2
[Chaudhri, Akmal B.(1997) Experiences Using Object Data Management In the Real
World. OOPSLA 1997 Workshop]
6.2.1 Summary
This article is a summary of presentations given about commercial case studies involving
object databases. This workshop was held at OOPSLA ‘97 (ACM Conference on ObjectOriented Programming, Systems, Languages, and Applications) in Atlanta, USA.
6.2.2 Review
The first section of the paper recounts experiences with ObjectStore when used as a
Scientific Data Management system (SDM). Users disliked unsafe pointers, the fact that
clusters were hard coded and the limitations with forms and the developer kit but overall
felt it was superior to relational DBMSs.
The next section demonstrated experiences using an OODMS with CORBA. Problems
included how to located a database object for a particular CORBA object, which was
solved by adding a tag to the object with the Persistence Service. To improve efficiency a
23
ODMG Standard 2.0 and Object Model
Presentation Report
Federated Database mechanism was employed and I/O requests were batched. Other
compromises with the OODMS meant that alternative methods were used to handle
security and access.
What followed regarded the use of object technology with the now defunct Iridium
system, which was supposed to provide a global mobile phone and data structure. The
passage focussed on the System Control Segment (SCS) and the use of Objectivity/DB.
The results were considered a great success thanks to the good integration of the DB with
other components.
The case of EDF, a French organisation was highly praised by its users. The task at had
required the storing and indexing of hundreds of thousands of text files with multimedia
primarily formatted in SGML (forerunner to XML). The OODMS O2 was used an was
applauded for its speed at recursively traversing trees with an average of 1,000 objects
though its text searching services had to be augmented with a different product.
What followed this was a report on the presentation given by Saud Alagic about O2 and
the ODMG standard. I will not go into this as it covers the same arguments outlined in
the other literary review elsewhere in this report.
Another case study of using an OODMS, this time using ObjectStore, highlighted the
issue of switching from a relational system to an OODB based system. The more serious
problems stated were: using the relational model as a basis for the object model which
resulted in too many classes, misuse of object deletion, creating an overly complex
schema and synchronisation and evolution of schema. The conclusion was that issues
regarding integration, architectural and deployment strategies were simply not foreseen.
The last two examples concern mapping of objects from database to database. The first
looked at clients taking certain objects for remote work and then feeding them back into
the system. The solution to this and surrounding issues related to updates was to use a
framework with various rules and guidelines. The other example concerned the mapping
of an OODBMS to a relational one. The results in this case were not so satisfactory as
there were few obvious conclusions due partly to the conservative attitude of the client - a
commercial bank.
The conclusion of this article ends by saying that on the whole there were a lot of positive
things to say about ODBMSs, but that there where problems but those could be
overcome.
6.2.3 Conclusion
Chaudhri’s article seems to be biased towards favouring object databases and his
summaries might have been more effective if he concentrated on significant points, but
since the presentations were case studies he has chosen to be verbosely informative. I
think some probing questions would have been useful in qualifying the experiences.
24
ODMG Standard 2.0 and Object Model
Presentation Report
7.0 The New ODMG 3.0 Standard
The change from 2.0 to 3.0 signifies a refining of the standard as there are few additions.
1. Java binding has been enhanced and is now more complete
2. There are minor improvements to the object model
3. The standard has been broadened for use by object-relational mapping systems as
well as object DBMS’s.
7.1 Java
Support has been moved up from Java 1.2 to cover Java 2. Binary relationships are now
supported, previously there was no support for relationships. The Java binding now has a
mapping for the Dictionary Container. What where previously vendor specific
implementations have now been moved into the odmg.org Java package. The
specification for the Java binding now correctly uses Java 2 syntax and naming
conventions e.g. capitals for constants.
New is the specification of ‘Property files’ which allows another method for addressing
persistence of Java Classes. However it is implementation specific as to the name of these
files and how they are used.
7.2 Object Model
Collections now have factory methods specified for each collection whereas before this
was inherited. Collections are now defined as classes rather than interfaces. Added to 3.0
is the atomic literal long. 3.0 now specifically talks about the copying, comparison and
equivalence of literals and it does this in a way that is similar to Java.
The meta data section has been expanded to include Visitor objects as a means of
traversing the meta data itself by double dispatching. The definitions of meta objects has
changed slightly in that some exceptions are no longer listed. The specification of
the database interface now has more exceptions listed than before.
7.3 Broadening
The group has broadened its remit to include Object-to-Database Mappings relevant to
relational and other databases. A result of this is the changing of its name from Object
Database Management Group to Object Data Management Group.
7.4 The Future
The ODMG group has said that it considers the standard to be fairly mature and now
wishes to turn its attention to propagating the standard to ensure compliance. The
maturity of the supported language also suggests that there bindings will not change
much in the foreseeable future.
25
ODMG Standard 2.0 and Object Model
Presentation Report
9.0 Conclusion
9.1 The ODMG Standard and Its Real World Application
Before a technology can become widely used, there must exist a degree of portability.
For example, if the email protocol (SMTP) were a closed, proprietary standard that was
only implemented by one company then email would not have been the success story it
is. Worse still would be if there were several standards that couldn’t interact with each
other. Before the foundation of the ODMG, this was a major factor preventing the uptake
of ODBMS technology.
The ODMG was created when several companies started working together to create a
standard that could allow programmers to produce applications that can be run on more
than one ODBMS product.
The more widely the standard is used, the more likely it is that new products will use it.
In order to get the standard used and avoid the vicious circle around a standard not being
used until others have accepted it, the ODMG have made two requirements in the
membership contract. Any company can become a member of the ODMG by paying the
required fee, but if they become voting members then they have to devote 32 hours per
month of a senior database expert’s time to ODMG activities, and they also make a
commitment to implement any of the standard that applies to ODBMS products they
produce. There are two other levels of membership that can also be applied for; the
reviewer membership is for interested parties. They have to devote 16 hours per month
of a senior database expert’s time but they do not have to implement the standard if they
choose not to, and although they can attend membership meetings, they cannot vote on
the actual standard. There is also an Associate Membership, which allows the ODMG
standard development to be followed by a wider community via mailing lists.
The ODMG standard is an open standard so it is not necessary to become a member
before you can implement it, but members get to see each version of the standard before
anyone else. This gives members a significant time to market advantage when it comes
to developing software using each new standard.
To make sure the standards are adhered to and to increase the credibility of products, the
ODMG are making test so products can be ODMG x-Certified. This means that a
particular product has passed the tests in a particular area of the ODMG standard. In this
case x can be replaced with one of five areas: ODL, OQL, C++, Java, and Smalltalk
language bindings. Since the standard is relatively new and is changing depending on the
needs and views of the public and the members of the ODMG, no tests have been defined
yet. To get round this a product can also be ODMG Compliant, meaning it has been
designed to meet the ODMG tests once they have been created. ODMG Compliance is
defined around the same five areas as ODMG certified, or the product can simply be
labelled ODMG Compliant, meaning it has been designed to meet the standard in at least
26
ODMG Standard 2.0 and Object Model
Presentation Report
one area. Currently vendors have to decide for themselves whether a product they
produce is compliant or not.
Now that the ODMG standard is maturing and bindings for more languages are being
produced, more and more ODMBS related products are being produced. This has led to a
problem that affects many software standards. Portability of ODBMS applications is
very useful to software companies in the sense that they can produce a new and possibly
better ODMBS product and their customers can buy it safe in the knowledge their custom
applications can be moved to it without any problem. The other side of this is that
another company can write a better or cheaper product that does the same job and the
same customers can move to it with the same assurances. In order to inhibit this,
companies add extra functionality to their products so their customers will not be able to
move away to another system.
Whenever the pros and cons of the ODMG standard are discussed the topic of SQL is
nearly always used as a counterpoint. SQL was initially designed as a language for
querying relational databases is a firmly established and widely used language. The latest
version, SQL3, is addressing the desire for OODMS technology by extending the
relational model to include OO features. This compares to the ODMG pure objects
approach and the issue of which will turn out to be the better choice is the subject of
fierce debate. There is also a school of thought that the two standards should be
combined to create a hybrid that incorporates both ideas. In fact Micro Database
Systems, one of the ODMG member companies, has produced a database engine that
allows the data to be viewed as relational and object models. Intersystems is another
company that has created a similar product and openly admits that it doesn’t comply to
the ODMG standard even though their design is based on the ODMG object model and
the client bindings are “inspired by the ODMG spec”.
Firm conclusions on the ODMG standard are difficult at this stage because it is still a
work in progress and it will no doubt adjust to changes in the software industry. ODMG
credibility will also be increased when official tests are created and users don’t have to
rely on the slightly dubious “ODMG Compliant” tag on software. Java support was
assured when Sun became a voting member in spite of the voices in the Java community
who didn’t want SUN to even adopt the ODGM standard when it came out. The
inclusion of Smalltalk bindings before the Smalltalk language itself has been standardised
will most likely mean that Smalltalk will be adapted to fit the ODMG standard on
insistence from potential users who already use ODMG products. No doubt the standard
will become more and more effective and useable as it matures and more powerful tools
are designed for it, and more software engineers become proficient in it’s use.
9.2 Conclusions and Criticisms of the ODMG Object Model
The ODMG object model requires careful examination before it can be accepted. While
it is not yet an industry standard, many large database companies are still adopting it. If
it is to become the standard for object oriented databases it must be accepted on the
grounds that it is a robust and a flexible solution rather than one that is forced on users by
27
ODMG Standard 2.0 and Object Model
Presentation Report
being the only model available. Independent reviews of the object model have been going
on each time a new version of the object model has been released, and they point out
flaws in the design.
The type checking system in the ODMG model is not perfect. Dynamic type checking is
used and no matter how well constructed a type checker is, there will always be situations
where it fails. This means that run-time checks have to be used, which reduces the
efficiency and reliability of the overall system. This problem is considered unacceptable
by many because static type checking would detect the problem at compile time.
Extentions to the ODMG model have been proposed that would allow for static type
checking but they use features not in common use across all languages so they have not
been implemented for the sake of compatibility.
Parametric types are also not supported in the current issue of the object model, except in
the C++ bindings. This is also done because Java and Smalltalk do not support
parametric types so they are again not implemented for compatibility.
Another issue is one of the lack of a “self” type. For example the copy operation defined
in the object model returns an Object class which could cause problems. The use of a
“self” type would allow the returning of the most specialised type rather than the most
generalised. Work to address this problem is currently under way.
Many complaints that are leveled at the ODMG model relate to the fact that is is not a
formal, mathamatical model. This was never the intention of the ODMG although they
do encourage the creation of such models, and are currently working with industry
experts to create one. Instead it concentrates on producing a practical, implementable
solution that incorporates the needs and demands of the users. Also, the ODMG model is
based on the Object Management Group model and will always remain compliant to their
model until required not to by user-defined functionality.
The ODGM model does have problems but the model itself is a work in progress and will
most likely be adjusted to solve some of the major ones as new versions are released and
users demand the problems be solved.
28
ODMG Standard 2.0 and Object Model
Presentation Report
References
Books
1. Eaglestone, B. (1998). Object Databases: An Introduction. McGraw Hill.
ISBN:0-07-709354-2.
2. Cattell, R.G.G (1997). The Object Database Standard: ODMG 2.0. Morgan
Kaufmann. ISBN:1-55860-463-4
3. Hughes, J.G. (1991). Object-Oriented Databases. Prentice Hall. ISBN:0-13629874-5
4. Delobel, C. (1995). Databases: From Relational to Object-Oriented Systems.
Thomson. ISBN:1-850-32124-8
Journals
1. Alagic, Suad. (1997) The ODMG Object Model: Does it Make Sense? OOPSLA
(ACM Conference on Object-Oriented Programming, Systems, Languages, and
Applications) USA
2. Chaudhri, Akmal B.(1997) Experiences Using Object Data Management In the
Real World. OOPSLA 1997 Workshop
Websites
1. www.odmg.org Accessed: 25/04/02
29