Workbook for BaBar Offline Users - Objectivity: The BaBar Conditions Database

Until late 2004, the BaBar data was stored in an object-oriented (OO) database called "Objectivity". But with the advent of the new computing model CM2, data is no longer stored in this OO database. Instead, it is stored in a more conventional database in the form of ROOT files (see the EventStore section of the workbook for more information on data storage). So now, only conditions information (see below) and more specialised tasks use the OO database.

Because the BaBar eventstore has moved away from Objectivity as storage means, the use of the objectivity database is now restricted to more advanced users, and is no longer within the scope of the Workbook. Therefore, this Workbook chapter contains only a description of the Conditions database, and some useful links for Objectivity users.

The offline database group have created a comprehensive new website for database information. It is at: $BFROOT/www/Public/Computing/Databases/. If you have any specific questions, it is best to email Jacek Becla of the Databases group.

Conditions Database

The Conditions Database consists of a set of databases for each detector subsystem. Each subsystem will have an index database and a number of conditions databases. Conditions measurements are taken every half hour, and the data is encapsulated in a conditions object and stored in a conditions database. The begin and end times define the interval, which is encapsulated in an interval object that contains a pointer to the associated conditions object. The interval objects make up the index system.

Terminology and Structure

To be compatible with the Objectivity based database, the objects at each stage of processing must comply with some data structure conventions. Classes that meet these restrictions are said to be persistent or persistent-capable. In BaBar software this is accomplished by having all classes that are designed for database storage inherit from the BdbPersObj class. Since persistent classes are at the base level of the entire database, most users and developers will not need familiarity with their implementation. Writing persistent classes is a delicate task that only a few titled "experts" should perform. This is discussed much later in the workbook, Writing Classes for Persistent Objects . By BaBar convention, applications should not use persistent-capable objects in a transient manner (for temporary purposes other than database storage).

The description of the persistent class types that create the BaBar database data model is called the schema. Objectivity requires the use of C++ classes that are defined in Data Definition Language (DDL) Files (those having a .ddl suffix). You might come across the term "schema evolution and versioning". The evolution regards changes in structure of persistent classes and the versioning is intended to accommodate either an optional or gradual migration of the rest of BaBar code to be compatible with the new persistent class structures.

A user interacts with the event data through C++ applications. The database is where an application's persistent data is stored. Each persistent object is created in an Objectivity database. The fundamental unit of persistent data is referred to as a basic object and is stored in a container. One or more containers compose a database. A database is physically represented by a database file, which is made up of all containers and basic objects stored in the database. Currently each database corresponds to a Unix file, although this one to one mapping is not expected after future releases of Objectivity. Each database is identified both by its file system location and by a unique Database ID (DBID) number.

A set of related database files and objects that can be accessed by a single application is called a federation or federated database. This is a higher level structure than a database. A federation is physically represented by a Federated Database File. By BaBar convention the file is named BaBar.FDDB, and is located on the catalog server. It contains the schema stored in the system database, as well as a catalog of additional databases that belong to the federation. Each database is a member of exactly one federated database. Each federation is identified by a unique Federated Database ID (FDID) number.

Creating a new federation generates a Boot File. The Boot File describes the federated database configuration, its own location and file server, the FDID, lock server node, and other parameters describing the federation. By BaBar convention this file is named BaBar.BOOT. In principle the Boot File is the only file that must be made visible to client applications, and unlike other database files it may reside on a NFS or AFS file system.

The BaBar database supports remote and local file systems. That is, applications may be run local to the federated database (on the same machine), or remotely (on a different machine). The database file systems are accessed remotely via the Advanced Multi-threaded Server (AMS) by a network protocol. To the user this means that a federation must be created and used on a machine that has the AMS daemon running. The application may be running on a remote non-AMS machine as long as the federated database is attached to an AMS machine.

When a user accesses a database, read and update locks are placed on that database to prevent conflicts. The lock server is a process running on a designated computer that manages concurrent access to a database. No data passes through the lock server, but it ensures that data within the federation is consistent and prevents simultaneous updates from multiple clients.

Creating the Necessary Environment

   ana30> cond18boot

• BdbSOS hypernews - for problems with the databases
• OO Databases hypernews - questions and general discussion about BaBar databases
• BaBar Databases Home Page
  Becla
• Getting Started with the BABAR Database (obselete, but may still have some relevance to specific users)
  Quarrie
• BaBar Event Store

Back to Workbook Front Page

Last modification: 21 January 2006
Last significant update: 7 June 2005