Virtual Data Modeling Layer

Basis

Database models have a much longer lifespan than software, which consists of functions and processes. That is why we have focused on data quality from the start. After more than 15 man-years of development, we have created a tool that describes the blueprint of a database so that it can be replicated stably, consistently, optimally and extremely quickly.

Um zu verstehen, was das genau in der Praxis heißt, beginnen wir mit einer kleinen Einführung in die Welt der Datenbanken...


Datenbankmodell


Grundlage für die Strukturierung der Daten und ihrer Beziehungen zueinander ist das Datenbankmodell, das durch den DBMS-Hersteller festgelegt wird. Je nach Datenbankmodell muss das Datenbankschema an bestimmte Strukturierungsmöglichkeiten angepasst werden:

  • hierarchisch: Die Datenobjekte können ausschließlich in einer Eltern-Kind-Beziehung zueinander stehen.
  • netzwerkartig: Die Datenobjekte werden miteinander in Netzen verbunden.
  • relational: Die Daten werden zeilenweise in Tabellen verwaltet. Es kann beliebige Beziehungen zwischen Daten geben. Sie werden durch Werte bestimmter Tabellenspalten festgelegt.
  • objektorientiert: Die Beziehungen zwischen Datenobjekten werden vom Datenbanksystem selbst verwaltet. Objekte können Eigenschaften und Daten von anderen Objekten erben.
  • dokumentenorientiert: Die zu speichernden Objekte werden als Dokumente mit möglicherweise verschiedenen Attributen, d.h. ohne die Voraussetzung der Strukturgleichheit, gespeichert


Vorteile von relationalen Datenbanken

  • einfaches Datenmodell
  • Datenkonsistenz (bei normalisierten Modellen), da Änderungen zentral und nur an einer Stelle erfolgen
  • Verknüpfung über Inhalte
  • Durch gleichberechtigte Relationen sind Einstiegspunkte beliebig
  • Durch die Zerlegung aller Objekt in Einzelteile werden die Daten mengenorientiert verarbeitet. Damit können komplizierte und komplexe Abfragen auf große Datenmengen und mächtige Operationen erfolgen
  • Hohes Maß an Datenunabhängigkeit: Die Navigation obliegt völlig dem Datenbanksystem und ist damit einfach für den Nutzer
  • Standardisierte einheitliche Datenbanksprache für mehrere Anbieter

Darum arbeiten wir ausschließlich mit relationalen Datenbanken wie MSSQL, PostgreSQL sowie ORACLE.


Jede Anwendungssoftware benötigt drei Systeme

  • Entwicklungssystem
    Entwicklungs-Plattform in der DMZ und nur intern erreichbar

  • Testsystem
    Plattformen außerhalb der DMZ und damit nur für Tester erreichbar. Nach Freigabe der Tester (in unserem Fall der Kunde) wird es auf das

  • Produktivsystem
    migriert und ist damit für alle sichtbar und produktiv


Die Herausforderung bei mehreren Systemen: Die Migration der Modelle und Daten

Für neue Prozesse und Funktionen muss das Datenmodell verändert bzw. erweitert werden. Dies betrifft z.B. Tabellen, Fremdschlüssel, Indizes sowie deren Dateninhalte. Diese müssen im laufenden Betrieb auf das Testsystem und später auf das Produktivsystem migriert werden, möglichst effizient, also ohne Downtime der Systeme.


Und genau da kommen die Nachteile von relationalen Datenbanken zum Tragen

  • Entstehung semantischer Lücken: Entity-Typen werden in Tabellen abgelegt. Diese semantische Beziehungen zwischen Entitäten, wie sie im Entity-Relationship-Modell definiert werden, können in einem Relationenmodell nicht explizit ausgedrückt werden
  • Is-a- und Part-of-Beziehungen lassen sich ebenfalls nicht ausdrücken, da es im klassischen Relationenmodell nicht möglich ist, den Tupeln wiederum Sub-Tupel zuzuordnen.
  • Keine Unterscheidung von Identitäts- und Kompatibilitätsspalten
  • Deklaration von nur wenigen Datentypen möglich
  • Die bei der Normalisierung erforderliche Zerlegung der Daten in Einzelteile erschwert inhaltlich und unter Performance-Gesichtspunkten die Suche nach komplexeren Zusammenhängen: Daten, die getrennt voneinander gespeichert werden, müssen auf der Anwendungsebene in Form von Joins wieder zusammengeführt werden.
  • Es lässt sich wenig Wissen über die Regeln und Funktionen speichern, die mit den Daten verbunden sind.


Fazit
Datenmodell-Migrationen sind aufwendig.

Die Lösung um nur Vorteile zu gewinnen: Unsere selbstbeschreibende Datenbanken mittels Metamodellen.

Um all diese Nachteile in der Praxis auszuräumen haben wir ein Metamodell entwickelt, welches sich selbst beschreibt und mit virtuellen Datentypen angereichert ist. 

Damit erfolgt die Migration extrem schnell, zielsicher und fehlerfrei. Nicht nur das, sondern wir können auch die Inhalte problemlos systemübergreifend überführen, da wir Identitäts- sowie Kompatibilitätsdaten kennen und diese heranziehen können. Und wir können größere Migrationen auch automatisiert zu einem bestimmten System ausführen lassen, zum Beispiel in der Nacht, damit unter Tags die Performance nicht beeinträchtigt wird.

Um Fehler zu vermeiden, werden alle Datenbanken auf allen Systemen stündlich gecrawlt und so das Metamodell mit den real existierenden Datenbanken gegengecheckt. Was Sie davon haben? Maximale Stabilität, Agilität, Flexibilität, Effizienz für extrem schnelles Wachstum.

Hier ein kurzer Auszug, wie das Metamodell funktioniert:

Virtueller Datentyp bei ICONPARC 

  • Primärschlüssel (objid)
  • eindeutiger Schlüssel (Identitätspalte)
  • Objektname (name)
  • Beschreibung (description)
  • Boolsches Flag (boolean_flag)
  • Ersteller des Objects (creator)
  • Bearbeiter des Objects (updater) als 

... entspricht dem realen Datentyp bei MSSQL

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

Problemstellung in bildlicher Darstellung:

Ergebnis aus unserer Metamodell-Lösung:

To the module overview

Whitepapers

Customer Testimonials