The database schema is best described by the ERA diagram below:
The schema is designed to be as generic, as possible to reflect the signal-processing purpose of the framework.
If the database driver does not recognize the uuid type, a similar type could be used, e.g.; guid, or a varchar of matching size. The same applies to the datetime data type - usually, a varchar type is used to store datetime (e.g. when using SQLite, that does not support the datetime type). Regarding the byte array data type, one usual substitution is the blob (binary large object) data type or similar.
Rows in the
subject table represents subjects (human, animal or virtual). Every subject has its unique
id. It also has a
name, that is displayed in the GUI. Optionally,
comment can be added to the subject entry.
subject is in a one-to-many relation to the
subject_properties table. It contains GUID-identified properties of subjects. There are three columns, which may store the parameter value -
value_double. Exactly one of these columns must be filled.
Time segments, values and parameters
Every time segment has a record in the
time_segments table. Tables
model_parameters are in the many-to-one relationship to the
Segments should have their name attribute filled to distinguish them in the GUI.
Measured values are stored in the
measured_value table. Each recorded value is stored by its signal GUID in the
signal_id attribute. Model parameters are stored in the
Every parameter set belongs to a model-signal pair. The GUIDs of both these entities are stored in the
signal_id attributes, respectively. Multiple parameters of a single model-signal combination
are allowed. If there are multiple parameter sets stored, they all may be used as solution hints for solvers.
Identifier name maps
id_names serves as an information table. It stores the GUID-name pairs of every GUID-identified entity stored in the database. The use of this table is not mandatory, though it is recommended. No currently implemented
entity currently uses this table.