A nuclear fuel reprocessing plant must ensure that all material is accounted for. The regulatory authorities need evidence of all events and corrections to ensure that no material is lost. Mistakes happen. The wrong drum is sent to a customer and the system of record needs to be corrected. Regulators need to be able to see data reports from before and after those corrections.

First and foremost the life cycle management of nuclear fuel is not that easy to understand! Additionally, to be quite honest the business team that had made the request had no expectation that the two developers who had been given the task to solve the audit challenge had any chance of success. The on site dedicated project team had been struggling for some time and were no where near a solution and as a last resort had requested a sprint exercise to assess other approaches.

Time Travel environment which underpinned the success.

The first stage of the technical journey in applying Time Travel to any requirement is to draw up a current view Entity Relationship Diagram (ERD). For the nuclear fuel management audit the ERD depicted below was devised. It is to be noted that this part of the design process is made much easier by the fact that the starting point is a current view design ie the ERD design does not require time stamp columns or audit tables. This has a massive implication for the approach to business requirements – it makes it a whole lot easier! 

After a current view entity design is devised the next stage is to set up a data model within the Time Travel framework using a script to define the entities, primary keys and referential constraints. The script for the nuclear fuel ERD shown above has been split into the 4 sections below for easier reference.

This is imported into the Time Travel environment and the database is created with the following script extract.

The “desc SELLA_SRC….” commands identify the source tables for use in application development.

The “exec gen;” command creates the database and Time Travel data entry and reporting is good to go!

The inserting of data is through the use of standard sql instruction. The developer sets the point in “valid time” or “real world time” or “the effective date” from which the business data value is valid and then inserts the data. In the data entry below, the location was available for nuclear fuel storage from 1999. The valid time system variable dbms_systime.set_valid_time() is set to ’01-JUN-1999′ and the insert command executed. The valid time variable can be set as being the present moment or any time in the past or the future depending on the valid time which applies to the business data. 

One of the great strengths of the Time Travel environment is the policing of referential integrity. This is done wholly by the infrastructure and critically relieves the developer of all temporal logic rule management. This capability is not available in any other supplier offering and is absolutely central to the productivity gains Time Travel provides developers.

As with standard referential integrity violations, the developer only needs to determine the application action when there is an attempted violation.

When inserting or updating business data, the “transaction time” or the “system time” is always set as the present moment in time. This is sometimes referred to as the moving point “Now”. The Time Travel system variable for transaction time is dbms_systime.set_transaction_time().

The reason for this is that the point in time that data is committed to a database is inviolable. In instances where it is required to record the system time relating to business data received from another system, this data is modelled as business data and committed to the Time Travel database with a valid time setting equal to the system time as provided from the source system.

Reporting uses standard select statements. For point in time reporting the developer specifies the required time points for transaction time and valid time and executes sql select statements.

The audit requirement for nuclear fuel management is an excellent example of a complex business requirement being rapidly addressed by a Time Travel capability The most challenging aspect to this work was understanding the business requirement and reflecting this within a “current view” entity relationship design. Once the current view design is devised, the feeding of the data into the database and the reporting were easily addressed. The overall analysis of this project revealed that the majority of the time was spent on writing scripts for data input! The critical aspect of the data being held and reported was wholly done by the power of a Time Travel friendly infrastructure.