Database Structure

  The SNO database will be comprised of multiple files in multiple directories. In addition, each database file has an internal tree-like structure using a UNIX-based format for specifying directories and subdirectories. A multiple file database enables us to separate frequently-changed elements of the SNO database from those which are not, making the update procedure more robust and giving the database external as well as internal structure. Multiple files also give individual institutions more flexibility in the use of their available diskspace, since individual database files may reside on different disks, and make it possible to guard against erroneous data entries. The chief disadvantage of multiple files comes in the code which has to open all the database files at SNOMAN initialization time, and in the code which has to pick the particular file in which a particular object resides, but this is transparent to the average user and does not add significant processing time overhead.

Each database file will be internally organized into directories and subdirectories as specified by the creators of the data which reside therein. Database objects contained in these subdirectories are comprised of a ``keys'' bank and an attached data bank. This is illustrated in Fig. 2.

  

Figure: A basic database object consisting of a keys bank which contains a pointer to its data bank.

The data contained in the keys banks which are pertinent here are:

1.

a temporal validity range (GMT must be used),

2.

an insertion time (automatically added by HEPDB when the object is written), and

3.

several ``user'' keys.

For SNODB v3_06_02, these user keys include the following pieces of information:

• data type (a combination of detector type [SNO or MiniSNO] and data source [MC or real], as shown below).
   

  data_type = 10*(IDDT_REAL or IDDT_MC) + 1*(IDDT_SNO or IDDT_MINISNO) where

  IDDT_SNO = 1

  IDDT_MINISNO = 2

  IDDT_REAL = 1

  IDDT_MC = 2

• bank alias,
• bank number,
• task type (e.g., are we looking at solar neutrino or upward-going muon events; we may wish to change the constants used by the fitter, say, depending on which type of event we are investigating),
• format number (initially 0 for all banks, changed whenever the format of the data in a bank is changed in a backward incompatible way, which hopefully occurs infrequently),
• source ID (identifies the source of the bank, e.g., DAQ or a particular calibrator).

This information is stored in several arrays in the SNODB code, as illustrated in Table 2.

   

2|c|keydbs 2|c|usrkeys 2|c|ipath

1 1c|Reserved 1 start date

2 start time

1c|H 3 end date

1c|E 4 end time

1c|P 5 creation date

1c|D 6 creation time

1c|B 7 eff. start date^*

8 eff. start time^*

9 eff. end date^*

10 1c|keys 10 eff. end time^*

11 start validity (GMT) 11 entry date

12 end validity (GMT) 12 entry time

13 data type 1 data type 13 data type

14 bank alias 2 bank alias 14 bank alias

15 bank no. 3 bank no. 15 bank no.

16 task type 4 task type 16 task type

17 format no. 5 format no. 17 format no.

18 source ID 6 source ID 18 source ID

To read a bank from the database one must provide an instant of validity (most commonly, an event's time stamp) along with the bank alias and some number of additional keys. Using these items of information, HEPDB will then search for the most recently added database object-in this example a bank-which satisfies all the criteria. HEPDB can be forced to read an older version of a given object if one specifies the appropriate upper limit on the insertion time.

To write a bank, the same information is required except that a validity range must be provided instead of an instant of validity. The validity range provides the start and end times for which the information written to the database is considered valid. Greenwich Mean Time (GMT) is the standard time frame for SNO and SNODB.

There are several ways in which to read and write to the database using the tools described in Section 8. Information is passed to and from these routines by means of the ipath vector shown in Table 2.

The initial database structure is given in Appendix C. This structure reflects the fact that certain ``constants'' can change frequently with time, e.g., PMT calibration constants, while other constants rarely if ever change, e.g., geometry constants. Such a structure is naturally implemented with separate files. The current database structure is given in the file $\sim$/3_06_02/dbs_tools_f/sndirs.dat which is reproduced the aforementioned Appendix. In this file, individual database files are given as *.dbs, followed by the internal HEPDB subdirectory and bank names.