Dependencies (Parameter database)
Parameter values often have dependencies, such as dependency of atomic element (Iron, Methane, Oxygen), on media (concrete/clay/rock) or location (Paris, Gothenburg, Kampala). From the database point-of-view, the dependencies change the parameter dimension. Kd_soil can be a scalar parameter if only one atomic element is ever considered, a vector if values are available for many elements or a matrix if both atomic elements and different soil types are considered.
The database allows up to two dependencies to be defined for a parameter. If more dependencies are required the user must either create several definitions (Kd_soil, Kd_bentonite, Kd_backfill) or use tags (Kd soil, Kd bentonite, Kd backfill).
A dependency is described with a name (“Atomic element”) and a listing of indices for the dependency (“Iron”, “Methane” etc).
Subsets
A subset is used when only some indices of a dependency apply to a parameter. For example, say that the database contains a dependency named “Contaminant” which lists 50+ different compounds. A parameter is to be defined which is only used for hydrophobic compounds. Using the “Contaminant” index list would unnecessarily create long tables for the parameter values. Instead, a sub-set of “Contaminant” can be defined named “Hydrophobic contaminants” which only includes the hydrophobic compounds of “Contaminant”. In the database notation, the Contaminant dependency would be the parent dependency.
Mapped index lists
Sometimes a dependency is naturally related to another dependency. For instance, the dependency Species is related to the dependency Organism. One can therefore document that a given dependency “maps” to another when a dependency is defined. A typical case is between atomic element and isotope. In the database notation it is said that the atomic element dependency maps to the isotope dependency. Mapping means that a parameter can be used in both the context of its own dependency and in the context of mapped dependency.
Also see:
