The Oracle analysis interface

The version management in Oracle

Most parameters used by the analysis change over time and need a version management in Oracle. Some data can have only one valid value at a certain date as for example the position of a certain cable, other ones may even change over time for a certain DAQ run depending on the status of the analysis.

The mayor requirements are:

• It must be possible to get a consistent set of informations at any date.
• To keep the history, no information, even if it is wrong, should to be overwritten without trace, to get an answer on the questions like this: Which parameters have I used when I did the analysis of these runs six months ago?
• Good performance

All tree- and condition-style parameter containers have a three dimensional version management:

1. time axis of runs
2. time axis of history
3. parameter context

A version is valid for a certain time range on the runs axis and on the history axis (defines a 2-dim plane) and for a specific parameter context (different 2-dim planes with individual time ranges).

A parameter or parameter set has 5 variables in Oracle for the version management:

Variable	Description
valid_until	Last date when the entry is still valid. (01-JAN-4000 00:00:00 for actual valid version)
date_create	Date when a version is inserted
invalid_since	Date when the entry is replaced by a new or better version and therefore gets invalid.
valid_since	First date when the entry is valid.
context_id	Identifier of the parameter context

Valid_since and valid_until define a time range on the runs axis and are defined by the user.
Date_create and invalid_since define a time range on the history axis and are set automatically.

Example: The user validates at a certain point in time (created on the history axis in the picture below) a version 1 for the time range t1 t2 (valid_since - valid_until) on the runs axis (yellow rectangle).
Date_create is set automatically to the actual date and invalid_since to year 4000 (open end on the history axis).
This version will now be used for initialization of all runs with start times between t1 and t2.

At a later time, a user insert a new version 2 for the same context and validates it for the time range t3 t4 (orange rectangle), in this example in a smaller time range than the first one.
The WebDB validation GUI sets the entry of version 1 invalid by setting invalid_since to the insert date minus 1 second. It then inserts three new rows:

1. version 1 in time range t1 until (t3 - 1 second)
2. version 2 in time range t3 until t4
3. version 1 in time range (t4 + 1 second) until t2

Date_create and the invalid_since of these new entries are set automatically to the actual time of the insert, respectively year 4000.

From now on a parameter container will be initialized for runs with start times between t3 and t4 with version 2, for the other ones still with version 1.
But if the user sets the history date to a time before version 2 was created, all runs will be initialized with version 1.

One can define a parameter release for a beam time or a simulation projects. These are (named) timestamps on the history axis.
In the analysis interface the history date is set by default to the time stamp of the last parameter release or to now, if no parameter release exists.
The user may overule this by setting explicitly a history date in the analysis macro.

-- IlseKoenig - 01 Jul 2007