Datenmigration - alles Standard?

In der heutigen GIS-Welt sind Schlagworte wie  Objektorientierung, Komponententechnologie und Internet bereits selbstverständlich geworden. Hinzu kommen speziellere Begriffe wie Interoperabilität oder verteilte Geodaten. Solche Begriffe entstammen aus der rasanten Entwicklung von neuen Technologien und der damit verbundenen Kurzlebigkeit von Systemen. Aus dieser Kurzlebigkeit heraus müssen heute unterschiedlichste strategische Einflüsse erkannt und bewertet werden. Bei den Einflüssen spielt die allgemeine Softwaretechnik und die GIS-technischen Anforderungen ebenso eine wichtige Rolle wie Planungs- und Investitionssicherheit zu gewährleisten. Solche Begriffe entstammen aber auch dem Ruf der GIS-Welt nach Standardisierungen, wie sie beispielsweise durch das OpenGis Konsortium vertreten und erarbeitet werden.

In diesem Zusammenhang ist es von erheblicher Bedeutung, über die zukünftigen Möglichkeiten nicht die Vergangenheit zu vernachlässigen. Früher getätigte Investitionen müssen dabei ebenso berücksichtigt werden, wie die Planungen und Festlegungen für die Zukunft, in der ein Investitionsschutz immer deutlicher zum zentralen Thema wird. Die vergangenen Investitionen beziehen sich dabei weniger auf ein konkretes Softwaresystem, sondern hauptsächlich auf die Erfassung und Speicherung von (Geo)-Daten, da diese in den meisten Fällen den weitaus höheren Kostenanteil darstellen. Daraus folgt, dass ein Datenbestand ebenso in der Lage sein muss sich weiterzuentwickeln, wie die Softwaretechnologie, die diese Daten umgibt. Bei einem Umstieg auf eine neue Technologie stellt sich also nicht nur die Frage nach einer geeigneten Systemwahl für die Zukunft, sondern auch die Frage nach der Migration des vorhandenen Datenbestandes in die neue Systemumgebung. Dieser Schritt, auch Datenmigration genannt, stellt oftmals die schwierigste Aufgabe bei einem Systemwechsel dar. Die Komplexität der Datenstrukturen, die Architektur der GIS-Software oder auch die Qualität der GIS-Daten nehmen Einfluss auf den Schwierigkeitsgrad einer Datenmigration.

Obwohl heute nahezu alle GIS-Softwarehersteller damit werben, dass sie sich an derzeit gültige Standards und Normen halten und somit für eine Investitionssicherheit stehen, stellt sich nach einer Datenmigration die Frage, ob der umgesetzte Datenbestand sich in der Praxis wirklich so standardisiert verhält, wie es ursprünglich geplant und angekündigt wurde. Wenn man sich also bei einer Datenmigration an die von den GIS-Softwareherstellern unterstützten Datenbanksysteme und deren Datenmodellierung hält, ist es dann möglich, systemunabhängig auf Datenbestände zuzugreifen? Kann man vielleicht sogar schon von „Interoperabilität“ sprechen?

Oder kurz gesagt: „Datenmigration – alles Standard?“

Am Beispiel eines konkreten Anwendungsfalls bei der Firma Dynamit Nobel GmbH zeigt die vorliegende Arbeit die Problematik und die Lösungsansätze einer Datenmigration. Es wird gezeigt, mit welchen Methoden eine Datenmigration innerhalb verschiedener GIS-Systeme nach heutigen Gesichtspunkten  durchführbar ist. Abschließend wird erläutert, inwiefern eine systemübergreifende Nutzung des migrierten Datenbestandes realisierbar ist.

Die beschriebene Migration des Datenbestandes hat etwa einen Zeitraum von einem dreiviertel Jahr in Anspruch genommen. Einen sehr großen Anteil an dieser Zeit hat die Sichtung und das Verstehen der alten Datenstruktur. Es hat sich als sehr aufwendig erwiesen, den historisch gewachsenen Datenbestand zu analysieren. Immer wieder stieß man dabei an Fragestellungen, deren Beantwortung nur durch eine gute Kenntnis der damals aktuellen und üblichen Datenmodellierungsansätze möglich gewesen ist. Zahlreiche Zwangsbedingungen, die es in heutigen Datenbanksystemen nicht mehr gibt, ließen nur eine recht umständliche Datenhaltung zu. Beim Analysieren des alten Datenbestandes musste sich immer wieder gefragt werden, wie eine entdeckte Teilstruktur nach heutigen Gesichtspunkten und Möglichkeiten abgelegt werden könnte. Auch galt es stets zu entscheiden, welche Informationen bei einer Migration unter Umständen nicht mehr benötigt würden, und welche auf keinen Fall verloren gehen dürfen. Daher hat es sich als sehr sinnvoll ergeben, die Daten Stück für Stück umzusetzen und nicht etwa in einem Arbeitsschritt. Das Befüllen der Konvertierungstabellen hat bei der technischen Umsetzung die meiste Zeit in Anspruch genommen, da hierbei in verschiedenen SQL-Statements die Strukturen der alten und der neuen Datenbank eingearbeitet und berücksichtigt werden mussten.

Im Endeffekt kann man aber sagen, dass sich der Aufwand mit Sicherheit gelohnt hat. Neben einer nie zuvor dagewesenen Kenntnis des Datenbestandes hat dieser durch die Migration sicherlich erheblich an Wert gewonnen. Durch die Integration in eine neue Softwareumgebung sind nun die Funktionalitäten eines GIS bezogen auf Analyse- und Verschneidungsfunktionen möglich. Es können Entscheidungen, die von baulichen Maßnahmen, über Besitz- und somit bis hin zu Abrechnungstechnischen  Fragestellungen reichen, schneller beantwortet, oder bearbeitet werden. Über dieses Mehr an Leistungsfähigkeit haben sich die nicht unerheblichen Kosten der Datenmigration schon bald gerechnet.

Das gesteckte Ziel, den Datenbestand durch die IMS-Technologie an verschiedene Arbeitsplätze zu verteilen, ist mit Sicherheit erreicht worden. Es ist dadurch möglich, die Daten an der Stelle zu pflegen, an der sie für planerische Zwecke auch benötigt werden. Das Ingenieurbüro bietet das technische Wissen, um die vom jeweiligen Konzernmitarbeiter benötigten Informationen online zur Verfügung zu stellen. Daher ist es nicht mehr notwendig, das Ingenieurbüro wegen jeder Auskunft per Telefon oder Email zu bemühen, wodurch nicht nur Zeit, sondern auch Kosten gespart werden. Ein weiterer Vorteil besteht darin, dass in Schadens-, oder Unglücksfällen, was bei einem Konzern dieser Größenordnung nicht selten vorkommt, wichtige Informationen, wie etwa Stauraumvolumen von Kanälen für abfließendes Löschwasser, oder Leitungsverläufe im Gas- oder Stromnetz, zu jeder Tages- und Nachtzeit abgerufen werden können, wodurch möglicherweise größere Schäden verhindert werden können.

Die Verwendung der beschriebenen Module lässt eine sehr detaillierte Anpassung an die Bedürfnisse des Konzerns zu. Mit Standardprogrammierumgebungen, wie ASP, Visual Basic oder HTML lassen sich jederzeit Ergänzungen oder Veränderungen durchführen.

Das weitere Ziel, eine offene und standardisierte Datenhaltung zu gewinnen, ist  nach derzeit aktuellen Gesichtspunkten als durchaus erfüllt zu beurteilen. Zwar hat sich gezeigt, dass die Systeme keineswegs als vollkommen interoperabel zu bezeichnen ist, aber fest steht, das ein verlustfreier Datenaustausch mit anderen Systemen möglich ist. Auch der Zugriff auf den Datenbestand mit einem Fremdsystem ist ebenfalls als gelungen und möglich zu erachten. Das Entscheidende war, dass kein Datenverlust beim Zugriff auftritt. Da immer mehr Systemhersteller die standardisierte Datenhaltung von Oracle unterstützen, ist auch ein Datenaustausch zwischen den Systemen möglich. Durch verschiedenste Schnittstellen ist es möglich zwischen den Systemen über Fremdformate zu korrespondieren.

Wenn man nun die im Titel etwas provokante Frage nach dem Standard aufgreift, kommt man zu der Feststellung, dass die Systeme von einer angestrebten Interoperabilität noch weit entfernt sind. Auch wenn die Ablage der Daten standardisiert in einem objektorientierten Oracle-Umfeld erfolgt, sind doch noch eine ganze Reihe von Metadaten für die Systeme erforderlich, um den Datenbestand anzusprechen. Der eine Weg wäre also, eben diese Metadatenstrukturen für alle Systeme einheitlich zu gestalten, so dass kein Abgleich mehr erforderlich würde. Dadurch würden sich zwar die verschiedenen Systeme immer mehr ähneln, aber es wäre ein großer Schritt in Richtung Interoperabilität gemacht. Eine weitere Möglichkeit besteht darin, eigene Applikationen zu entwickeln, welche die Metadatenstrukturen stets aktualisieren. Solche Applikationen zu erstellen gestaltet sich technisch nicht zu schwer, da die Metadatenstrukturen durchaus offen gelegt sind, oder in den konkreten Beispielen nicht sonderlich schwer zu durchschauen sind. Es gibt also hinreichende Metainformationen über die Metadatenstrukturen. Wenn nun die beiden beschriebenen Systeme parallel über dem selben Datenbestand verfügen sollen, müsste dieser Datenbestand zum einen die Metadaten beider Systeme beinhalten, und zum anderen eine Applikation zwischengeschaltet werden, welche die Metadaten stets um neue Informationen ergänzt.