The HEPDB database management system organises databases in files as a collection of directories and sub-directories (Similar to the UNIX file system structure). Residing at the end of any path-name there maybe zero, one or many actual data objects. These objects are further identified beyond their pathname by keys, which may be a single word of information (integer , hollerith, string etc.) or a vector of such words.
Supposing as stated earlier that an experiment currently stores its data under the RZ file system and that therefore the required directory structure is already known and the essential keys for the database are also already known we have a firm basis on which to start to build our HEPDB database structure.
Below is a description of an existing RZ file structure for a geometric database including the directory tree (corresponding to different parts of a detector) and its associated keys.
The required directory structure
GEOMETRY TYPE | KEYS | -----+------------------------------------------ | (I) | VAL_STAR start validity range of object |----->PC (I) | VAL_STOP end validity range of object |----->DC (H) | DETECTOR detector name |----->ST (H) | POINTER some MZ bank pointer name |----->PID |----->CAL_WIRE |----->CAL_STRIWe can now asses the directory structure and the keys to see if any modifications are required as this is the best time to start the implementation of any new keys etc.
For the sake of this example lets assume that the directory structure requires no real modification but we do however think it may be useful to add an extra key to signify the source from which a data object came, this can have one of two values (on-line or off-line data).
After the next short section which explains the use of keys under HEPDB we shall decide on how we are to implement the extra key.
The HEPDB package assumes that all key vectors consist of at least 10 keys. These keys are defined as shown in table [more info] on page [more info] of this manual.
The system keys (the first 5 keys) should not (normally) be touched by the user or application program. The special user (keys 6 to 10) keys may contain any information decided on by the experiment. (However it has been suggested that keys 6 and 7 may contain a unique source identifier and a software reference number respectively.) For instance these keys could be used to hold a key which is common to all databases regardless of their contents.
After the standard keys come a number of key pairs. The number of pairs is a database constant. For example, the CPLEAR collaboration use only one key pair, the start and end times for which a database object is valid. The OPAL collaboration use 3 key pairs - the start and end experiment, run and event number for which a database object is valid.
Additional keys, the so-called user keys, can be declared by the user (within an overall limit of 100 keys).
From our previous description of the existing RZ file we can see that we have 1 validity range pair VALSTAR , VAL-STOP. These will be held in keys 11 and 12 and therefore imply a database constant NPAIR (number of pairs) equals the value 1.
The other keys from our geometry RZ files will take the form of normal user keys occupying keys 11+NPAIR*2 and 12+NPAIR*2 or in other words keys 13 and 14. As discussed before in our example of the geometric database we have decided that an extra key to define the source (on-line, off-line) of a data object would be useful. As this will be common to all our databases (geometric, calibration and auxilliary) we can in this instance allocate a special user key for this job. We shall use key 10 (although we could have used any normal user key instead.).