In order to minimize the disk-memory transfers and to permit a tight
control of the whole system, a few general standard keys have been
defined. The HEPDB package assumes that all key vectors consist of at
least 10 keys. These keys are defined as shown in table
.
| 3|c|System keys | ||
| Key number | Meaning | Parameter |
| 1 | serial number | |IDHKSN| |
| 2 | pointer | |IDHPTR| |
| 3 | flags | |IDHFLG| |
| 4 | insertion time | |IDHINS| |
| 5 | reserved | |
| 3|c|Special User keys | ||
| 6 | unique source identifier | |IDHUSI| |
| 7 | software reference number | |IDHSRN| |
| 8 | reserved | |
| 9 | reserved | |
| 10 | reserved | |
| 3|c|Validity range pairs (Repeated |NPAIR| times) | ||
| 11 | start range 1 | |
| 12 | end range 1 | |
| 3|c|Normal user keys (up to RZ limit of 100) | ||
| |11+NPAIR*2| | first normal user key | |
| |12+NPAIR*2| | second normal user key | |
Table: HEPDB keys
The system keys should not be touched by the user or application program. The normal user keys may contain any information.
After the standard keys come a number of key pairs. The number of pairs is a database constant. For example, the L3 collaboration uses only one key pair, the start and end times for which a database object is valid. The OPAL collaboration uses 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 the overall RZ [10] limit of 100 keys). Their role will become more transparent when reviewing the functionality of the storage and retrieval of data objects, described below.