Virtual Data Modeling Layer

To understand exactly what this means in practice, let's start with a brief introduction to the world of databases...

Database model

The basis for structuring the data and their relationships to each other is the database model, which is defined by the DBMS manufacturer. Depending on the database model, the database schema must be adapted to certain structuring options:

• hierarchical: the data objects can only be in a parent-child relationship to each other.
• network-like: The data objects are connected to each other in networks.
• relational: The data is managed line by line in tables. There can be any number of relationships between data. They are defined by the values of certain table columns.
• object-oriented: The relationships between data objects are managed by the database system itself. Objects can inherit properties and data from other objects.
• Document-oriented: The objects to be stored are stored as documents with possibly different attributes, i.e. without the requirement of structural equality

Advantages of relational databases

• Simple data model
• Data consistency (with normalized models), as changes are made centrally and only in one place
• Linking via content
• Entry points are arbitrary due to equal relations
• By breaking down all objects into individual parts, the data is processed in a quantity-oriented manner. This allows complicated and complex queries to be performed on large amounts of data and powerful operations
• High degree of data independence: navigation is entirely the responsibility of the database system and is therefore simple for the user
• Standardized uniform database language for several providers

This is why we work exclusively with relational databases such as MSSQL, PostgreSQL and ORACLE.

Every application software requires three systems

• Development system
  Development platform in the DMZ and only accessible internally
  
  
• Test system
  Platforms outside the DMZ and therefore only accessible to testers. After approval by the testers (in our case the customer), it is migrated to the
  
  
• production system
  and is therefore visible and productive for everyone

The challenge with multiple systems: The migration of models and data

The data model must be changed or expanded for new processes and functions. This affects tables, foreign keys, indices and their data content, for example. These must be migrated to the test system and later to the production system during operation, as efficiently as possible, i.e. without system downtime.

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

• Semantic gaps are created: 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 relationships cannot be expressed either, as it is not possible to assign sub-tuples to the tuples in the classic relationship model.
• No differentiation between identity and compatibility columns
• Declaration of only a few data types possible
• The data fragmentation required for normalization makes it difficult to search for more complex relationships in terms of content and performance: Data that is stored separately from one another must be reunited at the application level in the form of joins.
• Little knowledge can be stored about the rules and functions associated with the data.

Conclusion
Data model migrations are time-consuming.

The solution to gain only advantages: Our self-describing databases using metamodels.

To eliminate all these disadvantages in practice, we have developed a metamodel that describes itself and is enriched with virtual data types.

This makes migration extremely fast, accurate and error-free. Not only that, but we can also easily migrate content across systems, as we know identity and compatibility data and can use this. 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 cross-checked with the real existing databases. What do you get out of it? Maximum stability, agility, flexibility and efficiency for extremely rapid growth.