Object Database, Object Creation, Objects, and “Collection Objects”

According to the working standard, an object-oriented database is the principal scope for all objects of an information system. In this database all objects are instances of a user- defined type that has been introduced to meet the requirements of the system. Closely associated with a database is ODMG’s introduction of a module as a unit of declaration and specification of the database in which schema and application objects have a scope. A number of exception flags are specified for this module (for example INTEGRITYERROR and DATABASECLOSED).

An interface that is inherited by all other user-defined interfaces is the OBJECT interface. A few of the behaviours it bestows to all inheritors are the COPY (make a copy of the receiver object), the DELETE (purge the object from the collection unless referential integrity problems occur – in which case raise the INTEGRITYERROR handler), and the SAME_AS (to be explained shortly) methods. To create an object one must use the OBJECTFACTORY interface that provides the new method for this purpose. Note the language bindings would need to have their own implementation of the OBJECTFACTORY interface.

The ODMG specification of an object includes three parts. The first deals with identity, the second indicates an object’s lifetime, and the third its value.

All objects have an identifier. This identifier is unique (with respect to the scope of the collection) and immutable. The standard bestows the responsibility of providing the

OOP – OODB and the ODMG Standard- Page [ 105]

identifiers on the OODBMS. All interfaces and classes, as we have stated previously, respond to the SAME_AS method that returns a Boolean result on checking the identifier of the receiver object’s to that of another object (passed as an argument) in the collection. Relationship instances use these identifiers.

Also the standard provides for naming of any object (over and above identifiers). These names are useful database entry points; but their management should not be taken lightly (both from the aspect of OODBMS design and from a DBA aspect). Homonyms are not allowed.

While it is obvious that a database stores objects for a period of time that is independent of the processes that create or access them (i.e. we are very much interested in object persistence) there are scenarios where some objects should purge when their process ends (the standard calls these transient objects). These transient objects are common in an application front-end and closely associated with the programming-language environment. The type of lifetime an object has, the standard wants us to understand, is independent of the object’s type.

The standard makes use of the term collection to denote a number of distinct “elements” and therefore a type generator. There are some structural restrictions on the standard’s collections. The most important restriction being that these “elements” must be of the same type – i.e. homogenous sets. If the “elements” are literals then the literals must be all of the same type. If the “elements” are user defined type instances then the objects must be of the same type. If the “elements” are collections of “elements” then the collections of “elements” must all be of the same type.

The specified behaviour of a user defined collection, which is a specialisation of the Object interface, includes CARDINALITY (returns the number of elements in the receiver collection), CONTAINS_ELEMENT (returns a Boolean flag if the identifier passed to the receiver is present in the collection), INSERT_ELEMENT, and SELECT_ELEMENT (returns an item from the collection that satisfies the query passed to the receiver collection). Some methods yield dynamic information on the collection’s state (e.g. CARDINALITY and IS_EMPTY methods).

OOP – OODB and the ODMG Standard- Page [ 106]

A useful companion to the collection interface is the iterator interface that allows access and traversal of a collection’s elements. Other than the obvious methods AT_END, RESET, and GET_ELEMENT, there is an interesting Boolean method called IS_STABLE which indicates whether this iterator traversal is to be insulated from traversal processing side- effects over the same collection.

Collections can be specialised to a number of other particular collection types (for example

set, bag, list, array and dictionary). For example the set is an un-ordered and collection of

unique elements. The SET class (note the shift from interface to class here), which is a sub- type of COLLECTION, has a VALUE attribute whose type is parameterised with a type and a number of common set operations (e.g. CREATE_UNION, CREATE_INTERSECTION, IS_SUBSET_OF, and IS_SUPER_SET_OF). Some methods, for example the

INSERT_ELEMENT, are incrementally modified to reflect the uniqueness semantics of set over those of a collection.

5.3.2.3 Literals

The standard specifies a good number of types whose values do not have an identifier; these we have seen are called literals. These types are an exact equivalence of OMG’s IDL own values. The most basic – called atomic, and very close to our basic domains of the previous section, include the following list; long, long long, short, unsigned long, unsigned long,

unsigned short, float, double, Boolean, octet, character, string and enumeration. The last is

really a type generator as a definition is required to specify the list of literals making up an enumerate type. For example to specify sex type one could define the enumerated type gender with the literals “male” and “female”.

Another set of literal type generators is the collection of literals (with the same variety as the collections just presented but restricted to literals).

We can also use the record data type generator (the standard calls these structures). Each

structure has a name and a fixed number of components, with each of these having a name

and a literal data type. A text book example being an address with its components street, city and postcode. There are a number of structures pre-defined too: e.g. date and time.

OOP – OODB and the ODMG Standard- Page [ 107]

Since literals do not have an identifier then the use of SAME_AS is not compatible. To compare two literals one uses the EQUALS method. The standard lists a number of rules, related to the data type that gives the exact meaning of two literals being equal. This is based on structure and values. An almost verbatim reproduction of a selection of these rules follows.

Two literals, x and y, are considered equivalent if they have the same literal type and:  are both atomic and contain the same value;

 are both sets, have the same parameter type t, and each element of x is in y and each element of y is in x;

 are both structures of the same type and for each component j then x.j and y.j are equivalent.