Migrationsleitfaden Version 3.0

in nur einem Datenbanksystem in normalisierter Form (ohne Redundanz) vor. Zudem ist
im Idealfall die Abfragesprache (SQL), mit der die Anwendungen auf der Datenbank
arbeiten, standardisiert und jede Anwendung sollte mit jedem RDBMS problemlos zusammenarbeiten.
In der Realität finden sich in vielen IT-Infrastrukturen mehrere RDBMS,
in denen teilweise die gleichen Daten mehrfach verwaltet werden und die von verschiedenen
Anwendungen mit unterschiedlichen SQL-Dialekten und hersteller-spezifischen
Spracherweiterungen sowie über herstellerspezifische Schnittstellen abgefragt werden.
Die Ausführungen in Kapitel II.A 1 zeigen, dass sich die einzelnen Datenbank-Produkte
in vielerlei Hinsicht voneinander unterscheiden. Als potenzielle Migrationshemmnisse
können sich unter anderem die Unterschiede in Bezug auf folgende Aspekte auswirken:
� Erweiterte Funktionalitäten, die vom Standard abweichen oder darüber hinaus
gehen
� Implementierte Datentypen
� Implementierte Sicherheitsfunktionen
� Angebotene Funktionen zur Notfallvorsorge und Hochverfügbarkeit, zum Beispiel
Clustering und Replikation
� Unterstützte Betriebssysteme, auf denen die Datenbank-Produkte lauffähig sind
� Angebotene Lizenzmodelle
� Unterstützte Speicherformate
� Verfügbare administrative Tools
� Verfügbare Zusatzprodukte
� Verfügbare Schnittstellen und Treiber
� Unterstützte SQL-Dialekte
� Vorgegebene Systemgrenzen, beispielsweise die maximale Größe von Feldern,
Tabellen und Datenbanken
� Maximale Speicher- und Verarbeitungsgeschwindigkeit
Eine Migration bietet vor diesem Hintergrund die Chance, eine Konsolidierung der
Software- und Datenstrukturen durchzuführen. Gleichzeitig müssen bei einer Migration
neben dem Datenbestand i.d.R. auch die Anwendungen umgestellt werden, was in
vielen Fällen nicht ohne Eingriff in die Client-Software möglich ist. Unter Client-Software
wird in diesem Zusammenhang eine beliebige Anwendung verstanden, die auf die
Datenbank zugreift. Häufig läuft die Client-Software auf einem Applikationsserver. Selbst
wenn die Datenbankanbindung mittels ODBC oder JDBC standardisiert ist und keine
Trigger oder Stored Procedures verwendet werden, muss bei einer Datenbankmigration
clientseitig mindestens der ODBC/JDBC-Treiber ausgetauscht werden. Die Zentralisierung
und Konsolidierung des Datenbestandes bedarf also offensichtlich einiger
Aufwände. Andererseits ist sie ein sehr attraktives Ziel, weil hierdurch im laufenden
Betrieb erhebliche Pflegeaufwände und damit Kosten reduziert werden können.
Für die Migration von Datenbankschemata gibt es herstellerunabhängige Tools, die eine
Migration zwischen beliebigen Datenbanken ermöglichen. Diese Tools können jedoch
Seite 169