2. What are Object Oriented Databases?

Atkinson et al. [4] and Zdonik and Maier [5] propose definitions of object oriented database systems in terms of their mandatory features, which we can divide into object-oriented features and database features, as summarised below.

2.1 Object-oriented features

• complex objects: Complex objects can be built up from simpler ones by applying set, tuple and list constructors which represent collections, attributes and relations, and order.

• object identity: An object in the database should have an identity independent of its value, so that there is a useful equality distinction between two identical objects which point to exactly the same data structure in memory and two objects which are merely similar in that their types and elements are equal. This provides for object sharing, i.e. objects can share a single element and updates to that element will be reflected in each object automatically.

• encapsulation: An object has a visible external interface that is independent of its hidden internal implementation. Only those operations specified in the interface can be performed on the object by applications. The implementation part includes both attributes representing the state of the object, and procedures which describe each operation.

Less central to the OODB concept according to Zdonik and Maier, but still seen as mandatory by Atkinson et al. are the following features:

• types or classes: Object types (found in C++) and classes (found in SmallTalk) both summarise the common features of a set of objects with the same characteristics, but they are employed in different ways. Types are not objects themselves, and are used primarily to ensure program correctness at compile time by allowing the user to declare the representation of variables and expressions the program manipulates. Classes on the other hand are objects, and are used at run-time to create new objects (instances), for example by applying a new operator to the class.

  Note that the type/class distinction corresponds to the difference between static and dynamic data typing in procedure-oriented programming languages such as C (static) and Lisp (dynamic), but these do not have the added benefit of encapsulation.

• type or class hierarchies and inheritance: Inheritance provides a means of avoiding the explicit and repeated storage of data which can be inferred, and helps code reusability. When two types t1 and t2 have features (attributes and operations) in common, those features can be abstracted out into a single subsuming type T, with t1 and t2 being declared as subtypes of T so that they automatically gain the common features without each having to respecify them.

• overriding, overloading and late binding: It may be desirable for a type t to inherit certain attributes or operations of type T, but not others which are under-specified or otherwise inappropriate. In this case t can override the features by defining its own local features with same name.

  Having two or more types use the same name for related but distinct attributes or operations is called overloading the name. The system can select the appropriate binding for the name at run-time by examining type of the object to which it is being applied (this is called late binding).

• extensibility: Applications can add to the set of types or classes built into the OODB, and new types or classes must have the same status and usage as predefined ones.

• computational completeness: Either the database description and manipulation language should itself be able to express any computable function (not the case for the RDBMS query language SQL, for example), or it should provide an application programmer's interface (API) to a standard programming language.

2.2 Database features

• persistance: The data manipulated by an application, whatever its type, should survive beyond the execution of the process which runs it and be available for re-use in subsequent processes. This should happen implicitly - save and load operations etc. should not be required.

• efficient secondary storage management: Mechanisms should be provided for fast and efficient manipulation of very large databases. Allocation of disk storage and transfer of data to and from main memory should be invisible to the application.

• concurrency: Multiple users should be able to work concurrently on a database, viewing and updating shared data without affecting its integrity. The system should lock objects when they are read or written to prevent simultaneous access, and execute atomic operation sequences which cannot be interrupted leaving the database partially updated.

• recovery: In the event of disk, processor or software failure, the OODB should be able to restore the data to a coherent state.

• ad hoc query language: The system should provide the functionality of an efficient, high-level, application-independent, declarative ad hoc query language. This does not necessarily mean it should provide a textual query language per se; a graphic browser with equivalent access facilities is just as good. The internal data manipulation language could also be made available for this job.