[ ESO ]
QC1 database:
configuration tables
 

QC1 database:
Project
Tech Guide
Users Guide
Configuration tables

The structure of each QC1 table is defined in a definition file (configuration table). This definition table has to be provided by the QC scientist. It is read by internal QC1 database management tools and defines completely the structure of the QC1 database for that instrument.

The configuration table is the prime source of database structure information. It needs to be carefully designed and maintained.

The configuration table can either be an excel table (.xls) or a flat text file with separators.

The configuration table is used internally for the sql create/table command.

Database table definition files

As a database table, each table definition file itself has rows and columns which become entries and keys.

There is one table definition file per QC1 table (or one sheet in the excel file). It lists:

key name comment
field_name  should be self-explaining if possible; if a FITS keyword_name exists, use a translation. Try to be consistent with other instruments: don't be creative when similar field names already exist for other instruments.
keyword_name short version of related FITS keyword (if available)
field_type  one of varchar/float/integer/datetime
plot_flag 

used for qc1_plotter interface. Possible values are:

empty - not selectable for the interface
xd - used as X axis default (must be unique)
yd - Y axis default (must be unique)
xy - selectable in interface
f - selectable for filtering

Note that this key is also used to define a primary key. That is, the combination of all 'f' keywords, plus mjd_obs, is used as primary key to identify all entries. This is necessary for qc1Hide.

keyword_type type of key; used sorting by qc1_browser; possible values:

general
qc1
instrument
sort_flag  integer number; used for sorting by qc1_browser; within all keys per keyword_type, sorting is done along sort_flag
length length for varchar types
default_value default values: NULL or specific value
example example
description used for self-documentation

Sections

Each table description has three sections, defined by the content of keyword_type:

  1. General keywords:
    like PIPEFILE etc. These are useful for joins (matches) across databases (e.g. with science archive).
  2. Specific QC1 keywords:
    the real QC1 parameters.
  3. Instrument keywords:
    inherited from the raw files.

General keywords

The essential set of general keywords is the following:

cdbfile
pipefile
arcfile
origfile
mjd_obs
tpl_start
civil_date
validity_flag
timestamp

-cdbfile:  the file name of the master calibration file (DFO naming convention)
-pipefile: the pipefile name of the master calibration file
-arcfile: the arcfile  name of the (first) associated raw file
-origfile: the origfile name of the (first) associated raw file

-tpl_start: tpl.start keyword from the raw files
-validity_flag: yes by default; no by updating; used and filled by the qc1_hide tool.
-timestamp: of last modification.

Filenames: For the purpose of being able to cross-correlate (join) information from the qc1 database with e.g. the raw data archive, it is extremely useful to have, as part of the qc1 database, information about the file names associated with the qc1 parameters. Of course this information is not always present, but we should try hard to retrieve it for historical data, and to provide for future data by default.

MJD-OBS is considered a fundamental keyword which (in connection with some other parameters) is used to identify entries (primary key). This is needed if e.g. an entry should be deleted or updated. Therefore, it should have highest-possible precision, as stored in the FITS headers.
 


QC1 keywords

Choose names which are as close as reasonable to their parent FITS key names. 

Instrument keywords

These contain relevant setup information, just taken from the FITS headers.


Description field

The description field is used for self-documentation. Any care taken in filling this field with sensible content pays back manifold since it provides essential self-documentation.

Find here some details of an example table description.

General table definition file

There is also a general part which contains

  • the table names,
  • a sort flag (used to control the sequence of the tables displayed e.g. in the qc1Browser),
  • a short description (displayed in the interfaces).

The content of this table is read into the database table qc1_tables.

The complete UVES definition file in excel format can be found here.


[ Internal QC Home page ]