Diplomarbeit. Funktionale Migration von Informationssystemen. Stefan Koch Matrikel-Nr März 2006

Transkript

1 Diplomarbeit Funktionale Migration von Informationssystemen Stefan Koch Matrikel-Nr März 2006 Christian-Albrechts-Universität zu Kiel Institut für Informatik und Praktische Mathematik Lehrstuhl Technologie der Informationssysteme Prof. Dr. rer. nat. habil. Bernhard Thalheim

2

3 Aufgabe Funktionale Migration von Informationssystemen Systemmigration ist auch für Informationssysteme zu einer drängenden Aufgabe geworden. Nachdem Informationssysteme eine breite Anwendung gefunden haben, z.t. mit relativ komplexen Anwendungsprogrammen (der sogenannten Anwendungslogik) ergänzt wurden, zugleich aber sowohl Hardware- als auch Softwaresysteme einem Alterungsprozess unterliegen, ist eine Evolution dieser Altsysteme in vielen Anwendungen durch Unterlegung moderner Systeme eine wichtige, aber in der Forschung relativ stiefmütterlich behandelte Aufgabe. Erbschaftsinformationssysteme (engl. Legacy systems, deutsch oft irreführend als Altlastensysteme bezeichnet; da die Informationen selbst eine wertvolle Ressource sind, ist eher von Erhaltung des Erbes zu sprechen) können, sollten und müssen durch Reengineering aufbereitet werden und es muss Vorsorge dafür getragen werden, dass die Systeme nicht wieder zu Erbschaftsinformationssystemen werden. Trotz der Wichtigkeit gibt es bisher nur wenig umfassende Migrationsmethoden für Erbschaftsinformationssysteme und keinen allgemeinen Ansatz. Aufgrund der Entwicklungen zur strukturellen Integration von Systemen, zur Abbildung von Schemata auf andere Schemata und dem darauf fuÿenden informationserhaltenden Abbilden von Datenbankinhalten kann das Problem der strukturellen Migration als gelöst angesehen werden. Es können alle strukturellen Informationen des logischen Schemas aufgenommen werden, mit einer entsprechenden Aufbereitung um nicht enthaltene Information ergänzt und damit für eine Migration verwendet werden. Damit kann auch die Datenbank auf das neue System umziehen. Diese Aufbereitung ist bei genauer Betrachtung mit einer Rückgewinnung des konzeptionellen Schemas verbunden. Dieser Zugang entspricht zugleich dem Compilerzugang, der sich für Programmiersprachen eingebürgert hat. Nicht gelöst ist dagegen das Problem der funktionalen Migration. Es existiert eine Vielzahl von Funktionen, Prozeduren, aktiven Datenbanksystemkomponenten wie Trigger, Anfragen und abgeleiteten Prozeduren, die nicht in der gleichen Weise auf die Funktionalität des Zielsystemes abgebildet oder compiliert werden kann. Aufgrund der Vielfalt der Funktionalität ist die Existenz eines allgemeinen Compilerzuganges eher unwahrscheinlich. Die semantikergänzende Aufbereitung der strukturellen Information läÿt dagegen eine konzeptionelle funktionale Migration zu. Es i

4 können die Funktionen, Prozeduren, Trigger, Anfragen und abgeleiteten Funktionen konzeptionell aufbereitet werden und dann mit der üblichen Abbildung unter Berücksichtigung des Systemproles des Zielsystemes auf neue Funktionalität abgebildet werden. Mit der Diplomarbeit soll die funktionale Migration für Anfragen erprobt werden. Es sollen dazu Anfragen auf Visual SQL Niveau angehoben werden, diese Anfragen einer Wiederbetrachtung durch die Entwickler zugeführt werden und in die Anfragen des Zielsystemes aus Visual SQL überführt werden. Es soll mit der Diplomarbeit eine Machbarkeitsstudie für die funktionale Migration entstehen, die aufzeigt, welche der bekannten Mechanismen der strukturellen Migration übernommen werden können, welche Ergänzungen notwendig sind und welche Mechanismen für die gesamte konzeptionelle funktionale Migration erforderlich sind. ii

5 Selbstständigkeitserklärung Ich erkläre hiermit, dass ich die vorliegende Arbeit selbstständig und nur unter Verwendung der angegebenen Literatur und Hilfsmittel angefertigt habe.... Kiel, den 17. März 2006 iii

6 iv

7 Inhaltsverzeichnis 1 Einführung zur Migration von Erbschaftsinformationssystemen Das Problem der Erbschaftsinformationssysteme Die Lösung: Migration Über den Begri Migration Probleme bei der Migration von geerbten Informationssystemen Über den Begri Reengineering Migrationsstrategien Cold Turkey Chicken Little Die Buttery-Methode Bewertung der Migrationsstrategien Migrationskomplexität und IS-Architekturen Softwarearchitektur nach Brodie und Stonebraker Softwarearchitektur nach Siedersleben Vorbereitung und globales Design Überblick zur Migration von Datenbanken Aufgaben der Datenbankmigration Strukturelle Migration Funktionale Migration DBMS-Unterschiede Ein Beispiel Herkunft / Hintergrund Das Datenbankschema Reengineering des Schemas Konsequenzen für die betroenen Anfragen v

8 Inhaltsverzeichnis 3 Anfragen bei der funktionalen Migration Das bisherige Vorgehen bei der Migration von Anfragen Bewertung des bisherigen Vorgehens Qualitätskriterien für migrierte Anfragen Anforderungen an eine neue Strategie Mögliche Lösungsstrategien Konzeptionelle Migration von Anfragen Beschreibung der neuen Strategie Vorteile der Visualisierung Visual SQL - Ein kurzer Überblick Funktionsumfang Formulierung von Anfragen Durchführung an Beispielen Beispiel 1: Dekomposition eines Entity-Typs Beispiel 2: Komposition zweier Entity-Typen Beispiel 3: Verkürzung eines Anfrage-Pfades Einschränkungen und Anwendbarkeit Implementierung der konzeptionellen Migration von Anfragen Zielsetzung Gewählte Technologien Schnittstelle zu VisualSQL Ein- und Ausgabe Die Übersetzung von SQL-Anfragen Der Parser Der Übersetzer Realisierte Funktionalität Einschränkungen der Übersetzung Zusammenfassung 77 7 Ausblick 79 A Erklärung der verwendeten Notation für das ER-Modell 81 vi

9 Inhaltsverzeichnis B Dokumentation des Beispiels 85 B.1 ER-Modell: Entitäten B.2 ER-Modell: Beziehungen B.3 Relationales Datenmodell C DTD für VisualSQL-Dateien 93 D Grammatik des T-SQL-Parsers 103 Literaturverzeichnis 107 vii

10 Inhaltsverzeichnis viii

11 Abbildungsverzeichnis 1.1 Klassikation der Probleme bei der Migration von Erbschaftsinformationssystemen (aus [8]) Migrationsarchitektur für Informationssysteme nach [10] Die Chicken Little Schritte nach [10] Aufbau des Zielsystems bei der Buttery-Methode (aus [39]) Phase 4 (Migration der Daten) der Buttery-Methode nach [39] Migrieren der Daten in TempStore T S n (aus [39]) Die Phasen der Buttery-Methode nach [39] Zerlegbare Erbschafts-IS-Architektur nach [10] Halbzerlegbare Erbschafts-IS-Architektur nach [10] Nicht zerlegbare Erbschafts-IS-Architektur nach [10] Gemischte Erbschafts-IS-Architektur nach [10] Schema der strukturellen Migration Schema der funktionalen Migration Konzeptionelles Schema des Weinherstellungsbeispiels Modellierungs-Problem Karton Artikel im Altsystem (ERM) Modellierungs-Problem Karton Artikel (RDM) Lösung des Modellierungs-Problems Karton Artikel (RDM) Eine Anfrage an das ursprüngliche Schema Die Anfrage zum neuen Schema Denition der Tabelle Karton als Sicht auf dem neuen Schema Denition der Tabelle KartonInhalt als Sicht auf dem neuen Schema Anfrage mit eingesetzten Sichten-Denitionen Schema der neuen Strategie ix

12 Abbildungsverzeichnis 4.2 Visual SQL: Projektion und Selektion (mit AND) Visual SQL: Group By, Order By und abgeleitetes Attribut Visual SQL: natürlicher Verbund Visual SQL: Unteranfrage Beispiel 1: Anfrage an Artikel vor der Dekomposition Beispiel 1: Sichtendenition für die ursprüngliche Tabelle Artikel Beispiel 1: Anfrage an Artikel mit eingebetteter Sichtendenition Beispiel 1: Formulierung der Anfrage in Visual SQL Beispiel 1: Erste visuelle Umformulierung Beispiel 1: Zweite visuelle Umformulierung Beispiel 1: Erste SQL-Repräsentation der visuell bearbeiteten Anfrage Beispiel 1: Dritte visuelle Umformulierung Beispiel 1: Zweite SQL-Repräsentation der visuell bearbeiteten Anfrage Beispiel 2: Sichtendenitionen für die ursprünglichen Tabellen Artikel und Wein Beispiel 2: Anfrage mit eingesetzten Sichtendenitionen Beispiel 2: Formulierung der Anfrage in Visual SQL Beispiel 2: Visuelle Vereinfachung der Anfrage Beispiel 2: SQL-Repräsentation der visuell bearbeiteten Anfrage Beispiel 3: Die zu untersuchende Anfrage Beispiel 3: Formulierung der Anfrage in Visual SQL Beispiel 3: Visuelle Vereinfachung der Anfrage Beispiel 3: SQL-Repräsentation der visuell bearbeiteten Anfrage Zwei Beispielproduktionen der Grammatik in JJTree-Syntax Übersetzer-Ergebnis der zu Abb. 4.5 gehörenden SQL-Anfrage Reengineering von Anfragen mittels Visual SQL A.1 Notation ER-Modell: Entität A.2 Notation ER-Modell: Beziehung A.3 Notation ER-Modell: Rollen und Kardinalitäten A.4 Notation ER-Modell: Spezialisierung / Generalisierung B.1 Relationales Schema des Weinherstellungsbeispiels x

13 1 Einführung zur Migration von Erbschaftsinformationssystemen 1.1 Das Problem der Erbschaftsinformationssysteme Erbschaftsinformationssysteme oder auch geerbte Informationssysteme (engl. legacy information systems) werden zunehmend als Hauptproblem für viele groÿe Firmen erkannt. Ein Erbschaftsinformationssystem ist jedes Informationssystem (IS), das Anpassungen und Veränderungen signikant widersteht (siehe [10]). In der Regel ist es sehr groÿ und älter als 10 Jahre. Allerdings ist auch ein erst kürzlich entwickeltes IS ein Erbschaftsinformationssystem, wenn es nicht leicht an die sich permanent verändernden Geschäftsanforderungen angepasst werden kann. Ein ehemals auf zeitgemäÿer Hardware, unter Verwendung von mittlerweile überholten Technologien und Techniken, entwickeltes Informationssystem bildet gemeinsam mit den darin enthaltenen Daten ein Erbe, das es zu verwalten gilt. Die Daten und die grundlegende Funktionalität des Systems sollen erhalten bleiben, aber es müssen Fehler behoben und Erweiterungen entwickelt werden, um veränderten Geschäftsanforderungen zu genügen (z.b. einer erforderlichen Anbindung des Systems an andere, modernere Systeme). Solche Anpassungen werden durch fehlende Dokumentation und fehlendes Know-How erschwert, da die ursprünglichen Entwickler des IS in den meisten Fällen das Unternehmen bereits verlassen haben oder mittlerweile in anderen Aufgabenbereichen tätig sind und die Details ihrer früheren Entwicklungen vergessen haben. Die Wartung eines Erbschaftsinformationssystems verursacht hohe Kosten, bindet anderweitig einsetzbare Arbeitskraft und verhindert so die Erfüllung der aktuellen Geschäftsanforderungen eines Unternehmens. Aus diesen Gründen mindert sich auch dessen Wettbewerbsfähigkeit, so dass dringender Handlungsbedarf besteht. In den meisten Fällen werden entsprechende Maÿnahmen aber bisher durch hohe Kosten und technische Herausforderungen verhindert. Es stellt sich daher beispielsweise die Frage, auf welche Weise man das alte IS verändern kann, ohne Einbuÿen bei seiner auftragsentscheidenden Funktion hinnehmen zu müssen, denn kein Unternehmen wird einen Fehler riskieren, durch den es Zeit, Aufträge und das Vertrauen der Kunden verliert. Erbschaftsinformationssysteme können, sollen und müssen durch Reengineering 1

14 1 Einführung zur Migration von Erbschaftsinformationssystemen sowie Migrationsmaÿnahmen zukünftig verbessert werden. Die o.g. Probleme würden so beseitigt werden, wobei aber Vorsorge dafür getragen werden muss, dass das IS nicht wieder zu einem Erbschaftsinformationssystem wird (vgl. [8, 10]). Im Hinblick darauf sind also langfristige Lösungsmodelle anzustreben, die im Folgenden dargestellt werden sollen. 1.2 Die Lösung: Migration Für die genannten Probleme von Erbschaftsinformationssystemen sind bisher mehrere Lösungen vorgeschlagen worden, die sich nach [8] in drei Kategorien einteilen lassen: 1. Redevelopment beinhaltet die Neuentwicklung der Anwendung(en), 2. Wrapping verpackt eine existierende Komponente der Anwendung zu einer neuen, anders zugreifbaren Software-Komponente und 3. Migration siedelt das Erbschaftsinformationssystem, oder einzelne Teile davon 1, in eine exiblere Umgebung um, wobei die ursprünglichen Daten und Funktionen erhalten bleiben. Wrapping verspricht zwar kurzfristig recht unkomplizierte Teil-Lösungen, kann aber auf lange Sicht die Wartung und Verwaltung des Systems verkomplizieren. Andererseits ist das Redevelopment, also die vollständige Neuentwicklung der vorhandenen Anwendung(en), für die meisten Unternehmen zu riskant (vgl. auch Abschnitt 1.3.1). Deshalb wird allgemein die Migration als angemessene Lösung befürwortet (z.b. in [8, 10]), bei der die langfristigen Vorteile (wie z.b. mehr Flexibilität, bessere Verständlichkeit des Systems, einfachere Wartung und geringere Kosten) am gröÿten sind. Für ein gegebenes Erbschaftsinformationssystem ist es jedoch nicht immer möglich, die passende Lösung in eine der o.g. Kategorien einzuordnen. Migration kann deshalb auch das Wrapping von einem Teil des Systems, die Wartung eines anderen, oder die Neuentwicklung eines weiteren Teils beinhalten. Man spricht zwar meistens davon, dass die Ansätze auf der Ebene des Systems angewendet werden, aber man wendet sie überwiegend auf einzelne Komponenten des Systems an Die architekturbedingte Zerlegbarkeit eines Informationssystems wird in Abschnitt 1.4 behandelt. 2 In [6, 7, 8, 9, 10, 39, 40] sind ausführlichere Informationen zur Migration von Erbschaftsinformationssystemen aufgeführt.

15 1.2 Die Lösung: Migration Über den Begri Migration Die Migration eines Erbschaftsinformationssystems siedelt im Wesentlichen ein vorhandenes operationales System in eine neue Umgebung um. Sie beginnt mit einem geerbten IS und endet mit einem vergleichbaren Ziel-IS, das sich zwar deutlich vom Original unterscheidet, aber sehr viele Funktionen und Daten aus dem ursprünglichen System enthält. Echte Migrationen sind welche von Funktionen und (geerbten) Daten, denn vieles vom Code der Erbschaftsanwendung ist entbehrlich oder ersetzbar, aber erheblich groÿe Mengen der Erbschaftsdaten und -Funktionen sind es nicht (siehe [10]). Entscheidend bei der Migration ist, dass die Funktionalität des Systems ununterbrochen zur Verfügung steht, und dass sie in Hinblick auf das operationale und geschäftliche Umfeld so wenig Schaden wie möglich anrichtet. Die möglicherweise auftretenden Probleme müssen folglich einer genauen Betrachtung unterzogen werden Probleme bei der Migration von geerbten Informationssystemen Die Durchführung eines Migrationsvorhabens ist eine groÿe Herausforderung und kann zahlreiche Bereiche des Software Engineerings umfassen, wie z.b. das Verstehen vorhandener Programme und Datenbanken sowie die Entwicklung und das Testen des neuen Systems (vgl. [8]). Abbildung 1.1 zeigt wichtige Aufgaben bzw. Probleme der Migration, von denen einige (z.b. die Entwicklung des Zielsystems, das Testen und die Auswahl des Datenmodells) zu allen Software Engineering-Projekten gehören und bereits ausführlich untersucht und unterstützt worden sind. Andere davon gehören speziell zur Migration und müssen noch ausführlich untersucht werden (siehe [8]). Eng verbunden mit dem Thema Migration ist der Begri des Reengineerings, welcher daher im folgenden Abschnitt näher erläutert wird Über den Begri Reengineering Das Reengineering eines Systems bezeichnet eine Anpassung des Systems, bei der nicht die Erweiterung, sondern die Verbesserung der bestehenden Funktionen im Vordergrund steht. Hierfür ist ein genaues Untersuchen und Verstehen des Systems erforderlich. Reengineering-Maÿnahmen können sogar bis zu einer (fast) vollständig neuen Implementierung des Erbschaftsinformationssystems führen. Im Gegensatz zur Migration, bei der sich die Umgebung des Zielsystems (oder einzelner Teile davon) immer verändert, kann ein durch Reengineering entstandenes System aber auch in der gleichen Umgebung laufen wie das ursprüngliche System ( vgl. [8, 11, 24, 28]). 3

16 1 Einführung zur Migration von Erbschaftsinformationssystemen Abbildung 1.1: Klassikation der Probleme bei der Migration von Erbschaftsinformationssystemen (aus [8]) Somit zählt das Reengineering eher zur Kategorie Redevelopment (s.o.) als zur Migration, denn das Ziel der Migration ist die Vermeidung des langen und teuren Implementierungsprozesses (siehe [8, 33]) indem versucht wird, so viel wie möglich vom Erbschaftsinformationssystem wieder zu verwenden (wie z.b. die Implementierung und das Design). Wenn der Groÿteil des Erbschaftsinformationssystems nicht wieder verwendet werden kann, dann handelt es sich um ein Redevelopment- und nicht um ein Migrationsprojekt. Reengineering selbst ist also keine Lösung für das Problem geerbter Informationssysteme, sondern eine Technologie, die in Redevelopment- und Migrationsprojekten zum Einsatz kommen sollte (vgl. [8]). Auf spezielle Migrationsstrategien soll im nächsten Abschnitt eingegangen werden. 1.3 Migrationsstrategien Wenn man den Umfang, die Komplexität und das Risiko zum Fehlschlag bei Migrationsprojekten bedenkt, dann ist eine wohldenierte, leicht zu implementierende und detaillierte Methodik entscheidend für den Erfolg eines solchen Projekts. Trotzdem gibt es bisher nur wenig umfassende Migrationsmethoden für Erbschaftsinformationssysteme und keinen allgemeinen Ansatz. In diesem Abschnitt werden die Strategien Cold Turkey und Chicken Little sowie die Buttery-Methode zur Migration von Erbschaftsinformationssystemen vorgestellt und anschlieÿend kurz bewertet. 4

17 1.3 Migrationsstrategien Cold Turkey Die traditionelle Methode zur Migration von geerbten Informationssystemen ist der sog. Cold Turkey [10]. Er beinhaltet ein komplettes Neuschreiben des alten Systems mithilfe von modernen Softwaretechniken und der Hardware des Zielsystems. Das geerbte Informationssystem bleibt dabei bis zur Fertigstellung des neuen Systems vollständig im Einsatz. Erst wenn die Entwicklung des neuen Systems beendet ist, wird der sog. Cutover durchgeführt, der aus dem Abschalten des alten Systems, dem Übertragen der vorhandenen Daten und dem Aktivieren des neuen Systems besteht. Diese Strategie beinhaltet aus folgenden Gründen ein erhebliches Risiko für einen Fehlschlag (siehe [10]) : 1. Der Geschäftsführung muss ein besseres System versprochen werden. Stellt man der Geschäftsführung eines Unternehmens eine Migrationsstrategie vor, die aus einem 1:1-Neuschreiben des Systems besteht, dann wird dies in den meisten Fällen abgelehnt. Erst wenn für das neue System zusätzliche Funktionen versprochen werden, wird der Antrag genehmigt. Dadurch erhöht sich aber die Komplexität des Neuschreibens und damit das Risiko eines Fehlschlags. 2. Geschäftsanforderungen verändern sich ständig. Während des Neuschreiben-Prozesses entwickelt sich das Erbschaftsinformationssystem aufgrund von Wartung und dringenden Geschäftsbedürfnissen weiter. Die Aussicht auf Unterstützung neuer Geschäftsprozesse durch das neue System führt daher zu erheblichen Anforderungsänderungen während dessen Entwicklung, wodurch sich ebenfalls das Risiko eines Fehlschlags erhöht. 3. Es existieren kaum Spezikationen. Die einzige Dokumentation für geerbte Informationssysteme ist üblicherweise der Code selbst. Das erhöht erheblich die Komplexität und die Kosten der Entwicklung des Ersatz-Systems. 4. Häug existieren undokumentierte Abhängigkeiten. In der Regel existieren Anwendungen, von nicht-kritischen (z.b. Reporting und andere Informationsanwendungen) bis hin zu auftragsentscheidenden, die auf Daten und andere Ressourcen des Erbschaftsinformationssystems zugreifen. Wenn das IS vollständig neu geschrieben werden soll, dann müssen Cold Turkey-Strategen diese Abhängigkeiten aufdecken und entsprechend behandeln. 5. Erbschaftsinformationssysteme können zu groÿ sein, um die Daten zu überspielen. Es gibt Fälle, in denen das neue System trotz beendeter Entwicklung nicht in Betrieb genommen werden kann, weil die Migration der Daten nicht innerhalb 5

18 1 Einführung zur Migration von Erbschaftsinformationssystemen einer akzeptablen Zeit möglich ist. Dies liegt daran, dass das System während der Datenmigration abgeschaltet werden muss und somit dessen auftragsentscheidende Funktion nicht zur Verfügung steht. 6. Die Leitung von Projekten, an denen viele Personen beteiligt sind, ist sehr schwierig. 7. Eine Verspätung wird selten toleriert. Groÿe Projekte verzögern sich zwangsläug aufgrund der oben genannten Probleme und die Geduld der Geschäftsführung lässt schnell nach. Dies bedingt häug die Terminierung und somit das Scheitern von teilweise oder fast beendeten Migrationsprojekten. 8. Groÿe Projekte neigen dazu, sich weiter zu vergröÿern. Eine solche Vergröÿerung erfolgt oft dadurch, dass weitere Personengruppen zu dem bereits sehr groÿen Projekt hinzugefügt werden, um neue Funktionalität oder Verbesserungen einzubringen. Dies ist für den Migrationsprozess allerdings nicht erforderlich, sondern eher ein Hindernis. Es erhöht die Komplexität der Projektleitung und macht das Projekt anfälliger für einen Fehlschlag oder eine Terminierung. 9. Homöostasie ist allgemein verbreitet. Die Angst vor Veränderungen, neuen Techniken und neuen Technologien trägt zu einem enormen Widerstand gegen die Cold Turkey Migration bei, reduziert das Ausmaÿ an Unterstützung, welches das Migrationsteam erhalten wird, und behindert gleichzeitig die Chance des Projekts auf einen endgültigen Erfolg. 10. Eine sog. Analyselähmung setzt ein. Es besteht die weit verbreitete Annahme, dass die Umsetzung der Cold Turkey- Strategie erst beginnen könne, wenn man alles über das IS wisse bzw. dessen Funktionsweise umfassend verstanden habe. Das Erreichen dieses Zustandes ist aber aufgrund der Gröÿe und Komplexität des Systems praktisch nicht möglich, so dass ständige Analysen ins Leere laufen und einen erfolgreichen Beginn der Migration behindern bzw. ausschlieÿen. Cold Turkey berücksichtigt keinen Zeitraum für eine sukzessive Anpassung. Direkt nach dem Umschalten (engl. ash cut oder cutover) vom alten zum neuen System muss das neue System mit voller Funktionalität zur Verfügung stehen. Auftretende Fehler haben entsprechend weitreichende Auswirkungen, daher beinhaltet diese Form der Migration von Erbschaftsinformationssystemen ein sehr hohes Risiko. 6

19 1.3 Migrationsstrategien Chicken Little Eine alternative Strategie ist die sog. Chicken Little-Methode [10]. Sie beinhaltet ein minimales Risiko und soll zwei Ziele erreichen: 1. Sie behandelt die Probleme von Erbschaftsinformationssystemen und zeigt einen Weg auf, der diese überwindet. 2. Sie baut eine IS-Infrastruktur auf, die hilft, ein Wiederkehren der Probleme zu verhindern. Während des gesamten Migrationsprozesses arbeiten das Erbschafts- und das Zielinformationssystem bei diesem Ansatz parallel, wobei mithilfe eines (oder mehrerer) Gateways das Zusammenspiel der beiden Systeme nach auÿen als ein einziges Informationssystem zur Verfügung gestellt wird. Dies hat für die Anwender des IS den Vorteil, dass ihnen die interne Aufteilung der Funktionalität verborgen bleibt. In Abbildung 1.2, welche die Migrationsarchitektur dieser Strategie veranschaulicht, ist zusätzlich zu erkennen, dass die Benutzer sowohl über die geerbten Schnittstellen als auch über die evtl. bereits neu entwickelten Schnittstellen auf das System zugreifen können. Abbildung 1.2: Migrationsarchitektur für Informationssysteme nach [10] Zu Beginn der Migration stellt das geerbte IS die gesamte Funktionalität zur Verfügung. Dann wird schrittweise zum Ziel-IS migriert, bis die gesamte Funktionalität vom neuen System übernommen worden ist und das alte IS abgeschaltet werden kann. Die Konsistenz der Daten und die Kommunikation der beiden Systeme wird dabei von verschiedenen Gateways (z.b. einem Datenbank-Gateway, siehe [10]) gewährleistet. Die Strategie des Chicken Little-Ansatzes besteht in der Migration des Erbschaftsinformationssystems durch kleine, inkrementelle Schritte, bis das angestrebte längerfristige Ziel erreicht ist. Dabei steht inkrementell für einen sukzessiven Prozess, 7

20 1 Einführung zur Migration von Erbschaftsinformationssystemen also ein schrittweises Erreichen des angestrebten Ziels, im Gegensatz zur Durchführung in einem einzigen Gesamtschritt. Die Inkrement-Gröÿe, also die Schrittweite, kann und soll von den Planern des Chicken Little nach [10] so gewählt werden, dass das Risiko bei der Ausführung des Schrittes minimal ist. Zu beachten ist dabei allerdings, dass sich durch eine Verringerung der Inkrement-Gröÿe die Anzahl der Schritte erhöht. Selbstverständlich ist das Risiko minimal, wenn die Inkrement- Gröÿe gegen Null geht, aber das angestrebte Ziel rückt in weite Ferne. Es ist also Vorsicht geboten, damit nicht eine ähnliche Situation, wie die der Analyselähmung (vgl. Abschnitt 1.3.1), auftritt und einen Fortschritt des Prozesses verhindert. Man sollte die Inkrement-Gröÿe somit angemessen wählen, denn das Ziel dieses Ansatzes ist nicht ein minimales Risiko, sondern ein kontrollierbares Risiko. Chicken Little ist somit eine inkrementelle Migrationsmethodik, die den Vorteil hat, dass im Falle des Fehlschlags eines Schrittes nur dieser eine Schritt wiederholt werden muss und nicht das ganze Projekt. In Abbildung 1.3 sind die einzelnen Schritte dieser Strategie angegeben, wobei jeder dieser Schritte auch wieder inkrementell ausgeführt werden kann und soll (vgl. [10]). Die Chicken Little Schritte 1. Inkrementelles Analysieren des geerbten IS 2. Inkrementelles Zerlegen der Struktur des geerbten IS 3. Inkrementelles Designen der Ziel-Interfaces 4. Inkrementelles Designen der Ziel-Anwendungen 5. Inkrementelles Designen der Ziel-Datenbank 6. Inkrementelles Installieren der Ziel-Umgebung 7. Inkrementelles Erzeugen und Installieren der notwendigen Gateways 8. Inkrementelles Migrieren der geerbten Datenbank 9. Inkrementelles Migrieren der geerbten Anwendungen 10. Inkrementelles Migrieren der geerbten Interfaces 11. Inkrementelles Wechseln zum Ziel-IS Abbildung 1.3: Die Chicken Little Schritte nach [10] 8

21 1.3 Migrationsstrategien Die Buttery-Methode In [39] wird Chicken Little als die ausgereifteste Migrationsmethode bezeichnet. Sie ermöglicht es Unternehmen, ihre geerbten Informationssysteme weiterhin zu nutzen und gleichzeitig neue Mechanismen zu entwickeln, die den alten Systemen eine Zusammenarbeit mit neuen, modernen Systemen erlauben, die zusätzliche Funktionalität anbieten. Der Nachteil dabei besteht allerdings in der Notwendigkeit der Zusammenarbeit von den Erbschafts- und Zielsystemen unter Verwendung der in [10] vorgestellten Gateways (siehe auch Abb. 1.2). Diese Notwendigkeit erhöht die Komplexität des Migrationsprozesses zusätzlich um ein beachtliches Maÿ und stellt eine groÿe technische Herausforderung dar. Deshalb wird in [39] die sog. Buttery- Methode vorgestellt, die einen Ansatz zur Migration von Erbschaftsinformationssystemen beinhaltet, für den keine Gateways benötigt werden. Das Ziel der Buttery-Methode ist eine Anleitung für die Migration eines geerbten, auftragsentscheidenden Systems zu einem Zielsystem. Im Unterschied zum Chicken Little-Ansatz wird das neue System während dessen Entwicklung allerdings nur zu Testzwecken verwendet, wodurch die Konsistenz zwischen den beiden (heterogenen) Informationssystemen auch ohne den Einsatz von Gateways bewahrt werden kann. Die Buttery-Methode basiert auf der Annahme, dass die Daten des Erbschaftssystems den bedeutendsten Teil des Systems ausmachen. Da für die Entwicklung des Zielsystems allerdings nicht die Daten selbst, sondern deren Semantik und deren Daten-Schema entscheidend sind, trennt die Buttery-Methode die Phasen der Zielsystem-Entwicklung und der Datenmigration und entfernt somit die Notwendigkeit von Gateways. Zu diesem Zweck werden die folgenden neuen Konzepte eingeführt, die anschlieÿend kurz erklärt werden: Legacy SampleData, Target SampleData und Sample DataStore; TempStore; Data-Access-Allocator (DAA); Data- Transformer; Termination-Condition und Treshold Value. Legacy SampleData ist eine repräsentative Teilmenge der Daten in der Erbschafts- Datenbank, Target SampleData wird aus Legacy SampleData transformiert und ein Sample DataStore speichert die Target SampleData basierend auf dem Datenmodell des Zielsystems. Dort dient der Sample DataStore für die Entwicklung und die Tests aller Zielsystemkomponenten (bis auf die Daten). In Abbildung 1.4 ist der parallele Aufbau des Zielsystems (Chrysalis, deutsch: Insektenpuppe) zum Erbschaftssystem (Caterpillar, deutsch: Raupe) dargestellt, und es wird die Trennung der Datenmigration (zunächst nur Beispieldaten) von der (schrittweisen) Migration der übrigen Komponenten (z.b. Interfaces und Anwendungen) verdeutlicht. Auÿerdem ist dort auch der Einuÿ von Dokumentation und Know-How für diese beiden Prozesse gut zu erkennen. 9

22 1 Einführung zur Migration von Erbschaftsinformationssystemen Abbildung 1.4: Aufbau des Zielsystems bei der Buttery-Methode (aus [39]) Sobald die Entwicklung und die Testphase des Zielsystems abgeschlossen sind, beginnt die Datenmigrationsphase. Hierbei kommen die Komponenten TempStore, Data-Access-Allocator und Data-Transformer sowie die Termination-Condition und der Treshold Value zum Einsatz. Das Zusammenspiel dieser Komponenten sowie das Vorgehen bei der Datenmigration werden in Abbildung 1.5 angegeben. Die Phase 4 der Buttery-Methode (Migration der Daten) 1. Die Daten im ursprünglichen System werden eingefroren, d.h. auf read-only gesetzt. 2. Der Data-Transformer sorgt für die Migration der (nun statischen) Daten von der Quell-Datenbank zum Zielsystem. 3. Während der Datenmigration werden alle Datenmanipulationen (insert, update, delete) vom Data-Access-Allocator (DAA) verarbeitet, der die Ergebnisse im ersten von mehreren TempStores speichert. 4. Wenn alle Daten von der Quell-Datenbank zum Zielsystem migriert wurden, wird der TempStore auf read-only gesetzt und ein neuer TempStore wird aktiviert. 5. Die Daten (beziehungsweise die Datenmanipulationen) vom ersten TempStore werden zum Zielsystem transferiert. 6. Während dieser Datenmigration werden alle Datenmanipulationen im nächsten TempStore gespeichert. 7. Dies wiederholt sich solange, bis die Termination-Condition erreicht ist, und die Gröÿe des letzten TempStores unterhalb einer vorgegebenen Schranke (dem Treshold Value) liegt. 8. Das Erbschaftsinformationssystem wird abgeschaltet, die letzten Daten werden migriert, und das Zielsystem wird aktiviert. Abbildung 1.5: Phase 4 (Migration der Daten) der Buttery-Methode nach [39] 10

23 1.3 Migrationsstrategien Zusätzlich wird der Aufbau des Systems während der Datenmigrationsphase in Abbildung 1.6 veranschaulicht, wobei der Data-Transformer als Chrysaliser bezeichnet wird. Abbildung 1.6: Migrieren der Daten in TempStore T S n (aus [39]) In Abbildung 1.7 ist eine Übersicht der in [39] genannten Phasen der Buttery- Methode angegeben. Die vierte Phase besteht dabei aus der schon angesprochenen Datenmigration, deren Details in Abbildung 1.5 aufgelistet sind. Auf eine detaillierte Beschreibung der übrigen Phasen wird hier verzichtet, da diese sich nicht wesentlich von den bereits in dieser Arbeit genannten Aufgaben unterscheiden (siehe [39]). Die Phasen der Buttery-Methode 0. Vorbereiten der Migration 1. Verstehen der Semantik des geerbten Systems und Entwickeln des/der Ziel-Datenschemas 2. Aufbauen eines Sample DataStore, basierend auf den Beispieldaten Target SampleData im Zielsystem 3. Inkrementelles Migrieren aller Komponenten (auÿer den Daten) des geerbten Systems zur Ziel-Architektur 4. Sukzessives Migrieren der geerbten Daten ins Zielsystem und Trainieren von Benutzern im Zielsystem 5. Cut-over zum fertiggestellten Zielsystem Abbildung 1.7: Die Phasen der Buttery-Methode nach [39] 11

24 1 Einführung zur Migration von Erbschaftsinformationssystemen Bewertung der Migrationsstrategien Wie schon zu Beginn dieses Abschnitts angesprochen, erfordert der Erfolg eines Migrationsprojekts eine wohldenierte, detaillierte Methodik, die darüber hinaus auch noch leicht zu implementieren ist. Oft werden die vorhandenen Strategien allerdings als zu allgemein oder zu speziell eingestuft. Die bekanntesten drei Migrationsstrategien wurden bereits vorgestellt und sollen nun abschlieÿend verglichen sowie bewertet werden. Cold Turkey Das wichtigste Kriterium für ein Gelingen der Cold Turkey-Migration ist das Vorhandensein eines Gurus, der das System (bzw. die Systeme) möglichst vollständig versteht. Bei sehr komplexen Systemen ist es allerdings in den meisten Fällen unwahrscheinlich, jemanden mit diesem Wissen zu nden, weshalb die vollständige Neuentwicklung eines Systems (genau dies beinhaltet der Cold Turkey) oft nur im Falle einfachster Informationssysteme möglich ist. Nur bei einer kurzen Analyseund Entwicklungszeit kann letztendlich der Groÿteil der in Abschnitt angesprochenen Probleme und Risiken umgangen werden. Die Wahrscheinlichkeit eines Fehlschlags bei der Migration mit dieser Strategie ist bei einfachen bzw. vollständig verstandenen Systemen deutlich geringer als bei komplexen. Dies schlieÿt ein Misslingen des Vorhabens aber keineswegs aus. Ein weiterer Kritikpunkt ist der riskante Cutover, bei dem nach Beendigung der Neuentwicklung vom geerbten zum neuen System umgeschaltet wird. Da das zu migrierende Informationssystem eine auftragsentscheidende Funktion besitzt, können auch kurze Ausfälle nicht in Kauf genommen werden. Erschwert wird der Cutover des Systems durch die bereits angesprochene Migration der Daten. Während der Datenmigration darf das Erbschaftsinformationssystem bereits nicht mehr verwendet werden, und je mehr Daten sich darin benden, desto länger dauert ihre Migration und somit der Ausfall des Systems. Schlieÿlich ist selbst nach erfolgtem Cutover das Risiko sehr groÿ, dass Fehler, die sich bei der Neuentwicklung des Systems eingeschlichen haben (z.b. beim Verstehen des alten Systems, in der Konzipierung des neuen Systems oder bei dessen Programmierung), den Einsatz des neuen Systems und somit auch die geschäftliche Tätigkeit des Unternehmens blockieren. (Anmerkung: Diese Beschreibung des Cutover stammt aus [10] und trit aus heutiger Sicht nicht mehr vollständig zu, denn mittlerweile kann man die genannten Risiken dadurch abschwächen, dass man den neu entwickelten sowie den Produktionsserver eine Weile parallel laufen lässt. Dies geschieht im sog. Shadowing-Betrieb, d.h. ein Server ist der Schatten des anderen. Auf diese Weise ist ein Abgleichen der Ergebnisse und somit ein Korrektheitstest des neuen Systems möglich, ohne dass der Betrieb bereits vollständig auf den neuen Server umgestellt wird. Sobald die Ergebnisse übereinstimmen, kann man den Testserver zum Produktionsserver 12

25 1.3 Migrationsstrategien machen. Der ursprüngliche Server wird dann allerdings nicht abgeschaltet, sondern läuft noch eine Weile als Schatten des neuen Servers mit. Im Falle schwerwiegender Fehler bewahrt man sich so die Möglichkeit, wieder auf den ursprünglichen Server umzuschalten. Es muss allerdings darauf geachtet werden, dass das ursprüngliche System nach einer gewissen (erfolgreichen) Testphase auch wirklich abgeschaltet wird, da man sonst die Erbschaft niemals wirklich abstöÿt und somit möglicherweise auch wieder die Wartung des geerbten Systems erforderlich macht, wodurch die Migration ihr eigentliches Ziel verfehlt.) Insgesamt ist der Ansatz Cold Turkey sehr allgemein gehalten und beinhaltet sehr viele Risiken. Auÿerdem erfüllt er eher die Kriterien des Redevelopment (siehe Abschnitt 1.2.1) als die der Migration, bei der es um Wiederverwendung und somit um die Vermeidung aufwendiger Neuentwicklungen geht. Chicken Little Aufgrund der eben genannten Risiken des Cold Turkey-Ansatzes wird dieser in der Literatur, welche die Chicken Little-Strategie favorisiert (vgl. [9, 10]), pauschal abgewertet. Sachlich betrachtet fallen folgende Unterschiede bzw. Neuerungen auf: 1. Der eine groÿe Schritt des Cutover beim Cold Turkey soll durch viele kleine Schritte ersetzt werden. 2. Das Zielsystem ist während der Entwicklung bereits verfügbar. Es arbeitet parallel zum Erbschaftsinformationssystem und übernimmt noch während des Migrationsprozesses dessen schon migrierte Funktionalität. Dadurch verschwinden die Probleme des Cold Turkey jedoch nicht vollständig, sondern verlagern sich teilweise nur. Es entstehen andere Probleme, welche neue Voraussetzungen bzw. Anforderungen an das Erbschaftsinformationssystem stellen und die Chicken Little-Strategie wiederum erheblich einschränken oder in der Durchführung erschweren. zu 1.) Die Voraussetzung für eine Aufteilung des Migrationsprozesses in viele kleine Schritte erfordert auch eine Aufteilungsmöglichkeit des Erbschaftsinformationssystems. Nach [10] sollte eine funktionale Zerlegung (siehe Abschnitt 1.4) möglich sein. Auÿerdem ist eine zerlegbare Architektur (siehe Abschnitt 1.4) wünschenswert, denn im Falle einer nicht zerlegbaren Architektur wird das inkrementelle Vorgehen erheblich erschwert. 13

26 1 Einführung zur Migration von Erbschaftsinformationssystemen zu 2.) Die gleichzeitige Verfügbarkeit und das Zusammenarbeiten der beiden Informationssysteme, so dass sie von der Funktionalität her für die Benutzer als ein einziges IS erscheinen, stellt eine sehr groÿe technische Herausforderung dar. Die hierfür benötigten Gateways bringen eine beachtliche Komplexität mit sich und bilden den gröÿten Bestandteil der Chicken Little-Strategie. Sie ermöglichen erst den parallelen Betrieb der Systeme und die inkrementelle Migration der Funktionalität, die diesen Ansatz ausmachen. Ein wichtiges Kriterium für den Erfolg dieser Migrationsstrategie ist also jemand, der das System zerlegen kann. Ist diese Bedingung nicht erfüllt, so sind die Vorteile des Verfahrens nicht nutzbar. Buttery-Methode Die Buttery-Methode orientiert sich nach [39] an der Chicken Little-Strategie und versucht die angesprochene Komplexität der Gateways zu vermeiden. Dies wird jedoch nicht neuartig gelöst, sondern es wird dadurch umgangen, dass das Ziel-IS bis zum Ende des Migrationsprozesses nicht für den Echtbetrieb freigeschaltet wird. Es steht während der Entwicklung nur für Tests zur Verfügung und muss erst den Cutover, inklusive der darin enthaltenen Datenmigration, abwarten, um die volle Funktionalität des Erbschaftsinformationssystems übernehmen zu können. Diese Tatsache erinnert wiederum eher an den Cold Turkey als an Chicken Little, wobei allerdings eines der groÿen Probleme des Cold Turkey-Ansatzes, nämlich die Nicht-Verfügbarkeit beider Informationssysteme während der Datenmigration, mit der Buttery-Methode behoben wird, denn mithilfe des in Abschnitt beschriebenen Vorgehens bleibt das Erbschaftsinformationssystem während der Datenmigration weiterhin verfügbar. Für die Nutzbarkeit der Buttery-Methode ist allerdings eine klare Trennung der Anwendung von der Zugrisschicht der Datenbank erforderlich, da sonst der Data- Access-Allocator nicht dazwischen eingefügt werden kann (siehe Abbildung 1.6). 3 Ist diese Voraussetzung jedoch erfüllt, so ist die Implementierung der für diese Methode benötigten Komponenten nicht so komplex wie die Entwicklung der beim Chicken Little-Ansatz benötigten Gateways. Einige der Probleme, die schon beim Cold Turkey in Bezug auf die parallele Neuentwicklung genannt wurden (z.b. Weiterentwicklung der Geschäftsanforderungen), bleiben auch bei dieser Methode bestehen. Sie können allerdings durch eine mögliche Inkrementalisierung im Sinne von Chicken Little und durch umfangreiche Tests mit den Testdaten (Legacy/Target SampleData, siehe 1.3.3) abgeschwächt werden Auf entsprechende Merkmale, welche die Zerlegbarkeit der Architektur betreen, wird in Abschnitt 1.4 eingegangen.

27 1.4 Migrationskomplexität und IS-Architekturen Schluÿfolgerung Keiner der hier vorgestellten Ansätze zur Migration von Erbschaftsinformationssystemen ist universell anwendbar. Jeder Ansatz hat seine Vor- und Nachteile und passt für die zu migrierenden Systeme mehr oder weniger gut. Die vielversprechendste Lösungsstrategie enthält somit Aspekte aus allen drei Ansätzen, nämlich die Neuentwicklung einzelner, möglichst weniger 4, Bestandteile (Cold Turkey), die Zerlegung der Migrationsaufgabe in Teilaufgaben (Chicken Little) und die separate Betrachtung der Datenmigration (Buttery). 1.4 Migrationskomplexität und IS-Architekturen Zusätzlich zur Wahl der Migrationsmethodik hängt die Komplexität des Migrationsaufwandes - und seines wahrscheinlichen Erfolgs oder Fehlschlags - von der IS-Architektur in der Erbschaftsumgebung ab (vgl. [10]). Deshalb wird in diesem Abschnitt die Architektur von Informationssystemen und deren Einuss auf die Komplexität der Migration betrachtet. Die Entwicklungen im Bereich der Softwarearchitektur spiegeln sich auch in den Architekturen von Informationssystemen wider. Es ist zu beobachten, dass die vor vielen Jahren entwickelten Informationssysteme meistens keine Zerlegbarkeit in kleinere Komponenten aufweisen, die heutzutage Bestandteil moderner Softwarearchitektur ist. Eine solche Struktur, sofern sie denn vorhanden ist, ermöglicht eine komponentenweise Migration des geerbten Informationssystems, wodurch die Komplexität der Migration erheblich verringert werden kann. Da allerdings niemand weiÿ, was die nächste Generation von Softwarearchitektur bringen wird (ebensowenig weiÿ man im Voraus, wie die zukünftige Generation von Rechnern aussehen wird), kann man nicht erwarten, dass Erbschaftsinformationssysteme die Anforderungen der heutzutage modernen Softwarearchitektur erfüllen. Vielmehr ist entscheidend, dass man sich zum Zeitpunkt der Planung ein nachvollziehbares Konzept bzw. eine schlüssige Architektur überlegt und dass man diese Überlegungen während der langjährigen Entwicklung auch konsequent umgesetzt hat. Denn nur bei der konsequenten Umsetzung einer durchdachten Struktur kann diese auch nach vielen Jahren noch verstanden werden. Andernfalls werden die Analyse und die Migration eines Systems sehr komplex. Aus diesen Gründen sollte bei der Planung einer Migration immer darauf geachtet werden, dass das Zielsystem so strukturiert wird, dass es die hier angesprochenen Anforderungen erfüllt, um so zukünftige Entwicklungen zu vereinfachen. Brodie und Stonebraker betrachten in [10] die Architektur von Informationssystemen im Kontext der Migration. Siedersleben beschreibt in [32] ebenfalls die Archi- 4 Erinnerung: Die Migration zeichnet sich durch Wiederverwendung aus. Bei umfangreicher Neuentwicklung handelt es sich um ein Redevelopment-Projekt (vgl. Abschnitt 1.2). 15

28 1 Einführung zur Migration von Erbschaftsinformationssystemen tektur von Software- und Informationssystemen; er betrachtet diese allerdings unter dem Aspekt der Standardisierung und der Möglichkeit zur Wiederverwendung. In den nächsten beiden Abschnitten werden beide Ansätze ausführlicher erläutert Softwarearchitektur nach Brodie und Stonebraker Die vollständige Funktion eines Informationssystems ist aufgeteilt in eine Menge von einzelnen Funktionen. Solche Funktionen können wiederum in Unterfunktionen zerlegt werden und so weiter, so dass eine Hierarchie von Funktionen entsteht, die als funktionale Zerlegung des Informationssystems bezeichnet wird. Das IS wird aus Komponenten oder Modulen entwickelt, die diese Struktur abbilden. Alle Informationssysteme können angesehen werden, als bestünden sie aus drei Komponenten, die aber meistens nicht klar voneinander getrennt sind: 1) Interfaces, 2) Anwendungen und 3) einem Datenbank-Service. In [10] werden die wohlstrukturierten und unstrukturierten Extreme und ein Punkt dazwischen betrachtet: 1. Zerlegbare Erbschafts-IS-Architekturen, 2. halbzerlegbare Erbschafts-IS-Architekturen und 3. nicht zerlegbare Erbschafts-IS-Architekturen. Bei einer zerlegbaren Architektur sind die o.g. Komponenten klar voneinander getrennt und besitzen wohldenierte Schnittstellen. Sie ist die am besten geeignete Architektur für ein Migrationsvorhaben. Abbildung 1.8 zeigt ein Informationssystem mit dieser Architektur, das aus mehreren Anwendungsmodulen besteht. Diese sollten unabhängig voneinander sein, d.h. keine hierarchische Struktur haben, und nur mit dem Datenbanksystem kommunizieren, damit sie auch unabhängig voneinander migriert werden können. Abbildung 1.9 zeigt ein halbzerlegbares Informationssystem. Es ist schwieriger zu migrieren als ein zerlegbares IS, da sich die Anwendungsmodule nicht vom Datenbanksystem trennen lassen. Die Interfaces bilden allerdings auch bei dieser Architektur noch eigenständige Komponenten. Eine nicht zerlegbare Architektur (siehe Abbildung 1.10) ist am schlechtesten für ein Migrationsvorhaben geeignet. Sie ist nicht in funktionale Komponenten zerlegbar und stellt von auÿen gesehen eine black box dar (vgl. [10]). In der Realität ist es allerdings oft nicht möglich, die Architektur eines Informationssystems in eine der Kategorien einzuordnen. Meistens nden sich Teile aus jeder Kategorie, wodurch eine neue Form entsteht, die solche gemischten Architekturen (engl. hybrid architectures) enthält (siehe Abbildung 1.11). Architekturen dieser Kategorie sind sehr komplex und erschweren die Migration, aber durch einen gewissen Anteil zerlegbarer Komponenten ermöglichen sie doch auch einige getrennte (inkrementelle) Migrationsschritte. 16

29 1.4 Migrationskomplexität und IS-Architekturen Abbildung 1.8: Zerlegbare Erbschafts-IS-Architektur nach [10] Abbildung 1.9: Halbzerlegbare Erbschafts-IS-Architektur nach [10] 17

30 1 Einführung zur Migration von Erbschaftsinformationssystemen Abbildung 1.10: Nicht zerlegbare Erbschafts-IS-Architektur nach [10] Abbildung 1.11: Gemischte Erbschafts-IS-Architektur nach [10] 18

31 1.4 Migrationskomplexität und IS-Architekturen Es ist also jeweils eine genaue Analyse des Systems erforderlich, um dessen Architektur den genannten Kategorien zuzuordnen und einzelne (möglichst unabhängige) Komponenten aufzudecken. Die Architektur wirkt sich entscheidend auf den Migrationsprozess aus, wobei für die Endanwender des Systems vollständig verborgen bleibt, ob es sich um eine zerlegbare, halbzerlegbare, nicht zerlegbare oder um eine gemischte Architektur handelt Softwarearchitektur nach Siedersleben Bei der Architektur von Softwaresystemen ist das Denken in Komponenten und Schnittstellen ein ganz entscheidender Bestandteil, ebenso wie die Trennung von Anwendung und Technik. Deshalb unterteilt Siedersleben in [32] die Systemarchitektur, also die Architektur eines Informationssystems, in die folgenden drei Architekturen: 1. Anwendungsarchitektur (A-Architektur), 2. Technikarchitektur (T-Architektur) und 3. die Architektur der technischen Infrastruktur (TI-Architektur). Die A-Architektur strukturiert die Software aus Sicht der Anwendung. Sie beschreibt die Funktionen und das Zusammenspiel der Anwendungskomponenten, die ohne Bezug zur Technik entworfen werden und ausschlieÿlich die Funktionalität der Anwendung beinhalten sollen, die auf genauer Kenntnis der fachlichen Abläufe basiert. 5 Die A-Architektur besteht aus drei Schichten: einer Übersicht der Anwendungskomponenten, deren Leistungsumfang und der von ihnen verwalteten Daten (Vorgaben dafür sind die Anwendungsfälle, das Datenmodell und die Nachbarsysteme), einer Auÿensicht, welche die Schnittstellen der Anwendungskomponenten auf der Ebene von Operationen beschreibt und einer Innensicht, welche die Klassen sowie deren Struktur darstellt, die für die Implementierung der Anwendungskomponenten benötigt werden. Die T-Architektur stellt den sachgemäÿen Umgang mit der Technik sicher. Sie beschreibt alle anwendungsunabhängigen Komponenten des Systems: Zugrisschicht, GUI-Rahmen, Fehlerbehandlung und anderes mehr. Auÿerdem verbindet sie die A- Architektur mit der TI-Architektur. Die T-Software ist die Ablaufumgebung für die A-Software. 5 Dies entspricht dem, was auch Brodie und Stonebraker als funktionale Komponenten bezeichnen, allerdings betonen sie nicht eine möglichst vollständige Trennung von der Technik. 19

32 1 Einführung zur Migration von Erbschaftsinformationssystemen Zur TI-Architektur gehören die physischen Geräte (Rechner, Netzleitungen, Drucker etc.), die installierte Systemsoftware (Betriebssystem, Transaktionsmonitor, Anwendungsserver, Verbindungssoftware) und das Zusammenspiel von Hardware und Systemsoftware. 1.5 Vorbereitung und globales Design In jedem Fall ist es für den Migrationsprozess von entscheidender Bedeutung, das zu migrierende Erbschaftsinformationssystem zu kennen. Deshalb ist die ausführliche Analyse eine wichtige Vorbereitung, bei der allerdings die in Abschnitt bereits angesprochene Analyselähmung vermieden werden muss. Zusätzlich sollten zur Vorbereitung und zur Entwicklung des globalen Designs der Migration die folgenden Schritte befolgt werden (vgl. auch [10]): 0. Nachvollziehen früherer Entscheidungen und bisheriger Probleme Bevor das neue System entwickelt werden kann, muss herausgefunden werden, welche Entscheidungen (z.b. in Bezug auf die Paradigmen der Modellierung) vor bzw. bei der Entwicklung des geerbten Systems getroen worden sind und welche Gründe es dafür gab. So kann man vermeiden, sich bei der Entwicklung des neuen Systems für einen falschen Weg zu entscheiden. In [35] (Seite 15.) werden diese vom Modellierer gefällten Entscheidungen (dort als Urteile bezeichnet) genauer erläutert. Ein Modellierungsurteil wird dabei als ternäre Beziehung zwischen Eigenschaft, Theorien und den im Kontext agierenden Individuen aufgefasst. Nach der Modellierung sind dann allerdings oft nur noch die Modellierungsurteile verfügbar, wodurch die impliziten Annahmen, die theoretischen Grundlagen, die Beobachtung der Realität und oft auch die Spezika des Entwicklers nicht mehr nachvollziehbar sind. Dies wird in [35] (Seite 16) als das Dilemma der Modellierung bezeichnet. Auÿerdem sollten die Hauptprobleme des Erbschaftssystems ermittelt werden, die sich während dessen Betrieb gezeigt haben, um diese in zukünftige Entscheidungen mit einzubeziehen. Auf diese Weise ist es möglich, ein Auftreten der Probleme bei der Verwendung des neuen Systems schon während dessen Planung auszuschlieÿen. 1. Radikales Reduzieren sowie Analysieren von Funktionen und Daten Die Herausforderung der Migration wächst nach Abschätzung von Brodie und Stonebraker exponentiell zur Gröÿe der zu migrierenden Erbschaft (vgl. [10]). Deshalb soll die Migration im Sinne der Neuplanung 6 soweit wie möglich durch eine radikale Vereinfachung der Informationssysteme vermieden werden und 6 engl. Reengineering, siehe Abschnitt

33 1.5 Vorbereitung und globales Design zwar nicht nur initial, sondern vor jedem einzelnen inkrementellen Schritt. Dies bedeutet, dass man alle Funktionen anschauen und bewerten muss, um eine Übersicht zu erstellen, aus der ersichtlich ist, welche Funktionen wichtig sind, welche nicht und was die Funktionen überhaupt tun. An dieser Stelle ist wieder einmal die vorhandene Dokumentation von entscheidender Bedeutung, aber in vielen Fällen existiert diese gar nicht, wodurch ein solcher Schritt beträchtlich erschwert wird. 2. Entwicklung eines globalen Designs des Ziel-Informationssystems Das globale Design des Ziel-Informationssystems beinhaltet die Interfaces, Funktionen und Daten (siehe Abschnitt 1.4). Für komplexe Erbschaftsinformationssysteme wird die Migration viele Jahre dauern und deshalb ist es unmöglich, ein detailliertes Design zu entwerfen, das während der gesamten Migration gültig bleibt. Somit muss auch das Design inkrementell erstellt werden. 3. Designen der Zielumgebung Bei der Entwicklung der Zielumgebung sollte man versuchen, diese so exibel wie möglich zu halten. Man binde das Ziel-IS beispielsweise nicht an ein bestimmtes Betriebssystem, Datenbankmanagementsystem oder Programmiersprache. Wie bei globalem Schema und Funktionsdesign, entwickle man ein globales Design der Zielumgebung und biete ein detailliertes Design nur, wenn es für die inkrementellen Schritte benötigt wird. 4. Designen des Migrationsframeworks Das Migrationsframework beinhaltet das Erbschaftsinformationssystem, das Ziel-IS, und das zusammengesetzte IS, welches die alten, die neuen und die Zwischenkomponenten (wie z.b. Gateways beim Chicken Little-Ansatz oder Data-Access-Allocator bei der Buttery-Methode) enthält. Auÿerdem beinhaltet es das Mapping zwischen Source-Objekten und ihren Gegenstücken im Ziel. 21

34 1 Einführung zur Migration von Erbschaftsinformationssystemen 22

35 2 Überblick zur Migration von Datenbanken Jedes Informationssystem basiert auf einer oder mehreren Datenbanken. Diese enthalten die zu verwaltenden Daten und bilden die Grundlage für die eigentliche Funktionalität des Systems. Im Falle modernerer Systeme sind die Datenbanken über Datenbankmanagementsysteme (DBMS) von den Anwendungen isoliert und die Kommunikation zwischen beiden erfolgt über wohldenierte Schnittstellen. Im Sinne der Softwarearchitektur stellt also die Datenbank bzw. das DBMS eine eigenständige Komponente des Systems dar (siehe Abschnitt 1.4). Man könnte somit vermuten, dass sich die Migration einer Datenbank ohne Auswirkung auf den Rest des Systems durchführen lässt. In der Realität ist dies jedoch mit einer Menge Arbeit verbunden, für die es bislang kaum allgemeine oder automatisierbare Lösungen gibt. Insbesondere wenn nicht nur ein anderes Datenbankschema, sondern auch ein anderes DBMS zum Einsatz kommen soll, treten viele Probleme auf. Die Ursache hierfür sind zahlreiche Unterschiede zwischen den einzelnen Datenbanksystemen, wie beispielsweise in der bereitgestellten Funktionalität oder den schon angesprochenen Schnittstellen, so dass sich die Migration der Datenbank-Komponente unter Umständen doch auf die gesamte Anwendung auswirkt. Einige Teile dieser Migrationsaufgabe können automatisiert gelöst werden und für andere sind manuelle Lösungen vorhanden. Es gibt aber auch bisher ungelöste Teilprobleme. In diesem Abschnitt wird ein Überblick zur Thematik der Datenbankmigration gegeben, in dem die Aufgaben, die bisherigen Strategien und die bestehenden Probleme beschrieben werden. Auÿerdem wird ein spezielles Problem herausgearbeitet, dessen Lösungsansatz das Ziel dieser Arbeit darstellt. Zusätzlich werden hier einige der bereits angesprochenen Unterschiede von Datenbankmanagementsystemen angegeben, wodurch die enorme Komplexität eines vollständigen Migrationsvorhabens zumindest angedeutet werden soll. Abschlieÿend wird in diesem Kapitel auÿerdem ein Beispiel aus der Praxis vorgestellt, das den Ausschnitt einer Datenbank sowie einige Anfragen enthält. Es dient zunächst zur Veranschaulichung der in diesem Abschnitt vorgestellten Verfahren und später zur Demonstration des noch in dieser Arbeit vorzustellenden Ansatzes zur Migration von Anfragen. 23

36 2 Überblick zur Migration von Datenbanken 2.1 Aufgaben der Datenbankmigration Bei der Migration von Datenbanken unterscheidet man die strukturelle und die funktionale Migration, wobei der strukturelle Teil die Daten- sowie die Zugrisstrukturen und der funktionale Teil u.a. die Anfragen und die Modikationen der Daten enthält. Alternativ könnte man auch eine Separation der Datenbankmigration in die Aspekte Daten, Prozesse und Steuerung vornehmen. Dabei kann man prinzipiell die Daten als stellvertretend für die strukturelle Migration, und die Prozesse als stellvertretend für die funktionale Migration ansehen. Die Steuerung ist ein zusätzlicher Aspekt, der die Funktionalität des DBMS bezüglich der Steuerung der zugrundeliegenden Maschine beschreibt (z.b. die Verwaltung von Speicher oder Prozessen). 1 Allgemein lässt sich sagen: 1. der strukturelle Teil kann als gelöst angesehen werden, 2. die Bewältigung des funktionalen Teils in vollem Umfang stellt bislang einen unerfüllten Wunsch dar und 3. die Migration der Steuerungsfunktionalität ist bisher nicht beherrschbar. Deshalb wird für die in dieser Arbeit angesprochenen Migrationen von Datenbanken zwischen verschiedenen Datenbankmanagementsystemen vorausgesetzt, dass das Ziel-DBMS mindestens die Steuerungsfunktionalität anbietet, die auch vom Ausgangs-DBMS zur Verfügung gestellt wird. Im Folgenden werden die beiden Teile, also die strukturelle und die funktionale Migration, genauer beschrieben. Es wird angegeben, was sie beinhalten, welches ihre problematischen Teile sind, was bereits gelöst wurde, und welche Probleme noch oen bzw. ungelöst sind. Dabei beziehen sich die folgenden Aussagen aufgrund des im Rahmen dieser Diplomarbeit untersuchten Anwendungsfalls 2 insbesondere auf Migrationen zwischen zwei relationalen Datenbanksystemen, sie gelten z.t. aber auch für allgemeine Datenbankmigrationen. 1 Diese Art der Steuerung darf nicht mit den Steuerprozessen verwechselt werden, die sich auf die Steuerung des Datenbanksystems beziehen und beispielsweise die Vergabe bzw. das Entziehen von Rechten sowie das Setzen von Optionen beinhalten. 2 Es wurde für eine Anwendung aus der Praxis die Migration vom Microsoft SQL Server 2000 nach Oracle untersucht. Die Anwendung wird im weiteren Verlauf dieser Arbeit noch genauer vorgestellt, da sie zur Veranschaulichung der beschriebenen Verfahren sowie zur Erprobung der in dieser Arbeit neu entwickelten Strategie zur Migration von Anfragen verwendet wird. 24

37 2.1 Aufgaben der Datenbankmigration Strukturelle Migration Zum strukturellen Teil einer Datenbankmigration zählen Datenbankschema, Sichten (sofern in beiden Datenbanksystemen vorhanden), Indizes (sofern in beiden Datenbanksystemen vorhanden), Integritätsbedingungen sowie die vorhandenen Daten. Die Migration von Datenbankschemata ist in der Literatur bereits ausführlich behandelt worden. Sie beinhaltet das Finden eines neuen Datenbankschemas, auf welches das alte Schema abgebildet werden kann und soll. Ein Ansatz hierfür besteht in der Rückgewinnung des konzeptionellen Schemas sowie dessen Anpassung, wonach das so entstandene Schema wieder ins logische Modell überführt wird und dann das Ziel-Datenbankschema bildet. Entscheidend für die Migrierbarkeit der übrigen Komponenten ist dabei das Vorhandensein einer Abbildungsfunktion, die das alte Schema auf das neue abbildet. 3 Da es sich bei Sichten um Abbildungen handelt, kann die eben angesprochene Abbildungsfunktion (bzw. deren Umkehrfunktion) ebenfalls als Menge von Sichten deniert werden. Auf diese Weise ist es möglich, das neue Schema mit Hilfe von Sichten auf das alte Schema abzubilden, wodurch die ursprünglichen Abbildungen (Sichten) beibehalten werden können. Sie bilden nun allerdings nicht mehr das alte Schema, sondern die neu entstandenen Sichten ab. Die Migration von Sichten besteht also in der Denition neuer, zusätzlicher Sichten, die aufsetzend auf dem neuen Schema das alte Schema zur Verfügung stellen. Indizes basieren auf bestimmten Attributen eines Relationstyps, um den Zugri auf gesuchte Tupel zu beschleunigen. Verändert sich die Struktur eines Relationstyps im Verlauf der Änderung des Datenbankschemas, so dass von einem Index verwendete Attribute beeinusst werden, dann muss dieser Index auf dem geänderten Relationstyp gemäÿ der durchgeführten Änderungen neu erstellt werden. Andernfalls kann er unverändert übernommen werden. Aufgrund der eben genannten Tatsache, dass Indizes der Zugrisbeschleunigung dienen, wäre allerdings auch eine Sichtweise denkbar, welche die Indizes vollständig von der Migration ausschlieÿt, da es sich dabei um eine reine Performanz-Frage handelt und nicht um die Erhaltung von Strukturen oder Informationen. 3 Verwandte Themen hierzu sind das sog. Schema Mapping und das Schema Matching. Das Schema Mapping setzt äquivalente Bestandteile zweier, möglicherweise heterogener, Schemata miteinander in Beziehung, und das Schema Matching bezeichnet Methoden, mit denen auf automatisiertem Wege ein Schema Mapping zwischen zwei gegebenen Schemata gefunden werden kann (vgl. auch [17, 27, 31]). 25

38 2 Überblick zur Migration von Datenbanken Die Migration von Integritätsbedingungen umfasst Konstrukte wie Primär- und Fremdschlüssel oder CHECK-Constraints. Bei einem Wechsel des DBMS kann sich deren Migration schwierig gestalten, da nicht alle Typen von Integritätsbedingungen von allen Datenbanksystemen angeboten werden (z.b. unterstützt MySQL keine CHECK-Bedingungen [29]). Deshalb sollte vor der Migration besonders darauf geachtet werden, dass die im geerbten System verwendeten Integritätsbedingungen auf das Zielsystem abbildbar sind. Die Migration der Daten besteht im Wesentlichen aus dem Kopieren der Daten vom alten ins neue Datenbankschema, wobei wieder die o.g. Abbildungsfunktion die entscheidende Rolle spielt, da sie beschreibt, wie die Daten aus dem alten Schema auf das neue abzubilden sind. Wichtig für die Datenmigration ist auÿerdem, dass das zu migrierende System bereits abgeschaltet oder in einen nur-lesen-modus versetzt wird, damit keine Änderungen auf dem Datenbestand, die während oder nach der Datenmigration durch das geerbte System vorgenommen werden, verloren gehen (siehe Cutover und Datenmigration in den Abschnitten und 1.3.3). Reengineering des Datenbankschemas In Kapitel 1 wurde bereits angesprochen, dass zur Migration immer auch ein gewisses Maÿ an Reengineering gehört. Deshalb erfolgt auch zur Vorbereitung der Migration des Datenbankschemas ein Reengineering des bisher vorhandenen Datenbankschemas, das meistens eine (Rück-) Transformation des Schemas in eine Repräsentation auf konzeptioneller Ebene beinhaltet, wie z.b. das Entity-Relationship- Modell (ER-Modell, siehe [34]). Dieser Vorgang wird auch als Reverse Engineering bezeichnet 4. Dabei geht es zunächst darum, das Schema zu verstehen, um es anschlieÿend entzerren und normalisieren zu können, denn in der Regel wächst auch das Datenbankschema im Laufe der Zeit mit der Anwendung und verliert dadurch an Wohlstrukturiertheit. Das gröÿte Problem besteht auch bei diesem Schritt im Verständnis des vorhandenen Schemas, da meistens kaum Dokumentationen zu den einzelnen Typen und Attributen vorhanden sind. Nachdem das konzeptionelle Datenbankschema durch das Reverse Engineering erhalten und dieses konzeptionelle Schema angepasst wurde, wird das Reengineering durch die erneute Transformation des Schemas in die logische Repräsentation abgeschlossen. Durchführung der strukturellen Migration In Abbildung 2.1 wird das schematische Vorgehen bei der strukturellen Migration gezeigt. Als erstes erstellt man aus dem vorhandenen Datenbankschema S das neue 4 Für das Reverse Engineering von Datenbankschemata und das Extrahieren von ER-Modellen aus relationalen Datenbanken gibt es zahlreiche Ansätze und umfangreiche Literatur, wie z.b. [2, 3, 4, 5, 18, 19, 20, 23, 26]. 26

39 2.1 Aufgaben der Datenbankmigration Schema S'. Dieses entsteht unter Verwendung des im Prozess des Reverse Engineering entwickelten konzeptionellen Datenbankschemas (s.o.), welches nach Abschluss der Anpassungen zum logischen Datenmodell transformiert wird. Die bereits angesprochene Transformations- bzw. Abbildungsfunktion Trans beschreibt dabei, wie (auf logischer Ebene) S' aus S entstanden ist, was im Wesentlichen die entsprechenden Anpassungsschritte auf konzeptioneller Ebene beinhaltet. 5 Die beiden Schemata müssen mithilfe der Transformationsfunktion aufeinander abbildbar sein, denn nur dann sind auch die übrigen Aspekte (z.b. die Anfragen) aufeinander abbildbar (s.o.). Deshalb muss die Existenz dieser Transformationsfunktion im Folgenden vorausgesetzt werden. Darauf aufbauend deniert man für S' Sichten, die nach auÿen hin das Schema S zur Verfügung stellen (in Abb. 2.1 als S-Sichten bezeichnet), was allerdings nur möglich ist, wenn auch die Umkehrfunktion zu Trans existiert, weshalb dieses im Folgenden ebenfalls vorausgesetzt wird. Die ursprünglich auf dem Schema S denierten Sichten kann man dann unverändert übernehmen, da diese nun die S-Sichten auf S' verwenden. Dann erstellt man neue Indizes auf S', die den Indizes auf S entsprechen, und migriert die Integritätsbedingungen sowie die Daten (s.o.). Abbildung 2.1: Schema der strukturellen Migration Funktionale Migration Zum funktionalen Teil einer Datenbank zählt alles, was eine Interaktion der Anwendung bzw. der Anwender mit dem DBMS bzw. den gespeicherten Daten darstellt, wobei die Funktionen sowohl auf der Seite des Anwenders (z.b. in Datenbank-Befehlen innerhalb der Anwendung oder ad-hoc-anfragen der Anwender), als auch auf der Seite des DBMS (z.b. in gespeicherte Prozeduren) deniert sein können. Die funktionale Migration beinhaltet insbesondere die folgenden Aspekte: 5 Solche Schritte können beispielsweise Anwendungen der in [25] genannten Regeln sein. 27

40 2 Überblick zur Migration von Datenbanken innerhalb einer Anwendung denierte Datenbank-Befehle, Anfragen (z.b. DQL 6 : select) Daten-Manipulationen (z.b. DML 7 : insert, update,delete) Denitionen (z.b. DDL 8 : create, alter, drop) Steuerung (z.b. DCL 9 : grant, revoke) ad-hoc-befehle 10, gespeicherte Prozeduren (SPs), Trigger und benutzerdenierte Funktionen. Am Anfang dieses Kapitels wurde bereits festgestellt, dass ein allgemeiner Ansatz für die funktionale Migration bislang noch nicht vorgeschlagen wurde. Dies liegt an der unterschiedlichen Funktionalität, die von den einzelnen Datenbanksystemen zur Verfügung gestellt wird. Einige Teile wurden von ihnen gemäÿ des Standards implementiert und andere wurden hinzugefügt, modiziert oder ganz weggelassen. Deshalb sind in den bisherigen Ansätzen jeweils zwei konkrete Datenbanksysteme notwendig, um eine Beschreibung oder gar Anleitung für die Migration der Funktionen (bzw. der abbildbaren Anteile) zwischen beiden zu formulieren. Aus diesem Grund wird in diesem Abschnitt auf eine ausführliche Beschreibung der funktionalen Migration verzichtet und nur ein grober Überblick zu den Bestandteilen und dem Vorgehen bei der funktionalen Migration abgegeben. Stattdessen soll im nächsten Abschnitt ein Überblick über einige Unterschiede von verschiedenen Datenbankmanagementsystemen erstellt, der die Ursache für die hier genannten Probleme verdeutlichen soll. Im Kapitel 3 wird dann ein Teilproblem der funktionalen Migration genauer betrachtet, für das in dieser Arbeit ein allgemeiner Ansatz entwickelt werden soll. In Abbildung 2.2 wird das schematische Vorgehen bei der funktionalen Migration gezeigt. Für alle Objekte (fest denierte Anfragen, gespeicherte Prozeduren, usw.) der Datenbank müssen, unter Verwendung der Informationen über die Schema- Transformationsfunktion, entsprechende Objekte in der Zieldatenbank erzeugt werden, da es aufgrund der schon angesprochenen Vielzahl von Unterschieden zwischen 6 Data Query Language 7 Data Manipulation Language 8 Data Denition Language 9 Data Control Language 10 Ad-hoc-Befehle sind nicht im Programmcode einer Anwendung hinterlegt, sondern werden direkt von den Anwendern formuliert und in der Regel unmittelbar danach ausgeführt. Dabei kann es sich ebenfalls um Anfrage-, Manipulations-, Denitions- und Steuerungsanweisungen handeln. 28

41 2.2 DBMS-Unterschiede den existierenden Datenbankmanagementsystemen keine automatisierten Lösungen hierfür gibt. Zusätzlich muss im Falle eines DBMS-Wechsels auch auf fehlende oder zusätzliche Features und möglicherweise unterschiedliche Syntax geachtet werden. Die Migration von Anfragen wird später in dieser Arbeit behandelt, wobei die adhoc-anfragen bereits an dieser Stelle nicht weiter betrachtet werden, denn hierzu wäre eine Art von ad-hoc-migration nötig, welche deutlich komplexer ist als die ebenfalls noch nicht vollständig behandelte Migration von fest denierten Anfragen. Abbildung 2.2: Schema der funktionalen Migration 2.2 DBMS-Unterschiede Wie bereits angesprochen wurde, kann eine Datenbank unter Beibehaltung des bisherigen Datenbankmanagementsystems migriert werden oder es kann damit ein Wechsel des DBMS verbunden sein. Ändert sich das DBMS während der Migration nicht, so wird im Wesentlichen nur das Datenbankschema verändert und die übrigen Objekte müssen, wie oben erwähnt, daran angepasst werden. Erfolgt allerdings auch ein Wechsel des DBMS, so kommen weitere Probleme hinzu, die das Vorhaben zusätzlich noch weiter erschweren. Von einigen Datenbank-Herstellern wie IBM (DB2 ), Microsoft (SQL Server) und Oracle (Oracle9i) gibt es sogenannte Migrations-Anleitungen (engl. migration guides) für die Migration von Datenbanken anderer Hersteller zu ihrer Datenbank (siehe [12, 13, 15, 16]). Darin wird mehr oder weniger genau beschrieben, wie beispielsweise die strukturelle Migration durchzuführen ist, welche Datentypen dabei konvertiert werden müssen oder wie die vorhandenen Anfragen umzuformulieren sind. Im Folgenden werden hauptsächlich am Beispiel SQL Server 2000 und Oracle9i einige solche Konstrukte vorgestellt. Es werden nicht alle Unterschiede und Probleme angegeben, denn es soll hier lediglich ein Eindruck der Komplexität einer Migration zwischen zwei DBMS vermittelt werden. Da der Schwerpunkt dieser Diplomarbeit 29

42 2 Überblick zur Migration von Datenbanken in der Migration von Anfragen liegt, werden allerdings die Unterschiede hinsichtlich der Formulierung von Anfragen genauer betrachtet als die Unterschiede der übrigen Aspekte. Auÿerdem macht dieser Abschnitt deutlich, dass ein allgemeiner automatisierter Ansatz auf der Ebene der Datenbanksysteme nicht möglich ist, da jedes System einige Bestandteile besitzt, die andere Systeme nicht enthalten, und viele Bestandteile, die in anderen Systemen anders umgesetzt wurden (syntaktisch oder semantisch). Um einen allgemeinen Ansatz verfolgen zu können, braucht es daher eine höhere Ebene, auf der die Konzepte systemunabhängig formuliert werden können. Zusätzlich muss man, um die Allgemeinheit bewahren zu können, auf dieser Ebene Einschränkungen machen, durch die solche Konstrukte ausgeschlossen werden, die nicht in allen (oder zumindest in den meisten) Systemen repräsentiert werden können. Datentypen Datentypen lassen sich zum Teil direkt übernehmen oder können aufeinander abgebildet werden. Besonders problematisch sind allerdings Unterschiede, die sich auf die speicherbaren Werte beziehen. Bei der Migration vom SQL Server 2000 zu Oracle9i gibt es zum Beispiel ein Problem beim Wertebereich des numerischen Datentyps float. Es muss vor der Migration sichergestellt werden, dass in der zu migrierenden SQL Server-Datenbank keine float-werte auÿerhalb des von Oracle9i speicherbaren Bereichs - 1.0E bis 1.0E enthalten sind, weil dieser Datentyp beim SQL Server Werte im Bereich E bis 1.79E speichern kann. NULL-Werte SQL Server 2000 und Oracle9i haben zum Teil eine unterschiedliche Semantik von NULL-Werten. Der SQL Server wertet beispielsweise einen leeren String zu einem einzelnen Leerzeichen aus, Oracle9i hingegen zu NULL. Auÿerdem gibt es Unterschiede hinsichtlich der Sortierung von Anfrageergebnissen mithilfe der Order By-Klausel (s.u.). Funktionen Von jedem Datenbanksystem wird ein breites Spektrum an Funktionen angeboten. Werden solche Funktionen des Systems in der zu migrierenden Datenbank verwendet (z.b. in Anfragen), dann muss untersucht werden, ob und in welcher Form diese Funktionen ebenfalls im Zielsystem vorhanden sind. Möglicherweise heiÿt eine Funktion im Zielsystem anders oder es gibt Unterschiede bezüglich der Parameter (mehr/weniger, Reihenfolge). Im Folgenden werden für das Beispiel SQL Server 2000 zu Oracle9i einige Kategorien von Funktionen genannt und in Klammern dahinter 30

43 2.2 DBMS-Unterschiede wird jeweils eine problematische SQL Server-Funktion aus der Kategorie sowie deren Entsprechung in Oracle angegeben. Für Details wird auf [16] verwiesen. Kongurationsfunktionen (SQL Server: Oracle: nicht vorhanden) Cursor-Funktionen (SQL Server: Oracle: %rowcount) Aggregat-Funktionen (SQL Server: checksum, Oracle: nicht vorhanden) Datum- und Zeit-Funktionen (SQL Server month(d), Oracle: to_number(to_char(d,'mm'))) Mathematische Funktionen (SQL Server: rand, Oracle: nicht vorhanden) Sicherheitsfunktionen (SQL Server: alle, Oracle: nicht unterstützt) System-Funktionen (SQL Server: coalesce, Oracle: case) Zeichenketten-Funktionen (SQL Server: patindex, Oracle: nicht vorhanden) SET-Optionen (SQL Server: SET DATEFIRST, Oracle: NLS_TERRITORY ) Stored Procedures Nach [16] wird die Migration von gespeicherten Prozeduren zwischen dem SQL Server und Oracle9i vollständig von Oracles Migration Workbench 11 übernommen. Höchst wahrscheinlich handelt es sich dabei allerdings nur um den Prozedurrahmen, da es unklar bleibt, wie innerhalb des Prozedurrumpfes u.a. mit Funktionen (s.o.) oder Anfragen umgegangen wird. Denn wie in diesem Abschnitt deutlich wird, ist die Migration von Anfragen aufgrund einer Vielzahl von Problemen keineswegs automatisiert machbar (s.u.). In [13] werden folgende Probleme aufgezählt, die speziell für die Migration von gespeicherten Prozeduren gelten: 1. Maximale Anzahl der zulässigen Parameter 2. Maximale Schachtelungstiefe von verschachtelten gespeicherten Prozeduren 3. Zulässigkeit von Default-Werten für Parameter 4. Zulässigkeit von Wildcard-Zeichen (z.b. '%') in Parametern 5. Transaktionskontrolle und Fehlerbehandlung Auÿerdem sei noch einmal betont, dass gespeicherte Prozeduren auch Anfragen enthalten und dadurch sämtliche Probleme der Migration von Anfragen erben können. 11 Bei der Migration Worbench von Oracle handelt es sich um ein Tool, welches den Migrationsprozess von anderen Datenbanksystemen zu Oracle vereinfachen soll (vgl. [16]). 31

44 2 Überblick zur Migration von Datenbanken Trigger Trigger sollen im Falle der Migration zwischen dem SQL Server und Oracle9i ebenfalls vollständig von der Migration Workbench von Oracle migriert werden. Aber auch Trigger können Anfragen enthalten und erben somit deren Probleme bei der Migration. Allgemein kann die Migration von Triggern ohne einen automatisierten Ansatz sehr komplex werden, denn für die manuelle Migration von Triggern ist ein genaues Verständnis der dahinterliegenden Logik erforderlich. Aufgrund vieler vorhandener Trigger, die sich möglicherweise gegenseitig aufrufen, ist dieses Verständnis jedoch sehr schwer zu erlangen. Möglicherweise sind Trigger im Zielsystem insgesamt nicht vorhanden oder es gibt Einschränkungen, die es beim ursprünglichen DBMS nicht gibt. Oracle unterstützt beispielsweise BEFORE Trigger, der SQL Server allerdings nicht. In [15] wird für diesen Fall vorgeschlagen, das Problem mit INSTEAD OF Triggern zu lösen. Benutzerdenierte Funktionen Grundsätzlich enthalten benutzerdenierte Funktionen die gleichen Elemente wie gespeicherte Prozeduren, wodurch die dort genannten Probleme auch hier auftreten können. Kritisch sind allerdings die zulässigen Typen von benutzerdenierten Funktionen. SQL Server 2000 unterstützt drei Typen von benutzerdenierten Funktionen: Skalarfunktionen, Inlinefunktionen mit Tabellenrückgabe und aus mehreren Anweisungen bestehende Funktionen mit Tabellenrückgabe (vgl. [14]). Von diesen ist zu überprüfen, ob sie in Oracle ebenfalls umsetzbar sind. Anfragen Bei den Anfragen gibt es zahlreiche Unterschiede, die es in jedem Fall erforderlich machen, die bisherigen Anfragen bei einem Wechsel des DBMS anzupassen. Einige Probleme beschränken sich dabei auf rein syntaktische Unterschiede und sind somit leicht lösbar, die übrigen sind teilweise schwieriger oder möglicherweise gar nicht lösbar. Für die Migration der select-statements von Microsofts SQL Server- zu Oracles Oracle9i-Datenbank müssen dabei u.a. die folgenden Unterschiede beachtet werden (siehe [16]): 32 SELECT-Klausel Die Hauptprobleme bei der SELECT-Klausel sind die TOP n Unterklausel, die Spezikation von Spalten-Aliasen und die Verwendung der speziellen Spaltentypen IDENTITYCOL und ROWGUIDCOL. Top n Unterklausel

45 2.2 DBMS-Unterschiede Die Top n Unterklausel beschränkt das Ergebnis einer Anfrage auf n Zeilen oder Prozent. Diese Unterklausel muss aus den Anfragen entfernt werden und stattdessen müssen diese Anfragen um eine zusätzliche Where- Klausel erweitert werden, die das Ergebnis auf die gewünschte Zeilenanzahl beschränkt. Angabe von Spalten-Aliasen Ein Microsoft SQL Server Spalten-Alias kann mit der Syntax column_heading = column_name angegeben werden. Oracle unterstützt diese Syntax nicht, sondern nur die beiden Formen column_name column_heading und column_name as column_heading. Auÿerdem werden die Metadaten für Spalten-Aliase, die nicht in Anführungszeichen eingeschlossen sind, im Ergebnis einer Anfrage in Groÿschrift zurückgegeben. 12 Wenn im Programmcode der Anwendung Spalten-Aliase referenziert werden, dann müssen die Anfragen so modiziert werden, dass die Spalten-Aliase in Anführungszeichen eingeschlossen werden 13. IDENTITYCOL Referenzen auf IDENTITYCOL müssen entfernt werden und durch einen Oracle9i kompatiblen Ausdruck ersetzt werden. Die Migration Workbench von Oracle verwendet zur Generierung eindeutiger Spaltenwerte die Funktion OmwbEmulation.Identity. ROWGUIDCOL Referenzen auf ROWGUIDCOL müssen ebenfalls entfernt und durch die Funktion SY S_GU ID() ersetzt werden. INTO-Klausel Die INTO-Klausel, die beim SQL Server das dynamische Erzeugen von Tabellen und deren Befüllen mit dem Ergebnis der ausgeführten Anfragen ermöglicht, gibt es in Oracle9i nicht. Stattdessen muss die Anfrage zu einem CREATE TABLE... AS SELECT... transformiert werden. FROM-Klausel Fehlende FROM-Klausel Beim SQL Server ist die Angabe einer FROM Klausel nicht erforderlich, wenn die Auswahlliste nur aus Konstanten, Variablen und arithmetischen Ausdrücken (also nicht aus Spaltenreferenzen) besteht, z.b. SELECT 12 Z.B. gibt die Anfrage SELECT column1 Column1_Alias FROM table_source als Spaltennamen in den Metadaten den Wert COLUMN1_ALIAS zurück. 13 Z.B. SELECT column1 Column1_Alias FROM table_source 33

46 2 Überblick zur Migration von Datenbanken SELECT-Anfragen in Oracle9i erfordern allerdings immer die Angabe einer FROM Klausel, weshalb dort die Dummy-Tabelle DUAL angeboten wird, so dass Anfragen, die keine FROM Klausel enthalten, durch anhängen von FROM DUAL ausgeführt werden können, beispielsweise SELECT 3+5 FROM DUAL. Hints Sowohl SQL Server als auch Oracle9i erlauben Hints zur Beeinussung der Wahl des Ausführungsplans oder des Sperrverfahrens. Allerdings ist auch hierbei die Syntax vollkommen unterschiedlich. Alle Hints in SQL Server-Anfragen müssen entfernt werden, und evtl. anschlieÿend Oraclespezisch neu erstellt werden. Beispielsweise muss die Anfrage select title from titles with (HOLDLOCK) where pub_id > 800 zu select title from titles where pub_id > 800 FOR UPDATE OF NOWAIT umformuliert werden. Derived Table Alias Die Verwendung des Schlüsselwortes AS ist bei der Vergabe eines Alias für eine abgeleitete Tabelle nicht zulässig, deshalb muss es aus den FROM Klauseln entfernt werden. WHERE-Klausel Suchbedingungen NOT Operator vor einem Ausdruck Der SQL Server erlaubt die Verwendung des NOT Operators in Suchbedingungen direkt nach dem WHERE und vor einem Prädikat oder einer Suchbedingung. Für Oracle9i müssen diese Anweisungen so umformuliert werden, dass direkt hinter dem WHERE kein NOT vorkommt und dass stattdessen die folgende Suchbedingung negiert wird. Beispielsweise müsste die Anfrage select title from titles where NOT pub_id > 800 zu

47 2.2 DBMS-Unterschiede select title from titles where pub_id <= 800 umformuliert werden. LIKE-Operator Der LIKE Operator des SQL Server unterstützt eine begrenzte Teilmenge der Syntax von regulären Ausdrücken. Er beinhaltet den Wertebereichsoperator ([]) und den not character Operator( ). Beide werden von Oracle9i nicht unterstützt. Deshalb müssen Vergleiche, die diese Operatoren verwenden, umformuliert werden, so dass sie stattdessen die Oracle9i -Funktion substr verwenden. CONTAINS- und FREETEXT-Klauseln In Suchbedingungen des SQL Server können die CONTAINS- und FREETEXT-Klauseln verwendet werden, die das Durchsuchen von Spalten mit zeichenbasierten Datentypen ermöglichen, um präzise oder weniger genaue (fuzzy) Treer von einzelnen Wörtern und Ausdrücken zu erhalten, Wortverwandtschaften innerhalb bestimmter Grenzen festzustellen oder gewichtete Treer zu erzielen. Suchbedingungen, die diese Klauseln enthalten, müssen für die Verwendung in Orale9i so umformuliert werden, dass sie das Tool Oracle Text einsetzen. Outer Joins Beim SQL Server kann der Operator = für die Formulierung eines left outer join verwendet werden, und der Operator = für die Formulierung eines right outer join. Da diese Syntax von Oracle9i nicht unterstützt wird, müssen Anfragen, die diese Syntax verwenden, in Oracle9i-Syntax umformuliert werden. Beispielsweise muss die Anfrage select distinct (DNAME) from EMP e, DEPT d where e.deptno =* d.deptno zu select distinct (DNAME) from EMP E right outer join DEPT D on E.DEPTNO = D.DEPTNO umformuliert werden. GROUP BY-Klausel ALL 35

48 2 Überblick zur Migration von Datenbanken Anfragen, die das Schlüsselwort ALL in der GROUP BY Klausel enthalten, müssen umformuliert werden, damit sie der Oracle9i Syntax entsprechen. GROUP BY-Ausdruck Beim SQL Server können GROUP BY-Ausdrücke zur Erzeugung von Gruppierungen angegeben werden, ohne dass in der Auswahlliste eine Aggregatfunktion angewendet wird. In Oracle9i ist dies nicht zulässig, wodurch auch diese Anfragen modiziert werden müssen. Super-Aggregate Die Syntax für die Angabe des CUBE oder ROLLUP Operators unterscheidet sich ebenfalls zwischen den beiden System. Die SQL Server- Syntax 14 hierfür ist [ GROUP BY group_by_expression [ WITH { CUBE ROLLUP } ]] und die Oracle9i Syntax lautet GROUP BY [ ROLLUP CUBE ] group_by_expression Auch hier ist also eine Umformulierung der Anfragen notwendig. HAVING-Klausel Keine GROUP BY-Klausel Der SQL Server lässt Anfragen zu, welche die HAVING-Klausel ohne eine GROUP BY-Klausel verwenden. In Oracle9i ist muss für die Verwendung der HAVING-Klausel eine GROUP BY-Klausel in der Anfrage vorhanden sein. Suchbedingungen Hierbei gibt es die gleichen Unterschiede wie bei den Suchbedingungen in der WHERE-Klausel (s.o.). UNION Spaltendatentypen Die entsprechenden Ausdrücke in den Auswahllisten der Komponenten- Anfragen einer zusammengesetzten Anfrage müssen passende Datentypen besitzen. Oracle9i castet die Datentypen implizit anders als der SQL Server. Hierzu muss die Kompatibilität der Datentypen genauer betrachtet werden (s.o.). 14 Dies ist jeweils nicht die vollständige Syntax der GROUP BY-Klausel! 36

49 2.2 DBMS-Unterschiede ORDER BY-Klausel NULL-Werte Der SQL Server behandelt NULL als den kleinsten möglichen Wert (also kommen die NULL-Werte bei einer aufsteigenden Sortierung immer zuerst). Oracle9i behandelt NULL hingegen als den gröÿten möglichen Wert (also kommen die NULL-Werte bei einer absteigenden Sortierung immer zuerst). Folglich müssen Anfragen, die eine ORDER BY-Klausel enthalten und auf NULL-Daten angewendet werden, an die unterschiedliche NULL-Behandlung angepasst werden (Verwendung von NULLS FIRST bzw. NULLS LAST). COMPUTE-Klausel Die COMPUTE-Klausel des SQL Server wird von Oracle9i nicht unterstützt. Anfragen, welche die COMPUTE-Klausel verwenden, müssen zu einer zusammengesetzten Anfrage (unter Verwendung des UNION-Operators) umformuliert werden. FOR-Klausel Mit ihrer Hilfe ist die Generierung von XML-Daten möglich. Oracle9i unterstützt die Generierung von XML-Daten ebenfalls, allerdings müssen auch dafür die Anfragen angepasst werden. OPTION-Klausel Die OPTION-Klausel, die das Angeben von Hints für die gesamte Anfrage ermöglichen, werden in Oracle9i nicht unterstützt. Deshalb müssen alle OPTION-Klauseln entfernt werden und ggf. neue Hints in Oracle9i-Syntax erstellt werden. 37

50 2 Überblick zur Migration von Datenbanken 2.3 Ein Beispiel Wie zu Anfang dieses Kapitels bereits erwähnt wurde, soll nun zum Abschluss des Überblicks zur Datenbankmigration ein Beispiel vorgestellt werden, mit dessen Hilfe einige der hier vorgestellten Verfahren veranschaulicht werden können Herkunft / Hintergrund Dem nun folgenden Beispiel liegt eine reale Anwendung aus der Praxis zugrunde, nämlich ein Warenwirtschaftssystem mit integrierten PPS 15 -Modulen. Der in dieser Arbeit untersuchte Teil der zugehörigen Datenbank 16 beschränkt sich auf einen kleinen Teil des Produktionsbereichs der Anwendung und wurde für die Verwendung in dieser Arbeit aufbereitet, d.h. auf die wesentlichen Bestandteile reduziert, um eine gewisse Überschaubarkeit für den Betrachter zu erzielen. Es läÿt sich allerdings nicht verhindern, dass diese Vereinfachung bereits die Ergebnisse verfälscht, da normalerweise genau die Komplexität und die Unübersichtlichkeit des Schemas die Herausforderung sowie die Schwierigkeit der Migration ausmacht und sich auch auf die Anfragen auswirkt. Einige der festgestellten Probleme innerhalb des Datenbankschemas und der Anfragen fallen durch diese Vereinfachung somit bereits weg, aber es bleiben auch noch einige übrig, die das Prinzip und das Konzept der Vorgehensweisen durchaus veranschaulichen. Da es sich bei der untersuchten Anwendung um einen industriellen Ursprung handelt, kann sie als Beispiel in dieser Diplomarbeit nicht verwendet werden. Stattdessen wird auf ein möglichst analoges Beispiel zurückgegrien, auf das die Probleme und Vorgehensweisen gröÿtenteils übertragen werden können und das somit als Platzhalter für die ursprüngliche Anwendung dienen soll. Es handelt sich bei diesem Beispiel um die Produktion bzw. die Herstellung von Wein. Aufgrund der Tatsache, dass sich die untersuchte Anwendung nicht exakt auf die Herstellung von Wein abbilden läÿt, und die exakte Darstellung derselben nicht das Ziel dieser Arbeit bildet, mögen es die Kenner der Weinherstellung verzeihen, wenn manches Detail nicht präzise wiedergegeben oder vor dem Hintergrund der ursprünglichen Anwendung etwas zweckentfremdet wurde Produktionsplanung und -Steuerung 16 Bei der untersuchten Beispielanwendung handelt es sich um eine Microsoft SQL Server Datenbank. 17 Ausführliche Informationen zum Thema Wein und dessen Herstellung werden beispielsweise in 38 [30] angeboten.

51 2.3 Ein Beispiel Das Datenbankschema In Abbildung 2.3 ist das konzeptionelle Schema des Beispiels im ER-Modell 18 angegeben. Darin ist grob der Weg von geernteten Trauben bis zum fertigen Wein erkennbar: Die geernteten Trauben werden zunächst in einem Sammellager aufbewahrt, bis sie für einen ersten Verarbeitungsvorgang entnommen werden. Dieser Vorgang ist möglicherweise in mehrere Vorgangsschritte aufgeteilt und wird mithilfe einer Maschine ausgeführt. Die einzelnen Schritte erzeugen dann Zwischenprodukte (Artikel), die wiederum gelagert werden. Dann folgen normalerweise weitere Vorgänge, die einem Lager die jeweiligen Zwischenprodukte entnehmen und daraus neue erzeugen. Diese Schleife ist in dem vorliegenden Teil des Datenbankschemas allerdings nicht vollständig ausmodelliert, da hier im Wesentlichen nur die Trauben und der fertige Wein relevant sind. In einem letzten Vorgang bzw. Vorgangsschritt wird dann der fertige, in Flaschen abgefüllte Wein in Kartons verpackt, die dann ebenfalls zunächst in einem Lager abgestellt werden. Wie bereits erwähnt wurde, sind zur Verbesserung der Übersichtlichkeit nur einige der Typen und Attribute ins Schema aufgenommen worden und so sind beispielsweise Informationen über die Anbaugebiete (Weinberg, Lage, Winzer), also über die Herkunft der Trauben, sowie detaillierte Eigenschaften (Attribute) der Trauben oder Weine in diesem Teil-Schema nicht enthalten. Eine ausführlichere Dokumentation dieses Beispiels bendet sich in Anhang B. Sie enthält kurze Beschreibungen zu den einzelnen Entity- und Relationship-Typen sowie eine Abbildung des Schemas im relationalen Datenmodell 19 (RDM) Reengineering des Schemas In Abschnitt wurde bereits festgestellt, dass zur Migration des Datenbankschemas meistens auch ein Reengineering gehört, das normalerweise die Erstellung eines konzeptionellen Schemas aus dem logischen Schema beinhaltet. Das in Abbildung 2.3 gezeigte Schema ist bereits das Ergebnis dieser Reengineering-Phase, und es werden nun nachträglich einige der durchgeführten Reengineering-Maÿnahmen erläutert. Das Modellierungs-Problem Karton Artikel In Abbildung 2.3 beschreibt die Beziehung KartonInhalt das Verhältnis von Kartons und Artikeln. Danach kann ein Karton kann 0-N Artikel enthalten, also beliebig viele oder keine Artikel enthalten, d.h. es sind auch verschiedene Weine in einem 18 Eine Erklärung der verwendeten Notationen für das ER-Modell bendet sich in Anhang A. Zur Erstellung der ER-Modelle in dieser Arbeit wurde das Modellierungstool DB-Main verwendet. 19 Die Abbildungen der relationalen Datenbankschemata in dieser Arbeit wurden mit dem Datenbankdiagramm-Editor des SQL Server 2000 von Microsoft erstellt. 39

52 2 Überblick zur Migration von Datenbanken Abbildung 2.3: Konzeptionelles Schema des Weinherstellungsbeispiels 40

53 2.3 Ein Beispiel Karton möglich. Der Fall von keinem enthaltenen Artikel, also einem leeren Karton, tritt nur dann ein, wenn einem Karton der Inhalt aus irgendeinem Grund wieder entnommen wird. 20 Im ursprünglichen Schema 21 gab es zwei Beziehungen, die diese Möglichkeiten repräsentiert haben, was damit zu begründen ist, dass zunächst nicht die Notwendigkeit bestanden hat, verschiedene Weine in einen Karton zu verpacken, und dass diese Möglichkeit erst nachträglich hinzugefügt wurde. In Abbildung 2.4 werden diese beiden Beziehungen gezeigt. Wie eben beschrieben wurde, handelt es sich dabei um Alternativen, d.h. ein Karton nimmt an genau einer der beiden Beziehungen zum Artikel teil, was durch eine externe Integritätsbedingung sichergestellt wird. 22 Abbildung 2.4: Modellierungs-Problem Karton Artikel im Altsystem (ERM) Im konzeptionellen Schema (Abb. 2.4) sieht man sofort, dass es dort ein Problem gibt 23, im relationalen Modell (Abb. 2.5) war dies jedoch nicht so oensichtlich zu erkennen, da dort aufgrund der Kardinalität 0-1 sämtliche Attribute der Beziehung KartonInhalt-einArtikel in den Relationstyp Karton eingebettet wurden und fehlende Dokumentation das Verständnis ihrer Bedeutung erschwerte. Auÿerdem sieht man in Abbildung 2.4, dass aufgrund der Kardinalität 0-N der Beziehung KartonInhalt-mehrereArtikel auch der Fall von nur einem Artikel im Karton über diese Relation abgebildet werden kann. Dies wird seit Einführung dieser Beziehung auch so umgesetzt, aber den Aufwand zur Anpassung der bereits vorhandenen 20 Es werden nicht alle leeren Kartons modelliert, sondern nur die, welche mal Artikel enthielten, die aber später wieder entnommen wurden (z.b. wenn eine Flasche zerbricht). In einem solchen Fall kann somit nachvollzogen werden, was aus dem Karton sowie dessen Inhalt geworden ist. 21 Das ursprüngliche Schema bezeichnet das Schema, so wie es zu Beginn des Reengineerings (im relationalen Datenmodell) vorgefunden wurde. 22 Hier ist die eben genannte (O-N)-Kardinalität auch dafür erforderlich, die Alternativen ausdrücken zu können. 23 Aus diesem Grund wählt man für Reengineering-Maÿnahmen die konzeptionelle Ebene. 41

54 2 Überblick zur Migration von Datenbanken Abbildung 2.5: Modellierungs-Problem Karton Artikel (RDM) Daten und Anfragen (denn dies bedeutet ein Reengineering des Anwendungscodes) wollte man nicht eingehen. Deshalb die Beziehung KartonInhalt-einArtikel im Rahmen des Reengineerings entfernt 24 (siehe Abb. 2.3 und 2.6). Abbildung 2.6: Lösung des Modellierungs-Problems Karton Artikel (RDM) Zusätzlich gab es in der ursprünglichen Modellierung dieses Ausschnitts der Datenbank noch ein Kennzeichen 25, welches signalisierte, ob ein Karton mehrere Artikel enthält, also ob die neue oder die alte Beziehung zu Artikel verwendet wird. 26 Da die alte Beziehung entfernt wurde und es zukünftig nur noch eine Möglichkeit gibt, wird dieses ebenfalls nicht mehr benötigt und deshalb entfernt. 24 Durch das Entfernen der Beziehung ist dann allerdings eine Transformation der vorhandenen Daten, welche sie auf die verbleibende Beziehung abbildet, sowie eine Anpassung der vorhandenen Anfragen erforderlich. 25 In diesem Fall ein Attribut mit zwei möglichen Werten: 'ja' oder 'nein', bzw. 1 oder Das Kennzeichen wurde nur in Anfragen verwendet, welche die neue Beziehung genutzt haben, weil die Anpassung der alten Anfragen bezüglich dieses Kennzeichens den gleichen Aufwand bedeutet hätte wie das Umstellen auf die neue Beziehung (s.o.). 42

55 2.3 Ein Beispiel Konsequenzen für die betroenen Anfragen Sobald das Datenbankschema während des Migrationsprozesses verändert wird (z.b. in der Reengineering-Phase), müssen die davon betroenen Anfragen an diese Änderungen angepasst werden. Die hierfür vorhandenen Lösungsansätze werden nun einmal an diesem Beispiel veranschaulicht. Die in Abbildung 2.7 angegebene Anfrage bezieht sich auf das ursprüngliche Schema, dargestellt in Abbildung 2.5, und ist typischer Bestandteil von Anfragen, die z.b. in einer Lager- oder Bestandsübersicht eingesetzt werden. SELECT K.Ident, K.Groesse, K.Status, K.PackDatum, Artikel = CASE WHEN K.MehrereArtikel = 1 THEN KI.Artikel_Ident ELSE K.Artikel_Ident END, Stueck = CASE WHEN K.MehrereArtikel = 1 THEN KI.Stueck ELSE K.Stueck END FROM Karton K LEFT OUTER JOIN KartonInhalt KI ON K.Ident = KI.Karton_Ident Abbildung 2.7: Eine Anfrage an das ursprüngliche Schema Im Normalfall ist bei einer solchen Anfrage natürlich nicht nur der Primärschlüssel der Artikel interessant, sondern auch deren übrige Eigenschaften oder zumindest deren Bezeichnung. In einem solchen Fall muss der Verbund zwischen Karton bzw. KartonInhalt und Artikel wie bei dieser Anfrage über den mittels Fallunterscheidung (CASE-Funktion) erhaltenen Primärschlüssel hergestellt werden, wodurch die Anfrage schnell unübersichtlich und unverständlich wird. Die in Abbildung 2.8 gezeigte Anfrage ermittelt dieselben Informationen wie die vorherige, aber sie bezieht sich auf das angepasste Schema (siehe Abbildung 2.3). Man sieht sofort, wie sich die eben betrachtete Komplikation aufgelöst hat, und auch der zusätzliche Verbund zu Artikel würde nicht mehr die geschilderte Schwierigkeit darstellen. Aufgrund der durchgeführten Schema-Änderung ist es somit möglich, zukünftig einfachere Anfragen zu formulieren. Problematisch an der Änderung ist allerdings, dass man auch die bereits formulierten Anfragen 27 anpassen muss. Wie in Abschnitt 27 In Sichtendenitionen, in gespeicherten Prozeduren, im Programmcode,... 43

56 2 Überblick zur Migration von Datenbanken SELECT K.Ident, K.Groesse, K.Status, K.PackDatum, KI.Artikel_Ident, KI.Stueck FROM Karton_neu K LEFT OUTER JOIN KartonInhalt_neu KI ON K.Ident = KI.Karton_Ident Abbildung 2.8: Die Anfrage zum neuen Schema bereits festgestellt wurde, kann man solche Anpassungen normalerweise durch die Denition von Sichten umgehen: Damit die vorhandenen Anfragen lauähig bleiben, müssen für die veränderten Tabellen Sichten erstellt werden, welche die Daten der ursprünglichen Tabellen liefern und wie die ursprünglichen Tabellen benannt sind. Auf diese Weise verwenden die betroenen Anfragen dann nicht mehr die Tabellen Karton und KartonInhalt, sondern die gleichnamigen Sichten. Dabei muss allerdings beachtet werden, dass die neuen Tabellen zur Vermeidung von Namenskonikten anders benannt werden müssen, was ein groÿer Nachteil dieses Verfahrens ist. Der Einfachheit halber werden die neuen Tabellen im folgenden Beispiel als Karton_neu und KartonInhalt_neu bezeichnet (siehe Abb. 2.6). In den Abbildungen 2.9 und 2.10 sind die Denitionen der für das Beispiel benötigten Sichten angegeben, so dass unter Verwendung dieser Sichten auch die ursprüngliche Anfrage (siehe Abb. 2.7) auf dem neuen Schema lauähig ist. Durch diese Vorgehensweise reduziert man zwar die Anpassungsarbeit vieler Anfragen, die gröÿtenteils im Programmcode der Anwendung enthalten sind, auf die Erstellung (meistens) weniger Sichten, aber man handelt sich dadurch auch die folgenden Nachteile ein: 1. die neuen Objekte müssen umbenannt werden (s.o.), 2. die vorhandenen Anfragen nutzen die Schema-Änderungen nicht und bleiben dadurch unverständlich und 3. die zusätzlichen Sichten müssen zukünftig gepegt sowie gewartet werden. Deshalb kann man die explizite Denition dieser Sichten auch dadurch umgehen, dass man die Tabellen in der Anfrage durch die entsprechenden sichtendenierenden Anfragen substituiert, wodurch man jedoch den Vorteil verliert, nicht den Code der Anwendung anpassen zu müssen. In der obigen Anfrage auf dem neuen Schema (Abb. 2.8) muss also überall dort, wo bisher der Name Karton oder KartonInhalt steht, jeweils die denierende Anfrage der entsprechenden Sicht eingesetzt werden (siehe Abbildung 2.11), wodurch die Anfrage deutlich unübersichtlicher wird. 44

57 2.3 Ein Beispiel CREATE VIEW Karton AS SELECT K.*, Artikel = CASE WHEN(SELECT COUNT(*) FROM KartonInhalt_neu KI WHERE KI.Karton_Ident = K.Ident) = 1 THEN (SELECT Artikel_Ident FROM KartonInhalt_neu KI WHERE KI.Karton_Ident = K.Ident) ELSE NULL END, Stueck = CASE WHEN(SELECT COUNT(*) FROM KartonInhalt_neu KI WHERE KI.Karton_Ident = K.Ident) = 1 THEN (SELECT Stueck FROM KartonInhalt_neu KI WHERE KI.Karton_Ident = K.Ident) ELSE NULL END, MehrereArtikel = CASE WHEN(SELECT COUNT(*) FROM KartonInhalt_neu KI WHERE KI.Karton_Ident = K.Ident) > 1 THEN 1 ELSE 0 END FROM Karton_neu K Abbildung 2.9: Denition der Tabelle Karton als Sicht auf dem neuen Schema CREATE VIEW KartonInhalt AS SELECT * FROM KartonInhalt_neu WHERE Karton_Ident in (SELECT Karton_Ident FROM KartonInhalt_neu GROUP BY Karton_Ident HAVING COUNT(*)>1) Abbildung 2.10: Denition der Tabelle KartonInhalt als Sicht auf dem neuen Schema 45

58 2 Überblick zur Migration von Datenbanken 46 SELECT K.Ident, K.Groesse, K.Status, K.PackDatum, Artikel = CASE WHEN K.MehrereArtikel = 1 THEN KI.Artikel_Ident ELSE K.Artikel END, Stueck = CASE WHEN K.MehrereArtikel = 1 THEN KI.Stueck ELSE K.Stueck END FROM (SELECT Karton_neu.*, Artikel = CASE WHEN (SELECT COUNT(*) FROM KartonInhalt_neu KI WHERE KI.Karton_Ident = Karton_neu.Ident) = 1 THEN (SELECT Artikel_Ident FROM KartonInhalt_neu KI WHERE KI.Karton_Ident = Karton_neu.Ident) ELSE NULL END, Stueck = CASE WHEN(SELECT COUNT(*) FROM KartonInhalt_neu KI WHERE KI.Karton_Ident = Karton_neu.Ident) = 1 THEN (SELECT Stueck FROM KartonInhalt_neu KI WHERE KI.Karton_Ident = Karton_neu.Ident) ELSE NULL END, MehrereArtikel = CASE WHEN(SELECT COUNT(*) FROM KartonInhalt_neu KI WHERE KI.Karton_Ident = Karton_neu.Ident) > 1 THEN 1 ELSE 0 END FROM Karton_neu) K LEFT OUTER JOIN ( SELECT * FROM KartonInhalt_neu WHERE Karton_Ident in (SELECT Karton_Ident FROM KartonInhalt_neu GROUP BY Karton_Ident HAVING COUNT(*)>1)) KI ON K.Ident = KI.Karton_Ident Abbildung 2.11: Anfrage mit eingesetzten Sichten-Denitionen

59 3 Anfragen bei der funktionalen Migration Die Migration von Anfragen ist ein Teilproblem der Migration von Informationssystemen (bzw. deren Datenbanken) und Bestandteil der funktionalen Migration (siehe Kapitel 2). Anfragen können innerhalb des Programmcodes einer Informationssystemanwendung fest deniert sein (evtl. parametrisiert) oder innerhalb der Datenbank in Form von Sichten, gespeicherten Prozeduren, benutzerdenierten Funktionen usw. verwendet werden. In dieser Diplomarbeit wird zunächst nur die Migration der Anfragen betrachtet, die innerhalb der zu migrierenden Anwendung deniert sind. Später wird dann kurz diskutiert, inwiefern das in dieser Arbeit entwickelte Verfahren auf die übrigen Anfragen in den komplexeren Objekten erweitert werden kann (siehe Kapitel 7). 3.1 Das bisherige Vorgehen bei der Migration von Anfragen Die einfache Migration solcher Anfragen besteht bislang darin, aus der Transformationsfunktion, die das alte Datenschema auf das neue abbildet, Sichtendenitionen für das neue Schema abzuleiten, die nach auÿen das alte Schema zur Verfügung stellen. Dieses Verfahren wurde schon im Abschnitt vorgestellt, da auf diese Weise die auf dem ursprünglichen Datenschema denierten Sichten migriert werden können 1, und es wurde in Abschnitt einmal anhand einer Beispielanfrage veranschaulicht. Alternativ zu der Denition neuer Sichten kann man die Informationen über die Transformationsfunktion auch direkt in die Anfragen einsetzen, so dass die Sichten selbst nicht notwendig sind (siehe Beispiel in Abschnitt 2.3.4). In beiden Fällen erreicht man, dass Anfragen auf dem alten Schema auch auf dem neuen Schema lauähig sind, wobei allerdings vorausgesetzt werden muss, dass die Anfragen nur Konstrukte verwenden, die in beiden Systemen verfügbar sind und in beiden Systemen gleich formuliert werden 2. Ist diese Voraussetzung nicht erfüllt, so müssen die Anfragen dennoch (manuell) angepasst werden. 1 Dort wurden die zu erstellenden Sichten als S-Sichten auf dem neuen Schema S' bezeichnet. 2 Beispiele für mögliche Unterschiede wurden in Abschnitt 2.2 angegeben 47

60 3 Anfragen bei der funktionalen Migration 3.2 Bewertung des bisherigen Vorgehens Das Ziel der Denition zusätzlicher Sichten besteht darin, die Anwendung bzw. deren Programmcode unverändert lassen zu können. Allerdings lösen die Sichten (virtuell oder materialisiert) das Problem nicht vollständig, denn sie bringen nicht nur einen möglichen Performanz-Verlust und zusätzlichen Wartungsaufwand mit sich, sondern sie erschweren auch das Verständnis der Anfragen. Denn wie man bereits am Beispiel (Abschnitt 2.3.4) sehen konnte, passen die Anfragen nicht mehr direkt zum Datenschema, sondern nur noch zu den darüberliegenden Sichten, die zum Verständnis der Anfragen nun ebenfalls verstanden werden müssen, was je nach durchgeführter Schema-Änderung keineswegs trivial sein muss. Erzeugt man die Sichten nicht explizit, sondern setzt deren Denitionen in die Anfragen ein, so verliert man den Vorteil, den Anwendungscode unangetastet lassen zu können. Die Anfragen werden dann komplexer als sie vielleicht bisher schon waren, aber man hat zumindest den Vorteil, dass man die Anfrage direkt neben das Schema legen kann und nicht zusätzlich noch die besagten Sichten dazwischen legen muss. Bei beiden Vorgehensweisen bleibt allerdings der groÿe Nachteil, dass man die eigentlichen Vorteile des aufbereiteten Datenschemas nicht für die bestehenden Anfragen ausnutzt. Wie man im Beispiel (siehe Abschnitt 2.3.4) sehen kann, ist die resultierende Anfrage weit entfernt von der übersichtlichen Struktur der von Hand neu erstellten Anfrage. Zusätzlich muss man bei diesen beiden Vorgehensweisen davon ausgehen, dass den zu migrierenden Anfragen korrekte und optimale Anfragen zugrunde liegen, was jedoch in der Praxis oft nicht der Fall ist. Man kann beobachten, wie Anfragen innerhalb einer Anwendung mit der Zeit wachsen, um zusätzliche oder modizierte Informationen zu liefern. Unter Umständen gibt es Korrekturen, die nachträglich lokal von jemandem durchgeführt werden, der die Anfrage bis dahin nicht kannte und ihre Gesamtfunktionalität auch zum Zeitpunkt der Korrektur noch nicht kennt. Es ist wahrscheinlich, dass die gesamte Anfrage anschlieÿend (strukturell) vereinfacht oder hinsichtlich besserer Performanz/Ezienz optimiert werden kann. Möglicherweise war die ursprüngliche Anfrage für das bisherige DBS auch korrekt und optimal formuliert, aber durch die Migration zu einem neueren DBS kann die Anfrage nun doch noch verbessert werden. Insgesamt wird der Anspruch, den man an die Anfragen hat, durch die bisherigen Vorgehensweisen nicht erfüllt, denn oft genügen sie einigen oder sogar vielen der im folgenden Abschnitt aufgeführten Qualitätskriterien nicht. Es handelt sich um brute force-lösungen, die darauf abzielen, mit minimalem Aufwand ein lauähiges neues System zu erstellen. 48

61 3.3 Qualitätskriterien für migrierte Anfragen 3.3 Qualitätskriterien für migrierte Anfragen Nicht nur bei der Migration von Anfragen, sondern auch bei der Formulierung von Anfragen im Allgemeinen spielen gewisse Qualitätskriterien eine bedeutende Rolle. Qualitativ bessere Anfragen lassen sich zweifellos einfacher migrieren (besonders, wenn mit qualitativ besser auch die Verständlichkeit gemeint ist), aber höchstwahrscheinlich ndet man nur wenige dieser guten Anfragen vor, denn genau das ist einer der Gründe dafür, ein System zu migrieren. Das Ziel der Migration besteht darin, im Zielsystem möglichst gute Anfragen zu verwenden, d.h. es müssen innerhalb der Migration auch die schlechten Anfragen verbessert werden, wobei gut und qualitativ auf bestimmte Qualitätskriterien bezogen ist, von denen nun einige aufgezählt werden: Funktionalität Richtigkeit / Genauigkeit (Praxis-) Tauglichkeit Kompatibilität / Zusammenarbeitsfähigkeit Robustheit Flexibilität / Anpassungsfähigkeit in sich geschlossen / Unabhängigkeit Vertrauenswürdigkeit / Zuverlässigkeit Reife Fehlertoleranz Erhaltung der Zuverlässigkeit Verwendbarkeit Verständlichkeit Lernbarkeit Durchführbarkeit Attraktivität / Reiz Angemessenheit / Eignung Verfügbarkeit Erhaltung der Verwendbarkeit Ezienz 49

62 3 Anfragen bei der funktionalen Migration Zeitverlauf Verwendung / Ausnutzung der Ressourcen Ehaltung der Ezienz Wartungsfähigkeit Analysierbarkeit Veränderlichkeit Dauerhaftigkeit Testmöglichkeit Erhaltung der Wartungsfähigkeit Übertragbarkeit / Portabilität Anpassungsfähigkeit Installierbarkeit Koexistenz / Ersetzbarkeit Einsetzbarkeit Erhaltung der Portabilität Wiederverwendbarkeit Man hat also mit der bisherigen Vorgehensweise die Komplexität der Anwendung nicht im Gri, denn selbst wenn man mithilfe der beschriebenen Verfahren ein lauähiges migriertes System erreicht, so ist dennoch die Erfüllung der genannten Qualitätskriterien nicht gesichert. Insbesondere die Korrektheit, Ezienz und Wartungsfähigkeit möchte man schlieÿlich erreichen, da beispielsweise das Kriterium Wartungsfähigkeit auch ein wesentlicher Grund dafür ist, die Migration überhaupt durchzuführen. Das angestrebte Ergebnis ist ein verständlicheres System, aber durch die bisherige Vorgehensweise erreicht man möglicherweise sogar das Gegenteil. 3.4 Anforderungen an eine neue Strategie Die Lauähigkeit der Anfragen auf dem neuen Datenbanksystem ist nicht das einzige Ziel, sondern es besteht auÿerdem der Wunsch, die Komplexität des Zielsystems im Gri zu haben. Die Anwendung soll also während der Migration so in Ordnung gebracht werden, dass anschlieÿend die Anfragen in Bezug auf die genannten Qualitätskriterien (möglichst) optimal sind. Hierfür werden jedoch neue Mechanismen benötigt, mit denen die Anwendung daraufhin untersucht und bewertet werden 50

63 3.5 Mögliche Lösungsstrategien kann. Insbesondere das Verständnis, das Aufdecken potentieller Problemstellen und die darauf folgende Anpassung komplexer Anfragen muss vereinfacht werden. Wie in Abschnitt beschrieben wurde, so wird ein ähnlicher Wunsch auch bereits bei der Migration des Datenschemas verfolgt, denn auch das Datenschema wächst mit der Zeit und ist in der Regel unstrukturiert, unverständlich und fehlerbehaftet. Dort will man sich ebenfalls nicht mit einer 1:1-Migration und reiner Lauähigkeit zufrieden geben, sondern im Verlauf der Migration auch ein gewisses Maÿ an Reengineering betreiben. 3.5 Mögliche Lösungsstrategien Eine automatisierte Lösung des geschilderten Problems ist derzeit nicht denkbar, und es ist in jedem Fall Handarbeit nötig, um das angestrebte Ziel zu erreichen. Zu untersuchen bleibt allerdings, inwieweit der Benutzer dabei möglicherweise technisch unterstützt werden kann. 3 Zur Lösung des beschriebenen Problems und zur Erfüllung der eben genannten Wünsche gibt es folgende Möglichkeiten: 1. manuelles Editieren der textuellen Anfragen 2. manuelles Editieren der Anfragen mithilfe visueller Mechanismen Das manuelle Editieren beinhaltet eine Untersuchung der Anfragen in Hinblick auf die genannten Kriterien. Hierfür können dann sowohl die durch das beschriebene Vorgehen entstandenen Anfragen verwendet werden, als auch die ursprünglichen und unveränderten Anfragen, so wie sie in der geerbten Anwendung deniert sind. Dabei ist das vollständige Verständnis des Schemas und der daran durchgeführten Änderungen sowie der Anfragen selbst eine unumgängliche Voraussetzung, da andernfalls Kriterien, wie beispielsweise die Korrektheit der Anfragen, nicht erfüllt werden können. Die Komplexität von möglicherweise mehreren Seiten (SQL-) Code erschwert das Erreichen dieser Voraussetzung beachtlich und stellt wahrscheinlich die gröÿte Hürde dieses Ansatzes dar. Hinzu kommt auÿerdem die Tatsache, dass man während der Analyse und der Anpassungen die Besonderheiten mehrerer SQL- Dialekte (zumindest zwei Dialekte: Quell- und Ziel-DBMS) beachten muÿ. Der zweite Lösungsansatz zielt darauf ab, die Schwierigkeiten des eben beschriebenen Ansatzes zur reduzieren. Durch die Schaung einer konzeptionellen Ebene für Anfragen (nach Vorbild des ER-Modells für Datenbankschemata) und der damit 3 Das bereits mehrfach angesprochene Aufbereiten des Datenschemas während der Schema- Migration kann ebenfalls nicht ohne Handarbeit durchgeführt werden, und auch hier ist man zunächst nur darum bemüht, dem Benutzer die Arbeit, und insbesondere das Verständnis, zu erleichtern. Lediglich eine brute-force-variante der 1:1-Schema-Migration ist automatisiert machbar. 51

64 3 Anfragen bei der funktionalen Migration verbundenen Möglichkeit zur Visualisierung von Anfragen, könnte deren Verständnis vereinfacht werden. Mithilfe einer Editiermöglichkeit dieser Visualisierung könnte man dann ebenfalls die Anpassung der Anfragen vereinfachen. Zur Vermeidung der Schwierigkeiten, die durch unterschiedliche Syntax und Semantik verschiedener SQL-Dialekte verursacht werden, wäre bei der Verwendung einer solchen Visualisierung zusätzlich eine möglichst Dialekt-unabhängige Formulierung/Repräsentation der Anfragen wünschenswert. Dieser Ansatz, also die Migration von Anfragen mithilfe solcher visueller Mechanismen, wird in dieser Arbeit verfolgt und bildet den Schwerpunkt im nun folgenden Kapitel. 52

65 4 Konzeptionelle Migration von Anfragen Im Unterschied zur bisherigen Vorgehensweise bei der funktionalen Migration wie sie in Abschnitt 3.1 beschrieben wurde, soll in dieser Diplomarbeit auf die in Abschnitt 3.2 angesprochenen Nachteile und die in Abschnitt 3.4 angesprochenen Anforderungen eingegangen werden. Im Vordergrund steht dabei eine Aufbereitung der Anfragen gemäÿ der in Abschnitt 3.3 genannten Qualitätskriterien. 4.1 Beschreibung der neuen Strategie Die neue Strategie zur Migration von Anfragen verfolgt den im Abschnitt 3.5 bereits kurz vorgestellten Ansatz, die Anfragen mithilfe von visuellen Mechanismen zu editieren. Es ist die praktikabelste Lösung für die genannten Probleme, denn wie im vorherigen Kapitel gezeigt wurde, ist das Editieren der Anfragen notwendig und für komplexe Anfragen ein sehr schwieriges Vorhaben. Deshalb soll versucht werden, den Benutzer durch eine Visualisierung dabei zu unterstützen. Auÿerdem wurde bereits festgestellt, dass die Migration von Anfragen auf der Ebene konkreter Datenbanksysteme nicht allgemeingültig behandelt werden kann. Deshalb wird die Migrationsaufgabe zusätzlich im Zuge der Visualisierung auf ein höheres Abstraktionsniveau angehoben. Auf dieser Ebene kann dann eine Revision der so gewonnenen konzeptionellen Anfrage-Repräsentationen durchgeführt werden, bevor sie abschlieÿend wieder auf die konkrete Ebene, in das jeweilige Ziel-DBMS (bzw. den dort verwendeten SQL-Dialekt), heruntergebracht werden können. Dabei stellt das Transformieren der Anfragen in einen (beliebigen) konkreten SQL-Dialekt jedoch keineswegs eine triviale Aufgabe dar. Eine entscheidende Voraussetzung hierfür ist die Unterstützung aller in der Anfrage verwendeten Konstrukte durch den gewünschten SQL-Dialekt (siehe Abschnitt 4.5). Als Vorlage oder zumindest als analoges Vorgehen zu dieser Strategie könnte man das ER-Modell ansehen, das zur konzeptionellen Repräsentation für Datenbankschemata dient. Denn wie schon in Abschnitt beschrieben wurde, hat sich das ER-Modell bereits als Zwischenstation für die Migration von Datenbankschemata etabliert. Ein solcher Mechanismus soll zukünftig also auch für Anfragen angeboten werden, 53

66 4 Konzeptionelle Migration von Anfragen wobei als Werkzeug für diesen Mechanismus Visual SQL 1 [36, 37] gewählt wird, da es u.a. eine Formulierung von Anfragen ermöglicht, die sich stark an das ER- Paradigma anlehnt, das sich ja bereits für die Aufbereitung von Schemata bewährt hat. In Abbildung 4.1 wird das Vorgehen der neuen Strategie veranschaulicht. Das Verfahren beginnt bei einer, durch die bisherige Vorgehensweise erhaltenen, migrierten Anfrage, die bisher das Endprodukt der Migration war. Diese wird dann nach Visual SQL hochgeholt, was im Wesentlichen eine Abstraktion von den verwendeten Datenbanksystemen sowie eine Visualisierung der Anfrage beinhaltet (s.o.). Die so erhaltene konzeptionelle, verständlichere Repräsentation der Anfrage kann dann durchgesehen und ggf. angepasst werden, so dass die in Abschnitt 3.3 genannten Qualitätskriterien möglichst gut erfüllt werden. Anschlieÿend wird die Anfrage von Visual SQL zurück nach SQL transformiert und zwar in den jeweiligen Dialekt des Ziel-DBMS der Migration. Die Visual SQL-Anfrage kann dann u.a. zu Dokumentationszwecken oder als Visualisierung aufbewahrt werden. Abbildung 4.1: Schema der neuen Strategie In Abschnitt 4.4 wird dieses Vorgehen anhand einiger Beispiele veranschaulicht, doch zuvor werden einige Vorteile der Visualisierung, sowie ein Überblick zu Visual SQL angegeben. 1 In Abschnitt 4.3 wird eine kurze Einführung zu Visual SQL angegeben. 54

67 4.2 Vorteile der Visualisierung 4.2 Vorteile der Visualisierung In [36] werden die Möglichkeiten und Grenzen der Visualisierung diskutiert. Da die dort genannten Vorteile eines der grundlegenden Kriterien für die Wahl dieses Migrationsansatzes darstellen, werden diese hier kurz aufgeführt Durch die Visualisierung von SQL Anfragen kann der Überblick über komplexere Anfragen erhalten und somit deren Verständnis vereinfacht werden. 2. Eine übersichtliche Anordnung erleichtert das Erkennen und Verstehen von Zusammenhängen innerhalb der in einer Anfrage verwendeten Bausteine, die ohne eine Visualisierung nicht so oensichtlich wären. 3. Ein weiteres Argument ist die einfache Pege von Anfragen in einer visuellen Repräsentation, denn Veränderungen des Datenbankschemas erfordern auch eine Anpassung der Anfragen (siehe Kapitel 2). Die häuge Wiederverwendung von ganzen Anfragen oder Teilen davon kann diese Anpassungen nur dann vereinfachen, wenn man den Überblick behält. 4. Der Fall der Wiederverwendung einer Anfrage als Kernbestandteil einer neuen Anfrage, also die Erweiterung einer Anfrage, ist nur dann möglich, wenn man sich dabei über die Implikationen der Wiederverwendung informieren kann. 5. Der durch eine Visualisierung gewonnene Überblick und das so erlangte Verständnis ermöglichen eine einfachere Korrektheitsprüfung, die ohne Visualisierung im Falle einer gröÿeren Anfrage durchaus auch einen erfahrenen Programmierer überfordern kann. 4.3 Visual SQL - Ein kurzer Überblick Das in [36, 37] vorgestellte Visual SQL ist ein ER-basierter Ansatz zur Datenbank- Programmierung und bietet u.a. die Möglichkeit, die Komplexität von mehreren Seiten (SQL-) Code zu reduzieren, indem es den Benutzern mithilfe einer graphischen Gestaltung entgegenkommt. Auf diese Weise ermöglicht es eine Formulierung von (komplexen) SQL-Anfragen, die sich sehr stark an das ER-Paradigma anlehnt, und genau das soll für den in dieser Arbeit verfolgten Ansatz zur Migration von Anfragen ausgenutzt werden. Deshalb folgt nun ein kurzer Überblick zu Visual SQL. 3 2 Für ausführlichere Informationen wird auf [36] verwiesen. 3 Für Details und hier nicht beschriebene Anfragen-Konstrukte wird auf [36] verwiesen. 55

68 4 Konzeptionelle Migration von Anfragen Funktionsumfang Visual SQL umfasst nicht nur die bereits angesprochene Formulierung von Anfragen, sondern insgesamt die folgenden Aspekte der Datenbankprogrammierung: 1. Denition und Modikation von Datenbankschemata (CREATE TABLE, AL- TER TABLE, sowie die Denition von Integritätsbedingungen (CHECK- Einschränkungen)) 2. Zuordnung und Streichen von Rechten (GRANT, REVOKE) 3. Modikation von Datenbanken (INSERT, UPDATE, DELETE) 4. Anfragen an Datenbanken (SELECT) Da für diese Diplomarbeit im Wesentlichen nur die Anfragen relevant sind, werden auch nur diese hier genauer betrachtet Formulierung von Anfragen Anhand einiger Anfragen zu dem bereits vorgestellten Beispielschema (siehe Abbildung B.1) wird im Folgenden gezeigt, wie sich Anfragen in Visual SQL formulieren lassen. Die folgenden drei Anfragen verwenden zunächst nur die einfachen Operationen Projektion und Selektion. SELECT * FROM Traube T; SELECT Bezeichnung, Sorte, Farbe FROM Traube T; SELECT Nummer, ErfassungsDatum, AusfuehrDatum FROM Vorgang V WHERE ErfassungsDatum < ' ' AND Status = 'noch nicht begonnen'; In Abbildung 4.2 ist die dritte Anfrage (Zeige die Nummer, das Datum der Erfassung und das Datum der geplanten Ausführung von allen alten Vorgängen, die noch nicht begonnen wurden.) in Visual SQL formuliert. Hier ist erkennbar, dass sich Visual SQL an der Entity-Darstellungsform von HERM 5 orientiert. Mit dem - Zeichen werden die Ausgabekomponenten gekennzeichnet und die oben rechts daran geschriebenen Zahlen dienen der Bestimmung der Ergebnisreihenfolge. Die nächste Anfrage verwendet Gruppierung, Sortierung und ein abgeleitetes Attribut. Die Visual SQL-Formulierung dieser Anfrage ist in Abbildung 4.3 gezeigt. 4 Für Details zu den übrigen Aspekten wird auf [36, 37] verwiesen. 5 Higher-order Entity-Relationship Model, siehe [34] 56

69 4.3 Visual SQL - Ein kurzer Überblick Abbildung 4.2: Visual SQL: Projektion und Selektion (mit AND) SELECT Ver_Ident, AnzVorgaenge = COUNT(*) FROM Vorgang V WHERE AusfuehrDatum = ' ' GROUP BY Ver_Ident ORDER BY COUNT(*) DESC; Abbildung 4.3: Visual SQL: Group By, Order By und abgeleitetes Attribut Als nächstes wird die Verknüpfung mehrerer Relationen betrachtet. Werden beispielsweise Informationen über die für heute geplanten Vorgänge inklusive ihrer einzelnen Teilschritte benötigt, dann muss die folgende Anfrage formuliert werden: SELECT * FROM Vorgang V, Vorgangsschritt VS WHERE V.Ident = VS.Tei_Ident AND V.AusfuehrDatum = ' '; Die Visual SQL-Repräsentation zu dieser Anfrage ist in Abbildung 4.4 dargestellt. Zur Demonstration von Unteranfragen interessieren uns nun alle Weine, die einen überdurchschnittlichen Alkoholgehalt haben, denn dazu muss zunächst innerhalb einer Unteranfrage der durchschnittliche Alkoholgehalt berechnet werden. Die Anfrage hierfür sieht folgendermaÿen aus: 57

70 4 Konzeptionelle Migration von Anfragen Abbildung 4.4: Visual SQL: natürlicher Verbund SELECT A.Nummer, A.Bezeichnung, W.AlkoholVolProz FROM Artikel A, Wein W WHERE A.Ident = W.Ident AND W.AlkoholVolProz > (SELECT AVG(AlkoholVolProz) FROM Wein W1); Die Visual SQL-Formulierung dieser Abbildung ist in Abbildung 4.5 angegeben. Die Verschachtelung ist dort gut zu erkennen, und man kann sich vorstellen, dass auf diese Weise auch mehrfach verschachtelte Anfragen übersichtlich darstellbar sind. Abbildung 4.5: Visual SQL: Unteranfrage 58

71 4.4 Durchführung an Beispielen 4.4 Durchführung an Beispielen Bevor die Vorteile und der Nutzen der konzeptionellen Migration von Anfragen anhand von drei Beispielen veranschaulicht werden, sei noch einmal angemerkt, dass die in dieser Arbeit gezeigten Beispiele zugunsten besserer Verständlichkeit auf die wesentlichen Bestandteile reduziert wurden. Es kann dadurch sein, dass ein geübter SQL-Programmierer in den zu untersuchenden Anfragen auch ohne eine Visualisierung die Optimierungs- und Vereinfachungsmöglichkeiten schnell erkennt. Wenn man jedoch bedenkt, dass die hier verwendeten Beispielanfragen Bestandteile von deutlich gröÿeren Anfragen sein könnten, dann stellt man fest, dass die gezeigten Probleme nicht mehr so oensichtlich zu erkennen sind und in der Unübersichtlichkeit einer textuellen Anfrageformulierung leichter untergehen Beispiel 1: Dekomposition eines Entity-Typs Während der in Abschnitt bereits teilweise erläuterten Reengineering Phase wurde eine Veränderung des Beispiel-Datenbankschemas durchgeführt, welche die Dekomposition des Entity-Typs Artikel zu den zwei Entity-Typen Artikel und Wein beinhaltete. Der neue Entity-Typ Wein ist ein spezieller Artikel, also ein Untertyp zu Artikel 6, der zusätzlich zu den allgemeinen Artikel-Eigenschaften noch einige weinspezische Eigenschaften besitzt (siehe Abbildung 2.3). Im ursprünglichen Schema waren diese weinspezischen Eigenschaften hingegen als Attribute des Typs Artikel modelliert, die nur dann mit Werten belegt wurden, wenn es sich bei einem Artikel um Wein handelte (andernfalls wurden diese Attribute mit dem NULL-Wert belegt). Dies wurde während des Reengineerings korrigiert, so dass die in Abbildung 4.6 gezeigte Anfrage korrigiert werden muss und daher einer genaueren Untersuchung unterzogen werden sollte. SELECT Ident, Nummer, Bezeichnung, Jahrgang FROM Artikel WHERE Jahrgang IS NOT NULL; Abbildung 4.6: Beispiel 1: Anfrage an Artikel vor der Dekomposition Gemäÿ dem in Abschnitt veranschaulichten Verfahren muss für die ursprüngliche Tabelle Artikel die in Abbildung 4.7 gezeigte Sicht deniert werden, damit die Anfrage auch auf dem neuen Schema lauähig ist. 7 6 Dies wird in Abbildung 2.3 durch die IS-A-Beziehung modelliert (siehe Anhang A). 7 Die für die Sichtendenition erforderliche Umbenennung der neuen Tabelle wurde ebenfalls in Abschnitt begründet. 59

72 4 Konzeptionelle Migration von Anfragen CREATE VIEW Artikel AS SELECT A.Ident, Nummer, Bezeichnung, Jahrgang, AlkoholVolProz, SO2Gehalt, Säure FROM Artikel_neu A LEFT OUTER JOIN Wein W ON A.Ident = W.Ident; Abbildung 4.7: Beispiel 1: Sichtendenition für die ursprüngliche Tabelle Artikel Der nächste Schritt besteht dann in der Substitution der Tabelle Artikel innerhalb der Anfrage durch die entsprechenden Sichtendenition (siehe Abb. 4.8), wodurch der Ausgangspunkt für die kozeptionelle Migration der Anfrage erreicht wird. SELECT Ident, Nummer, Bezeichnung, Jahrgang FROM ( SELECT Artikel.Ident, Nummer, Bezeichnung, Jahrgang AlkoholVolProz, SO2Gehalt, Säure FROM Artikel A LEFT OUTER JOIN Wein W ON A.Ident = W.Ident ) X WHERE Jahrgang IS NOT NULL; Abbildung 4.8: Beispiel 1: Anfrage an Artikel mit eingebetteter Sichtendenition Als erster Schritt der konzeptionellen Migration wird die eben erstellte Anfrage in ihre entsprechende Visual SQL Repräsentation überführt (siehe Abb. 4.9). Die in der Anfrage enthaltene Unteranfrage ist aufgrund der Gruppierung (dargestellt durch das Rechteck um die beiden Entitäten) auch in der visuellen Repräsentation deutlich erkennbar. 60 Abbildung 4.9: Beispiel 1: Formulierung der Anfrage in Visual SQL

73 4.4 Durchführung an Beispielen Die an die Gruppierung gehefteten Attribute (erkennbar an der gestrichelten Umrandung) bilden dabei die Ausgabe der Hauptanfrage 8. Bei genauer Betrachtung der Anfrage kann man nun festellen, dass diese Ausgabe lediglich einen Teil der Ausgabe von der Unteranfrage nach oben bzw. auÿen durchreicht. Dies ist allerdings auch möglich, indem man den in Abschnitt 4.3 beschriebenen Mechanismus von Visual SQL ausnutzt, und den Index des Ausgabesymbols inkrementiert 9 (siehe Abb. 4.10). Abbildung 4.10: Beispiel 1: Erste visuelle Umformulierung Beim Blick auf die so entstandene Anfrage ist erkennbar, dass die Schachtelung der Anfrage nicht mehr benötigt wird, weshalb man sie im nächsten Schritt entfernen kann (siehe Abb. 4.11). Dabei ist jedoch zu beachten, dass dann all diejenigen Ausgabe-Markierungen entfallen müssen, die sich bislang nur auf die Unteranfrage bezogen haben, da sie sich andernfalls zukünftig auf die Hauptanfrage beziehen, wodurch das Ergebnis der Anfrage verändert wird. Abbildung 4.11: Beispiel 1: Zweite visuelle Umformulierung Wie man an dieser Stelle leicht bemerkt, ist visuell bereits eine deutliche Vereinfachung der Anfrage gelungen, die sich auch auf die SQL-Repräsentation dieser Anfrage überträgt (siehe Abb. 4.12). 8 Anhand der '1' im Index der Ausgabesymbole innerhalb der Unteranfrage wird signalisiert, dass diese Ausgaben nur für die Unteranfrage gelten 9 Die so entstandene '0' im Index muss nicht an das Ausgabesymbol geschrieben werden (siehe Abschnitt 4.3). 61

74 4 Konzeptionelle Migration von Anfragen SELECT A.Ident, A.Nummer, A.Bezeichnung, W.Jahrgang FROM Artikel A LEFT OUTER JOIN Wein W ON A.Ident = W.Ident WHERE W.Jahrgang IS NOT NULL; Abbildung 4.12: Beispiel 1: Erste SQL-Repräsentation der visuell bearbeiteten Anfrage Im Unterschied zu der eben durchgeführten Anpassung der Anfrage, für die keine Kenntnis des Datenbankschemas notwendig ist, kann nun mithilfe dieser Kenntnis eine weitere Vereinfachung der visuellen Frage durchgeführt werden. Man muss dazu wissen, dass es sich bei der Beziehung zwischen Wein und Artikel um eine IS-A-Beziehung handelt und dass es keine Weine geben kann, für die kein Jahrgang angegeben ist. Deshalb wird die Bedingung Jahrgang IS NULL innerhalb der Anfrage nur dann wahr, wenn es sich nicht um einen Wein handelt 10. Da in der Anfrage allerdings die Bedingung Jahrgang IS NOT NULL formuliert ist, sollen nur diejenigen Artikel betrachtet werden, die Weine sind, was sich auch dadurch realisieren lässt, dass man den LEFT OUTER JOIN zu einem einfachen Verbund umformuliert. Auf diese Weise ist die Bedingung Jahrgang IS NOT NULL nicht mehr notwendig und kann deshalb entfernt werden. Die somit ein weiteres Mal vereinfachte Anfrage ist in Abbildung 4.13 und ihre zugehörige SQL-Repräsentation ist in Abbildung 4.14 gezeigt. Abbildung 4.13: Beispiel 1: Dritte visuelle Umformulierung SELECT A.Ident, A.Nummer, A.Bezeichnung, W.Jahrgang FROM Artikel A JOIN Wein W ON A.Ident = W.Ident; Abbildung 4.14: Beispiel 1: Zweite SQL-Repräsentation der visuell bearbeiteten Anfrage 10 Man beachte, dass es sich zwischen Artikel und Wein um einen LEFT OUTER JOIN handelt. 62

75 4.4 Durchführung an Beispielen Beispiel 2: Komposition zweier Entity-Typen Nun soll einmal der umgekehrte Fall zu dem eben betrachteten Beispiel untersucht werden. Dafür sei angenommen, dass im ursprünglichen Schema der Typ Wein bereits ein Untertyp von Artikel gewesen ist, und dass während des Reengineerings eine Komposition dieser beiden Typen zum neuen Typ Artikel durchgeführt wurde. Für Artikel, die keine Weine sind, werden dann die weinspezischen Attribute mit dem NULL-Wert belegt. In Abbildung 4.15 sind die beiden erforderlichen Sichtende- nitionen gezeigt, und in Abbildung 4.16 ist die zu untersuchende Anfrage (siehe Abb. 4.14) mit eingesetzten Sichtendenitionen dargestellt. CREATE VIEW Artikel AS SELECT Ident, Nummer, Bezeichnung FROM Artikel_neu; CREATE VIEW Wein AS SELECT Ident, Jahrgang, AlkoholVolProz, SO2Gehalt, Säure FROM Artikel_neu WHERE Jahrgang IS NOT NULL; Abbildung 4.15: Beispiel 2: Sichtendenitionen für die ursprünglichen Tabellen Artikel und Wein SELECT A.Ident, A.Nummer, A.Bezeichnung, W.Jahrgang FROM ( SELECT Ident, Nummer, Bezeichnung FROM Artikel ) A JOIN ( SELECT Ident, Jahrgang, AlkoholVolProz, SO2Gehalt, Säure FROM Artikel WHERE Jahrgang IS NOT NULL ) W ON A.Ident = W.Ident; Abbildung 4.16: Beispiel 2: Anfrage mit eingesetzten Sichtendenitionen In der visuellen Darstellung der Anfrage 11 (siehe Abb. 4.17) erkennt man leicht, dass es sich bei den beiden verwendeten Entitäten um den gleichen Typ handelt, nämlich Artikel, was am Bezeichner der Entitäten festgestellt werden kann. Aufgrund 11 Die dargestellte Anfrage ist bereits durch eine Auösung der Verschachtelung (siehe Beispiel 1, Abschnitt 4.4.1) vereinfacht worden. 63

76 4 Konzeptionelle Migration von Anfragen der direkten Gegenüberstellung geben aber auch die Anzahl und die Namen der jeweiligen Attribute bereits einen Hinweis darauf. Weiter ist zu beobachten, dass aus beiden Entitäten jeweils exklusiv unterschiedliche Attribute selektiert werden und dass ein Verbund auf dem Attribut Ident durchgeführt wird. Abbildung 4.17: Beispiel 2: Formulierung der Anfrage in Visual SQL Da es sich bei dem Attribut Ident um einen (bzw. den Primär-) Schlüssel des Typs Artikel handelt, kann man die Anfrage deutlich vereinfachen, indem man die Entität Artikel mit dem Alias W aus der Anfrage entfernt und das Attribut Jahrgang in der Entität Artikel mit dem Alias A zur Ausgabe hinzufügt (siehe Abb. 4.18). Abbildung 4.18: Beispiel 2: Visuelle Vereinfachung der Anfrage Die Schlüsseleigenschaft (bzw. die Eindeutigkeit) des Attributs Artikel.Ident ist eine wesentliche Voraussetzung für diesen Vereinfachungsschritt, da die Anfrage andernfalls nach der Veränderung u.u. nicht mehr die gleichen Ergebnisse liefert wie davor. Auÿerdem dürfen keine Attribute in der Auswahl doppelt vorkommen, da dies in der vereinfachten Anfrage in Visual SQL nicht darstellbar ist 12 und dadurch ebenfalls das Ergebnis der Anfrage verändert wird. Durch Transformation der visuellen Anfrage nach SQL erhält man die in Abbildung 4.19 gezeigte Anfrage, welche gegenüber der ursprünglichen Anfrage (siehe Es ist in Visual SQL nicht möglich, ein Attribut mehrfach in das Ergebnis der Anfrage aufzunehmen, siehe [36].

77 4.4 Durchführung an Beispielen Abb. 4.16) deutlich vereinfacht wurde. SELECT A.Ident, A.Nummer, A.Bezeichnung, A.Jahrgang FROM Artikel A WHERE A.Jahrgang IS NOT NULL; Abbildung 4.19: Beispiel 2: SQL-Repräsentation der visuell bearbeiteten Anfrage Beispiel 3: Verkürzung eines Anfrage-Pfades Als letztes Beispiel wird die in Abildung 4.20 gezeigte Anfrage untersucht. SELECT K.*, KI.*, W.Jahrgang FROM Karton K JOIN KartonInhalt KI ON K.Ident = KI.K_K_Ident JOIN Artikel A ON A.Ident = KI.K_A_Ident JOIN Wein W ON W.Ident = A.Ident; Abbildung 4.20: Beispiel 3: Die zu untersuchende Anfrage Da es sich dabei bereits um eine zulässige Anfrage bezüglich des neuen Datenbank- Schemas handelt 13, wird dieses Mal die Einsetzung von Sichtendenitionen nicht benötigt, und die Anfrage kann unverändert nach Visual SQL transformiert werden (siehe Abb. 4.22). Abbildung 4.21: Beispiel 3: Formulierung der Anfrage in Visual SQL In der visuellen Repräsentation ist leicht feststellbar, dass keines der Attribute der Entität Artikel für das Ergebnis benötigt wird. Dieses zu erkennen wäre in der textuellen Darstellung der Anfrage insbesondere dann erschwert, wenn der '*' nicht 13 Die dazu notwendigen Schritte wurden bereits einige Male veranschaulicht, und werden deshalb hier nicht noch einmal gezeigt. 65

78 4 Konzeptionelle Migration von Anfragen verwendet worden wäre. Auÿerdem wird der Verbund sowohl von KartonInhalt und Artikel, als auch von Artikel und Wein auf dem Attribut Artikel.Ident durchgeführt, das einen (bzw. den Primär-) Schlüssel der Entität Artikel darstellt. Somit kann der Anfragepfad verkürzt werden, indem der Verbund von KartonInhalt und Wein zukünftig direkt erfolgt (siehe Abb. 4.22). Abbildung 4.22: Beispiel 3: Visuelle Vereinfachung der Anfrage Transformiert man diese Anfrage wieder nach SQL, so ist auch dort der Anfragepfad verkürzt worden, wodurch die Anfrage an Übersichtlichkeit gewinnt und je nach verwendetem DBMS performanter ausgeführt wird (siehe Abb. 4.23). SELECT K.*, KI.*, W.Jahrgang FROM Karton K JOIN KartonInhalt KI ON K.Ident = KI.K_K_Ident JOIN Wein W ON W.Ident = KI.K_A_Ident; Abbildung 4.23: Beispiel 3: SQL-Repräsentation der visuell bearbeiteten Anfrage 4.5 Einschränkungen und Anwendbarkeit Die eben angegebenen Beispiele zeigen, dass das hier vorgestellte Verfahren einen hohen Nutzen haben und den Prozess der Anfragen-Migration erheblich unterstützen kann. Es ist allerdings ebenfalls, wie auch die bisherigen Verfahren, nicht universell anwendbar. Eine Einschränkung in Bezug auf die Anwendbarkeit dieser Strategie liegt im Sprachumfang der konzeptionellen Sprache, in diesem Fall Visual SQL. Wie bereits angesprochen wurde, abstrahiert diese Sprache von den DBMS-spezischen SQL- Dialekten, um u.a. eine konzeptionelle Formulierung von Anfragen zu ermöglichen. Hierbei ist es durchaus sinnvoll, nicht jedes DBMS-spezische Konstrukt in den Sprachumfang aufzunehmen, da sonst keine wirkliche Abstraktion stattndet. Dadurch 66

79 4.5 Einschränkungen und Anwendbarkeit kann es allerdings vorkommen, dass Anfragen, die solche Konstrukte verwenden und die nicht so umformuliert werden können, dass diese Konstrukte eliminiert werden, sich nicht in dieser Sprache ausdrücken lassen. (Beispiele hierfür werden in Abschnitt 5.7 angegeben.) Für solche Anfragen ist folglich die Visualisierung und dadurch eine Ausnutzung dieser Strategie nicht möglich. Die Visualisierung hat zahlreiche Vorteile (siehe Abschnitt 4.2), aber natürlich auch einige Nachteile. In [36] wurden diese Nachteile bereits diskutiert, weshalb hier nur ein kurzer Überblick darüber abgegeben wird (siehe [36] für Details): 1. Anwendbarkeit für mittelgroÿe Anfragen Die Übersichtlichkeit einer Visualisierung entfällt, wenn diese zu viele Objekte enthält. In [36] wird auf Beobachtungen verwiesen, die gezeigt haben, dass bereits ab etwa 30 Entity- und Relationship-Typen innerhalb einer Übersicht der Überblick verloren geht. (Diese Anzahl ist in Anfragen allerdings selten der Fall.) 2. initialer Aufwand Ist die Anwendung, also insbesondere das Datenschema und die verwendeten Anfragen, sehr einfach und von geringer Komplexität, so ist der Weg über eine Visualisierung unpassend, denn dann ist der initiale Aufwand zu hoch und der Nutzen zu gering. (Schon in Kapitel 1 wurde festgestellt, dass die Überlegung von Migrationsstrategien nur dann sinnvoll bzw. erforderlich ist, wenn das Neuschreiben der Anwendung nicht trivial ist.) 3. falsche Granularität Interne Schema-Beschränkungen, die innerhalb von Anfragen wirksam werden, müssten eigentlich ebenfalls visualisiert werden. Dazu werden allerdings andere Visualisierungstechniken benötigt. 4. kein Universalmittel Visualisierung ist nur dann eine Hilfe, wenn die graphische Darstellung eine eindeutige Semantik besitzt. 67

80 4 Konzeptionelle Migration von Anfragen 68

81 5 Implementierung der konzeptionellen Migration von Anfragen Bisher war es mit der vorhandenen Implementierung von Visual SQL (siehe [1]) möglich, zu einem gegebenen Datenbankschema Anfragen zu formulieren, und diese nach SQL (Standard-SQL92) zu transformieren. Durch die Beschäftigung mit der funktionalen Migration erschien allerdings eine neue Komponente als erforderlich, die eine Übersetzung vorhandener SQL-Anfragen nach Visual SQL ermöglicht. Deshalb wurde im Rahmen dieser Diplomarbeit eine solche Übersetzungskomponente entwickelt, so dass nun auch eine technische Unterstützung für das vorgestellte Verfahren verfügbar ist. Denn insgesamt kann man mit der Visual SQL-Implementierung und der eben genannten Erweiterung zukünftig SQL-Anfragen (im Dialekt Transact-SQL, s.u.) visualisieren, die visuellen Anfragen mithilfe des Visual SQL-Editors modizieren und abschlieÿend wieder nach SQL (in den Dialekt Standard-SQL92 ) übersetzen. In diesem Kapitel wird der entwickelte Übersetzer sowie dessen Implementierung kurz beschrieben. Für eine bessere Verständlichkeit wird dabei im Folgenden mit VisualSQL die Implementierung sowie mit Visual SQL die Sprache bezeichnet. 5.1 Zielsetzung Das Ergebnis der Implementierung soll ein Übersetzer sein, der SQL-Anfragen in ihre entsprechende Visual SQL-Repräsentation überführt. Hierbei muss allerdings die Entscheidung für einen bestimmten SQL-Dialekt getroen werden, da sich die Dialekte unterschiedlicher Datenbanksysteme sowohl vom Funktionsumfang, als auch von der Syntax her deutlich unterscheiden (siehe Abschnitt 2.1.2). Für den in dieser Arbeit zu entwickelnden Übersetzer wird der Dialekt Transact-SQL (T-SQL) gewählt, der in Microsofts SQL Server 2000 zum Einsatz kommt, da es sich bei der Datenbank der untersuchten Beispielanwendung um eine SQL Server 2000 Datenbank handelt (siehe Abschnitt 2.3). Aufgrund der Implementierung des SQL92- Standards durch T-SQL lassen sich dann jedoch auch allgemeinere SQL-Anfragen übersetzen, sofern sie diesem Standard entsprechen. 69

82 5 Implementierung der konzeptionellen Migration von Anfragen 5.2 Gewählte Technologien Als erstes wurde untersucht, ob und auf welche Weise sich das Problem mit der Programmiersprache Java lösen lässt, da die bisherige Implementierung von VisualSQL Java verwendet und somit eine gute Kommunikation zwischen den beiden Programmen herstellbar wäre. Eines der entscheidenden Kriterien für die Wahl von Java zur Lösung des Problems stellte dann das Vorhandensein des Java-Parsergenerators JavaCC (Java Compiler Compiler, siehe [21]) dar, mit dessen Hilfe auf einfache Weise der erforderliche T-SQL-Parser erzeugt werden kann. Somit wurden für die Implementierung die Programmiersprache Java in der Version 1.5.0_05 sowie JavaCC in der Version 4.0beta1 gewählt, wobei zusätzlich die JavaCC-Erweiterung JJTree (siehe [22]) zum Einsatz kommt, welche die Erzeugung abstrakter Syntaxbäume während des Parsens ermöglicht. 5.3 Schnittstelle zu VisualSQL Als Schnittstelle zwischen dem zu entwickelnden Übersetzer und VisualSQL wird das durch eine DTD 1 beschriebene XML-Format gewählt, das von VisualSQL zur Abspeicherung von Anfragen verwendet wird Ein- und Ausgabe Der Aufruf des Übersetzers in der Konsole benötigt die Angabe der folgenden drei Parameter 1. der Name der VSQ-Datei 3, die das entsprechende Datenbankschema für die zu übersetzende Anfrage enthält, 2. der Name der Textdatei, welche die zu übersetzende (Transact-) SQL-Anfrage beinhaltet und 3. der Name der VSQ-Datei, in die das Ergebnis der Übersetzung ausgegeben werden soll. Auf diese Weise ist die Verwendung des Übersetzers als eigenständiges Programm möglich. Die durch den Übersetzer erzeugte VSQ-Datei kann dann mit VisualSQL, 1 Dokumenttypdenition 2 Die DTD ist im Anhang C an diese Arbeit angefügt. 3 Dabei handelt es sich um eine von VisualSQL gespeicherte Datei, die der bereits angesprochenen DTD entspricht. In einer solchen Datei ist jeweils das Datenbankschema und eine Anfrage an dieses Schema gespeichert. 70

83 5.5 Die Übersetzung von SQL-Anfragen genau wie eine von VisualSQL selbst gespeicherte Anfrage, geönet und editiert werden. Die Integration des Übersetzers in VisualSQL ist derzeit noch nicht umgesetzt, sie wird aber wahrscheinlich noch im Rahmen von [1] erfolgen. Dabei ist es möglich, dem Benutzer die Angabe der Datenbankschema-Datei abzunehmen, indem von VisualSQL das jeweils aktuell geönete Datenbankschema (in Form des Bezeichners der gespeicherten Datei) an den Aufruf des Übersetzers übergeben wird. Ebenso kann die Angabe des Bezeichners der Ausgabe-Datei von VisualSQL übernommen werden, da der Anwender von VisualSQL dann diese Anfrage nach dem Önen selbst speichern kann. 4 Somit ist dann für den Anwender nur noch die Datei mit der zu übersetzenden Anfrage anzugeben, wodurch die Verwendung des Übersetzers für den Anwender deutlich vereinfacht wird. 5.5 Die Übersetzung von SQL-Anfragen In diesem Abschnitt wird der Aufbau des entwickelten Übersetzers beschrieben. Für alle vorkommenden Fachbegrie aus dem Themenbereich Übersetzerbau wird auf [38] verwiesen Der Parser Für die Erzeugung eines Parsers sind die folgenden Bestandteile erforderlich, welche für den vorliegenden Fall (T-SQL) anschlieÿend erklärt werden: die Denition der Token (für die lexikalische Analyse) und die Denition der Grammatik (für die syntaktische Analyse). Lexikalische Analyse Für die lexikalische Analyse ist die Denition aller zulässiger Token erforderlich, die sich im Fall des T-SQL-Parsers in die folgenden Kategorien einteilen lassen: SQL-Schlüsselwörter (z.b. select, from, where,...), Bezeichner (für Tabellen, Attribute, Funktionen,... ), Zeichenketten- sowie numerische Konstanten und Kommentare (Inline- und Blockkommentare: , /*...*/). 4 Beim Anlegen einer neuen Anfrage-Datei in VisualSQL ist diese ebenfalls solange in einer temporären Datei abgelegt bis der Anwender sie explizit speichert. 71

84 5 Implementierung der konzeptionellen Migration von Anfragen Syntaktische Analyse Der syntaktischen Analyse liegt bei der Verwendung von JavaCC eine kontextfreie Grammatik zugrunde, die sich im Fall des T-SQL-Parsers an der Syntaxbeschreibung des select-statements vom SQL Server orientiert (siehe [14]). Abweichungen bzw. Umformulierungen dieser Grammatik erfolgten hauptsächlich zur Vereinfachung der Übersetzung oder um beispielsweise eine Linksrekursion aufzulösen. 5 Abbildung 5.1 zeigt die folgenden zwei Produktionen der Grammatik in JJTree- Syntax, wobei SelectStatement die Startproduktion der Grammatik ist. 6 SelectStatement := SelectWithoutOrder ( OrderByClause )? ( <SEMICOLON> )? <EOF> SelectWithoutOrder := SelectList ( IntoClause )? FromClause ( WhereClause )? ( GroupByClause )? SimpleNode SelectStatement() : {} { SelectWithoutOrder() [ OrderByClause() ] <EOF> { return jjtthis; } } void SelectWithoutOrder() : {} { SelectList() [ IntoClause() ] FromClause() [ WhereClause() ] [ GroupByClause() ] } Abbildung 5.1: Zwei Beispielproduktionen der Grammatik in JJTree-Syntax Die Methode SelectStatement() hat den Rückgabewert SimpleNode, wodurch der Aufruf SimpleNode n = SelectStatement(); 5 Die in [14] angegebene Syntax ist für den Anwender zur Beschreibung gültiger Anfragen gedacht und deshalb in einer möglichst lesbaren Form dargestellt. Für die Grammatik-Denition in einem Parser sind allerdings einige Umformulierungen notwendig. 6 Die vollständige Grammatik des entwickelten T-SQL-Parsers ist in Anhang D angegeben. 72

85 5.6 Realisierte Funktionalität das Parsen eines select-statements veranlasst und der entstandene abstrakte Syntaxbaum (bzw. die Wurzel davon) als Rückgabewert in der Variablen n erhalten wird Der Übersetzer Die Übersetzung der SQL-Anfragen zu Visual SQL-Anfragen erfolgt durch semantische Aktionen während des Parsens. Gleichzeitig wird dabei ein Syntaxbaum für die Altanfrage aufgebaut, der allerdings für die Übersetzung nicht benötigt wird. Deshalb wäre die Verwendung der JavaCC-Erweiterung JJTree im Nachhinein nicht notwendig gewesen, sie vereinfacht allerdings durch die Ausgabemöglichkeit des Syntaxbaums das Verständnis und die Fehlersuche. Mithilfe der o.g. semantischen Aktionen werden bereits während des Parsens Objekte erzeugt, die nach Abschluss des Parsens bereits eine vollständige Repräsentation der zu erstellenden XML- bzw. VSQ-Datei enthalten. Die Klassen dieser Objekte entsprechen dabei im Wesentlichen den Elementen der DTD, d.h. es gibt beispielsweise die Klassen Query, Abstraction, GroupBy usw. (siehe Anhang C). Da es sich bei dem erzeugten Parser um einen Top-Down-Parser handelt, erfolgt das Einlesen der Anfrage von oben nach unten. Die Übersetzung der Anfrage erfolgt allerdings in der folgenden Reihenfolge: 1. From-Klausel (inkl. join-kanten) 2. Auswahlliste 3. Where-Klausel 4. Group By-Klausel 5. (Having-Klausel) 6. Order By-Klausel 7. Into-Klausel Nach der Übersetzung werden die Objekte dann nur noch in die angegebene Datei ausgegeben. 5.6 Realisierte Funktionalität Da es sich in dieser Diplomarbeit generell um eine Machbarkeitsstudie handelt, wurden hier im Wesentlichen nur die grundlegenden und gängigen Komponenten von select-anfragen realisiert. Als Beispiele können dafür können die in Kapitel 4 gezeigten Visual SQL-Anfragen betrachtet werden, die bis auf die folgenden zwei Ausnahmen mit dem hier entwickelten Übersetzer erzeugt wurden: 73

86 5 Implementierung der konzeptionellen Migration von Anfragen 1. Die in Abbildung 4.9 gezeigte Abbildung wurde manuell aus der in Abbildung 4.11 angegebenen Anfrage erzeugt, weil diese bereits das Ergebnis der Übersetzung war. Die dort betrachtete Verschachtelung wird also bereits während der Übersetzung aufgelöst. 2. Die in Abbildung 4.5 gezeigte Anfrage wurde ebenfalls manuell nachbearbeitet, da skalare Unteranfragen nicht vollständig übersetzt werden, sondern als textuelle Bedingung dargestellt werden (siehe Abb. 5.2). Abbildung 5.2: Übersetzer-Ergebnis der zu Abb. 4.5 gehörenden SQL-Anfrage 5.7 Einschränkungen der Übersetzung Einige Konstrukte, die in T-SQL formulierbar sind, lassen sich in Visual SQL nicht ausdrücken und können daher nicht übersetzt werden. Dazu zählen u.a. 74 Das mehrfache Aufnehmen eines Attributs in die Auswahlliste. Beispielsweise wird die Anfrage select Nummer,* from Artikel daher zu select * from Artikel übersetzt, wodurch die Anfragen allerdings unterschiedliche Ergebnisse liefern. die Top n-klausel Die Verwendung von Ausdrücken in der Group By- und Order By-Klausel ist nicht möglich. Es können dort nur Attributnamen angegeben werden. die Vereinigung mehrerer Anfrageergebnisse mittels union In Bedingungen sind nur boolesche Ausdrücke zulässig, in denen die NOT's vollständig nach innen verschoben sind. (KNF oder DNF)