Babar logo
Workbook HEPIC Databases PDG HEP preprints
Organization Detector Computing Physics Documentation
Personnel Glossary Sitemap Search Hypernews
Unwrap page!
Wkbk. Search
Wkbk. Sitemap
Logging In
Info Resources
Software Infrastructure
CM2 Introduction
Event Store
Modifying Code
Writing and Editing
Framework II
Find Data
Batch Processing
Advanced Infrastructure
New Releases
Main Packages
Event Displays
Contributing Software
Advanced Topics
Make CM2 Ntuples
New Packages
New Packages 2
Persistent Classes
Site Installation
Check this page for HTML 4.01 Transitional compliance with the
W3C Validator
(More checks...)

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

Introduction to the Objectivity 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 is a repository for history under which the data was acquired or processed. This includes geometry, electronics calibrations, detector alignments, trigger/online/detector configuration, and reconstruction adjustable parameters. The Conditions Database is designed to allow for a complete description of the detector as a function of time, where different components of the detector may exhibit different time variances.

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

The BaBar conditions database utilizes Objectivity, a commercial object database. Much of the terminology and implementation of the BaBar database is a result of the underlying base of Objectivity.

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

The only necessary run-time environment variable is OO_FD_BOOT. Applications use this variable to locate the Conditions Database Boot File, to find the conditions and calibration information appropriate to the data you are going to analyse. The QuickTour analysis job is based on a 18-series production release, so needs conditions information relevant to 18-series. To set the conditions boot file, you must issue this command from your release directory:
   ana30> cond18boot
Like all unix environment variables, this assignment only remains for the current session. At every new login or shell session this variable will need to be reset.
General Related Documents:

Back to Workbook Front Page

Author: Tracey Marsh
Joseph Perl
Jenny Williams

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