About the master database

Introduction

InfoWorks WS Pro is a workgroup-based modelling and configuration management system that can also be used as a standalone product.

To facilitate both workgroup and standalone operation, InfoWorks WS Pro maintains model data in a centralised multi-user master database. Local working copies of parts of this data are then made available in each user's working folder.

The master database provides a flexible hierarchy for managing model data and contains all your model data and results. It consists of a database and directories containing supporting files including simulation results and ground models.

The data stored in an InfoWorks WS Pro master database is called master data.

InfoWorks WS Pro includes comprehensive master database management facilities, which let you organise your work logically and efficiently. Using these facilities you can see the overall structure of the database, break it down into its components, and view any part of the data itself.

Database formats supported

InfoWorks WS Pro uses its own workgroup data server as the default database component of the master database.

Support is also included for Microsoft SQL Server databases. If you already have a Microsoft SQL Server installation you can use this to create and manage master databases of almost unlimited size.

Support is also included for Oracle databases, for which you must already have your own Oracle database installation.

Database versions

Each master database has a version number. For example, a master database created with version 2023.0 of the software will have a database version of 2023.0. You can choose which version of the database is to be used when you create a master database. This can be useful if you collaborate with other users who do not work with the same version of InfoWorks WS Pro as you.

Notes:

• If you work with a master database that is older than the version of the software you are using, for example, database version 2023.0 with software version 2023.1, you may not be able to access all the new features that are available in the newer version of InfoWorks WS Pro. The availability of a new feature depends on whether or not it requires database tables and fields, such as object properties or a database item, that are only available in the newer version of the database.

• You cannot paste data copied from a master database with a newer database version than the database you are pasting to.

• You can update an older version of a master database to a newer one. This lets you access all the features available in the newer version of the software. However, the updated master database cannot be used, by you or any other user, in an older version of the software.

The version number of the currently selected master database is displayed in the Explorer window.

Organising your master databases

Master database location

InfoWorks WS Pro can be used as both a standalone product or in a workgroup. If you want to share the master database as part of a workgroup, the master database must be located on a machine where it can be accessed by all your users.

A SQL Server or Oracle installation will be visible across the network as long as the server is running.

If you are using the software as standalone, the master database can be on a server or on the local machine.

You will get best performance for workgroup operation if you keep the master database on a proper network file server.

When working as a single user, you will get the best performance if the master database is stored on your local hard disk. Bear in mind that:

• master databases can become very large
• you will have to move the master database to a shared location before other users can gain access

How many master databases?

Ideally you will have just one master database for your workgroup or even for your entire organisation. Some organisations have an extremely large (more than 20 Gigabyte) master database using an Oracle or SQL Server database.

A consultant might choose to have a different master database for each client. Water companies may divide their data based on geographical criteria.

If you have multiple master databases, you can assign each one to a named group. (This is not to be confused with object groups within a master database.)

Working folder

To facilitate workgroup operations, and to keep work in progress separate from the main data storage, InfoWorks WS Pro uses a working folder.

The working folder is a directory where working copies of files are stored. You only need one working folder, even if you work with more than one master database. Data for each master database is stored in a sub-directory of the working folder. The sub-directory name is the unique database identifier for the master database.

The data stored in your working folder is called transitory data and is made up of the following:

• working copies of checked out networks
• local results files
• other temporary working files

You should never have to access these local files directly. You can clean up unwanted local files from within InfoWorks WS Pro.

See Setting the local folders locations for more details.

Remote roots

Some master database data is not stored in the database file itself, but as separate files in remote root directories. The data most commonly stored in this way is simulation results. These tend to be very large and can reduce database performance.

The location of the remote root directories can be changed.

When working with Microsoft SQL Server or Oracle databases you must set the location for your remote roots. The remote roots do not have to be on the same drive or even the same machine as the database. You only need one set of remote roots, even if you work with more than one master database.

Files are always stored in a sub-directory of the remote root. The sub-directory name is the unique database identifier for the master database.

See the Remote roots topic for more details.

Creating master databases

A master database is created using InfoWorks WS Pro.

SQL Server or Oracle databases are created using the creation tools supplied with the database installation. Innovyze provides scripts to format the new database correctly.

You can also create and update transportable databases, which have a similar format to master databases. Transportable databases store copies of some or all the data from an InfoWorks WS Pro master database for copying and backup purposes. Archives allow you to store data for future use.

Structure and contents

InfoWorks WS Pro includes data management facilities that let you organise your work logically and efficiently within the master database.

The master database can be viewed using the Explorer window or the Model Group window. The Model Group window is the most convenient for day to day work, as it can be docked (attached) to the side of the InfoWorks WS Pro main window.

The general structure of the master database is:

• The master database contains one or more model groups.
• Model groups can contain other model groups, version controlled items, and data groups.
• Data groups can contain other data groups of the same type and database items of the correct type for the group.

Item types

Some items, such as networks, are version controlled items. These provide a safe and structured way of creating successive versions to test potential changes, or going back to a previous version and branching to explore other scenarios.

Other model data, such as electricity tariff data, is stored in data groups. Groups can be embedded within groups to provide structured storage.

Item names

Item names can be up to 80 characters long, and must not be blank. Names can contain spaces.

The names of version controlled items must be unique within a master database.

All other names must be unique within that type and its parent. For example, two data groups of different types within a model group can have the same name, but two groups of the same type must have different names.

Protecting items

Database items are marked as protected from deletion when they are used in simulations to prevent loss of critical data.

Once database items have been used in a simulation, they cannot be altered or deleted.

You can override these protections and clean up redundant model runs and data.

General structure

Version controlled items reside within model groups. Version controlled items need to be checked out before editing. Checked out items are shown with a red border to the icon.

If you carry out a run with a checked out network, the run icon is shown with a red border. The simulation icons contained under the run icon will have a red border if the control data set used for the simulation was checked out.

The colour of the run icon indicates the run type. The available types are:

	Normal Run
	Automatic Calibration Run
	Water Quality Run
	WatSed (sedimentation) Run
	Fire Flow Run
	Critical Link Analysis Run
	Shutdown Run
	Flushing Run
	Leakage Locator Run
	InfoWorks TS (Transient System) Run

Other data is stored in data groups, and groups can be embedded in groups.

The Database items topic gives a list of all the version controlled items and groups that make up a master database.

Database identifier

Each master database has a unique database identifier. When you create a new database, this identifier is generated automatically and is a string of letters and numbers guaranteed to be unique. It takes the form 629810C2-3F6B-11D3-9BF3-00600891B690. Unique database identifiers can be set manually. For instance, the identifier for the example database usually takes the form IWExamples123.

Version control

Version control allows a modeller to record major changes to a network model providing a permanent record and enforcing a standard on the calibration process. It also means that a previous model can always be revisited as a starting point if the final version is unacceptable.

If different scenarios are being investigated a model can be branched from the base model and modified independently. In this situation it is at the discretion of the individual modeller how often the model is checked back in because his modifications are independent of the base model being used by other colleagues.

Once a model has been calibrated and authorised by the manager of the modelling team, the final model may be copied to a designated secure location in the audit trail and intermediate network models removed. However the process of arriving at the final model is still available until authorisation.

See Managing version controlled items for more information.

Database administration

Further database protection is available to administrators. Some more sensitive database operations, such as deleting data in bulk, can only be carried out by administrators.

Copying master databases

You should never copy a master database, rename the copy, and then carry on using the new and original databases. Every master database has a unique database identifier (see above). This identifier is used to manage files in the working folder, and in some circumstances, files that form part of the master database itself. If you work with two master databases that have the same unique database identifier your working files will get mixed up and you run a very real risk of losing or corrupting data. Because your working copies of networks may well be based on the same root network, it could be difficult to spot that these problems are occurring.

The correct way to copy data is to create a new master database, and then open the existing master database as a guest to copy data from. Alternatively, use a transportable database to transfer data from the old to the new database. This may seem a long winded approach but it is designed to:

• let you copy data into a new master database or an existing database that already contains data
• protect the integrity of your data in both databases
• support copying data between databases of different types

Transportable databases

Transportable databases allow you to copy data between master databases, even if the databases are of different types. Transportable databases have the same internal format as a master database, and allow you to maintain the full structure of the data you are copying.

You would use a transportable database for:

• copying data from one master database to another
• sharing data with other departments or external consultants
• sending data to Innovyze as part of a support request

All types of data can be copied into a transportable database, including results files from your remote root directory.

See Transportable databases for more details.

Deleting data

Data can be deleted from the master database only before the data is used. Once data is marked as used in a simulation, it is protected from deletion by the database management system.

These protections can be overridden by administrators. See Deleting data for more details.

Backing up data

You must back up your master database - that is the database file and the GUIDA Globally Unique IDentifier, or GUID, is an automatically generated identifier that is guaranteed to be unique across all systems. It is generated using a complex algorithm based on the date and time and the individual computer's network card ID. GUIDs take the form {629810C2-3F6B-11D3-9BF3-00600891B690} and you will see them in a number of places where uniqueness is essential. directories containing supporting files (for example, simulation results and ground model files).

You should not need to back up your working folder. The only things you would lose if the directory is destroyed are changes to checked out networks since they were last checked out, and local results files.

For more information about carrying out backups, see Backing up your data.