CS713 - Object Oriented DBMS
Course Page
Q & A
Short Question & Answers
Q 1: Defince Starburst design and architecture.
  • A table can be stored in variety of methods (such as heap files, non-recoverable temporary file, B+ trees etc).
  • Each table has associated attachment types.
  • Integrity constraints are checked by providing veto power to attachment.
  • Storage and attachment methods utilize common services:Concurrency Control, Recovery, Event Queues
  • The core provides a standard event queue for different activities.
  • Several extensions are made to SQL in SB.
  • Q 2: Dictionary object in ODMG-3.0.
  • A Dictionary object is 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; };
  • Iterating over a Dictionary object will result in the iteration over a sequence of Associations.
  • Each get_element operation, executed on an Iterator object, returns a structure of type Association.
      Dictionary Factory & Interface

    interface DictionaryFactory : ObjectFactory {
         Dictionary new_of_size(in long size);

    class Dictionary : Collection {
         exception DuplicateName{string key; };
         exception KeyNotFound{Object key; };
         attribute dictionaryvalue;
         void bind(in Object key, in Object value) raises(DuplicateName);
         void unbind(in Object key) raises(KeyNotFound);
         Object lookup(in Object key) raises(KeyNotFound);
         boolean contains_key(in Object key);
  • Q 3: Advance transection model.
      Features of Advanced Transactions
    Each advanced transaction model extends the traditional transaction concept along the following dimensions:
  • Supporting long-lived transactions
  • Supporting open-ended activities
  • Supporting cooperative activities
  • Supporting local autonomy
  • Supporting user controlled transaction
  • Application-specific transaction manager
  • Framework for analyzing transaction models

    In the following, we will survey SOME of important advanced transaction models
  • Nested transaction
  • Sagas
      Nested transaction
    A nested transaction is used to provide a transactional guarantee for a subset of operations performed within the scope of a larger transaction. Doing this allows you to commit and abort the subset of operations independently of the larger transaction.
    The rules to the usage of a nested transaction are as follows:
  • While the nested (child) transaction is active, the parent transaction may not perform any operations other than to commit or abort, or to create more child transactions.
  • Committing a nested transaction has no effect on the state of the parent transaction. The parent transaction is still uncommitted. However, the parent transaction can now see any modifications made by the child transaction. Those modifications, of course, are still hidden to all other transactions until the parent also commits.
  • Likewise, aborting the nested transaction has no effect on the state of the parent transaction. The only result of the abort is that neither the parent nor any other transactions will see any of the container modifications performed under the protection of the nested transaction.
  • If the parent transaction commits or aborts while it has active children, the child transactions are resolved in the same way as the parent. That is, if the parent aborts, then the child transactions abort as well. If the parent commits, then whatever modifications have been performed by the child transactions are also committed.
  • The locks held by a nested transaction are not released when that transaction commits. Rather, they are now held by the parent transaction until such a time as that parent commits.
  • Any container modifications performed by the nested transaction are not visible outside of the larger encompassing transaction until such a time as that parent transaction is committed.
  • The depth of the nesting that you can achieve with nested transaction is limited only by memory.
    To create a nested transaction, use the XmlManager::createTransaction method, but pass it the internal Berkeley DB Transaction object as an argument. For example:
    // parent transaction
    XmlTransaction parentTxn = myManager.createTransaction();
    // child transaction
    XmlTransaction childTxn =
    XmlManager.createTransaction(parentTxn.getTransaction(), null);
  • SAGAS [Garcia-Molina & Salem'87]
  • Supporting long-lived transactions
  • A saga is a collection of relatively independent subtransactions Tl, T2,....,Tn. Associated with subtransactions T1, T2,...,Tn-1 are compensating transactions C1, C2,...,Cn-1
  • The system guarantees that either Tl,T2,...,Tn or T1, T2,...,Tj, Cj,..., C2, C1(j < n) is executed "
  • Subtransactions of a saga can be interleaved in any way with other (sub)transactions IInterBase!
  • When a subtransaction completes, it can commit without waiting for other subtransactions
  • When failure occurs, a saga may try to proceed by executing the missing subtransactions (forward recovery); if not possible, it rollbacks the committed subtransactions by issuing compensating transactions
       Subtransactions may not see the same consistent state
         -> Consistency is compromised
       Subtransaction can commit when complete NO commit protocol is needed
         -> Isolation lS reduced to subtransaction level
       Failure atomicity is required
         -> Atomicity and Durability are still required
  • Q 4: Specification and implementation of ODMG-3.0.
    Type has an external spec and one or more implementations.
  • Specification: external characteristics of type; visible to users.
    Operations, state variables and exceptions.
  • Implementation: internal detail of objects of type; determined by a language binding.
  • Interface defines abstract behavior of an object type.
  • Class definition gives abstract state and abstract behavior of object type.
  • Literal.


  • Interface Employee {…};                       // abstract behavior
  • class Person {…};                                   // abstract state and behavior
  • struct Complex {float re; float im};     // abstract state
  • Data structure and methods depend on language binding.
  • Q 5: Define ODAPTER Architecture

  • New version of open DB.
  • Claimed to be used with 10 different RDBMSs.
  • Interfaces to Smalltalk and C++ provided.
  • Q 6: Explain inheritence behavior of ODMG.
  • ISA defines inh of behavior, EXTENDS defines of state and behavior; only to classes not to literals; single inheritance.
  • EXTENDS is transitive.

  • class Person {
         attribute string name;
         attribute Date birthDate;

  • class EmPerson extends Person: Employee {
         attribute Date hireDate;
         relationship Manager boss inverse

  • class MangPerson extends EmPerson : Manager {
         relationship set subordinates
         inverse Employee::boss;

  • Duplication of declarations in Interface and Class; like of boss and subordinates; help to access the relevant objects.

  • Course Instructor

    Dr. Nayyer Masood Dar Ph.D Computer Science University of Bradford, UK
    Database System: A Practical Approach to Design, Implementation & Management by T. Connoly, C. Begg
    Object-Oriented Database Systems: Approaches and Architectures by C. Prabhu
    Object Oriented Oracle by W. Rahayn, D. Taniar, E. Pardede
    Principles of Distributed Database Systems by T. Oszu, P. Valduriez, S. Sridhar

    The Object Data Standard: ODMG 3.0 by R. Cattell, D. Barry