Virtual Data Modeling Layer
Datenmodelle haben eine wesentlich längere Lebensdauer als Software, welche Funktionen und Prozesse umfasst. Daher haben wir von Anfang an unseren Fokus auf die Datenqualität gelegt. Nach über 15 Mannjahren Entwicklung haben wir ein Tool entwickelt, welches den Bauplan einer Datenbank beschreibt, um sich damit stabil, konsistent, optimal und extrem schnell fehlerfrei zu replizieren.
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. Hier einige Beispiele:
Virtueller Datentyp bei ICONPARC
- eindeutiger Schlüssel (unique_key & als Identitätspalte gekennzeichnet)
- Boolsches Flag (boolean_flag)
- Objektname (name)
- Primärschlüssel (objid)
- Beschreibung (description)
- Ersteller des Objects (creator)
- Bearbeiter des Objects (updater) als
... entspricht dem realen Datentyp bei 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
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.
