RAIS RAIS 4 Fiche technique télécharger pdf (Page 13)

RAIS 3.0 Programmer’s Guide – Part I : Advanced Customization

letter M. This letter makes the menu node for our protector appear under the menu group

Common Tables. A hidden menu group exists in RAIS for hiding all protectors, having the

key prefix Y. Rename the key of the new protector to something like Y99, meanwhile taking

care that this key is not yet used.

2.1.3 Comments

It is allowed to extend the table definition of protectors to include for instance a category of

facilities to be protected. Values for this category could be Management or Administration.

However, the basic field mentioned above must exist for protection to be executed upon

record operations.

Although such extensions are possible, it is highly recommended to move fields such as

above mentioned category field to the RAIS tables (in above example the facility). The

preselection lists for the form [Protector Facility] may then be extended in such a way to

include that category field (see section 2.6).

Protectors may be created to protect for deletion of departments, instead of facilities. This

would prevent for direct deletion of protected departments, of course, but not for cascaded

deletions by deleting the facilities protected departments belong to. To avoid cascaded

deletions, protectors must be created for both facilities and departments. Cascaded deletions

have to be considered when protecting any information items.

Note

We have defined the protector for protecting the waste management facility to be called

[Protector Facility]. We did not call it [Protector Waste Management] as it might be useful

to protect other facilities as well. Records for those facilities may simply be appended to this

protector, and the naming convention still is meaningful and correct.

Take utmost care not to introduce duplicate key values. Take care that all key values must

comply with the format L99, a letter followed by two digits.

2.2 Creating Custom Evaluators

Some records in RAIS 3.0 have special functions, and the existence of those records is

required for the good functioning of RAIS 3.0. Examples of such records are all [unknown]

records; these exist in the tables [Generator Model], [Generator Type], [Manufacturers] and

many more. These records exist in the default values database of RAIS 3.0, distributed by the

IAEA. [unknown] records have a primary key value of 1 in the default value database of the

IAEA. Queries could then use a filter value of 1 to retrieve all generators where the model is

unknown:

Select * from [generator] where [fk model id] = 1

As long as [unknown] records are associated the primary key value of 1, above mentioned

query will function correctly. However, we must keep in mind that many countries will use

consolidation, and that during consolidation records are appended. From this observation, it

may happen that primary keys are shifted during append in the destination database, so that

the [unknown] records will have a new primary key value.

1 2 ... 8 9 10 11 12 13 14 15 16 17 18 ... 60 61

Pas de commentaire

RAIS RAIS 4 Fiche technique Page 13