Data Migration Map

Bei einer Daten-Migration geht es darum, Daten von einem System in ein anderes zu überführen. Klassischerweise geschieht das bei einem Produktwechsel. Die Daten aus dem Alt-System müssen dabei ins neue System überführt werden. 

Herausforderung

Auch wenn beide System den gleichen fachlichen Zweck abdecken, so ist die Datenmodellierung innerhalb der Systeme nie dieselbe. Natürlich ist eine Adresse auch nach der Migration noch eine Adresse, aber vielleicht besteht sie nun aus zwei Adresszeilen und einem Postfach, währenddem sie vorher nur ein einziges Feld war – oder umgekehrt. Komplexe Modellunterschiede sind eine der Hauptherausforderung bei einer Datenmigration.

 

Es empfiehlt sich grundsätzlich ein Data Mapping zu erstellen, um herauszufinden wo die Datenfelder im neuen System schlussendlich abgelegt werden.

Data Mapping

Ein Data Mapping wird klassischerweise auch beim Datenfluss zwischen Inhouse-Schnittstellen oder beim Aufbau eines Data Warehouses erstellt. Die Komplexität des Mappings hängt jedoch vom unterliegenden Datenmodell, der Hierarchie und der Datennormalisierung ab. Das Adressbeispiel oben ist ein einfaches, flaches Mapping. Es kann aber gut sein, dass die Adressen im Quellsystem über mehrere Tabellen verteilt sind: Person-Tabelle, Adress-Tabelle, PLZ-Ort-Tabelle, Ländercode-Tabelle, etc. – D.h. die Felder kommen von verschiedenen Quell-Tabellen in eine Zieltabelle und unterliegen somit zwangsmässig einer Transformation, welche sehr komplex werden kann.

 

Data Mappings sind hilfreich bei fachlichen Anforderungen und Spezifikationen. Bei der technischen Herleitung, wie nun die Daten effektiv migriert werden müssen, reichen sie jedoch nicht mehr aus.

Das Zielsystem gibt die Struktur vor

Am Ende müssen die Daten im Zielsystem landen. Somit gibt dieses die Struktur vor, in welcher die Daten für die Überführung vorliegen müssen. Die Struktur kann anhand der finalen Datenbanktabellen, mittels Importvorlagen (JSON, CSV, Excel) oder via Staging Tabellen (Zwischentabellen auf einer Datenbank) vorgegeben werden. Wie migriert wird, hängt von den verwendeten Systemen (Technologien) und dem Zugriff auf die Systeme ab. Ein Direktimport in die finalen Datenbanktabellen kommt selten vor, da kein Software-Anbieter dies zulassen möchte (was nebenbei auch nicht empfehlenswert ist, denn oftmals kommen Business Rules zum Einsatz, welche dann die unterliegenden Tabellen befüllen). Gängig ist, die Daten mittels Staging Tabellen oder Files zur Verfügung zu stellen.

Data Migration Source Target

Die Staging Tabellen (oder Files) werden oft vom Provider des Zielsystems vorgegeben und ist die Vereinbarung für die Datenlieferung (A) aus dem Quellsystem. Den Import oder Load (B) ins Zielsystem wird oftmals vom Provider selbst durchgeführt, da dieser über das nötige Knowhow, Tools und Zugriffe verfügt. Alternativ stehen definierte Importschnittstellen oder API zur Verfügung, welche die Entwickler nutzen können.

Hilfsmittel Migration Map

Als verantwortlicher Entwickler für den Export realisiert man schnell, dass die Datenfelder auf das neue Modell transformiert werden müssen – das heisst eine andere Struktur abbilden. Mit der Kenntnis des Quellsystems und der neuen Zielvorgaben empfiehlt es sich eine «Migration Map» zu erstellen. Mit diesem Hilfsmittel wird der Weg vom Quellsystem ins Zielsystem visualisiert, ohne dabei auf Feldebene zu gehen. Es versteht sich daher als eine Unterstützung, um die Datentransformation anhand von Business Objekten zu entwickeln, nachzuvollziehen und schlussendlich zu dokumentieren. Gerade bei Abklärungen mit dem Business erweist es sich als hilfreich die technische Tiefe wegzulassen – die ist schlussendlich in den Scripts drin und interessiert auf diesem Level weniger.

 

Ein vereinfachtes Beispiel einer Hotelverwaltungssofware: Die grünen Zwischentabellen wurden als Vereinbarung mit dem Lieferant getroffen. Dieser möchte die Daten vereinfacht in den fünf Staging Tabellen erhalten. Das Ziel ist nun diese mit den Daten aus der Quell-Datenbank zu befüllen. Die Tabellen in der Quell-Datenbank sind oft in höherem Grade normalisiert und nutzen Codes und Referenztabellen um ihre Daten sinnvoll abzubilden. Es muss also eine Transformation vom Quellsystem ins Zielsystem stattfinden. Diese Transformation wird über mehrere Levels (00, 01, 02, etc.) mittels Views oder temporären Tabellen abgebildet, welche voneinander abhängig sind.

Migration Map

Die Migration Map bildet somit ein logischer Ablauf auf Business Objekt Ebene und zeigt, wie die Datenobjekte über die Levels transformiert werden, damit sie schlussendlich korrekt in den vereinbarten Staging Tabellen vorliegen. Gerade bei komplexeren Vorgaben mit mehreren Duzend Staging Tabellen bietet dies folgende Vorteile:

  • Übersicht wie die Objekte und schlussendlich die Exportdaten voneinander abhängig sind
  • Keine Redundanz im Scripting, wenn die Endtabellen auf gleiche Quellobjekte zugreifen (z.B. Räume werden nur einmal aus den Sourcen gezogen und am Schluss in zwei Exporten verwendet)
  • Wenn Anpassungen gemacht werden müssen, erkennt man die Auswirkung auf die verschiedenen Extrakte
  • Anpassungen müssen nur an einer oder wenigen Stellen gemacht werden
  • Hilft als Schnittstelle zwischen dem Business und dem Provider und kann potentielle Komplexität erklären – Visualisierung hilft technischen und fachlichen Personen für ein gemeinsames Verständnis
  • Schnellere Fehlerfindung, wenn im Extrakt Daten fehlen oder falsche Informationen auftauchen
  • Dokumentation und Nachvollziehbarkeit

Fazit: Eine Migration Map hilft dem Entwickler bei der Herleitung der zu exportierenden Daten und fördert das Verständnis zwischen den unterschiedlichen fachlichen und technischen Teilnehmer. Gerade bei komplexen und einer grossen Menge an Tabellen heisst es den Überblick zu bewahren, denn Änderungen, Korrekturen und Erklärungen tauchen im Laufe der Entwicklungs-, Tests- oder in der Produktionsphase mit Sicherheit auf.

Autor: Andrea Gasser