The structure of the database is hierarchical. The data is organized into projects. Each project can be seen as a database of its own – data is not shared between projects.

Parameters are described using definitions. Each type of parameter has a definition which determines its name, unit and dependencies as well as some general information about the parameter. The definition is identified by its name; within a project there may not be two definitions with the same name.

Values for specific type of parameter are stored in an instance. A chosen definition states the name, unit and dependencies of the parameter values. In order to identify the instance it can be given search tags. An instance can be seen as a set of values for a specific type of parameter and a specific case or scenario.

The instance has one entry for each dependency. A parameter entry (may) contain a nominal value, a probability density function as well as statistics such as mean value, min, max and number of samples.

For example: The distribution coefficient for soil is defined in the project as Kd_soil. The definition states that Kd_soil depends on atomic element and that it is unitless. When investigating different scenarios, different sets of values for Kd_soil are used. Hence, for each scenario an instance of Kd_soil is created. Each instance is tagged with the name of the scenario, and data is filled in for each atomic element relevant to the scenario.


See also:

• Dependencies
• Users and roles
• Quality assurance

Back