MOOD Structure and Initialization

Table types

Some tables describe things (e.g. Parameter files; Configs) which are of interest to high-level users; call them Instance Tables. Others are just machinery to make the whole thing go. Typically these are either

Class Tables

A row identifies a kind of Parameter, FSW input, or whatever. For every instance table with a corresponding class table, there is a foreign key column in the instance table referring to a row in the class table.

Relation Tables

Relate two instance tables or two class tables. Usually a row in a Relation Table doesn't have much beyond the two foreign key columns.

Table creation

Tables now in or expected to be in MOOD are listed below along with references among them, more or less in the order they should be created. Each table will have a primary key.

1. Delegates
   Table type: Instance table.
   Foreign keys: none.
   Description: Describes spheres of management. There will be rows for CAL, TKR, ACD, Timing, Trigger, perhaps Filter, etc.
2. Conditions
   Table type: Instance table.
   Foreign keys: to Delegates
   Description: Conditions under which Parameter and Ancillary files were created. May have columns for such things as energy-related settings, temperatures, etc. Depending on value of the delegate foreign key, only some of these columns may be used in a particular row.
3. FSW_class
   Table type: Class table.
   Foreign keys: none
   Description: Types of binaries to be uploaded. Includes one row for each LATC component; e.g. one for GEM, one for ARC, etc. ACD calibrations scripts form another class, CAL calibrations scripts another, there are three types of thermal control files, and so forth.
4. Parameter_class
   Table type: Class table.
   Foreign keys: to Delegates
   Description: One row for each type of file which might be input to some procedure creating a (binary) FSW input. For the most part there is a one-to-one correspondence between parameter classes and FSW input classes, but there need not be for LATC files. Sometimes several LATC source files will be used to produce a single binary. To further complicate matters, one might partition the input different ways at different times (e.g. use a single source file under some circumstances but not others).
5. Offline_class
   Table type: Class table.
   Foreign keys: none
   Description: One row for each kind of offline calibration. In the existing calibration metadata database, rather than having a separate class table, the calibration metadata includes a calib_type (string) column. This might suffice for MOOD as well.
6. Ancillary_class
   Table type: Class table.
   Foreign keys: to Delegates
   Description: One row for each kind of ancillary file. Might not be needed.
7. LATC_mapping
   Table type: Instance table.
   Foreign keys: to FSW_class
   Unique index: (FSW_class_fk, name)
   Description: A place to name the different ways one might provide input source to create a LATC binary. For example, there might be two different ways to partition source for the CFE component, one called one-to-one (single source file) and another called CAL-friendly (put source for thresholds in one file; settings for other registers in another). This table is not used by the kernel build routine (MootBuild::BuildFromParm) which just takes as input a list of pre-registered parameter keys. It could be used by user interface code to make it easier to identify a complete and compatible collection of LATC input files.
8. Configs
   Table type: Instance table.
   Foreign keys: none
   Description: Each row identifies a configuration which may be uploaded. Relation tables allow a configuration to be traced to the FSW binaries comprising it; these may in turn may be traced to Parameter files (sources for the binaries).
9. FSW_inputs
   Table type: Instance table.
   Foreign keys: to FSW_class
   Description: A row with good status corresponds to a binary which has been registered with FMX (via fmx add command). The resulting FMX logical id is saved in the row.
10. Parameters
    Table type: Instance table.
    Foreign keys: to Parameter_class and to Conditions.
    Description: A row in this table represents a human-readable source file (most commonly XML) used in the creation of an FSW input.
11. Ancillary
    Table type: Instance table.
    Foreign keys: to Ancillary_class (maybe) and to Conditions.
    Description: Files written out as a result of analyzing physics data or charge injection calibration runs. They describe detector performance or characteristics and may be used as input to procedures creating configuration source files (e.g., to determine channels to be masked off or threshold settings) or to create calibrations for use during Offline runs.
12. OfflineCalib
    Table type: Instance table.
    Foreign keys: to Offline_class (maybe)
    Index: (completion, instrument, calib_type, flavor, proc_level)
    Description: A row represents a calibration (e.g., TKR bad strips, CAL asymmetry) used during offline analysis.
13. FClass_to_PClass
    Table type: Class relations table.
    Foreign keys: to FSW_class, Parameter_class and, for LATC binaries, also LATC_mapping.
    Description: Relates types of FSW_inputs to the types of Parameters used to build them. There may be more than one way to build a particular FSW_input type.
14. PClass_to_AClass
    Table type: Class relations table.
    Foreign keys: to Parameter_class and Ancillary_class.
    Description: Not yet certain this table will be needed.
15. OClass_to_AClass
    Table type: Class relations table.
    Foreign keys: to Offline_class and Ancillary_class.
    Description: Not yet certain this table will be needed.
16. Configs_to_FSW
    Table type: Instance relations table.
    Foreign keys: to FSW_inputs and Configs.
    Description: Each Config is built from a set of FSW_input instances.
17. FSW_to_Parameters
    Table type: Instance relations table.
    Foreign keys: to FSW_inputs and Parameters.
    Description: Each binary FSW_input is built from one or more Parameter (source) file instances. May be able to dispense with this table since essentially the same information is contained in the description field of FSW_inputs.
18. Parameters_to_Ancillary
    Table type: Instance relations table.
    Foreign keys: to Ancillary and Parameters.
    Description: Relates a parameter file to the ancillary files it was derived from.
19. Offline_to_Ancillary
    Table type: Instance relations table.
    Foreign keys: to Ancillary and OfflineCalib.
    Description: Calibration files used by Offline may be derived from one or more ancillary files.
20. Instrument
    Table type: Instance table.
    Foreign keys: none
    Description: Keep track of which bays have calorimeters, which have trackers. More fields might be added to this table. Currently software doesn't really use it.

Table initialization

The contents of some of the instance tables and all the other tables is relatively static. The bulk of this information will be known when the database is created. There may be occasional additions as the system evolves. Initialization immediately after a MOOD database is created could go something like this:

1. Fill Delegates. Initial set of rows will have name field equal to ACD, ACD, CAL, TKR, TRG, TIM, HSK, plus one called generic for backwards compatibility or when delegate is irrelevant.
2. Fill FSW_class. There will be, at a minimum, rows for each of the 15 LATC component classes, one for LATC master files, one for input to LATC_map, three for thermal control files, three for calibration scripts (one each for ACD, CAL and TKR), and one generic one with name equal none.
3. If used, fill Offline_class. At a minimum there will be a row for each of the possible calib_type values in the old calibration metadata database.
4. If used, fill Ancillary_class. Note this table has a foreign key linking it to Delegates.
5. Fill Parameter_class. There will be a row for nearly every row in FSW_inputs (in most cases a FSW binary is built from a single source file) and some additional rows for those LATC component binaries which may, under some circumstances, be built from a list of source files. Note this table has a foreign key linking it to Delegates.
6. Fill FClass_to_PClass and LATC_mapping. For every "normal" FSW class (may not include oddballs like the one named none or latc_master) add an entry to LATC_mapping with name = one_to_one and add an entry to FClass_to_PClass linking the FSW class to a single PClass and also having a foreign key for the new row in LATC_mapping. For each LATC component whose binaries may be formed from a list of sources of more than one parameter class, need to come up with a name for the list (that is, a name for each such list) and add a row to LATC_mapping, then add rows to FClass_to_PClass for each source file referencing the new row in LATC_mapping.
7. If used, fill PClass_to_AClass and OClass_to_AClass.

Initial draft: 5 Oct 2006 Last revised: Friday, 20-Oct-2006 11:49:59 PDT

J. Bogart