The Data Model

The persistent data model (Figure 1.1) describes the design of the database used to store bookkeeping data. This database is supposed to be relational. Thus the description is the description of the tables used and of their colums. Each bubble of the figure is a table and the list of column is given inside each one. The associations drawn as lines show where IDs are supposed to match. As an example, the Job_ID in _Job and in _JobOptions match. The dotted line indicates that on the FilesParam side, the EvtType_ID is actually stored in the Value column when the Name column contains ``EventtType'' and not as a separate column.

Figure 1.1: The design of the database tables

The whole design was intended to build thin tables on the database side by removing all columns that would not be absolutely necessary for all cases. Lines in one of the parameter tables replace these columns. As an example, the number of event of a given file is only relevant in the case of a file containing data (not in the case of a log file). Thus, is was not added in the _Files table but will be a line in the _FileParams table with name ''NbEvent'' and value the actual number of event of the associated file.

This architecture also allows taking advantage of the indexing capabilities of the underlying database to search for objects. As an example, indexes should be created in the _InputFile table, based on the file_ID and in the _Files table based on the Job_ID. This allows an efficient browse of the hierarchy of jobs and files.

In principle, every object in the data model maps to a table and every relation between objects to an ID. There are however some exceptions:

• The Type and Quality objects have actually no members. These are stored as parameters. The names of these parameters are ''Name'' and ''Version'' for Type and ''Group'' and ''Flag'' for Quality.
• Types are not mapped to a table since this table would have had no column except the ID one. They only exist through IDs in other tables. As an example, the Type_ID is used in the _TypeParams and in the _Files tables.
• Qualities are not mapped to a table. However, the table would have had two columns: one for File_ID and one for Quality_ID. For optimization purposes, it was decided that the File_ID would be replicated in every line of the _QualityParams table and that the _Qualities table would be suppressed. However, all the quality parameters defined for a given file stay grouped by the Quality_ID and will map to parameters of the same Quality object in the transient world.
• The many to many link that exists for input files requires a specific link table: _InputFiles. Each line of this table describes one link between a job and a file, which is seen as an input file of this job. Note that the output files relation is a regular relation and is thus mapped to an ID, namely the Job_ID in _Files.