pdf: 600KB - Potsdam Institute for Climate Impact Research

29
6.6 Representation of the model in a database
Represent a model in a database?! Seems like a strange idea, but consider the following example
implemented in Microsoft Access (Fig. 6.2).
Here we have a relational database with two tables: 'compartment' and 'flow'. The 'compartment'
table has two fields: 'compartment name' and 'initial value'. The 'flow' table has 4 fields: 'flow
name', source and destination compartments for the flow ('from' and 'to'), and the flow equation.
This represents a complete specification of the model: an appropriate human (or computer-based)
interpreter could write a program to simulate the behaviour of the model so defined. Though a
simple example, it could be easily extended to handle parameters, intermediate variables,
submodels, etc.
But - it's in a database! So we could also do normal database-type operations: interrogate the
structure of the model ("tell me the equations for all flows associated with the compartment
'water'"); or print out a summary report on the model (number of compartments, number of
outflows and inflows). If we add a 'model ID' field to each table, then we could store information
on many models in a single database, put it onto a web-enabled database, and enable anyone to
retrieve models according to their structure, through their web browser. In other words, we can
now do many things with the model that we could not do if it were implemented merely as a
computer program in a conventional programming language.
Fig. 6.2 Representation of the model in an Access database.