Erwartete Lesezeit: 3 minuten
Jede Datenmigration ist anders. Daher kann es nicht die richtige optimale Lösung geben. Hier beschreibe ich allgemein wie eine mögliche , für unterschiedliche Szenarien passende, Lösung.
Ablauf einer Datenmigration
Analysephase
Zu Beginn jeder Migration steht die Analyse. Hierbei sollte man sich mindestens die folgenden Fragen stellen:
- Von wo kommen die Daten ?
- Wie sehen die Daten aus ?
- Wohin sollen die Daten ?
- Wie sieht die Zielstruktur aus ?
- Sind Konvertierungen , Filterungen oder Erweiterungen notwendig ?
- Um welche Datenmenge handelt es sich ?
All diese Informationen sollte man sich an einer zentralen Stelle notieren und sich so ein Migrationsregelwerk erstellen. Bei der Beschreibung der Datentrukturen kann man sich an den jeweiligen Datenmodelle orientieren. Für die Beschreibung der Konvertierungen kann man eine einfache Tabelle erstellen, in der die Spalten Quell-Tabelle, Quellfeld, Zieltabelle, Zielfeld , anzuwendende Regeln.
Die Regeln sollten in einem weiteren Dokument beschrieben werden. Hierbei sollte jede Regel eine eindeutige ID haben , eine Beschreibung der Konvertierungen oder die Filterkriterien oder eine Beschreibung wie die Daten erweitert werden sollen. Im Optimalsten Fall sind die Regeln so beschrieben , dass sie Wiederverwendbar ist.
Ein Beispiel hierfür wäre die Erstellung einer neuen Kundennummer. Wird die Kundennummer in mehreren Tabellen genutzt, muss die jeweilige Quell-Kundennummer immer zur selben Ziel-Kundennummer konvertiert werden. Also sollte immer das selbe Regelwerk verwendet werden.
Entladen der Daten
In letzter Zeit habe ich vermehrt Migrationsszenarien gesehen, die auf einer direkte Migration in den DMS , basierten. Also per Insert-Select oder Select-Transform-Insert. Diese Variante kann bei kleineren Datenmengen funktionieren. Aber stellt Euch mal vor Ihr müsst pro Entität mehrere Millionen Datensätze migrieren. Das dürfte in dieser Variante sehr lange Dauern (hab ich leider erleben müssen).
Daher empfiehlt es sich bei größeren Datenmengen die Daten in Dateien zu entladen und diese dann über eine Dateiverarbeitung zu transformieren.
Die Transformation
Hierbei handelt es sich um die komplexeste Phase einer Migration. Kann man alle Daten 1:1 übertragen entfällt diese Phase natürlich, aber in den meisten Fällen ist irgendwo eine Formatanpassung , eine Filterung oder eine Umschlüsselung notwendig.
Hier ein Beispiel für einen möglichen Transformationsablauf :
Pro Datensatz wird jedes Feld durchlaufen umgewandelt und dann ausgegeben.
Im Falle von Filterungen (Datensätze werden ggf. nicht übernommen) , sollte man diese zuerst durchführen, um unnötige Transformationen zu vermeiden.
Filterungen könne ohne Probleme per SQL Select Abfrage oder Dateiabgleich durchgeführt werden.
Fehlerhafte Sätze sollten ausgesteuert werden und in einer separaten Datei gespeichert werden. Dadurch kann man diese nach der Korrektur nochmals durch die Transformation laufen lassen ohne den gesamten Bestand verarbeiten zu müssen.
Am Ende der Transformation sollte man benötigte Prüfsummen speichern.
Laden der Daten
Nach der Transformation werden die Daten in das Zieldatenmodell geladen. Hier zeigt sich, ob man bei der Transformation bzgl. der Feldformate alles korrekt gemacht hat.
Protokollierung
Je nachdem in welcher Branche man unterwegs ist müssen aus Revisionsgründen bestimmte Protokolle und Kennzahlen gespeichert werden. Hierbei empfiehlt es sich die Protokolle der Transformationen so zu speichern , dass man die während der Transformationsphase erstellten Protokolle wiederverwenden kann.
Man geht aber meistens schon auf Nummer sicher wenn man die Anzahl Datensätze Entladen , Anzahl Datensätze ok und fehlerhaft der Transformation und die Datensätze die geladen wurden speichert. Ebenso sollte man sich über eventuelle Aufbewahrungsfristen Gedanken machen. In den Migrationen , in denen ich mitgearbeitet hab, waren es immer 10 Jahre.