Concepts illustrated

Introduction

Let's take a simple example of calibration data, say "target position," which is defined by three coordinates x, y, z, each represented by floating point number.

Using C++ as an example language, if a user asks for "target position":

auto data = calibration->GetCalib("/target/position");

the calibration database should provide the appropriate data in the current context so it can be used:

if (data["z"] > 30) ...

"The current context" is the key phrase here, since the values of target position could be different for different runs, values may change with time, e.g., if more precise calibration is performed. Also, a user may want to use a personal version of data for various reasons.

The picture above illustrates features of CCDB that involve control of the context:

• The data returned depends on run number.
• A history mechanism: by default CCDB honors the last assignment of data to a particular run, but one can always recover assignments made in the past.
• Variations (equivalent to "branches" in version control systems): users have the ability to create and work with alternative versions of the data, varying the run assignments and/or the data itself.

Terms and concepts

Namepath

Data is associated by the namepath. The namepath string is unique across all detector systems. Forward slash(/) is used to specify a hierarchical namepath.

For example:

/target/position
/FDC/driftvelocity/timewalk_parameters
/FDC/base_time_offset

This allows implementors of individual detector systems to specify a hierarchy with as much or little depth as is needed, appropriate to the physical structure of their device.

Namepath format: Allowed symbols are a-z, A-Z, 0-9, '_' and '-'. Spaces or other special symbols are not allowed in the namepath (this simplifies console management and database validation of namepath objects).

/My-path/to/data_01            # OK
/Some...thing/is wrong here!   # ERROR: illegal symbols '...', '!' and spaces.

---

Tables Types

Each namepath corresponds to a "table type". The idea of table type is that while data values may change, "the shape" of the table never does.

Note that the term "table" is ambiguous especially if topic is related to databases. CCDB uses the term "table type" for the definition of data (the shape), and "data set" or "constant set" for the data itself, i.g. values of table type.

Table type - defines columns and a number of rows. Each column may have its own type and name (see below).

In our target position example, the namepath "/target/position" is a table type, defining data arranged in three float columns and one row. Whatever the values of /target/position are, they are always presented as one row of "x", "y", "z" columns.

Column names: Columns may have names, however column names are optional.

The "/target/position" example has 3 columns named "x", "y", and "z". They could be also identified as "0", "1", "2".

As another example, the /FDC/driftvelocity/timewalk_parameters parameters may have members "slope", "offset", and "exponent".

By contrast, a set of constants with a namepath "/FDC/CathodeStrips/pedestals" may have 100 values identified simply as 0, 1, 2, 3, ...

Column types: Column types may be one of the following:

• int
• uint
• long
• ulong
• bool
• double
• string

Data and Assignments

Each type table may have multiple versions of the constant sets. Each constant set has at least one "assignment". The assignment holds the information specifying the association of the constant set with a context:

• run range - Runs for which the data is valid
• creation time - Creation time of the assignment (used for the history feature)
• variation - Name of the variation
• comment - Any useful comments about the assignment

One could say that assignment shows the context within which the data "is correct."

A particular constant set can have several assignments. This allows the use the same constants for different run ranges and helps avoid "update anomalies."