Skip to content
Welcome to the next generation MIKE+ Documentation

MIKE+ Data Structure

The MIKE+ data storage is divided into a number of data stores.

The main storage for the model data is SQLite (or PostGIS database, optionally). But a number of additional files and data stores define the MIKE+ functionality such as binary result files and configuration files.

MIKE+ is installed with SQLite/SpatialLite. If you want to use the alternative database option, PostgreSQL/PostGIS then you must install the two products found in the “Prerequisites\ PostgreSQL” and “Prerequisites\PostGIS” folders. For more details please check the MIKE+ Installation guide.

Terminology

Storage Database

This is a database with a structure similar to a GIS database. It is used to hold the model data such as physical network description and other physical data, input data to the various numerical engines as well as general setup information. A database may hold only one instance of a particular model (however one database may hold water distribution, collection system and river data). The format of the database is also the basic data format used by Spatial Lite SQLite database (alternatively, PostGIS).

The Project File (.mupp)

This file holds all information about the current user setup. A project file will thus hold the individual settings for the user such a symbology for the featured network elements, pointer to added background data, etc.

Configuration and Import Bridges

These files are normally not touched by the user but may in certain circumstances be changed to fit individual user setups.

Time Series and Result Data

Binary data in the form of input timeseries data as well as result data are stored externally in binary data files.

Storage Database Basics

The MIKE+ database uses a SQLite database. SQLite is an embedded SQL database engine. SQLite is a C-language library which implements a fast, self-contained and highly reliable SQL database engine.

MIKE+ also allows the use of PostGIS as storage database format. PostGIS is an extension to the PostgreSQL object-relational database system, this engine allows GIS objects to be stored in the database. The use of a PostGIS database requires that a PostgreSQL installation is already available on a server (consult your IT service for the initial configuration). For more information about PostGIS please visit http://postgis.net.

The structure of the MIKE+ database is very much like a normal database consisting of tables having columns (or fields). What makes it special are:

  • The database contains a predefined datastructure needed for GIS to operate correctly on the database
  • Some tables are called 'feature classes' because they contain a special binary formatted column defining the spatial geometry of the object (row)

You can operate the database through SQL commands, but please be very careful if you try to manipulate data with such tools; always have a backup of your database.

Scenario Management

The database may contain a variety of scenarios of each model. These scenarios are managed by MIKE+ through the Scenarios Editor. Scenarios are in general stored as difference tables - the use and documentation of these are beyond the scope of this documentation.

It must be noted however that when opened with any tool, the database will represent the current active MIKE+ scenario.

The MIKE+ Database Contents

The MIKE+ database will contain all model parameters for the active model(s). Data is stored in either:

  • Feature classes. These are database tables with spatial contents (such as pipes, nodes, etc.)
  • ‘Standard’ database tables i.e. tables without a spatial content.

Naming Convention

All feature classes and tables follow the same naming convention:

Table Description
m_ Means that the table is a general MIKE+ table covering all parts of MIKE+ (typical configuration information)
ms_ Means that the table belongs to the collection systems part of MIKE+ i.e. common to any of the numerical engine models
mw_ Are tables specific to the Water Distribution network
msm_ Are tables specific to the MIKE 1D model of collection systems
mrm_ Are tables specific to the MIKE 1D model for river networks
mss_ Are tables specific to the SWMM network
m2d_ Are tables specific to the 2D overland module

Table: Feature classes and tables - naming conventions

Information on the individual fields of the database may be found in the sections of the manual describing the individual parameters. Generally it is not recommended to use characters such as ‘?’ and ‘'’ in any unique names (MUIDs). Database fieldnames are also shown as tooltips in the individual data editors when hovering over the field.

PostGIS database specifics

Using a PostGIS database allows to save the project database on a central server. This e.g. eases sharing model data amongst users, since various users can successively connect to the database as long as they have access to the server, without having to move the project files.

With a PostGIS database, it is also possible to have multiple users connecting to the database simultaneously, allowing e.g. model building by multiple users. The primary goal of this functionality is to allow users to review and analyze the model data simultaneously, or to allow them to build / edit different parts of the model. The following applies while multiple users are accessing the same PostGIS database:

  • Some settings or functionalities which have an impact on the entire project are disabled. For instance, importing other model setups into the database (from File \ Import menu) is not possible, and changing the unit system is disabled, in order to avoid severe conflicts between users which could otherwise happen. To enable such functionalities again, only one user must be connected.
  • If multiple users are to edit data simultaneously, it is recommended that they enable the auto-refresh option, so that changes made by one user are visible to others as well (see User preferences, for details on the auto-refresh option).
  • If multiple users are to edit data simultaneously, it is also recommended that they ensure to edit different data to avoid conflicts. For example, even if the auto-refresh option is active (see , a small delay will usually occur after a change is made by a user, before it appears for the other users. Therefore, if one user edits (or delete) a feature, the change should soon be visible to others but there is possibly a short period of time during which others may apply a conflicting change (and if the node was deleted by the first user, the changes made by others will simply be lost).
  • If result files are loaded in the project, they may not be refreshed if another user later re-run a simulation which changes the results. As a consequence, the loaded results may not show the results of the latest simulation.
  • The option to support multiple users only applies to the database. The MIKE+ project may however contain other types of files, storing e.g. time series data, 2D overland domain data or cross sections data, which can only be edited by one user at a time.