We work exclusively with relational databases such as MSSQL or ORACLE. These include per system up-to-date

  • > 1,000 tables
  • > 9,000 columns
  • > 3,000 foreign keys

Enormous advantages of relational databases

  • simple data model
  • Data consistency (with normalized models), since changes are made centrally and only at one point.
  • Link via content
  • Entry points are arbitrary through equal relations
  • By splitting all objects into individual parts, the data is processed quantity-oriented. This enables complicated and complex queries to be made for large amounts of data and powerful operations.
  • High degree of data independence: The navigation is completely incumbent on the database system and is therefore easy for the user.
  • Standardized uniform database language for several providers

Each B2B platform requires three systems distributed over two or three locations

Development System

  • here, in the heart of Munich, we are developing our software in the DMZ.

Staging System

  • here our customers test their platforms outside the DMZ. After release, it is tested on

Live System

  • and is thus visible to everyone - provided it is not a closed B2B system.

The challenge of database migrations

New processes are jointly defined for our customers. Initially, we develop these on the development system. For this purpose, the data model may have to be changed or extended. We create new

  • spreadsheets
  • foreign keys
  • indices 

on. They have to come on staging system and later on live system during operation, without any interruption and as efficiently as possible.

And this is exactly where the disadvantages of relational databases come into play

  • Semantic gaps: Entity types are stored in tables. These semantic relationships between entities, as defined in the Entity Relationship Model, cannot be explicitly expressed in a relational model.
  • Is-a and Part-of relations cannot be expressed either, since it is not possible in the classical relation model to assign sub-tuples to the tuples again.
  • No distinction between identity and compatibility columns
  • Declaration of only a few data types possible
  • The necessary splitting of data into individual parts during normalization makes the search for more complex contexts more difficult in terms of content and performance: Data that is stored separately must be merged again at the application level in the form of joins.
  • Little knowledge can be stored about the rules and functions associated with the data.


Data model migrations are costly

The solution to gain only advantages

Our self-describing databases using metamodels

In order to eliminate all the above disadvantages in practice, we have developed a metamodel that describes itself and is enriched with virtual data types.

Here are some examples:

Virtual data type at IconParc

  • unique key (unique_key & marked as identity column)
  • Boolean flag (boolean_flag)
  • Object name (name)
  • Primary key (objid)
  • Description (description)
  • creator of the object (creator)
  • Editor of the object (updater) as 

... corresponds to the real data type for MSSQL

  • varchar(50), not null + unique index
  • integer, not null
  • varchar(50), not null
  • integer, not null + primary index
  • text, nullable
  • integer, not null + foreign key to users
  • integer, not null + foreign key to users

This makes migration extremely fast, accurate and error-free.


Not only that, but we can also migrate content across systems without any problems, because we know identity and compatibility data and can use them. 

And we can also automate larger migrations to a specific system, for example at night, so that performance is not impaired during the day.

To avoid errors, all databases on all systems are crawled hourly and the metamodel is checked against the real existing databases.

What do our customers get out of it?

Maximum agility, flexibility, efficiency
for extremely fast growth