Workbook for BaBar Offline Users - Objectivity: The BaBar
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
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
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.
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.
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
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
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.
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:
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:
Last modification: 21 January 2006
Last significant update: 7 June 2005