This page hosts the documentation of the SmartCGMS software architecture and all of its components.

Database schema

The database schema is best described by the ERA diagram below:

ERA diagram

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, the comment can be added to the subject entry.

The table 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_string, value_int and 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 measured_value and model_parameters are in the many-to-one relationship to the time_segments table. 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 model_parameters table. Every parameter set belongs to a model-signal pair. The GUIDs of both these entities are stored in the model_id and 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

The table 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.