Ich fasse hier mal die Gedanken zusammen, die als Grundlage einer Checkliste bei der Migration einer bestehenden Datenbank dienen können. Das ist mehr eine Merkliste für mich, die ich hin und wieder ergänzen werde...

Spezialfall: Verteilte Daten

Hierbei kann es vorkommen, dass dasselbe Datenmodell in mehreren Datenbankinstanzen unterschiedliche Daten enthält, die Primärschlüssel aber über die verschiedenen Instanzen nicht eindeutig sind. Möchte man solche Datenbanken im Zuge der Migration in eine einzige Instanz zusammenführen, muss man neue technische Schlüsselspalten erzeugen.

Die Identität eines Datensatzes wurde vorher dann durch den Primärschlüssel und eine fachliche Entity-ID beschrieben. Diese beiden (oder mehr) Spalten werden dann in einer technischen Schlüsselspalte zusammengeführt, die als Grundlage von Fremdschlüsselbeziehungen dient.

Stichtagsregelung

Ein weiterer Spezialfall ist gegeben, wenn es sich bei dem Datenmodell um eine Buchhaltung im weiteren Sinne handelt: werden hier Kontoauszüge erstellt und kommt es im Rahmen der Neudefinition oder Änderung von Anforderungen dazu, dass die Berechnung der Kontoauszüge nach den neuen und den alten Vorschriften unterschiedliche Werte ergeben (Stichwort: Rundungsregeln), muss zu einem festzulegenden Stichtag für jedes Konto eine Ausgleichsbuchung angelegt werden, die sicherstellt, dass der Auszug zu diesem Stichtag nach alter und neuer Regelung identische Werte liefert.

Fachliche Anforderungen

Sind innerhalb des Datenmodell semantische Bedeutungen verborgen, müssen für die Migration eventuell Anpassungen vorgenommen werden - eventuell ist es sogar notwendig, die verborgenen semantischen Bedeutungen explizit sichtbar zu machen.

Diese Herausforderung trat in einem System auf, in dem numerische Werte als Messwerte gespeichert wurden, die als Grundlage der Berechnung mit SI-Einheiten dienten. Das System wurde durch den Eintritt in den nordamerikanischen Markt um die Unterstützung der dort üblichen Einheitensysteme (zöllig vs. metrisch) erweitert. Das brachte die Notwendigkeit mit sich, in der Datenbank zu vermerken, in welchem Einheitensystem die zugrundeliegenden Messwerte erfasst wurden.

Allgemein

Nun noch einige allgemeine Gedanken zur Migration:

Binärdaten können eventuell in einem Datenbanksystem für Performanz-Probleme sorgen: sind sie in dem alten Datenbanksystem ins Dateisystem ausgelagert, kann man im neuen eventuell eine Direktspeicherung im Datenbanksystem erwägen. Auch der umgekehrte Fall ist denkbar.

Es sollte festgestellt werden, inwieweit die Stored Procedures aus dem Altsystem in das neue konvertiert werden müssen/können.

Alle Contraints des Altsystems müssen im neuen System wieder rekonstruiert werden. Dazu muss das neue System natürlich zunächst alle im Altsystem verwendeten Constraint-Typen unterstützen.

Lasttests, die im Idealfall für das Altsystem vorliegen, sind auf dem neuen System zu fahren - falls das neue System dabei schlechter abschneidet, sind die Ursachen zu finden und zu beseitigen!

Bei der Migration der Daten ist bei allen Feldern, die Texte enthalten, darauf zu achten, dass bei unterschiedlichen Encodings zwischen dem neuen und dem Altsystem entsprechend korrekte Konvertierungen vorgenommen werden. In seltenen Fällen sind gegebenenfalls Anpassungen der Spaltenbreite nötig!

Das Übertragen von Zeitinformationen macht gegebenenfalls dedizierte Konvertierungen nötig (Timestamps vs. Datum oder unterschiedliche Referenzen für den Beginn der jeweiligen Zeitrechnung).

Bei Spalten mit Gleitkommawerten ist das jeweilige Machine Epsilon zu beachten: das neue System sollte einen kleineren oder zumindest den gleichen Wert für das Machine Epsilon der Spaltentypen aufweisen!

Kommentar hinzufügen (via ) Kommentare ansehen (via )

Kommentar hinzufügen (via ) Kommentare ansehen (via )