Funktionale Migration - Technologie der Informationssysteme

Diplomarbeit
Funktionale Migration von
Informationssystemen
Stefan Koch
Matrikel-Nr. 481894
17. 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
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
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
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
iv
Inhaltsverzeichnis
1 Einführung zur Migration von Erbschaftsinformationssystemen
1.1
1.2
1.3
1.4
1.5
1
Das Problem der Erbschaftsinformationssysteme . . . . . . . . . . . .
Die Lösung: Migration . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.1 Über den Begri Migration . . . . . . . . . . . . . . . . . . .
1.2.2 Probleme bei der Migration von geerbten Informationssystemen
1.2.3 Über den Begri Reengineering . . . . . . . . . . . . . . . . .
Migrationsstrategien . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.1 Cold Turkey . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.2 Chicken Little . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.3 Die Buttery-Methode . . . . . . . . . . . . . . . . . . . . . .
1.3.4 Bewertung der Migrationsstrategien . . . . . . . . . . . . . . .
Migrationskomplexität und IS-Architekturen . . . . . . . . . . . . . .
1.4.1 Softwarearchitektur nach Brodie und Stonebraker . . . . . . .
1.4.2 Softwarearchitektur nach Siedersleben . . . . . . . . . . . . . .
Vorbereitung und globales Design . . . . . . . . . . . . . . . . . . . .
2 Überblick zur Migration von Datenbanken
2.1
2.2
2.3
Aufgaben der Datenbankmigration . . . . . . . .
2.1.1 Strukturelle Migration . . . . . . . . . . .
2.1.2 Funktionale Migration . . . . . . . . . . .
DBMS-Unterschiede . . . . . . . . . . . . . . . .
Ein Beispiel . . . . . . . . . . . . . . . . . . . . .
2.3.1 Herkunft / Hintergrund . . . . . . . . . .
2.3.2 Das Datenbankschema . . . . . . . . . . .
2.3.3 Reengineering des Schemas . . . . . . . . .
2.3.4 Konsequenzen für die betroenen Anfragen
1
2
3
3
3
4
5
7
9
12
15
16
19
20
23
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
24
25
27
29
38
38
39
39
43
v
Inhaltsverzeichnis
3 Anfragen bei der funktionalen Migration
47
3.1
Das bisherige Vorgehen bei der Migration von Anfragen . . . . . . . . 47
3.2
Bewertung des bisherigen Vorgehens
3.3
Qualitätskriterien für migrierte Anfragen . . . . . . . . . . . . . . . . 49
3.4
Anforderungen an eine neue Strategie . . . . . . . . . . . . . . . . . . 50
3.5
Mögliche Lösungsstrategien . . . . . . . . . . . . . . . . . . . . . . . 51
. . . . . . . . . . . . . . . . . . 48
4 Konzeptionelle Migration von Anfragen
53
4.1
Beschreibung der neuen Strategie . . . . . . . . . . . . . . . . . . . . 53
4.2
Vorteile der Visualisierung . . . . . . . . . . . . . . . . . . . . . . . . 55
4.3
Visual SQL - Ein kurzer Überblick . . . . . . . . . . . . . . . . . . . 55
4.4
4.5
4.3.1
Funktionsumfang . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.3.2
Formulierung von Anfragen . . . . . . . . . . . . . . . . . . . 56
Durchführung an Beispielen . . . . . . . . . . . . . . . . . . . . . . . 59
4.4.1
Beispiel 1: Dekomposition eines Entity-Typs . . . . . . . . . . 59
4.4.2
Beispiel 2: Komposition zweier Entity-Typen . . . . . . . . . . 63
4.4.3
Beispiel 3: Verkürzung eines Anfrage-Pfades . . . . . . . . . . 65
Einschränkungen und Anwendbarkeit . . . . . . . . . . . . . . . . . . 66
5 Implementierung der konzeptionellen Migration von Anfragen
69
5.1
Zielsetzung
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.2
Gewählte Technologien . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.3
Schnittstelle zu VisualSQL . . . . . . . . . . . . . . . . . . . . . . . . 70
5.4
Ein- und Ausgabe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.5
Die Übersetzung von SQL-Anfragen . . . . . . . . . . . . . . . . . . . 71
5.5.1
Der Parser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.5.2
Der Übersetzer . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.6
Realisierte Funktionalität . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.7
Einschränkungen der Übersetzung . . . . . . . . . . . . . . . . . . . . 74
6 Zusammenfassung
77
7 Ausblick
79
A Erklärung der verwendeten Notation für das ER-Modell
81
vi
Inhaltsverzeichnis
B Dokumentation des Beispiels
85
B.1 ER-Modell: Entitäten . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
B.2 ER-Modell: Beziehungen . . . . . . . . . . . . . . . . . . . . . . . . . 88
B.3 Relationales Datenmodell . . . . . . . . . . . . . . . . . . . . . . . . 91
C DTD für VisualSQL-Dateien
93
D Grammatik des T-SQL-Parsers
103
Literaturverzeichnis
107
vii
Inhaltsverzeichnis
viii
Abbildungsverzeichnis
1.1
Klassikation der Probleme bei der Migration von Erbschaftsinformationssystemen (aus [8]) . . . . . . . . . . . . . . . . . . . . . . . .
4
1.2
Migrationsarchitektur für Informationssysteme nach [10] . . . . . . .
7
1.3
Die Chicken Little Schritte nach [10] . . . . . . . . . . . . . . . . . .
8
1.4
Aufbau des Zielsystems bei der Buttery-Methode (aus [39]) . . . . . 10
1.5
Phase 4 (Migration der Daten) der Buttery-Methode nach [39] . . . 10
1.6
Migrieren der Daten in TempStore T Sn (aus [39]) . . . . . . . . . . . 11
1.7
Die Phasen der Buttery-Methode nach [39] . . . . . . . . . . . . . . 11
1.8
Zerlegbare Erbschafts-IS-Architektur nach [10] . . . . . . . . . . . . . 17
1.9
Halbzerlegbare Erbschafts-IS-Architektur nach [10] . . . . . . . . . . 17
1.10 Nicht zerlegbare Erbschafts-IS-Architektur nach [10] . . . . . . . . . . 18
1.11 Gemischte Erbschafts-IS-Architektur nach [10] . . . . . . . . . . . . . 18
2.1
Schema der strukturellen Migration . . . . . . . . . . . . . . . . . . . 27
2.2
Schema der funktionalen Migration . . . . . . . . . . . . . . . . . . . 29
2.3
Konzeptionelles Schema des Weinherstellungsbeispiels . . . . . . . . . 40
2.4
Modellierungs-Problem Karton ↔ Artikel im Altsystem (ERM) . . . 41
2.5
Modellierungs-Problem Karton ↔ Artikel (RDM) . . . . . . . . . . . 42
2.6
Lösung des Modellierungs-Problems Karton ↔ Artikel (RDM) . . . . 42
2.7
Eine Anfrage an das ursprüngliche Schema . . . . . . . . . . . . . . . 43
2.8
Die Anfrage zum neuen Schema . . . . . . . . . . . . . . . . . . . . . 44
2.9
Denition der Tabelle Karton als Sicht auf dem neuen Schema . . . . 45
2.10 Denition der Tabelle KartonInhalt als Sicht auf dem neuen Schema . 45
2.11 Anfrage mit eingesetzten Sichten-Denitionen . . . . . . . . . . . . . 46
4.1
Schema der neuen Strategie . . . . . . . . . . . . . . . . . . . . . . . 54
ix
Abbildungsverzeichnis
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
4.10
4.11
4.12
4.13
4.14
4.15
Visual
Visual
Visual
Visual
SQL: Projektion und Selektion (mit AND) . . . . . . . . .
SQL: Group By, Order By und abgeleitetes Attribut . . . .
SQL: natürlicher Verbund . . . . . . . . . . . . . . . . . .
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 . . . . . . . .
4.16
4.17
4.18
4.19
4.20
4.21
4.22
4.23
. .
. .
. .
. .
. .
. .
. .
. .
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 . . .
5.1
5.2
Zwei Beispielproduktionen der Grammatik in JJTree-Syntax . . . . . 72
Übersetzer-Ergebnis der zu Abb. 4.5 gehörenden SQL-Anfrage . . . . 74
7.1
Reengineering von Anfragen mittels Visual SQL . . . . . . . . . . . . 79
A.1
A.2
A.3
A.4
Notation
Notation
Notation
Notation
ER-Modell:
ER-Modell:
ER-Modell:
ER-Modell:
Entität . . . . . . . . . . . . . . .
Beziehung . . . . . . . . . . . . .
Rollen und Kardinalitäten . . . .
Spezialisierung / Generalisierung
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
57
57
58
58
59
60
60
60
61
61
62
62
62
63
63
64
64
65
65
65
66
66
81
82
82
83
B.1 Relationales Schema des Weinherstellungsbeispiels . . . . . . . . . . . 91
x
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
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 davon1 , 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 an2 .
1 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.
2
1.2 Die Lösung: Migration
1.2.1 Ü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.
1.2.2 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.
1.2.3 Ü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
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
1.3 Migrationsstrategien
1.3.1 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
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 TurkeyStrategie 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
1.3 Migrationsstrategien
1.3.2 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
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 InkrementGröÿ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
1.3 Migrationsstrategien
1.3.3 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. ButteryMethode 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) ; DataTransformer ; Termination-Condition und Treshold Value.
Legacy SampleData ist eine repräsentative Teilmenge der Daten in der ErbschaftsDatenbank, 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
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,
delete)
update,
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
5.
vom
TempStore auf read-only gesetzt und ein neuer TempStore wird aktiviert.
Die Daten (beziehungsweise die Datenmanipulationen) vom ersten
TempStore wer-
den zum Zielsystem transferiert.
6.
Während dieser Datenmigration werden alle Datenmanipulationen im nächsten
TempStore gespeichert.
7.
Termination-Condition erreicht ist, und die
TempStores unterhalb einer vorgegebenen Schranke (dem Tres-
Dies wiederholt sich solange, bis die
Gröÿe des letzten
hold 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
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 Sn (aus [39])
In Abbildung 1.7 ist eine Übersicht der in [39] genannten Phasen der ButteryMethode 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
Sample DataStore, basierend auf den Beispieldaten Target SampleData im Zielsystem
2.
Aufbauen eines
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
1 Einführung zur Migration von Erbschaftsinformationssystemen
1.3.4 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 1.3.1 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
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
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 1.3.3 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 DataAccess-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.
3 Auf entsprechende Merkmale, welche die Zerlegbarkeit der Architektur betreen, wird in Abschnitt 1.4 eingegangen.
14
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 weniger4 , 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 Archi4 Erinnerung: Die Migration zeichnet sich durch Wiederverwendung aus. Bei umfangreicher Neuentwicklung handelt es sich um ein Redevelopment-Projekt (vgl. Abschnitt 1.2).
15
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.
1.4.1 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
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
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
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.
1.4.2 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 AArchitektur 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
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 1.3.1 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 Neuplanung6 soweit wie möglich durch
eine radikale Vereinfachung der Informationssysteme vermieden werden und
6 engl. Reengineering, siehe Abschnitt 1.2
20
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
1 Einführung zur Migration von Erbschaftsinformationssystemen
22
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
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 Anwendungsfalls2 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
2.1 Aufgaben der Datenbankmigration
2.1.1 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
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 1.3.1 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-RelationshipModell (ER-Modell, siehe [34]). Dieser Vorgang wird auch als Reverse Engineering
bezeichnet4 . 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
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
2.1.2 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
2 Überblick zur Migration von Datenbanken
• innerhalb einer Anwendung denierte Datenbank-Befehle,
Anfragen (z.B. DQL6 : select)
Daten-Manipulationen (z.B. DML7 : insert, update,delete)
Denitionen (z.B. DDL8 : create, alter, drop)
Steuerung (z.B. DCL9 : grant, revoke)
• ad-hoc-Befehle10 ,
• 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 SchemaTransformationsfunktion, 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
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
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 + 126 bis 1.0E + 126 enthalten sind, weil dieser Datentyp beim
SQL Server Werte im Bereich - 1.79E + 308 bis 1.79E + 308 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
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: @@daterst, Oracle: nicht vorhanden)
• Cursor-Funktionen (SQL Server: @@cursor_rows, 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
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]):
• 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
32
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 WhereKlausel 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 werden13 .
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
2 Überblick zur Migration von Datenbanken
3+5. 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 Oracle spezisch 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
34
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
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 Syntax14 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 KomponentenAnfragen 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
2.2 DBMS-Unterschiede
• ORDER BY-Klausel
NULL-Werte
Der SQL Server behandelt NULL als den kleinsten möglichen Wert (al-
so 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
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.
2.3.1 Herkunft / Hintergrund
Dem nun folgenden Beispiel liegt eine reale Anwendung aus der Praxis zugrunde,
nämlich ein Warenwirtschaftssystem mit integrierten PPS15 -Modulen. Der in dieser Arbeit untersuchte Teil der zugehörigen Datenbank16 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.17
15 Produktionsplanung und -Steuerung
16 Bei der untersuchten Beispielanwendung handelt es sich um eine Microsoft SQL Server 2000 Datenbank.
17 Ausführliche Informationen zum Thema Wein und dessen Herstellung werden beispielsweise in
[30] angeboten.
38
2.3 Ein Beispiel
2.3.2 Das Datenbankschema
In Abbildung 2.3 ist das konzeptionelle Schema des Beispiels im ER-Modell18 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 Datenmodell19 (RDM).
2.3.3 Reengineering des Schemas
In Abschnitt 2.1.1 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
2 Überblick zur Migration von Datenbanken
Abbildung 2.3: Konzeptionelles Schema des Weinherstellungsbeispiels
40
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 Schema21 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
gibt23 , 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
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 entfernt24 (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 Kennzeichen25 , 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 0.
26 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
2.3 Ein Beispiel
2.3.4 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 Anfragen27 anpassen muss. Wie in Abschnitt
27 In Sichtendenitionen, in gespeicherten Prozeduren, im Programmcode, . . .
43
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
2.1.1 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
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
2 Überblick zur Migration von Datenbanken
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
46
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 2.1.1 vorgestellt, da auf diese
Weise die auf dem ursprünglichen Datenschema denierten Sichten migriert werden
können1 , und es wurde in Abschnitt 2.3.4 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 werden2 . 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
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
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
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
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 2.1.1 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 SQLDialekte (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 SchemaMigration 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
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
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 2.1.1 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
4 Konzeptionelle Migration von Anfragen
wobei als Werkzeug für diesen Mechanismus Visual SQL1 [36, 37] gewählt wird,
da es u.a. eine Formulierung von Anfragen ermöglicht, die sich stark an das ERParadigma 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
54
Visual SQL angegeben.
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.2
1. 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 DatenbankProgrammierung 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
4 Konzeptionelle Migration von Anfragen
4.3.1 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, ALTER 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. 4
4.3.2 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 < '01.01.2006'
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 HERM5 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
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 = '01.03.2006'
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 = '01.03.2006';
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
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
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.
4.4.1 Beispiel 1: Dekomposition eines Entity-Typs
Während der in Abschnitt 2.3.3 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 Artikel6 , 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 2.3.4 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 2.3.4 begründet.
59
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.
Abbildung 4.9: Beispiel 1: Formulierung der Anfrage in Visual SQL
60
4.4 Durchführung an Beispielen
Die an die Gruppierung gehefteten Attribute (erkennbar an der gestrichelten Umrandung) bilden dabei die Ausgabe der Hauptanfrage8 . 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 inkrementiert9 (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
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 handelt10 . 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
62
Artikel und Wein um einen LEFT OUTER JOIN handelt.
4.4 Durchführung an Beispielen
4.4.2 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 Sichtendenitionen 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 Anfrage11 (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
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 ist12 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
12 Es ist in
Visual SQL nicht möglich, ein Attribut mehrfach in das Ergebnis der Anfrage aufzu-
nehmen, siehe [36].
64
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
4.4.3 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 DatenbankSchemas handelt13 , 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
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 SQLDialekten, 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
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
4 Konzeptionelle Migration von Anfragen
68
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 SQL92Standards durch T-SQL lassen sich dann jedoch auch allgemeinere SQL-Anfragen
übersetzen, sofern sie diesem Standard entsprechen.
69
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 DTD1 beschriebene XML-Format gewählt, das von VisualSQL zur
Abspeicherung von Anfragen verwendet wird.2
5.4 Ein- und Ausgabe
Der Aufruf des Übersetzers in der Konsole benötigt die Angabe der folgenden drei
Parameter
1. der Name der VSQ-Datei3 , 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
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.
5.5.1 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
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 JJTreeSyntax, 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
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.
5.5.2 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
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.
• 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)
74
5.7 Einschränkungen der Übersetzung
• Die CASE-Funktion. Insbesondere, wenn darin noch Unteranfragen verwendet
werden (siehe Abb. 2.11).
Da der volle Umfang der Anfragen-Übersetzung den Rahmen dieser Diplomarbeit
sprengen würde, konnten u.a. die folgende Aspekte nicht realisiert werden:
• Die meisten Unteranfragen können nur geparst, aber nicht übersetzt werden.
Unteranfragen innerhalb der From-Klausel, also abgeleitete Tabellen, werden
übersetzt (die Verschachtelung wird dabei aufgelöst, s.o.). Andere Unteranfragen (z.B. in der Auswahlliste) werden nur zu textuellen Bedingungen übersetzt.
Korrelierte Unteranfragen können nicht übersetzt werden.
• NOT in booleschen Ausdrücken wird teilweise nicht übersetzt
• HAVING-Klauseln werden nicht übersetzt
75
5 Implementierung der konzeptionellen Migration von Anfragen
76
6 Zusammenfassung
In dieser Diplomarbeit wurde die funktionale Migration für Anfragen untersucht.
Dazu wurde zunächst das allgemeine Problem der Migration von Erbschaftsinformationssystemen und anschlieÿend der darin enthaltene Themenbereich der Datenbankmigration vorgestellt, dem diese Aufgabe zuzuordnen ist. Es wurde beschrieben
sowie anhand eines Beispiels veranschaulicht, wie der bisherige Zugang zur Migration von Anfragen ist, und es wurde festgestellt, dass neue Mechanismen erforderlich
sind, um den gestellten Anforderungen gerecht zu werden.
Daher wurde im Anschluÿ an diese Untersuchungen ein neuer Zugang zu dem
Problem der funktionalen Migration für Anfragen vorgestellt, der sich diesen Anforderungen annimmt und sich dabei an den bekannten Mechanismen der strukturellen
Migration orientiert. Analog zum ER-Modell für Datenbankschemata, wurde Visual SQL zur konzeptionellen Repräsentation für Anfragen gewählt, mit deren Hilfe
eine Wiederbetrachtung und Aufbereitung im Zuge der funktionalen Migration für
Anfragen möglich ist.
Im weiteren Verlauf dieser Arbeit erfolgte eine Machbarkeitsstudie dieser konzeptionellen funktionalen Migration. Darin wurde gezeigt, dass dieser Zugang für
eine Menge von Anfragen an ein gegebenes Datenbankschema, unter der Voraussetzung eines gegebenen Ziel-Datenbankschemas und einer gegebenen Abbildungsfunktion zwischen diesen beiden Schemata, eine gut unterstützte Entwicklung der
entsprechenden Anfrage-Menge für das Ziel-Datenbankschema ermöglicht, wobei die
gestellten Anforderungen durchaus umsetzbar sind.
Es zeigte sich jedoch, dass Mechanismen erforderlich sind, welche die Transformation der ursprünglichen Anfragen nach Visual SQL und die der dort angepassten
Anfragen zurück nach SQL unterstützen bzw. übernehmen. Solche Übersetzer müssen aufgrund der Vielfalt der existierenden SQL-Dialekte DBMS-spezische Prole
besitzen, um möglichst universell anwendbar zu sein. Anhand eines bereits existierenden Übersetzers, der im Rahmen dieser Diplomarbeit entwickelt wurde, ist
allerdings auch diese Anforderung als erfüllbar anzusehen.
Auÿerdem wurde festgestellt, dass dieser Zugang auch Einschränkungen besitzt
und daher ebenfalls, wie auch die bisherigen Verfahren, nicht universell anwendbar
ist. Als Erweiterung zu den Verfahren kann hiermit allerdings ein hoher Nutzen
erzielt werden.
77
6 Zusammenfassung
78
7 Ausblick
Mit dem in dieser Arbeit vorgestellten Verfahren ist zusätzlich zur Unterstützung der
funktionalen Migration auch eine Möglichkeit zur Analyse und zum Reengineering
von SQL-Anfragen aufgezeigt worden. Denn auch ohne Migrationsabsichten kann
man zukünftig ein Reengineering von komplexen Anfragen durchführen, indem man
sie in eine visuelle Repräsentation überführt, dort einer Wiederbetrachtung unterzieht und sie dann wieder zurück in den ursprünglichen SQL-Dialekt übersetzt (siehe
Abbildung 7.1).
Abbildung 7.1: Reengineering von Anfragen mittels Visual SQL
Ebenfalls in dieser Abbildung bereits angedeutet ist die denkbare Erweiterung
durch einen sog. Problem-Detektor, der für eine gegebene Visual SQL-Anfrage
(und damit verbunden ein gegebenes Datenbankschema) potentiell kritische Teile
der Anfrage hervorhebt. Als Probleme hierbei könnten u.a. die in Abschnitt 4.4
untersuchten Fälle speziziert werden. Auf diese Weise könnte der Anwender auf
einen solchen Fall aufmerksam gemacht werden, so dass er die Möglichkeit erhält,
das Problem zu lösen bzw. eine Vereinfachung der Anfrage vorzunehmen.
Auÿerdem ist auf diese Weise eine alternative Migration von Sichten möglich, denn
79
7 Ausblick
die sichtendenierenden Anfragen können nun anders als bisher (siehe Abschnitt
2.1.1) ebenfalls mit dem hier vorgestellten Verfahren migriert werden.1
Möglicherweise ist dieses Verfahren auch auf die Daten-Manipulationssprache erweiterbar, denn diese ist für Visual SQL ebenfalls bereits deniert worden [36, 37].
In der derzeitigen Implementierung (vgl. [1]) ist sie jedoch noch nicht enthalten.
1 Die
80
Visual SQL-Implementierung unterstützt bereits die Denition und Anpassung von Sichten.
Anhang A
Erklärung der verwendeten
Notation für das ER-Modell
Die in dieser Arbeit gezeigten ER-Modelle wurden mit dem Modellierungstool DBMain erstellt, dessen Notation hier nun kurz erläutert wird.
Entität (Entity)
In Abbildung A.1 ist die Notation einer Entität gezeigt. Sie beinhaltet den Namen der Entität (Vorgang ), und darunter die Namen der Attribute, wobei das
Primärschlüssel-Attribute unterstrichen dargestellt sind, und zusätzlich ist der Primärschlüssel-Constraint noch einmal in Form von id: <Attributname> unter den
Attributen aufgeführt.
Abbildung A.1: Notation ER-Modell: Entität
81
Anhang A Erklärung der verwendeten Notation für das ER-Modell
Beziehung (Relationship)
Beziehungen haben bis auf die äuÿere Form die gleiche Notation wie Entitäten,
denn bei Beziehungen wird nicht das Rechteck, sondern das Sechseck verwendet
(siehe Abbildung A.2).
Abbildung A.2: Notation ER-Modell: Beziehung
Rollen und Kardinalitäten
Die an einer Beziehung beteiligten Entitäten (die sog. Rollen) werden mit der Beziehung verbunden und auf die jeweilige Verbindungslinie wird die Kardinalität der
entsprechenden Rolle geschrieben (siehe Abb. A.3). Dabei gibt die Kardinalität an,
wie oft eine Rolle an der Beziehung teilnehmen darf. In dem gezeigten Beispiel bedeutet dies, dass ein Vorgang 0-N Teilschritte haben kann (also muss ein Vorgang
keinen Teilschritt besitzen, darf aber beliebig viele haben) und dass ein Vorgangsschritt Teilschritt von genau einem Vorgang ist (also muss ein Vorgangsschritt zu
mindestens einem Vorgang gehören und darf dann nicht zusätzlich noch zu einem
anderen gehören).
Abbildung A.3: Notation ER-Modell: Rollen und Kardinalitäten
82
Spezialisierung / Generalisierung
(IS-A-Relationship)
Das letzte im Beispielschema verwendete Konstrukt ist die Spezialisierung bzw.
Unter- / Obertyp-Beziehung (siehe Abb. A.4). Dabei ist die Obertyp-Rolle (hier:
Artikel) über eine stärkere Linie mit dem Symbol der IS-A - Beziehung (dem Dreieck) verbunden als die Untertyp-Rolle (hier: Wein). Die in Abbildung A.4 gezeigte
Situation bedeutet also, das Wein ein spezieller Artikel ist und zusätzlich zu den
normalen Artikel-Eigenschaften (Nummer,Bezeichnung ) noch weitere Eigenschaften (Jahrgang, . . . ) besitzt.
Abbildung A.4: Notation ER-Modell: Spezialisierung / Generalisierung
83
Anhang A Erklärung der verwendeten Notation für das ER-Modell
84
Anhang B
Dokumentation des Beispiels
B.1 ER-Modell: Entitäten
In diesem Abschnitt werden die im ER-Modell des Beispielschemas (siehe Abb. 2.3)
enthaltenen Entitäts-Typen kurz beschrieben. Die Attribute der Typen werden allerdings nur dann beschrieben, wenn ihre Namen nicht für sich sprechen, wobei die
in Klammern eingeschlossen Attribute für diejenigen Attribute stehen, die durch
die Transformation in das relationale Modell entstehen1 (Fremdschlüssel-Attribute,
siehe Abb. B.1). Die Beschreibung der Fremdschlüssel besteht dabei aus dem Namen der referenzierten Entität sowie dem Namen der entsprechenden Beziehung in
Klammern dahinter.
Traube
Der Entitäts-Typ Traube ist für die Speicherung von Informationen zu den verwendeten Traubensorten vorgesehen.
Ident
Bezeichnung
Sorte
Farbe
Normhektarertrag
Charakteristik
(künstlicher) Primärschlüssel
Ernte
Als Ernte wird hier eine zusammenghörige Menge geernteter Trauben verstanden,
welche die gleichen Eigenschaften besitzen, also die gleiche Sorte, das gleiche Erntedatum, dieselbe Herkunft usw. haben.
1 Die Transformation ins relationale Modell wurde mithilfe des Modellierungstools DB-Main
durchgeführt, wodurch die Namen der Fremdschlüssel-Attribute aus den ersten drei Buchstaben
der beteiligten Beziehung sowie dem referenzierten Primärschlüssel-Attribut generiert wurden,
und deshalb nicht unbedingt selbsterklärend sind.
85
Anhang B Dokumentation des Beispiels
Ident
Qualität
Ertrag
Datum
Mostgewicht
(Gee_Ident)
(künstlicher) Primärschlüssel
Traube (geerntete Traube)
Sammellager
In Sammellagern wird das geerntete Gut bis zur Weiterverarbeitung gelagert. Dabei
handelt es sich beispielsweise um ein Silo.
Ident
Bezeichnung
Menge
(künstlicher) Primärschlüssel
Möglicherweise ein Matchcode, der den Inhalt beschreibt
Die jeweils enthaltene Menge von Trauben
Traubenlager
Ein Traubenlager besteht aus einer Menge von Sammellagern, die gemäÿ einiger
Kriterien zu einem solchen Traubenlager zusammengefassst werden können. Die Zuordnung von Sammellagern zu Traubenlagern erfolgt über die Beziehung TraubenlagerZuordnung. Ein Sammellager kann mehreren Traubenlagern zugeordnet werden,
wenn es deren jeweiligen Kriterien entspricht. Auf diese Weise kann man beispielsweise alle Sammellager einer bestimmten Traubensorte oder einer bestimmten Ernte
zusammenfassen. (Voraussetzung für die von- und bis-Angaben ist eine gewisse
Sortierung der Eigenschaftswerte.)
(Ident)
Sorte_von
Sorte_bis
Lager (durch die Untertyp-Beziehung geerbt)
Die minimale enthaltene Traubensorte
Die maximale . . .
Lager
Alle Artikel (geerntetes Gut, Zwischenprodukte und fertiger Wein) werden in Lagern
bzw. Lagerplätzen (gleiche Adresse, aber u.a. eine andere Bezeichnung) abgelegt.
Ident
Bezeichnung
Strasse
Postleitzahl
Ort
86
(künstlicher) Primärschlüssel
B.1 ER-Modell: Entitäten
Vorgang
Mithilfe von Vorgängen wird im Wesentlichen der Einsatz der für die Verarbeitung
benötigten Maschinen geplant. Über die Beziehungen verarbeiten und Verarbeitungsort werden dabei die zu verarbeitenden Trauben und die jeweils zu verplanende Maschine angegeben.
Ident
Nummer
ErfassungsDatum
AusfuehrDatum
Status
Typ
(Ver_Ident)
(künstlicher) Primärschlüssel
nicht unbedingt eindeutige Nummer des Vorgangs
Das Datum, an dem der Vorgang geplant wurde
Das Datum, an dem der Vorgang ausgefuehrt werden soll
z.B. 'noch nicht begonnen', 'begonnen', 'beendet', . . .
z.B. 'Keltern', 'Abfüllen', 'Verpacken', . . .
Maschine (Verarbeitungsort)
Vorgangsschritt
Vorgänge können aus mehreren Vorgangsschritten bestehen, die sich sinnvoll zu einem Vorgang zusammenfassen lassen. Im Vorgangsschritt wird hauptsächlich bestimmt, welcher Artikel hergestellt werden soll. Beispielsweise können bei einem
Abfüll-Vorgang nacheinander unterschiedlich groÿe Flaschen befüllt werden.
Ident
Position
Status
(Tei_Ident)
(Erz_Ident)
(Abl_Ident)
(künstlicher) Primärschlüssel
Zur Festlegung einer Ausführungsreihenfolge
z.B. 'noch nicht begonnen', 'begonnen', 'beendet', . . .
Vorgang (Teilschritt)
Artikel (erzeugen)
Lager (Ablage)
Artikel
Artikel sind nicht nur die endgültigen, verkaufsfähigen Produkte (also der in Flaschen abgefüllte Wein), sondern auch alle während der Herstellung vorkommenden
Zwischenprodukte.
Ident
Nummer
Bezeichnung
(künstlicher) Primärschlüssel
Nicht unbedingt eindeutige Artikelnummer
Wein
Weine sind spezielle Artikel, nämlich die verkaufsfähigen Endprodukte der Weinherstellung (in Flaschen abgefüllter Wein), und haben als Untertyp von Artikel zusätzlich zu den allgemeinen Artikel-Eigenschaften weitere, spezielle Eigenschaften.
87
Anhang B Dokumentation des Beispiels
(Ident)
AlkoholVolProz
SO2Gehalt
Saeure
Artikel (durch die Untertyp-Beziehung geerbt)
Alkoholanteil
Enthaltenes Schwefeldioxid
Säuregehalt
Maschine
Hier werden Informationen über die vorhandenen Maschinen hinterlegt. Dabei kann
es sich beispielsweise um eine Kelter- oder eine Um- bzw. Abfüll-Anlage handeln.
Ident
Bezeichnung
(künstlicher) Primärschlüssel
Karton
Kartons sind die Einheit für das Verkaufslager. In Kartons verpackte Weinaschen
können verkauft werden oder aber auch wieder entnommen und in andere Kartons
verpackt werden. Der Inhalt eines Kartons kann sich also während seiner Lagerzeit
noch ändern.
Ident
Groesse
PackDatum
Status
(Ver_Ident)
(Lag_Ident)
(künstlicher) Primärschlüssel
Kennzeichen für die Flaschengröÿe und die mögliche Stückzahl
Das Datum, an dem der Karton gepackt wurde
z.B. 'verkauft', 'reserviert', . . .
Vorgangsschritt (verpacken)
Lager (Lagerort)
B.2 ER-Modell: Beziehungen
geernteteTraube
Hierüber wird einer Ernte zugeordnet, welche Traubensorte geerntet wurde.
einlagern
Hierüber wird zugeordnet, in welche(s) Sammellager eine Ernte eingelagert wird.
Eine Ernte kann auf mehrere Sammellager verteilt werden, und ein Sammellager
kann Anteile aus mehreren Ernten enthalten.
(E_E_Ident)
(Ident)
88
Ernte
Sammellager
B.2 ER-Modell: Beziehungen
verarbeiten
Hierüber wird für die Vorgänge bestimmt, welche Menge an Trauben jeweils aus
welchem Sammellager verarbeitet werden soll.
Ident
Menge
Vollstaendig
(V_V_Ident)
(V_S_Ident)
(künstlicher) Primärschlüssel
Enthält die zu verarbeitende Menge
'Ja', wenn das komplette Sammellager verarbeitet werden soll
Vorgang
Sammellager
Verarbeitungsort
Legt fest, welche Maschine für einen Vorgang eingeplant wird.
Teilschritt
Ordnet einzelne Vorgangsschritte dem jeweiligen Vorgang zu.
erzeugen
Ermöglicht (und erzwingt) die Angabe von jeweils einem zu erzeugenden Artikel pro
Vorgangsschritt.
verpacken
Beinhaltet für jeden Karton die Information, durch welchen Vorgangsschritt er gepackt wurde.
Ablage
Bestimmt, in welchem Lager ein Artikel (kann dann auch ein gepackter Karton sein)
nach der Erzeugung abgelegt werden soll.
Lagerort
Beschreibt, in welchem Lager sich ein Karton bendet (aktuell). Dies muss nicht
mehr derselbe Ort sein, der bei dem verpackenden Vorgangsschritt hinterlegt wurde.
KartonInhalt
Hierüber wird die Verbindung zwischen Kartons und den enthaltenen Artikeln hergestellt. Üblicherweise enthält ein Karton nur eine Sorte Wein, aber es kann auch
89
Anhang B Dokumentation des Beispiels
vorkommen, dass er mehrere verschiedene enthält (z.B. je zwei Flaschen von drei
Weinsorten bei einer Kartongröÿe von sechs Flaschen).
Ident
Stueck
(K_K_Ident)
(K_A_Ident)
(künstlicher) Primärschlüssel
Flaschenanzahl des Artikels
Karton
Artikel
TraubenlagerZuordnung
Hierüber wird zugeordnet, aus welchen Sammellagern ein Traubenlager besteht (siehe Entität Traubenlager)
Ident
(T_S_Ident)
(T_T_Ident)
(künstlicher) Primärschlüssel
Sammellager
Traubenlager
Teilverwendung
Protokolliert im Wesentlichen den Transfer von Trauben zwischen Sammellagern
und Maschinen.
Ident
(künstlicher) Primärschlüssel
Datum
Datum (und Uhrzeit) der Aktion
Aktion
z.B. 'autom. Zugang', 'man. Abgang'
Menge
Menge der von der Aktion betroenen Trauben
(T_S_Ident) an der Aktion beteiligtes Sammellager
(T_M_Ident) an der Aktion beteiligtes Traubenlager
90
B.3 Relationales Datenmodell
B.3 Relationales Datenmodell
In Abbildung B.1 ist das Beispielschema im relationalen Datenmodell abgebildet. Es
wurde mithilfe des Modellierungstools DB-Main aus dem konzeptionellen Schema
(siehe Abb. 2.3) generiert. Daraus wurde eine SQL Server 2000 Datenbank erzeugt,
für die dann das in Abbildung B.1 gezeigte Datenbankdiagramm erstellt wurde. Die
Beschreibung der Tabellen und Attribute (inklusive der durch die Transformation
vom konzeptionellen ins relationale Datenmodell entstandenen) ist in den Abschnitten B.1 und B.2 angegeben.
Abbildung B.1: Relationales Schema des Weinherstellungsbeispiels
91
Anhang B Dokumentation des Beispiels
92
Anhang C
DTD für VisualSQL-Dateien
<!-- Das Wurzel-Dokument, es beinhaltet das Datenbankmodell und die Anfrage -->
<!ELEMENT vsq (Modell,Query*)>
<!-- Das Datenbankmodell bestehend aus Listen von Entitaeten,
Relationen und Sichten -->
<!ELEMENT Modell (entities,relations,views)>
<!-- Eine Liste von Entitaeten -->
<!ELEMENT entities (Entity)*>
<!-- Eine Liste von Relationen -->
<!ELEMENT relations (Relation)*>
<!-- Eine Liste von Sichten -->
<!ELEMENT views (View)*>
<!-- Die Datenbankentitaeten bestehend aus Listen
von Attributen und Schluesseln -->
<!ELEMENT Entity (attributes,keys)>
<!-- Die Datenbankrelationen bestehen aus Listen
von Quell- und Ziel-Schluesseln -->
<!ELEMENT Relation (sourcekeys,destinationkeys)>
<!-- Eine Sicht die mit Hilfe einer VisualSQL-Anfrage definiert ist -->
<!ELEMENT View (Query)>
<!-- Liste von Datenbank-Attributen -->
<!ELEMENT attributes (Attribut)*>
<!-- Liste von Schluesseln -->
<!ELEMENT keys (key)*>
<!-- Liste von Quellschluesseln -->
<!ELEMENT sourcekeys (key)*>
<!-- Liste von Zielschluesseln -->
<!ELEMENT destinationkeys (key)*>
<!-- Ein Datenbankattribut, es hat keinen Wert nur Attribute -->
<!ELEMENT Attribut EMPTY>
<!-- Ein Schluessel, der nur eine Verweis auf ein Datenbankattribut hat -->
<!ELEMENT key EMPTY>
<!-- Eine Anfrage ist eine Liste eingetragenen Elemente -->
<!ELEMENT Query (Abstraction | Association | GroupBy | Having |
93
Anhang C DTD für VisualSQL-Dateien
OrderBy | QueryEntity | Selection | TemporaryTable | Distinct)*>
<!-- Die Folgenden Elemente sind die graphischen Kompomenten einer Anfrage
und koennen damit eine Liste von ConnectionPoints enthalten. Einige
enthalten weitere spezifische Elemente. -->
<!-- Teilanfrage mit ihren Anfrage-Komponenten und Aggregationen -->
<!ELEMENT Abstraction (connectionpoints,queryattributs,elements)>
<!-- Kante zwischen zwei Anfrage-Komponenten -->
<!ELEMENT Association (connectionpoints)>
<!-- Die GroupBy-Klausel mit ihrer QueryAttribut-Liste -->
<!ELEMENT GroupBy (connectionpoints,groupAttributs)>
<!-- Die Having-Komponente -->
<!ELEMENT Having (connectionpoints)>
<!-- Das Distinct-Flag -->
<!ELEMENT Distinct (connectionpoints)>
<!-- Die OrderBy-Klausel mit ihrer QueryAttribut-Liste
und der Reihenfolge zu den QueryAttributen -->
<!ELEMENT OrderBy (connectionpoints,orderAttributs)>
<!-- Die QueryEntity mit ihrer QueryAttribut-Liste,
die zu Entitaeten oder Aggregationen gehoehren -->
<!ELEMENT QueryEntity (connectionpoints,queryattributs)>
<!-- Das QueryAttribut, welches entweder zu einer Entity
oder einer Aggregation gehoert -->
<!ELEMENT QueryAttribut (connectionpoints,Aggregation?)>
<!-- Die Selections-Klausel -->
<!ELEMENT Selection (connectionpoints)>
<!-- Der TemporaryTable -->
<!ELEMENT TemporaryTable (connectionpoints)>
<!-- Aggregation enthaelt eine Liste von Attributen -->
<!ELEMENT Aggregation (attributs)>
<!-- Eine
<!ELEMENT
<!-- Eine
<!ELEMENT
Liste von ConnectionPoints -->
connectionpoints (ConnectionPoint)*>
Liste von QueryAttrbuts -->
queryattributs (QueryAttribut)*>
<!-- Eine Liste von untenstehenden Anfrage-Elementen -->
<!ELEMENT elements (Abstraction | Association | GroupBy
| Having | QueryEntity | Selection | Distinct)*>
<!-- Eine Liste von QueryAttributen -->
<!ELEMENT groupAttributs (groupAttribut)*>
<!-- Eine Liste von QueryAttributen, mit Richtung der Ordnung -->
<!ELEMENT orderAttributs (orderAttribut)*>
<!-- Eine Liste von Attributreferenzen auf Datenbankattributen -->
<!ELEMENT attributs (key)*>
<!-- Der ConnectionPoint den alle graphischen Kompomenten enthalten koennen -->
<!ELEMENT ConnectionPoint EMPTY>
94
<!ELEMENT groupAttribut EMPTY><!-- Eine Referenz auf ein QueryAttribut -->
<!ELEMENT orderAttribut EMPTY><!-- Eine Referenz auf ein QueryAttribut -->
<!ATTLIST vsq version CDATA #REQUIRED><!-- Die Version des XML-Schemas -->
<!ATTLIST Modell name CDATA #REQUIRED><!-- Der Name des Datenbankmodells -->
<!ATTLIST Query nr CDATA #IMPLIED><!-- Die Nummer der Query -->
<!-- id
: Die ID der Komponente innerhalb den XML-Dokumentes,
um Referenzen zu anderen Elementen herzustellen -->
<!-- type : Der 'Herkunfts'-Type der Entity.
0 := Datenbank-Entity;
1 := Entity von einem TemporaryTable;
2 := Entity von einem View -->
<!-- name : Name der Entity -->
<!-- Nr
: Nummer der Entity im Datenbankmodell -->
<!ATTLIST Entity
id ID #REQUIRED
type (0|1|2) #REQUIRED
name CDATA #REQUIRED
Nr CDATA #REQUIRED
>
<!-- Die ID der Komponente innerhalb den XML-Dokumentes,
um Referenzen zu anderen Elementen herzustellen -->
<!-- Name der Relation -->
<!-- Die ID der Source-Entity dieser Relation -->
<!-- Die ID der Destinaton-Entity dieser Relation -->
<!-- Nummer der Relation im Datenbankmodell -->
<!ATTLIST Relation
id ID #REQUIRED
name CDATA #REQUIRED
source_id IDREF #REQUIRED
destination_id IDREF #REQUIRED
Nr CDATA #REQUIRED
>
<!-- Die ID der Komponente innerhalb den XML-Dokumentes,
um Referenzen zu anderen Elementen herzustellen -->
<!-- Name der Attributs -->
<!-- Der Datentype des Attributs. Die Werte sind:
1 := NUM; 2 := FLOAT; 3 := CHAR; 4 := VARCHAR; 5 := DATE;
6 := BOOL; 7 := SEQUENCE; 8 := INDEX; 9 := COMP -->
<!-- Die Groesse des Datentypes -->
<!-- Nummer des Attributs in der Entity -->
<!ATTLIST Attribut
id ID #REQUIRED
name CDATA #REQUIRED
type (1|2|3|4|5|6|7|8|9) #REQUIRED
95
Anhang C DTD für VisualSQL-Dateien
size CDATA #REQUIRED
Nr CDATA #REQUIRED
>
<!-- Die ID der Komponente innerhalb den XML-Dokumentes,
um Referenzen zu anderen Elementen herzustellen -->
<!-- Die ID der Entity die von diesem View definiert wird. -->
<!-- Der Name des Views -->
<!-- Die Nummer des View im Datenbankmodell -->
<!ATTLIST View
id ID #REQUIRED
entity_id CDATA #REQUIRED
name CDATA #REQUIRED
Nr CDATA #REQUIRED
>
<!-- Die Nummer des Keys in der Attributliste -->
<!-- Die ID des Attributs zu diesem Key -->
<!ATTLIST key
Nr CDATA #REQUIRED
attribut_id CDATA #REQUIRED
>
<!-- Die ID der Komponente innerhalb den XML-Dokumentes,
um Referenzen zu anderen Elementen herzustellen -->
<!-- X-Koordinate der Abstraction -->
<!-- Y-Koordinate der Abstraction -->
<!-- Breite der Abstraction -->
<!-- Hoehe der Abstraction -->
<!-- Schachteltiefe der Komponente -->
<!-- Die Breite der evt. vorhandenen Aggregations-Attribute -->
<!-- Die Hoehe der evt. vorhandenen Aggregations-Attribute -->
<!-- Der Type der Abstraction. Die Werte sind:
0 := Standard SubQuery; 1 := Exists SubQuery; 2 := not exists SubQuery -->
<!ATTLIST Abstraction
id ID #REQUIRED
x CDATA #REQUIRED
y CDATA #REQUIRED
width CDATA #IMPLIED
height CDATA #IMPLIED
depth CDATA #REQUIRED
ag_width CDATA #IMPLIED
ag_height CDATA #IMPLIED
type (0|1|2) "0"
>
<!-- Die ID der Komponente innerhalb den XML-Dokumentes,
um Referenzen zu anderen Elementen herzustellen -->
<!-- X-Koordinate der Association -->
<!-- Y-Koordinate der Association -->
96
<!-- Breite der Association -->
<!-- Hoehe der Association -->
<!-- Schachteltiefe der Komponente -->
<!-- Name der Association -->
<!-- Der Type der Association. Die Werte sind:
0 := Standard; 1 := Join -->
<!-- Die ID der Source-Komponente dieser Association -->
<!-- Die ID des ConnectionPoints der Source-Komponente dieser Association -->
<!-- Der Pfeiltype am Source-Ende. Die Werte sind:
0 := Standard-Ende;
1 := Outer-Join-Ende -->
<!-- Die ID der Destination-Komponente dieser Association -->
<!-- Die ID des ConnectionPoints der Destination-Komponente
dieser Association -->
<!-- Der Pfeiltype am Destination-Ende. Die Werte sind:
0 := Standard-Ende;
1 := Outer-Join-Ende -->
<!-- Gibt die Breite der Linie an.
Die Linie ist nur umrandet und nicht gefuellt. -->
<!ATTLIST Association
id ID #REQUIRED
x CDATA #IMPLIED
y CDATA #IMPLIED
width CDATA #IMPLIED
height CDATA #IMPLIED
depth CDATA #REQUIRED
name CDATA #REQUIRED
type (0|1) "0"
source_id IDREF #REQUIRED
sPoint_id IDREF #REQUIRED
sourcetype (0|1) #REQUIRED
destination_id IDREF #REQUIRED
dPoint_id IDREF #REQUIRED
destinationtype (0|1) #REQUIRED
linewidth CDATA #REQUIRED
>
<!-- Die ID der Komponente innerhalb den XML-Dokumentes,
um Referenzen zu anderen Elementen herzustellen -->
<!-- X-Koordinate der GroupBy-Komponente -->
<!-- Y-Koordinate der GroupBy-Komponente -->
<!-- Breite der GroupBy-Komponente -->
<!-- Hoehe der GroupBy-Komponente -->
<!-- Schachteltiefe der Komponente -->
<!-- Die ID der Kompmente zu der dieses GroupBy gehoert.
Es koennen nur QueryEntity- oder Abstraction-IDs sein -->
<!ATTLIST GroupBy
id ID #REQUIRED
x CDATA #REQUIRED
y CDATA #REQUIRED
97
Anhang C DTD für VisualSQL-Dateien
width CDATA #IMPLIED
height CDATA #IMPLIED
depth CDATA #REQUIRED
source_id IDREF #REQUIRED
>
<!-- Die ID der Komponente innerhalb den XML-Dokumentes,
um Referenzen zu anderen Elementen herzustellen -->
<!-- X-Koordinate der Having-Komponente -->
<!-- Y-Koordinate der Having-Komponente -->
<!-- Breite der Having-Komponente -->
<!-- Hoehe der Having-Komponente -->
<!-- Schachteltiefe der Komponente -->
<!ATTLIST Having
id ID #REQUIRED
x CDATA #REQUIRED
y CDATA #REQUIRED
width CDATA #IMPLIED
height CDATA #IMPLIED
depth CDATA #REQUIRED
>
<!-- Die ID der Komponente innerhalb den XML-Dokumentes,
um Referenzen zu anderen Elementen herzustellen -->
<!-- X-Koordinate der Distinct-Komponente -->
<!-- Y-Koordinate der Distinct-Komponente -->
<!-- Breite der Distinct-Komponente -->
<!-- Hoehe der Distinct-Komponente -->
<!-- Schachteltiefe der Komponente -->
<!ATTLIST Distinct
id ID #REQUIRED
x CDATA #REQUIRED
y CDATA #REQUIRED
width CDATA #IMPLIED
height CDATA #IMPLIED
depth CDATA #REQUIRED
>
<!-- Die ID der Komponente innerhalb den XML-Dokumentes,
um Referenzen zu anderen Elementen herzustellen -->
<!-- X-Koordinate der OrderBy-Komponente -->
<!-- Y-Koordinate der OrderBy-Komponente -->
<!-- Breite der OrderBy-Komponente -->
<!-- Hoehe der OrderBy-Komponente -->
<!-- Schachteltiefe der Komponente -->
<!ATTLIST OrderBy
id ID #REQUIRED
x CDATA #REQUIRED
y CDATA #REQUIRED
width CDATA #IMPLIED
98
height CDATA #IMPLIED
depth CDATA #REQUIRED
>
<!-- Die ID der Komponente innerhalb den XML-Dokumentes,
um Referenzen zu anderen Elementen herzustellen -->
<!-- X-Koordinate der QueryEntity -->
<!-- Y-Koordinate der QueryEntity -->
<!-- Breite der QueryEntity -->
<!-- Hoehe der QueryEntity -->
<!-- Schachteltiefe der Komponente -->
<!-- Die ID der Entity auf die sich diese QueryEntity bezieht -->
<!-- Anfrage-Name der QueryEntity -->
<!-- Die Breite der evt. vorhandenen Aggregations-Attribute -->
<!-- Die Hoehe der evt. vorhandenen Aggregations-Attribute -->
<!ATTLIST QueryEntity
id ID #REQUIRED
x CDATA #REQUIRED
y CDATA #REQUIRED
width CDATA #IMPLIED
height CDATA #IMPLIED
depth CDATA #REQUIRED
source_id IDREF #REQUIRED
name CDATA #REQUIRED
ag_width CDATA #IMPLIED
ag_height CDATA #IMPLIED
>
<!-- Die ID der Komponente innerhalb den XML-Dokumentes,
um Referenzen zu anderen Elementen herzustellen -->
<!-- X-Koordinate der Selection -->
<!-- Y-Koordinate der Selection -->
<!-- Breite der Selection -->
<!-- Hoehe der Selection -->
<!-- Schachteltiefe der Komponente -->
<!-- Die Selections-Bedingung als Text -->
<!ATTLIST Selection
id ID #REQUIRED
x CDATA #REQUIRED
y CDATA #REQUIRED
width CDATA #IMPLIED
height CDATA #IMPLIED
depth CDATA #REQUIRED
selection CDATA #REQUIRED
>
<!-- Die ID der Komponente innerhalb den XML-Dokumentes,
um Referenzen zu anderen Elementen herzustellen -->
<!-- X-Koordinate des TemporaryTable -->
<!-- Y-Koordinate des TemporaryTable -->
99
Anhang C DTD für VisualSQL-Dateien
<!-- Breite des TemporaryTable -->
<!-- Hoehe des TemporaryTable -->
<!-- Schachteltiefe der Komponente -->
<!-- Die ID der Entity die von diesem Temporary Table definiert wird. -->
<!-- Name des TemporaryTables -->
<!ATTLIST TemporaryTable
id ID #REQUIRED
x CDATA #REQUIRED
y CDATA #REQUIRED
width CDATA #IMPLIED
height CDATA #IMPLIED
depth CDATA #REQUIRED
entity_id IDREF #REQUIRED
name CDATA #REQUIRED
>
<!-- Die ID der Komponente innerhalb den XML-Dokumentes,
um Referenzen zu anderen Elementen herzustellen -->
<!-- X-Koordinate des QueryAttribut -->
<!-- Y-Koordinate des QueryAttribut -->
<!-- Breite des QueryAttribut -->
<!-- Hoehe des QueryAttribut -->
<!-- Schachteltiefe der Komponente -->
<!-- Die ID der Komponente zu welcher diese QueryAttribut gehoert.
Komponenten koennen sein QueryEntity, Abstraction und TemporaryTable -->
<!-- Steht dieses 'Query'-Attribut im Anfrage-Ergebnis. -->
<!-- Wird dieses 'Query'-Attribut in der Anfrage angezeigt. -->
<!-- Die Stelle an der dieses 'Query'-Attribut im Anfrage-Ergebnis steht -->
<!-- Die ID des Datenbank-Attributs, falls vorhanden. Es ist nur vorhanden,
wenn keine Aggregation zu diesem QueryAttribut vorhanden ist. -->
<!-- Die Nummber des QueryAttributs in der Source-Komponente -->
<!ATTLIST QueryAttribut
id ID #REQUIRED
x CDATA #IMPLIED
y CDATA #IMPLIED
width CDATA #IMPLIED
height CDATA #IMPLIED
depth CDATA #REQUIRED
source_id IDREF #REQUIRED
inresult (true|false) #REQUIRED
isshown (true|false) #REQUIRED
resultnumber CDATA #REQUIRED
attribut_id IDREF #IMPLIED
Nr CDATA #REQUIRED
>
<!-- Die ID der Komponente innerhalb den XML-Dokumentes,
um Referenzen zu anderen Elementen herzustellen -->
<!-- Der Aggregations-Type. Werte sind:
0 := COUNT; 1 := MIN; 2 := MAX; 3 := AVG; 4 := SUM -->
100
<!-- Der Name der Aggrgation -->
<!ATTLIST Aggregation
id ID #REQUIRED
type (0|1|2|3|4) #REQUIRED
name CDATA #REQUIRED
formel CDATA #IMPLIED
>
<!-- Die Nummer der Attribut-Referenz in der Attributliste -->
<!-- Die ID des Attributs zu diesem groupAttribut -->
<!ATTLIST groupAttribut
Nr CDATA #REQUIRED
attribut_id IDREF #REQUIRED
>
<!-- Die Nummer der Attribut-Referenz in der Attributliste -->
<!-- Die ID des Attributs zu diesem orderAttribut -->
<!-- Der Wert ob die Richtung 'Descending' ist.
'true' steht fuer 'Descending' und false fuer nicht 'Descending' -->
<!ATTLIST orderAttribut
Nr CDATA #REQUIRED
attribut_id IDREF #REQUIRED
direction (true|false) #REQUIRED
>
<!-- Die ID der Komponente innerhalb den XML-Dokumentes,
um Referenzen zu anderen Elementen herzustellen -->
<!-- X-Koordinate des ConnectionPoint -->
<!-- Y-Koordinate des ConnectionPoint -->
<!-- Breite des ConnectionPoint -->
<!-- Hoehe des ConnectionPoint -->
<!-- Dieser Wert beschreibt die Richtung in der eine
Association von einem ConnectionPoint abgehen kann
Die Werte sind:
0 := NONE; 1 := HORIZONTAL;
2 := VERTICAL; 3 := HORIZONTAL_VERTICAL -->
<!-- Falls 'true', kann eine Association per 'Drag and Drop' im Anfrage-Editor
von oder zu diesen ConnectionPoint gezogen werden.-->
<!-- Die Nummer des ConnectionPoint in der Komponente -->
<!ATTLIST ConnectionPoint
id ID #REQUIRED
x CDATA #REQUIRED
y CDATA #REQUIRED
width CDATA #IMPLIED
height CDATA #IMPLIED
connectionDirection (0|1|2|3) #REQUIRED
connectable (true|false) #REQUIRED
Nr CDATA #REQUIRED
>
101
Anhang C DTD für VisualSQL-Dateien
102
Anhang D
Grammatik des T-SQL-Parsers
Die hier gezeigte Grammatik des T-SQL-Parsers wurde mithilfe des JavaCC-Tools
jjdoc erzeugt.
S_Identifier
S_Quoted_Identifier
S_Char_Literal
Op
:=
:=
:=
:=
Constant
StringExpression
SelectStatement
:=
:=
:=
SelectWithoutOrder
:=
IntoClause
SelectList
:=
:=
SelectItem
:=
SelectAllItems
TableName
TableAlias
ColumnName
ColumnAlias
RelObjectName
:=
:=
:=
:=
:=
:=
FromClause
TableSource
Table
DerivedTable
JoinedTable
JoinType
:=
:=
:=
:=
:=
:=
<S_IDENTIFIER>
<S_QUOTED_IDENTIFIER>
<S_CHAR_LITERAL>
( <EQUAL> | <NEQUAL> | <LESS>
| <LEQUAL> | <GREATER> | <GEQUAL> )
<NUMBER>
S_Char_Literal
SelectWithoutOrder
( OrderByClause )? ( <SEMICOLON> )? <EOF>
SelectList ( IntoClause )?
FromClause
( WhereClause )?
( GroupByClause )?
<INTO> TableName
<SELECT> ( <ALL> | <DISTINCT> )?
( <TOP> Constant ( <PERCENT> )? )?
SelectItem ( <COMMA> SelectItem )*
( <ASTERISK>
| SelectAllItems
| ColumnAlias <EQUAL> SQLSimpleExpression
| SQLSimpleExpression ( ( <AS> )? ColumnAlias )? )
TableName <DOT> <ASTERISK>
( "#" ( "#" )? )? RelObjectName ( <DOT> RelObjectName )?
RelObjectName
RelObjectName ( <DOT> RelObjectName )?
RelObjectName
<S_IDENTIFIER>
| <S_QUOTED_IDENTIFIER>
| <S_CHAR_LITERAL>
<FROM> TableSource ( <COMMA> TableSource )*
Table ( JoinedTable )*
( DerivedTable | TableName ( ( <AS> )? TableAlias )? )
<LPAREN> SubQuery <RPAREN> ( <AS> )? TableAlias
( <CROSS> <JOIN> Table | JoinType Table JoinWhereClause )
( <LEFT> ( <OUTER> )? <JOIN>
103
Anhang D Grammatik des T-SQL-Parsers
| <RIGHT> ( <OUTER> )? <JOIN>
| <FULL> ( <OUTER> )? <JOIN>
| ( <INNER> )? <JOIN> )
JoinWhereClause
:= <ON> SQLExpression
WhereClause
:= <WHERE> SQLExpression
GroupByClause
:= <GROUP> <BY> SQLExpressionList ( HavingClause )?
HavingClause
:= <HAVING> SQLExpression
OrderByClause
:= <ORDER> <BY>
OrderByExpression ( <COMMA> OrderByExpression )*
OrderByExpression
:= SQLSimpleExpression ( <ASC> | <DESC> )?
SQLExpression
:= SQLOrExpressions
SQLOrExpressions
:= SQLOrExpression | SQLAndExpressions
SQLOrExpression
:= SQLAndExpressions ( <OR> SQLAndExpressions )+
SQLAndExpressions
:= SQLAndExpression | SQLUnaryLogicalExpressions
SQLAndExpression
:= SQLUnaryLogicalExpressions
( <AND> SQLUnaryLogicalExpressions )+
SQLUnaryLogicalExpressions := ( <NOT> )?
( ExistsClause | SQLRelationalExpressions )
ExistsClause
:= <EXISTS> <LPAREN> SubQuery <RPAREN>
SQLRelationalExpressions := SQLRelationalExpression
| ( SQLRelopExpression
| <LPAREN> SQLExpressionList <RPAREN>
| SQLSimpleExpressions )
SQLRelationalExpression := ( <LPAREN> SQLExpressionList <RPAREN>
| SQLSimpleExpressions )
( SQLInClause | SQLBetweenClause
| SQLLikeClause | IsNullClause )
SQLExpressionList
:= SQLSimpleExpression ( <COMMA> SQLSimpleExpression )*
SQLRelopExpression := ( <LPAREN> SQLExpressionList <RPAREN>
| SQLSimpleExpressions ) Relop
( ( <ALL> | <ANY> )?
<LPAREN> SubQuery <RPAREN>
| SQLSimpleExpressions )
Relop
:= ( <EQUAL> | <NEQUAL> | <LESS>
| <LEQUAL> | <GREATER> | <GEQUAL> )
SQLInClause
:= ( <NOT> )? <IN>
<LPAREN>
( SQLExpressionList | SubQuery )
<RPAREN>
SQLBetweenClause
:= ( <NOT> )? <BETWEEN>
SQLSimpleExpression <AND> SQLSimpleExpression
SQLLikeClause
:= ( <NOT> )? <LIKE> StringExpression
IsNullClause
:= <IS> ( <NOT> )? <NULL>
SQLSimpleExpression
:= SQLSimpleExpressions
SQLSimpleExpressions
:= SQLAdditiveExpressions
SQLAdditiveExpressions := SQLAdditiveExpression | SQLMultiplicativeExpressions
SQLAdditiveExpression := SQLMultiplicativeExpressions
(( <PLUS> | <MINUS> ) SQLMultiplicativeExpressions )+
SQLMultiplicativeExpressions := SQLMultiplicativeExpression | SQLUnaryExpressions
SQLMultiplicativeExpression := SQLUnaryExpressions
104
( ( <ASTERISK> | <DIV> ) SQLUnaryExpressions )+
SQLUnaryExpressions := SQLUnaryExpression | SQLPrimaryExpression
SQLUnaryExpression
:= ( <PLUS> | <MINUS> ) SQLPrimaryExpression
SQLPrimaryExpression := ( <NULL> | CaseFunction | FunctionCall
| StringExpression | ColumnName | Constant
| <LPAREN> SubQuery <RPAREN>
| <LPAREN> SQLExpression <RPAREN> )
CaseFunction
:= <CASE> ( <WHEN> SQLExpression
<THEN> SQLSimpleExpression )+
( <ELSE> SQLSimpleExpression )? <END>
FunctionCall
:= FunctionName
<LPAREN>
( ( <DISTINCT> | <ALL> )?
( FunctionArguments | <ASTERISK> ) )?
<RPAREN>
FunctionName
:= ( RelObjectName ( <DOT> RelObjectName )?
| <LEFT> | <RIGHT> )
FunctionArguments
:= SQLExpressionList
SubQuery
:= SelectWithoutOrder
105
Anhang D Grammatik des T-SQL-Parsers
106
Literaturverzeichnis
[1] André Ackermann. Diplomarbeit: Visuelle Datenbankprogrammierung, 2006.
[2] Reda Alhajj. Documenting legacy relational databases. In ER Workshops,
pages 161172, 1999.
[3] Reda Alhajj. Extracting the extended entity-relationship model from a legacy
relational database. Inf. Syst., 28(6):597618, 2003.
[4] Reda Alhajj and Faruk Polat. Database reverse engineering.
[5] Martin Andersson. Extracting an Entity Relationship Schema from a Relational Database through Reverse Engineering. In Conference on The Entity
Relationship Approach, Manchester UK, December 1994.
[6] Jesus Bisbal. A Survey of Research into Legacy System Migration, 1997.
[7] Jesus Bisbal, Deirdre Lawless, Bing Wu, and Jane Grimson. Legacy Information
System Migration: A Brief Review of Problems, Solutions and Research Issues,
1999.
[8] Jesús Bisbal, Deirdre Lawless, Bing Wu, and Jane Grimson. Legacy Information
Systems: Issues and Directions. IEEE Software, 16(5):103111, /1999.
[9] Michael L. Brodie and Michael Stonebraker. DARWIN: On the Incremental
Migration of Legacy Information Systems. Technical Report S2K-93-25, 1993.
[10] Michael L. Brodie and Michael Stonebraker. Migrating Legacy Systems - Gateways, Interfaces & The Incremental Approach. Morgan Kaufmann Publishers,
1995.
[11] Reengineering Center. Perspectives on Legacy System Reengineering. Software
Enginnering Institute at Carnegie Mello University, Pittsburg, PA, 1995.
[12] Whei-Jen Chen, Fadel Fiani, Marina Greenstein, Stefan Hummel, Ranjit K.
Kalidasan, Ken Leonard, Art Sammartino, and Artur Wronski. Oracle to IBM
DB2 UDB Conversion Guide, November 2003.
107
Literaturverzeichnis
[13] Whei-Jen Chen, Alain Fisher, Stefan Hummel, Shailendra Kishore, Wei Bin
Teah, and Ted Wasserman. Microsoft SQL Server to IBM DB2 UDB Conversion
Guide, June 2005.
[14] Microsoft Corporation. Onlinedokumentation des Microsoft SQL Server 2000.
(In der Installation enthalten, oder downloadbar unter www.microsoft.com.).
[15] Microsoft Corporation. Solution Guide for Migrating Oracle on UNIX to SQL
Server on Windows, April 2005.
[16] Oracle Corporation. Migrating Applications from Microsoft SQL Server to
Oracle9i Database, November 2003.
[17] Hong Hai Do, Sergey Melnik, and Erhard Rahm. Comparison of schema matching evaluations. In Revised Papers from the NODe 2002 Web and DatabaseRelated Workshops on Web, Web-Services, and Database Systems, pages 221
237, London, UK, 2003. Springer-Verlag.
[18] J.-L. Hainaut, M. Chandelon, C. Tonneau, and M. Joris. Contribution to a
theory of database reverse engineering. In WCRE '93: Proceedings of the 1993
Working Conference on Reverse Engineering, (Baltimore, Maryland; May 2123, 1993), pages 161170. IEEE Computer Society Press (Order Number 378002), May 1993.
[19] Jean Henrard and Jean-Luc Hainaut. Data Dependency Elicitation in Database
Reverse Engineering. In CSMR '01: Proceedings of the Fifth European Conference on Software Maintenance and Reengineering, page 11, Washington, DC,
USA, 2001. IEEE Computer Society.
[20] Jean Henrard, Jean-Luc Hainaut, Jan-Marc Hick, Didier Roland, and Vincent
Englebert. Data Structure Extraction in Database Reverse Engineering. In ER
'99: Proceedings of the Workshops on Evolution and Change in Data Management, Reverse Engineering in Information Systems, and the World Wide Web
and Conceptual Modeling, pages 149160, London, UK, 1999. Springer-Verlag.
[21] http://javacc.dev.java.net/.
[22] http://javacc.dev.java.net/doc/jjtree.html.
[23] Paul Johannesson. A method for transforming relational schemas into conceptual schemas. In Proceedings of the Tenth International Conference on Data
Engineering, pages 190201, Washington, DC, USA, 1994. IEEE Computer Society.
[24] Gregorios Koutsoukos and Mohammad El-Ramly. Practical Aspects of Software
Reengineering and Code Transformation, CAiSE'05.
108
Literaturverzeichnis
[25] Thomas Lehmann and Klaus-Dieter Schewe. A pragmatic method for the integration of higher-order entity-relationship schemata. In ER, pages 3751,
2000.
[26] N. Mfourga. Extracting entity-relationship schemas from relational databases:
A form-driven approach. In WCRE '97: Proceedings of the Fourth Working
Conference on Reverse Engineering (WCRE '97), page 184, Washington, DC,
USA, 1997. IEEE Computer Society.
[27] Renée J. Miller, Laura M. Haas, and Mauricio A. Hernández. Schema mapping
as query discovery. In VLDB '00: Proceedings of the 26th International Conference on Very Large Data Bases, pages 7788, San Francisco, CA, USA, 2000.
Morgan Kaufmann Publishers Inc.
[28] Hausi A. Müller, Jens H. Jahnke, Dennis B. Smith, Margaret-Anne Storey,
Scott R. Tilley, and Kenny Wong. Reverse Engineering: A Roadmap, 2000.
[29] MySQL 5.1 Reference Manual.
[30] Jens Priewe. Wein - Die neue groÿe Schule. Zabert Sandmann Verlag, Dezember
2005.
[31] Erhard Rahm and Philip A. Bernstein. A survey of approaches to automatic schema matching. VLDB Journal: Very Large Data Bases, 10(4):334350,
November 2001.
[32] Johannes Siedersleben. Moderne Software-Architektur. Dpunkt Verlag, 2004.
[33] Harry M. Sneed. Planning the Reengineering of Legacy Systems. IEEE Softw.,
12(1):2434, 1995.
[34] Bernhard Thalheim. Entity-Relationship Modeling: Foundations of Database
Technology. Springer-Verlag New York, Inc., Secaucus, NJ, USA, 2000.
[35] Bernhard Thalheim. Informationssystem-Entwicklung - Die integrierte Entwicklung der Strukturierung, Funktionalität, Verteilung und Interaktivität von
groÿen Informationssystemen, 2003.
[36] Bernhard Thalheim. Visual SQL - An ER-Based Introduction into Database Programming. Technical report, Brandenburg University of Technology at
Cottbus, 08 2003.
[37] Bernhard Thalheim. Tutorial: Visual SQL, An ER-Based Introduction to Database Programming. 23rd ER Conference ER'04, Shanghai, China, Nov. 2004.
109
Literaturverzeichnis
[38] Reinhard Wilhelm und Dieter Maurer. Übersetzerbau - Theorie, Konstruktion,
Generierung. Springer-Verlag, 1992.
[39] B. Wu, D. Lawless, J. Bisbal, J. Grimson, R. Richardson, and D. O'Sullivan.
The Buttery Methodology : A Gateway-free Approach for Migrating Legacy
Information Systems, 1997.
[40] Bing Wu, Deirdre Lawless, Jesus Bisbal, Jane Grimson, Vincent Wade, Donie
O'Sullivan, and Ray Richardson. Legacy Systems Migration : A Method and
its Tool-Kit Framework. In APSEC, pages 312, 1997.
110