Diplombericht Master Thesis

Diplombericht Master Thesis
Lightweight DWH Interface
in der Firma Emmi Schweiz AG
Abstract
Diese Arbeit beinhaltet das Entwickeln einer Schnittstellentechnik, welche die Daten von
einem Quellsystem in ein Datawarehouse überträgt. Hauptziel ist, die heutige Belastung der
Quellsysteme um mindestens 70% zu verringern. Auch soll der Konfigurationsaufwand neuer
Schnittstellen minimiert werden.
Klasse.Nr / Datum: MAS-07-01.21 / 27. August 2009
Experte:
Betreuer:
Student:
Thomas Glauser, Lährenbühlstrasse 14b , 8112 Otelfingen
Tel. P: +41 79 217 66 82
Tel. G: +41 52 261 57 58
E-Mail: thomas.glauser.di@bluewin.ch
Urs Müller, Forelstrasse 1, 3072 Ostermundigen
Tel. G: +41 31 930 24 84
E-Mail: urs-b.mueller@emmi.ch
Stefan Lüthi, Allmendingenstrasse 16, 3608 Thun
Tel. P: +41 79 458 46 84
Tel. G: +41 31 930 24 88
E-Mail: stefan.luethi@emmi.ch
Keywords:
10.09.2009
Datenbank, Datawarehouse, Oracle, ETL, Schnittstelle
Seite 1 von 80

Diplombericht
Master Thesis MAS-07-01.21
Änderungskontrolle
Version Datum Autor Bemerkungen
0.1 27.08.2009 Stefan Lüthi Erstellung
0.2 30.08.2009 Stefan Lüthi Testing & Planung
0.3 06.09.2009 Stefan Lüthi Anhang & Change Requests
0.4 08.09.2009 Stefan Lüthi Erfahrungen und Schlusswort
1.0 10.11.2009 Stefan Lüthi Fertigstellung
Review / Prüfung
Version Prüfdatum Prüfende Stelle Bemerkungen
Referenzierte Dokumente
Version
Dokument
10.09.2009 Seite 2 von 80

Diplombericht
Master Thesis MAS-07-01.21
Inhaltsverzeichnis
1 Allgemeines......................................................................................................... 6
1.1 Dokument ........................................................................................................ 6
1.1.1 Zweck.......................................................................................................... 6
1.1.2 Umfang........................................................................................................ 6
1.1.3 Leserkreis.................................................................................................... 6
1.1.4 Übersicht..................................................................................................... 6
1.1.5 Begriffe und Definitionen ............................................................................. 6
1.1.6 Nomenklatur................................................................................................ 6
2 Projektübersicht.................................................................................................. 7
2.1 Allgemeine Beschreibung ................................................................................ 7
2.1.1 ETL Prozess................................................................................................ 7
2.1.2 Ladeprozess kleine Tabellen ....................................................................... 8
2.1.3 Ladeprozess grosser Tabellen ................................................................... 8
2.2 Problemstellung............................................................................................... 9
2.3 Projektziele...................................................................................................... 9
2.4 Mögliche Lösungen........................................................................................ 10
2.4.1 LogMiner (erste Vision) ............................................................................. 10
2.4.2 Timestamp / Change Key Column ............................................................. 11
2.4.3 Tabel differencing...................................................................................... 11
2.4.4 Oracle Change Data Capture .................................................................... 12
2.5 Entscheid....................................................................................................... 13
2.5.1 Erklärung zur Bewertung ........................................................................... 13
3 Analyse .............................................................................................................. 15
3.1 Change Data Capture.................................................................................... 15
3.1.1 Architektur ................................................................................................. 15
3.1.1.1 Publisher......................................................................................... 16
3.1.1.2 Source Tabelle................................................................................ 16
3.1.1.3 Change Source............................................................................... 16
3.1.1.4 Change Set..................................................................................... 16
3.1.1.5 Change Table ................................................................................. 16
3.1.1.6 Subscriber....................................................................................... 16
3.1.2 Change Data Capture Modus .................................................................... 17
3.2 Applikation..................................................................................................... 18
3.2.1 Pakete....................................................................................................... 18
3.2.2 Use Case Diagramm (Publish) .................................................................. 19
3.2.3 Übersicht Use Cases (Publish).................................................................. 20
3.2.4 Aktoren...................................................................................................... 20
3.2.5 Detailbeschreibung Use Cases (Publish)................................................... 21
3.2.5.1 Programm starten ........................................................................... 21
3.2.5.2 Login............................................................................................... 22
3.2.5.3 Destinationsystem konfigurieren ..................................................... 23
3.2.5.4 Change Source konfigurieren.......................................................... 24
3.2.5.5 Change Source löschen.................................................................. 26
3.2.5.6 Change Set konfigurieren ............................................................... 28
3.2.5.7 Change Set löschen........................................................................ 30
3.2.5.8 Changetabelle ändern..................................................................... 32
3.2.5.9 Changetabelle purgen..................................................................... 34
10.09.2009 Seite 3 von 80

Diplombericht
Master Thesis MAS-07-01.21
3.2.5.10 Changetabelle erstellen ................................................................ 35
3.2.5.11 Change Tabelle löschen ............................................................... 38
3.2.5.12 Sourcesystem konfigurieren.......................................................... 39
3.2.6 Use Case Diagramm (Subscribe) .............................................................. 40
3.2.7 Übersicht Use Cases (Subscribe).............................................................. 40
3.2.8 Spezifikation GUI....................................................................................... 41
3.2.8.1 Tree View........................................................................................ 41
3.2.8.2 Menu Bar ........................................................................................ 41
3.2.8.3 Toolbar............................................................................................ 42
3.2.8.4 Kontext Menu auf TreeView ............................................................ 42
3.2.8.5 Statusbar ........................................................................................ 42
4 Design ................................................................................................................ 43
4.1 Applikation..................................................................................................... 43
4.1.1 Übersicht Struktur...................................................................................... 43
4.1.2 Source Code ............................................................................................. 44
4.2 Datenbank ..................................................................................................... 45
4.2.1 DB Model DWH (Destination System) ....................................................... 45
4.2.1.1 all_change_sources ........................................................................ 45
4.2.1.2 all_change_sets.............................................................................. 45
4.2.1.3 all_change_tables ........................................................................... 45
4.2.1.4 all_published_columns.................................................................... 45
4.2.1.5 all_tables......................................................................................... 46
4.2.2 DB Model Source Datenbank .................................................................... 46
4.2.2.1 all_tab_columns .............................................................................. 46
4.2.2.2 all_tables......................................................................................... 46
4.2.2.3 all_capture_prepared_tables........................................................... 46
5 Testing ............................................................................................................... 47
5.1 Ziel des Testens ............................................................................................ 47
5.2 Übersicht der Tests........................................................................................ 47
5.3 Testablauf...................................................................................................... 47
5.3.1 Ablauf........................................................................................................ 47
5.3.2 Test Dokumentation .................................................................................. 47
5.3.3 Testmethoden ........................................................................................... 48
5.3.4 Testfälle..................................................................................................... 48
5.4 System Test................................................................................................... 48
5.5 Usability Test................................................................................................. 48
5.6 Testergebnisse.............................................................................................. 49
5.6.1 Systemtests............................................................................................... 49
5.6.2 Usabilitytests ............................................................................................. 49
6 Planung und Zeitmanagement......................................................................... 50
6.1 Vorgehensmodell........................................................................................... 50
6.2 Zeitmanagement............................................................................................ 51
6.3 Projektplan / Zeitplan und Meilensteine ......................................................... 52
6.4 Termine ......................................................................................................... 53
6.5 Projektmanagement....................................................................................... 53
6.6 Meetings / Reviews /Statusmeldungen .......................................................... 53
6.6.1 Meetings.................................................................................................... 53
6.7 Reviews......................................................................................................... 53
6.7.1 Statusmeldungen ...................................................................................... 53
10.09.2009 Seite 4 von 80

Diplombericht
Master Thesis MAS-07-01.21
7 Erfüllung der Anforderungen und Ziele .......................................................... 54
7.1 Nicht funktionale Anforderungen.................................................................... 54
7.2 Funktionale Anforderungen............................................................................ 55
7.2.1 Publisher Teil............................................................................................. 55
7.2.2 Subscriber Teil .......................................................................................... 55
7.3 Ziele .............................................................................................................. 56
8 Erfahrungen....................................................................................................... 57
8.1 Resultat ......................................................................................................... 57
8.2 Ausblick ......................................................................................................... 57
8.3 Schlusswort ................................................................................................... 58
9 Installations- und Betriebshandbuch .............................................................. 59
9.1 Technische Umgebung.................................................................................. 59
9.1.1 Client......................................................................................................... 59
9.1.2 Datenbank................................................................................................. 59
9.1.2.1 RDBMS........................................................................................... 59
9.1.2.2 Server Umgebung........................................................................... 59
9.2 Installation ..................................................................................................... 60
9.2.1 Datenbank................................................................................................. 60
9.2.1.1 Konfiguration Change Data Capture ............................................... 60
9.2.1.2 Konfiguration LDI Tool .................................................................... 60
9.2.2 Setup......................................................................................................... 61
9.3 Benutzerhandbuch ........................................................................................ 64
9.3.1 Über LDI.................................................................................................... 64
9.3.2 Startup LDI ................................................................................................ 64
9.3.3 Benutzeroberfläche ................................................................................... 65
9.3.4 TreeView ................................................................................................... 66
9.3.5 Objekte bearbeiten .................................................................................... 67
9.3.6 Changesourcen bearbeiten ....................................................................... 67
9.3.7 Changesets bearbeiten ............................................................................. 68
9.3.8 Changetabellen bearbeiten........................................................................ 69
9.3.8.1 Source Properties ........................................................................... 69
9.3.8.2 Destination Properties..................................................................... 70
9.3.9 Shortcuts................................................................................................... 72
9.3.10 Fehlerbehandlung.................................................................................. 72
10 Change Requests ....................................................................................... 73
11 Anhang ........................................................................................................ 77
11.1 Glossar.......................................................................................................... 77
11.2 Referenzen.................................................................................................... 78
11.3 Tabellenverzeichnis ....................................................................................... 79
11.4 Abbildungsverzeichnis ................................................................................... 79
10.09.2009 Seite 5 von 80

Diplombericht
Master Thesis MAS-07-01.21
1 Allgemeines
1.1 Dokument
1.1.1 Zweck
Dieses Dokument ist der Diplombericht der Master Thesis MAS-07-01.21 „Lightweight DWH
Interface“. Es bietet einen Überblick über die gesamte Arbeit und die erstellten Artefakte. Es
soll aufgezeigt werden, welche Arbeiten im Rahmen der Diplomarbeit durchgeführt wurden
und welche Resultate erzielt wurden. Ein wesentlicher Teil setzt sich aus dem Pflichtenheft
und aus der Detailspezifikation zusammen. Zusätzlich werden die dazugehörigen Ergebnisse
dokumentiert. Auch werden die im Laufe des Projekts aufgetretenen Änderungsanfragen
aufgeführt und es wird ein Ausblick auf zukünftig geplante Versionen gegeben.
1.1.2 Umfang
Diese Arbeit wird in der Form einer Master Thesis vollzogen. Sie bildet einen Teil der
Ausbildung zum Master of Advanced Studies in Information Technology (MAS-IT). Der
gesamte Arbeitsaufwand beträgt 360 Stunden (12 ECTS-Punkte) und dauert ein Semester.
1.1.3 Leserkreis
Dieses Dokument richtet sich in erster Linie an den Experten und an den Betreuer.
1.1.4 Übersicht
Dieses Dokument ist wie folgt aufgebaut:
Kapitel 1
Kapitel 2
Kapitel 3
Kapitel 4
Kapitel 5
Kapitel 6
Kapitel 7
Kapitel 8
Kapitel 9
Kapitel 10
Kapitel 11
Vermittelt einen Überblick über das Dokument.
Projektübersicht und Problemstellung
Analyse Change Data Capture und Applikation
Design Applikation und Datenbank
Angaben und Ergebnisse zum Testing
Planung und Zeitmanagement
Übersicht über die Erfüllung der gesteckten Ziele und Anforderungen
Ausblick und Schlusswort zu der Diplomarbeit
Installations- und Betriebshandbuch
Angaben zu den Change Requests
Anhang
1.1.5 Begriffe und Definitionen
Die in diesem Dokument verwendeten Begriffe und Definitionen sind im Glossar beschrieben.
1.1.6 Nomenklatur
Das Dokument ist in Deutsch gehalten. Dort wo es jedoch sinnvoll erscheint, werden die
englischen Originalbegriffe verwendet. Zu Gunsten einer besseren Lesbarkeit wird für
sämtliche Bezeichnungen nur die männliche Form verwendet.
10.09.2009 Seite 6 von 80

Diplombericht
Master Thesis MAS-07-01.21
2 Projektübersicht
2.1 Allgemeine Beschreibung
Das Projekt befasste sich mit der Problematik der Übernahme von operativen Daten in den
Staging Bereich eines Datawarehouse.
Die Kapitel 2.1.1 und 2.1.2 zeigen die Ist - Situation dieser Schnittstellen im analysierten
System auf. Das Kapitel 2.1.3 beschreibt die Probleme, welche sich in diesem Bereich stellen
und auch den Anstoss für dieses Projekt gegeben haben.
2.1.1 ETL Prozess
Die Abbildung 1 zeigt den ETL - Prozess in der Emmi Schweiz AG. Dieser folgt immer dem
gleichen Ablauf. Zuerst werden alle benötigten Daten von den Quellsystemen in den
Stagingbereich des DWH übernommen (Punkt 1). Ab dort werden die Daten transformiert und
konvertiert und werden in die verschiedenen Data - Marts geladen (Punkt 2).
Die rot gestreifte Linie markiert den Bereich, in welchem sich dieses Projekt bewegt. Bereiche
ausserhalb der Markierung sind von der geplanten Arbeit nicht betroffen.
relational
dimensional
Quellsysteme
transformation / converting
evaluations
ERP DB
(OLTP)
E1 Master
landing-zone
Datawarehouse
MIS DB
Oracle 11g R1
Standard Reports
(Microstrategy)
Sales Line
ERP DB
(OLTP)
EFM
1
Staging
2
DWH Bus
Financial
Query
Service
Ad hoc Zugriff
(SQL)
Stammdaten DB
(OLTP)
DWH Bus
ESDS
Procurement
Budget DB
Feedback operationelle
Systeme
(PROCOS)
PROCOS
Abbildung 2-1: ETL Prozess Schema
Metadaten
10.09.2009 Seite 7 von 80

Diplombericht
Master Thesis MAS-07-01.21
2.1.2 Ladeprozess kleine Tabellen
Bei der Übernahme von Tabellen mit Records < 30'000'000 in den Stagingbereich, werden
die kompletten Daten bei jeder Übertragung gelöscht und wieder geladen. Die Löschung
erfolgt mit dem Befehl Truncate und ist dadurch sehr schlank gehalten. Der Ladevorgang ist
bei einer grossen Anzahl Records aufwendig.
2.1.3 Ladeprozess grosser Tabellen
Bei der Übernahme von Tabellen mit Records > 30'000'000 in den Stagingbereich, werden
nur Änderungen seit der letzten Übernahme verarbeitet.
Abbildung 2 zeigt den Standardvorgang einer solchen Übernahme.
1. Als erstes wird eine Hilfstabelle gelesen, welche die Primary Keys der gelöschten
Records von der Haupttabelle enthält. Anhand dieses Keys werden auch auf der
Zieltabelle diese Records gelöscht.
2. Anhand einer Spalte, welche das Änderungsdatum enthält, werden die zusätzlichen
oder geänderten Records seit der letzten Übernahme identifiziert. Da diese Spalte
nicht indexiert ist, löst dies jede Nacht einen Full Table Scan aus.
3. Um zu prüfen, ob auch wirklich die Daten auf der Quell- wie auch auf der
Zieldatenbank gleich sind, wird nach jeder Übernahme einen Abgleich gemacht. Dies
wird gemacht, indem man auf einer definierten Spalte eine Summe bildet und diese
beiden Summen vergleicht. Die Vergangenheit hat gezeigt, dass dieser Abgleich
notwendig ist, da schon einige Fehler gefunden wurden.
4. Dies ist ein Trigger, welcher auf der Quelltabelle programmiert werden muss. Dieser
stellt sicher, dass alle Änderungen mit einem korrekten Änderungsdatum versehen
werden. Auch kann durch den Trigger gewährleistet werden, dass gelöschte Records
zu einem späteren Zeitpunkt auf der Zieltabelle via Primary Key auch gelöscht werden
können.
ERP DB
4
PK gelöschte Rows
Quelltabelle
Full Table Scan Summe ausrechnen Summe vergleichen Summe ausrechnen - Full Table Scan
3
2
Stagingbereich DWH
Datawarehouse
MIS DB
Oracle 11g R1
Full Table Scan - Änderungen selektieren - Änderungen übernehmen
Gelöschte Records auch in DWH löschen
1
Delete Tabelle
Zieltabelle
Trigger
Abbildung 2-2: Ladeprozess grösserer Tabellen
10.09.2009 Seite 8 von 80

Diplombericht
Master Thesis MAS-07-01.21
2.2 Problemstellung
Durch die aufwendige Übernahme der grossen Tabellen, werden die Quellsysteme derart
belastet, dass der produktive Betrieb während den Übernahmen beeinträchtigt wird.
Abbildung 3 zeigt die Kurve der CPU auf dem Quellsystem während einer Übernahme an
einem Wochenende. Es ist deutlich zu sehen, dass ab ca. 17:00 bis ca. 07:00 die Last
ansteigt. Genau in dieser Zeit wurden die Daten, welche nur wöchentlich übernommen
werden können, übertragen und abgeglichen.
Abbildung 2-3: CPU Kurve Quellsystem
Des Weiteren besteht der Wunsch die Daten mindestens vom Vortag im Datawarehouse
auswerten zu können. Bei dieser Übertragungstechnik ist dies aber nicht möglich, da die
Laufzeit der Schnittstellen bis um ca. 12:00 Mittags dauern würde. Auch darf eine solche
Belastung der Quellsysteme nicht während des Tagesgeschäfts der Emmi AG auftreten, da
dies den Lieferprozess der Firma beeinträchtigt würde.
2.3 Projektziele
Das Ziel dieses Projekts ist eine Schnittstellentechnik zu beschreiben und zu realisieren:
• Welche die Daten im gewünschten Zeitrahmen (max. 2 Stunden für die grössten
Tabellen) in den Staging - Bereich des DWH bringt.
• Welche die Belastung des Quellsystems um mindestens 70% verringert.
• Welche es erlaubt die zukünftigen Schnittstellen mit 50% Aufwand zu realisieren.
• Welche der Stabilität zur jetzigen Technik ebenwürdig ist.
• Welche das weglassen der Trigger auf den Quellsystemen erlaubt.
Um diese Ziele zu erreichen, werden in den folgenden Kapiteln die Lösungsansätze
analysiert und die Anforderungen sowie die Ziele genauer beschrieben.
10.09.2009 Seite 9 von 80

Diplombericht
Master Thesis MAS-07-01.21
2.4 Mögliche Lösungen
In diesem Kapitel werden die möglichen Lösungen für das erreichen der Projektziele kurz
beschrieben und verglichen. Danach wird entschieden, welche Technik für das Projekt
geeignet ist. Dieser Entscheid wird die technische Umsetzung des Projekts massiv
beeinflussen. Daher wird diesem Teil genügend Zeit beigemessen. Jede Lösung wird auch
praktisch analysiert und ein schlanker „Proof of Concept“ wird durchgeführt.
2.4.1 LogMiner (erste Vision)
Die erste Idee, wie man die im Kapitel 2.1.3 beschriebenen Probleme lösen könnte, sah wie
folgt aus:
Staging Table
Change Table
Abbildung 2-4: Prozessablauf Vision
Die archivierten Redo Logs der Quelldatenbank, werden auf den Rechner der Zieldatenbank
kopiert. Dort werden mit der bestehenden Oracle Technologie LogMiner alle Änderungen in
eine Zwischentabelle geschrieben. Diese Änderungen werden mittels einer neu
programmierten Applikation gefiltert und aufbereitet. Danach werden die aufbereiteten
Records in die entsprechende Stagingtabelle geschrieben. Jeder Record enthält zusätzliche
wichtige Merkmale wie:
• Änderungsart (Insert, Update, Delete)
• SCN damit die Reihenfolge bestimmt werden kann
• Ein Flag Verarbeitet Ja/Nein
10.09.2009 Seite 10 von 80

Diplombericht
Master Thesis MAS-07-01.21
2.4.2 Timestamp / Change Key Column
Diese Methode ist bereits bei den grössten Tabellen umgesetzt und im Kapitel 2.1.3
beschrieben. Sie belastet die Systeme stark und bedeutet einen grossen Aufwand bei der
Programmierung neuer Schnittstellen.
Mit dieser Technik können die Projektziele nicht erreicht werden.
2.4.3 Tabel differencing
Bei dieser Methode, werden die gesamten Daten von der Quelldatenbank zur Zieldatenbank
transportiert. Danach werden sie mittels speziellen SQL’s verglichen (minus). Auch diese
Technik ist sehr belastend für die Systeme. Mittels Datenbanklink kann eine Verbesserung
erzielt werden.
Mit dieser Technik können die Projektziele nicht erreicht werden.
10.09.2009 Seite 11 von 80

Diplombericht
Master Thesis MAS-07-01.21
2.4.4 Oracle Change Data Capture
Oracle bietet das Feature „Change Data Capture“ an. Diese Technologie kann in
verschiedenen Modi betrieben werden:
• Synchronus
• Asynchronus HotLog
• Asynchron Distributed HotLog
• Asynchronus HotLog online
• Asynchronus Autolog archive
Für das anstehende Projekt bietet sich „Asynchronus Autolog Archive“ am besten an, da die
Anforderungen ziemlich genau auf die bestehende Umgebung in der Emmi Schweiz AG
passen. Auch ist eine möglichst zeitnahe Übertragung nicht nötig. Des Weiteren belastet
dieser Modus die Systeme am wenigsten.
In diesem Kapitel wird also nur auf den „Asynchronus Autolog Archive“ Modus eingegangen.
Um die Funktionsweise der anderen Modi zu erfahren wird auf das Kapitel 16 im Dokument
Oracle Data Warehousing Guide 11g Release 1 (B28313-02) verwiesen.
Asynchronus Autolog Archive
Dieser Modus beinhaltet einen ziemlich ähnlichen Vorgang wie im Kapitel 2.4.1 beschrieben.
Die Daten werden auch aus den Archivierten Redo Logs gewonnen. Anstelle des LogMiners
steht das Feature Change Data Capture, welches auch die Funktion des Aufbereitens der
Daten beinhaltet. In der Abbildung 5 sieht man ein Übersichtsschema, wie dieser Modus
funktioniert. Eine genaue Beschreibung kann aus dem Dokument Oracle Data Warehousing
Guide 11g Release 1 (B28313-02) entnommen werden.
Abbildung 2-5: Prozessablauf Change Data Capture
10.09.2009 Seite 12 von 80

Diplombericht
Master Thesis MAS-07-01.21
2.5 Entscheid
Bei den verschiedenen Lösungsansätzen im Kapitel 2.4 kommen nur die Logminer - Lösung
und das Change Data Capture in Frage. Bei allen Anderen können die gesteckten Ziele nicht
erreicht werden.
Kriterien
Gewicht LogMiner
Change Data
Capture
1 Belastung Quellsystem 9 5 5
2 Belastung Zielsystem 3 3 4
3 Implementationsaufwand / Tabelle 5 2 4
4 Stabilität 7 3 5
5 Supportbarkeit 6 2 4
6 Releasefähigkeit 7 1 4
7 Aufwand 5 2 4
8 Kosten 2 5 5
Resultat 124 194
Tabelle 2-1: Entscheidungstabelle
Aufgrund des Resultats der Entscheidungstabelle wird sich für „Change Data Capture“
entschieden.
2.5.1 Erklärung zur Bewertung
Belastung Quellsystem
Aufgrund der sehr ähnlichen Technologie werden bei beiden Varianten die Quellsysteme
kaum belasten.
Belastung Zielsystem
Da bei der LogMiner Lösung das aufbereiten der Daten programmiert werden muss, gehe ich
nicht davon aus, dass ich dies gleich effizient gestalten könnte wir die Firma Oracle.
Implementationsaufwand / Tabelle
„Change Data Capture“ stellt einige der gewünschten Funktionen zur Verfügung. Somit kann
die zur Verfügung stehende Zeit auch in die Entwicklung eines GUI investiert werden. Somit
sollte auch das Ziel der einfachen Weiterentwicklung erreicht werden.
Stabilität
Da „Change Data Capture“ ein Standard Feature von Oracle ist und dieses weltweit in Firmen
eingesetzt wird, kann von einer guten Stabilität ausgegangen werden. Bei der selber
entwickelten Variante, wäre das „handeln“ jeglicher Spezialsituationen sicher schwierig
gewesen.
10.09.2009 Seite 13 von 80

Diplombericht
Master Thesis MAS-07-01.21
Supportbarkeit
Bei der LogMiner Variante ist es schwierig über Jahre das Know-How aufrechtzuerhalten. Da
„Change Data Capture“ ein Standard Feature ist, kann man sich auch bei der Firma Oracle
Unterstützung besorgen.
Releasefähigkeit
Das „Change Data Capture“ Feature wird bei Oracle mit den DB Relases gleichzeitig
ausgeliefert, da es ein Bestandteil der ganzen Software ist. Die eigene Lösung müsste bei
jedem Upgrade der Umgebung neu erweitert und getestet werden.
Aufwand
Beim Aufwand kann gesagt werden, dass eine eigene Entwicklung den Rahmen der
Diplomarbeit gesprengt hätte. Beim „Change Data Capture“ kann die vorgesehene Zeit
voraussichtlich eingehalten werden.
Kosten
Das sowohl LogMiner wie auch „Change Data Capture“ keine Option ist, welche separat
Lizenziert werden muss, dürften sich die Kosten im gleichen Rahmen bewegen.
10.09.2009 Seite 14 von 80

Diplombericht
Master Thesis MAS-07-01.21
3 Analyse
In diesem Kapitel ist der grösste Teil aus der Detailspezifikation entnommen. Es beschreibt
die Technologie Change Data Capture ein wenig genauer und zeigt, wie die Applikation
geplant wurde.
3.1 Change Data Capture
Change Data Capture ist ein standard Feature von Oracle. Es stellt eine sehr ausgereifte
Technik zur Verfügung, welche die Änderungen von einer Datenbank an eine weitere
Datenbank befördert. Um genaue Details dieser Technik zu erfahren wird auf die
Dokumentation von Oracle (Oracle Data Warehousing Guide 11g Release 1 (B28313-02))
verwiesen. In diesem Kapitel wird nur ein grober Überblick dieser Features gegeben, welche
in dieser Arbeit relevant sind.
3.1.1 Architektur
Grundlegend unterteilt sich die Change Data Capture (CDC) Architektur in zwei Bereiche: in
einen Source - Bereich und einen Staging - Bereich. Der Staging - Bereich ist nicht mit einem
üblichen Staging - Bereich im ETL - Umfeld zu vergleichen. Die Abbildung 3-1 zeigt ein
Überblick der CDC Architektur. Die rote Linie beschreibt die Systemgrenzen dieses Projekts.
In einem späteren Release könnte auch der Subscriber - Teil im GUI verwaltbar gemacht
werden.
Abbildung 3-1: Architektur Change Data Capture
Als Source - Bereich wird hier das operative System bezeichnet, in welchem die relevanten
Datenänderungen stattfinden. Im Staging Bereich werden die Änderungen in einem
10.09.2009 Seite 15 von 80

Diplombericht
Master Thesis MAS-07-01.21
sogenannten Publisherbereich abgelegt. Pro Source Tabelle gibt es im Stagingbereich
jeweils eine Änderungstabelle (Change Table).
In den folgenden Kapiteln werden die verschiedenen Teile des Change Data Capture
genauer beschrieben.
3.1.1.1 Publisher
Der Publisher enthält alle Funktionalitäten um, die Datenänderungen im Source - Bereich zu
erkennen und darzustellen. Der Publisher ist ein normaler Datenbank Benutzer, welcher mit
den entsprechenden Rechten ausgestattet sein muss. Dieser Benutzer wird für ein DWH
einmalig angelegt und wird daher im geplanten Tool nicht verwaltet werden können, da diese
Möglichkeit in den standard Oracle Tools mehrfach und in einer befriedigenden Form
vorhanden ist.
3.1.1.2 Source Tabelle
Dies ist die Tabelle, von welcher alle Änderungen auf der Stagingdatenbank gewünscht
werden. Um eine Tabelle für CDC zu präparieren, muss diese mit dem Befehl
DBMS_CAPTURE_ADM.PREPARE_TABLE_INSTANTIATION instanziert werden. Weitere
Schritte sind auf der Source Datenbank nicht nötig.
3.1.1.3 Change Source
Die Change Source ist die logische Repräsentation der Sourcedatenbank. Somit wird für jede
Sourcedatenbank eine Change Source auf der Stagingdatenbank angelegt. Eine Change
Source kann gestoppt und wieder gestartet werden.
3.1.1.4 Change Set
In einem Change Set sind mehrere Change Tabellen zusammengefasst. Alle Change
Tabellen, welche in einem Change Set zusammengefasst sind, werden
transaktionskonsistent nachgeführt. Des Weiteren werden beim asynchronen Change Data
Capture durch das Anlegen, aktivieren und deaktivieren des Change Sets die Oracle Streams
Prozesse, welche für das Erfassen der Datenänderungen zuständig sind, gesteuert.
3.1.1.5 Change Table
In den Change Tabellen werden die Datenänderungen als Logical Change Record
tabellarisch dargestellt. Beim Erstellen der Change Tabellen wird definiert, welche Quell-
Tabellen und welche Spalten dieser Quell-Tabellen für die Change Data Capture Umgebung
relevant sind.
3.1.1.6 Subscriber
Der Subscriber enthält Funktionalitäten um Views auf die Change Tabellen zu erstellen. Mit
Hilfe dieser Views können immer nur die Datenänderungen geladen werden, welche noch
nicht verarbeitet wurden. Diese Views stellen eine angenehme Art dar mit dem ETL Prozess
10.09.2009 Seite 16 von 80

Diplombericht
Master Thesis MAS-07-01.21
die Daten abzugreifen. Dies ist aber auch ohne Weiteres direkt auf den Change Tabellen
möglich. Dieser Teil wir nach Bedarf zu einem späteren Zeitpunkt in das vorgesehene Tool
eingebaut.
3.1.2 Change Data Capture Modus
Hier wird nochmals kurz der Modus, welcher ausgewählt wurde beschrieben. Schon bei der
Erstellung des Pflichtenhefts hat man sich für den Modus Asynchronous Auto Log Archive
CDC entschieden. Dieser Modus ist optimal auf die Situation in der Emmi zugeschnitten und
belastet das Source System kaum. Dieser Modus ist nur möglich, weil das Source- und das
Stagingsystem genau die gleiche Hardware und die gleichen Oracle Releases aufweisen. Auf
der Abbildung 3-2 ist der Ablauf grob dargestellt.
Abbildung 3-2: Übersicht Modus CDC
Auf der Source Datenbank wird jede Änderung durch den Logwriter (LGWR) geloggt. Dieser
schreibt diese Änderungen in die Redo-Logs, welche jede halbe Stunde durch den Archiver-
Prozess in die sogenannten Archivierten Redo-Logs geschrieben werden. Dies ist ein ganz
normaler Vorgang und wird auf jeder Oracle Datenbank gemacht. Eine Anpassung, welche
gemacht werden muss, ist das Einschalten eines Supplemental Loggings auf der Source
Datenbank. Dies bewirkt, dass die Source Datenbank zusätzliche Informationen in die
Logdateien schreibt und genau diese zusätzliche Logging ist die einzige Belastung, welche
CDC dem Sourcesystem zufügt.
Auf der Staging Datenbank sind die Oracle Streams Prozesse für das importieren der
erforderlichen Daten aus den archivierten Redo-Logs verantwortlich.
10.09.2009 Seite 17 von 80

Diplombericht
Master Thesis MAS-07-01.21
3.2 Applikation
3.2.1 Pakete
Die Applikation kann in zwei Pakete aufgeteilt werden. Im Paket Publish befinden sich diese
Anwendungsfälle, welche im Zusammenhang Übertragung der Daten und zur Verfügung
stellen der Daten stehen.
Im Paket Subscribe befinden sich diese Anwendungsfälle, welche sich im Bereich des
Beziehens der Daten befinden. Das Subscribe Paket wird nur mit einem Use Case Diagramm
beschrieben. Die genaue Spezifikation wird zum Zeitpunkt der Umsetzung gemacht, da dies
voraussichtlich in einem zweite Release umgesetzt wird und nur als Kann Ziel in dieser
Spezifikation aufgeführt wird.
Abbildung 3-3: Package Diagramm LDI
10.09.2009 Seite 18 von 80

Diplombericht
Master Thesis MAS-07-01.21
3.2.2 Use Case Diagramm (Publish)
Use Case Diagramm: LDI (Publish)
Programm starten
FA.01.010
Login
FA.01.020
Destinationsystem
konfigurieren FA.02.010
Change Source
Konfigurieren FA.03.010
Change Source
löschen FA.03.020
Change Set
konfigurieren FA.04.010
Change Set löschen
FA.04.020
DWH System
Changetabelle
ändern FA.05.010
ETL - Programmierer
Changetabelle
purgen FA.05.020
Changetabelle
erstellen FA.05.030
Change Tabelle
löschen FA.05.040
Sourcesystem
konfigurieren FA.06.010
Source System
Abbildung 3-4: Use Case Diagramm Publish
10.09.2009 Seite 19 von 80

Diplombericht
Master Thesis MAS-07-01.21
3.2.3 Übersicht Use Cases (Publish)
ID Beschreibung M K
FA.01
Startup Applikation
FA.01.010 Programm starten X
FA.01.020 Login X
FA.02
Destinationsystem
FA.02.010 Destinationsystem konfigurieren X
FA.03
Change Source
FA.03.010 Change Source konfigurieren X
FA.03.020 Change Source löschen X
FA.04
Change Set
FA.04.010 Change Set konfigurieren X
FA.04.020 Change Set löschen X
FA.05
Change Tabelle
FA.05.010 Changetabelle ändern X
FA.05.020 Changetabelle purgen X
FA.05.030 Changetabelle erstellen X
FA.05.040 Changetabelle löschen X
FA.06
Sourcesystem
FA.06.010 Sourcesystem konfigurieren X
Tabelle 3-1: Übersicht Use Cases (Publish)
Diese Anforderungen wurden gegenüber dem Pflichtenheft ein wenig angepasst. Dies aus
dem Grund, weil bei der detaillierten Analyse erweiterte Erkenntnisse gewonnen wurden.
Diese Erkenntnisse haben dazu bewogen, einige Anforderungen wegzulassen und einige auf
Kann Ziele zurückzustufen.
3.2.4 Aktoren
Es werden alle Aktoren kurz beschrieben.
Name
ETL - Programmierer
Source System
Destination System
Tabelle 3-2: Aktoren
Beschreibung
Dies ist der Hauptbenutzer dieser Software. Er definiert die ETL
Schnittstellen für das DWH. Er ist der einzige, welche mit dieser
Applikation arbeitet.
Das Sourcesystem ist die Datenbank, welche die Quelldaten für
die Schnittstelle enthält.
Das Zielsystem ist der Stagingbereich des DWH. Dies auch in der
Form einer Oracle Datenbank.
10.09.2009 Seite 20 von 80

Diplombericht
Master Thesis MAS-07-01.21
3.2.5 Detailbeschreibung Use Cases (Publish)
3.2.5.1 Programm starten
AD Programm starten
User startet Programm
Login wird aufgerufen
(FA.01.020)
Login nicht erfolgreich
Login OK
Metadaten werden von
DWH eingelesen
Programm wird beendet
GUI wird
Initialisiert
Programm
gestartet
Programm
beendet
Abbildung 3-5: Aktivitätsdiagramm Programm starten
Der Benutzer startet das Programm per Mausklick aus seinem Startmenu. Die Applikation
wird gestartet und der Benutzer wird zum Login aufgefordert (siehe include FA.01.020). Wenn
das Login OK ist, werden die Meta Daten aus dem DWH gelesen und die TreeView wird
konfiguriert (siehe Kapitel GUI). Danach wird das GUI angezeigt. Bei nicht erfolgreichem
Login, wird der Prozess wieder beendet. Mit dem SQL Statement aus Tabelle 3-3 können die
nötigen Informationen aus dem DWH bezogen werden, um die TreeView mit den nötigen
Objekten zu initialisieren. Weitere Infos über die TreeView können aus dem Kapitel 3.2.8.1
bezogen werden.
10.09.2009 Seite 21 von 80

Diplombericht
Master Thesis MAS-07-01.21
Vorgang
SQL
Daten für TreeView select source_database, source_name, b.set_name, c.change_table_schema,
lesen
c.change_table_name
from all_change_sources a, all_change_sets b, all_change_tables c
where source_type = 'AUTOLOG'
and a.source_name = b.change_source_name
and b.set_name = c.change_set_name;
Tabelle 3-3: SQL Programm starten
3.2.5.2 Login
Dieses Aktivitätsdiagramm zeigt den Ablauf des Anmeldeprozesses. Dieser Prozess wird
nach dem Start der Applikation automatisch aufgerufen und ist ein Teil des Startvorgangs.
AD Login
Auswahl DWH DB
Eingabe Benutzername & Passwort
für DWH DB
abbrechen
neuer Versuch
Login OK
Programm wird beendet
Login
fehlgeschlagen
Login OK
Abbildung 3-6: Aktivitätsdiagramm Login
10.09.2009 Seite 22 von 80

Diplombericht
Master Thesis MAS-07-01.21
Der Benutzer wird aufgefordert, die DB vom gewünschten DWH auszuwählen (DB’s können
aus dem tnsnames.ora ausgelesen werden) und seine Benutzerangaben einzugeben. Dies
sind die Benutzerangaben des Publishers vom DWH. Die Benutzerangaben werden gegen
die ausgewählte DB geprüft. Bei erfolgreicher Anmeldung wird die Applikation gestartet und
der Angegebene Benutzer bleibt angemeldet. Bei nicht korrekten Angaben wird der Benutzer
aufgefordert es erneut zu versuchen. Der Vorgang kann auch abgebrochen werden. Damit
schliesst sich die Applikation wieder.
Abbildung 3-7: GUI Login
Das GUI wird nicht näher beschrieben, da es selbsterklärend ist.
3.2.5.3 Destinationsystem konfigurieren
Kann Ziel. Wird zum Zeitpunkt der Umsetzung spezifiziert.
10.09.2009 Seite 23 von 80

Diplombericht
Master Thesis MAS-07-01.21
3.2.5.4 Change Source konfigurieren
Das Aktivitätsdiagramm zeigt den Ablauf für die Erstellung oder für die Änderung eine
Change Source. Eine Change Source wird nur eine pro Sourcesystem erstellt. Im
dazugehörigen GUI sieht man, wie und wo der Benutzer die Eingaben machen kann.
AD Change Source konfigurieren
User wählt
Sourcesystem aus
CS erstellen
CS ändern
User mutiert CS
Eigenschaften
User erfasst CS
Eigenschaften
CS ändern
CS erstellen
OK
Fehler beim ändern der CS
Fehlermeldung
Fehler beim Erstellung
OK
GUI anpassen
CS geändert
Vorgang
abgebrochen
CS erstellt
Abbildung 3-8: Aktivitätsdiagramm Change Source konfigurieren
Der Benutzer wählt, ob er eine neue Change Source erstellen oder ob er eine bestehenden
abändern will. Aufgrund der Auswahl, werden die Eingabefelder ausgefüllt oder nicht.
Nachdem er die Eigenschaften mutiert hat, kann er die Eingabe speichern. Im Reiter SQL
kann das jeweilige SQL, welches beim Speichern ausgeführt wird, angesehen werden. Wenn
10.09.2009 Seite 24 von 80

Diplombericht
Master Thesis MAS-07-01.21
kein Fehler auftritt, wird dieser Vorgang abgeschlossen. Bei einer neuen Source wird die
TreeView entsprechend angepasst. Kann der Vorgang nicht durchgeführt werden, wird die
originale Fehlermeldung der Datenbank ausgegeben. Bei einer Änderung kann das Feld
Change Source Name nicht mutiert werden und ist im GUI gesperrt.
Abbildung 3-9: GUI Change Source
Die Tabelle 3-2 enthält die SQL’s, welche beim Speichern an die Datenbank gesendet
werden. Ein Fehlerhandling ist bei diesen Packages schon implementiert und muss nicht
zusätzlich programmiert werden.
Vorgang
SQL
Change Source DBMS_CDC_PUBLISH.CREATE_AUTOLOG_CHANGE_SOURCE(
erstellen
change_source_name => 'CS_XXXXX',
description => 'Change Source from XXXXXXXX DB',
source_database => 'XXXXXX.emmi.ch',
first_scn => 0000000000);
Change Source DBMS_CDC_PUBLISH.ALTER_AUTOLOG_CHANGE_SOURCE(
ändern
change_source_name => 'CS_XXXXXXX',
first_scn => 0000000000);
Tabelle 3-4: SQL Change Source
10.09.2009 Seite 25 von 80

Diplombericht
Master Thesis MAS-07-01.21
3.2.5.5 Change Source löschen
Das Aktivitätsdiagramm zeigt den Ablauf beim Löschen einer Change Source.
AD Change Source löschen
User wählt
Change Source aus
Change Source
löschen
Fehler bei Löschung
Fehlermeldung
OK
GUI anpassen
CS geändert
Vorgang
abgebrochen
Abbildung 3-10: Aktivitätsdiagramm Change Source löschen
Der Benutzer wählt die entsprechenden Change Source aus und wählt Change Source
löschen aus dem Kontext Menu (siehe Kapitel Spezifikation GUI) oder betätigt den
Löschknopf in der Toolbox .
Bei erfolgreicher Löschung wird die TreeView entsprechend angepasst. Bei einem Fehler
wird die originale Datenbankfehlermeldung ausgegeben. Im SQL Reiter wird der
entsprechenden SQL Befehl angezeigt, welcher gegen die DB ausgeführt wird.
10.09.2009 Seite 26 von 80

Diplombericht
Master Thesis MAS-07-01.21
Bei der Löschung ist zu berücksichtigen, dass eine Change Source nur gelöscht werden
kann, wenn es keine Change Sets mehr enthält. Dies wird aber sauber vom Change Data
Capture Mechanismus abgehandelt und muss nicht durch die Applikation geprüft werden.
In der Tabelle 3-3 sieht man das SQL, welches an die Datenbank gesendet wird. Auf eine
Skizze des GUI wird verzichtet, da dies keinen Nutzen bringt. Der Name der Change Source
(CS_XXXXX) wird von der markierten Stelle aus der TreeView gezogen.
Vorgang
SQL
Change Source löschen DBMS_CDC_PUBLISH.DROP_CHANGE_SOURCE('CS_XXXXX');
Tabelle 3-5: SQL Change Source löschen
10.09.2009 Seite 27 von 80

Diplombericht
Master Thesis MAS-07-01.21
3.2.5.6 Change Set konfigurieren
Das Aktivitätsdiagramm zeigt den Ablauf für die Erstellung oder für die Änderung eines
Change Sets. Pro Change Source können mehrere Change Sets konfiguriert werden.
Innerhalb des Change Sets werden die Change Tabellen transaktionskosistent nachgeführt.
Im dazugehörigen GUI sieht man, wie und wo der Benutzer die Eingaben machen kann.
AD Change Set konfigurieren
User wählt
Change Source aus
CSet erstellen
CSet ändern
User mutiert CSet
Eigenschaften
User erfasst CSet
Eigenschaften
CSet ändern
CS erstellen
OK
Fehler bei Änderung
Fehlermeldung
Fehler bei Erstellung
OK
GUI anpassen
CSet geändert
Vorgang
abgebrochen
CSet erstellt
Abbildung 3-11: Aktivitätsdiagramm Change Set konfigurieren
Der Benutzer wählt, ob er ein neues Change Set erstellen oder ein bestehendes abändern
will. Je nach dem, werden die Eingabefelder ausgefüllt oder nicht und die entsprechenden
Felder sind mutierbar. Felder welche für den einen oder anderen Vorgang nicht mutiert
werden dürfen, werden im GUI gesperrt. Dies aus dem Grund, weil nicht beide Statements
10.09.2009 Seite 28 von 80

Diplombericht
Master Thesis MAS-07-01.21
die gleichen Eigenschaften haben. Nachdem er die Eigenschaften mutiert hat, kann er die
Eingabe speichern. Im Tab SQL kann das jeweilige SQL, welches beim Speichern ausgeführt
wird, angesehen werden. Wenn kein Fehler auftritt, wird dieser Vorgang abgeschlossen. Bei
einer neuen Source wird die TreeView entsprechend angepasst. Kann der Vorgang nicht
durchgeführt werden, wird die originale Datenbankfehlermeldung ausgegeben. Die
Fehlerbehandlung ist im SQL Package gut abgehandelt und muss nicht weiter programmiert
werden.
Abbildung 3-12: GUI Change Set konfigurieren
In der Tabelle 3-4 sind die SQL Statements ersichtlich, welche beim Speichern auf die
Datenbank gesendet werden.
Vorgang
SQL
Change Set erstellen DBMS_CDC_PUBLISH.CREATE_CHANGE_SET(
change_set_name => 'CSET_XXXXX_1',
description => 'Change Set for XXXXXX',
change_source_name => 'CS_XXXXX',
stop_on_ddl => 'y'
begin_date => NULL,
end_date => NULL);
Change Set ändern DBMS_CDC_PUBLISH.ALTER_CHANGE_SET(
change_set_name => 'CSET_XXXXX_1',
description => 'Change Set for XXXXXX',
enable_capture => 'Y',
recover_after_error => 'Y',
remove_ddl => 'Y',
stop_on_ddl => 'Y');
Tabelle 3-6: SQL Change Set konfigurieren
10.09.2009 Seite 29 von 80

Diplombericht
Master Thesis MAS-07-01.21
3.2.5.7 Change Set löschen
Das Aktivitätsdiagramm zeigt den Ablauf einer Löschung eines Change Sets.
AD Change Set löschen
User wählt
Change Set aus
Change Set
löschen
Fehler bei Löschung
Fehlermeldung
OK
GUI anpassen
CS geändert
Vorgang
abgebrochen
Abbildung 3-13: Aktivitätsdiagramm Change Set löschen
Der Benutzer wählt das entsprechenden Change Set aus und wählt Change Set löschen aus
dem Kontext Menu (siehe Kapitel Spezifikation GUI) oder betätigt den Löschknopf in der
Toolbox.
Bei erfolgreicher Löschung wird die TreeView entsprechend angepasst. Bei einem Fehler
wird die originale Datenbankfehlermeldung ausgegeben. Im SQL Tab wird der
entsprechenden SQL Befehl angezeigt, welcher gegen die DB ausgeführt wird.
10.09.2009 Seite 30 von 80

Diplombericht
Master Thesis MAS-07-01.21
Abbildung 3-14: GUI Change Set löschen
Bei der Löschung ist zu berücksichtigen, dass ein Change Set nur gelöscht werden kann,
wenn es keine Change Tabellen mehr enthält. Dies wird aber sauber vom Change Data
Capture Mechanismus abgehandelt und muss nicht durch die Applikation geprüft werden.
In der Tabelle ist das SQL Statement zu sehen, welches bei der Löschung an die DB
gesendet wird.
Vorgang
SQL
Change Source löschen DBMS_CDC_PUBLISH.DROP_CHANGE_SET('CSet_XXXXX_1');
Tabelle 3-7: SQL Change Set löschen
10.09.2009 Seite 31 von 80

Diplombericht
Master Thesis MAS-07-01.21
3.2.5.8 Changetabelle ändern
Das Aktivitätsdiagramm zeigt den Ablauf bei Änderung einer Change Tabelle.
Abbildung 3-15: Aktivitätsdiagramm Changetabelle ändern
Der Benutzer wählt in der TreeView die gewünschte Tabelle und im Kontext Menu (siehe
Kapitel Spezifikation GUI) „Changetabelle ändern“. Im GUI ist nur der Reiter Destination
mutierbar. Die Source - Seite muss nie geändert werden, ausser bei einer Löschung. Der
User nimmt die gewünschten Änderungen vor und speichert anschliessend seine Eingaben.
10.09.2009 Seite 32 von 80

Diplombericht
Master Thesis MAS-07-01.21
Wenn bei der Änderung ein Fehler auftritt, wird die originale Datenbankfehlermeldung
ausgegeben. Die Eigenschaften können weiter mutiert werden. Der Vorgang wird beendet,
indem der Benutzer die Aktion abbricht oder die Changetabelle korrekt abgespeichert wird.
Abbildung 3-16: GUI Changetabelle ändern
Bei Änderungen an den Spalten, muss mit „ADD“ oder „DROP“ angegeben werden, ob eine
Spalte hinzugefügt bzw. gelöscht werden soll. Dies steht nur bei Änderung an
Changetabellen zur Verfügung.
In der Tabelle 3-6 sieht man das entsprechende Alter Statement, welches beim Speichern an
die Datenbank gesendet wird.
Vorgang
SQL
Change Tabelle ändern DBMS_CDC_PUBLISH.ALTER_CHANGE_TABLE(
owner => ’OWNER’,
change_table_name =>’TABLE’ ,
operation => ’ADD’,
column_type_list => ’COLXXX NCHAR(5)’,
rs_id =>’Y’,
row_id => 'Y' ,
user_id => 'Y',
timestamp => 'Y',
object_id => 'Y' ,
source_colmap => 'Y',
target_colmap => 'Y');
Tabelle 3-8: SQL Changetabelle ändern
.
10.09.2009 Seite 33 von 80

Diplombericht
Master Thesis MAS-07-01.21
3.2.5.9 Changetabelle purgen
Dieses Aktivitätsdiagramm zeigt den Ablauf, wenn die Daten einer Changetabelle
reorganisiert werden. Das heisst nicht mehr benötigte Daten werden gelöscht.
AD Changetabelle purgen
User wählt Changetabelle aus
Destinationtabelle purgen
Fehler bei Purgevorgang
Fehlermeldung
OK
Tabelle
purged
Vorgang
abgebrochen
Abbildung 3-17: Aktivitätsdiagramm Changetabelle purgen
Der Benutzer wählt in der TreeView die gewünschte Tabelle und im Kontext Menu (siehe
Kapitel Spezifikation GUI) „Changetabelle purgen“. Das SQL Statement aus Tabelle 3-7 wird
an die Datenbank gesendet. Daten welche von keiner SubscriberView in Zugriff sind, werden
gelöscht. Bei einem Fehler wird die originale Datenbankfehlermeldung ausgegeben.
Daten welche mit diesem Package gelöscht wurden, können nicht mehr hergestellt werden!
Vorgang
SQL
Change Tabelle purgen DBMS_CDC_PUBLISH.PURGE_CHANGE_TABLE(
owner => ‚’OWNER’,
change_table_name => ’TABLE’);
Tabelle 3-9: SQL Change Tabelle konfigurieren
10.09.2009 Seite 34 von 80

Diplombericht
Master Thesis MAS-07-01.21
3.2.5.10 Changetabelle erstellen
Das Aktivitätsdiagramm zeigt den Ablauf bei Erstellung einer Change Tabelle.
AD Changetabelle erstellen
User wählt neue Changetabelle erstellen
User erfasst Source Owner & Tabelle
User erfasst sämtliche Eigenschaften
der Changetabelle (Reiter Destination)
Fehlermeldung
User speichert neue Changetabelle
Tabelle wird auf Source DB
instanziert
Fehler beim instanzieren
Vorgang abbrechen
OK
Changetabelle wird in DWH erstellt
Fehler bei Erstellung
Vorgang abbrechen
OK
Changetabelle
erstellt
Vorgang
abgebrochen
Abbildung 3-18: Aktivitätsdiagramm Changetabelle erstellen
10.09.2009 Seite 35 von 80

Diplombericht
Master Thesis MAS-07-01.21
Der Benutzer wählt ein Change Set und wählt im Kontext Menu (siehe Kapitel Spezifikation
GUI) „Neue Change Tabelle erstellen“. Er erfasst auf dem Reiter Source auf dem GUI Owner
und danach Tabellenname von der gewünschten Source Tabelle. Diese kann der Benutzer
bequem aus Kombinationsfeldern auswählen. Die Daten für die Kombinationsfelder können
aus der Source Datenbank geholt werden. Siehe Statements in Tabelle 3-8.
Abbildung 3-19: GUI Changetabelle erstellen (Source)
Danach wechselt der User auf der Reiter Destination und erfasst dort sämtliche
Eigenschaften der Changetabelle. Der Owner kann ausgewählt werden. Der Inhalt des
Kombinationfeldes kann aus dem DWH bezogen werden (siehe Tabelle 3-8). Der Name für
die Changetabelle muss eingegeben werden. Die restlichen Angaben müssen zum Teil
erfasst werden oder können aus der DWH DB bezogen werden. Wo welche Eigenschaften
des Change Data Capture bezogen werden können, ist auf dem Datenbankmodell in diesem
Dokument ersichtlich.
Nachdem sämtliche Eigenschaften gepflegt sind, speichert der User die Changetabelle. Das
Erstellungsstatement ist in Tabelle 3-8 ersichtlich. Als erstes wird auf der Source Datenbank
die Tabelle instanziert und vorbereiten. Dies muss in der Regel nur einmal gemacht werden.
Das Statement darf aber problemlos mehrere Male ausgeführt werden. Danach wird die
Changetabelle auf dem DWH erstellt. Tritt bei diesen Vorgängen ein Fehler auf, so wird die
originale Datenbankfehlermeldung ausgegeben und die Speicherung wird abgebrochen. Der
Vorgang gilt erst als erfolgreich abgeschlossen, wenn sowohl die Instanzierung wie auch die
Erstellung der Changetabelle erfolgreich sind. Zu beachten gilt, dass die Instanzierung der
Sourcetabelle immer früher als das kreieren der Changetabelle gemacht werden muss.
10.09.2009 Seite 36 von 80

Diplombericht
Master Thesis MAS-07-01.21
Abbildung 3-20: GUI Changetabelle erstellen Destination
Vorgang
Change Tabelle
erstellen
Source Tabelle
konfigurieren
Selektion Destination
Owner
Selektion Source
Owner
Selektion Source Table
Tabelle 3-10: SQL Source Tabelle konfigurieren
SQL
DBMS_CDC_PUBLISH.CREATE_CHANGE_TABLE(
owner => ’OWNER’,
change_table_name =>’TABLE’ ,
change_set_name => ’CSet_XXXXX_1’,
source_schema => ’SRC_OWNER’,
source_table => ’SRC_TABLE’,
column_type_list => ’COLXXX NCHAR(5)’,
capture_values => ’BOTH’ ,
rs_id =>’Y’,
row_id => 'Y' ,
user_id => 'Y',
timestamp => 'Y',
object_id => 'Y' ,
source_colmap => 'Y',
target_colmap => 'Y',
options_string => ’Tablespace XXXXX’);
DBMS_CAPTURE_ADM.PREPARE_TABLE_INSTANTIATION(
'OWNER.TABLE');
SELECT OWNER FROM ALL_TABLES GROUP BY OWNER;
SELECT OWNER FROM ALL_TABLES GROUP BY OWNER;
SELECT TABLE_NAME FROM ALL_TABLES
WHERE OWNER = 'OWNER';
10.09.2009 Seite 37 von 80

Diplombericht
Master Thesis MAS-07-01.21
3.2.5.11 Change Tabelle löschen
Dieses Aktivitätsdiagramm zeigt den Ablauf für die Löschung einer Change Tabelle.
AD Change Tabelle löschen
User wählt
Change Tabelle aus
Change Tabelle
löschen
Fehler bei Löschung
Fehlermeldung
OK
GUI anpassen
CS geändert
Vorgang
abgebrochen
Abbildung 3-21: Aktivitätsdiagramm Change Tabelle löschen
Der Benutzer wählt die entsprechenden Change Tabelle aus und wählt Change Tabelle
löschen aus dem Kontext Menu (siehe Kapitel Spezifikation GUI) oder betätigt den
Löschknopf in der Toolbox .
Der User wird nochmals aufgefordert die Löschung zu bestätigen. Auf dieser Aufforderung
kann er ein zusätzliches „force“ Flag setzen, welches die Löschung erzwingt.
Bei erfolgreicher Löschung wird die TreeView entsprechend angepasst. Bei einem Fehler
wird die originale Datenbankfehlermeldung ausgegeben. Im SQL Tab wird der
entsprechenden SQL Befehl angezeigt, welcher gegen die DB ausgeführt wird.
10.09.2009 Seite 38 von 80

Diplombericht
Master Thesis MAS-07-01.21
Abbildung 3-22: GUI Source Tabelle löschen
Vorgang
SQL
Source Tabelle löschen DBMS_CDC_PUBLISH.DROP_CHANGE_TABLE(
owner IN VARCHAR2,
change_table_name IN VARCHAR2,
force_flag IN CHAR);
Tabelle 3-11: SQL Source Tabelle löschen
3.2.5.12 Sourcesystem konfigurieren
Kann Ziel. Dies wird noch nicht spezifiziert.
10.09.2009 Seite 39 von 80

Diplombericht
Master Thesis MAS-07-01.21
3.2.6 Use Case Diagramm (Subscribe)
Use Case Diagramm: LDI (Subscribe)
Subscription
erstellen FA.51.010
Subscribtion
löschen FA.51.020
Subscribtion
aktivieren FA.51.030
ETL - Programmierer
SubscriberView
erstellen FA.52.010
SubscriberView
löschen FA.52.020
DWH System
SubscriberView
extend Window FA.52.030
SubscriberView purge
Window FA.52.040
Abbildung 3-23: Use Case Diagramm (Subscribe)
3.2.7 Übersicht Use Cases (Subscribe)
ID Beschreibung M K
FA.51
Subscription
FA.51.010 Subscription erstellen X
FA.51.020 Subscription löschen X
FA.51.030 Subscription aktivieren X
FA.52
Destinationsystem
FA.52.010 SubscriberView erstellen X
FA.52.020 SubscriberView löschen X
FA.52.030 SubscriberView extend Window X
FA.52.040 SubscriberView purge Window X
Tabelle 3-12: Übersicht Use Cases (Subscribe)
Der gesamt Subscription - Teil besteht aus Kann Anforderungen und wird voraussichtlich in
der Form eines zweiten Releases umgesetzt.
10.09.2009 Seite 40 von 80

Diplombericht
Master Thesis MAS-07-01.21
3.2.8 Spezifikation GUI
Wie schon im Pflichtenheft definiert, orientiert sich das GUI stark am SQL Developer von
Oracle. In diesem Kapitel wird noch auf die verschiedenen Menu und anderen komplexen
Steuerelemente eingegangen.
3.2.8.1 Tree View
Die TreeView ist das zentrale Navigationshilfsmittel der Applikation.
Destination System (DWH)
Source System
Change Source
Change Set
Change Table
Sie wird beim Start der Applikation geladen und
aufgrund der Daten im der DWH Datenbank konfiguriert.
Sie wird auch bei jeder Änderung aktualisiert. Auf den
verschiedenen Knoten werden unterschiedliche Kontext
Menus hinterlegt, welche mit der rechten Maustaste
hervorgerufen werden können. Aussehen und Inhalt der
Kontext Menus können im Kapitel Kontext Menu
entnommen werden.
3.2.8.2 Menu Bar
Je nach Zustand der Applikation werden die Menupunkte aktiviert bzw. deaktiviert. Sichtbar
sind die Menupunkte jedoch immer.
Abbildung 3-24: Menu Bar
Die Tabelle 3-11 zeigt zu welchem Zeitpunkt welche Menupunkte aktiv sind.
Tabelle 3-13: Übersicht Menu Bar
10.09.2009 Seite 41 von 80

Diplombericht
Master Thesis MAS-07-01.21
3.2.8.3 Toolbar
Auf der Toolbar befinden sich nur die nötigsten Werkzeuge. Wie diese ungefähr aussehen
wird, ist auf der Abbildung 3-25 zu entnehmen. Sie wird viel in erster Linie für das Speichern
und Löschen der verschiedenen Objekte verwendet.
Abbildung 3-25: Übersicht Toolbar
3.2.8.4 Kontext Menu auf TreeView
Entsprechend dem Knoten, wo der User mit der rechten Maustaste das Kontext Menu
hervorholt, sind die Menupunkte aktiviert oder nicht. In Tabelle 3-13 sieht man bei welchem
Knoten, welche Punkte aktiviert sind.
Tabelle 3-14: Übersicht Kontext Menu
3.2.8.5 Statusbar
In der Statusbar informiert den Benutzer über den Verlauf der Applikation. Sie wird soviel wie
nötig aktualisiert.
Abbildung 3-26: Übersicht Statusbar
10.09.2009 Seite 42 von 80

Diplombericht
Master Thesis MAS-07-01.21
4 Design
4.1 Applikation
Die Grundregeln der Applikation sind folgende: Die Applikation soll so gebaut werden, dass
keine lokalen Konfigurationsfiles benötigt werden. Die einzigen Angaben, welche die
Applikation lokal bezieht, ist die Anmeldung vom User. Die restlichen Informationen werden
aus der angemeldeten Datenbank gewonnen. Auch dort sollen keine Toolspezifischen
Tabellen angelegt werden, da die gewünschten Informationen in den Systemtabellen von
Oracle vorhanden sind. Somit sollte auch das Setup sehr einfach gestaltet werden können.
4.1.1 Übersicht Struktur
Die Aufgabenstellung fordert kein spezifisches Design. Die Herausforderung besteht darin,
ein für die Grösse der Applikation günstiges Design zu finden. Im .net Kurs wurde die
Trennung in die verschiedenen standard Layer empfohlen.
Abbildung 4-1: Software Layer
• Der Presentation Layer enthält sämtliche Klassen im Zusammenhang mit dem GUI.
• Der Business Layer enthält die Logik der Applikation.
• Der Data Layer enthält die Klassen für die Kommunikation mit der Datenbank. Auch
würde dieser das Lesen bzw. Schreiben von Konfigurationsfiles und Registry
Einträgen steuern. Ein Ziel vom mir ist es aber, in dieser Applikation auf
Konfigurationsfiles und Registry Einträge zu verzichten.
• Der Service Layer enthält unterstützende Klassen, welche auch in späteren Projekten
verwendet werden können und nicht im unmittelbaren Zusammenhang mit dieser
Applikation stehen.
10.09.2009 Seite 43 von 80

Diplombericht
Master Thesis MAS-07-01.21
4.1.2 Source Code
In diesem Kapitel sind Regeln für den Sourcecode angegeben. Die Konventionen für die
Namensgebung ist in der Tabelle 4-2 ersichtlich und müssen für die Lesbarkeit eingehalten
werden.
Kürzel Objekttyp
cbo ComboBox
cbx CheckBox
clp Clipboard
cmd CommandButton
cmnu Contextmenu
ctl Control
dat Data
drv DriveListBox
fil
FileListBox
fra Frame
frm Form
glb Global
img Image
lbl Label
lst ListBox
mdi MDIForm
mnu Menu
opt OptionButton
pic PictureBox
prp PropertyPage
tmr Timer
txt TextBox
vsb VScrollBar
Tabelle 4-1: Namenskonventionen Sourcecode
Das Errorhandling wird in jeder Klasse für jeden Bereich nach dem gleichen Ablauf
implementiert.
10.09.2009 Seite 44 von 80

Diplombericht
Master Thesis MAS-07-01.21
4.2 Datenbank
Bei den DB Modellen wurden nur diese Tabellen berücksichtigt, welche für die Applikation
benötigt werden. Die meisten Tabellen sind auf den Datenbanken nur logische Views, welche
auf Systemtabellen zugreifen. Es handelt sich ausschliesslich um Oracle Tabellen. Das Tool
soll ausschliesslich mit diesen arbeiten und kann somit gegen jede Oracle Enterprise
Datenbank verwendet werden.
4.2.1 DB Model DWH (Destination System)
Abbildung 4-2: DB Model DWH
4.2.1.1 all_change_sources
In dieser View sind die Eigenschaften aller Change Source enthalten.
4.2.1.2 all_change_sets
In dieser View sind die Eigenschaften aller Change Sets enthalten
4.2.1.3 all_change_tables
In dieser View sind die Eigenschaften aller Change Tabellen enthalten
4.2.1.4 all_published_columns
In dieser View sind alle Spalten der Change Tabellen und die dazugehörigen Eigenschaften
enthalten.
10.09.2009 Seite 45 von 80

Diplombericht
Master Thesis MAS-07-01.21
4.2.1.5 all_tables
In dieser View sind alle Tabellen der Datenbank enthalten. Aus dieser Tabelle werden
Informationen wie zum Beispiel der Owner für die Erfassung einiger Objekte gewonnen.
4.2.2 DB Model Source Datenbank
Abbildung 4-3: DB Model Source Datenbank
4.2.2.1 all_tab_columns
Diese View enthält die Eigenschaften der Spalten aller Tabellen auf einer Oracle Datenbank.
Diese Daten werden bei der Erfassung der Changetabellen auf dem GUI benötigt
4.2.2.2 all_tables
In dieser View sind alle Tabellen der Datenbank enthalten. Aus dieser Tabelle werden
Informationen wie zum Beispiel der Owner oder Namen der Sourcetabellen für die Erfassung
auf dem GUI bezogen.
4.2.2.3 all_capture_prepared_tables
In dieser View sind die Tabellen der Sourcedatenbank eingetragen, welche für das Data
Capture vorbereitet sind (Diese Tabellen wurden instanziert).
10.09.2009 Seite 46 von 80

Diplombericht
Master Thesis MAS-07-01.21
5 Testing
5.1 Ziel des Testens
• Verifikation der Anforderungen
• Softwarefehler früh erkennen
5.2 Übersicht der Tests
Objekt
Testmethode nach Phase
Entwurf
Realisierung
GUI Usability Walkthrough Usability Test
Dokumentation
Review
Source Code
Review
Funktionale Anforderungen
Programm starten
Login
Destinationsystem
konfigurieren
Change Source konfigurieren
Change Source löschen
Change Set konfigurieren
Change Set löschen
Changetabelle ändern
Changetabelle purgen
Changetabelle erstellen
Changetabelle löschen
Sourcesystem konfigurieren
Nicht funktionale Anforderungen
Siehe Kapitel 3.3.1 in
Pflichtenheft
Tabelle 5-1: Übersicht Tests
5.3 Testablauf
5.3.1 Ablauf
Systemtest
Systemtest
Systemtest
Systemtest
Systemtest
Systemtest
Systemtest
Systemtest
Systemtest
Systemtest
Systemtest
Systemtest
Systemtest
1. Test-Fälle werden erfasst
2. Ausführen der Test-Fälle
3. Rapportieren und korrigieren der Fehler
4. Wiederholen von Schritt 2 - 3 bis alle Tests erfolgreich sind
5. Schreiben des Test-Reports
5.3.2 Test Dokumentation
• Die Test-Fälle werden in einem spezifischen Dokument festgehalten.
• Gefundene Fehler werden in einem spezifischen Dokument festgehalten.
10.09.2009 Seite 47 von 80

Diplombericht
Master Thesis MAS-07-01.21
5.3.3 Testmethoden
Analyse / Entwurf:
Realisierung:
Abnahme:
Review der Requirements und Dokumente, Usability-
Walkthrough der GUI Skizzen und des ersten Prototyps
Systemtests auf Testsystem
Subset von Systemtests auf Ziel-System
5.3.4 Testfälle
Detailspezifikation und Pflichtenheft dienen als Grundlage für die Identifikation der Testfälle
für die Unit- und Systemtests.
Folgende Eigenschaften werden für jeden Testfall erfasst:
• Fallnummer
• Testfall
• Testschritt Nummer
• Testschritt
• Vorbedingungen
• Beschreibung Testfall
• Erwartetes Ergebnis
• Tatsächliches Ergebnis
• Daten Input
• Daten Output
• Check / Verifikation
5.4 System Test
Bei den Systemtests werden sämtliche funktionalen und nicht funktionalen Anforderungen
getestet. Jeder Use Cases wird manuell durchgetestet. Dazu werden Schnittstellen in den
verschiedenen Möglichkeiten erstellt.
5.5 Usability Test
Nach der Detailspezifikation ist das GUI auf Papier entworfen. Ein erster Walkthrough wird
mit dem ETL - Programmierer durchgeführt und die Erkenntnisse werden dokumentiert und
fliessen direkt in die Entwicklung des Tools ein.
Wenn die erste Lauffähige Version der Applikation erstellt ist, wird ein Usability Test mit dem
ETL - Programmierer durchgeführt. Auch dieses Resultat soll, sofern es mit dem Aufwand
des Projekts zu vereinbaren ist, in die Applikation einfliessen. Ansonsten werden die
Erkenntnisse festgehalten zu einem späteren Zeitpunkt umgesetzt.
10.09.2009 Seite 48 von 80

Diplombericht
Master Thesis MAS-07-01.21
5.6 Testergebnisse
5.6.1 Systemtests
Die Tests wurden alle durchgeführt. Es wurden 29 Tests für die funktionalen Anforderungen
und 17 für die nicht funktionalen Anforderungen erfasst. Diese wurden in einem separaten
Excelfile erfasst. Aufgrund des Formates konnten die Testfälle leider nicht in dieses
Dokument integriert werden.
Bis auf drei Tests waren alle erfolgreich. Die nicht erfolgreichen Tests konnten jedoch
korrigiert werden. Nach einem zweiten Testlauf, konnten alle Tests erfolgreich abgeschlossen
werden.
5.6.2 Usabilitytests
Ein erster Usability Test wurde nach dem Entwurf des GUI für die Detailspezifikation
gemacht. Dieser Walkthrough war sehr aufschlussreich, da der ETL Programmierer auch
genau wusste um welche Technologie es sich handelt und er sich dadurch genaue
Vorstellungen hatte, wie das Endprodukt aussehen könnte. Ein Ziel für das Tool war eine
intuitive Bedienbarkeit. Daher musste die Testperson ohne vorherige Angaben und
Erklärungen berichten, was im aufgefallen ist und fragen, was im unklar war. Diese Fragen
ergaben meist kleine Änderungen am GUI. Diese Änderungen wurden danach mittels
Change Requests erfasst und flossen direkt in die Entwicklung. Dies ersparte einige
nachträgliche Korrekturen.
Das gleiche wurde danach noch zweimal mit den ersten Versionen des Tools gemacht. Diese
Tests können als sehr erfolgreich angesehen, da ich dadurch einige Zeit einsparen konnte.
An dieser Stelle möchte ich dem ETL Programmierer auch herzlich für seine Zeit und sein
Engagement bedanken.
10.09.2009 Seite 49 von 80

Diplombericht
Master Thesis MAS-07-01.21
6 Planung und Zeitmanagement
6.1 Vorgehensmodell
Beim Vorgehensmodell habe ich mich an dem klassischen Wasserfallmodel orientiert. Da in
diesem Projekt die Phasen ziemlich genaue abgrenzbar sind und die Laufzeit auch ziemlich
kurz ist (5 Monate), sollte sich dieses Vorgehen gut eigenen. Auch für ein Einmannprojekt
fand ich dieses Modell sehr geeignet. Folgende Phasen habe ich durchlaufen:
Abbildung 6-1: Vorgehensmodell
Nachfolgend sind die Inhalte und Resultate pro Projektphase aufgelistet:
Projektphase Inhalt Resultat
Initialisierung • Projektinitialisierung Auftraggeber
• Projektantrag
• Kick-Off Meeting Experte
Analyse • Analyse der bestehenden Lösung
• Pflichtenheft
• Analyse möglicher Lösungswege
• Projektplan
• Diskussion mit Auftraggeber und ETL
Programmierer
• Definition Ziele und Anforderungen
• Projektablauf festlegen
• Erstellung Pflichtenheft
Entwurf • Erhöhung des Verständnisses der
Anforderungen
• Detailspezifikation
• Erstellen der notwendigen UML
Diagramme
• Erarbeiten der Detailspezifikation
• Definition der Testfälle
Realisierung • Konfiguration der Umgebung
• Entwicklung GUI
• Testen der Software
• Erstellung Benutzerhandbuch
Einführung • Umsetzung der neuen Technik in
einem Bereich
• Fertigstellung Diplombericht
• Präsentation der Diplomarbeit
Nutzung • Nicht Bestandteil der Diplomarbeit
• Flächendeckender Einsatz der neuen
Technik
Tabelle 6-1: Inhalte und Resultate der Projektphasen
• Benutzerhandbuch
• Installationshandbuch
• Software
• Testprotokoll
• Diplombericht
• Komplette ETL
Schnittstelle auf
neuen Technik
umgesetzt
10.09.2009 Seite 50 von 80

Diplombericht
Master Thesis MAS-07-01.21
6.2 Zeitmanagement
Arbeit
Aufwand
Ist pro
geplant Ist Kategorie
Projektleitung 24 21 21
Dokumentation 124 116
Projektantrag 2 3
Pflichtenheft 36 40
Detailspezifikation 36 32
Benutzerhandbuch 14 10
Diverse Protokolle 8 9
Diplombericht 28 22
Prototyping 42 58 58
Analyse 24 21
Bestehende Lösung 8 4
Lösungswege 14 14
Entscheide 2 3
Entwurf 28 30
Architektur 12 10
Design 16 20
Realisierung 132 134
Installation Testumgebung 10 7
Konfiguration Umgebung 10 6
Ausbildung .net 32 32
Programmierung
Konfigurationstool 44 56
Testing 36 33
Einführung 32 27
Konfiguration produktive
Umgebung 10 7
Installation Konfigurationstool 10 6
Inbetriebsetzung Schnittstelle 8 11
Schulung Anwender 4 3
Aufwand Total 392 407 407
Tabelle 6-2: Zeitmanagement
Angaben zum Zeitmanagement und warum die geplante Zeit nicht ganz gereicht hat, werden
im Kapitel Ausblick und Schlusswort gemacht.
10.09.2009 Seite 51 von 80

6.3 Projektplan / Zeitplan und Meilensteine
Abbildung 6-2: Projektplan
10.09.2009 Seite 52 von 80

Diplombericht
Master Thesis MAS-07-01.21
6.4 Termine
Termin
Ziel
20.04.2009 Review Pflichtenheft
23.04.2009 Abgabe Pflichtenheft
04.06.2009 Review Entwurf (Detailspezifikation)
20.08.2009 Review Realisierung
10.09.2009 Abgabe Diplomarbeit
11.09.2009 Präsentation Diplomarbeit
Tabelle 6-3: Termine
6.5 Projektmanagement
Der Projektplan kann aufgrund neuer Erkenntnisse einer vorgängigen Phase überprüft und
angepasst werden. In der Entwurfsphase wird nach Bedarf eine zweite Iteration durchgeführt,
um die Analyse zu verfeinern und zu vertiefen. In diesem Projekt wurde keine zweite Iteration
benötigt.
6.6 Meetings / Reviews /Statusmeldungen
6.6.1 Meetings
Mit dem Experten wurde nach jeder Phase ein Meeting durchgeführt.
Mit dem Betreuer, welcher auch gleichzeitig der Auftraggeber darstellt, wurden nur nach
Bedarf Meetings durchgeführt.
6.7 Reviews
Die Meetings mit dem Experten, wurden meist als Review einer vergangenen Phase
verwendet.
6.7.1 Statusmeldungen
Dem Experten und dem Betreuer wurde jede zweite Woche ein Statusreport (Vorlage von
BFH) gesendet, damit diese über den Projektfortschritt auf dem Laufenden waren.
10.09.2009
Seite 53 von 80

Diplombericht
Master Thesis MAS-07-01.21
7 Erfüllung der Anforderungen und Ziele
In diesem Kapitel werden die gesteckten Ziele und die verschiedenen Anforderungen mit dem
Resultat verglichen. In den untenstehenden Tabellen gibt es jeweils eine Spalte M oder K
welche angeben, ob es jeweils eine Muss bzw. Kann Anforderungen ist.
7.1 Nicht funktionale Anforderungen
ID Beschreibung M K Erfüllt
NFA.01 Architektur / Plattform
NFA.01.010 Das GUI muss auf eine Emmi Standard PC lauffähig sein X
NFA.01.020 Als Datenbanksystem muss Oracle unterstützt werden X
NFA.01.030 Die Erstellung des GUI soll im Visual Studio .net erfolgen X
NFA.02 Zuverlässigkeit / Stabilität
NFA.02.010 Die Stabilität der neue Schnittstellentechnik soll
mindestens der jetzigen Technik entsprechen
NFA.03 Performance
NFA.03.010 Die Belastung der Quellsysteme soll um mindestens 70% X
verringert werden
NFA.03.020 Die Daten jeder Schnittstelle sollen täglich übernommen X
werden können.
NA.04 Konfiguration
NFA.04.010 Mit der neuen Technik soll der Aufwand der Konfiguration X
einer neuen Schnittstelle um 50% verringert werden
NFA.04.020 Auf Trigger in den Quellsystemen soll verzichtet werden X
können
NFA.05 Monitoring / Logging
NFA.05.010 Alle Konfigurationen sollen geloggt und ausgewertet
X
werden können.
NFA.06 Dokumentation
X *
NFA.06.010 Installationshandbuch muss erstellt werden X
NFA.06.020 Benutzerhandbuch muss erstellt werden X
NFA.06.030 Projektbericht muss erstellt werden X
NFA.07 Sicherheit
NFA.07.010 Die Benutzerverwaltung soll dem Emmi Standard für
X
Datenbankbenutzer entsprechen
NFA.08 Sprache
NFA.08.010 Die Sprache im Tool muss englisch sein X
NFA.08.020 Die Dokumentation soll ausschliesslich in deutscher X
Sprache erfolgen.
NFA.09 Usability
NFA.09.010 Ein ETL - Programmierer soll sich intuitiv im GUI
X
zurechtfinden (Know - How CDC wird vorausgesetzt)
NFA.09.020 Das System soll den User unterstützen möglichst wenig X
Fehler zu machen
Tabelle 7-1: Anforderungskatalog nicht funktionaler Anforderungen
* Diese Anforderung kann erst in ca. einem halben Jahr abschliessend beurteilt werden.
10.09.2009 Seite 54 von 80

Diplombericht
Master Thesis MAS-07-01.21
7.2 Funktionale Anforderungen
7.2.1 Publisher Teil
ID Beschreibung M K Erfüllt
FA.01
Startup Applikation
FA.01.010 Programm starten X
FA.01.020 Login X
FA.02
Destinationsystem
FA.02.010 Destinationsystem konfigurieren X -
FA.03
Change Source
FA.03.010 Change Source konfigurieren X
FA.03.020 Change Source löschen X
FA.04
Change Set
FA.04.010 Change Set konfigurieren X
FA.04.020 Change Set löschen X
FA.05
Change Tabelle
FA.05.010 Changetabelle ändern X
FA.05.020 Changetabelle purgen X
FA.05.030 Changetabelle erstellen X
FA.05.040 Changetabelle löschen X
FA.06
Sourcesystem
FA.06.010 Sourcesystem konfigurieren X
Tabelle 7-2: Übersicht Use Cases (Publish)
Diese Kann Anforderungen wurden verworfen (Change Request ID 2)
- Diese Kann Anforderung wurde nicht implementiert.
7.2.2 Subscriber Teil
ID Beschreibung M K Erfüllt
FA.51
Subscription
FA.51.010 Subscription erstellen X -
FA.51.020 Subscription löschen X -
FA.51.030 Subscription aktivieren X -
FA.52
Destinationsystem
FA.52.010 SubscriberView erstellen X -
FA.52.020 SubscriberView löschen X -
FA.52.030 SubscriberView extend Window X -
FA.52.040 SubscriberView purge Window X -
Tabelle 7-3: Übersicht Use Cases (Subscribe)
- Der gesamte Subscriber Teil wird in einer zukünftigen Version umgesetzt
10.09.2009 Seite 55 von 80

Diplombericht
Master Thesis MAS-07-01.21
7.3 Ziele
Die gesetzten Ziele konnten wie in Tabelle 7-1 ersichtlich erreicht werden. Einige wurden
übertroffen, da die Daten mindestens jede halbe Stunde (Redolog Switch auf der
Sourcedatenbank) an das Datawarehouse übertragen werden. Somit können sicher alle
Tabellen täglich in den Stagingbereich übernommen werden, egal wie gross diese sind.
Auch die Belastung kann sehr gering gehalten werden, da nur noch das senden der
archivierten Redologs das Sourcesystem belasten und eine solche Belastung kann fast
vernachlässigt werden.
Um die Stabilität abschliessend zu beurteilen, bedarf es längerer Erfahrung. Da Change Data
Capture eine etablierte Technologie bei Oracle darstellt, sollte auch dies kein Problem
darstellen.
Mit dem entwickelten Tool ist es nun auch möglich, eine Tabelle innerhalb kürzester Zeit in
den Stagingbereich zu bringen und zu konfigurieren. Die anschliessende Transformation der
Daten muss jedoch weiterhin gemacht werden und in diesem Teil wird keine weitere Zeit
eingespart.
Auf die Trigger in der Source Datenbanken kann in Zukunft verzichtet werden, da Change
Data Capture nur die Änderungen überträgt.
Der Grundstein für eine schlanke Übernahme ist nun gelegt, nun gilt es diese Technologie
flächendeckend einzuführen.
10.09.2009 Seite 56 von 80

Diplombericht
Master Thesis MAS-07-01.21
8 Erfahrungen
8.1 Resultat
Mit dem Resultat bin ich grundsätzlich zufrieden. Alle Muss Anforderungen wurde umgesetzt
und einige Kann Anforderungen konnten auch umgesetzt und getestet werden. Zudem
konnte, durch die zahlreichen Change Requests, die Qualität des Tools gegenüber der ersten
Planung zusätzlich verbessert werden.
Bei der Programmierung hatte ich einige Ideen, welche sich hinterher als sehr praktisch
erwiesen haben. Diese Ideen haben mich aber am Anfang sehr viel Zeit gekostet. Dadurch
konnte die geplante Zeit für den Programmieraufwand um einige Stunden nicht eingehalten
werden. Da ich nicht als Programmierer tätig bin, hätte man wahrscheinlich an einigen Stellen
eine professionellere Lösung finden können. Der technische Teil hat aber grossen Spass
gemacht und war für mich sehr lehrreich. Speziell aufwendig war das GUI, welches ich auch
ein wenig unterschätzt habe. Es konnten aber trotzdem viele Funktionen, welche den
Benutzer unterstützen (Shortcuts, Toolbar, Verhinderung von Fehleingaben, etc.) eingebaut
werden. Auch die TreeView wurde mit selbst kreierten Icons ausgestattet.
Ein Punkt welcher man hervorheben könnte ist, dass das Tool keine einzige Tabelle oder
Konfigurationsdatei benötigt. Es bezieht alle Informationen aus den Standardtabellen der
Oracle Datenbank und der Change Data Capture Technologie und auch das Login
funktioniert über die normale Benutzerverwaltung der Datenbank.
8.2 Ausblick
Während der Entwicklung des Tools, sind mir immer Funktionen aufgefallen, welche die
tägliche Arbeit des ETL - Programmierers vereinfachen könnten. Diese Funktionen haben
zum Teil gar nichts mit der Technologie Change Data Capture zu tun, wären aber zum Teil
extrem praktisch. Deshalb wird das Tool in Zukunft einige neue Features erfahren.
Geplante Features für Version 2:
• Verwaltung Subscribtion - Views
• Dashboard um über den Betriebszustand einfach eine Überblick zu erhalten
• Datenansicht der Changetabellen
• Einige kleinere Anpassungen am GUI
10.09.2009 Seite 57 von 80

Diplombericht
Master Thesis MAS-07-01.21
8.3 Schlusswort
Die ganze Zeit der Diplomarbeit war spannend, aber auch sehr anspruchsvoll. Da ich
während der ganzen Zeit 100% in der Firma engagiert war und dadurch nicht mehr allzu viel
Freizeit hatte. Ich konnte in dieser Zeit aber äusserst wertvolle Erfahrungen sammeln.
Was bei der Dokumentation immer ein Problem war, war einen gesunden Mittelweg zwischen
Detaillierungsgrad, Wahrung der Übersicht und Aufwand zu finden. Daher bin ich eigentlich
positiv Überrascht, dass der Terminplan in vielen Bereichen sehr gut eingehalten werden
konnte. Als Highlight kann sicher die Detailspezifikation angesehen werden. Hätte ich doch
viel lieber schon im Mai mit der Umsetzung begonnen. Der Aufwand für eine genauere
Analyse hat sich aber voll ausbezahlt.
Zu guter Letzt möchte ich es nicht unterlassen, mich bei meinem Experten Herr Thomas
Glauser zu bedanken, welcher mich durch dieses halbe Jahr begleitet hat und mir mit guten
Ratschlägen zur Seite stand.
10.09.2009 Seite 58 von 80

Diplombericht
Master Thesis MAS-07-01.21
9 Installations- und Betriebshandbuch
Für das Installations- und Betriebshandbuch gibst es separates Dokument, welches auch auf
der CD mit dem Setup vorhanden sein wird. Im diesem Diplombericht werden nur die
wichtigen Kapitel angehängt.
9.1 Technische Umgebung
Dieses Kapitel gibt Auskunft über die technische Umgebung, in welcher das Tool LDI
einwandfrei funktioniert. Bei unterschiedlichen Versionen kann ein einwandfreier Betrieb nicht
garantiert werden.
9.1.1 Client
Betriebssystem: Windows XP
DB-Verbindung: Oracle Client 11g oder 10g
Framework: Microsoft .net Framework 3.5
9.1.2 Datenbank
9.1.2.1 RDBMS
RDBMS:
Oracle Enterprise Database11g
9.1.2.2 Server Umgebung
Das Betriebssystem des RDBMS ist nicht relevant für die Funktionalität von LDI.
10.09.2009 Seite 59 von 80

Diplombericht
Master Thesis MAS-07-01.21
9.2 Installation
Die Installation muss in der gleichen Reihenfolge wie in diesem Kapitel vollzogen werden.
9.2.1 Datenbank
9.2.1.1 Konfiguration Change Data Capture
Hier wird auf das Dokument des Herstellers (Oracle) verwiesen.
Oracle Data Warehousing Guide 11g Release 1 (B28313-02)
9.2.1.2 Konfiguration LDI Tool
9.2.1.2.1 View erstellen (Abfrage Alert Log)
Damit das Tool die Alerts von der Datawarehouse Datenbank abfragen kann, muss eine View
erstellt werden:
1. Auf Datawarehouse als User SYS (as sysdba) einloggen.
2. View mit untenstehendem SQL erstellen
Vorgang
SQL
View erstellen CREATE OR REPLACE VIEW "SYS"."LDI_ALERTLOG" AS
SELECT * FROM X$DBGALERTEXT WITH READ ONLY
Tabelle 9-1: SQL View erstellen
9.2.1.2.2 User erstellen
Auf dem Datawarehouse und auf den entsprechenden Source Datenbanken muss ein
Publisher User erstellt werden:
1. Auf Datawarehouse oder auf der Source Datenbank als User System einloggen.
2. User mit untenstehendem SQL erstellen
Vorgang
SQL
User erstellen CREATE USER CDC_PUBLISHER IDENTIFIED BY *Password
DEFAULT TABLESPACE *Tablespacename;
GRANT DBA TO CDC_PUBLISHER;
Tabelle 9-2: SQL User erstellen
*Password:
*Tablespacename:
Gewünschtes Passwort eingeben
Als Tablespacename soll der Tablespace angegeben werden, welcher
die Change Tabellen enthalten wird.
10.09.2009 Seite 60 von 80

Diplombericht
Master Thesis MAS-07-01.21
9.2.1.2.3 DB Links zu gewünschten Source - Systemen erstellen
Damit das Tool die Meta-Daten von den Source Datenbanken beziehen kann, muss ein
Datenbanklink pro Source Datenbank auf der Datawarehouse Datenbank erstellt werden.
1. Auf Datawarehouse oder auf der Source Datenbank als User System einloggen.
2. Link mit untenstehendem SQL erstellen
Vorgang
SQL
Link erstellen CREATE PUBLIC DATABASE LINK *Linkname
USING *Servicename
Tabelle 9-3: SQL Link erstellen
*Linkname:
*Servicename:
Der Linkname muss zwingend der gleiche Name sein wie der
Servicename
Der Servicename der Source - Datenbank angeben
9.2.2 Setup
Um das Setup zu starten muss die Datei EmmiLDISetup.msi ausgeführt werden. Ansonsten
ist das Setup selbsterklärend.
Startfenster
Abbildung 9-1: Setup Startfenster
10.09.2009 Seite 61 von 80

Diplombericht
Master Thesis MAS-07-01.21
Auswahl Installationsordner
Abbildung 9-2: Setup Installationsordner
Bestätigung Installation
Abbildung 9-3:Setup Bestätigung Installation
10.09.2009 Seite 62 von 80

Diplombericht
Master Thesis MAS-07-01.21
Ausführung Installation
Abbildung 9-4:Setup Ausführung Installation
Installation erfolgreich
Abbildung 9-5: Setup Installation erfolgreich
10.09.2009 Seite 63 von 80

Diplombericht
Master Thesis MAS-07-01.21
9.3 Benutzerhandbuch
In diesem Benutzerhandbuch sind die Möglichkeiten und die Handhabung des LDI Tools
beschrieben. Es bietet einen groben Überblick über die Funktionen dieses Tools. Um Change
Data Capture zu administrieren wird aber ein gutes Know-How über diese Technologie
vorausgesetzt. Auf diese Technologie wird jedoch in diesem Handbuch nicht eingegangen,
da diese in unzähligen Oracle Dokumenten zu genüge beschrieben ist. Ein empfehlenswertes
Dokument ist der Oracle Data Warehousing Guide 11g Release 1 (B28313-02) hier wird
Change Data Capture im Kapitel 16 genau beschrieben.
9.3.1 Über LDI
Mit LDI Version 1.0 kann die Technologie Change Data Capture von Oracle verwaltet
werden. Es sind sowohl Changesourcen, Changesets und Changetables administrierbar. Alle
möglichen Funktionen können in diesem Tool ausgeführt oder angepasst werden. In einer
späteren Version werden auch die Subscription View administriert werden können.
9.3.2 Startup LDI
Beim aufstarten des Programms, wird die Loginmaske (Abb. 4-1) angezeigt. Dort müssen die
Benutzerangaben (Publisher) der Datawarehouse Datenbank angegeben werden.
Die Anmeldung erfolgt genau gleich wie diese bei normalen Oracle Datenbanken. Für
detaillierte Angaben wird an dieser Stelle auf die Dokumentation von Oracle verwiesen.
Abbildung 9-6: Loginmaske
10.09.2009 Seite 64 von 80

Diplombericht
Master Thesis MAS-07-01.21
9.3.3 Benutzeroberfläche
Die Benutzeroberfläche (Abb. 4-2) ist wie die gewohnten Microsoft Produkte aufgeteilt. Sie
lehnt sich auch sehr an den SQL Developer von Oracle. Am oberen Rand befinden sich die
Menuleiste und die Toolbar. Am unteren Rand ist die Statusleiste angebracht.
Auf der linken Seite befindet sich eine TreeView, welche die zentrale Navigation für das
gesamt Tool darstellt. Der rechte Teil ist der eigentliche Arbeitsbereich.
Abbildung 9-7: Benutzeroberfläche
1. Menuleiste & Toolbar
2. TreeView
3. Eigenschaften der ausgewählten Objekte
4. Statusbar
10.09.2009 Seite 65 von 80

Diplombericht
Master Thesis MAS-07-01.21
9.3.4 TreeView
Die TreeView ist die zentrale Navigation des LDI Tools. Sie zeigt die gesamte Hierarchie des
Change Data Capture eines Datawarehouses. Mit Doppelklick auf ein Knoten, wird das
ausgewählte Objekt im rechten Arbeitsbereicht des Tools angezeigt und kann danach
bearbeitet werden. Ein Klick mit der rechten Maustaste bewirkt das Anzeigen eines
Kontextmenüs. Auf diesem Menu sind nur die möglichen Punkte aktiviert. Die anderen
Punkte sind zwar sichtbar, aber nicht auswählbar.
Abbildung 9-8: TreeView
10.09.2009 Seite 66 von 80

Diplombericht
Master Thesis MAS-07-01.21
9.3.5 Objekte bearbeiten
Wenn ein Objekt bearbeitet wird, werden im rechten Teil der Applikation die verschiedenen
Eigenschaften und Optionen angezeigt. Dieser Teil ist mit verschiedenen Registern unterteilt.
Abbildung 9-9: Register des Bearbeitungsteils
1. Register zur Erfassung der Eigenschaften und Optionen der Source Datenbank.
2. Register zur Erfassung der Eigenschaften und Optionen der Datawarehouse
Datenbank.
3. Dieses Register enthält die zuletzt ausgeführten SQL Statements im Zusammenhang
mit Change Data Capture. Diese Statements können auch in einem normalen SQL-
Tool ausgeführt werden und sollen detailliert aufzeigen, was genaue konfiguriert
wurde.
4. Im Register Log sind die Alertmeldungen der DWH Datenbank aufgelistet. Dies gibt
detailliert Auskunft über den Zustand der DB und der verschiedenen Capture
Prozesse.
9.3.6 Changesourcen bearbeiten
Wenn eine Changesource zur Bearbeitung ausgewählt wird oder eine neue erstellt werden
soll, werden im rechten Teil der Applikation die Eigenschaften angezeigt. Bei Erstellung
können alle Eigenschaften erfasst werden. Bei Änderung einer Changesource können nur
diese Felder verändert werden, welche noch änderbar sind. Die Applikation lässt nur Zeichen
zur Eingaben zu, welche auch von Oracle unterstützt werden, dies soll den Benutzer vor
Fehleingaben schützen.
Abbildung 9-10: Changesource bearbeiten
1. Changesource Name
2. Beschreibung der Changesource
3. Auswahl der Source Datenbank (hier werden nur diese Datenbanken angezeigt,
welche auch mit Change Data Capture funktionieren)
4. Erfassung der SCM (System Change Number). Mit dieser Option kann angegeben
werden, ab welchem Zeitpunkt der Captureprozess starten soll. Der momentane Wert
wird jeweils automatisch vom Tool abgefragt und angezeigt. Mit der Eingabe NULL
wird diese Option so belassen wie sie ist.
10.09.2009 Seite 67 von 80

Diplombericht
Master Thesis MAS-07-01.21
9.3.7 Changesets bearbeiten
Wenn ein Changeset zur Bearbeitung ausgewählt wird oder ein neues erstellt werden soll,
werden im rechten Teil der Applikation die Eigenschaften angezeigt. Bei Erstellung können
alle nötigen Eigenschaften erfasst werden. Bei Änderung einer Changesource können nur
diese Felder verändert werden, welche noch änderbar sind. Die Applikation lässt nur Zeichen
zur Eingaben zu, welche auch von Oracle unterstützt werden, dies soll den Benutzer vor
Fehleingaben schützen.
Abbildung 9-11: Changesets bearbeiten
1. Changeset Name
2. Beschreibung des Changesets
3. Name der übergeordneten Changesource. Dieser kann nie verändert werden.
4. Option Stop on DDL
5. Hier kann der Zeitraum des Capturings genau definiert werden. Bei der Auswahl
NULL werden keine zeitlichen Begrenzungen gesetzt
6. Hier können drei weitere Optionen für den Capturingprozess gesetzt werden:
• Enable Capture
• Recover after Error
• Remove DDL
Die Optionen für die Changesets sind im Dokument Oracle Data Warehousing Guide 11g
Release 1 (B28313-02) ausführlich beschrieben.
10.09.2009 Seite 68 von 80

Diplombericht
Master Thesis MAS-07-01.21
9.3.8 Changetabellen bearbeiten
Wenn eine Changetabelle zur Bearbeitung ausgewählt wird oder eine neue erstellt werden
soll, werden im rechten Teil der Applikation die Eigenschaften angezeigt. Bei Erstellung
können alle nötigen Eigenschaften erfasst werden. Bei Änderung einer Changesource
können nur diese Felder verändert werden, welche noch änderbar sind. Die Applikation lässt
nur Zeichen zur Eingaben zu, welche auch von Oracle unterstützt werden, dies soll den
Benutzer vor Fehleingaben schützen.
9.3.8.1 Source Properties
Hier werden die Angaben der Sourcetabelle erfasst.
Abbildung 9-12: Changetabelle Source bearbeiten
1. Auswahl Source Datenbank. Diese kann nie verändert werden, da sie vom
übergeordneten Changeset vorgegeben ist.
2. Owner der Source Tabelle. Bei dieser Auswahl werden nur mögliche Owner
angezeigt. Systemuser sind nicht enthalten.
3. Auswahl der Sourcetabelle. Hier werden nur diese Tabellen zur Verfügung gestellt,
welche zum ausgewählten Owner gehören.
Die Optionen für die Changesets sind im Dokument Oracle Data Warehousing Guide 11g
Release 1 (B28313-02) ausführlich beschrieben.
10.09.2009 Seite 69 von 80

Diplombericht
Master Thesis MAS-07-01.21
9.3.8.2 Destination Properties
Hier werden die Angaben der Destinationtabelle (Capture Table) erfasst.
Abbildung 9-13: Changetabelle Destination bearbeiten
1. Auswahl Destination Owner. Hier stehen nur mögliche Owner des Datawarehouses
zur Auswahl.
2. Name der Changetabelle. Hier lässt das Tool nur Oracle kompatible Zeichen zu.
3. Auswahl des Changesets. Diese ist nie mutierbar, da diese durch das übergeordnete
Changeset gegeben ist.
4. Diese Auswahl beinhaltet die Capture Values. Folgende Werte können ausgewählt
werden:
• New = Nur die neuen Werte der Updates auf der Sourcetabelle werden in die
Changetabelle geschrieben
• Old = Nur die Werte vor einem Update auf der Sourcetabelle werden in die
Changetabelle geschrieben
• Both = Es werden sowohl die alten wie auch die neuen Werte bei einem
Update auf der Sourcetabelle in die Changetabelle geschrieben
10.09.2009 Seite 70 von 80

Diplombericht
Master Thesis MAS-07-01.21
5. Im Feld Optionsstring können weitere Optionen für das kreieren eine Tabelle
angegeben werden. Die Syntax ist die gleiche wir bei einem normalen CREATE
TABLE DDL Befehl. Die möglichen Optionen können in der Oracle Dokumentation
nachgelesen werden. (Oracle Database Administrator’s Guide 11g Release 1
(B28310-01))
6. In dieser Liste werden die Spalten einer Tabelle angezeigt. Ob es die Spalten der
Sourcetabelle oder diese der Changetabelle sind ist abhängig von der Auswahl bei
Punkt 8.
7. In diesem Bereich werden die konfigurierten Hilfsspalten der Changetabelle
angezeigt. Dieser Bereich dient nur zur Anzeige.
8. Bei den beiden Checkboxen „Add“ und „Drop“ wird entschieden, ob die selektierten
Spalten entfernt bzw. hinzugefügt werden sollen. Wenn die Checkbox „Add“ selektiert
ist, werden in der Liste (Punkt 6) alle Spalten der Sourcetabelle angezeigt, welche
noch nicht in der Changetabelle vorhanden sind. Ist die Checkbox „Drop“ angewählt,
werden in der Liste (Punkt 6) alle Spalten der Changetabelle angezeigt. Diese beiden
Checkboxen haben auch Einfluss auf den Bereich von Punkt 9. Wenn in diesem
Bereich eine Hilfsspalte auf Y (yes) steht, wird diese auch entfern bzw. hinzugefügt.
9. In diesem Bereich kann angegeben werden, ob eine Hilfsspalte hinzugefügt bzw.
entfernt werden soll. Siehe auch Punkt 8.
Die Optionen für die Changetabellen und die Hilfsspalten sind im Dokument Oracle Data
Warehousing Guide 11g Release 1 (B28313-02) ausführlich beschrieben.
10.09.2009 Seite 71 von 80

Diplombericht
Master Thesis MAS-07-01.21
9.3.9 Shortcuts
Die folgenden Shortcuts können genutzt werden:
Shortcut
[Strg] + [C]
[Strg] + [V]
[Strg] + [X]
[Strg] + [F4]
[Strg] + [Tab]
[Alt] + [Leertaste]
[Alt] + [Leertaste] + [X]
[Alt] + [Leertaste] + [N]
[Alt] + [Leertaste] + [X]
[Alt] + [unterstrichener Menubuchstabe]
[Shift] + [F10]
[Shift] + [Tab]
Tabelle 9-4: Shortcuts
Beschreibung
Kopieren
Einfügen
Ausschneiden
Applikation schliessen
Register wechseln
(mit Shift gegen den Uhrzeigersinn)
Systemmenü
Fenster maximieren
Fenster minimieren
Fenster wiederherstellen
Menupunkt Aufruf
Kontextmenu öffnen
Rückwärts durch Optionen
9.3.10 Fehlerbehandlung
Tritt in der Applikation eine Fehler auf, so wird dieser mit einem Error Provider angezeigt
(Abb. 4-9). Beim Auftreten eines Fehlers, wird der rote Punkt mit dem Ausrufezeichen
blinkend angezeigt. Um die genaue Fehlermeldung anzuzeigen, muss mit dem Mauszeigen
auf dem roten Punkt positioniert werden. Mit einem Mausklick irgendwo im Fenster des Error
Provider, kann der Fehler ausgeblendet werden. Ist der Fehler im Change Data Capture
aufgetreten, wird immer die original Fehlermeldung der Datenbank im Tool ausgegeben.
Abbildung 9-14: Fehleranzeige
10.09.2009 Seite 72 von 80

Diplombericht
Master Thesis MAS-07-01.21
10 Change Requests
Die Usability Test haben immer wieder einige kleinere Änderungen ergeben, welche aber für
die Applikation zum Teil einen erheblichen Mehrwert dargestellt haben. Diese Änderungen
wurden in der Form von Change Requests aufgenommen. Die Änderungen, welche vom
Auftraggeber bewilligt wurde, wurden innerhalb dieses Projekts umgesetzt. Die
nichtgenehmigten Änderungen werden voraussichtlich in einem späteren Release umgesetzt.
Auf den folgenden Seiten sind die Change Request tabellarisch dargestellt.
Angaben zur Tabelle Change Requests:
Personen
Kurzzeichen
Experte Thomas Glauser
TGL
ETL - Programmierer Stéphane Probst SPR
Auftraggeber Urs Müller
UMU
Tabelle 10-1: Personen Change Request
10.09.2009 Seite 73 von 80

CR
Nr. Beschreibung
Anforderungs-
ID
Mehrkosten
Nein / Ja
(Betrag)
Grund
Bewilligung
durch
Auftraggeber
(UMU)
Review
durch
1
Bei der Detailspezifikation wurden aufgrund
neuer Erkenntnisse die Funktionalen
Anforderungen nochmals überarbeitet. Deshalb
wird beantragt, die Anforderungen der
Detailspezifikation als die geltenden dieses
Projekts zu bewilligen.
Funktionale
Anforderungen
Pflichtenheft
Nein
Mit den überarbeiteten Anforderungen,
können die Projektziele nicht nur
erreicht, sondern übertroffen werden.
Auch kann das Tool für spätere
Erweiterungen, besser konzipiert
werden.
̌
TGL
SPR
2
3
4
5
6
Die in der Detailspezifikation definierte
Verwaltung des Sourcesystems kann komplett
weggelassen werden, da die Detailanalyse
gezeigt hat, dass eine elegantere Lösung mit
den Change Sourcen möglich ist. Das
Sourcesystem hat nur eine informative Funktion
und diese Informationen können aus der
Change Source bezogen werden. Deshalb
können die Anforderungen des Sourcesystems
weggelassen werden. FA.06.010 Nein
Auf dem GUI ist ein Reiter geplant, welcher
anzeigt, was im
Moment bearbeitet wird. Dieser ist überflüssig Gesamtes GUI Nein
Das Change Set kann aktiviert bzw. deaktiviert
werden.
Dies kann der Benutzer bequemer über das
Kontextmenu in der TreeView verwalten, als auf
dem rechten Panel im Konfigurationsteil des
Tools FA.04.010 Nein
Bei der Erstellung einer Changetabelle wäre
eine Listbox effektiver als eine ComboBox. FA.05.030 Nein
Beim erstellen oder ändern einer Changetabelle
konnte der Type der Spalten verändert werden.
Dies wird als nicht sinnvoll erachtet.
FA.05.010
FA.05.030
Nein
Ein Ziel der Applikation ist, dass
möglichst wenige
Daten in einer speziellen Tabelle oder
in einem Konfigurationsfile abgelegt
werden. Dies damit eine sehr schlanke
Verwaltung dieses Tools möglich ist.
Auch der Usability Walkthrough hat
ergeben, dass die Verwaltung des
Sourcesystems überflüssig und es zu
einer schlankeren Handhabung beiträgt. ̌ SPR
Der Usability Walkthrough hat ergeben,
dass dieser Reiter überflüssig ist und
kann deshalb weggelassen werden. ̌ SPR
Der Usability Walkthrough hat ergeben,
dass die
Manipulation über ein Kontextmenu für
den Benutzer einfacher und logischer
ist. ̌ SPR
Der Usability Walkthrough hat ergeben,
dass die Auswahl einer Sourcetabelle
so einfacher wird. ̌ SPR
Beim Usability Walkthrough ist
aufgefallen, dass die Änderung der
Datentypen nicht sinnvoll ist ̌ SPR
10.09.2009 Seite 74 von 80

CR
Nr. Beschreibung
7
8
9
Nach Anmeldung des Benutzers, wird auf dem
rechten Panel nichts angezeigt. Dort könnten
einige Angaben zum Zustand der verschiedenen
Prozesse stehen.
Auf der rechten Seite im GUI sollte immer ein
Reiter Log vorhanden sein. In diesem kann der
jeweilige Status der Ausführung angeschaut
werden
Auf der rechten Seite im GUI ist ebenfalls eine
Toolbox geplant. Dies ist überflüssig, da die
gleichen Buttons auch auf der Haupttoolbox
vorhanden sind.
Anforderungs-
ID
Mehrkosten
Nein / Ja
(Betrag)
Neue Anforderung
(Kann) Ja (700.--)
Neue Anforderung
(Kann) Ja (800.--)
Bewilligung
durch
Auftraggeber Review
Grund
(UMU) durch
Beim Usability Walkthrough und der
dazu geführten Diskussion ist
aufgefallen, dass diese
Statusinformationen sehr praktisch für
den User wären. SPR
Wenn eine Ausführung aus dem Tool
nicht erfolgreich ist, muss analysiert
werden warum nicht. Das Log ist daher
sehr nützlich und sollte direkt im Tool
angesehen werden können. ̌ SPR
FA.02.XX,
FA.03.XX,
FA.04.XX,
FA.05.XX Nein Siehe Beschreibung ̌ SPR
10
Im Contextmenu sollte ein Save Menu Punkt
vorhanden sein
Kontextmenu
Kapitel 3.2.8.4
in Detailspezifikation
Nein
Dieser Menupunkt wäre in manchen
Fällen praktisch und gibt keinen
Mehraufwand ̌ SPR
11
Im Menu wurde ein File / Open Menupunkt
geplant, dieser kann weggelassen werden
Menu Bar
Kapitel 3.2.8.4
in Detailspezifikation
Nein
Dieser Menupunkt ist überflüssig und
kann zum Teil verwirrend wirken ̌ SPR
12
Im Menu wurde unter Run ein Delete Button
geplant, dieser sollte unter der Gruppe File
platziert werden
Menu Bar
Kapitel 3.2.8.4
in Detailspezifikation
Nein
Der Menupunkt ist für den User unter
File logischer zu finden. Dies hat ein
weiterer Usability Test mit dem ETL
Programmierer ergeben ̌ SPR
13
In der Toolbar kann der Open Button
weggelassen werden
Tool Bar
Kapitel 3.2.8.3
in Detailspezifikation
Nein
Dieser Button ist überflüssig und kann
zum Teil verwirrend wirken ̌ SPR
10.09.2009 Seite 75 von 80

CR
Nr. Beschreibung
Anforderungs-
ID
Mehrkosten
Nein / Ja
(Betrag)
Grund
Bewilligung
durch
Auftraggeber
(UMU)
Review
durch
14
Im Menu unter der Gruppe View ist der Log
Menupunkt überflüssig.
Da nicht nur eine Tabelle, sondern auch ein
ChangeSet oder die ganze Tabelle gepurged
werden können, sollte dies auch im Tool
15 möglich sein.
Tabelle 10-2: Change Requests
Menu Bar
Kapitel 3.2.8.4
in Detailspezifikation
Nein
Neue Anforderung
(Muss) Ja (300.--)
Dieser Punkt wurde durch den Change
Reguest CR8 überflüssig ̌ SPR
Diese Möglichkeiten sind im Laufe des
Projekts aufgefallen und sollte
umgesetzt werden ̌ SPR
10.09.2009 Seite 76 von 80

Diplombericht
Master Thesis MAS-07-01.21
11 Anhang
11.1 Glossar
Begriff
Aktor
CDC
CPU
CS
Cset
DB
DBA
Destination
DWH
E1
EFM
ERP
ETL
Beschreibung
Ein Aktor ist ein Benutzer oder ein System welches mit der
Applikation interagiert.
Change Data Capture - Technologie von Oracle zum Übertragen der
Änderungen einer Datenbank
zentrale Verarbeitungseinheit eine Computers (Prozessor)
Change Source
Change Set
Datenbank
Datenbankadministrator
Ziel - in diesem Projekt meist der Staging bereich des DWH
Datawarehouse. Zentrale Datensammlung (Datenbank), deren Inhalt
sich aus Daten unterschiedlicher Quellen zusammensetzt.
Name des ERP Releases, welcher in der EMMI eingesetzt wird.
Emmi Factory Management
Enterprise Ressource Planning
Bezeichnet den Prozess einer Schnittstelle zu einem DWH.
E. Extraktion (Extract) der relevanten Daten aus verschiedenen Quellen
T. Transformation (Transform) der Daten in das Format der
Zieldatenbank
L. Laden (Load) der Daten in die Zieldatenbank.
GUI
Graphical User Interface, englischer Begriff für Bedienoberfläche.
LDI
Lightweight Datawarehouse Interface
MIS
Management Information System
OLAP
Online Analytical Processing
OLTP
Online Transaction Processing
Oracle
Oracle ist eine Datenbankmanagementsoftware
Owner
Eigentümer eine Tabelle und Benutzer einer Datenbank
Proof of Concept Machbarkeitsstudie
purge
reorganisieren von nicht benötigten Daten
Records Datensatz einer Tabelle
Redo Logs Dort werde alle Änderungen einer DB gespeichert
Review
Begutachtung
RMT
Rechte Maus Taste
Rows
siehe Record
Schema siehe Owner
SCN
System Change Number
Source
Quelle - in diesem Projekt eine ERP System
tnsnames.ora File welches die auf dem Client konfigurierten Datenbanken enthält
10.09.2009 Seite 77 von 80

Tool
Trigger
UML
Use Case
Diplombericht
Master Thesis MAS-07-01.21
Werkzeug
Datenbanktrigger. Bei einer bestimmten Art einer Änderung, wird ein
gespeichertes Programm aufgerufen.
Unified Modeling Language
Anwendungsfall - Verhalten zwischen Aktoren und dem betrachteten
System
User
Benutzer, Anwender eines Systems
Tabelle 11-1: Glossar
11.2 Referenzen
Folgende Dokumente und Webadressen dienten als Informationsquellen.
Projektmanagement
http://de.wikipedia.org/
http://www.stefan-baur.de
http://www.it-checklists.com
Unterlagen BFH CAS Business Engineering, Zühlke Engineering AG
Oracle Data Capture
Oracle Data Warehousing Guide 10g Release 2 (B14223-02)
Oracle Data Warehousing Guide 11g Release 1 (B28313-02)
ETL Architektur
The Data Warehouse Lifecycle Toolkit, Ralph Kimball
Skript Data Warehousing, CAS Information Management und BI, Thomas Glauser
10.09.2009 Seite 78 von 80

Diplombericht
Master Thesis MAS-07-01.21
11.3 Tabellenverzeichnis
Tabelle 2-1: Entscheidungstabelle........................................................................................ 13
Tabelle 3-1: Übersicht Use Cases (Publish) ......................................................................... 20
Tabelle 3-2: Aktoren ............................................................................................................. 20
Tabelle 3-3: SQL Programm starten..................................................................................... 22
Tabelle 3-4: SQL Change Source......................................................................................... 25
Tabelle 3-5: SQL Change Source löschen............................................................................ 27
Tabelle 3-6: SQL Change Set konfigurieren ......................................................................... 29
Tabelle 3-7: SQL Change Set löschen ................................................................................. 31
Tabelle 3-8: SQL Changetabelle ändern .............................................................................. 33
Tabelle 3-9: SQL Change Tabelle konfigurieren................................................................... 34
Tabelle 3-10: SQL Source Tabelle konfigurieren .................................................................. 37
Tabelle 3-11: SQL Source Tabelle löschen .......................................................................... 39
Tabelle 3-12: Übersicht Use Cases (Subscribe) ................................................................... 40
Tabelle 3-13: Übersicht Menu Bar ........................................................................................ 41
Tabelle 3-14: Übersicht Kontext Menu.................................................................................. 42
Tabelle 4-1: Namenskonventionen Sourcecode ................................................................... 44
Tabelle 5-1: Übersicht Tests................................................................................................. 47
Tabelle 6-1: Inhalte und Resultate der Projektphasen .......................................................... 50
Tabelle 6-2: Zeitmanagement............................................................................................... 51
Tabelle 6-3: Termine ............................................................................................................ 53
Tabelle 7-1: Anforderungskatalog nicht funktionaler Anforderungen..................................... 54
Tabelle 7-2: Übersicht Use Cases (Publish) ......................................................................... 55
Tabelle 7-3: Übersicht Use Cases (Subscribe) ..................................................................... 55
Tabelle 9-1: SQL View erstellen ........................................................................................... 60
Tabelle 9-2: SQL User erstellen ........................................................................................... 60
Tabelle 9-3: SQL Link erstellen ............................................................................................ 61
Tabelle 9-4: Shortcuts .......................................................................................................... 72
Tabelle 10-1: Personen Change Request............................................................................. 73
Tabelle 10-2: Change Requests ........................................................................................... 76
Tabelle 11-1: Glossar ........................................................................................................... 78
11.4 Abbildungsverzeichnis
Abbildung 2-1: ETL Prozess Schema..................................................................................... 7
Abbildung 2-2: Ladeprozess grösserer Tabellen..................................................................... 8
Abbildung 2-3: CPU Kurve Quellsystem ................................................................................. 9
Abbildung 2-4: Prozessablauf Vision .................................................................................... 10
Abbildung 2-5: Prozessablauf Change Data Capture ........................................................... 12
Abbildung 3-1: Architektur Change Data Capture................................................................. 15
Abbildung 3-2: Übersicht Modus CDC .................................................................................. 17
Abbildung 3-3: Package Diagramm LDI................................................................................ 18
Abbildung 3-4: Use Case Diagramm Publish........................................................................ 19
Abbildung 3-5: Aktivitätsdiagramm Programm starten .......................................................... 21
Abbildung 3-6: Aktivitätsdiagramm Login.............................................................................. 22
Abbildung 3-7: GUI Login ..................................................................................................... 23
Abbildung 3-8: Aktivitätsdiagramm Change Source konfigurieren ........................................ 24
Abbildung 3-9: GUI Change Source ..................................................................................... 25
Abbildung 3-10: Aktivitätsdiagramm Change Source löschen............................................... 26
Abbildung 3-11: Aktivitätsdiagramm Change Set konfigurieren ............................................ 28
Abbildung 3-12: GUI Change Set konfigurieren.................................................................... 29
10.09.2009 Seite 79 von 80

Diplombericht
Master Thesis MAS-07-01.21
Abbildung 3-13: Aktivitätsdiagramm Change Set löschen..................................................... 30
Abbildung 3-14: GUI Change Set löschen ............................................................................ 31
Abbildung 3-15: Aktivitätsdiagramm Changetabelle ändern.................................................. 32
Abbildung 3-16: GUI Changetabelle ändern ......................................................................... 33
Abbildung 3-17: Aktivitätsdiagramm Changetabelle purgen.................................................. 34
Abbildung 3-18: Aktivitätsdiagramm Changetabelle erstellen ............................................... 35
Abbildung 3-19: GUI Changetabelle erstellen (Source) ........................................................ 36
Abbildung 3-20: GUI Changetabelle erstellen Destination .................................................... 37
Abbildung 3-21: Aktivitätsdiagramm Change Tabelle löschen .............................................. 38
Abbildung 3-22: GUI Source Tabelle löschen ....................................................................... 39
Abbildung 3-23: Use Case Diagramm (Subscribe) ............................................................... 40
Abbildung 3-24: Menu Bar.................................................................................................... 41
Abbildung 3-25: Übersicht Toolbar ....................................................................................... 42
Abbildung 3-26: Übersicht Statusbar .................................................................................... 42
Abbildung 4-1: Software Layer ............................................................................................. 43
Abbildung 4-2: DB Model DWH ............................................................................................ 45
Abbildung 4-3: DB Model Source Datenbank ....................................................................... 46
Abbildung 6-1: Vorgehensmodell.......................................................................................... 50
Abbildung 6-2: Projektplan ................................................................................................... 52
Abbildung 9-1: Setup Startfenster......................................................................................... 61
Abbildung 9-2: Setup Installationsordner .............................................................................. 62
Abbildung 9-3:Setup Bestätigung Installation ....................................................................... 62
Abbildung 9-4:Setup Ausführung Installation ........................................................................ 63
Abbildung 9-5: Setup Installation erfolgreich......................................................................... 63
Abbildung 9-6: Loginmaske .................................................................................................. 64
Abbildung 9-7: Benutzeroberfläche ...................................................................................... 65
Abbildung 9-8: TreeView ...................................................................................................... 66
Abbildung 9-9: Register des Bearbeitungsteils ..................................................................... 67
Abbildung 9-10: Changesource bearbeiten........................................................................... 67
Abbildung 9-11: Changesets bearbeiten............................................................................... 68
Abbildung 9-12: Changetabelle Source bearbeiten............................................................... 69
Abbildung 9-13: Changetabelle Destination bearbeiten ........................................................ 70
Abbildung 9-14: Fehleranzeige............................................................................................. 72
10.09.2009 Seite 80 von 80