Материал: Крючков Фундаменталс оф Нуцлеар Материалс Пхысицал Протецтион 2011

designate the location for this to be identified. So each location is given a unique identifier. The location name does not need to be unique, still this may be accepted as a rule if approved within a department.

The CoreMAS database core accepts the concept of item. Item is what determines the material accounted for when this is split down to the smallest parts that have one type of material relating to an “item” or more than one in addition to the elements or isotopes unaccounted for. The item identifier should be unique, while the item name needs not be such.

Containerization proceeds from the logic concept of items being often batched together. A so formed batch may be in a physical container or in an assembly or combined otherwise. A physical container may contain an assembly, another container, one or more package types, or one or more items. This leads to the following generalization: a container may contain a container or containers, a package or material. Therefore, a physical container or an assembly may be dealt with using the logic containerization concept. An item in a container ceases to be capable of moving singly, without the container. For example, if a physical container contains items A, B and C, it makes no sense to account for whether item B is capable of moving without items A and C moved simultaneously. The container description identifier is used to expressly identify the container. The CoreMAS requires a unique container identifier to be given to each container. No container names or types need to be unique, still this may be made a rule if approved within a department. If process requires so, the CoreMAS database may limit the number of containers that can be placed one in another.

The CoreMAS database supports the concept of bulk material. This is generated where items are mixed so that no individual pieces can be distinguished. The examples are solutions, spills, etc. Bulk material normally has the form of a solution in a tank or a process line. When moved across accounting or physical boundaries, these are measured to determine the material quantity to be accounted for as of the given time. A bulk material description identifier is used to expressly identify bulk material.

CoreMAS user characteristics

Expected to delimit access to data depending on the user status, an NM A&C system requires its database to contain the concept of user. Depending on the functions performed, the following CoreMAS user groups are identified:

346

∙accounting of NM: persons who enter data on the operations done on material to be used by personnel who have no access to the material accounting system. They enter data on operations for offsite shipments and receipts of material;

∙handling of NM: all persons immediately involved in material handling. These include those dealing with in-process or stored material and with the material prepared for shipment;

∙guarding of MBAs: persons responsible for the material held in the MBA they are in charge of;

∙measuring operations: persons who measure material;

∙inventory taking: persons who compare the physical inventory data against the book inventory;

∙management of material: persons who prepare regular and special reports and respond to inquiries for internal and external use;

∙system administration: persons in charge of the CoreMAS configuration and servicing.

Users are given the rights and permits of access to information as defined by their respective status.

CoreMAS database tables

The database core includes all the tables essential to the accounting system operation. We shall look at essential groups of database tables and into how these interconnect. Each table in the relational database describes one entity, be it a subject or an object. The communication between entities is via primary and foreign keys (PK and FK). Some CoreMAS tables may have no connections to other tables whatever; these are archive tables, tables of constants and some others. For example, the Container ID table stores the ConID value that contains the next container number to be given to the next databased container.

The CoreMAS contains a total of about one hundred tables. The complete ERD is very complicated and cannot be described herein. Organizationally, all tables are grouped by functionality. Given below are the functionality descriptions and the listing of basic tables for each of such groups. These groups are:

∙authorization;

∙computation;

∙measurement;

∙containerization;

347

∙transaction;

∙material;

∙reporting.

Authorization. This group of tables controls the process of operations on the CoreMAS menu options being authorized. It defines which accounting and control functions are accessible to the given user. Names of tables in this group: Users, Usergroup, Groups, GroupAuth, Authorization, Operation, UserOpNameAcct.

Correction. This is a group of correction tables that deal with the algorithmic steps to be taken to compute or determine the quantity of material by measurements. Example: there is a tank containing a liquid and it is required to compute the volume from the liquid level, for which purpose a cylinder volume formula is used. The tables in this group are: MatlTransformNumber, MtMatlOutput, MtIsoAmountOutput, MtInput, MtElementToOutput, MtMeasurement, and Decay. The Decay tables keep track of the decay rates for isotopes and their derivative isotopes. The MT tables are temporary tables which contain intermediate splits, combinations and changes of material as of the transaction result approval time, following which information is saved into the Material (NETWt), Element (ElementWt) and Isotope (IsoWt) tables.

Measurement. The Measurement group of tables stores measurement results and measurement units. The tables in this group are: MTMeasurement, MeasMatl, MeasElem, MeasIso, MeasType, UnitConversion, Unit, MeasNumber, Instrument and InstrumentNumber. The MTMeasurement table links measurement results to the transaction during which the material’s quantitative characteristics were updated by calculation.

The Containerization group’s tables are arranged so that to ensure the unlimited:

1)number of containers that can be put into one another;

2)packaging relating to containers;

3)number of tamper indicating devices (seals) applied to container, material or location.

This group includes Container, ContainerNumber, ConType, ConTypeNumber, Packaging, PackageType, PackageTypeNumber, TID, TIDType, TIDNumber and TempConMovement tables.

Transaction. The Transaction group of tables describes transactions in the CoreMAS. The Transfer and TransferNumber tables describe links to the report generation function. The Terminal table contains information on

348

the client computer from which the transaction was put in. The StatusType, StatusOpType and OpType tables contain types of transactions that can be done to material in different states (e.g., anticipated, unmeasured, written off). This group includes Transaction, Terminal, AcctPeriod, TransactionNumber, AcctPeriodNumber, StatusType, StatusOpType, OpType and TIC tables.

The Material group includes all other tables to the exclusion of the reporting tables (STPError and TableVer). These tables contain descriptions of material, elements and isotopes; the accounting logic (to which, logically, material balance areas (MBA), physical location, material forms, detailed or general types of material the given material belongs); physical elements and isotopes; descriptions of forms and processes relating to elements and material; material classification for the report generation function (COEI tables). Some of the tables in this group are: Material, Element, IsoAmount, ElemType, IsoType, ElemForm, MatlForm, COEIProfile, COEICode, Project, DetlMatlType, SumMatlType.

The Reporting group includes tables which are representative of the state report system (clearly, the USA’s). These tables have been included in the COREMAS with a premise that each country to where COREMAS will be delivered will form its own state standard. Some of the tables in this group are: TransactionEvent741, TransferNumber, Transfer, TransactionDetail741, ShipRecMatlDiff, ShipRecElemDiff, ShipRecIsoDiff, Comment, TransportPackaging, TmpProject, TmpCOEIDetail, TmpMBRSubtotal, TmpCOEI, TmpIntAdjust, TmpCOEISumIso.

When operating the database by adding and deleting rows, one needs to see that the foreign keys of tables always indicate at the existing primary keys. This rule is called consistency of links and should be at all times observed. Most up-to-date relational databases do checks automatically whenever table fields are declared to be primary or foreign keys. This property is ensured in SQL Server 6.5, but, because the CoreMAS was originally developed for version 21 which did not ensure the consistency of links to be tracked down, the CoreMAS includes other software tools to support this consistency.

Stored procedures of the CoreMAS database

Stored procedures are the following database objects to consider as components essential to the A&C system operations. It is only via stored procedures that a CoreMAS user is granted access to the database. This

349

gives the database a much greater capability, efficiency and flexibility and accelerates drastically the speed of response for SQL queries.

Stored procedures are translated and optimized in the Transaction SQL language queries that are stored and processed directly on the server. Only the name and formal parameters of the procedure are networked and the query result is sent back. This accelerates processing and cuts network traffic.

One more point to this approach is that it enables highly differentiated control of access. Though SQL Server 6.5 allows user authorizations at the column level, stored procedures enable this to be done without using SQL Server access accounting mechanisms.

The CoreMAS uses a total of over 300 stored procedures which support most diverse NM A&C system functions.

General requirements to transactions

Essential functional operations of any A&C system are organized via transactions. Transaction is a set of data handling operations performed integrally in the database. Where not all of them can be performed, the transaction “rolls back”, which means that the data base is reset to the status it had before the transaction. Any CoreMAS transaction is done in five consecutive steps:

∙input: what the user should submit for the transaction to be successfully launched,

∙normal handling: what is to be done by the CoreMAS core application,

∙exception handling: handling of exception cases,

∙user authorization: determination of which transaction may be entered by the given user for the material in the given record,

∙output – the anticipated result of the successful t ransaction.

To enter a transaction, one needs to have a unique identifier to enable identification of the data record concerned. It may be identifiers for the descriptions of material, containers or material location, or identifiers оf instruments. The moment the identifier is authenticated, data elements are needed to specify the type of the transactions required.

Any time the material is changed as the transaction is normally handled, the respective transaction will be recorded and so the changes in question will be identified. No transaction record is subject to erasure or update. In the event of an error found after the transaction is recorded, input data is to be created to rectify the error and a separate corrective transaction should be done. No description data is permitted to be physically updated or erased

350