Home

Re-Engineering betrieblicher Nutzdaten

1. Benutzer externe System schnitt f i stelle schnitt stelle Verarbeitung Daten gt Gateway in Be SER Datenverwaltung 4 Datenverwaltung ren ch ee ee ys oe ee EA j ap A en gt A ep tre ee hath Oa E ee cme costa eat ae N Pees Daten bernahme 5 i Daten Vv L J Fig 4 5 R ckw rts Datengateway Auch f r Verarbeitungs und Schnittstellengateways lassen sich analoge Betrachtun gen anstellen Grunds tzlich wird bei einem inkrementellen Vorgehen in gr sseren Verh ltnissen die Abl sung nicht nur auf Stufe der einzelnen Komponenten erfolgen k nnen Vielmehr wird auch innerhalb der einzelnen Komponenten eine Aufteilung erfolgen m ssen Eine Abl sung erfolgt somit auf der Ebene einzelner Anwendungen wobei die zugeh rigen Datenbest nde einzeln bernommen werden In diesen F llen VOORGEHENSMODELLE 89 ist unter Umst nden ber l ngere Zeit mit einer Koexistenz des Ausgangs und Zielsystems zu leben Eine vertiefte Behandlung der Daten bernahmeproblematik im Zusammenhang mit Abl sungen durch Anwendungen die als Weiterentwicklung bestehender Anwen dungssysteme entstanden sind ist in Oertly 91 zu finden In diesen Situationen also in Anwendungen die im Rahmen von evolution rer Weiterentwicklung bzw inkre menteller Vervollst ndigung entstanden sind Janes 93 handelt es sich um homoge ne Ueberg nge also um Probleme der Klasse P T
2. Fig 5 3 Kombination von SD TP und TD Programmen Durch Kombination von SD TD TP Programmen lassen sich eine ganze Reihe von Import Vorg ngen definieren und durchf hren Da die Sprache TD eine Teilmenge von SQL umfasst ist eine Weiterverarbeitung der Daten in beliebigen relationalen Systemen m glich WERKZEUGUNTERSTUTZUNG 109 5 6 DART KERNSYSTEM 5 6 1 Aufgabe Das DART Kernsystem ist verantwortlich f r die zentrale Verwaltung der Daten Nutz und Meta Daten sowie f r die Verwaltung und den Aufruf der einzelnen Dienste Die zu verwaltenden Daten stammen dabei aus folgenden drei Quellen e Import Dienste e Benutzer via interaktive Eingabe e Analyse Konversions Korrektur Hilfs Dienste Das Kernsystem muss M glichkeiten anbieten um neue Dienste deren Funktionalit t dem Kernsystem unbekannt ist zu registrieren und diese mit den n tigen Parametern aufrufen zu k nnen Das Kernsystem muss ebenfalls die M glichkeit bieten die vor handenen Daten und Meta Daten geeignet zu pr sentieren z B in Form von Berich ten Zudem muss auch eine interaktive Nachdokumentation m glich sein 5 6 2 Realisierungskonzept F r die L sung der genannten Aufgaben wurde das Kernsystem in drei Schichten aufgeteilt Datenverwaltung Nutz und Meta Daten Repositorium und Steuerung Datenverwaltung Die Datenverwaltung muss die Persistenz der bearbeiteten Daten sicherstellen Dies ist eine klassische Aufgabe eines Date
3. read write Ausgangssystem in rascher Folge ge n dert aktualisiert Ag statisch read only Die zu bernehmenden Daten werden haupts chlich gelesen Aenderungen sind selten Expansion E Der zu bernehmende Datenbestand w chst rasch Der zu bernehmende Datenbestand w chst langsam Fig 3 11 Klassifikationskriterien f r Daten bernahmen Aufgrund dieser orthogonalen Kriterien l sst sich ein konkret zu beurteilendes Ueber nahmeproblem einer Problemklasse P zuschreiben die formal als 6 Tupel beschrieben werden kann P T Uv Ua Z A E wobei gilt dass T e Ty Ty Z Zzr Zn Uv e Uvi Uvi Ace Ag As Ua e Ua Uaa E e Eg Ex Anhand der genannten Kriterien lassen sich die wohl schwierigsten Probleme wie folgt umschreiben Es sind Daten bernahmen bei denen sich das Zielsystem stark vom Ausgangssystem unterscheidet ein unterbruchsfreier Uebergang zu gew hrlei sten ist der Datenbestand rasch w chst und h ufig ge ndert wird und die Daten nur als Ganzes bernommen werden k nnen Solche Probleme lassen sich mit obiger Notation also folgendermassen darstellen P Tv Uvi Uak Zn Aa Eg DATEN RE ENGINEERING 75 Die Zuordnung eines konkreten Problems zu einer Problemklasse dient einer ersten groben Beurteilung des weiteren Vorgehens Die Kriterien anhand derer die Zutei lung zu einer Problemklasse erfolgt wurden so gew hlt dass die entscheidenden Merkmale in der Regel rasch
4. Benutzer schnittstelle Daten physisch Fig 2 6 Standard Architektur eines Anwendungssystems Die einzelnen Komponenten sind dabei tiber interne Schnittstellen miteinander ver bunden Anwendungssysteme mit dieser Architektur werden im folgenden als zerlegbar bezeichnet Sofern die einzelnen Komponenten nicht sauber abgegrenzt werden k nnen was in der Praxis leider h ufig der Fall ist so werden in Anlehnung an Brodie Stonebraker 95 die Begriffe teilweise zerlegbares bzw monoli thisches Anwendungssystem verwendet Zerlegbares Anwendungssystem Anwendungssystem das eine Zerlegung in die Komponenten Benutzerschnittstelle externe Systemschnittstelle Verarbei tung und Datenverwaltung entlang klarer Schnittstellen erlaubt Teilweise zerlegbares Anwendungssystem Anwendungssystem bei dem meh rere Komponenten eng miteinander verflochten sind das aber mindestens ei ne Schnittstelle aufweist entlang derer es funktional zerlegt werden kann Monolithisches Anwendungssystem Anwendungssystem das keine erkenn bare Struktur aufweist die eine Zerlegung erlaubt 30 GRUNDLAGEN UND BEGRIFFE Es ist offensichtlich dass zerlegbare Anwendungssysteme f r eine Uebernahme er hebliche Vorteile bieten fo of externe System schnittstelle Ta Benutzer schnittstelle Benutzerschnittstelle externe Systemschnittstelle Verarbeitung Verarbeitung Daten
5. Benutzer i System schnittstelle j schnittstelle v v Verarbeitung v Datenverwaltung Daten physisch Fig 2 8 Datenzugriffsebenen Zugriff via Betriebsystem Auf dieser Ebene erfolgt der Zugriff direkt mit Hilfsmitteln des entsprechenden Betriebssystems Man erh lt die Daten in der Form in der sie physisch abgelegt sind Diese Art des Zugriffs ist dann zu w hlen wenn die Daten einfach strukturiert sind beispielsweise formatierte Textdaten und wenn gen gend Angaben ber die Art der physischen Speicherung zug nglich sind Diese physischen Angaben sind in der Praxis oft zug nglich bilden sie doch regelm ssig Bestandteil der entsprechenden Betriebssystemdokumentation Der Vorteil dieser Zugriffsart ist dass man rasch an alle Daten herankommt nachteilig ist der Umstand zu werten dass die interessierenden Nutzdaten oft vorg ngig von betriebssystemspezifischen Hilfsda ten getrennt werden m ssen beispielsweise Headerdaten bei einem Band Block trenndaten bei einer direkten Speicherungsform Auf dieser Ebene weisen die Nutzdaten oft wenig erkennbare Struktur auf so dass diese Zugriffsart durchaus er hebliche Reverse Engineering Aufwendungen verursachen kann z B wenn unvoll 32 GRUNDLAGEN UND BEGRIFFE st ndige Informationen ber die Datentypen und deren Speicherungformen vorlie gen In schwierigen F llen ist diese Art des Zugriffs allerdings oft die
6. Entwurf und Realisierung dieses Dienstes konnte allerdings nur anhand der Testda ten gezeigt werden dass die ETHICS Daten ohne Informationsverlust auf UNIMARC abbildbar sind Mangels eines geeigneten realen Zielsystems das die Daten in UNIMARC Format einzulesen im Stand war konnte dieser Dienst allerdings nur sehr grob getestet werden Eine ausf hrliche Beschreibung dieses Export Dienstes ist in Mohn Nanduri 95 zu finden 6 3 4 Projektstand Uebernahmedauer Die explorative Durchf hrung wurde abgeschlossen allerdings nur mit Testdaten Die im Rahmen von Studentenarbeiten implementierten Import und Export Dienste sind als Prototypen vorhanden und wurden eingesetzt Eine reale Uebernahme des vollen Datenbestandes wurde aus folgenden Gr nden nicht durchgef hrt e F r eine reale Uebernahme m ssen eine Reihe von Fragen hinsichtlich des Zielsystems abschliessend gekl rt sein insbesondere das Austauschformat Dies war zur Zeit der Durchf hrung dieser Fallstudie noch nicht der Fall e F r eine reale Uebernahme muss der Ausgangsdatenbestand sinnvoll abge grenzt werden Insbesondere muss Einigkeit ber Art und Umfang der zu bertragenden Daten zwischen den verschiedenen Datenlieferanten und dem Datenempf nger herrschen Im Rahmen des eingangs erw hnten Projektauf trages an die Landesbibliothek mussten solche Fragen erst genauer untersucht werden e F r eine reale Durchf hrung m ssen geeignete technische Mittel bereitstehen
7. bzw Datenbank An wendungskomplex wie sie in Janes 93 bzw Oertly 91 verwendet werden die jedoch f r die Datenverwaltung nur Datenbankverwaltungssysteme zulassen GRUNDLAGEN UND BEGRIFFE 23 2 5 NUTZUNGSDAUER EINZELNER KOMPONENTEN Betrachtet man die Komponenten eines gr sseren betrieblichen Anwendungssystems unter dem Gesichtspunkt ihrer Nutzungsdauer so stellt man fest dass die Ger te in der Regel heute die k rzeste Nutzungsdauer einige wenige Jahre haben Ganz anders pr sentiert sich die Situation f r die Programme Hier ist zu unterschei den zwischen Systemprogrammen Betriebssysteme Datenbankverwaltungssysteme Kommunikationssysteme u a sowie Standardanwendungsprogrammen auf der einen und individuell entwickelten Anwendungsprogrammen auf der anderen Seite Auch System und Standardanwendungsprogramme weisen heute Einsatzdauern von oft nur noch wenigen Jahren auf Im Bereich der individuell produzierten Anwendungspro gramme sind jedoch nicht selten Nutzungsdauern im Bereich von zehn bis zu zwanzig und mehr Jahren festzustellen Zehnder 91 Dies hat im wesentlichen zwei Gr nde Erstens m ssen die in die Entwicklung der individuellen Anwendungsprogramme gesteckten grossen Investitionen die sich nur auf eine kleine Zahl von Installationen verteilen so lange als m glich gesch tzt werden wobei dann nicht selten der geeigne te Abl sungszeitpunkt verpasst wird Zweitens bilden solche oft sehr grossen An wendun
8. im Zusammenhang mit einer Reihe von T tigkeiten Datenaufbereitung Daten bernahme Datenkorrektur ver wendet wird die angesprochenen Begriffe jedoch noch keineswegs mit einer allseits akzeptierten Bedeutung versehen sind was sich auch dadurch zeigt dass sie noch nicht Eingang in entsprechende Standardw rterb cher wie IEEE 91 oder Schnei der 91 gefunden haben wird zuerst eine saubere Begriffsbildung vorgenommen Bis heute hat sich f r diese Re Begriffe noch keine einheitliche Schreibweise durchgesetzt In dieser Arbeit wird konsequent die Vorsilbe Re abgetrennt Deutsche Uebersetzungen dieser Begriffe existieren nicht oder haben sich noch nicht durch setzen k nnen Ausnahmen Wiederverwendung und Restrukturierung Im folgenden werden deshalb in der Regel die englischen Begriffe verwendet 2 2 REVERSE ENGINEERING RE ENGINEERING Mit den Begriffen Reverse bzw Re Engineering wurden urspr nglich Techniken f r die Analyse von Ger ten nicht nur Computern und die Optimierung von Produkti onsverfahren umschrieben wobei es bei Reverse Engineering im wesentlichen darum geht von einem bestehenden Produkt Entwurfsspezifikationen f r Zwecke des Nach bauens abzuleiten Rekoff 85 Im folgenden ist nur die Bedeutung der entsprechen den Begriffe im Zusammenhang mit Anwendungen im Informatikbereich von Interes se In diesem Zusammenhang tauchten die beiden Begriffe erst ab Mitte der achtziger Jahre in der Literatur auf D
9. Aktualit t Vollst ndigkeit Konsistenz Genauigkeit timeliness completeness consistency accuracy Fig 3 8 Einstufig hierachische Gliederung des Begriffes Datenqualit t Die erw hnten Untersuchungen zeigen allerdings dass es f r einzelne der erw hnten Merkmale ausserordentlich schwierig ist sofern man einmal von v llig unrealisti schen Annahmen ber den betrachteten Datenbestand absieht einfach mess und verbesserbare Kriterien zu finden und dass eine Betrachtung nur einzelner Merkmale zur Beschreibung von Datenqualit t nicht gen gt Ein pr ziserer Versuch ist in Wang et al 93 zu finden Im Rahmen dieser umfang reichen Studie wird im wesentlichen versucht die offensichtlichen Schw chen des einstufig hierarchischen Ansatzes dadurch zu berwinden dass eine gr ssere Anzahl von Merkmalen untersucht wurde wobei diese Merkmale ber mehrere Stufen auf gegliedert werden Dieser Ansatz l sst sich deshalb als mehrstufig hierarchische Gliederung charakterisieren Datenqualit t Ebene 1 Zuganglichkeit Interpretierbarkeit Glaubw rdigkeit N tzlichkeit accessibility interpretability believability usefulness Ebene 2 Verf gbarkeit Semantik Vollst ndigkeit Aktualit t Konsistenz Bedeutung availability Syntax completeness timeliness consistency relevancy Glaubw rdigkeit Korrektheit der Quelle Genauigkeit credibility accuracy Fig 3 9 Mehrstufig hierachische Gl
10. Aufgrund der Gr sse des Datenbestandes war an ein Arbeiten mit dem gesam ten Datenbestand auf den f r diese Fallstudie verf gbaren Systemen nicht zu denken Die Untersuchungen erstreckten sich ber eine Zeitspanne von rund einem Jahr 6 3 5 Beurteilung Vorgehen Aufgrund der mangelhaften Kenntnisse des Anwendungsbereiches sowie der nur l ckenhaft vorhandenen Informationen mussten in der Vorphase wesentliche Res sourcen in die Beschaffung und Aufbereitung der ben tigten Informationen eingesetzt werden Die Rekonstruktion eines konzeptionellen Schemas hat sich zur Erarbeitung von Kenntnissen als recht hilfreich erwiesen f r die Beurteilung der Daten bernah meprobleme gen gten dann aber Kenntnisse eines Ausschnittes davon Eine Ein schr nkung auf das minimal N tige erwies sich insbesondere zu Beginn des Projek tes als recht schwierig Im wesentlichen wurden f r die Daten bernahme nur Infor mationen auf logischer Ebene gebraucht FALLSTUDIEN 135 Werkzeugunterst tzung Die im Rahmen der vorliegenden Untersuchung zu Experimentierzwecken entwickel ten Werkzeuge haben sich f r die Untersuchungen im Zusammenhang mit der explo rativen Durchf hrung grunds tzlich als geeignet erwiesen F r eine Uebernahme der realen Daten sind sie aber nicht leistungsf hig genug F r ADABAS Datenbanksysteme sind heute relationale Schnittstellen verf gbar Durch Einsatz eines solchen Werkzeuges k nnte die Aufbereitung f r das Z
11. DB MAIN 116 INHALTSVERZEICHNIS 7 6 FALLSTUDIEN 118 6 1 Vorbemerkungen 118 6 2 Fallstudie A Parlament 118 6 2 1 Ausgangslage Problemstellung 118 6 2 2 Beurteilung der Aufgabe 121 6 2 3 Vorgehen 123 6 2 4 Projektstand Uebernahmedauer 127 6 2 5 Beurteilung 128 6 3 Fallstudie B ETHICS 128 6 3 1 Ausgangslage Problemstellung 128 6 3 2 Beurteilung der Aufgabe 130 6 3 3 Vorgehen 132 6 3 4 Projektstand Uebernahmedauer 134 6 3 5 Beurteilung 134 6 4 Fallstudie C Bilanzdaten 135 6 4 1 Ausgangslage Problemstellung 135 6 4 2 Beurteilung der Aufgabe 137 6 4 3 Vorgehen 139 6 4 4 Projektstand Uebernahmedauer 140 6 4 5 Beurteilung 140 6 5 Zusammenfassende Beurteilung 141 7 BEURTEILUNG UND AUSBLICK 142 7 1 Beurteilung 142 7 2 Offene Fragen Ausblick 143 LITERATURVERZEICHNIS 145 ABBILDUNGSVERZEICHNIS Fig Fig Fig Fig Fig Fig Fig Fig Fig Fig Fig Fig Fig Fig Fig Fig Fig Fig Fig Fig Fig Fig Fig Fig 2 1 22 DS 2 4 2 3 2 6 IT 2 8 2 9 Zusammenhang der Re Begriffe Komponenten eines betrieblichen Anwendungssystems Nutzungsdauer einzelner Komponenten eines Anwendungssystems Varianten der Komponentenabl sung Daten bernahme bzw Datenmehrfachnutzung Standard Architektur eines Anwendungssystems Teilweise zerlegbares bzw monolithisches Anwendungssystem Datenzugriffsebenen Klassifikation von Daten 2 10 Daten Lebenszyklusmodell 2 11 Datengetrie
12. Gesehenes sofort zu fr heren Erfahrungen in Beziehung setzen zu k nnen Insbesondere wenn gewisse Kenntnisse ber den Anwendungsbe reich vorhanden sind k nnen so unter Umst nden sehr schnell Hypothesen gebildet werden DATEN RE ENGINEERING 53 Es ist deshalb bei jeder Datenanalyse n tzlich Werkzeuge zur Verf gung zu haben die dieses Anschauen von Daten unterst tzen Dabei ist es insbesondere sehr hilf reich wenn verschiedene Sichten auf die Daten m glich sind die rasch miteinander verglichen werden k nnen beispielsweise das Umschalten auf verschiedene Zeichen s tze siehe auch Abschnitt 3 4 2 Im Rahmen eines konkreten Problemes waren aufgrund unvollst ndiger und teilweise falscher Dokumentationen Angaben ber folgende Daten zu finden Position 1 2 3 4 5 6 1234567890123456789012345678901234567890123456789012345678901 TRANSFER19920630CD2000000000473Art Garfunkel Breakaway ZHMGA 19921015CD4006758451794California Man ZHFU 19920707CD9003549331506Hans Liner Band Liebe oder Wa RITHZ 19920707CD0035627500725Laurent Voulzy The collection LUPM 19920708CD8012861103228Gloria Gaynor Love affair BEFAB 19920727CD4009880952054La Camilla Everytime you lie ZHMGA 19920806CD4006759731734Big Daddy Cutting their own g CRGC 19920911CD2000000105062New Africa Mandingo Fela Ani ZHMGA 19920806CD0075678239724Lemonheads It s a shame about GEKSA 19920909CD5400211001165La Da
13. Phase 5 Aufbereitung f r das Zielsystem Zweck Anpassen der im Zwischensystem aufbereiteten Daten an die Erfordernisse des Zielsystems Voraussetzungen Aufbereiteter und komplett dokumentierter Datenbestand im Zwischensystem Pr zise Kenntnisse ber das Zielsystem Ziel Resultate Die Daten in einer Form bereitstellen dass sie ohne gr ssere Anpassungsarbeiten ins Zielsystem gebracht und dort verwendet werden k nnen Diese Phase ist nur dann zu durchlaufen wenn das entsprechende Zielsystem Anfor derungen an den Aufbau der Daten stellt die nicht bereits im Zwischensystem erf llt 98 VORGEHENSMODELLE werden konnten Wird beispielsweise zur Realisierung der Datenverwaltungskompo nente des Zielsystems ein relationales Datenbankverwaltungssystem eingesetzt und basiert das Zwischensystem auch auf der relationalen Technologie so sind bei einer vern nftigen Aufbereitung in dieser Phase h chstens noch kleinere Anpassungen n tig beispielsweise Zeichensatzumstellungen Es k nnen aber durchaus zwischen dem Ziel und dem Zwischensystem noch umfangreichere Technologieanpassungen n tig sein ein Beispiel daf r ist in Fallstudie A Kapitel 6 zu finden In dieser Phase erfolgt auch das Bereitstellen sauberer Datenbeschreibungen die als Dokumenta tionsgrundlage f r k nftige Erweiterungen des Zielsystems dienen werden Ist ein vollst ndiger Durchgang der Phasen 1 5 erfolgt d h die explorative Durch f hrung abgeschlossen so k
14. StudNr Integer Name ARRAY 1 20 OF CHAR Strasse ARRAY 1 20 OF CHAR PLZ ARRAY 1 4 OF CHAR Ort ARRAY 1 30 OF CHAR FakNr INTEGER FakBez ARRAY 1 30 OF CHAR ImmDatum ARRAY 1 6 OF CHAR ExmDatum ARRAY 1 6 OF CHAR Code ARRAY 1 5 OF CHAR END Die Angaben zu einem Studierenden umfassen eine eindeutige Nummer den Na men die Adresse die Zugeh rigkeit zu einer Fakult t Immatrikulations bzw Exma trikulationsdatum im Format TTMMJJ und einen Code der zusammengesetzt sei aus dem Geburtsjahr dem Geschlecht und einer Semesternummer 76 DATEN RE ENGINEERING Das neue System das beispielsweise eingekauft wird umfasst einige Neuerungen Zus tzlich sollen bei der Uebernahme auch gerade n tige Aenderungen an den Daten durchgef hrt werden F r Studierende k nnen mehrere Adressen erfasst werden z B die Wohna dresse und die Adresse der Eltern Die Postleitzahl muss bei allen Adressen anhand einer Referenztabelle ge n dert werden Situation Deutschland 1993 Immatrikulations und Exmatrikulationsdatum sollen auch beim Jahrtausend wechsel korrekt bleiben d h Einf hren des Jahrhunderts ist n tig Das zusammengesetzte Codefeld soll in seine Bestandteile aufgespalten wer den Duplikate und Redundanzen sollen soweit m glich und sinnvoll eliminiert werden Diese Anforderungen f hren nun zu einer Reihe von Aufbereitungs und Uebernah mearbeiten Dazu geh ren
15. das Thema Daten Reverse Engineering wird im Kapitel 3 behandelt Im folgenden werden des halb auch statt der Begriffe Datenbankverwaltungssystem und Datenbankentwurf gelegentlich die allgemeineren Begriffe Datenverwaltungssystem und Datenentwurf verwendet Siehe z B die sog Fichenaff re in der Schweiz bei welcher alle Staatsschutzakten trotz ihrer schlechten Qualit t nicht einfach vernichtet sondern einer allf lligen Einsichtnahme der Betroffenen zug nglich gehalten werden In Date 95 wird gesch tzt dass im Bereich der Datenbanktechnik pro Jahr ber 100 000 Seiten an wissenschaftlichen Publikationen ver ffentlicht werden 38 GRUNDLAGEN UND BEGRIFFE Es besteht heute Einigkeit dar ber dass der Datenentwurf auf unterschiedlichen Abstraktionsebenen zu erfolgen hat Die Unterscheidung von folgenden Ebenen hat sich als besonders zweckm ssig erwiesen vgl Fig 2 11 e Konzeptionelle Ebene e Logische Ebene e Physische Ebene Auf jeder der verschiedenen Ebenen erfolgt ein Entwurfsprozess der als Ergebnis ein sogenanntes Schema liefert Schema Beschreibung von Daten auf einer bestimmten A bstraktionsebene Betrachtet man nur den Ausschnitt eines Schemas der fiir eine einzelne Anwendung relevant ist so wird dafiir eine sogenannte externe Ebene auch Benutzer oder An wendungssichten genannt eingef hrt Da im Rahmen dieser Arbeit aber Anwen dungssysteme betrachtet werden wird auf das Konzept dieser Si
16. ABBILDUNGSVERZEICHNIS ZUSAMMENFASSUNG ABSTRACT 1 EINLEITUNG 1 1 Problemstellung Evolution statt Revolution 1 2 Zielsetzungen und Abgrenzung 1 3 Hauptresultate Gliederung der Arbeit 2 GRUNDLAGEN UND BEGRIFFE 2 1 Vorbemerkungen 2 2 Reverse Engineering Re Engineering 2 3 Re Engineering versus Wartung 2 4 Komponenten betrieblicher Anwendungssysteme 2 5 Nutzungsdauer einzelner Komponenten 2 6 Abl sung und Migration einzelner Komponenten 2 7 Mehrfachnutzung von Datenbest nden 2 8 Architektur betrieblicher Anwendungssysteme 2 9 Zugriffsm glichkeiten auf Datenbest nde 2 10 Daten Datenbest nde Datenarten 2 11 Daten Lebenszyklen 2 12 Daten Forward Engineering 10 11 12 12 15 15 18 18 18 20 22 23 24 27 28 30 33 35 37 INHALTSVERZEICHNIS 3 DATEN RE ENGINEERING 3 1 Legacy Systeme 3 2 Problembereiche bei einer Daten bernahme 3 2 1 Unvollst ndige und fehlende Angaben 3 2 2 Ausgangssystemprobleme 3 2 3 Uebergangsprobleme 3 2 4 Analyse Konversion Korrektur 3 3 Analyse 3 3 1 Daten Reverse Engineering 3 3 2 Arten von Analysemethoden 3 3 3 Informationsquellen 3 3 4 Schemarekonstruktion 3 3 5 Konsistenz Verifikation Validation 3 4 Konversion 3 4 1 Strukturelle Anpassungen 3 4 2 Codierungs und Darstellungsprobleme 3 4 3 Datenobjektidentifikation 3 4 4 Konversionskonflikte 3 5 Korrektur 3 5 1 Ursachen von Datenwertproblemen 3 5 2 Redundanz Duplikate unvollst ndige und feh
17. Ausnahme der Bereitsstellung von Testdaten nicht ber hrt e Mehrfachnutzung Es handelt sich bei dem Problem um eine Mehrfachnut zung Auch nach einer erfolgten Daten bernahme bleibt das Ausgangssystem weiterhin unver ndert in Betrieb e Datenaktualit t Die H ufigkeit der Datenaktualisierung ist unkritisch Im we sentlichen kommen im Laufe der Zeit neue Daten hinzu Aenderungen und L schungen sind an Katalogdaten extrem selten e Datenqualit t Eine Korrektur der Daten war nicht vorgesehen e Umfang Es handelt sich bei den Daten der ETH Bibliothek um einen sehr grossen Datenbestand mit betr chtlichen Zuwachsraten Das Problem geh rte somit zur folgenden Problemklasse P Problemtyp Tu Mehrfachnutzung Uebergangsvertr glichkeit Uv inhomogen Uebergangsart Uag diskontinuierlich Zerlegbarkeit 2 zerlegbar Aenderungsgrad As statisch Expansion Eg gross Ausgangssystem Es handelt sich beim Bibliothekssystem ETHICS ETH Library Information and Control System um ein propriet res System das in den 80er Jahren entwickelt wur de Es weist eine Gr sse von ca 1x10 Zeilen Code in 1500 PL I Programmen auf Der Gesamtdatenbestand Nutz Meta und Hilfsdaten weist eine Gr sse von rund 20 GByte auf ETHICS verwaltet die Daten eines Bibliotheksverbundes ETHICS Verbund der insgesamt rund 30 Bibliotheken umfasst Als Datenbankverwaltungssystem benutzt ETHICS ein ADA
18. Bundesrepu blik Deutschland per 1 7 1993 als Folge der Wiedervereinigung nicht lange im voraus geplant werden Diese Umstellung f hrte nicht nur zu Programm nderungen sondern auch zu sehr umfangreichen Anpassungsarbeiten an vorhandenen Datenbest nden Ein bekanntes Beispiel stellt in diesem Zusammenhang die Speicherung von Jahreszahlen bei der Verarbeitung von Kalenderdaten dar Bei einer erstaunlich grossen Zahl von Anwendun gen die heute immer noch im Betrieb stehen wurde auf eine Speicherung des Jahrhunderts verzichtet was m glicherweise nach dem 31 12 1999 zu erheblichen Problemen f hren wird Dieser Sachverhalt ist bei Daten bernahmen zu beachten EINLEITUNG 15 1 2 ZIELSETZUNGEN UND ABGRENZUNG Diese Arbeit befasst sich mit der systematischen Vorgehensweise f r Datenaufberei tung und bernahme Dabei m ssen einerseits Metadaten d h Datenbeschreibun gen andererseits aber auch die zur Erf llung eines Anwendungszweckes unmittelbar ben tigten Daten die sog Nutzdaten untersucht werden Insbesondere soll aber auch R cksicht auf die grosse Vielfalt der Ausgangs und Zielsysteme genommen werden Damit will diese Arbeit einen Beitrag zur L sung der im Abschnitt 1 1 ange schnittenen Probleme leisten F r eine systematische Untersuchung m ssen dabei unter anderem folgende Pro blemstellungen vertieft bearbeitet werden e Wie k nnen Ausgangssysteme Datenbest nde Datenanalyseprobleme Datenaufbereitun
19. Ein automatisches Erkennen solcher Duplikate ist in man chen F llen durchaus m glich entsprechende Verfahren sind bekannt Kukich 92 Ukkonen 85 Wu Manber 92 Yates Gonnet 92 Es ist aber zu beachten dass es ein sehr schwieriges Problem ist bei Duplikaten zu entscheiden welche Daten nun als Original zu behalten und welche zu eliminieren sind Dies muss typischerweise im Rahmen eines Validierungsprozesses erfolgen kann also nicht automatisch durchge f hrt werden Neben dem Erkennen und Eliminieren redundanter Daten was namentlich auch ein sehr schwieriges Problem ist wenn Daten aus mehreren unabh ngigen Datenquellen zusammengef hrt werden sollen kann bei einer Daten bernahme aber auch die Si tuation auftreten dass die Daten des Ausgangssystems f r Zwecke des Zielsystems unvollst ndig oder gar nicht vorhanden sind Dies bedeutet dass im Rahmen der Aufbauphase f r ein Nachfolgesystem innerhalb des Datenlebenszyklus Fig 2 10 nebst der Uebernahme auch eine Erst bzw Nacherfassung oder Fremdbeschaffung zu erfolgen hat Es handelt sich dabei im wesentlichen um manuell durchzuf hrende T tigkeiten die entsprechend teuer und zeitaufwendig sind Oft ist zu entscheiden ob solche Erfassungs und Korrekturarbeiten besser noch im Ausgangssystem zu erfolgen haben sofern die entsprechenden Daten dort berhaupt eingegeben werden k nnen oder ob die Daten w hrend der Uebernahme oder erst im Zielsystem zu erg nzen bzw korrigier
20. FALLSTUDIEN 121 6 2 2 Beurteilung der Aufgabe Die Aufgabe wies folgende Eigenschaften auf die die Probleml sung beeinflussten e Zeitverh ltnisse Die Abkl rung war zeitunkritisch Ein eventueller Ueber nahmeentscheid hing von den Resultaten dieser Abkl rung ab Da das vorge sehene Zielsystem teilweise noch in der Entwicklung war Teile davon waren zwar schon in Betrieb an anderen wurde aber noch gearbeitet war auch f r eine reale Daten bernahme genug Zeit vorhanden Das Volumen der Daten sollte eine Uebernahme in einem Schritt erlauben e Ausgangssystemunabh ngigkeit Das Ausgangssystem musste f r die Unter suchung nicht ber hrt werden e Uebernahme Es handelt sich bei dem Problem um eine Uebernahme Nach der realen Daten bernahme war geplant den Betrieb des Ausgangssystems einzustellen e Datenaktualit t F r die Untersuchung standen die Daten der Jahre 1983 1994 zur Verf gung Geplant war eine Daten bernahme nach Abschluss der Herbstsession 1995 Ab diesem Zeitpunkt sollte das neue System G 2 in Be trieb stehen und die Vorst sse nur noch in dieses System eingegeben werden Die Aktualisierung einmal erfasster Daten wurde h chst selten durchgef hrt im wesentlichen wurden gelegentlich Eingabefehler korrigiert Die Daten bernahme konnte in einem einmaligen Durchgang durchgef hrt werden ohne nachtr gliche Aktualisierungen Korrekturen an den Daten sollten allenfalls im neuen System erfolgen e Datenqua
21. Familie der sogenannten xBase Systeme stammt Delphi bezeichnet eine Entwicklungsumgebung der Firma Borland Im Zen trum von Delphi steht die Programmiersprache Pascal die allerdings um wesentliche Eigenschaften erweitert wurde Beide Sprachen unterst tzen moderne Software Engineering Konzepte beispielsweise Objektorientierung modulare Entwicklung getrennte Uebersetzung F r beide Sprachen stehen eine Reihe von weiteren Werkzeugen zur Anwendungsentwicklung Listengeneratoren Funktionsbibliotheken f r den Zugriff auf relationale Datenbanken u a zur Verf gung Beide Produkte waren neu auf dem Markt und deshalb noch nicht sehr weit verbreitet 17 So dauerte z B das Aendern des Datentyps eines Attributes bei einem Testdatenbestand von 10 000 Datens tzen rund 20 Minuten gegen ber rund 4 Sekunden f r dieselbe Aufgabe auf derselben Plattform bei Einsatz eines Datenverwaltungsystems f r Arbeitsplatzrechner WERKZEUGUNTERSTUTZUNG 103 5 4 DART ARCHITEKTUR Mit DART sollte rasch ein Experimentiersystem entstehen das zum Verst ndnis und zur L sung einzelner Probleme im Rahmen einer Daten bernahme beigezogen wer den kann Ausgehend von der Gliederung des Daten bernahmevorganges in einzelne Problembereiche und basierend auf der Idee einer ausgangs und zielsystemunabh n gigen Datenaufbereitung innerhalb eines Zwischensystems wurde eine Architektur entwickelt die es erlauben sollte die gesteckten Ziele m glichst optimal zu e
22. Linkbibliothek DLL gew hlt Dieses Konzept wird von verschiedenen Betriebssy stemen unterst tzt Dynamische Linkbibliotheken enthalten Programmteile Prozeduren Funktionen die erst zur Laufzeit einer Anwendung dynamisch gebun den werden Wesentliche Teile des verwendeten Betriebssystems selbst sind in Form solcher DLL s implementiert und von einer Vielzahl von Programmiersprachen be nutzbar Dieses Konzept erlaubt eine weitgehend freie Wahl des f r eine konkrete Problemstellung zu verwendenden Entwicklungswerkzeuges Die Grundidee der Kommunikation zwischen dem DART Kernsystem und den ein zelnen Diensten basiert auch auf diesem Konzept Ein Dienst ist durch Aufruf ent sprechender Kernsystem Funktionen zur Laufzeit in der Lage auf die ben tigten Nutz und Meta Daten zuzugreifen WERKZEUGUNTERSTUTZUNG 113 Ein Arbeiten mit einem konkreten Dienst l uft im wesentlichen folgendermassen ab Registrieren des Dienstes in DART Programmname Art der Parameter Dies muss nur einmal gemacht werden Durchf hrung DART Benutzer Auswahl des aufzurufenden Dienstes im Kernsystem aus einer Liste der ver f gbaren Dienste Durchf hrung DART Benutzer Wahl der Daten die dem Dienst zur Verf gung gestellt werden sollen Durch f hrung DART Benutzer Starten des Dienstes Durchf hrung Kernsystem Zugriff via Funktionen des Kernsystems auf die gew hlten Daten und Durch f hren der entsprechenden Verarbeitun
23. R ckw rtsrich tung unterscheiden Betrachtet man nun den Entwicklungsprozess entlang der Zeit achse r ckw rts wobei mindestens um eine Entwicklungsphase zur ckgegangen wird so spricht man von Reverse Engineering Reverse Engineering Methoden und Verfahren zur Wiedergewinnung verlo rener eventuell auch Erstgewinnung nie systematisch vorhandener Be schreibungskomponenten eines Anwendungssystems Dabei stehen folgende Ziele im Vordergrund e Verstehen der einzelnen Systemkomponenten und ihrer Beziehungen unter einander e Erzeugen von Beschreibungen e Identifizieren von Komponenten f r eine sp tere Wiederverwendung Dabei ist zu beachten dass es sich bei Reverse Engineering um reine Analyset tigkei ten handelt die das untersuchte System nicht ver ndern Zur begrifflichen Abgrenzung dieses Zur ckschauens vom vorw rts gerichteten herk mmlichen Entwicklungsprozess wurde f r diesen der Begriff Forward Engineering eingef hrt Die Kombination von Reverse Engineering mit anschlies sendem Forward Engineering wird als Re Engineering bezeichnet Re Engineering Analyse und darauf aufbauend Neukonstruktion von Tei len eines Anwendungssystems Gelegentlich findet man in der Literatur daf r auch die Begriffe Renovation und Reclamation Chikofsky Cross 90 20 GRUNDLAGEN UND BEGRIFFE F r die Transformation der Ergebnisse einer Entwicklungsphase innerhalb derselben Abstraktionsebene wird der Begriff
24. Vorkommen 8403 8399 8398 8399 7629 8387 8397 974 125 8398 8395 398 4131 8394 244 46 7882 5902 1981 1882 79 2168 126 FALLSTUDIEN Die Attribut berpr fung lieferte Resultate der folgenden Art Attribut 101 Gesch ftsnummer Vorkommen 8403 100 Eingabe zwingend Ja Konsistenzbedingung Vorhanden inaktiv Formatpr fung Eingabeformat 1 T0 9 0 97 0 9 0 9 0 9 0 9 2 Ad 0 9 0 9 0 9 0 9 0 9 0 9 0 9 0 9 Vorkommen mit Format 1 7979 2 419 Problemf lle 5 RECORDNR Feld 101 3573 30286 043 5706 90 1050 7835 3083335 9693 NR 10037 x Korrekturen automatisch manuell Bemerkungen Die Numerierung in BASIS weicht von derjenigen in SWISSBASE ab eine weitgehende automatische Korrek tur ist m glich Fig 6 5 Resultate der Attribut berpr fung Beispiel Die vollst ndigen Resultate dieser Untersuchungen sind in Aebi 95 zu finden Basierend auf diesen sehr detaillierten Resultaten wurde provisorisch beschlossen eine Uebernahme in G 2 vorzusehen sobald die entsprechenden Entwicklungsarbei ten des Zielsystems einen gen gend stabilen Zustand erreicht h tten Kurze Zeit sp ter wurde jedoch beschlossen einen v llig anderen Weg zu beschrei ten Aufgrund der nicht unerheblichen Anpassungsarbeiten die f r eine volle Daten bernahme in G 2 zu leisten gewesen w ren und insbesondere aufgrund der sehr knappen personellen Resourcen wurde entschieden die Daten nic
25. Your Data Ready For The Repository Datamation No 1 1990 S 43 47 Chapin 88 Chapin N Software Maintenance Life Cycle Int Conf On Software Main tenance IEEE Computer Society Press 1988 S 6 13 Chatterjee Segev 91 Chatterjee A Segev A Data Manipulation in Heterogeneous Databases SIGMOD Record Vol 20 No 4 1991 S 64 68 Chiang et al 94 Chiang H L et al Reverse Engineering of Relational Databases Extraction of an EER Model from a Relational Database Knowledge amp Data Engi neering Vol 12 Nr 2 1994 S 107 142 Chikofsky et al 93 Chikofsky E et al Challenges to the Field of Reverse Engineering Proc of the Int Working Conf on Reverse Engineering IEEE Computer Society Press 1993 S 144 150 Chikofsky Cross 90 Chikofsky E Cross J Reverse Engineering and Design Recovery A Taxo nomy IEEE Software Vol 23 Nr 1 1990 S 13 17 Clavel 94 Clavel G A Proposal for a Swiss Information Network Working paper submitted to the Steering Committee of the Project Network CH 1994 Codd 90 Codd E F The Relational Model for Database Management Version 2 Addison Wesley 501 Seiten 1990 Cron 95 Cron D Pers nliche Vorst sse 1983 1995 Semesterarbeit ETH Z rich Institut fiir Informationssysteme 1995 Date 95 Date C J An Introduction to Database Systems Addison Wesley 6 Aufla ge 839 Seiten 1995 148 LITERATURVERZEICHNIS Davis A
26. Zielsysteme zu bertragen Diese Strategie bringt eine Reihe von Vorteilen e Unabh ngigkeit Die Daten sind f r die Aufbereitung von implementations spezifischen Eigenheiten der Ausgangs und Zielssysteme befreit e Flexibilit t Besteht zu Beginn des Uebernahmeprozesses noch keine ab schliessende Klarheit ber das Zielsystem k nnen trotzdem wesentliche Auf bereitungsarbeiten bereits vorangetrieben werden Insbesondere bei einem geplanten oder ungeplanten Wechsel des Zielsystems werden so wesentliche Investitionen gesch tzt siehe auch Fallstudie A Kapitel 6 e Mehrfachnutzung Gelingt es Ausgangs und Zielsysteme anhand gewisser Kriterien zusammenzufassen so kann der Aufwand f r die Durchf hrung ei ner Daten bernahme reduziert werden Bei n Ausgangsystemen und m Ziel systemen m ssen dann theoretisch statt nx m nur n m Uebernahmen reali siert werden Die problemspezifischen Aufbereitungsarbeiten k nnen im Zwi schensystem erledigt werden In der Praxis ist dieser rechnerische Vorteil da n und m in der Regel klein sind nicht berw ltigend der Aufwand einer Da ten bernahme jedoch so gross dass sich der Aufwand auch schon bei sehr wenigen unterschiedlichen Ausgangs bzw Zielsystemen lohnen kann Zwischensystem AN Fig 4 6 Reduktion der Uebernahmearbeiten VORGEHENSMODELLE 91 Mit einer geeigneten Wahl des Zwischensyst
27. aber eine Abl sung dauert desto gr sser werden jedoch auch die damit verbundenen Risiken Aus folgenden Gr nden ist deshalb von der Alles auf einmal Strategie in komplizierteren Verh ltnissen abzuraten e Erweiterungen des Zielsystems In vielen F llen ist die Absicht schwer vermit telbar ein in Betrieb stehendes System durch ein funktional gleichwertiges allenfalls intern anders strukturiertes und damit hoffentlich besser wartbares System zu ersetzen Vielmehr wird ein solches teures Vorhaben nur im Zu sammenhang mit dem Versprechen von wesentlichen funktionalen Erweite rungen bewilligt werden was aber die Komplexit t des Zielsystems erh ht und den Abl sungsvorgang erschwert e Ver nderungen der Umwelt Gr ssere Entwicklungsvorhaben dauern lange Es ist deshalb w hrend der Entwicklungszeit sowohl auf ge nderte Anforde rungen R cksicht zu nehmen als auch das Ausgangssystem in dringenden F llen im Rahmen adaptiver Wartungsarbeiten anzupassen Diese Entwick lungen m ssen synchronisiert werden e Gr sse der zu bertragenden Datenbest nde Legacy Systeme weisen oft eine Gr sse auf die eine Uebertragung der Datenbest nde in einem Schritt gar nicht erlauben weil das zu untolerierbar langen Betriebsunterbr chen f hren w rde e F hrung Grosse und komplexe Projekte sind anspruchsvoll durchzuf hren F r die F hrung grosser Abl sungsprojekte bestehen noch sehr wenig Erfah rungen auf denen basiert werden k
28. andererseits falls n tig weiterzuent wickeln und an ge nderte Bed rfnisse anzupassen Eine sich stetig ndernde Umwelt f hrt dazu dass ein Anwendungssystem in der Regel nicht unver ndert ber einen l ngeren Zeitraum betrieben werden kann Die Gr nde die zu solchen Ver nderungen f hren lassen sich grob in zwei Gruppen einteilen e Anwendungssystem inhdrente Gr nde und e Anwendungssystem externe Gr nde Anwendungssystem inh rente Gr nde Hierbei handelt es sich um Gr nde deren Ursachen im Entwurf der Realisierung und dem Betrieb eines Anwendungssystems zu suchen sind Dazu z hlen z B ungen gende Leistungsf higkeit unbefriedigende Benutzerschnittstellen oder mangelhafte Funktionalit t Verf gbarkeit von leistungs f higeren Komponenten usw Anwendungssystem externe Gr nde Ursachen die unabh ngig von einem konkreten Anwendungssystem zu einer Ver nderung f hren wie z B ver nderte Rechtsgrundla gen Aenderung von anderen Anwendungssystemen oder sonstigen Systemen zu denen eine Schnittstelle besteht usw Irgendwann wird f r jede Komponente der Zeitpunkt erreicht wo sie nicht weiter gepflegt oder angepasst werden kann sondern durch eine neue ersetzt werden muss F r eine vern nftige Planung der Lebensdauer einer Komponente und damit des geeigneten Abl sungszeitpunktes spielen vor allem inh rente Gr nde eine Rolle Im Sinne von vorbehaltenen Entschl ssen sollte jedoch immer auch eine vern nftige R
29. auf der neuen Datenverwaltungstechnologie aufsetzen k nnen Die effizi ente Umsetzung der Datenzugriffe der Anwendungskomponente des Ausgangssystems auf eine neue Datenverwaltung stellt beim Uebergang von prozedural realisierten Datenzugriffen wie sie f r Legacy Systeme typisch sind auf deskriptive Zugriffe typisch f r moderne relationale Systeme jedoch ganz erhebliche Anforderungen 88 VORGEHENSMODELLE Etwas einfacher gestaltet sich unter Umst nden die Umsetzung von Datenzugriffen von neuen Anwendungen auf eine bestehende Datenverwaltungskomponente Fig 4 5 Dies vor allem deshalb weil moderne Anwendungen im Hinblick auf eine weit gehende Datenunabh ngigkeit entworfen werden k nnen was den Einbau eines Ga teways stark erleichtert Im Falle eines solchen R ckw rts Gateways k nnen die neuen Anwendungen im Hinblick auf die Verwendung der neuen Datenverwaltungs komponente entwickelt werden Die deskriptiven Zugriffe m ssen innerhalb des Datengateways in prozedurale umgesetzt werden Es erfolgt also zuerst eine Abl sung der Programme gefolgt von der Uebernahme der Daten Zur Umsetzung von Datenzugriffen moderner Anwendungen auf ltere Datenverwal tungssysteme stehen eine Reihe von kommerziellen Gatewayprodukten zur Verf gung So wurde insbesondere dem Problem des Zugriffs auf das hierarchische Daten bankverwaltungssystem IMS aufgrund seiner grossen Verbreitung viel Beachtung geschenkt Paulley 93 Dippold Meier 92
30. cher Schnittstellen werden sogenannte Gateways und Wrapper eingesetzt Gateway Komponente die eine Verbindung zwischen funktional vergleichba ren Komponenten zweier Anwendungssysteme herstellt Abh ngig vom Verwendungszweck lassen sich Datengateways Verarbeitungsgate ways oder Benutzerschnittstellengateways bzw Gateways zwischen externen System schnittstellen unterscheiden Benutzer REN Benutzer extere 3 i System j System schnitt schnitt schnitt schnitt stelle stelle i stelle stelle Verarbeitung Gate Verarbeitung ways Datenverwaltung Datenverwaltung Fig 4 2 Gateways F r die Unterst tzung von Abl sungen spielen Gateways eine besondere Rolle Mit ihrer Hilfe ist es beispielsweise m glich die Datenverwaltungskomponente eines Anwendungssystems zu ersetzen ohne dass dies an der Benutzerschnittstelle des Ausgangssystems sichtbar wird Eines der am schwierigsten zu l senden Probleme bei der Einf hrung von Gateways ist die Aufteilung eines Anwendungssystems in Komponenten und das Finden geeig neter Schnittstellen f r die Plazierung von Gateways Namentlich bei monolithischen 86 VORGEHENSMODELLE Legacy Systemen ist das oft gar nicht m glich In solchen F llen muss unter Umst n den zuerst das Anwendungssystem geeeignet restrukturiert werden Gateways m ssen folgende drei Aufgaben erf llen Brodie S
31. dellexterne Konsistenzbedingungen m ssen mit anderen Mitteln typischerweise Programmiersprachen formuliert und gepr ft werden Statische Konsistenzbedingun gen gelten w hrend der gesamten Lebensdauer der entsprechenden Daten w hrend dynamische Konsistenzbedingungen zul ssige Zustands berg nge Mutationen festlegen Moderne Datenbankverwaltungssysteme bieten heute f r die Formulierung und Ue berpr fung von auch sehr komplexen Konsistenzbedingungen eigene Program miersprachen an Triggers Stored Procedures Damit kann die Konsistenzsiche rung zentral im Datenbankverwaltungssystem durchgefiihrt werden Leider hat aber jeder Hersteller entsprechender Produkte hier seine eigene Begriffswelt und Notation eingef hrt Konsistenzbedingungen die mit diesen Mechanismen formuliert und gepr ft werden sind deshalb auch zu den modellexternen Konsistenzbedingungen zu z hlen Es ist heute unbestritten dass eine m glichst weitgehende Entkoppelung zwischen Anwendungsprogrammen und Konsistenzpr fung anzustreben ist Definition und Pr fung von Konsistenzbedingungen sollten zentral im Datenbankverwaltungssy stem erfolgen Codd 90 Dieses Konzept hat sich in der Praxis allerdings noch nicht auf breiter Basis durchgesetzt Vielmehr wird die Konsistenzsicherung nach wie vor weitgehend durch die Anwendungsprogramme sichergestellt Insbesondere bei Le gacy Systemen gestaltet sich eine Rekonstruktion der Konsistenzbedingungen deshalb
32. der Frage einer k nftigen Abl sung in der Regel zu wenig Bedeutung beigemessen Dazu geh rt auch die Planung von Einsatzdauern Viele Anwendungen bleiben heute aus sehr verschiedenen Gr nden zu lange in Betrieb Angesichts der F lle von technischen und organisatorischen Problemen die im Rah men einer Daten bernahme zu l sen sind darf nicht vergessen werden dass Daten bernahmen eine Reihe von Fragestellungen aufwerfen auf die im Rahmen der vor liegenden Arbeit nicht eingegangen werden konnte Namentlich sind hier auch ko nomische und juristische Probleme zu nennen Oekonomische Probleme Daten bernahmen werden als Projekte durchgef hrt Aufgrund von Erfahrungen die w hrend vielen Jahren im Bereich der Anwendungsentwicklung gesammelt werden konnten ist hinl nglich bekannt dass das Absch tzen von Projektkosten im Bereich der Informatik eine ausgesprochen anspruchsvolle Aufgabe darstellt W hrend im Programmentwicklungsbereich heute eine Reihe von entsprechenden Modellen zur Verf gung stehen gilt dies nicht in gleichem Masse f r Re Engineering Projekte Hier sind erst in j ngster Zeit entsprechende Anstrengungen unternommen worden Noch bestehen recht wenige gesicherte Erkenntnisse die ein vern nftiges Absch tzen der Kosten solcher Projekte erlauben eine fr he Arbeit zu diesem Problembereich bildet beispielsweise Sneed 91 Juristische Probleme Bei der Uebernahme von Daten namentlich bei einer Mehrfach
33. der vorliegenden Arbeit lassen sich in folgende drei Hauptpunkte zu sammenfassen Begriffe Probleme Klassifikationen Im Zusammenhang mit den Schlagworten Re Engineering und Migration hat sich noch keine auf breiter Basis akzeptierte Begriffswelt etabliert Zu Beginn der Arbeit werden deshalb zuerst detailliert die n tigen begrifflichen Grundlagen bereitgestellt In Kapitel 2 liegt das Schwergewicht der Betrachtungen auf Fragestellungen im Zu sammenhang mit Anwendungssystemen ihren Komponenten und ihrer Struktur und den sich daraus ergebenden Problemen bei einer Daten bernahme In Kapitel 3 wer den eine Reihe von Fragestellungen im Zusammenhang mit Nutzdaten diskutiert Ausgehend von bewusst breit angelegten Uebersichten ber einzelne Problembe reiche werden eine Reihe von Klassifikationen erarbeitet Vorgehensmodell f r Daten bernahmen F r die konkrete Abwicklung von Daten bernahmeprojekten bestehen erst wenige methodische Grundlagen Herk mmliche Vorgehensmodelle f r die Anwendungs entwicklung ber cksichtigen die Phasen Betrieb und Abl sung einer Anwendung nur unzureichend Ausgehend von einer Uebersicht ber grunds tzliche Vorgehensm g lichkeiten wird im Rahmen dieser Arbeit ein Vorgehensmodell vorgeschlagen das sich auf das Problem Daten bernahme konzentriert und f r eine Vielzahl von Aus gangssituationen ein strukturiertes Vorgehen zur Abwicklung von Daten bernahme projekten anbietet Bestehende Anwendun
34. dieser Richtung sind beispielsweise in Chapin 88 Falkenberg Kaufmann 93 Kn ll Schwarze 93 Kaufmann 94 Sneed 95 Kl sch Gall 95 und vor allem in Brodie Stonebraker 95 zu finden Bis jetzt hat jedoch keines dieser Modelle breite Akzeptanz gefunden Es handelt sich vorerst noch mehr um eigentliche Fallstudien Allgemeine Prinzipien die sich daraus ableiten lassen m ssen sich in der Praxis erst noch bew hren Trotz dem weitgehenden Fehlen von etablierten Vorgehensmodellen haben sich in der Praxis anhand konkreter Erfahrungen bei Abl sungen verschiedene Strategien her ausgebildet Die Wahl einer solchen Strategie h ngt dabei nat rlich stark vom konkret vorliegenden Problem ab 4 2 2 Die Alles auf einmal Strategie Gelegentlich mag die Versuchung gross sein ein Legacy System in einem einmaligen Kraftakt loszuwerden und durch ein von Grund auf neu entwickeltes oder allenfalls fremdbeschafftes Anwendungssystem zu ersetzen Dieses Vorgehen ist in einfachen berschaubaren Verh ltnissen angebracht insbesondere dann wenn die Abl sung gen gend rasch und ohne den Betrieb nachhaltig zu st ren erfolgen kann Diese Bedingungen sind in der Praxis nur selten gegeben Oft ist die Versuchung gross eine 84 VORGEHENSMODELLE Abl sung dazu zu nutzen auch gleich funktionale Erweiterungen einzuf hren was jedoch die Komplexit t des Zielsystems und damit oft auch die Abl sungszeit deut lich erh ht Je l nger
35. eine Adresse dargestellt als PASCAL Typ TYPE Adresse RECORD PLZ Integer Ort ARRAY 1 8 OF CHAR END von einem 32 Bit little endian Rechner z B einem IBM PC auf einen 32 Bit pig endian Rechner z B einen Mac bertragen werden Dabei seien die kon kreten Werte 8000 PLZ und Z rich Ort zu bertragen Byte Position Byte Position 0 0 4 4 8 8 Uebertragene Byte Folge h c i r 64 DATEN RE ENGINEERING Auf dem Zielrechner wurde aus der Postleitzahl 8000 jedoch durch Vertauschen der Byte Anordnung die Zahl 64 x 2 31 x 2 Ein weiteres Problem bei dieser Umset zung stellt das Zeichen dar das auf dem Ausgangs und Zielsystem nicht gleich codiert wird Bereits bei diesem trivialen Beispiel ergeben sich bei einer Daten bernahme wesentli che Probleme Diese lassen sich durch geeignete Abstraktionen nur zum Teil vermei den Insbesondere das Problem der verschiedenen Zeichencodierungen bleibt beste hen und muss deshalb gesondert gel st werden Die hier angeschnittenen Eigenheiten der physischen Repr sentation sind nicht nur bei Daten bernahmen sondern auch bei einem permanenten oder periodischen Datenaustausch zwischen heterogenen Systemen ein Problem Im Rahmen des OSI Modelles sind sie auf der Ebene 6 Darstellungsschicht zu l sen Im Rahmen von Daten bernahmen h ngt viel davon ab auf welcher Ebene der Zu grif
36. einen eigenen Import Dienst zu entwerfen und zu implementieren Dieser Dienst musste in der Lage sein Wiederholungsgruppen aufzul sen und ADABAS spezifische Datentypen umzuwandeln sowie eine in der Voruntersuchung festgestellte ETHICS spezifische Zusammenfassung von Datens tzen wieder r ck g ngig zu machen Um diesen Dienst m glichst allgemein benutzbar zu machen wurde er in zwei Teilen entworfen und implementiert Mit Hilfe des allgemeines Teils ist eine Umsetzung von beliebigen ADABAS Daten in 1 Normalform m glich Der spezielle Teil konnte nur im Rahmen der vorliegenden Untersuchung eingesetzt wer den Dieser Import Dienst ist in Nigg 95 detailliert beschrieben Aufbereitung im Zwischensystem Im Rahmen der Aufbereitungsphase wurden nur eine einfache Konversion durchge f hrt Zusammenfassen von Attributen um die Entwicklung des Importdienstes f r das Zielsystem zu erleichtern Da nur unvollst ndige Testdaten zur Verf gung stan den musste auf eine gr ndliche Untersuchung der Daten insbesondere im Hinblick auf eine allf llige Korrektur verzichtet werden Aufbereitung f r das Zielsystem Die wichtige Frage ob das gew hlte Zielsystem f r eine Darstellung der ETHICS Daten geeignet war musste in dieser Phase beantwortet werden Es wurde entschie den sie konstruktiv durch Entwicklung eines konkreten Export Dienstes f r die Um setzung der Daten aus dem Zwischensystem in UNIMARC zu beantworten Durch 134 FALLSTUDIEN
37. eines Datenbestandes so dass er in verschiedenen Zielsystemen genutzt werden kann Die urspr ngliche Nutzung bleibt im Ausgangssystem weiterhin gew hrleistet F r eine solche Mehrfachnutzung kommen vor allem Datenbest nde in Frage die ber einen l ngeren Zeitraum konstant bleiben und im wesentlichen nur gelesen werden Beispielsweise eignen sich Adressdaten bereits publizierte Aktien und Devisenkurse oder Katalogdaten einer Bibliothek siehe auch Fallstudie B sehr gut f r eine Mehrfachnutzung Bei Mehrfachnutzungen stellt sich gegen ber Daten bernahmen das zus tzliche Problem wie mit neu dazukommenden Daten umgegangen werden soll Sofern ein mehrfach genutzter Datenbestand in den verschiedenen Zielsystemen nicht nur gele 28 GRUNDLAGEN UND BEGRIFFE sen sondern auch erweitert wird muss unter Umst nden zwischen den verschiedenen Systemen ein Abgleich erfolgen Dabei muss auch entschieden werden wie Mehr facherfassungen zu behandeln sind Auch wenn der Datenbestand nur im urspr ngli chen System erweitert werden darf muss eventuell in regelm ssigen Abst nden ein Nachf hren der neu hinzugekommenen Daten in den entsprechenden Zielsystemen erfolgen Es ist auch die Frage zu kl ren in welchen Zielsystemen Korrekturen er laubt sind um unkontrollierte Redundanz zu vermeiden N Ausgangssystem Zielsystem Zielsystem Ausgangssystem Legacy System Anwendungs 7 Anwendungs Anw
38. einfache zeichenorientierte Benutzerschnittstelle Eine Volltextsuche sowie eine suche ber einen Thesaurus sind m glich Betrieben wurde das System im Auftrag der Parlamentsdienste vom Bundesamt f r Informatik auf einem Rechner mittlerer Gr sse der Firma Digital Equipment VAX Zielsystem Als Zielsystem war urspr nglich entweder GU 1 oder G 2 vorgesehen Beide Syste me basierten auf dem kommerziellen Information Retrieval System BASIS das ber viele Funktionen eines normalen Datenbank verwaltungssystems verf gt dar berhin aus aber auch Funktionen f r Verwaltung und Abfragen von Volltextdaten anbietet Im Verlaufe des Projektes wurde von einer Uebernahme der Vorstossdaten in G 1 oder G 2 abgesehen Details zu diesem Entscheid sind im Abschnitt 6 2 3 zu fin den Als Zielsystem wurde schliesslich das Produkt Multimedia V iewer der Firma Microsoft gew hlt Es handelt sich dabei um ein Entwicklungssystem mit dem das Erstellen multimedialer Abfragesysteme unterst tzt wird Die innerhalb eines solchen Abfragesystems zu verwaltenden Daten m ssen im RTF Format Rich Text Format vorliegen Art und Umfang der Daten Zugriffsebenen Die Daten eines pers nlichen Vorstosses bestehen typischerweise aus formatierten und unformatierten Volltexte Daten Die formatierten Daten dienen im wesentlichen der Identifikation eindeutige Vorstossnummer Urheber Datum Status der Bearbei tung Die unformatierten Daten enth
39. einzige ber haupt m gliche Zugriff via Datenverwaltung Die meisten gebr uchlichen Datenverwaltungs bzw Datenbankverwaltungssysteme bieten M glichkeiten die Daten in einem wohldefi nierten Format auf Sekund rspeicher auszulagern sogenannte Dumps Insbesonde re Systeme die auch Metadaten verwalten was beispielsweise f r alle relationalen Datenbankverwaltungssysteme gilt erlauben auf diese Art einen recht einfachen Zugriff auf die Daten Auf dieser Ebene sind oft Angaben zur physischen Speicherung bereits vorhanden Datentypen Wertebereiche Zeichens tze Da die Art der Da tenspeicherung von der Art der Pr sentation der verarbeiteten Daten wesentlich ab weichen kann z B bei allen Arten von berechneten oder abgeleiteten Daten sind aber auch bei einem Zugriff auf dieser Ebene unter Umst nden noch erhebliche Aufwendungen zur Vervollst ndigung der ben tigten Angaben n tig Zugriff via Verarbeitung Gelegentlich bieten Anwendungsprogramme M glichkeiten auf die Daten in verarbeiteter Form zuzugreifen So sind in Anwendungen gelegent lich Funktionen implementiert die eine Ausgabe statt auf den Bildschirm oder Druk ker in eine Datei umleiten lassen Auf dieser Ebene erfolgt der Zugriff auf bereits aufbereitete Daten H ufig sind diese Mechanismen jedoch nicht daf r ausgelegt s mtliche Daten des entsprechenden Anwendungssystems bereitzustellen Oft k nnen jedoch auf dieser Zugriffsebene Anga
40. geringen Anteils 20 40 je nach Quelle aller Datenbest nde ein Datenbankverwaltungssystem eingesetzt wird K ng 94 L thi et al 92 Hildebrand 92 Brodie 89 Daten Re Engineering hat deshalb vor allem auch bei Nicht Datenbank Anwendungen eine grosse Be deutung e Viele der eingangs erw hnten betrieblichen Anwendungen weisen nicht selten eine Lebensdauer von zehn und mehr Jahren auf Das heisst aber auch dass sie mit einer heute weitgehend berholten Technologie entwickelt und vermutlich im Laufe der Jahre mehrmals ge ndert wurden Sie sind h ufig gar nicht unvoll st ndig oder falsch dokumentiert Dies gilt nicht nur f r die Programme sondern auch f r die Daten Solche Dokumentationsm ngel k nnen eine Daten bernahme erheblich erschweren e Im Gegensatz zu diesen langlebigen Anwendungen beobachtet man im Arbeits platzrechnerbereich eine gegenteilige Entwicklung Die auf diesen Systemen ein gesetzten Anwendungsprogramme werden aufgrund der rasanten Entwicklung der Ger te und Systemprogramme immer rascher durch Folgeprodukte ersetzt Damit verbunden ist auch eine h ufige Anpassung der Datenbest nde e Die Anforderungen an eine Anwendung bleiben ber die Betriebszeit nicht stabil vielmehr m ssen regelm ssig Anpassungen und Erweiterungen vorgenommen werden F r die Daten kann das bedeuten dass sich die urspr nglich beim Ent wurf einer Anwendung festgelegten Konsistenzbedingungen ver ndern oder dass zus tzli
41. herige Phase nochmals zu durchlaufen Dann folgt eine detaillierte Beschreibung Phase I Abgrenzung Zweck M glichst pr zise Umschreibung des zu l senden Daten bernah meproblems Abgrenzung der zu bernehmenden Daten Grobe Planung der Ressourcen Voraussetzungen Konkretes Daten bernahmeproblem Klarheit ber die Problem ursachen Ziel Resultate Problemumschreibung Grober Zeit und Vorgehensplan Insbesondere bei gr sseren Daten bernahmeproblemen muss in dieser Phase eine sinnvolle Gliederung in Teildatenbest nde vorgenommen werden die allenfalls ein zeln bernommen werden k nnen Diese Phase soll auch Uebersicht ber bereitzustel lende personelle und materielle Ressourcen sowie ber die Zeitverh ltnisse liefern Es ist zu beachten dass im Gegensatz zu Entwicklungsprojekten bei Daten bernahmen nur komplette Datenbest nde bzw zusammengeh rige Teildatenbest nde in die Be trachtungen mit einbezogen werden d rfen Ans tze zur Aufgabenverkleinerung durch Verzicht auf Teildatenbest nde wie sie bei Entwicklungsprojekten unter dem Stichwort 80 20 Regel zur Reduktion des Problemumfanges angestellt werden sind im Zusammenhang mit Daten bernahmen usserst gef hrlich Eine allf llige Redukti on des Datenumfanges sollte erst in einer sp teren Phase erfolgen 96 VORGEHENSMODELLE Wichtig ist in dieser Phase auch dass Klarheit besteht warum eine Daten bernahme berhaupt durchgef hrt werden soll Problema
42. hrung die Phasen 3 bis 5 hingegen in der Regel bei beiden Durchf hrungen durchlaufen 94 VORGEHENSMODELLE 1 Abgrenzung 2 Voranalyse 3 Aufbereitung f r das Zwischensystem 4 Aufbereitung im Zwischensystem _ Durchf hrungs entscheid Analyse Konversion Korrektur 5 Aufbereitung f r das Zielsystem 3 Aufbereitung f r das Zwischensystem 4 Aufbereitung im Zwischensystem Analyse Konversion Korrektur 5 Aufbereitung f r das Zielsystem Fig 4 9 Phasenfolgedarstellung des MIKADO Modells __ Uebergabe der Daten ans Zielsystem VORGEHENSMODELLE 95 Basierend auf einer griindlichen Beurteilung der in den einzelnen Phasen erhaltenen Ergebnissen wird entweder die n chste Phase in Angriff genommen oder die vorher gehende Phase muss nochmals wiederholt werden 4 3 2 Die Phasen von MIKADO In den einzelnen Phasenbeschreibungen wird jede Phase einleitend gem ss folgendem Schema kurz charakterisiert Zweck Was ist die grunds tzliche Aufgabe die in dieser Phase gel st werden soll Voraussetzungen Was muss an Voraussetzungen gegeben sein damit die Phase begonnen werden kann Ziel Resultate Welche konkreten Ergebnisse m ssen vorliegen damit die Phase abgeschlossen und damit die n chste Phase in Angriff genom men werden kann Sind diese Resultate nicht erzielbar darf die Phase nicht abgeschlossen werden unter Umst nden ist die vor
43. in der Lage ihre Katalogdaten direkt in ein solches Austauschformat zu bertragen bzw ein solches Format zu lesen Dies gilt jedoch nicht f r alle Bibliothekssysteme Insbesondere verwendet die ETH Bibliothek ein eigenes Format zur Darstellung ihrer Daten und ist nicht in der Lage ein solches Standardformat zu schreiben oder zu lesen Als Zielsystem wurde f r die vorliegende Untersuchung ein Format gew hlt das international sehr weit verbreitet und entsprechend m chtig ist UNIMARC Art und Umfang der Daten Zugriffsebenen Der Datenbestand eines gr sseren Bibliothekssystems weist eine recht komplexe Struktur auf Online Abfrage Bestellung Periodika Kontrolle und Beschaffung sind typische Aufgaben eines solchen Systems Nebst einer Reihe von Grundaufgaben die bei verschiedenen Systemen weitgehend vergleichbar sind bestehen bei Details der Datendarstellung zwischen verschiedenen Bibliothekssystemen zum Teil gravierende Unterschiede die sich unter anderem vor allem in unterschiedlichen F higkeiten bei einer Katalogabfrage zeigen So sind beispielsweise f r die Verwaltung von Periodika sehr unterschiedliche Varianten denkbar nur ganze Jahrg nge Jahrg nge und Einzel hefte Artikel innerhalb eines Heftes oder auch Kombinationen ETHICS bietet eine Reihe von Suchm glichkeiten die in anderen Bibliothekssystemen blicherweise nicht zu finden sind und weist deshalb eine recht hohe Komplexit t auf Insbesondere bestehen sehr viele Bez
44. jeder betrieblichen Anwendung stehen Daten W hrend bei vielen An wendungen im technischen Bereich keine gr sseren Datenmengen permanent gespei chert und verwaltet werden m ssen bilden Dateneingabe Verarbeitung permanente Speicherung und Datenausgabe geradezu Standardaufgaben bei betrieblichen Anwen dungssystemen F r den Begriff Daten findet sich bedauerlicherweise keine einfache Definition Ins besondere die Abgrenzung zum Begriff Information bereitet oft M he Der Begriff wird deshalb h ufig in einem intuitiven Sinne verwendet F r die vorliegende Arbeit wird folgende Begriffsbildung in Anlehnung an Schneider 91 zugrundegelegt Daten Angaben ber Dinge und Sachverhalte die entsprechend codiert elektronisch gespeichert und verarbeitet werden k nnen Im folgenden sind nur persistent gespeicherte Daten von Interesse d h Daten die nicht nur w hrend der Laufzeit von Anwendungsprogrammen existieren sondern dar berhinaus verf gbar sind im Gegensatz beispielsweise zu einer Symboltabelle in einem Compiler die nur zur Laufzeit des Compilers vorhanden ist Der Begriff Daten l sst sich in vielf ltiger Weise weiter charakterisieren Nebst der Bedeutung der Persistenz spielen vor allem Einsatzbereich Aufgabe und Form eine wichtige Rolle Daten Einsatzbereich datentechnische Aufgabe Form Stammdaten Metadaten formatiert Bewegungsdaten Nutzdaten unformatiert Hilfs Steuerdaten Fig 2 9 Klassifikation von Da
45. l ckenhaft vorhandenen Informationen ber das Ausgangssy stem mussten im Rahmen von aufwendigen Analysearbeiten vervollst ndigt werden Aufgrund dieser gr ndlichen Voruntersuchung konnte aber der Durchf hrungsent scheid leichter verantwortet werden Die Durchf hrung einer explorativen Daten ber nahme hat sich dabei als ausgesprochen wichtig herausgestellt Erschwerend hat sich bei dieser Aufgabe die mangelnde Voraussicht bei der Planung Implementation und Benutzung des Ausgangssystems bemerkbar gemacht Offensichtlich wurde nie an eine sp tere Abl sung gedacht So musste aufgrund fehlender Einheitlichkeit in den einzelnen Bilanzstrukturen auf die Uebernahme wichtiger Daten verzichtet werden was den Nutzen des Datenbestandes im Zielsystem nat rlich schm lert Aufgrund verschiedener organisatorischer Rahmenbedingungen auf die kein Einfluss genommen werden konnte waren die Kompetenzen f r die Entwicklung des Zielsy stems und f r die Daten bernahme auf verschiedene Personen in verschiedenen Be FALLSTUDIEN 141 reichen der Bank verteilt Dies hat zu wesentlichen zeitlichen Verz gerungen gef hrt Ein fr hzeitiges Einbeziehen der f r die Daten bernahme Verantwortlichen h tte geholfen einige der erw hnten Probleme zu vermeiden Werkzeugunterst tzung Der im Rahmen dieser Aufgabe entwickelte Import Dienst hat sich im Testeinsatz bew hrt Es wurde so entworfen und implementiert dass insbesondere das Einlesen und Konvertieren
46. migration of these data are tasks that have to be tackled regularly In many situa tions however there exists only incomplete or even wrong knowledge about the systems that are to be replaced and the data contained therein This doctoral thesis examines a number of problems which have to be solved during a data migration process Based on a broad discussion of initial situations and problems and corresponding classifications the process model MIKADO for data migration is presented MIKADO is a multi phase model suitable for migrating data between heterogeneous source and target systems It supports the analysis conversion and correction of data An important step is the transfer of the data to an intermediary system which helps to isolate from unfavorable characteristics of the source and target systems This step however necessitates an operating break at least for a short time It offers the following advantages the complexity of the migration process is reduced considerably and the data can be prepared for diverse purposes Because of the large size of the data in practical data migration projects typically special tools are needed Thus as a support to the process model MIKADO the tool architecture DART is presented as a concept as well as a description of its implemen tation with a set of tools The practical applicability of MIKADO and DART is proven by three data migration projects in different areas of application 12 1 E
47. muss Es wird weiter vorausgesetzt dass auch Angaben ber den Anwendungsbereich verf g bar sind oder f r die Daten bernahme beschafft bzw erg nzt werden k nnen Als typische Ausgangslage lassen sich zwei unterschiedliche Arten von Anwendungs systemen unterscheiden die im folgenden als Gross bzw Kleinanwendungen be zeichnet werden 44 DATEN RE ENGINEERING Grossanwendungen findet man typischerweise in sogenannten Midi und Mainframe Umgebungen Sie weisen eine Reihe der folgenden Merkmale auf Sie stehen schon seit vielen Jahren im Einsatz und wurden w hrend dieser Zeit mehrfach ver ndert und an neue Anforderungen angepasst Sie sind h ufig sehr gross bis hin zu einigen Millionen Zeilen Programm code und Datenbest nden von etlichen GByte Gr sse Sie wurden mit aus heutiger Sicht veralteten Sprachen und Werkzeugen ent wickelt COBOL RPG Assembler Das Sortiment an Werkzeugen ist je doch eher beschr nkt z B dominiert COBOL als Programmiersprache Ihre Datenverwaltung basiert auf komplexen Dateisystemen oder lteren Da tenbanksystemen VSAM IMS IDS Sie werden auf Ger ten betrieben die heute nicht mehr hergestellt werden oder deren Wartung erhebliche Kosten verursacht Die Zahl der Benutzer ist oft gross Sie wurden h ufig in dem Betrieb in dem sie eingesetzt werden auch entwik kelt F r Entwicklung und Betrieb wurden grosse Investitionen get tigt Kleinanwendungen sind typisch
48. oft als ausgesprochen schwierig Die Konsistenzsicherung stellt eine wesentliche Voraussetzung f r den Aufbau und die Nutzung eines Datenbestandes dar Die Ueberpr fung der Einhaltung von Konsi stenzbedingungen und das Ausl sen und Durchf hren entsprechender Reaktionen im Falle einer Verletzung einer solchen Bedingung stellen jedoch auch einen nicht zu vernachl ssigenden Aufwand dar Leikauf 91 Es muss deshalb beim Datenentwurf eine Auswahl von als wesentlich erachteten Konsistenzbedingungen getroffen wer den Mit Konsistenzbedingungen k nnen zudem nur Eigenschaften formuliert und gepr ft werden die sich formal beschreiben lassen Insbesondere kann die Korrektheit der Daten d h die Uebereinstimmung der Daten mit den entsprechen den Sachverhalten der Realit t wie bereits erw hnt nicht im Rahmen der Konsi stenzsicherung festgestellt werden Aufgrund von Realit ts nderungen und damit verbundenen Aenderungen und Erwei terungen eines Anwendungssystems sind auch die Konsistenzbedinungen nicht ein f r DATEN RE ENGINEERING 61 alle Mal fix festgelegt sondern werden allenfalls im Laufe der Zeit ge ndert Insbe sondere werden durch neue Anwendungen oft neue Konsistenzbedingungen einge f hrt gelegentlich verlieren auch bestehende Konsistenzbedingungen wieder ihre G ltigkeit oder werden abge ndert Dieser Vorgang geschieht bei Legacy Systemen in weitgehend unkontrollierter Weise Insbesondere werden vorhandene Daten bei Ei
49. umfasst insbeson dere auch die Verwaltung und das Aufrufen der einzelnen Dienste Der Kontrollteil bietet Funktionen zur Registrierung und Parametrisierung eines Dienstes an Als Parameter gelten dabei alle Arten von verwalteten Datenobjekten Relationen Attri bute Mengen von Attributen Da DART typischerweise auch als Werkzeug zur Nachdokumentation eingesetzt werden soll m ssen auch M glichkeiten bestehen um direkt interaktiv Meta Daten eingeben l schen bzw ndern und nat rlich auch ausdrucken zu k nnen Die Beschreibung der Implementation des Kernsystems ist in Hochstrasser 95 zu finden 5 7 DART DIENSTE 5 7 1 Aufgabe Mit Hilfe von einzelnen Diensten werden die eigentlichen Daten Re Engineering Aufgaben d h Aufgaben aus den Bereichen Analyse Konversion und Korrektur durchgef hrt Zur Unterst tztung einzelner Aufgaben sind sogenannte Hilfsdienste vorgesehen z B zur Erzeugung von tempor ren Zugriffssstrukturen 5 7 2 Realisierungskonzept Um eine einfache und rasche Entwicklung von Diensten zu erm glichen und um bereits vorhandene Programmbibliotheken nutzen zu k nnen wurde darauf geachtet an die Entwicklung von Diensten m glichst wenig Anforderungen zu stellen Insbe sondere sollte die Entwicklung von Diensten m glichst nicht an eine bestimmte Pro grammiersprache oder Entwicklungsumgebung gebunden sein Zur Abwicklung der Kommunikation mit dem Kernsystem wurde deshalb das Konzept der dynamischen
50. unterschiedlichen DATEN RE ENGINEERING 57 Abstraktionsebenen zu rekonstruieren Es ist jedoch wichtig festzuhalten dass sehr viele der heute im Betrieb stehenden Anwendungssysteme diese Entwurfsstufen gar nicht durchlaufen haben sondern beispielsweise anhand eines funktionsgetriebenen Prozesses entworfen wurden Es ist insofern nicht ganz korrekt von Schema Rekonstruktion zu sprechen da solche Schemas unter Umst nden ja gar nie bestanden haben Es ist aber trotzdem m glich gewisse Angaben aus dem in Betrieb stehenden Anwendungssystem das heisst durch Analyse der Daten selbst zu gewinnen Je nach Ausgangslage ist f r ein konkret vorliegendes Daten bernahmeproblem vorab zu entscheiden welche Angaben ben tigt werden welche bereits vorliegen und wel che noch beschafft werden m ssen Dabei kann diese Rekonstruktion unterschiedlich weit getrieben werden Es ist nicht in jedem Falle n tig und sinnvoll Informationen bis zur konzeptionellen Ebene zu rekonstruieren Wie in Abschnitt 2 12 bereits disku tiert wurde k nnen beim Entwurfsprozess zwischen der konzeptionellen und der physischen Ebene Angaben zur Semantik verlorengehen Diese lassen sich in der Regel weder vollst ndig noch eindeutig rekonstruieren F r manche Zwecke liefert das physische Schema durchaus gen gend Angaben um eine Daten bernahme durchf hren zu k nnen Sehr h ufig wird man aber zus tzliche Informationen ben tigen ohne aber deshalb gleich die Rekonstrukti
51. verwendet werden Mit UNICODE wurde auch ein solcher Code standardisiert UNICODE 95 Eine Reihe moderner Betriebssysteme unterst tzen diesen Code bereits e Codierung von Zahlen F r die Codierung von Zahlen werden in jedem Com putersystem eine ganze Reihe von unterschiedlichen Varianten unterschieden Ganzzahlen Festpunktzahlen Gleitpunktzahlen Dies geschieht aus Gr nden einer effizienten Speicherung und Verarbeitung Sofern kein Zugriff auf einer Stufe m glich ist die diese physischen Details verbirgt so muss bei einer Daten bernahme darauf R cksicht genommen und numerische Werte m ssen entsprechend umgesetzt werden e Interne Repr sentation Zur Ermittlung der Position eines einzelnen Bytes in nerhalb einer Folge von Bytes spielt es eine Rolle ob die Z hlung von rechts oder von links beginnt Die sogenannten little endian Rechner beginnen mit der Numerierung beim wertniedrigsten d h am weitesten rechts stehenden Byte Zu dieser Kategorie geh ren nebst allen INTEL Prozessoren 80x86 Prozessorfamilie beispielsweise auch die VAX von DEC big endian Rechner beginnen die Numerierung mit dem am weitesten links stehenden Byte Als wichtige Vertreter sind hier alle MOTOROLA Rechner 68000 Prozessorfamilie aber auch die Prozessoren der IBM Mainframes zu nennen Diese physische Repr sentation ist bei einer Uebernahme von Daten zu beach ten Zur Illustration dieser Probleme diene folgendes Beispiel Es soll
52. von Daten ab Diskette m glichst komfortabel unterst tzt wird um die Zeit f r die Uebernahme der Ausgangsdaten zu minimieren 6 5 ZUSAMMENFASSENDE BEURTEILUNG Beurteilt man die im Rahmen der drei durchgef hrten Fallstudien gemachten Erfah rungen im Zusammenhang mit den wesentlichen Eigenschaften von MIKADO aber auch mit den in Abschnitt 3 8 aufgestellten Hypothesen so ergeben sich die folgen den Beobachtungen Parlament ETHICS Bilanzdaten gross gross gross gross klein bestatigt bestatigt bestatigt bestatigt bestatigt bestatigt bestatigt teilweise teilweise bestatigt bestatigt bestatigt best tigt best tigt best tigt nicht best tigt nicht best tigt Fig 6 7 Ergebnisse der Fallstudien Nutzen einer explorativen Daten bernahme Nutzen eines Zwischensystems Hypothese I Hypothese II Hypothese III Hypothese IV Hypothese V Hypothese VI Insgesamt kann gesagt werden dass alle drei Uebernahmen dank der strukturierten Vorgehensweise in vern nftiger Zeit durchgef hrt werden konnten Bei allen drei Aufgaben hat sich aber auch deutlich gezeigt dass die Daten bernahme wahrscheinlich ganz erheblich vereinfacht worden w re wenn das Problem einer k nftigen Daten bernahme bereits zu einem fr heren Zeitpunkt idealerweise bereits bei Planung Entwurf und Realisierung der entsprechenden Systeme in die Ueberle gungen miteingeflossen w re 142 7 BEURTEILUNG
53. von Inkonsistenzen Diss ETH Z rich Verlag der Fachvereine Z rich 1991 Li 93 Li L Fast In Place Verification of Data Dependencies IEEE Transactions on Knowledge amp Data Engineering Vol 5 Nr 2 1993 S 266 281 Lim et al 93 Lim E P et al Entity identification problem in database integration Proc of the Int Conf on Data Engineering 1993 S 294 301 L thi et al 92 Liithi A et al Einsatz von Informationstechnologien in der Schweiz 1992 Universitat Freiburg 1992 Mamrak et al 89 Mamrak S et al Chameleon A system for solving the data translation problem TEEE Transactions on Software Engineering Vol 15 No 9 1989 S 1090 1108 Mamrak et al 94 Mamrak S et al The Integrated Chameleon Architecture Translating Elec tronic Documents with Style Prentice Hall 179 Seiten 1994 152 LITERATURVERZEICHNIS Mannila 92 Mannila H et al Discovering Functional and Inclusion Dependencies in Relational Databases International Journal of Intelligent Systems Vol 7 Nr 7 1992 S 592 607 Mannila R ih 92 Mannila H R ih K J On the Complexity of Inferring Functional Depen dencies Discrete Applied Mathematics Vol 40 Nr 2 1992 S 237 243 Mannila R ih 94 Mannila H R ih K J Algorithms for Inferring Functional Dependencies from Relations Data amp Knowledge Engineering Vol 12 Nr 1 1994 S 83 99 McClure 93 McClure C Softwa
54. werden welche Daten aufzubewah ren sind und welche definitiv nicht mehr gebraucht werden Geeignete Speichermedi en und Archivierungskonzepte sind bereitzustellen die Langzeitarchivierung stellt zur Zeit noch erhebliche technische Probleme sowohl betreffend die Lebensdauern der entsprechenden Medien als auch das sp tere Wiederherstellen in einem sich rasch ndernden technischen Umfeld Werden die Daten nie mehr gebraucht so sind sie zu entsorgen Das kann normalerweise durch L schen auf den entsprechenden Datentr gern geschehen kann aber in schwierigen F llen auch ganz erhebliche technische und organisatorische Aufwendungen verursachen 2 12 DATEN FORWARD ENGINEERING Der Entwurfsprozess im Datenbereich ist seit vielen Jahren Gegenstand intensiver Forschung Entsprechend reichhaltig sind die vorhandenen Resultatet Heute sind eine ganze Reihe von weitgehend unbestrittenen Methoden und Techniken bekannt was sich auch in der grossen Zahl an vorhandenen Lehrb chern zu diesem Thema zeigt Obwohl die entsprechenden Methoden ihren Ursprung im Gebiet der Datenbank technik haben gelten die folgenden Ausf hrungen weitgehend auch f r Anwendun gen deren Daten nicht mit Datenbanksystemen sondern beispielsweise mit konven tionellen Dateisystemen verwaltet werden Insbesondere im Zusammenhang mit der Rekonstruktion von Entwurfsunterlagen aus bestehenden Anwendungssystemen gelangen in der Regel dieselben Begriffe sinngem ss zur Anwendung
55. zur Verf gung zu haben e Logging Zu Dokumentationszwecken w re die Aufzeichnung der durchge f hrten Dienstaufrufe n tzlich e Erweiterungen des Metamodelles Dienste sollten das Metamodell von DART erweitern k nnen Dies muss allerdings unter der Kontrolle des Kernsystems erfolgen Diese M glichkeit ist im Metameta Modell von DART bereits vor gesehen wurde aber nicht implementiert e Leistung Die Leistung einzelner Dienste muss f r den praktischen Einsatz noch deutlich erh ht werden Dies kann einerseits durch Optimierung der ein gesetzten Algorithmen erfolgen entsprechende Vorschl ge f r den Import Dienst sind in Rossi 95 zu finden andererseits kann aber auch die Leistung aller Dienste durch Verbesserung der Datenbereitstellung durch das Kernsy stem noch erh ht werden beispielsweise durch den Einbau eines Cache e Mehrbenutzerf higkeit F r praktische Zwecke muss DART von mehreren Benutzern gleichzeitig verwendet werden k nnen Trotz dieser M ngel und W nsche kann zusammenfassend gesagt werden dass sich das Konzept von DART grunds tzlich bew hrt hat 5 9 VERWANDTE ARBEITEN 5 9 1 Vergleichbare Projekte Eine vertiefte Auseinandersetzung mit kommerziell verf gbaren Werkzeugen war im Rahmen dieser Arbeit wegen den ganz unterschiedlichen Entwicklungsst nden nicht vorgesehen und wurde deshalb auch nicht durchgef hrt Interessant ist jedoch ein Vergleich mit anderen Forschungsarbeiten auf der Ebene der zugrunde
56. BAS System Es handelt sich dabei um ein Produkt der Firma Software AG das ein propriet res Datenmodell unterst tzt Tsichritzis Lochovsky 77 Dieses kennt im Gegensatz zum Relationen modell auch Wiederholungsgruppen Eine Beschreibung von m glichen Umset zungsstrategien von ADABAS Daten sind in Neumann et al 93 zu finden F r ETHICS besteht an der ETH ein eigener Rechenzentrumsbetrieb FALLSTUDIEN 131 Zielsystem Im Rahmen der vorliegenden Aufgabe war zu Beginn kein eindeutiges Zielsystem definiert Vielmehr war die Wahl eines geeigneten Zielsystems Bestandteil der Abkl rungen die von der Landesbibliothek durchzuf hren waren Dieses bewegliche Ziel machte eine seri se Abkl rung der Uebernahme an sich recht schwierig Da es sich bei der untersuchten Aufgabe aber um ein Problem handelte das an sich weder neu noch einmalig war konnten Anleihen bei hnlichen Projekten gemacht werden Das Bed rfnis nach Datenaustausch zwischen verschiedenen Bibliotheken besteht an vielen Orten seit langem Im Laufe der Jahre haben sich deshalb im Bibliotheksbe reich eine Reihe von nationalen und internationalen standardisierten Datenaus tauschformaten entwickelt Gredley Hopkinson 90 Diese haben allerdings recht unterschiedlich starke Verbreitung erlangt und sind untereinander nur beschr nkt kompatibel Solche Datenaustauschformate erleichtern einen Austausch von Kata logdaten Einige vor allem kommerzielle Bibliothekssysteme sind
57. DISS ETH Nr 11628 Re Engineering und Migration betrieblicher Nutzdaten ABHANDLUNG zur Erlangung des Titels Doktor der technischen Wissenschaften der Eidgen ssischen Technischen Hochschule Z rich vorgelegt von Daniel Aebi Lie oec publ Universit t Z rich geboren am 19 April 1959 von Z rich und Aetingen SO Angenommen auf Antrag von Prof Dr C A Zehnder Referent Prof Dr L Richter Korreferent 1996 VORWORT Die vorliegende Arbeit entstand w hrend meiner Teilzeitt tigkeit als Assistent in der Arbeitsgruppe von Prof Zehnder am Institut f r Informationssysteme der ETH Z rich Die langj hrige wissenschaftliche Auseinandersetzung dieser Gruppe mit Pro blemen der Informatik Projektentwicklung vor allem auch im Zusammenhang mit Datenbankanwendungen f hrte ber Arbeiten zur evolution ren Entwicklung sol cher Anwendungen naheliegenderweise auch zum Problemkreis bestehende Anwen dungen abzul sen oder mit neuen Anwendungen ber geeignete Schnittstellen zu verbinden In diesem Umfeld entstand die vorliegende Arbeit die sich mit Problemen der Datenaufbereitung und bernahme befasst Prof C A Zehnder dem Betreuer dieser Arbeit geb hrt mein ganz besonderer Dank Seine in jeder Hinsicht grossz gige Unterst tzung hat diese Arbeit berhaupt erst erm glicht Sein konsequentes Hinweisen auf die Bedeutung einer klaren einfachen und konsistenten Begriffsbildung waren mir eine grosse Hilfe E
58. INLEITUNG 1 1 PROBLEMSTELLUNG EVOLUTION STATT REVOLUTION W hrend den 70er und fr hen 80er Jahren war die betriebliche Informatik durch den Aufbau einer grossen Zahl von Anwendungen meistens basierend auf Grossrechnern zur Rationalisierung wirtschaftlicher Abl ufe gekennzeichnet Damit verbunden waren oft auch umfangreiche Datenersterfassungen Diese Anwendungen haben in vielen Betrieben mittlerweile den Leistungsumfang erreicht der zur Nutzung der entsprechenden Rationalisierungspotentiale n tig ist die bestehenden Anwendungen m ssen jedoch st ndig neuen Anforderungen angepasst oder durch modernere abge l st werden Parallel zu dieser Entwicklung entstanden ab Mitte der achtziger Jahre vor allem ausgel st durch das Verf gbarwerden von billiger Rechenleistung am Arbeitsplatz sog Personalcomputer auch eine sehr grosse Zahl von weitgehend isoliert be triebenen kleineren Anwendungen h ufig mit lokalen Datenbest nden Heute wird an vielen Orten ein Zusammenwachsen dieser beiden Welten angestrebt In den neunziger Jahren steht der Entwurf und die Realisierung von entscheidungsunterst t zenden Anwendungen im Vordergrund die in der Regel auf bereits vorhandenen Datenbest nden basieren Diese Entwicklung hat dazu gef hrt dass immer h ufiger vorhandene Datenbest nde strukturell wie auch inhaltlich an neue Verh ltnisse angepasst werden m ssen Nicht selten bilden die Datenbest nde die weitaus kostbarste Kompone
59. Idee liegt ihnen aber zugrunde dass versucht wird m glichst fr h anhand von konkret vorliegenden VORGEHENSMODELLE 83 Teilergebnissen berpr fbare Resultate vorzuweisen die dann eine R ckkoppelung auf den Entwicklungprozess ausl sen k nnen Damit sollen Fehlentwicklungen ver mieden oder zumindest fr hzeitig erkannt und korrigiert werden k nnen Um fr hzei tig zu Resultaten zu kommen m ssen aber nat rlich entsprechende Einschr nkungen sowohl im Funktionsumfang als auch in der Leistung solcher Teilergebnisse in Kauf genommen werden Alle diese Modelle gehen jedoch urspr nglich von einer neu zu entwickelnden An wendung aus die dann unter Umst nden w hrend l ngerer Zeit in vielen Phasen an ver nderte Anforderungen angepasst wird F r die Durchf hrung von Abl sungen bereits existierender Anwendungssysteme sind sie nicht geeignet 4 2 VORGEHENSMODELLE F R DIE ABL SUNG VON ANWENDUNGS SYSTEMEN 4 2 1 Ausgangslage W hrend f r die Gliederung von Entwicklungsvorhaben zahlreiche Vorgehensmodel le bekannt sind bestehen f r die Durchf hrung von Wartungs und Re Engineering aufgaben oder gar Abl sungen von Anwendungssystemen nur sehr wenige systemati sche Ans tze Die bekannten Vorgehensmodelle f r die Entwicklung ber cksichtigen bestehende Systeme mit ihren Eigenheiten nur ungen gend oder gar nicht F r die genannten Problembereiche m ssen deshalb spezielle Vorgehensmodelle entwickelt werden Erste Ans tze in
60. Model of Software Development and Enhancement IEEE Computer Vol 21 No 5 1988 S 26 37 Br ndli 94 Br ndli M Ermittlung von Datenkosten Diplomarbeit ETH Z rich Institut f r Informationssysteme 1994 Breitbart 90 Breitbart Y Multidatabase Interoperability SIGMOD Record Vol 19 No 3 1990 S 53 60 Briand et al 88 Briand H et al From Minimal Cover to Entity Relationship Diagram Proc of the 6th Int Conf on the Entity Relationship Approach Elsevier 1988 S 287 304 Brodie 89 Brodie M L Future intelligent information systems Al and database technologies working together In Brodie M L Mylopoulos J eds Artificial intelligence and databases Morgan Kaufmann 1989 S 623 641 Brodie Stonebraker 95 Brodie M L Stonebraker M Migrating Legacy Systems Morgan Kauf mann Publishers Inc San Francisco 210 Seiten 1995 Brunner 93 Brunner H SwissBase V 1 2 Benutzerhandbuch Bundesamt f r Informatik Informations und Dokumentationszentrum 1993 B ttemeyer 95 B ttemeyer W Wissenschaftstheorie f r Informatiker Spektrum Akademi scher Verlag 149 Seiten 1995 LITERATURVERZEICHNIS 147 Cardenas Wang 85 Cardenas A F Wang G R Translation of SOL DS Data Access Update into Entity Relationship Data Access Update Proc of the 4th Int Conf on Entity Relationship Approach IEEE Computer Society Press 1985 S 256 267 Carlyle 90 Carlyle R Zs
61. O Modell wird eine Daten bernahme grunds tzlich zweimal durchgef hrt zuerst explorativ dann effektiv Im Rahmen der explorativen Durchf h rung geht es im wesentlichen darum das Problem in all seinen Einzelheiten zu verste hen entsprechende L sungsverfahren und Werkzeuge f r Teilprobleme zu entwickeln und einen Vorgehensplan zu erarbeiten Je nach Ausgangslage kann die explorative Durchf hrung auch nur mit einem Teildatenbestand durchgef hrt werden Bei der effektiven Durchf hrung wird die Daten bernahme mit aktuellen Daten durchgef hrt In einfachen Verh ltnissen k nnen die beiden Durchf hrungen auch zusammenfallen Daten bernahme 1 Durchf hrung 2 Durchf hrung explorativ effektiv Zeit LL sn Fig 4 8 Die zwei Durchf hrungsarten beim MIKADO Modell Dieses Konzept kann mit einer Kombination von Wegwerf mit evolution rem Prototyping verglichen werden Als Resultate der explorativen Durchf hrung sollen jedoch nicht nur Erkenntnisse und Erfahrungen sondern auch ein detaillierter Vorge hensplan sowie auch geeignete Werkzeuge zur effektiven Durchf hrung anfallen In MIKADO werden folgende f nf Phasen unterschieden Fig 4 9 1 Abgrenzung 2 Voranalyse 3 Aufbereitung f r das Zwischensystem 4 Aufbereitung im Zwischensystem mit den Teilaufgaben e Analyse e Konversion e Korrektur 5 Aufbereitung f r das Zielsystem Dabei werden die Phasen I und 2 nur in der explorativen Durchf
62. PONENTEN BETRIEBLICHER ANWENDUNGSSYSTEME Bei der vorliegenden Arbeit stehen betriebliche Anwendungssysteme im Zentrum des Interesses Diese lassen sich wie folgt schematisch darstellen betriebliches i Anwendungssystem Individuelle bzw Standard Anwendungsprogramme t Systemprogramme t Ger te Plattform Daten physisch Fig 2 2 Komponenten eines betrieblichen Anwendungssystems Ein System das aus diesen Komponenten aufgebaut ist wird im folgenden als be triebliches Anwendungssystem oder kurz Anwendungssystem bezeichnet Betriebliches Anwendungssystem Ein Anwendungssystem besteht aus Ge r ten System und Anwendungsprogrammen zur Erfassung Verarbeitung Ausgabe und permanenten Speicherung von Daten sowie den f r den Betrieb verwendeten Daten Sind nur die Programme und Daten von Interesse so wird daf r der Begriff Anwen dung verwendet Dabei ist zu beachten dass keinerlei Voraussetzungen betreffend der technischen Realisierung der Datenverwaltung gemacht werden Insbesondere ist es unerheblich ob die Daten durch ein Datenbankverwaltungssystem durch entsprechende Dienste des Betriebssystems Filesystem oder durch spezielle anwendungsspezifisch ent wickelte Systemprogramme verwaltet werden z B spezielle Transaktionsverwal tungssysteme wie sie in Flugreservationssystemen h ufig eingesetzt werden Ver wandte Begriffe sind datenbankbasiertes Anwendersystem
63. Projektes das an der Universit de Namur Belgien durchgef hrt wird Im Rahmen dieses Projektes in das w hrend einer f nf j hrigen Laufzeit 1993 1997 rund f nfzig Personenjahre Aufwand investiert wird sollen Methoden und eine Werkzeugumgebung f r Reverse Engineering Re Engineering Migration Wartung und evolution re Weiterentwicklung von Daten bankanwendungen entwickelt werden Kernst ck bildet eine Methode die semanti kerhaltende Transformationen eines Datenbestandes erlaubt Hainout et al 93 Be merkenswert an diesem Projekt ist dass insbesondere auch dem Daten Reverse Engineering starke Beachtung geschenkt wird WERKZEUGUNTERSTUTZUNG 117 Im Rahmen dieses Projektes wird eine Werkzeugumgebung entwickelt die vor allem auch das Pflegen und Weiterentwickeln bestehender Datenbest nde unterst tzt Es stehen dazu Werkzeuge zur Erfassung von Datenbeschreibungen verschiedener Aus gangssysteme zur Verf gung Es k nnen Beschreibungen von relationalen Daten bankverwaltungssystemen d h SQL Anweisungen CODASYL Datenbankver waltungssystemen aber auch Dateibeschreibungen aus COBOL Programmen eingele sen werden Weitere Systeme insbesondere IMS sind geplant Diese Beschreibungen k nnen dann in DB MAIN erg nzt und zu konzeptionellen Schemas weiterentwickelt werden Hainout et al 92 Joris et al 92 Zur Pflege solcher Schemas stehen eine Reihe von Werkzeugen zur Verf gung Beispielsweise k nnen anhand von Muster vergl
64. R NOT NULL PRIMARY KEY AdressTyp INTEGER Strasse CHAR 30 PLZ CHAR 5 Ort CHAR 30 Der Zusammenhang zwischen Studierenden und Fakult ten bzw ihren Adressen wird ber eine Schl ssel Fremdschl ssel Beziehung hergestellt Auf eine weitergehende Normalisierung es besteht noch eine funktionale Abh ngigkeit zwischen PLZ und Ort wird aus Gr nden einer effizienten Implementation verzichtet 3 8 HYPOTHESEN KONSEQUENZEN LEHREN 3 8 1 Hypothesen Aufgrund der geschilderten Sachverhalte lassen sich eine Reihe von Hypothesen formulieren Basierend auf diesen Hypothesen wird im folgenden versucht Konse quenzen f r die Durchf hrung von Daten bernahmen sowie Lehren f r den Entwurf von neuen Anwendungssystemen zu ziehen Hypothese I Hypothese II Hypothese III Interaktivit t n tig Eine vollautomatische Rekonstruktion fehlender Informationen ist in der Regel nicht m glich Daher muss sorgf ltig abgewogen werden was manuell und was automatisch zu tun ist Ma nuelle Vorgehensweisen k nnen manchmal leistungsf higer sein als maschinelle Ein Zusammenhang zwischen Datenobjekten des Aus gangs und des Zielsystems kann in der Regel nicht automatisch her gestellt werden Der Daten bernahmevorgang insgesamt erfordert an vielen Stellen ein manuelles Eingreifen Informationsbed rfnisse a priori unklar Die Informationsbeschaffung ist ein aufwendiger und teurer Vorgang Es muss deshalb genau ab gekl rt werden wel
65. Re Structuring Restrukturierung verwendet Z Forward Engineering Forward Engineering fe je y 2 lt 3 R z at i Cc Re Engi 2 Re Engineering 2 Re Engineering neering D a je 2 5 E Z 5 a g 3 E in Reverse Engineering Reverse Engineering Restructuring Restructuring Restructuring Zeit Fig 2 1 Zusammenhang der Re Begriffe in Anlehnung an Chikofsky Cross 90 2 3 RE ENGINEERING VERSUS WARTUNG Die bisher diskutierten Begriffe stammen aus dem Problembereich der Analyse An passung und Ver nderung bestehender Anwendungssysteme F r Massnahmen in diesem Bereich hat aber auch der Begriff Wartung eine seit l ngerem allseits akzep tierte Bedeutung IEEE 91 Wartung Ver nderung eines Produktes nach der Ablieferung um Fehler zu korrigieren die Leistung oder andere Eigenschaften zu verbessern oder um das Produkt an eine ver nderte Umgebung anzupassen Folgende Wartungstypen werden unterschieden Lehner 91 e Korrigierende Wartung corrective maintenance Behebung von Fehlern nach der Betriebsaufnahme e Adaptive Wartung adaptive maintenance Anpassungen an ver nderte An forderungen e Perfektionierende Wartung perfective maintenance Verbessern der Lei stung umfasst aber auch alle Massnahmen um k nftige Wartungsaufwen dungen zu reduzieren z B Restrukturierung Im deutschen Sprachraum wird gelegentlich auch der Begriff Sanierung ver
66. T wurde im Rahmen von drei konkreten Daten bernahmen gezeigt Die entsprechenden Erfahrungen sind im Kapitel 6 detail liert beschrieben Erwartungsgem ss haben diese Experimente aber auch eine Reihe von M ngeln und und w nschbaren Erweiterungen aufgezeigt e R cksetzen durchgef hrter Aktionen UNDO Es ist insbesondere bei der explorativen Durchf hrung sehr w nschbar wenn durchgef hrte Aenderun gen wieder r ckg ngig gemacht werden k nnten Dies ist allerdings kein tri 114 WERKZEUGUNTERSTUTZUNG viales Problem da eine Aenderungsoperation auf sehr grosse Datenmengen wirken kann Dieses Problem sollte urspriinglich durch die Transaktionsver waltung der Datenverwaltungskomponente von DART behandelt werden hat sich aber wie bereits erw hnt als nicht praktikabel erwiesen Eine Erleichte rung k nnte aber immerhin durch das Einf hren von sogenannten Checkpoints erreicht werden Mit Hilfe von Checkpoints k nnten benutzer gesteuert definitive Zwischenergebnisse eingefroren werden so dass im Fehlerfalle nur die Aenderungen bis zum letzten solchen Checkpoint r ck g ngig gemacht werden m ssten e Kommandosprache Gr ssere und damit oft zeitintensive Arbeiten sollten in der explorativen Durchf hrung vorbereitet und anschliessend ohne Benut zerinteraktion ablaufen k nnen Mehrere Dienste sollten dazu in geeigneter Reihenfolge abgearbeitet werden k nnen Es w re n tzlich hier eine einfache Kommandosprache
67. UND AUSBLICK 7 1 BEURTEILUNG Das Vorgehensmodell MIKADO wurde im Rahmen von drei konkreten Projekten aus der Praxis auf seine Tauglichkeit hin berpr ft Dabei wurden f r die konkrete Ue bernahme der entsprechenden Datenbest nde auch eine ganze Reihe von spezifischen Werkzeugen entsprechend der vorgeschlagenen Architektur DART entwickelt Sowohl das Vorgehensmodell als auch die Werkzeuge haben sich dabei bew hrt Bei allen Projekten zeigte sich deutlich die Bedeutung einer explorativen Daten ber nahme In einem Umfeld wie es typischerweise bei Legacy Systemen anzutreffen und das durch unvollst ndige oder falsche Angaben ber das Ausgangssystem und gele gentlich sogar auch ber das Zielsystem gekennzeichnet ist lohnt sich dieser Auf wand Es hat sich im Verlaufe dieser Arbeit auch immer wieder gezeigt dass viele Probleme ihre Ursache in unsachgem sser Realisierung oder in speziellen Eigenheiten der Ausgangssysteme haben So hat sich beispielsweise das Bereitstellen eines geeig neten Zugriffes auf die Ausgangsdaten gelegentlich als wesentlich schwieriger her ausgestellt als zu Beginn erwartet wurde Das Aufbereiten der Daten in einem Zwi schensystem kann die Komplexit t eines Daten bernahmeprojektes deutlich senken Im Rahmen der durchgef hrten Projekte wurde die Erfahrung gemacht dass der Frage der Datenqualit t oft noch zu wenig Aufmerksamkeit geschenkt wird Es hat sich aber auch gezeigt dass eine seri se L su
68. Uebernahmeprozesses auf Informations l cken die nachtr glich gef llt werden m ssen die aber unter Umst nden das weitere Vorgehen stark beeinflussen k nnen Idealerweise k nnten die fehlenden Informationen mit Hilfe von Reverse Engi neering Techniken automatisch aus dem Ausgangssystem gewonnen werden Diese Hoffnungen sind allerdings etwas unrealistisch wie auch folgendes Zitat zeigt however reverse engineering is complex enough that at least in the short term it does not appear that very many real problems are suspectible to total ly automatic solution Chikofsky et al 93 Obwohl f r die Rekonstruktion fehlender Informationen aus Datenbest nden teilweise automatische Verfahren bekannt sind weisen diese h ufig eine f r praktische Zwecke nicht tolerierbare Komplexit t auf oder basieren auf zu restriktiven Annahmen ber die Ausgangsdaten s Most of these studies however appear to be limited in scope and are ge nerally based on assumptions on the quality and completeness of the source data structures to reverse engineer that cannot be relied on in many practical situations Hainout et al 95 DATEN RE ENGINEERING 51 Zur Vervollst ndigung bzw Rekonstruktion der ben tigten Informationen gilt der allgemeine Reverse Engineering Grundsatz dass s mtliche verf gbaren Informati onsquellen beigezogen werden sollten Insbesondere kann die Glaubw rdigkeit einer Information erheblich gesteigert werden w
69. Ward M et al The Maintainer s Assistant TEEE Int Conf on Software Maintenance IEEE Computer Society Press 1989 S 307 314 Winans Davis 91 Winans J Davis K Software reverse engineering from a currently existing IMS database to an entity relationship model In H Kangassalo Ed Enti ty Relationship Approach The Core of Conceptual Modelling Elsevier Science Publisher B V 1991 S 333 348 W hrle Krallmann 92 W hrle G Krallmann H Markt bersicht CARE Tools Wirtschaftsinfor matik Vol 34 Nr 2 1992 S 181 189 LITERATURVERZEICHNIS 157 Wu Manber 92 Wu S Manber U Fast Text Searching Allowing Errors Communications ofthe ACM Vol 35 Nr 10 1992 S 83 91 Yang 91 Yang H The supporting environment for a reverse engineering system the maintainer s assistant Int Conf On Software Maintenance IEEE Computer Society Press 1991 S 13 22 Yates Gonnet 92 Baeza Yates R Gonnet G A new Approach to Text Searching Communi cations ofthe ACM Vol 35 Nr 10 1992 S 74 82 Zehnder 89 Zehnder C A Informationssysteme und Datenbanken Verlag der Fach vereine und Teubner Z rich und Stuttgart 5 Auflage 274 Seiten 1989 Zehnder 91 Zehnder C A Informatik Projektentwicklung Verlag der Fachvereine und Teubner Z rich und Stuttgart 2 Auflage 309 Seiten 1991 Zvegintzov 94 Zvegintzov N technical editor Software Management Technology Refe rence Gu
70. abei wurden beide Begriffe vorerst ohne klare Abgren zung sowohl f r T tigkeiten der Analyse als auch der Ver nderung bestehender Anwendungssysteme verwendet Eisner 88 GRUNDLAGEN UND BEGRIFFE 19 Bis Ende der achtziger Jahre herrschte ein eigentlicher Begriffswirrwarr viele der erw hnten Begriffe wurden je nach Autor mit unterschiedlichen Bedeutungen ge braucht So wurden gelegentlich nicht nur der Begriff Reverse Engineering sondern auch die Begriffe Re Structuring und Re Design f r Sachverhalte verwendet die heute mit dem Begriff Re Engineering bezeichnet werden Es bestand deshalb ein Bedarf nach einer klaren Grundlage Eine erste begriffliche Basis wurde mit Chikofsky Cross 90 geschaffen und heute besteht immerhin wenigstens weitgehend Konsens in der Abgrenzung von Reverse und Re Engineering Ausgangspunkt f r die folgenden Begriffsbildungen ist die Feststellung dass sich die Entwicklung von Anwendungssystemen in einzelne Phasen gliedern l sst Dabei ist es unerheblich welches der zahlreich vorhandenen Vorgehensmodelle Wasser fallmodell Spiralmodell evolution res Prototyping u a Boehm 88 Schulz 89 Zehnder 91 betrachtet wird Wesentlich ist einzig die Beobachtung dass alle diese Modelle entlang der gerichteten Zeit verschiedene Einzelt tigkeiten unterscheiden wobei Zyklen durchaus vorkommen k nnen Die Repr sentation dieser Modelle als gerichtete Graphen l sst somit sowohl eine Vorw rts als auch eine
71. achte recht rasch Klarheit ber die Struktur der von SwissBase gelieferten flachen Datei Es zeigte sich auch dass eine Konversion der Daten in erste Normalform ohne gr ssere Schwierigkeiten m glich sein sollte 124 FALLSTUDIEN Hinsichtlich der Fragestellung der Datenqualit t zeigte ein erstes Ansehen der Daten zwei Problemkreise e Konsistenz Da nur der Code der Bildschirmmasken verf gbar war bestand keine abschliessende Klarheit ber Art und Umfang einer m glichen Konsi stenzsicherung innerhalb der Anwendung Eine Analyse der Bildschirmmas ken zeigte jedoch dass vermutlich bei der Dateneingabe gewisse Pr fungen durchgef hrt wurden Einzelne dieser Eingabepr fungen waren aber irgend wann wieder deaktiviert worden e Schreib und Darstellungsfehler Bei der Dateneingabe inbesondere der Volltexte war sicher mit dem Auftreten von Eingabefehlern zu rechnen Dies war vermutlich kein allzu gravierendes Problem Als viel gewichtiger erwies sich jedoch die Feststellung dass bei der Eingabe der Volltexte versucht wur de mittels geeigneter Eingabe von Leerschl gen Spaces die Darstellung zu beeinflussen Da es sich um eine zeichenbasierte Benutzeroberfl che han delt und die Textdarstellung mit einer Schrift mit fester Zeichenbreite erfolgt war das grunds tzlich m glich Diese Formatierungen w rden bei einer Ue bernahme wahrscheinlich verloren gehen Es zeigte sich leider auch dass sehr oft einfach ber die Begren
72. alten Inhalt Begr ndung und die Antwort des Bundesrates Diese Angaben liegen zum Teil nicht nur in deutscher sondern auch in franz sischer und italienischer Sprache vor Pro Session werden im Mittel zwei bis dreihundert neue Vorst sse eingereicht insgesamt wurden seit der Betriebsaufnahme 1983 rund zehntausend Vorst sse erfasst und gespeichert Die Nutzdaten umfassen ein Volumen von ca 60 MByte Es besteht ein Zugriff auf der Ebene des Datenverwaltungssystems Mit Hilfe von Hilfsprogrammen von SWISSBASE war es m glich die Daten als flache Textdatei s mtliche Daten in einer einzigen Datei herauszuschreiben Vorhandene Systembeschreibungen Die ber das Ausgangssystem vorhandenen Informationen waren usserst knapp Es lag zwar ein Benutzerhandbuch f r die Bedienung von SWISSBASE Anwendungen FALLSTUDIEN 123 vor dieses enthielt jedoch weder spezielle Angaben zur Vorstossverwaltung noch Angaben zum Aufbau der Daten Weitere Dokumente waren nicht vorhanden Zur L sung der Aufgabe konnten deshalb nur folgende Informationsquellen beigezo gen werden e Die Benutzerschnittstelle der laufenden Anwendung Bildschirmmasken e Die Daten Fiir die Zielsysteme GU 1 bzw GU 2 standen konzeptionelle Schemas zur Verfiigung Aufgrund der Tatsache dass das Zielsystem GU 2 aber noch in Entwicklung war war dieses Schema noch nicht stabil F r GU 1 war auch ein logisches Schema verf g bar F r das Datenverwaltungssystem BASIS wa
73. anabe Lonesome cat TRANSFER 19920630 CDP 000000000053 Billy Harper Soran Bushi B H TRANSFER 19920630 CD P 000000000077 Lyrical Melodies of Japan Melo LUPM 19920901 cDP 000000000084 John Williams amp The Boston Pop TRANSFER 19920630 CD 2000000000091 Fabrizio de Andr Indians TRANSFER 19920630 CD 2 000000000152 Jean Michel Jarre Les cham LUPM 19920923 CDP 000000000176 Stevie Wonder In square circl Fig 3 3 Visuell erkannte Struktur Hypothesen Eine maschinelle Suche nach solchen Hypothesen w re jedoch mit sehr grossem Aufwand verbunden und bei gr sseren Datenbest nden in vern nftiger Zeit gar nicht durchf hrbar Es l sst sich zwar f r solche Analysen auch nur mit Teildatenbest nden arbeiten es ist dann jedoch kein triviales Problem sicherzustellen dass die in einem solchen Teildatenbestand gefundenen Eigenschaften repr sentativ f r den Gesamtda tenbestand sind Pfund 94 Beispiel 2 Erkennen und Pr fen funktionaler Abh ngigkeiten Im Rahmen von Datenmodellierungsprozessen spielt das Konzept der funktionalen Abh ngigkeit eine zentrale Rolle Funktionale Abh ngigkeiten haben insbesondere eine grosse Bedeutung im Zusammenhang mit dem relationalen Modell aber nicht nur dort sondern auch bei Entit ten Beziehungsmodellen Navathe et al 92 Funk tionale Abh ngigkeiten spielen vor allem auch eine wichtige Rolle im Zusammenhang mit Normalisierungsprozessen DATEN RE ENGINEERING 55 Beispielrela
74. and getrennt und in eine m glichst allgemeine Darstel lung bergef hrt In dieser Phase erfolgt insbesondere aber auch die Vervollst ndi gung bzw Rekonstruktion und Ueberpr fung der zugeh rigen Datenbeschreibung logisches Schema Unter Umst nden k nnen auch bereits erste Aufbereitungsarbei ten beispielsweise das Umcodieren von Zeichens tzen erfolgen Phase 4 Aufbereitung im Zwischensystem Zweck Aufbereiten der Daten f r eine k nftige Nutzung Vervollst ndi gen der Dokumentation Korrigieren von falschen und Eliminieren von berfl ssigen Daten Gegebenenfalls auch Nacherfassen von fehlenden Daten Voraussetzungen Ausgangssystemunabh ngiger Datenbestand Logisches Schema Ziel Resultate Datenbestand der f r eine Uebernahme oder Mehrfachnutzung vorbereitet ist Vollst ndige Dokumentation In der Aufbereitungsphase erfolgt die Hauptarbeit bei einer Daten bernahme In dieser Phase werden die noch fehlenden Informationen vervollst ndigt und die f r eine k nftige Nutzung im Zielsystem n tigen Anpassungen und Korrekturen vorge nommen Im wesentlichen m ssen dabei Probleme wie sie in Kapitel 3 angesprochen wurden erkannt und gel st werden In dieser Phase sind aber insbesondere bei der explorativen Durchf hrung auch entsprechende Werkzeuge zur Unterst tzung bereit zustellen d h zu beschaffen oder zu entwickeln und es ist ein detaillierter Vorge hensplan f r die effektive Durchf hrung zu erarbeiten
75. ann im Prinzip die effektive Durchf hrung in Angriff genommen werden Es ist aber durchaus denkbar und in komplizierteren Verh ltnis sen zu erwarten dass aufgrund der Ergebnisse zuerst problemangepasst weitere Werkzeuge f r eine Uebernahme grosser Datenmengen zu entwickeln bzw zu be schaffen sind Bevor die effektive Durchf hrung in Angriff genommen werden kann muss der Uebernahmeplan allenfalls angepasst werden 99 5S WERKZEUGUNTERSTUTZUNG 5 1 VORBEMERKUNGEN STAND DER TECHNIK Die F lle von Problemen die bei einer Daten bernahme zu l sen sind sowie die Gr sse der Datenbest nde verlangen nach einer umfassenden Unterst tzung durch leistungsf hige Werkzeuge Beim Einsatz von Werkzeugen ist jedoch stets zu beach ten dass diese die eingesetzten Methoden zwar mehr oder weniger gut unterst tzen niemals aber ersetzen k nnen Da f r den Problemkreis Daten bernahmen bis jetzt nur wenige methodische Grundlagen verf gbar sind ist dementsprechend auch das Angebot an Werkzeugen noch recht schmal und wenig systematisch Nichtsdestotrotz sind aber doch f r eine Reihe von Aufgaben bereits Einzelwerkzeuge kommerziell verf gbar und das Angebot wird rasch gr sser W hrle Krallmann 92 Sitten auer 94 Zvegintzov 94 Aiken 96 Aufgrund der Komplexit t der Probleme die im Rahmen von Daten bernahmen zu l sen sind ist allerdings nicht damit zu rech nen dass in absehbarer Zeit gen gend leistungsf hige hochintegrierte Werkz
76. ant aus den Nutz und Metadaten ableitbar und f r die Benutzer eines betrieblichen Anwendungssystems nicht direkt zug nglich Das Kriterium Form erlaubt eine Unterscheidung von Daten anhand ihrer Struktur Formatierte Daten Menge von gleichartigen Daten f r die sich durch Kate gorienbildung Datentypen bilden lassen Schneider 91 Im Gegensatz dazu wird von unformatierten Daten gesprochen wenn die Struktur nicht sichtbar oder sehr kompliziert und daher nicht formalisiert ist Betrachtet man die Gesamtheit der in einem Betrieb oder f r eine betriebliche Aufga be elektronisch gespeicherten und verarbeiteten Daten so spricht man von einer Datenbasis Datenbasis Gesamtheit aller in einem Betrieb oder f r eine betriebliche Auf gabe elektronisch gespeicherten Daten GRUNDLAGEN UND BEGRIFFE 35 Sind nur die Daten von Interesse die in einem Anwendungssystem oder Teilbereich eine Rolle spielen so wird der Begriff Datenbestand verwendet Datenbestand Menge von elektronisch gespeicherten Daten die einen zu sammengeh renden Teil einer Datenbasis bilden und die in einem bestimmten Anwendungssystem genutzt und nachgef hrt werden In betrieblichen Anwendungssystemen werden typischerweise grosse Mengen forma tierter Daten verarbeitet Insbesondere im Zusammenhang mit einer Daten bernahme ist auch von sehr gros sem Interesse ob die entsprechenden Daten h ufig ge ndert oder vorwiegend nur gelesen werden Auf diese Problemat
77. ausschnittes und f hrt ber mehrere Stufen Realit ts ausschnitt y Konzeptioneller Entwurf M Konzeptionelles Schema y Logischer Entwurf M Logisches Schema y Physischer Entwurf y Physisches Schema Fig 2 11 Datengetriebener Entwurfsprozess Beim konzeptionellen Entwurf erfolgt die Datenbeschreibung weitgehend unabh ngig von spezifischen Anwendungsbed rfnissen und ohne Ber cksichtigung von speziellen Datenbankverwaltungs und Computersystemen Zweck des konzeptionellen Schemas ist eine Beschreibung des Informationsgehaltes eines Datenbestandes und nicht der Speicherungs und Zugriffsstrukturen Konzeptionelle Schemas pr judizieren nichts in Bezug auf eine k nftige Realisierung sie erweisen sich insbesondere auch als sehr n tzlich wenn die Datenverwaltung sp ter mittels konventionellen Dateisystemen und nicht mittels Datenbankverwaltungssystemen realisiert wird F r den konzeptionellen Entwurf gelangen typischerweise Entit ten Beziehungs modelle zum Einsatz Diese verwenden Entit ts bzw Beziehungsmengen als grund legende Modellierungskonstrukte Mit dem Begriff Entit t wird dabei ein Element der realen oder Vorstellungswelt bezeichnet das individuell identifiziert werden kann Mit Beziehungen werden logische Verbindungen zwischen Entit ten allgemeiner zwischen Mengen gleichartiger Entit ten hergestellt GRUNDLAGEN UND BEGRIFFE 41 Im Zusammenhang
78. beitung Oldenbourg 3 Auflage 1991 Scholl Tresch 93 Scholl M H Tresch M Schema Transformation without Database Reor ganization ACM SIGMOD Record Vol 22 Nr 1 1993 S 21 27 Schucan 94 Schucan C Klassifizierung von Daten bernahmeproblemen Diplomarbeit ETH Z rich Institut f r Informationssysteme 1994 LITERATURVERZEICHNIS 155 Schulz 89 Schulz A Software Lifecycle und Vorgehensmodelle Angewandte Infor matik Vol 31 Nr 4 1989 S 137 146 Shet 92 Shet A So Far Schematically Yet So Near Semantically Proc of the Conf on Semantics of Interoperable Database Systems Elsevier Science Publishers 1992 S 283 312 Shet Larson 90 Shet A Larson J Federated Database Systems for Managing Distributed Heterogeneous and Autonomous Databases Computing Surveys Vol 22 No 3 1990 S 183 236 Sittenauer et al 94 Sittenauer C Re Engineering Tools Report Software Technology Support Center 1994 Sneed 91 Sneed H Economics of software Re engineering Software Maintenance Research and Practice Vol 3 1991 S 163 182 Sneed 95 Sneed H Planning the Reengineering of Legacy Systems IEEE Software Vol 12 Nr 1 1995 S 24 34 Stahlknecht Drasdo 95 Stahlknecht P Drasdo A Methoden und Werkzeuge der Programmsanie rung Wirtschaftsinformatik Vol 37 Nr 2 1995 S 160 174 Steedman 93 Steedman D Abstract Syntax Notation One Tutorial and Re
79. ben ber die Daten Metadaten gefunden wer den die sp ter einen Zugriff auf anderen Ebenen erleichtern Zugriff via Benutzerschnittstelle oder externe Systemschnittstelle Sofern keine Zu griffsm glichkeit auf den oben angef hrten Ebenen besteht so bleibt allenfalls noch der direkte Zugriff via Benutzerschnittstelle So kann beispielsweise der Datenverkehr zwischen einer Anwendung und einem Terminal abgeh rt und entsprechend aufbe reitet werden Diese M glichkeit erscheint auf den ersten Blick umst ndlich und nicht sehr erfolgversprechend sie weist jedoch durchaus auch Vorteile auf So ist es damit m glich Daten aus Anwendungssystemen zu extrahieren auf die kein direkter Zugriff auf anderen Ebenen besteht und ber die nebst den Angaben zur Benutzung keine weiteren Informationen verf gbar sind Insbesondere wenn man an riesige weitver teilte Informationssysteme mit vielen heterogenen Datenquellen denkt z B Internet ist der Zugriff auf die an der Benutzerschnittstelle pr sentierten Daten oft die einzige M glichkeit an Daten heranzukommen Diese M glichkeit ist unter Umst nden auch im Zusammenhang mit geschlossenen Systemen anwendbar wenn die Entwickler bewusst keinen Zugriff vorgesehen haben z B bei Finanzinformationssystemen auf die damit verbundenen rechtlichen Aspekte wird im Rahmen dieser Arbeit aber nicht n her eingegangen GRUNDLAGEN UND BEGRIFFE 33 2 10 DATEN DATENBEST NDE DATENARTEN Im Zentrum
80. bener Entwurfsprozess 2 12 Zusammenhang Realit t Schema s Nutzdaten 3 1 3 22 3 3 3 4 3 5 3 6 3 7 3 8 3 9 Daten Forward vs Daten Reverse Engineering Beispieldaten f r visuelle Hypothesenbildung Visuell erkannte Struktur Hypothesen Beispielrelation mit funktionalen Abh ngigkeiten M glichkeiten der Schema Rekonstruktion Verifikation Validation Gegen berstellung Daten bernahme Datenbankintegration Einstufig hierachische Gliederung des Begriffes Datenqualit t Mehrstufig hierachische Gliederung des Begriffes Datenqualit t 3 10 Netzwerkartige Gliederung des Begriffes Datenqualit t 3 11 Klassifikationskriterien f r Daten bernahmen 4 1 Wasserfallmodell schematisch 20 22 23 26 28 29 30 31 33 36 40 42 51 53 54 55 57 59 69 71 71 72 74 82 ABBILDUNGSVERZEICHNIS Fig Fig Fig Fig Fig Fig Fig Fig Fig Fig Fig Fig Fig Fig Fig Fig Fig Fig Fig Fig Fig Fig 4 2 4 3 4 4 4 5 4 6 4 7 4 8 4 9 Sd 5 2 5 3 5 4 5 3 5 6 SE 6 1 6 2 6 3 6 4 6 5 6 6 6 7 Gateways Beispiel eines Wrappers Vorw rts Datengateway R ckw rts Datengateway Reduktion der Uebernahmearbeiten Daten bernahme via Zwischensystem Die zwei Durchf hrungsarten beim MIKADO Modell Phasenfolgedarstellung des MIKADO Modells DART Architektur Ablauf eines Import Vorganges Kombination von SD TP und TD Programmen Realisierungskon
81. ch eine niederlassungs bergreifende Nutzung der Daten erschwert sollen diese Kundendaten insk nftig zentral verwaltet werden Zu diesem Zweck wurde bankintern eine Anwendung entwickelt auf die ber das firmenweite Netzwerk von den einzelnen Niederlassungen aus zugegriffen werden kann Durch diese zentrale Zusammenfassung sollen vor allem folgende Vorteile erreicht werden e Reduktion der Wartungs Installations und Weiterentwicklungskosten e M glichkeit die Daten einfacher niederlassungs bergreifend auswerten zu k nnen z B f r Branchenauswertungen e Vereinfachung von technischen und organisatorischen Massnahmen in den Bereichen Datenschutz und Datensicherheit zentrale Zugriffskontrolle IST Zustand geplant Niederlassung 1 Niederlassung 1 ro lt a H Analyse i programm Kundendaten Niederlassung 2 Niederlassung 2 ir en i Analyse Analyse l zentrale M programm Kundendaten Kunden programm mM datenbank neu l Niederlassung n Niederlassung n P En Eur Analyse H programm Kundendaten Fig 6 6 Ausgangssituation Fallstudie C FALLSTUDIEN 137 6 4 2 Beurteilung der Aufgabe Die Aufgabe wies folgende Eigenschaften auf die die Probleml sung beeinflussten e Zeitverh ltnisse Die Abkl rung war zeitkritisch Der Uebernahmezeitpunkt war relativ kurzfristig angesetzt Die Betriebsaufnahme des Z
82. che Angaben f r eine konkrete Daten bernahme effektiv gebraucht werden Vorhandene Angaben sind oft unzuverl ssig und nicht vollst ndig Bei Legacy Systemen ist man regelm ssig mit falschen und unvoll st ndigen Angaben ber die Datenbest nde konfrontiert Diese Situa tion muss vor Beginn einer Daten bernahme bereinigt werden Durch Analyse mehrerer unabh ngiger Informationsquellen kann die Zuver l ssigkeit einer Information gesteigert werden So lohnt sich bei S Der Begriff Hypothese wird in dieser Arbeit mit der heute in der Wissenschaftstheorie weitverbreiteten Bedeutung ungesicherte Annahme verwendet B ttemeyer 95 78 DATEN RE ENGINEERING spielsweise auch bei Vorliegen eines Schemas eine Ueberpr fung des selben anhand der konkret vorliegenden Daten Dokumentationen sind oft unvollst ndig und nicht auf dem neuesten Stand Hypothese IV Das in Betrieb stehende System ist die zuverl ssigste Informations quelle Eine Analyse eines Datenbestandes kann eine ganze Reihe von Informationen liefern Es ist jedoch sorgf ltig zu unterscheiden was zuf llig nur f r den konkret untersuchten Datenbestand gilt und was allgemeine G ltigkeit hat Hypothese V Werkzeuge sind n tig Zur Ueberpr fung von Hypothesen aber auch zur Bew ltigung von Verwaltung und Darstellung gefundener Infor mationen sowie zur Durchf hrung von Konversions und Korrektur aufgaben m ssen Werkzeuge eingesetzt werden Hypothes
83. che solche Bedingungen hinzukommen In der Regel werden bei einer sol chen Aenderung die bestehenden Daten nicht daraufhin berpr ft ob sie diesen neuen Bedingungen auch gen gen Hier ergibt sich bei einer Daten bernahme ein Pr f und allf lliger Korrekturbedarf e Die Daten eines Ausgangssystems sind unter Umst nden nicht nur in einem sondern in einer ganzen Reihe von Zielsystemen nutzbar wobei sich diese oft stark unterscheiden k nnen F r eine Aufbereitung der Daten f r eine solche Mehrfachnutzung sind geeignete Datenaustauschformate zu finden oder zu defi nieren Eine Daten bernahme in ein solches in der Regel allgemeineres For mat stellt unter Umst nden zus tzliche Anforderungen an die Aufbereitung Das selbe gilt nat rlich auch wenn Daten aus mehreren Systemen zusammengef hrt werden m ssen 14 EINLEITUNG e Da das Problem der Datenaufbereitung und bernahme zeitlich weder mit dem Vorgang der Anwendungsentwicklung inklusive Datenbankentwurf noch mit Wartungsarbeiten zusammenf llt mithin nicht zu den klassischen Software Engineering Aufgaben zu z hlen ist existieren bis jetzt auch nur wenige methodi sche Grundlagen und Werkzeuge zu seiner L sung e H ufig sind solche Daten bernahmen nicht oder nur kurzfristig vorausseh und damit planbar e Die lange Lebensdauer von Anwendungen kann zu grossen Problemen f hren vor allem dann wenn sie nicht schon bei der Entwicklung eingeplant wurde Die
84. chten nicht weiter eingegangen F r die Modellierung von grossen Systemen die mehrere Anwendungssysteme um fassen und die mit den Begriffen f derierte verteilte oder auch Multidatenbanksyste me bezeichnet werden werden gelegentlich noch weitere Ebenen unterschieden Batini et al 86 Shet Larson 90 Auf jeder Ebene k nnen unterschiedliche Beschreibungsmittel zum Einsatz kommen Man spricht in diesem Zusammenhang von sogenannten Datenmodellen oder Daten beschreibungssprachen Datenmodell Formalismus bestehend aus Konstrukten f r die Beschreibung von Daten und einer Menge von Operationen zur Manipulation von Daten F r den Entwurfsprozess auf den verschiedenen Ebenen haben sich im Laufe der Jahre eine Reihe von Datenmodellen besonders bew hrt und in der Praxis durchge setzt So gelangen beispielsweise auf konzeptioneller Ebene vor allem Entit ten Beziehungs Modelle zum Einsatz F r den Entwurfsprozess auf logischer Ebene haben vor allem das hierarchische das netzwerkartige und das relationale Modell eine berragende Bedeutung erlangt wobei anzumerken ist dass nur das relationale Mo dell auf einer fundierten theoretischen Grundlage basiert F r die Beschreibungen auf physischer Ebene gelangen typischerweise Beschreibungsmittel der f r eine Realisie rung konkret eingesetzten Datenverwaltungssysteme zum Einsatz Das hierarchische Modell verdankt seine Bedeutung ausschliesslich dem kommerziellen Datenbankverwal
85. d zur Verf gung stehen m ssen Recherchen k nnen sich ber viele Jahre zur ck erstrecken ein Betrieb zweier Anwendungssy steme aber keine befriedigende L sung f r einen langfristigen Betrieb darstellt war geplant die Vorstossdaten von SWISSBASE in G 1 zu bertragen und den Betrieb der Vorstossanwendung in SWISSBASE aufzugegeben Aufgrund verschiedener sonstiger Anwendungsbed rfnisse f r die GU 1 nicht vorgesehen war sollte mittelfristig auch das Anwendungssystem G 1 durch ein Nachfolgesystem G 2 mit wesentlich erwei terter Funktionalit t abgel st werden Vorst sse Vorst sse SWISSBASE G 1 G 2 in Betrieb in Betrieb in Entwicklung 1 A Uebernahmevariante 1 VUebernahmevariane2 J Fig 6 2 Ausgangssituation Fallstudie A Im Rahmen der vorliegenden Fallstudie sollten die Probleme einer Uebernahme der Daten aus SwissBase in G l oder allenfalls GU 2 seri s abgekl rt und gegebenen falls die Daten bernahme auch effektiv real durchgef hrt werden Die Uebernahme der brigen Daten von GU 1 in GU 2 war nicht Bestandteil dieser Fallstudie sie sollte durch Mitarbeiter der Informatikdienste durchgef hrt werden Da zudem aus Benut zerkreisen sehr unterschiedliche Ansichten ber die Qualit t der Vorstossdaten ge ussert wurden sollte diesem Aspekt bei der Untersuchung besonderes Gewicht beigemessen werden
86. de soviel ver ndert wie n tig ist um die geforderte Aufgabe Fehlerelimination Funk tionserweiterung zu l sen konservatives Vorgehen Bei Re Engineering andererseits kann ein Anwendungssystem durchaus komplett zerlegt und an ders strukturiert wieder neu aufgebaut werden progressives Vorgehen Dabei ist auch eine funktionale Erweiterung eines Anwendungssystems m glich e Technologie Wartungsaktivit ten finden normalerweise mit derselben Tech nologie statt mit der ein Anwendungssystem urspr nglich entwickelt wurde das ist mit ein Grund warum es oft sehr schwierig ist geeignetes Wartungs personal zu finden Re Engineering umfasst typischerweise ein Anheben ei nes alten Anwendungssystems auf den aktuellen Stand der Technik Thurner 90 Dieser Aspekt impliziert auch dass der Einsatz der zur Verf gung stehenden Verfahren und Werkzeuge f r Wartung und Re Engineering sehr unterschiedlich sein kann Sowohl mit Wartung wie auch mit Re Engineering wird das Ziel verfolgt Anwen dungssysteme die in produktivem Betrieb stehen zu pflegen und weiterzuentwickeln Lano Haughton 94 Unter das Re Engineering fallen jedoch weit umfassendere Massnahmen Es ist zu beachten dass Reverse Engineering Techniken nicht nur beim Re Engi neering sondern auch bei der Wartung eine wesentliche Rolle spielen und zwar schon sehr lange und ganz unabh ngig von der Gr sse eines Anwendungssystems Aebi 93 22 GRUNDLAGEN UND BEGRIFFE 2 4 KOM
87. denen die Anwendungsprogramme aufsetzen vgl Fig 2 2 Im folgenden wird das Anwendungssystem aus dem eine Komponente zu berneh men ist Ausgangssystem genannt Das System in dem eine neue Komponente einge f hrt wird wird Zielsystem genannt Ausgangssystem Zielsystem Systeme zwischen denen eine Migration einer Komponente erfolgt In der Literatur wird der Begriff Migration gelegentlich mit unterschiedlicher Bedeu tung verwendet So wird damit beispielsweise manchmal die Abl sung eines ganzen Anwendungssystems Stonebraker Brodie 95 manchmal aber auch nur die Anpas sung an eine ver nderte Plattform Portierung bezeichnet M ller 88 Um solche Unklarheiten zu vermeiden wird in dieser Arbeit anstelle von Migration der synony me Begriff Uebernahme verwendet F r die vorliegende Arbeit stehen Probleme im Zusammenhang mit Datenbest nden und deren Weiterverwendung in einem neuen Anwendungssystem im Zentrum des Interesses Dabei m ssen regelm ssig aufwendige Anpassungsarbeiten durchgef hrt werden F r die Gesamtheit der dabei zu l senden Aufgaben wird im folgenden der Begriff Daten bernahme verwendet 26 GRUNDLAGEN UND BEGRIFFE Eine Abl sung einer Komponente eines Anwendungssystems kann im wesentlichen auf folgende Arten geschehen e Einkauf einer neuen Komponente die gegebenenfalls noch angepasst kon figuriert werden muss e Neuentwicklung einer Komponente e Uebernahme Dabei m ssen in der Regel Anpas
88. die minimal n tigen identifizierenden Merkmale der biblio graphischen Einheiten umfasst Es gibt in der Schweiz verschiedene Gruppen von untereinander verbundenen Bibliotheken sog Bibliotheksverb nde Die Suche nach einer bestimmten bibliographischen Einheit erfolgt normalerweise in den verschiedenen Katalogen In der Regel ist es nicht a priori bekannt ob und wenn ja in welcher Bibliothek eine gesuchte bibliographische Einheit vorhanden ist so dass gelegentlich mehrere Kataloge durchsucht werden m ssen Das Katalogisieren von bibliographischen Einheiten ist ein anspruchsvoller Vorgang der hohes Fachwissen erfordert und weitgehend manuell durchgef hrt werden muss Es sind bei diesem Vorgang eine Reihe von international anerkannten Normen einzu halten ISBD 92 Entsprechend hoch sind deshalb auch die dadurch verursachten Kosten Da eine bibliographische Einheit durchaus in mehreren Bibliotheken vor kommen kann erfolgt heute in diesen F llen typischerweise auch die Katalogisierung mehrfach Ein zentraler Katalog der in den einzelnen Bibliotheken erfassten bibliographischen Einheiten h tte offensichtliche Vorteile Eine Suche k nnte in nur einem Katalog durchgef hrt werden und die Katalogisierungskosten liessen sich durch Vermeiden von Mehrfacherfassungen reduzieren das bedeutet nicht dass die einzelnen Biblio theken nicht immer noch ber einen lokalen Katalog verf gen w rden vielmehr k nnte ein Austausch von Katalogdaten erf
89. dundanzen auf Bei der Entwicklung des im Kapitel 4 vorgestellten Vorgehensmodelles MIKADO wurde versucht diese Konsequenzen m glichst gut zu ber cksichtigen DATEN RE ENGINEERING 79 3 8 3 Lehren f r neu zu entwickelnde Anwendungen Viele der geschilderten Daten Re Engineering Probleme haben ihre Ursache in der Vergangenheit Oft bilden ungen gende Kenntnisse und mangelhafte Technologie zur Zeit der Entwicklung Grund f r heutige Probleme Es ist zu hoffen dass bei der Neu entwicklung von Anwendungssystemen einige der fr her gemachten Fehler nicht wiederholt werden Die Prinzipien von Datenunabh ngigkeit und zentraler Datenver waltung haben sich beispielsweise in der Praxis sehr bew hrt und k nnen eine Daten bernahme wesentlich erleichtern Datenverzeichnisse bilden wenn sie nachgef hrt sind eine wesentliche Hilfe im Zusammenhang mit dem Problembereich Analyse Auch die Anwendung moderner Entwicklungsprinzipien wie sie beispielsweise im Zusammenhang mit dem Datenentwurf erw hnt wurden erleichtern eine k nftige Daten bernahme Zur Unterst tzung des Datenentwurfsprozesses stehen heute auch eine grosse Zahl leistungsf higer Werkzeuge zur Verf gung Es ist allerdings zu beachten dass moderne Technologien nicht automatisch k nftige Abl sungen erleichtern In diesem Zusammenhang sind vor allem objektorientierte Datenbanken kritisch zu beurteilen wird doch dadurch vom erw hnten Prinzip der Datenunabh ngigkeit teilwei
90. e eine Umsetzung eines Schemas das mit dem Netzwerkmodell formuliert wurde auf eines das mit dem hierarchischen Modell formuliert wurde sehr aufwendig Navathe et al 92 Auf der Metaebene sind eine ganze Reihe von Konversionsproblemen zu l sen Dabei spielt die Abstraktionsebene Datentyp Attribut Entit ts bzw Beziehungsmenge eine grosse Rolle Innerhalb dieser Abstraktionsebenen gelegentlich auch ebenen bergreifend m ssen durch Vertauschen Hinzuf gen Weglassen und Ver ndern die n tigen Anpassungen vorgenommen werden Auf der Ebene der Nutzdaten erfolgen einerseits durch Struktur nderungen Anpas sungen die die Bedeutung explizit ver ndern z B wenn der Datentyp eines Attribu tes ge ndert wird es m ssen unter Umst nden aber auch implizite Bedeutungs nde rungen vorgenommen werden Auf diese Probleme wird in Abschnitt 3 5 eingegan gen Im Zusammenhang mit Legacy Systemen ist man oft in der Situation dass nur ein Zugriff auf tiefster Ebene physische Speicherung auf die Daten m glich ist Moderne Datenverwaltungssysteme bieten normalerweise einen Zugriff auf die Daten der von solchen physischen Darstellungseigenheiten weitgehend abstrahiert Es blei ben aber auch in diesen F llen nach wie vor Darstellungsprobleme z B Zeichen satzumsetzungen zu l sen 3 2 4 Analyse Konversion Korrektur Diese sehr unterschiedlichen Aufgaben die bei einer Daten bernahme zu l sen sind lassen sich in folgende dre
91. e 5th Int Conf on Software Engineering and Applications 1992 S 151 160 154 LITERATURVERZEICHNIS Rekoff 85 Rekoff M G On Reverse Engineering IEEE Transactions on Systems Man and Cybernetics Vol 15 Nr 2 1985 S 244 252 Richter 92 Richter L Wiederbenutzung und Restrukturierung oder Reuse Reengi neering und Reverse Engineering Wirtschaftinformatik Vol 34 Nr 2 1992 S 127 136 Ricketts et al 89 Ricketts J A et al Data Reengineering for Application Systems Proc of the Int Conf On Software Maintenance IEEE Computer Society Press 1989 S 174 179 Rossi 95 Rossi R Entwicklung einer Import Export Schnittstelle fiir DART Diplom arbeit ETH Z rich Institut fiir Informationssysteme 1995 Royce 70 Royce W W Managing the Development of Large Software Systems Proceedings of the IEEE WESCON 1970 Sabanis Stevenson 92 Sabanis N Stevenson N Tools and Techniques for Data Remodelling COBOL Applications Proc of the 5th Int Conf on Software Engineering and Applications 1992 S 503 515 Samuelson 90 Samuelson P Reverse Engineering Someone Else s Software Is It Legal IEEE Software Vol 23 Nr 1 1990 S 90 96 Schilling 95 Schilling M Normen und Verfahren fiir die Zeichendarstellung in Compu tersystemen Semesterarbeit ETH Ziirich Institut fiir Informationssysteme 1995 Schneider 91 Schneider H J Hrsg Lexikon der Informatik und Datenverar
92. e Use von Programmen grosse Auf merksamkeit geschenkt Hall 92 Krueger 92 Mit einer Wiederbenutzung von Programmen oder Programmteilen werden in der Regel folgende Ziele verfolgt e Reduktion von Produktionsrisiken durch Nutzen bereits getesteter und be w hrter Teile e Reduktion von Produktionskosten indem Entwicklungskosten durch in der Regel geringere Anpassungskosten ersetzt werden Im Zusammenhang mit Datenbest nden ist die Situation gegen ber Programmen insofern anders als eine Wiedernutzung den Normalfall darstellt Im Rahmen einer Daten bernahme sind in der Regel zwar mehr oder weniger umfangreiche Anpas sungsarbeiten n tig grunds tzlich wird jedoch der vorhandene Datenbestand weiter hin genutzt Die Komplexit t einer Daten bernahme h ngt dabei unter anderem aber davon ab wie sehr sich der Anwendungszweck des Zielsystems von demjenigen des Ausgangssystems unterscheidet Nebst solchen zweckvertr glichen Daten bernahmen k nnen aber gewisse Datenbe st nde nach entsprechenden Anpassungen durchaus auch in mehreren unter schiedlichen Zielsystemen eventuell sogar f r verschiedene Anwendungszwecke genutzt werden Eine solche Mehrfachnutzung ist vor allem dann sehr interessant wenn unter Umst nden hohe Datenerfassungskosten durch geringere Anpassungsko sten ersetzt werden k nnen Solche Aufbereitungen werden im folgenden Mehr fachnutzungen genannt Daten Mehrfachnutzung Aufbereiten
93. e VI Die Datenqualit t l sst sich bei einer Daten bernahme besonders g nstig verbessern Eine Daten bernahme bietet Gelegenheit eine gr ndliche Bereinigung der Daten vorzunehmen und die Datenqualit t anzuheben Datenqualit tsmerkmale m ssen aber so festgelegt wer den dass eine messbare Ver nderung feststellbar ist 3 8 2 Konsequenzen f r Daten bernahmen F r die konkrete Durchf hrung einer Daten bernahme lassen sich aus diesen Hypo thesen insbesondere folgende Konsequenzen ableiten Daten bernahmen sind Probleme die grunds tzlich noch wenig verstanden sind und oft sehr spezielle Eigenheiten aufweisen Diese Unsicherheit muss bei allen Planungen und Entscheidungen ber cksichtigt werden Insbesondere sind die Informationsbed rfnisse und die entsprechende Informationsbeschaf fung sehr genau zu pr fen Bloss W nschbares ist konsequent wegzulassen Eine Daten bernahme muss durch Werkzeuge unterst tzt werden es ist je doch meistens auch mit erheblichen manuell durchzuf hrenden Arbeiten zu rechnen Diese Erkenntnis erschwert vor allem eine zeitliche und finanzielle Planung einer Durchf hrung sehr Die Qualit t der Daten wird nicht besser durch die blosse Uebernahme in ein neues System aber z B dadurch dass vermieden wird Altlasten mit ins neue System zu bertragen Oftmals kann der Ausgangsdatenbestand signifi kant reduziert werden f r eine Verwendung im Zielsystem Legacy Systeme weisen oft grosse Re
94. e enthalten Schemas nicht nur solche von Legacy Systemen typischer weise keine detaillierten Angaben zur Konsistenz Bedeutung und Verwendung der beschriebenen Daten Mit Schemas werden blicherweise nur Strukturinformationen beschrieben 3 3 5 Konsistenz Verifikation Validation Der Nutzen eines Datenbestandes h ngt von sehr verschiedenen Kriterien ab We sentlich ist dabei unter anderem dass die Daten korrekt sind Diese Korrektheit ist allerdings in der Regel kein rein quantitativ berpr fbares Merkmal sondern h ngt wesentlich vom Verwendungszweck der Daten ab Zumindest m ssen die von einem Anwendungssystems verarbeiteten Nutzdaten aber ihrer Beschreibung entsprechen DATEN RE ENGINEERING 59 Damit das gew hrleistet werden kann werden beim Aufbau eines Anwendungssy stems namentlich beim Datenentwurf eine Reihe von Kriterien festgelegt denen die Daten minimal gen gen m ssen damit zwischen Schema und Nutzdaten keine Wider spr che auftreten k nnen Solche Kriterien werden Konsistenzbedingungen genannt Man spricht in diesem Zusammenhang von der Konsistenz eines Datenbestandes Konsistenzbedingungen Kriterien denen ein Datenbestand Nutzdaten und Metadaten gen gen muss um keine inneren Widerspr che aufzuweisen Der Begriff Konsistenz stellt eine Beziehung her zwischen einer Datenbeschreibung und den zugeh rigen Daten Die Daten gelten dann als konsistent wenn sie die in der Beschreibung definierten Ko
95. e urspriingliche Komponente die selbst nicht ver ndert wird nicht mehr sichtbar ist VORGEHENSMODELLE 87 Vorw rts bzw R ckw rtsgateways Abh ngig davon von welchem System aus die entsprechenden Anforderungen und Zugriffe erfolgen spricht man von Vorw rts bzw R ckw rtsgateways Vorw rtsga teways erlauben dem Ausgangssystem auf eine Komponente des Zielsystems zuzu greifen Analog erlaubt ein R ckw rtsgateway den Zugriff vom Zielsystem aus auf eine Komponente des Ausgangssystems Die Wahl eines Vorw rts bzw R ckw rtsgateways h ngt ab von der geplanten Abl sungsreihenfolge der einzelnen Komponenten bzw von der Verf gbarkeit von Kom ponenten des Zielsystems Entwicklungsreihenfolge Wenn beispielsweise zuerst die Datenverwaltungskomponente des Ausgangssystems abgel st werden soll Fig 4 4 m ssen die Daten in das Zielsystem bertragen und die alten Anwendungsprogramme mit Hilfe eines geeigneten Gateways mit der neuen Datenverwaltung verbunden wer den Man spricht dann in diesem Falle von einem Vorw rts Datengateway Benutzer exieine schnitt System Stelle schnitt stelle Verarbeitung tH Daten gt Gatewa N 7 i A Datenverwaltung 7 gt Datenverwaltung Daten bernahme Daten Fig 4 4 Vorw rts Datengateway Vorw rts Daten Gateways bieten den Vorteil dass neu zu entwickelnde Anwendun gen bereits
96. eaktion auf in der Regel unvorhersehbare externe Gr nde m glich sein Ein typisches Beispiel bildet hier der Uebergang von der Warenumsatzsteuer zur Mehrwert steuer in der Schweiz im Jahre 1995 Als Beispiel w re hier der Uebergang auf das metrische System in Grossbritannien zu nennen der im Rahmen der Europ ischen Integration erfolgen muss und der ganz erhebliche Aende rungen an Anwendungssystemen nach sich ziehen wird GRUNDLAGEN UND BEGRIFFE 25 Der Begriff Abl sung f r den gelegentlich auch der Begriff Erneuerung verwendet wird hat folgende Bedeutung Abl sung Ersatz von Teil Komponenten eines Anwendungssystems durch neue mit gleichem oder ver ndertem Funktionsumfang Wird eine vorhandene Komponente so angepasst dass sie in einem neuen Anwen dungssystem m glicherweise mit ge nderter Funktionalit t verwendet werden kann so spricht man von einer Migration oder Uebernahme einer Komponente Migration Uebernahme Gesamtheit von Aufbereitungs und Anpassungsar beiten zur Verwendung einer bestehenden Komponente oder von Teilen da von in einem anderen Anwendungssystem Migrationen d rfen nicht mit Portierungen verwechselt werden Bei einer Portierung werden Daten und Programme eines Anwendungssystems ohne Ver nderung ihrer Funktionalit t auf einer neuen Plattform verf gbar gemacht Das Ausgangssystem bleibt dabei weiterhin in Betrieb Der Begriff Plattform bezeichnet die Ger te und Systemprogramme auf
97. edundanz wird erst dann zu einem Problem wenn sie nicht mehr kontrolliert werden kann Kontrollierte Redundanz wird inner DATEN RE ENGINEERING 67 halb eines Anwendungssystems beispielsweise zur Leistungssteigerung eingesetzt So sind Zugriffsstrukturen Hilfsdaten berlicherweise aus den Nutzdaten abgeleitet aber auch Kopien die zu Sicherheits und Archivierungszwecken erstellt werden bedeuten nat rlich Redundanz Redundanz kann dann zum Problem werden wenn notwendige Daten nderungen nicht mehr in allen betroffenen Daten nachgef hrt werden was zu sogenannten Mu tationsanomalien f hrt Moderne Entwurfsverfahren bieten zwar weitgehende metho dische Unterst tzung zur Elimination oder zumindest Kontrolle von Redundanz beispielsweise Normaliserungsverfahren im relationalen Modell f r praktische Zwecke namentlich zur Vermeidung von Leistungseinbussen m ssen aber oft bei der Realisierung Kompromisse eingegangen werden Im Zusammenhang mit Legacy Systemen ist das Problem besonders genau zu untersuchen wurden doch diese Sy steme im Laufe der Zeit oft mehrfach ge ndert und erweitert so dass man bei solchen Systemen oft mit ganz erheblichen Redundanzen konfrontiert ist Im Rahmen von Datenkorrekturmassnahmen sind jedoch nicht nur Redundanzen im Sinne von Mehrfachspeicherungen derselben Daten zu untersuchen sondern vor allem verschiedene Dateninhalte die dieselben Sachverhalte der Realit t repr sentie ren sogenannte Duplikate
98. ehr genau d h auf der Ebene der einzelnen Attribute zu untersuchen und geeignet zu bersetzen da sonst unter Umst nden im Zielsystem durch falsche Daten erheblicher Schaden entstehen kann Beispiel 1 Unterschiede der verwendeten Einheiten Seien A bzw A Attribute des Ausgangs bzw Zielsystems die Temperaturmesswer te enthalten A Integer 40 A Integer Bei einer Daten bernahme gen gt eine einfache Umsetzung der Zahl 40 nicht da das Zielsystem die entsprechende Temperatur unter Umst nden nicht in C sondern in K erwartet Beispiel 2 Formate Seien A bzw A Attribute des Ausgangs bzw Zielsystems die Kalenderdaten enthal ten A String 23 12 94 gt A Strings Falls das Datumsformat im Zielsystem beispielsweise nicht TT MM JJ sondern MM TT JJ ist muss dies bei einer Daten bernahme selbstverst ndlich angepasst werden DATEN RE ENGINEERING 69 Diese sehr einfachen Beispiele zeigen bereits dass f r eine korrekte Daten bernahme strukturelle Kenntnisse allein nicht reichen Es muss auch Klarheit herrschen ber die Bedeutung und Verwendung der einzelnen Datenobjekte Diese Abgleichprobleme stellen sich nicht nur bei Daten bernahmen sondern auch im Zusammenhang mit dem Aufbau und dem Betrieb von f derativen Datenbanksy stemen In diesem Problemumfeld wird daf r oft der Begriff semantische Hetero genitat verwendet Shet Larson 90 Das Problem ist hier allerd
99. ei Fallstudien ist nach einheitlichem Muster gegliedert um eine Vergleichbarkeit der Ergebnisse zu erleichtern Die Probleme stammen aus drei unterschiedlichen Anwendungsbereichen 6 2 FALLSTUDIE A PARLAMENT 6 2 1 Ausgangslage Problemstellung Im Jahre 1983 nahmen die Informatikdienste der schweizerischen Bundesversamm lung Bundesparlament ein Anwendungssystems in Betrieb das unter anderem f r das Erfassen Speichern und Abfragen von pers nlichen Vorst ssen der einzelnen Ratsmitglieder Postulate Motionen Interpellationen einfache Anfragen einge setzt wurde Diese Vorst sse werden regelm ssig im sogenannten Amtlichen Bulle tin publiziert sind also ffentlich zug nglich Die Daten werden von Mitarbeitern der Parlamentsdienste von Ratsmitgliedern aber auch von Journalisten vor allem f r Dokumentations und Recherchezwecke verwendet Diese Vorstossverwaltung wurde auf einem zentralen Rechner betrieben zusammen mit einer Reihe von anderen Anwendungen Zur Datenverwaltung all dieser Anwen dungen wurde ein Volltext Retrieval System im folgenden mit SWISSBASE bezeich FALLSTUDIEN 119 net eingesetzt Die Datenbest nde der einzelnen Anwendungen sind aber voneinan der unabh ngig Die Benutzung dieser Anwendungen erfolgte von Terminals VT100 Standard oder von Arbeitsplatzrechnern mit Terminalemulationsprogrammen aus Diese sind via Telephon Modem bzw ber ein lokales Netzwerk mit dem System verb
100. eichen Namen von Attributen vereinheitlicht werden oder es k nnen DML Anweisungen analysiert werden um Schl ssel Fremdschl sselbeziehungen zu finden Schemas k nnen auf unterschiedliche Arten dargestellt werden es sind verschiedene graphische bzw textuelle Darstellungsarten implementiert und f r verschiedene Zielsysteme k nnen direkt Datendefinitions und Datenmanipulationsanweisungen generiert werden Die Funktionalit t von DB MAIN geht ganz wesentlich ber diejenige von DART hinaus Da DART im wesentlichen nur ein Ger st bildet das problemangepasst mit entsprechenden Funktionen Diensten zu f llen ist erstaunt das nicht weiter Noch wenig entwickelt sind bei DB MAIN allerdings die Verarbeitungen der Nutzdaten selbst insbesondere erlaubt DB MAIN nicht dieselbe Flexibilit t wie DART beim Frfassen formatierter Daten f r die keine maschinenlesbare Datenbeschreibung zur Verf gung steht DB MAIN stellt zwar f r eine Reihe von weitverbreiteten Aus gangssystemen entsprechende M glichkeiten f r das Erfassen von Datenbeschreibun gen zur Verf gung ist aber nicht so leicht an andere Ausgangssysteme anpassbar wie DART Die Nutzdaten selbst werden in DB MAIN nicht verwaltet Insbesondere stellt DB MAIN keine Analyse und Korrekturfunktionen f r die Nutzdaten zur Verf gung F r die Konversion der Daten werden entsprechende DML Anweisungen generiert diese m ssen aber unabh ngig von DB MAIN auf dem Zielsystem ausgef hrt werd
101. eihe von Problemen vermieden werden Konsistenz berwachung ist jedoch ein aufwendiger Prozess so dass h ufig auf den Einsatz leistungsf higer Methoden verzichtet wird werden muss Zu restriktive Konsistenzbedingungen k nnen ein System auch sehr unhand lich machen Ein Verletzen von Konsistenzbedingungen kann sich in gewissen F llen auch als durchaus sinnvoll und n tig zum Beispiel bei der Ersterfassung eines Da tenbestandes erweisen Auch Datenbest nde sollten gelegentlich wieder auf wohlde finierte Qualit tsmerkmale hin berpr ft werden 81 4 VORGEHENSMODELLE 4 1 VORGEHENSMODELLE FUR DIE ENTWICKLUNG VON ANWEN DUNGSSYSTEMEN Es ist ein allgemein anerkanntes Prinzip dass eine komplexe Aufgabe durch Aufglie derung in Teilaufgaben einfacher beherrschbar wird Diese Aufgliederung hat sich auch im Bereich der Informatik fiir den komplexen Vorgang der Anwendungsentwick lung bew hrt Man spricht in diesem Zusammenhang von sogenannten Vorgehens modellen Einzelne Teilaufgaben werden in diesen Modellen Phasen genannt Im Laufe der Zeit sind eine ganze Reihe solcher Modelle entstanden eine Uebersicht ist beispielsweise in Schulz 89 zu finden Im Zusammenhang mit Anwendungen wobei das Schwergewicht der Betrachtungen h ufig bei den Programmen liegt wird gelegentlich auch vom sogenannten Lebens zyklus und damit zusammenh ngend von Lebenszyklusmodellen gesprochen Damit soll signalisiert werden dass von solchen M
102. eme und Erarbeiten von entsprechenden L sungen unterst t zen Mit DART sollte die M glichkeit geschaffen werden rasch konkrete Er fahrungen zu sammeln Auf Leistungsoptimierungen wurde weitgehend ver zichtet e Ziel 3 Erweiterbarkeit DART sollte nur f r Aufgaben die regelm ssig im Rahmen von Daten bernahmen zu l sen sind namentlich im Problembereich Analyse eine Reihe von Basiswerkzeugen anbieten F r spezielle Aufgaben die nur bei einer ganz bestimmten konkreten Daten bernahme zu l sen sind sollten aber Mechanismen vorhanden sein um diese Basiswerkzeuge einfach erweitern oder kombinieren zu k nnen Auch das Zuf gen von neuen Werk zeugen sollte einfach m glich sein e Ziel 4 MIKADO kompatibel DART sollte das Vorgehensmodell MIKADO unterst tzen das heisst die eigentliche Datenaufbereitung sollte so weit wie m glich losgel st werden von spezifischen Eigenheiten der Ausgangs bzw Zielsysteme e Ziel 5 Praktische Anwendbarkeit Das System sollte anhand von konkreten Praxisproblemen auf seine Tauglichkeit hin berpr ft werden gegebenenfalls unter Inkaufnahme unbefriedigender Laufzeiten e Ziel 6 Flexible Schnittstellen Das System sollte nicht an eine bestimmte Entwicklungssprache gebunden sein sondern wenn m glich allgemeine Schnittstellen f r Erweiterungen anbieten Dieses Zielsystem wurde im Laufe der Arbeit angepasst und erweitert Insbesondere Ziel 5 wurde erst zu einem sp teren Zeitpunkt aufgenommen als
103. emen Das Anwen dungssystem aus dem die Daten stam men bleibt weiterhin in Betrieb Uebergangsver homogen Das Zielsystem ist als Weiterentwick tr glichkeit Uv lung des Ausgangssystems entstanden Uv Bei der Entwicklung des Zielsystems wurde die Uebernahme der Daten bereits eingeplant Die Strukturen der Daten im Ausgangs und Zielsystem unterscheiden sich nur geringf gig inhomogen Das Zielsystem wurde weitgehend oder Un ganz unabh ngig vom Ausgangssystem entwickelt Die Strukturen der Daten im Ausgangs und Zielsystem k nnen sich stark unterscheiden Uebergangsart kontinuierlich Der Uebergang vom Ausgangs ins Ua Ua Zielsystem muss unterbruchsfrei erfol gen Zu jedem Zeitpunkt muss eines der beiden Systeme den vollen Funktions umfang gew hrleisten diskontinuierlich F r die Daten bernahme kann der Be trieb w hrend einer beschr nkten Zeit unterbrochen werden Es ist keine dau ernde Verf gbarkeit von Ausgangs bzw Uag Zielsystem n tig 74 DATEN RE ENGINEERING Kriterium Auspr gungen Zerlegbarkeit Z zerlegbar Ein sinnvoller Betrieb des Zielsystems kann bereits mit einem Teildatenbestand aufgenommen werden Der Datenbe stand des Ausgangssystems kann in Teilbereiche zerlegt werden die einzeln bernommen werden k nnen nicht zerlegbar Der Datenbestand des Ausgangssystems 7 muss als ganzes bernommen werden n Aenderungsgrad dynamisch Die zu bernehmenden Daten werden im A
104. ems kann vor allem aber auch die Kom plexit t der im Einzelfall n tigen Anpassungen an die Zielsysteme reduziert werden Ausgangssystem Zielsystem externe externe Benutzer Su cternt i Benutzer i System schnitt pee schnitt peer schnitt schnitt stelle stelle stelle stelle Zwischensystem Verarbeitung Verarbeitung t Datenverwaltung 2 Datenverwaltung S A Ff Ge Na Fig 4 7 Daten bernahme via Zwischensystem Das Vorgehensmodell MIKADO ist entstanden als Resultat sowohl theoretischer Aebi Largo 94 als auch praktischer Ueberlegungen siehe Kapitel 6 Es stellt al lerdings noch kein etabliertes Vorgehensmodell dar vielmehr soll es als erste Ar beitsgrundlage dienen Es ist zu erwarten dass sich bei Vorliegen weiterer praktischer Erfahrungen es wurde im Rahmen dieser Arbeit dreimal eingesetzt noch wesentliche Aenderungen ergeben werden MIKADO wurde mit dem Ziel entwickelt die Durch f hrung von Daten bernahmen der Problemklasse P Uv Uaa Zz As zu unterst tzen Basierend auf den in Kapitel 3 gezogenen Schlussfolgerungen und praktischen Erfah rungen mit Daten bernahmeproblemen Aebi 93 ergaben sich folgende Anforderun gen an ein Vorgehensmodell e Ausgangssystemunabh ngigkeit Da in vielen Abl sungsprojekten zu Beginn der Arbeiten noch wenig detaillierte Kenntnisse ber das optimale Vorgehen vorhanden sind soll zuerst anhand von gezielten Experime
105. en Insbesondere k nnen damit aber nat rlich nur Konversionen und Korrekturen durch gef hrt werden die in der entsprechenden DML ausdr ckbar sind DB MAIN und DART k nnten sich f r gewisse Probleme gut erg nzen Beispiels weise k nnte DART f r gewisse Ausgangs oder Zielsysteme eine Art Pre bzw Postprocessor f r DB MAIN bilden 118 6 FALLSTUDIEN 6 1 VORBEMERKUNGEN Vorgehensmodelle m ssen ihre Tauglichkeit im praktischen Einsatz unter Beweis stellen Die im Rahmen der vorliegenden Arbeit entwickelte Vorgehensweise wurde deshalb bei der Durchf hrung von drei konkreten Daten bernahmeprojekten aus der Praxis auf ihre Brauchbarkeit hin berpr ft Dabei wurde einerseits bewusst in Kauf genommen dass diese Ueberpr fungen gegebenenfalls auch M ngel und Schw chen zutage f rdern w rden andererseits bot sich damit aber auch die Chance aus realen Problemen Lehren zu ziehen Die drei im folgenden detailliert beschriebenen Fallstu dien wurden im wesentlichen gem ss dem in Kapitel 4 vorgestellten MIKADO Modell durchgef hrt Wo immer m glich und sinnvoll wurden f r konkrete Teilauf gaben Werkzeuge eingesetzt die zum Teil problembezogen erst entwickelt werden mussten Diese problembezogenen Einzell sungen boten dann wiederum Anlass zum Entwurf und zur Weiter Entwicklung von DART Komponenten Fallstudien Vorge hensweise und Werkzeugentwicklung haben sich so zum Teil gegenseitig beeinflusst Die Beschreibung der dr
106. en sind Das in Kapitel 4 vorgestellte MIKADO Modell unterst tzt alle drei Varianten 68 DATEN RE ENGINEERING 3 5 3 Inhaltliche Abgleiche zwischen Ausgangs und Zielsystem Neben den in Abschnitt 3 4 bereits diskutierten strukturellen Anpassungen m ssen bei einer Daten bernahme auch bei kompatiblen Datentypen gelegentlich Darstel lungsunterschiede aufgel st werden Legacy Systeme unterscheiden in der Regel nur eine kleine Zahl verschiedener Datentypen ganze Zahlen Gleitkommazahlen Zei chenketten so dass f r Feinheiten der Darstellung und Speicherung die Daten oft entsprechend formatiert werden Formatierung man findet daf r auch Begriffe wie Sub Typing oder Picture bedeutet dabei eine gewisse Vorschrift der die Darstel lung innerhalb eines Grunddatentyps gehorchen muss Zur Beschreibung aber auch zur Erkennung solcher Formate eignen sich beispielsweise Musterbeschreibungsspra chen und darauf aufbauende Werkzeuge recht gut Aho et al 88 In Legacy Systemen findet man oft f r an sich gleiche Daten eine grosse Zahl unterschiedlicher Formate die auf die entsprechenden Formate des Zielsystems abzubilden sind Neben solchen Formatierungsunterschieden spielen aber auch noch andere Unter schiede eine Rolle die bei einer Daten bernahme zu Korrekturen und Anpassungen der Dateninhalte f hren beispielsweise unterschiedliche Einheiten und Werteberei che Solche feinen Unterschiede sind im Rahmen der Analyse s
107. en zur Beschreibung und Verbesserung von Datenqualit t Semesterarbeit ETH Z rich Institut f r Informationssysteme 1995 Hildebrand 92 Hildebrand K Informationsmanagement Status quo und Perspektiven Wirtschaftsinformatik Vol 34 Nr 5 1992 S 465 471 Hochstrasser 95 Hochstrasser M Entwicklung eines Kernsystems samt Steuerung f r DART Diplomarbeit ETH Z rich Institut f r Informationssysteme 1995 Huh et al 90 Huh Y U et al Data Quality Information and Software Technology Vol 8 No 32 1990 S 559 565 150 LITERATURVERZEICHNIS Hull King 87 Hull R King R Semantic Database Modeling Surveys Applications and Research Issues ACM Computing Surveys Vol 19 No 3 1987 S 201 260 IEEE 91 IEEE Standard Computer Dictionary IEEE Computer Society Press 1991 ISBD 92 ISBD General International Standard Bibliographic Description K G Saur 1992 Janes 93 Janes P Presto Methode und Werkzeug zur Evolution von Datenbankan wendungen Diss ETH Z rich Verlag der Fachvereine Z rich 1993 Joris et al 92 Joris M et al PHENIX Methods and Tools for Database Reverse Engi neering Proc of the Sth Int Conf on Software Engineering and Applications 1992 S 541 551 Kaufmann 94 Kaufmann A Software Reengineering Analyse Restrukturierung und Re verse Engineering von Anwendungssystemen Oldenbourg 284 Seiten 1994 Kim Seo 91 Kim W Seo J Classif
108. endungs Anwendungs Nee i programme programme programme SystemAgframme Systemprogramme Systemprogramme Systemprogramme im Gerate v t Ger te Ger te v Ger te Lad 3 E c ae Uebernahme Fao s en Mehrfachnutzung Fig 2 5 Daten bernahme bzw Datenmehrfachnutzung Mehrfachnutzungen sind aufgrund der zus tzlich zu l senden Probleme h ufig kom plexer als reine Daten bernahmen vor allem dann wenn ein dauernder Abgleich zwischen Ausgangs und Zielsystem en erfolgen muss 2 8 ARCHITEKTUR BETRIEBLICHER ANWENDUNGSSYSTEME Die Architektur eines Anwendungssystems zeigt schematisch die konkret realisierte L sung f r ein betriebliches Problem Trotz der enormen Zahl von im Betrieb stehen den Anwendungssystemen und der grossen Vielfalt von unterschiedlichsten Anwen dungsbereichen m ssen von solchen Systemen regelm ssig die folgenden vier Auf gaben gel st werden e Persistente Speicherung der Daten e Verarbeitung der Daten entsprechend den betrieblichen Anforderungen e Ein Ausgabe Kommunikation mit den Benutzern e Kommunikation mit anderen Anwendungssystemen GRUNDLAGEN UND BEGRIFFE 29 Anhand dieser Gliederung l sst sich folgende Standard Architektur eines Anwen dungssystems entwerfen externe System schnittstelle ES ess seek Sey t t Verarbeitung v Datenverwaltung
109. enhang gestellt werden m ssen Auch auf dieser Ebene k nnen eine ganze Reihe von Problemen entstehen auf die aber im folgenden nicht weiter eingegangen werden soll F r aus f hrliche Beispiele zu diesem Gebiet sei auf Neumann 95 verwiesen Durch sorgf ltigen Entwurf und Realisierung eines Anwendungssystems kann eine Reihe der genannten Probleme vermindert oder sogar ganz vermieden werden Im allgemeinen und namentlich im Zusammenhang mit Legacy Systemen m ssen die angef hrten Problembereiche aber sehr sorgf ltig und fr hzeitig untersucht werden DATEN RE ENGINEERING 49 damit ihr Einfluss auf den Daten bernahmevorgang abgesch tzt werden kann Unter Umst nden kann es sich sogar als n tig erweisen vor der Daten bernahme eine Be reinigung im Ausgangssystem vorzunehmen 3 2 3 Uebergangsprobleme Uebergangsprobleme entstehen dadurch dass sich das Ziel vom Ausgangssystem in mehr oder weniger gravierender Weise unterscheidet Zur Ueberbr ckung dieser Unterschiede muss eine Abbildung zwischen Ausgangs und Zielsystem gefunden werden Uebergangsprobleme lassen sich auf verschiedenen Ebenen lokalisieren Oft sind die im Ausgangs und Zielsystem verwendeten Datenmodelle verschieden Meta metaebene Unterschiedliche Datenmodelle bieten aber meistens auch verschieden m chtige Modellierungskonstrukte an z B Generalisierung Diese unterschiedliche M chtigkeit der Modelle kann zu erheblichen Problemen f hren So ist beispielsweis
110. enn sie durch mehrere unabh ngige Quel len best tigt werden kann Auch wenn entsprechende Dokumentationen des Aus gangssystems vorhanden sind sind diese h ufig nicht vollst ndig nachgef hrt so dass beispielsweise eine zus tzliche Ueberpr fung anhand des in Betrieb stehenden Sy stems sinnvoll sein kann Im folgenden werden unter dem Begriff Daten Reverse Engineering Massnahmen verstanden mit denen versucht wird beispielsweise anhand der konkret vorliegen den Datenbest nde fehlende bzw verlorengegangene Informationen ber die Struktur und Eigenschaften des zu bernehmenden Datenbestandes zu rekonstruieren Das Ziel ist dabei eine f r ein konkret vorliegendes Daten bernahmeproblem gen gend umfassende Beschreibung eines Datenbestandes zu gewinnen Ein Datenbestand repr sentiert immer nur ein Abbild der Realit t zu einem ganz bestimmten Zeitpunkt Die durch die Analyse eines Datenbestandes gewonnenen Angaben gelten deshalb grunds tzlich auch nur f r dieses eine Abbild Eine Ablei tung allgemein g ltiger Eigenschaften muss deshalb mit grosser Vorsicht erfolgen Es ist bei allen Untersuchungen zu unterscheiden zwischen Eigenschaften die m glicherweise zuf llig f r eine bestimmte Auspr gung eines Datenbestandes gelten und solchen die aufgrund der Implementierung des Anwendungssystems f r alle m glichen Auspr gungen G ltigkeit haben beispielsweise weil sie im Rahmen der Konsistenzsicherung im laufenden Betrieb s
111. epasst ist und die alle Phasen einer Daten bernahme abdeckt Diese Architek tur wurde auch mit einer Reihe von konkreten Werkzeugen realisiert Architektur und Werkzeuge sind in Kapitel 5 beschrieben Sowohl das Vorgehensmodell als auch die Werkzeuge wurden im Rahmen von drei konkreten Projekten aus der Praxis auf ihre Brauchbarkeit hin berpr ft Eine aus f hrliche Beschreibung der einzelnen Problemstellungen dieser drei Fallstudien der erzielten Resultate und der daraus abzuleitenden Konsequenzen ist in Kapitel 6 zu finden Die Arbeit schliesst in Kapitel 7 mit einer Beurteilung der Resultate und einem Aus blick auf weiterf hrende Arbeiten und offene Fragestellungen 18 2 GRUNDLAGEN UND BEGRIFFE 2 1 VORBEMERKUNGEN Ungef hr ab Mitte der achtziger Jahre tauchten auf dem Gebiet des Software Engineering eine Reihe von neuen Begriffen auf Re Engineering Re Use Re Documentation Re Design Re Structuring Re Specification Charakteristisch f r all diese Begriffe ist dass sie aus einer Kombination der Vorsilbe Re und einem bereits bestehenden Begriff gebildet werden Die Vorsilbe Re nochmals von neuem wieder deutet an dass diese Begriffe T tigkeiten umschreiben die bereits ausge f hrt wurden aber aus irgend einem Grunde erneut gemacht werden m ssen Obwohl nicht gleich gebildet geh rt auch der Begriff Reverse Engineering zu dieser Gruppe Da in dieser Arbeit der Begriff Daten Re Engineering
112. ering 100 WERKZEUGUNTERSTUTZUNG einsetzbaren Methoden bekannt sind oder aufgrund des Charakters der Aufgabe auch gar nie zu erwarten sind Dazu sind beispielsweise Datenkorrekturaufgaben oder Probleme im Zusammenhang mit dem Abgleich unterschiedlicher Semantik bei hete rogenen Datenquellen zu z hlen In sehr vielen F llen werden die Uebernahmever antwortlichen deshalb nicht darum herum kommen f r eine konkrete Ausgangslage entsprechende Werkzeuge zuerst problemangepasst zu entwickeln Auch wenn die Entwicklung in diesem Bereich recht st rmisch verl uft bleiben noch wesentliche Forschungsaufgaben zu l sen und bei vielen Aufgaben muss nach wie vor noch manuell eingegriffen werden Some tasks e g dealing with semantic interoperability schema integration data reengineering are not ultimately amenable to automation Considerable human interaction and decision making is required Much research has to be done to understand these areas let alone to produce tools to effectively ad dress them For most legacy IS migration steps there are almost no adequate tools or techniques Those that exist do not scale up to meet the challenges posed in the understanding decomposition integration or recomposition design development maintenance or evolution of large scale ISs Brodie Stonebraker 95 Die heute kommerziell verf gbaren Werkzeuge sind h ufig schlecht integrierbar Sie sind auch oft auf spezielle Probleme zugesc
113. esorgt wird und sehr unterschiedlich verl uft W hrend Grossanwendungen typischerweise von betriebsinternen Informatikabteilungen her DATEN RE ENGINEERING 45 gestellt und gepflegt werden erfolgt die Herstellung von Kleinanwendungen haupt s chlich durch selbst ndige in der Regel kleinere Informatikanbieter Viele dieser Anbieter sind selbst erst seit wenigen Jahren am Markt Ein Erfahrungs und Informa tionsaustausch zwischen diesen beiden Welten findet praktisch nicht statt Trotzdem findet man bei beiden Gruppen von Anwendungssystemen auch eine Reihe von gemeinsamen Eigenschaften e Ueber ihre Entwicklung und Funktionsweise liegen oft keine oder nur l cken hafte Angaben vor e Thre Pflege und Weiterentwicklung verursacht hohe Kosten e Thr Einsatz ist von grosser Bedeutung f r den entsprechenden Betrieb e Sie sind weitgehend monolithisch aufgebaut e Sie haben keine oder nur rudiment re Schnittstellen zu Nachbarsystemen geschlossene Systeme e Die urspr nglichen Entwickler sind nicht mehr verf gbar Anwendungen aus beiden Gruppen sind Kandidaten f r eine Abl sung Bemerkens wert im Zusammenhang mit dem Problem Daten bernahme ist dass Sch tzungen dahin gehen dass heute das gesamte von Kleinanwendungen verarbeitete Datenvolu men dasjenige der Grossanwendungen bei weitem bersteigt Carlyle 90 Piatetsky Shapiro Frawley 93 Namentlich sogenannte Spreadsheet Programme aber auch einfache Da
114. etriebsbereit F r diese Uebernahme sind keine manuellen Arbeiten mehr n tig Sie kann erfol gen sobald die Korrekturarbeiten abgeschlossen sind Bei sp ter allenfalls noch gew nschten Korrekturen kann dieser Schritt problemlos so oft wie gew nscht wiederholt werden 128 FALLSTUDIEN S mtliche Unterlagen und Werkzeuge wurden an die Informatikdienste bergeben Die Betriebsaufnahme des Zielsystems ist f r 1996 geplant Die im Rahmen dieser Fallstudie durchgef hrten Untersuchungen dauerten rund ein Jahr Die weitaus aufwendigste Phase bei diesem Uebernahmeproblem war die Vorun tersuchung 6 2 5 Beurteilung Vorgehen Aufgrund der urspr nglich sehr unsicheren Informationen ber die Datenqualit t und der nur l ckenhaft vorhandenen Informationen ber das Ausgangssystem hat sich die aufwendige Voruntersuchung gelohnt Sie lieferte konkrete Entscheidungsgrundlagen nicht nur f r den grunds tzlichen Durchf hrungsentscheid sondern insbesondere auch f r die Wahl des Zielsystems Die Aufbereitung der Daten innerhalb eines Zwischensystems hat sich in diesem Falle als ganz besonders sinnvoll erwiesen war doch zu Beginn der Arbeiten nicht mit dem pl tzlichen Wechsel des urspr nglich geplanten Zielsystems zu rechnen Dieser Ziel systemwechsel hat die laufenden Arbeiten praktisch gar nicht gest rt oder verz gert Sobald die entsprechenden Korrekturarbeiten abgeschlossen sind kann der nun in relationaler Form vorliegende Date
115. euge sogenannte CARE Werkzeugumgebungen zur Verf gung stehen werden Heute gelangen typischerweise je nach Problemstellung eine Reihe von meist unabh ngigen Einzelwerkzeugen zum Einsatz Die Aufgaben die im Rahmen einer Daten bernahme zu l sen sind lassen sich hin sichtlich der heute verf gbaren Werkzeugunterst tzung grob in drei Klassen gliedern Zur ersten Klasse sind dabei Aufgaben zu z hlen die seit vielen Jahren Gegenstand intensiver Foschung bildeten und f r die deshalb heute auch entsprechende L sungs methoden bekannt sind Stand der Technik Hierzu z hlen vor allem Aufgaben im Zusammenhang mit der Neuentwicklung von Anwendungen z B f r die Bereiche Datenmodellierung und Datenbankentwurf Daf r sind bereits eine Reihe sehr lei stungsf higer Werkzeuge verf gbar Eine zweite Klasse bilden jene Aufgaben zu de ren L sung erst in j ngerer Zeit vornehmlich im Rahmen von Forschungsarbeiten Methoden entwickelt wurden Stand der Forschung Entsprechende Werkzeuge befinden sich deshalb noch weitgehend im Prototypstadium Zu dieser Klasse z hlen insbesondere viele Aufgaben aus dem Bereich Daten Reverse Engineering so z B das Problem der Schema Rekonstruktion F r diese Klasse von Aufgaben w chst das Angebot an Werkzeugen aber zur Zeit am schnellsten Zur dritten Klasse von Aufga ben sind schliesslich jene zu z hlen zu deren L sung noch keine auf breiter Basis 16 CARE Computer Aided Re Engine
116. everse Engineering lterer Systeme befassen sind erstaunlich selten zu finden Als Beispiele w ren etwa Winans Davis 91 Nielsson 85 oder Davis Arora 85 zu nennen die sich mit dem hierarchischen Datenbankverwaltungssystem IMS bzw mit COBOL Dateien befassen Nebst diesen Arbeiten die sich mit einzelnen Systemen befassen sind vor allem aber allgemeinere Ans tze zum Daten Reverse Engineering von Interesse Hier wurden erst in den letzten paar Jahren vermehrte Anstrengungen unternommen Dabei haben vor allem die zwei Projekte REDO Van Zuylen 93 Sabanis Stevenson 92 und PHENIX Joris et al 92 Hainout et al 93 das Projekt PHENIX ging sp ter in das Projekt DB MAIN ber siehe auch Kapitel 5 grosses Interesse hervorgerufen Das REDO Projekt konzentriert sich dabei im wesentlichen auf Reverse und Re Engineering von COBOL Anwendungen Programme und Daten w hrend DB MAIN sich nur mit Daten Reverse Engineering befasst und f r unterschiedliche Ausgangssysteme eingesetzt werden kann Auff llig bei all den genannten Arbeiten ist dass die vorgeschlagenen Methoden eine hohe Interaktion mit Benutzern verlangen Viele basieren zudem auf restriktiven Annahmen ber das Ausgangssystem was ihre praktische Anwendbarkeit teilweise stark einschr nkt Es darf auch nicht vergessen werden dass f r eine Daten bernahme wesentlich mehr an Informationen ben tigt wird als gemeinhin in Form von Schemas festgehalten ist Insbesonder
117. f r Arbeitsplatzrechner und Workstation Um gebungen Sie weisen eine Reihe der folgenden Merkmale auf Sie wurden erst im Laufe der letzten paar Jahre entwickelt Sie sind eher klein einige zehntausend Zeilen Programmcode und oder Standardprogramme und Datenbest nde von einigen Dutzend MByte Gr sse Die Grundprogramme inkl Werkzeuge wurden meistens eingekauft Sie wurden mit Werkzeugen entwickelt die oft nicht mehr verf gbar sind weil die entsprechenden Werkzeughersteller wieder vom Markt verschwunden sind z B 4GL Entwicklungsumgebungen Man findet eine breite Palette von sehr unterschiedlichen Werkzeugen Ihre Datenverwaltung basiert auf Dateisystemen oder einfachen Datenverwal tungssystemen dBASE ACCESS 4th Dimension EXCEL FoxPro Sie werden auf kleinen und mittleren Rechnern betrieben die allenfalls mit einander ber ein Netzwerk verbunden sind Ihr Funktionsumfang ist eher beschr nkt Es existieren in einem Betrieb f r sehr viele solcher kleinen Anwendungsbereiche eigene Systeme Insel l sungen Die Zahl der Benutzer des einzelnen Systems ist gering Obwohl viele dieser Kleinanwendungen erst seit wenigen Jahren im Einsatz stehen stellt man mit Erstaunen fest dass aus Fehlern fr herer Entwicklungsvorhaben im Bereich der Grossanwendungen oft nicht viel gelernt wurde Dies hat seinen Grund im wesentlichen darin dass die Herstellung von Gross und Kleinanwendungen von v llig anderen Leuten b
118. f auf die zu bernehmenden Daten erfolgen kann Typischerweise treten gewisse Darstellungsprobleme auf h heren Ebenen seltener oder gar nicht auf da bereits eine entsprechende Umsetzung auf tieferen Schichten erfolgt ist So ist es beispielsweise f r die Uebernahme von numerischen Daten einfacher diese zuerst in eine textuelle Darstellung Zeichenkette berzuf hren und erst dann zu bernehmen Es darf je doch nicht bersehen werden dass in vielen F llen nur ein Zugriff auf Ebene des Betriebssystems m glich ist so dass diesen Umsetzungsproblemen Beachtung ge schenkt werden muss 3 4 3 Datenobjektidentifikation Auf h heren Abstraktionsebenen besteht eines der Hauptprobleme im Feststellen welche Datenobjekte des Ausgangssystems mit welchen Datenobjekten des Zielsy stems in Uebereinstimmung zu bringen sind Unter dem Begriff Datenobjekt soll dabei im folgenden die je nach Betrachtungsebene interessierende Teilmenge des zu bernehmenden Datenbestandes verstanden werden Attribute Entit ten Entit ts mengen Dabei sind vorab die bereits in Abschnitt 3 2 2 skizzierten Ausgangssy stemprobleme zu l sen d h es muss Klarheit herrschen ber Struktur und Bedeutung der Datenobjekte des Ausgangssystems Diese Aufgabe kann sich im Einzelfall als ausgesprochen schwierig herausstellen sie muss jedoch gel st werden damit die Daten im Zielsystem sinnvoll verwendet werden k nnen Diese Objektidentifikation erfordert immer auch Anwendun
119. ference Tech nology Appraisals Ltd 171 Seiten 1993 Stonebraker 84 Stonebraker M Adding Semantic Knowledge to a Relational Database System In J W Schmidt et al On Conceptual Modelling Springer 1984 S 333 356 Tanenbaum 92 Tanenbaum A S Computer Netzwerke 2 Auflage Wolfram s Verlag 801 Seiten 1992 156 LITERATURVERZEICHNIS Thurner 90 Thurner R Hrsg Reengineering Ein integrales Wartungskonzept zum Schutz von Software Investitionen Strategie Methoden Werkzeuge Ange wandte Informationstechnik AIT Hallbergmoos 251 Seiten 1990 Tsichritzis Lokovsky 77 Tsichritzis D Lochovsky F Data Base Management Systems Academic Press 388 Seiten 1977 Ukkonen 85 Ukkonen E Algorithms for Approximate String Matching Information and Control Vol 64 1985 S 100 118 UNICODE 95 The Unicode Consortium The UNICODE Standard Worldwide Character Encoding Version 1 1 2 Auflage Addison Wesley 1995 UNIMARC 94 UNIMARC Manual Bibliographic Format K G Saur 2 Auflage 1994 Van Zuylen 93 Van Zuylen H J The REDO Compendium John Wiley amp Sons 405 Seiten 1993 Ventrone Heiler 91 Ventrone V Heiler S Semantic Heterogeneity as a Result of Domain Evolution SIGMOD Record Vol 20 No 4 1991 S 16 20 Wang et al 93 Wang R et al Data Quality Research A Framework Survey and Analysis MIT Sloan School of Management 43 Seiten 1993 Ward et al 89
120. g Durchf hrung Dienst Dieses sehr einfache Konzept hat den wesentlichen Vorteil dass fast keine Anforde rungen an die Entwicklung von Diensten gestellt werden sie m ssen nur auf die Kernsystemfunktionen zugreifen k nnen eine F higkeit die aber jede Anwendung unter dem gew hlten Betriebssystem sowieso haben muss Nachteil dieses Konzeptes ist die fehlende Kontrolle Es ist m glich einen Dienst mit unpassenden Parametern aufzurufen z B wenn er mit falschen Parametertypen registriert wurde was nat rlich zu schweren St rungen f hren muss Die Verantwor tung f r eine konsistente Dienstverwendung liegt also einerseits beim Dienst Entwickler andererseits aber auch beim Dienst Benutzer Diese Nachteile wurden f r das Experimentiersystem in Kauf genommen Die Dienste wurden in Analyse Konversions Korrektur und Hilfsdienste gegliedert Diese Unterteilung ist jedoch rein organisatorischer Art um eine bersichtlichere Verwaltung zu erreichen Technisch gesehen besteht kein Unterschied zwischen diesen Dienstarten F r das Experimentiersystem wurden einige Dienste real implementiert Details hierzu sind in Odendahl 95 und Pfenninger 95 zu finden Da sich insbesondere einige der Analysedienste im praktischen Einsatz als recht n tzlich erwiesen haben wurden sie dahingehend erweitert dass sie auch ohne das Kernsystem einsetzbar sind 5 8 ERFAHRUNGEN WEITERF HRENDE ARBEITEN Die grunds tzliche Anwendbarkeit von DAR
121. g und f r andere Zwecke zu wenig Rechnung getragen Eine Datenmehrfachnutzung unterscheidet sich unter Umst nden 14 Das Zeichen bezeichnet ein sogenanntes Platzhaltersymbol don t care Symbol An seiner Stelle kann eine beliebige Auspr gung des entsprechenden Kriteriums eingesetzt wer den 15 MIKADO ist der Name eines Unterhaltungsspieles bei dem es darum geht aus einem Haufen hingeworfener St bchen ein St bchen nach dem anderen zu entfernen ohne dabei die brigen St bchen zu bewegen Die einzelnen St bchen sind durch Farben unterschiedlich markiert und repr sentieren unterschiedliche Punktzahlen Gewisse St bchen d rfen zur Wegnahme anderer zu Hilfe genommen werden Werkzeuge Es gewinnt diejenige Spielerin die unter diesen Bedingungen am meisten Punkte sammelt 90 VORGEHENSMODELLE stark von einem klassischen Uebernahmeproblem insbesondere dann wenn die Daten in einem Zielsystem f r wesentlich ver nderte Zwecke gebraucht werden F r eine Datenmehrfachnutzung kommen h ufig Datenbest nde in Frage die in sich abgeschlossen und nachgef hrt sind und ber eine l ngere Zeit nur wenigen Aende rungen unterworfen sind d h vor allem Stammdaten Eine solche Mehrfachnutzung legt die Idee nahe die Daten nicht direkt von einem Ausgangs in ein Zielsystem zu bertragen sondern sie zuerst in einem Zwischensy stem aufzubereiten konvertieren korrigieren und erst anschliessend in die entspre chenden
122. g von anderen Entwicklungswerk zeugen Dieser Anlauf konnte 1995 erfolgreich abgeschlossen werden Die Entwick lung von DART wurde durch eine Reihe von Studentenarbeiten unterstiitzt Als Entwicklungsplattform fiir DART wurden Arbeitsplatzrechner eingesetzt die unter dem Betriebssystem MS DOS Windows betrieben wurden Die einzelnen Arbeitsplatzrechner waren tiber ein Netzwerk mit einem zentralen Dateiserver ver bunden der unter UNIX betrieben wurde Fiir den ersten Anlauf gelangten als Ent wicklungsumgebung und Datenverwaltungskomponenten Produkte der Firma Pro gress zum Einsatz Es handelte sich dabei sowohl um ein relationales Datenbanksy stem als auch um ein Paket von Entwicklungswerkzeugen Editor Interpreter in deren Mittelpunkt eine 4 Generationssprache steht Mitentscheidend f r die Wahl dieser Werkzeuge war dass sie f r eine grosse Zahl von Plattformen verf gbar sind was eine sp tere Portierung von DART erleichtert h tte Es handelt sich bei diesen Werkzeugen um Produkte die weltweit in grossen St ckzahlen im Einsatz sind De taillierte Erfahrungen mit diesen Werkzeugen sowie Resultate von Leistungsmessun gen sind in Schucan 94 zu finden F r den zweiten Anlauf wurde der Gedanke der Portierbarkeit fallen gelassen Ent wickelt wurde mit Visual Objects und Delphi Visual Objects ist der Name einer Entwicklungsumgebung die von der Firma Computer Associates vertrieben wird Im Zentrum steht eine Sprache die aus der
123. gebenen Kontenrahmen kundenspezifisch zu erweitern es war zwar ein Kon tenplan mit dreistelligen Kontonummern vorgegeben dieser konnte jedoch individuell durch vierstellige Konten erg nzt werden F r diese vierstelligen Konten bestanden jedoch weder f r die Numerierung noch f r die Bezeichnung irgendwelche Vorschrif ten Das f hrte dazu dass buchhalterisch identische Sachverhalte bei verschiedenen Kunden ber ganz verschiedene Konti verbucht wurden Diese Unterschiede liessen sich nicht automatisch erkennen und aufl sen und ein manuelles Verfahren stand nicht zur Diskussion Auf eine Uebernahme dieser Kontowerte musste deshalb ver zichtet werden was den Nutzen der Daten im Zielsystem aber deutlich einschr nkt Eine weitere Schwierigkeit ergab sich dadurch dass die von der Bank vorgegebenen Kontenpl ne des Ausgangs und Zielsystems sehr unterschiedlich aufgebaut sind Da beim Entwurf des Zielsystems keine R cksicht auf die vorhandene Anwendung ge nommen wurde insbesondere hatte man sich nie mit dem Gedanken einer Daten bernahme besch ftigt bestanden zwischen den beiden Systemen erhebliche Abwei chungen wie gewisse Sachverhalte verbucht wurden Nach diversen Abkl rungen gelang es jedoch eine eindeutige Abbildung zu finden 140 FALLSTUDIEN Aufbereitung f r das Zwischensystem Aufbereitung im Zwischensystem Aufberei tung f r das Zielsystem Aufgrund der im Rahmen der Voruntersuchung gewonnenen Erkenntnisse wurde ei
124. gsprobleme Daten bernahmem glichkeiten klassifiziert werden e Haben Daten auch einen sog Lebenszyklus e Was sind m gliche Ursachen und Ausl ser f r eine Daten bernahme e Welche Kriterien k nnen einen Durchf hrungsentscheid beeinflussen e Wie kann der Daten bernahmeprozess in einzelne Schritte gegliedert werden e Was sind m gliche Strategien f r eine Daten bernahme e Sind Vorgehensmodelle bekannt e Wo und mit welchen Werkzeugen kann der Daten bernahmeprozess unter st tzt werden e Sind im Rahmen von konkreten Daten bernahmen gemachte Erfahrungen f r Entwurf Betrieb und Abl sung von anderen Anwendungssystemen nutzbar Die vorliegende Arbeit konzentriert sich auf die Behandlung von Problemen im Zu sammenhang mit formatierten allenfalls auch einfach formatierbaren Daten wie sie gerade im betrieblichen Umfeld sehr h ufig anzutreffen sind Probleme im Zusam menhang mit unformatierten oder komplexer strukturierten Daten beispielsweise Text Bild und Tondaten werden nicht behandelt 1 3 HAUPTRESULTATE GLIEDERUNG DER ARBEIT Daten bernahmen sind in der Regel anspruchsvolle Aufgaben die nicht nur komplexe technische und anwendungsseitige Probleme stellen sondern auch eine Reihe von Schwierigkeiten auf der Ebene der Projektf hrung bieten Die vorliegende Arbeit versucht verschiedenen Problemkreisen gerecht zu werden Das Schwergewicht der Betrachtungen liegt bei den Nutzdaten 16 EINLEITUNG Die Resultate
125. gssysteme in denen einzelne Komponenten oder Teile davon im Laufe der Zeit durchaus ersetzt werden nicht selten das infrastrukturelle R ckgrat einer Firma und k nnen aus Kosten und Komplexit tsgr nden nur mit M he ersetzt werden Betrachtet man nun aber die Nutzungsdauer von Daten so ist festzustellen dass diese bei weitem die langlebigste Komponente bilden die nicht selten w hrend mehreren Jahrzehnten genutzt wird Nebst technischen und konomischen Gr nden spielen daf r oftmals auch gesetzliche Grundlagen eine Rolle z B die Aufbewahrungspflicht von Buchhaltungsdaten Daten Anwendungsprogramme gt Anwendungsprogramme Systemprogramme Systemprogramme Systemprogramme Standardprogramme Standardprogramme Standardprogramme Hardware Hardware Hardware Hardware Hardware Hardware Hardware Zeit Fig 2 3 Nutzungsdauer einzelner Komponenten eines Anwendungssystems 24 GRUNDLAGEN UND BEGRIFFE Diese unterschiedlichen Nutzungsdauern der einzelnen Komponenten die ja ber Schnittstellen miteinander verbunden sind f hren nat rlich auch zu unterschiedli chen Abl sungszeitpunkten und damit auch regelm ssig zu entsprechenden Anpas sungsproblemen 2 6 ABL SUNG UND MIGRATION EINZELNER KOMPONENTEN Sowohl bei Wartungs als auch bei Re Engineering Entscheiden ist man regelm ssig mit dem Zielkonflikt konfrontiert einerseits ein Anwendungssystem m glichst lange stabil und kosteng nstig zu betreiben es aber
126. gssysteme besitzen oft eine Reihe von implementationsspezifi schen Eigenschaften die sich im Laufe der Zeit oft aufgrund von Sachzw ngen die aus heutiger Sicht nicht mehr detailliert nachvollziehbar sind in weitgehend unkon trollierter Weise entwickelt haben Mit dem in dieser Arbeit vorgeschlagenen Vorge hensmodell wird diesem Umstand dadurch Rechnung getragen dass versucht wird die Daten von solchen unerw nschten Eigenheiten der Darstellung und Speicherung zu befreien und in kontrollierter Weise in ein Zwischensystem berzuf hren wo die Aufbereitung der Daten vorgenommen werden kann Dies geschieht in einem ersten Schritt noch ohne Ber cksichtigung von speziellen Darstellungs und Speiche rungseigenheiten des Zielsystems Erst wenn die notwendigen Aufbereitungsarbeiten abgeschlossen sind werden die Daten in das entsprechende Zielsystem bernommen Diese Vorgehensweise bietet eine Reihe von Vorteilen beispielsweise wenn die Datenbest nde in verschiedenen Zielsystemen genutzt werden sollen oder wenn zur Zeit der Uebernahme das Zielsystem noch gar nicht in Betrieb ist Die Beschreibung dieses Vorgehensmodelles ist in Kapitel 4 zu finden Werkzeugunterst tzung Der konkrete Nutzen eines Vorgehensmodelles h ngt im praktischen Einsatz auch von einer vern nftigen Unterst tzung durch Werkzeuge ab In der vorliegenden Arbeit EINLEITUNG 17 wird eine Werkzeugarchitektur entworfen die auf das vorgeschlagene Vorgehensmo dell ang
127. gswissen In der Regel kann die Bedeutung einzelner Datenobjekte nur erkannt werden wenn eine Beziehung zu andern bereits bekannten Objekten hergestellt werden kann Obwohl gerade im Zusammenhang mit der Inte gration heterogener Datenbanken ein ganz erhebliches Interesse sowohl an einer weitgehend automatischen Objekterkennung als auch an einer Aufl sung allf lliger Bedeutungskonflikte besteht sind auf diesem Gebiet erst entt uschend wenig Resulta te vorhanden Lim et al 93 Garcia Molina et al 94 Hinzu kommt dass die vorge DATEN RE ENGINEERING 65 schlagenen Methoden auf Voraussetzungen an die zu integrierenden Systeme basie ren die bei Legacy Systemen nicht gegeben sind Es bleibt die unbefriedigende Er kenntnis dass sowohl das Erkennen als auch das Abgleichen der Datenobjekte weit gehend manuell zu erfolgen hat eine Erkenntnis die sich auch anderswo durchzuset zen scheint verzichten doch neuere Arbeiten auf die Forderung nach einer vollst ndi gen Automatisierung dieser Arbeiten und versuchen die Probleme durch Einbezug der Benutzer anzugehen Garcia Molina et al 95 3 4 4 Konversionskonflikte Ist die Bedeutung eines Datenobjektes im Ausgangs bzw Zielsystem bekannt und eine Abbildung sinnvoll so kann unter Umst nden eine Konversion erfolgen Eine solche Konversion kann sich in einfachen F llen in einem reinen Kopiervorgang ersch pfen oft sind jedoch auch erhebliche Umstrukturierungen n tig Insbesondere wenn g
128. h Int Conf on Data Engineering 1995 S 251 260 Gora Speierer 90 Gora W Speierer R ASN 1 DATACOM 223 Seiten 1990 Gredley Hopkinson 90 Gredley E Hopkinson A Exchanging Bibliographic Data Library As sociation Publishing Ltd 329 Seiten 1990 LITERATURVERZEICHNIS 149 G nauer Manus 91 G nauer J Manus W Austausch komplexer Datenbank Objekte in einer heterogenen Workstation Server Umgebung In Appelrath H J Hrsg Datenbanksysteme in Biiro Technik und Wissenschaft Springer Fachberichte Nr 270 1991 S 140 160 Habermann Leymann 93 Habermann H J Leymann F Repository Oldenbourg 294 Seiten 1993 Hainout et al 92 Hainout J L et al Contribution to a Theory of Database Reverse Engi neering Proc of the Sth Int Conf on Software Engineering and Applications 1992 S 161 170 Hainout et al 93 Hainout J L et al Transformation based Database Reverse Engineering Proc of the 12th Int Conf on the Entity Relationship Approach Springer Lecture Notes in Computer Science Vol 823 1993 S 364 375 Hainout et al 95 Hainout J L et al Requirements for Information System Reverse Engi neering Support Proc of the 2nd Int Conf on Reverse Engineering IEEE Computer Society Press 1995 S 134 145 Hall 92 Hall P A V Software Reuse and Reverse Engineering in Practice Chap man amp Hall 584 Seiten 1992 Hasler 95 Hasler D Quantitative Method
129. haft eines Datenbestandes best tigt werden kann Hypothesenpr fung Eine weitgehend automatische Rekonstruktion verlorengegangener Informationen ist ein grunds tzlich w nschbares Ziel sofern diese Automatisierung nicht mit unver n nftigem Aufwand zu erkaufen ist Anhand folgender zwei Beispiele soll jedoch verdeutlicht werden dass nicht alles was grunds tzlich automatisierbar ist auch zu brauchbaren Ergebnissen f hrt Insbesondere ist in vielen F llen eine halbautomati sche L sung das heisst eine maschinelle Unterst tzung eines Benutzers einer vollau tomatischen L sung deutlich berlegen Im folgenden wird daf r der Begriff benut zerunterst tzte Analyse verwendet Benutzerunterst tzte Analyse Vorgehen bei dem eine Analyse durch Kom bination von menschlichen F higkeiten mit maschinell durchf hrbaren Arbei ten durchgef hrt wird Gewisse menschliche F higkeiten sind ausgesprochen schwierig maschinell nachzu bilden Bei vielen Analyseproblemen lohnt sich deshalb ein R ckgriff auf diese menschlichen F higkeiten sehr diese k nnen aber beispielsweise sinnvoll durch maschinelle Ueberpr fungen unterst tzt werden Beispiel 1 Datentyperkennung Es ist f r einen Benutzer oft durch blosses Anschauen eines Datenbestandes schon m glich rasch bestimmte Eigenschaften zu vermuten Dies einerseits aufgrund der hervorragenden Mustererkennungsf higkeiten des Menschen andererseits aber auch aufgrund der M glichkeit
130. handener Datenbestand f r eine Mehr fachnutzung aufbereitet werden soll 3 2 PROBLEMBEREICHE BEI EINER DATENUBERNAHME 3 2 1 Unvollst ndige und fehlende Angaben Bevor eine Daten bernahme konkret durchgef hrt werden kann muss Klarheit ber Struktur und Verwendungszweck des Ausgangs und des Zieldatenbestandes vorlie gen und es muss eine Abbildung vom Ausgangs auf den Zieldatenbestand gefunden werden Diese Angaben sind oft nicht oder nur unvollst ndig vorhanden und m ssen deshalb zuerst anhand der verf gbaren Informationsquellen beschafft oder erg nzt werden Dabei sind sowohl syntaktische als auch semantische Aspekte zu ber cksich tigen Syntaktische Aspekte sind beispielsweise Kenntnisse ber Zeichens tze Daten typen Wertebereiche Formate Entit tsmengen oder Kardinalit ten Zu den semanti schen Aspekten geh ren unter anderem Kenntnisse ber Konsistenzbedingungen und den Verwendungszweck der Daten aber auch Eigenschaften die unter dem Begriff Datenqualit t zusammengefasst werden k nnen Im Rahmen einer Daten bernahme sind dabei sowohl Probleme zu l sen die ihre Ursache in Entwurf und Betrieb des Ausgangssystems haben als auch solche die erst im Zusammenhang mit der Uebernahme entstehen 3 2 2 Ausgangssystemprobleme Mit dem Begriff Ausgangssystemprobleme sollen im folgenden eine Reihe von Pro blemen bezeichnet werden die nicht in direktem Zusammenhang mit der Daten ber nahme stehen sondern die scho
131. hiedlicher Weise davon ab mit SQL steht aber immerhin eine stan dardisierte DDL DML zur Verf gung Melton Simon 93 Das relationale Modell erlaubt eine Pr sentation von Daten mit minima ler Redundanz und minimalen Verkn pfungen im Gegensatz etwa zu objektorientierten Modellen Das relationale Modell eignet sich vorz glich zur Modellierung betrieb licher Nutzdaten Weltweit sind sehr viele solcher Systeme im Einsatz 18 Die ersten Arbeiten zum Relationenmodell wurden von Codd bereits 1969 70 publiziert Die angegebene Referenz bezeichnet jedoch seine erg nzte Darstellung des Relationenmodells das sogenannte RM V2 Relationenmodell Version 2 104 WERKZEUGUNTERST TZUNG F r relationale Systeme sind viele Werkzeuge z B zur Datenmodellie rung kommerziell verf gbar Ein Zusammenwirken solcher Werkzeuge mit DART wird erleichtert Moderne Anwendungssysteme basieren h ufig auf relationaler Techno logie ein Zwischensystem in ebenfalls dieser Technologie erleichtert die Uebertragung vom Zwischen ins Zielsystem ganz erheblich in vielen F llen muss gar keine Uebertragung mehr erfolgen Aufgabenteilung Die eigentlichen Daten Re Engineering Aufgaben sollten getrennt werden von grunds tzlichen Verwaltungs und Dokumentationsauf gaben Aufgrund der Vielfalt an m glichen Problemen sollten einzelne Auf gaben durch speziell daf r entwickelte Programme sogenannte Dienste durchgef hrt werden Diese D
132. hnitten und nur schwer oder sogar gar nicht anpassbar auf etwas anders gelagerte Ausgangssituationen oder Probleme unter schiedlicher Gr ssenordnung Da zur Zeit auch noch kein Standard zum Datenaus tausch zwischen unterschiedlichen Werkzeugen breite Akzeptanz erlangt hat sind solche Einzelwerkzeuge oft nur umst ndlich kombinierbar und ihre Benutzerschnitt stellen sind h ufig sehr unterschiedlich ausgestaltet Zur Unterst tzung von Daten bernahmen gem ss dem MIKADO Modell wurde im Rahmen der vorliegenden Arbeit das experimentelle Daten bernahmesystem DART Data Re Engineering Toolkit entworfen und implementiert Es entstand aus dem Bed rfnis f r eine Vielzahl von Problemen eine Reihe lose gekoppelter Werkzeuge zur Verf gung zu stellen 5 2 DART AUSGANGSLAGE ZIELSETZUNGEN Dem Entwurf und der Realisierung von DART lagen folgende Zielsetzungen zugrun de e Ziel I Machbarkeit Da es sich bei DART um einen Forschungs wegwerf prototyp handelt wurden von Anfang an konsequent Entwurfs und Realisie rungsentscheide am Ziel der kurzfristigen Machbarkeit gemessen Es wurde nie die Entwicklung eines voll produktiv einsetzbaren Werkzeugsystems an gestrebt WERKZEUGUNTERSTUTZUNG 101 e Ziel 2 Experimentiersystem Aufgrund der Vielfalt an unterschiedlichen Da ten bernahmesituationen sollte DART m glichst flexibel f r verschiedene Ausgangs bzw Zielsysteme anpassbar sein und das Studium der damit ver bundenen Probl
133. ht in G 2 zu ber nehmen sondern im Rahmen einer neu extern zu entwickelnden Anwendung zur Verf gung zu stellen Diese L sung hat allerdings den Nachteil dass Recherchen unter Umst nden auf zwei verschiedenen Systemen gemacht werden m ssen Sie bot aber den Vorteil die laufenden terminkritischen Entwicklungsarbeiten nicht zus tz lich durch die Daten bernahme zu st ren Es wurde beschlossen ein solches Recher chesystem mit Hilfe des Produktes Microsoft Multimedia Viewer zu entwickeln Diese Entwicklungsarbeiten konnten auf den bereits erfolgten Erfahrungen mit dem SWISSBASE Datenbestand aufbauen Insbesondere lagen die Daten zur Zeit dieses Entscheides bereits im Zwischensystem vor Im Rahmen einer Studentenarbeit wurde FALLSTUDIEN 127 ein solches Recherchesystem entworfen und entwickelt und die Daten in einen funk tionsf higen Prototypen bernommen der an die Informatikdienste bergeben wurde Details zu dieser Anwendung sind in Cron 95 zu finden Aufbereitung f r das Zwischensystem Die Erfahrungen mit einem speziellen Import Dienst der f r die Voruntersuchung implementiert wurde haben die Entwicklung des allgemeinen Import Dienstes wie er in Kapitel 5 beschrieben wurde nachhaltig beeinflusst Mit beiden Diensten war eine einfache Uebernahme der Ausgangsdaten m glich Aufbereitung im Zwischensystem Im Rahmen der Datenaufbereitung waren insbesondere folgende Aufgaben zu l sen 1 Elimination von Attribu
134. i Bereiche gliedern e Analyse Beschaffen und Beurteilen von Informationen ber die zu berneh menden Daten sowie ber Eigenheiten des Ausgangs und des Zielsystems 50 DATEN RE ENGINEERING e Strukturelle Anpassungen Konversion Anpassen der Ausgangsdaten ans Zielsystem In der neuen Umgebung werden die Daten typischerweise in ver nderter Form gebraucht e Inhaltliche Anpassungen Korrektur Eine Daten bernahme bietet Gelegen heit sich nicht nur mit den Datenstrukturen sondern auch mit den Datenin halten auseinanderzusetzen Diese drei Aufgabenbereiche lassen sich allerdings nicht immer scharf trennen Viel mehr bestehen eine Reihe von gegenseitigen Abh ngigkeiten Beispielsweise haben strukturelle Anpassungen h ufig auch einen Einfluss auf den Inhalt und damit die Bedeutung der entsprechenden Daten Diese Gliederung bildet eine der Grundlagen f r das in Kapitel 4 vorgestellte Vorge hensmodell MIKADO und f r die dieses Modell unterst tzende Werkzeugarchitektur DART die in Kapitel 5 vorgestellt wird 3 3 ANALYSE 3 3 1 Daten Reverse Engineering Bei einer Daten bernahme aus einem Legacy System ist man h ufig in der unkomfor tablen Lage dass die vorhandenen Informationen f r eine seri se Beurteilung Pla nung und Durchf hrung einer Daten bernahme nicht ausreichen Es ist zudem oft schwierig pr zis angeben zu k nnen welche Angaben im Einzelfall genau gebraucht werden H ufig st sst man im Verlaufe des
135. ichen Zweck erf llen z B Buch haltungsprogramme selten eine volle Uebereinstimmung der Datenbeschreibungen zu finden Diese Unterschiede m ssen bei einer Daten bernahme berbr ckt werden d h die Meta und Nutzdaten m ssen detailliert auf solche Unterschiede hin ber pr ft und gegebenenfalls angepasst werden In der Regel darf nicht davon ausgegan gen werden dass an sich gleiche Sachverhalte der Realit t in beiden Systemen auch gleich modelliert und dargestellt sind Insbesondere bei der Abl sung von Legacy Systemen wenn oft nur unvollst ndige Datenbeschreibungen des Ausgangssystems vorliegen ist das ein sehr heikles Problem Besondere Schwierigkeiten bereitet dabei das Erkennen vergleichbarer Datenobjekte siehe auch Abschnitt 3 4 3 Obwohl die Rekonstruktion eines logischen oder gar konzeptionellen Schemas we sentliche Angaben f r eine Daten bernahme liefern kann gen gen solche Schemas allein noch nicht Es muss ja nicht nur eine Beschreibung des Ausgangs bzw Ziel 62 DATEN RE ENGINEERING systems vorhanden sein sondern vor allem auch eine m glichst einfach zu realisie rende Abbildung zwischen diesen Diese zu erkennen ist typischerweise kein einfa cher Vorgang Zum Aufgabenbereich Konversion geh ren eine ganze Reihe von Anpassungsarbeiten Diese Anpassungsprobleme treten nicht nur bei einer Daten bernahme auf sondern stellen sich insbesondere auch bei einer Integration heterogener Datenbanksysteme Breitbar
136. ichergestellt werden Methoden des Daten Reverse Engineering k nnen auch zu Erkenntnissen ber Eigenschaften eines Datenbestandes f hren die nicht anhand des Anwendungssystems selbst zu erkl ren sind sondern die sich beispielsweise aufgrund betrieblicher Abl ufe so ergeben haben Hainout et al 92 Vergleicht man Daten Reverse Engineering mit Daten Forward Engineering so lassen sich unter anderem folgende Unterschiede feststellen Daten Forward Daten Reverse Engineering Engineering neue Systeme mehrmals Weiterentw einmal pro System Untersuchungsgegenstand bestehende Systeme H ufigkeit Metadaten Metadaten Nutzdaten betroffene Daten Fig 3 1 Daten Forward vs Daten Reverse Engineering 52 DATEN RE ENGINEERING Untersuchungsgegenstand beim Daten Reverse Engineering bilden oft grosse Mengen gleichartig strukturierter Daten Um zu Erkenntnissen ber diese Daten zu gelangen erweist sich oft eine Kombination verschiedener Analysemethoden als g nstig 3 3 2 Arten von Analysemethoden H ufig sind Methoden zur Ueberpr fung einer Hypothese deutlich weniger komplex als solche mit der Hypothesen gefunden werden k nnen Im folgenden wird deshalb zwischen explorativen und affirmativen Analysemethoden unterschieden Explorative Analysemethode Methode mit der eine Eigenschaft eines Da tenbestandes erkannt werden kann Hypothesenfindung Affirmative Analysemethode Methode mit der eine vermutete Eigensc
137. ichtige im Sinne der festgelegten Konsistenzbedingungen aber der Realit t widersprechende Daten in ein Anwendungssystem gelangen Dies ist zwar grunds tzlich nicht absolut vermeidbar durch Pr fung von anspruch volleren Konsistenzbedingungen k nnte aber die Auftretenswahrscheinlich keit solcher Fehler reduziert werden Viele ltere Systeme verf gen jedoch nur ber einfache Eingabepr fungen e Anwendungsprogramme Aufgrund von Fehlern in den Anwendungspro grammen k nnen falsche Daten in ein System gelangen oder es k nnen auch richtige Daten falsch verarbeitet und gespeichert werden falsche Berechnun gen Speicherung in einem falschen Format Solche Fehler sind recht h u fig und bleiben manchmal ber l ngere Zeit unentdeckt Sie weisen jedoch oft eine gewisse Systematik auf die eine automatische Korrektur erlaubt e Systemsoftware Betriebssystem Datenverwaltung Fehler in den verwende ten Systemprogrammen k nnen zu Abst rzen und damit zu Datenverf l schungen f hren Diese Fehler sind recht selten aber deutlich h ufiger als Hardwarefehler e Hardware Aufgrund von Hardwarefehlern k nnen Daten verf lscht oder zer st rt werden Diese Art von Fehlern ist allerdings ausgesprochen selten Neben den erw hnten eher technischen Fehlerquellen darf auch nicht ausser acht gelassen werden dass die Daten eines Anwendungssystems letzten Endes immer auch noch von Menschen interpretiert und in einen gr sseren Zusamm
138. ide Release 4 2 Software Maintenance News Inc California 1994 LEBENSLAUF 19 April 1959 geboren in Z rich Fr hling 1974 Herbst 1978 Besuch der Mittelschule in Wetzikon Abschluss Matura Typus C Herbst 1978 Herbst 1979 Studium der Mathematik an der Universit t Z rich Herbst 1979 Fr hling 1985 Studium der Wirtschaftsinformatik an der Universitit Z rich Abschluss als Lic oec publ seit 1985 Selbst ndige T tigkeit in den Bereichen Informatikberatung und Software entwicklung Herbst 1991 Fr hling 1996 Teilzeittatigkeit als Assistent bei Prof Zehnder am Institut fiir Informations systeme der ETH Z rich
139. iederung des Begriffes Datenqualit t Die Schwierigkeit dieses Modells liegt in der Abgrenzung der einzelnen Merkmale So sind beispielsweise die beiden Merkmale N tzlichkeit und Glaubw rdigkeit nicht orthogonal 72 DATEN RE ENGINEERING Trotz aller Vorteile einer hierarchischen Gliederung ist ein Modell das die Abh ngig keiten der Merkmale besser zum Ausdruck bringt dem Problem angemessener Ein solcher Ansatz l sst sich als netzwerkartige Gliederung charakterisieren Interpretierbarkeit Glaubw rdigkeit Vollst ndigkeit Genauigkeit C menet gt A Verf gbarkeit Legende C_D Merkmal Be beeinflusst Datenqualit t im weiteren Sinne Fig 3 10 Netzwerkartige Gliederung des Begriffes Datenqualit t Hasler 95 Eine Daten bernahme bietet Gelegenheit insbesondere weil oft sowieso eine Anpas sung der Dateninhalte aufgrund der geschilderten Probleme durchzuf hren ist auch dem Aspekt der Datenqualit t Beachtung zu schenken Angaben zur Datenqualit t die im Rahmen einer detaillierten Analyse festzustellen sind k nnen aber einen Da ten bernahmevorgang nachhaltig beeinflussen siehe auch Fallstudie A in Kapitel 6 Es ist stets darauf zu achten nur Merkmale zu messen die auch verbessert werden k nnen und deren Verbesserung auch einen erkennbaren Nutzen erbringt In der Regel erfordern auch Datenqualit tsverbesserungen Validierungsprozesse verursa chen also einen wesentlichen manuellen Aufwand Es sind jed
140. iehungen zwischen einzelnen Entit tsmengen Der Umfang der Nutzdaten betr gt rund 6 GByte F r eine Verwendung in einem zentralen Katalog kann diese Menge aber deutlich reduziert werden insbesondere die gesamte Benutzerverwaltung und das Bestellwesen k nnen ja wegfallen Der Zugriff zu den ETHICS Daten konnte f r eine externe Untersuchung grunds tz lich auf zwei Ebenen erfolgen Datenverwaltungssystem und Benutzerschnittstelle Ein Zugriff auf Anwendungsebene besteht bei ETHICS nicht 132 FALLSTUDIEN F r die vorliegende Untersuchung stand eine Testbibliothek zur Verf gung Es handelt sich dabei um einen kleinen auch ETHICS intern verwendeten Datenbe stand der die gleiche Struktur wie die realen Daten aufweist aber leider teilweise mit semantisch sinnlosen Dateninhalten gef llt ist Vorhandene Systembeschreibungen Da das Ausgangssystem ETH intern entwickelt worden war bestand grunds tzlich ein Zugriff auf die entsprechenden Entwurfs und Wartungsunterlagen Diese sind bei ETHICS ausgesprochen umfangreich Ein konzeptionelles Schema ist nicht vorhan den Es standen grunds tzlich folgende Informationsquellen zur Untersuchung des Aus gangssystems zur Verf gung e Die Benutzerschnittstelle der laufenden Anwendung Bildschirmmasken Li stenbilder e Das Benutzerhandbuch e Die Test Daten e Die Entwickler bzw Betreiber e Technische Unterlagen zum eingesetzten Datenbanksystem Fiir das Zielsystem war ei
141. ielsystem konnte jedoch unabh ngig von der Daten bernahme erfolgen Die Verwaltung von neuen Kundendaten war somit zeitgerecht m glich eine Verz gerung der Daten bernahme konnte allenfalls ohne gravierende Konsequenzen in Kauf genommen werden e Ausgangssystemunabh ngigkeit Das Ausgangssystem wurde nicht ber hrt Der Betrieb des Ausgangssystems war zur Zeit der vorliegenden Untersu chung bereits in mehreren Niederlassungen eingestellt worden e Uebernahme Es handelt sich bei dem Problem um eine Uebernahme Auf ei nen bestimmten Zeitpunkt hin sollte der Betrieb des Ausgangssystems in allen Niederlassungen eingestellt werden e Datenqualit t Eine Korrektur der Daten war nicht vorgesehen Das Problem geh rte somit zur folgenden Problemklasse P Problemtyp Ty Uebernahme Uebergangsvertr glichkeit Uv inhomogen Uebergangsart Uaa diskontinuierlich Zerlegbarkeit Z gt zerlegbar Aenderungsgrad As statisch Expansion Ex klein Ausgangssystem Das Ausgangssystem war von einer bankexternen Firma Ende der achtziger Jahre entwickelt und dann w hrend mehreren Jahren immer wieder an neue Bed rfnisse bzw an Versions nderungen der zugrunde liegenden Plattform angepasst worden Die Anwendung selbst war zwar auf einer Festplatte installierbar die Kundendaten muss ten jedoch alle auf Diskette gespeichert werden Der Ausgangsdatenbestand ist hori zontal anhand der einzelnen Installati
142. ienste sollten durch eine zentrale Steuerung mit den entsprechenden Daten auf denen sie operieren versorgt werden Ebenso sollte die Konversion der Daten vom Ausgangs ins Zwischensystem sowie vom Zwischen ins Zielsystem von der Aufbereitung getrennt werden Zentrale Verwaltung der Meta Daten S mtliche Meta Daten sollten zentral gespeichert und verwaltet werden Datentypen Im Zwischensystem wird nur der Datentyp Zeichenkette un terst tzt entsprechende Anpassungen sind bei der Uebernahme aus dem Aus gangssystem bzw bei der Uebertragung ins Zielsystem durchzuf hren In einer sp teren Phase der Entwicklung wurde zus tzlich noch folgender Entscheid getroffen Benutzbarkeit als Einzelwerkzeuge Soweit m glich und sinnvoll sollten ein zelne Komponenten von DART sog Dienste vgl Abschnitt 5 7 auch los gel st vom Gesamtsystem benutzt werden k nnen Basierend auf diesen Entwurfsentscheiden wurde die Architektur des Gesamtsystems entwickelt Sie umfasst verschiedene Komponenten die im folgenden detailliert erl u tert werden DART besteht aus folgenden Komponenten Daten Import Daten Export Konversionen Ausgangs gt Zwischensystem bzw Zwischensystem gt Zielsystem Kernsystem Verwaltung der Meta Daten sowie Steuerung des Aufrufs der einzelnen Dienste Dienste Werkzeuge zur L sung einzelner Aufgaben Die einzelnen Komponenten sind ber Schnittstellen miteinander verbunden Im folgenden werden die e
143. igenschaften sowohl nach Methoden mit denen ihr Erf llungsgrad gemessen werden kann als auch nach Methoden zu ihrer Ver besserung zu suchen Dieser Denkansatz geht implizit von einer weitgehenden Ortho gonalit t der einzelnen Kriterien aus Eine Reihe von Arbeiten basieren grunds tzlich auf diesem Ansatz sie unterscheiden sich im wesentlichen in der Wahl der untersuch ten Kriterien und den Methoden zu ihrer Messung und Verbesserung Aebi Perro chon 93 Fox et al 94 Huh et al 90 Trotz aller Schwierigkeiten einer begrifflichen Abgrenzung ist es aber oft durchaus m glich f r einzelne dieser Eigenschaften messbare Kriterien zu finden die auch eine konkrete Ueberpr fung und Verbesserung der Qualit t eines Datenbestandes erlauben So lassen sich beispielsweise f r das Kriterium Vollst ndigkeit Eigen schaften festlegen die gemessen und beurteilt werden k nnen beispielsweise das Verh ltnis der Anzahl leeren zur Gesamtzahl von vorhandenen Attributinstanzen Sehr h ufig wird jedoch eine Verbesserung nicht automatisch erfolgen k nnen son DATEN RE ENGINEERING 71 dern wesentliche manuelle Aufwendungen verursachen Eine ganze Reihe von sol chen messbaren Kriterien sind in Hasler 95 zusammengetragen Bei diesem Ansatz bei dem einzelne orthogonale Eigenschaften isoliert untersucht werden l sst sich der Begriff Datenqualit t als einstufig hierarchisch gegliedert charakterisieren Datenqualit t
144. ik wird in Kapitel 4 n her eingegangen 2 11 DATEN LEBENSZYKLEN Im Bereich des Software Engineering wurden schon fr h Ueberlegungen zur Gliede rung des zeitlichen Verlaufs von Entwicklung und Betrieb von Programmen ange stellt Daraus entstanden verschiedene sogenannte Software Lebenszyklus Modelle Alle diese Modelle strukturieren den Entwicklungsprozess allenfalls auch die Be triebsdauer durch Gliederung in einzelne Phasen Analoge Betrachtungen lassen sich auch f r den Lebenszyklus von Datenbest nden anstellen Auch Datenbest nde durchlaufen deutlich unterscheidbare Phasen wobei die Phasengrenzen sinnvollerweise dort gezogen werden wo eine wesentliche Aende rung in der Nutzung und oder in den auftretenden Kosten festzustellen ist Br ndli 94 Das im folgenden dargestellte Modell unterscheidet f r Datenbest nde folgende vier Phasen e Vorbereitung e Aufbau e Betrieb e Archivierung Entsorgung Diese Phasenunterscheidung bezieht sich ausschliesslich auf die Datenbest nde und steht in keinem Zusammenhang zu einzelnen Phasen der Anwendungsprogramment wicklung Insbesondere haben die bereits erw hnten raschen Wechsel von Ger te und Programmkomponenten keinen Zusammenhang mit den hier pr sentierten Daten lebensphasen Das Modell betrachtet die Zeitspanne von der Planung bis zur Entsor gung eines Datenbestandes als Lebenszyklus Ein neuer Datenlebenszyklus beginnt wenn eine Anwendung durch eine neue abgel st wi
145. ikation und Test solcher Beschreibungen Die Daten werden nicht direkt vom 116 WERKZEUGUNTERSTUTZUNG Ausgangs ins Zielsystem sondern zuerst in ein allgemeines Zwischenformat SGML konvertiert Vereinfacht l sst sich die Architektur von ICA folgendermassen darstel len Grammar Development Tools General Description Phase Structural gt Mapping Tools Tools Explicit Markup Document Specific to General General to General Markup Specific Document Translator Document Translator Fig 5 7 Architektur von ICA Mamrak et al 94 Retagging Document Programs Langerfristig ist geplant ICA dahingehend auszubauen dass damit nicht nur Daten aus Textverarbeitungssystemen sondern auch allgemeinere Datenformate insbesonde re Daten aus relationalen Datenbanksystemen damit konvertiert werden k nnen Interessant an ICA ist der Entscheid hnlich wie in DART ein Zwischensystem einzu setzen und die Daten nicht direkt vom Ausgangs ins Zielssystem zu tibernehmen Sehr wichtig ist auch die M glichkeit Uebersetzungwerkzeuge anhand einer formalen Beschreibung generieren zu k nnen Zur Zeit bestehen aber erst Uebersetzungspro gramme f r einige wenige Ausgangs bzw Zielsysteme Da ICA frei verf gbar ist public domain kann sich das unter Umst nden aber rasch ndern 5 9 3 DB MAIN DB MAIN ist die Bezeichnung eines
146. in der Praxis typischerweise vorkommen ist dieses naive Verfahren selbstverst ndlich nicht brauchbar Es sind deshalb eine Reihe von Verfahren vorgeschlagen worden die allerdings unter Verzicht auf absolute Genau igkeit das Finden approximativer funktionaler Abh ngigkeiten erlauben Detaillierte Informationen hierzu sind beispielsweise in Bitton et al 89 Kivinen Mannila 92 Mannila 92 Li 93 und Mannila R ih 94 zu finden 12 Beispielsweise werden in Finanzinformationssystemen zur Beschreibung von Finanzinstru menten Aktien Obligationen Relationen mit rund zweitausend verschiedenen Attributen verwendet 56 DATEN RE ENGINEERING Beschr nkt man sich darauf Hypothesen die beispielsweise aufgrund von vorhande nem Anwendungswissen formuliert werden k nnen ber funktionale Abh ngigkeiten zu berpr fen so kann das mit einem Aufwand von O n log n durchgef hrt werden die Relation muss dazu im wesentlichen nur sortiert werden was durchaus eine praktische Anwendung erlaubt 3 3 3 Informationsquellen Wie bereits angedeutet basieren manche der bekannten Verfahren auf Voraussetzun gen die im allgemeinen Falle nicht als gegeben betrachtet werden k nnen Eines der in diesem Zusammenhang recht schwierig zu l senden Probleme besteht darin fest zustellen welche Informationen f r eine konkrete Daten bernahme berhaupt zwin gend gebraucht werden Zur Beschaffung und Vervollst ndigung von I
147. ings noch gravieren der m ssen doch solche Konflikte im laufenden Betrieb das heisst insbesondere nicht nur bei Lese sondern auch bei Schreiboperationen aufgel st werden Obwohl sehr grosse Anstrengungen unternommen wurden automatische L sungen f r das Erkennen und Aufl sen solcher Konflikte zu finden muss festgestellt werden dass die vorliegenden Ergebnisse bisher noch recht bescheiden und f r praktische Zwecke insbesondere bei gr sseren Datenmengen v llig unbrauchbar sind Shet 92 Chatterjee Segev 91 und Kim Seo 91 Viele der vorgeschlagenen L sungsans tze gehen dabei von Annahmen ber die zu integrierenden Systeme aus die im Falle von Legacy Systemen nicht gegeben sind Lim et al 93 Daten bernahme Datenbankintegration Metadaten nur unvollst ndig vorhan vorhanden den allenfalls auch falsch Lesen Lesen und Schreiben unver nderlich ver nderlich Zugriff Datenstrukturen Abgleich auf physischer kann automatisiert werden Ebene muss manuell erfolgen Anzahl unterschiedlicher Systeme gross eher klein Fig 3 7 Gegen berstellung Daten bernahme Datenbankintegration Falsche bzw inkompatible Datenwerte stellen ganz besondere Probleme bei einer Daten bernahme Ihr Erkennen erfordert in der Regel sehr aufwendige Analyse und allenfalls Korrekturarbeiten Sofern es sich nicht um systematische Fehler handelt ist unter Umst nden jeder einzelne als falsch erkannte Datenwert ind
148. insbesondere Um mehr als eine Adresse verwalten zu k nnen muss eine Abtrennung und getrennte Speicherung der Adressdaten erfolgen Das Attribut Code muss in einzelne Attribute aufgeteilt werden Der Datentyp des Attributs Postleitzahl muss ge ndert verl ngert werden und die vorhandenen Datenwerte m ssen bei der Uebernahme anhand einer Umsetzungstabelle Referenzdaten ersetzt werden Die Datentypen der beiden Attribute ImmDatum und ExmDatum m ssen ge ndert und die konkreten Datenwerte bei der Uebernahme um das Jahrhun dert erweitert werden Die Angaben zu den einzelnen Studierenden werden von den Angaben ber die Fakult ten getrennt Normalisierung Doppelt erfasste Daten zu Studierenden sollen bei der Uebernahme entfernt werden Dazu muss ein Vergleichskriterium definiert werden anhand dessen gleiche Eintr ge erkannt werden k nnen Die Elimination solcher Duplikate erfordert eventuell ein manuelles Eingreifen Entscheiden welche Daten zu behalten bzw zu l schen sind All diese Anpassungen f hren zu folgenden drei Relationen Notation SQL 89 CREATE Table Student StudNr INTEGER NOT NULL PRIMARY KEY Name CHAR 30 FakNr INTEGER ImmDatum DATE ExmDatum DATE Geburtsjahr INTEGER Geschlecht CHAR 1 Sem INTEGER DATEN RE ENGINEERING 77 CREATE Table Fakultaet FakNr INTEGER NOT NULL PRIMARY KEY Bezeichnung CHAR 30 CREATE Table Adresse StudNr INTEGE
149. inzelnen Komponenten und ihr Zusammenwirken beschrieben WERKZEUGUNTERSTUTZUNG 105 Konversions Hilfs Dienste Korrektur Dienste Analyse Dienste Kontrolle Repositorium Datenverwaltung Import Dienste Export Dienste Spezielle Spezielle Allgemeiner Import Dienst Import Allgemeiner Export Dienst Export Dienste Dienste Ausgangsdaten Zieldaten Fig 5 1 DART Architektur 5 5 DART IMPORT EXPORT DIENSTE 5 5 1 Aufgabe Mit Hilfe von Import bzw Export Diensten soll eine m glichst weitgehende Losl sung von systemspezifischen Eigenheiten der Ausgangs bzw Zielsysteme erreicht werden Die Aufgabe der Import Dienste besteht dabei im wesentlichen in der Kon version des Ausgangsdatenbestandes in relationale Form Mit Hilfe von Export Diensten erfolgt die Konversion von Daten des Zwischensystems in die im Zielsystem endg ltig verwendete Form Um im Zwischensystem weiterverarbeitet werden zu k nnen m ssen die Daten mindestens in erster Normalform vorliegen Um eine m glichst grosse Vielfalt an Ausgangs bzw Zielsystemen abdecken zu k nnen wurde eine Trennung in allgemeine und spezielle Dienste vorgenommen Bei der Entwicklung von Import bzw Export Diensten wurde von der Ueberlegung ausgegangen dass ein solcher Dienst f r eine m glichst grosse Zahl von Ausgangs bzw Zielsystemen nutzbar sein sollte dass aber auch eine Reihe von F l
150. ividuell zu korrigie ren Diese m glicherweise erheblichen Aufw nde d rfen aber nicht dazu verleiten das Problem einfach zu bergehen Man kommt nicht um eine seri se Beurteilung der konkret vorliegenden Ausgangslage herum 70 DATEN RE ENGINEERING 3 5 4 Datenqualit t Im Zusammenhang mit fehlerhaften Daten wird gerne von der Qualit t der Daten gesprochen Der Begriff Datenqualit t ist allerdings ausgesprochen unpr zis Da er stark kontextabh ngig ist besteht keine weitgehende Einigkeit ber seine Bedeutung Intuitiv wird Datenqualit t jedoch als etwas Positives W nschbares betrachtet Der Versuch Datenqualit t anhand des allgemeineren Begriffes Qualit t herzuleiten offenbart die Probleme Qualit t nach ISO 8402 Unter der Oualit t eines Produktes oder einer T tigkeit versteht man die Gesamtheit aller qualit tsrelevanten Merkmale und Eigenschaften Ein Merkmal oder eine Eigenschaft geh rt zu dieser Gesamt heit wenn es f r die Erf llung von Erfordernissen von Bedeutung ist Diese genormte Begriffbildung zeigt dass es einerseits mehrere relevante Merkma le geben kann und dass diese je nach Anforderungen verschieden gewichtet werden k nnen Es sind unschwer eine ganze Reihe von Eigenschaften zu finden die f r einen Daten bestand w nschbar sind e Richtigkeit e Vollst ndigkeit e Genauigkeit e Aktualit t e Verf gbarkeit e N tzlichkeit Es liegt nahe f r einzelne solcher E
151. konkrete Praxispro bleme siehe Kapitel Fallstudien eine praktische Ueberpr fung berhaupt erst m g lich machten Ziel 6 wurde als Konsequenz aus fr hen Erfahrungen mit einem ersten Prototyp formuliert Parallel zur Entwicklung und Ueberpr fung von DART erfolgte die Ausarbeitung des MIKADO Modelles Diese beiden Arbeiten beeinflussten sich gegenseitig stark 5 3 DART ENTSTEHUNGSGESCHICHTE UND EINGESETZTE ENT WICKLUNGSWERKZEUGE Die Entwicklung von DART erfolgte in zwei Anl ufen Ein erster Prototyp basierend auf einer Architektur die sich ausschliesslich auf die Analyse und Aufbereitung der Daten in einem Zwischensystem konzentrierte und ausgangs bzw zielsystemabh n gige Eigenheiten v llig ausser acht liess gelangte nicht bis zum praktischen Einsatz Aebi Largo 94 Dies war unter anderem auf einen wie sich allerdings erst nach tr glich zeigte falschen Entwurfsentscheid zur ckzuf hren Zentrales Element die 102 WERKZEUGUNTERSTUTZUNG ses Entwurfes bildete ein relationales Datenbankverwaltungssystem auf dem eine Reihe von Einzelwerkzeugen fiir Analyse Konversions und Korrekturaufgaben aufsetzen sollten Experimente zeigten jedoch dass die erreichbaren Leistungsdaten insbesondere f r Datenstruktur nderungen so schlecht waren dass ein kompletter Neuentwurf durchzuf hren war Der zweite Anlauf mit einer angepassten Architektur entstand aufgrund der Erfahrun gen mit dem ersten Versuch und unter Verwendun
152. leiche Sachverhalte unterschiedlich dargestellt werden z B im Ausgangssy stem als Attribut im Zielsystem als Entit t so sind gegebenenfalls entsprechende Verbindungselemente z B Schl ssel nachtr glich zu erfassen oder zu generieren Aber auch bei voller Strukturkompatibilit t d h wenn zu allen Attributen des Aus gangssystems ein entsprechendes Attribut im Zielsystem vorhanden ist muss bei der Konversion sehr sorgf ltig darauf geachtet werden dass kein unerw nschter Daten verlust entsteht Ein solcher Verlust ist namentlich dann m glich wenn der Datentyp eines Attributes im Ausgangssystem nicht mit dem entsprechenden Datentyp im Ziel system bereinstimmt z B ungleich lange Zeichenketten Uebertragung einer Gleit kommazahl in eine Ganzzahl Gerade bei Standardprogrammen bestehen oft nur eingeschr nkte M glichkeiten auf diese Darstellungs und Speicherungseigenheiten Einfluss zu nehmen Konversionen zwischen unterschiedlichen Datentypen stellen zwar im Einzelfall in der Regel keine allzu grossen Probleme Die Erkennung m gli cher Konflikte ist jedoch oft aufwendig 3 5 KORREKTUR 3 5 1 Ursachen von Datenwertproblemen Aufgrund von Aenderungen der Realit t die nicht in den Daten nachgef hrt werden ungen gender oder falscher Konsistenzkontrollen aber auch aufgrund von Fehlfunk tionen eines Anwendungssystems k nnen berfl ssige redundante oder auch falsche Daten entstehen Dies kann grunds tzlich in jede
153. len auftreten k nnen die besser individuell behandelt werden Wann immer m glich sollte ein Dienst an verschiedene Problemstellungen anpassbar konfigurierbar sein 106 WERKZEUGUNTERSTUTZUNG Die Aufgaben eines Import Dienstes analoges gilt fiir einen Export Dienst lassen sich wie folgt umschreiben Konversion der Daten des Ausgangssystems in erste Normalform Konversion der Datentypen des Ausgangssystems in Zeichenketten Erfassen bzw Bereitstellen der entsprechenden Meta Daten Im Rahmen von Studentenarbeiten wurden folgende Import Export Dienste real bereitgestellt e Ein spezieller Dienst f r den Import von Daten aus ADABAS Datenbank verwaltungssystemen e Ein allgemeiner Dienst f r den Import von Daten e Ein spezieller Dienst f r den Export von Daten in das UNIMARC Format e Ein spezieller Dienst f r den Export von Daten in ein Multimedia System Rich Text Format All diese Dienste wurden fiir konkrete Datentibernahmen eingesetzt siehe Kapitel 6 Der ADABAS Import Dienst entstand im Projektablauf zuerst Der allgemeine Im port Dienst sowie die Export Dienste wurden anschliessend zur selben Zeit parallel entwickelt Im folgenden wird nur der allgemeine Import Dienst detailliert beschrie ben Detaillierte Erl uterungen zu den brigen Diensten sind den bereits zitierten Arbeiten zu entnehmen Auf die Entwicklung eines allgemeinen Export Dienstes wurde verzichtet da die konkret untersuchte
154. lende Daten 3 5 3 Inhaltliche Abgleiche zwischen Ausgangs und Zielsystem 3 5 4 Datenqualit t 3 6 Klassifizierung von Daten bernahmen 3 7 Beispiel 3 8 Hypothesen Konsequenzen Lehren 3 8 1 Hypothesen 3 8 2 Konsequenzen f r Daten bernahmen 3 8 3 Lehren f r neu zu entwickelnde Anwendungen 43 43 46 46 46 49 49 50 50 52 56 56 58 61 61 62 64 65 65 65 66 68 70 72 75 77 77 78 79 6 INHALTSVERZEICHNIS 4 VORGEHENSMODELLE 81 4 1 Vorgehensmodelle f r die Entwicklung von Anwendungssystemen 81 4 2 Vorgehensmodelle f r die Abl sung von Anwendungssystemen 83 4 2 1 Ausgangslage 83 4 2 2 Die Alles auf einmal Strategie 83 4 2 3 Die inkrementelle Strategie 84 4 3 MIKADO Ein Vorgehensmodell f r Daten bernahmen 89 4 3 1 Grundlagen 89 4 3 2 Die Phasen von MIKADO 95 5 WERKZEUGUNTERST TZUNG 99 5 1 Vorbemerkungen Stand der Technik 99 5 2 DART Ausgangslage Zielsetzungen 100 5 3 DART Entstehungsgeschichte und eingesetzte Entwicklungswerkzeuge 101 5 4 DART Architektur 103 5 5 DART Import Export Dienste 105 5 5 1 Aufgabe 105 5 5 2 Realisierungskonzept 106 5 6 DART Kernsystem 109 5 6 1 Aufgabe 109 5 6 2 Realisierungskonzept 109 5 7 DART Dienste 112 5 7 1 Aufgabe 112 5 7 2 Realisierungskonzept 112 5 8 Erfahrungen weiterf hrende Arbeiten 113 5 9 Verwandte Arbeiten 114 5 9 1 Vergleichbare Projekte 114 5 9 2 The Integrated Chameleon Architecture ICA 115 5 9 3
155. liegenden Konzepte und Ideen Die konkret realisierten Systeme entziehen sich allerdings oft einem allzu direkten Vergleich da die dahinterstehenden Voraussetzungen und Ziele WERKZEUGUNTERSTUTZUNG 115 sowie die geleisteten Aufwendungen und verfiigbaren Ressourcen in der Regel sehr unterschiedlich sind Was schon bei der Diskussion von kommerziellen Werkzeugen festgestellt wurde dass sie n mlich oft nur f r Einzelaufgaben geeignet sind gilt in besonderem Masse auch fiir Forschungsarbeiten nur wenige Arbeiten befassen sich mit Datentibernah men als Gesamtproblem Eine Vielzahl von Arbeiten widmet sich Teilaspekten Sucht man nach umfassenderen Systemen so zeigt sich dass auch im Problembereich Software Re Engineering erst einige wenige Projekte mit ansprechendem Funktions umfang realisiert wurden Zu nennen sind hier insbesondere das bereits erw hnte REDO Projekt Van Zuylen 93 aber auch The Maintainer s Assistant Yang91 Ward et al 89 oder das CAS program understanding project M ller et al 94 Charakteristisch f r diese Arbeiten ist insbesondere dass ganz erhebliche Ressourcen personell und finanziell f r die Entwicklung solcher Systeme aufgewendet wurden Oft wurden diese Projekte auch in Zusammenarbeit mit Partnern aus der Industrie durchgef hrt Fragestellungen im Zusammenhang mit Daten Re Engineering spielen bei diesen Projekten aber eher eine untergeordnete Rolle Im Zusammenhang mit DART bieten sich f
156. lit t Eine allf llige Korrektur der Daten hing von den Resultaten der Qualit tskontrolle ab Das Problem geh rte somit zur folgenden Problemklasse P Problemtyp Ty Uebernahme Uebergangsvertraglichkeit Uvi inhomogen Uebergangsart Uaa diskontinuierlich Zerlegbarkeit Z gt zerlegbar Aenderungsgrad As statisch Expansion Ex klein Ausgangssystem Das System SWISSBASE entstand in den siebziger Jahren Es war urspr nglich als Datenbankverwaltungssystem f r Zwecke der Bibliotheksautomation im milit rischen Bereich entwickelt worden Durch laufende Weiterentwicklung w hrend mehreren Jahren wurde sein Einsatzgebiet aber immer breiter Es wurde insbesondere um weitreichende F higkeiten zur Verwaltung von Volltextdaten erg nzt Brunner 93 Es bietet nebst den grundlegenden Datenverwaltungsfunktionen auch M glichkeiten zur Anwendungsentwicklung an Es l sst sich somit am ehesten als aus heutiger Sicht einfache 4GL Entwicklungsumgebung charakterisieren SWISSBASE selbst wurde 122 FALLSTUDIEN vollst ndig in der standardisierten Programmiersprache MUMPS entwickelt und ist deshalb auf einer Vielzahl von verschiedenen Plattformen einsetzbar Die mit SWISSBASE entwickelten Anwendungen verwenden ebenfalls diese Sprache Die auf dieser Basis entwickelte Vorstossverwaltung bietet Funktionen f r Erfassen Aendern L schen Suchen und Drucken von Vorst ssen an Sie verf gt ber eine
157. lung von Generalisierungen Solche Eigenschaften eines konzeptionellen Schemas m ssen entsprechend umgesetzt oder unter Umst nden mit anderen Mitteln z B in den Anwendungsprogrammen dargestellt werden Der logische Entwurf beginnt mit einem konzeptionellen Schema und liefert als Er gebnis ein logisches Schema Ein logisches Schema beschreibt den Datenbestand in einem bestimmten Datenmodell welches von einer Klasse von real verf gbaren Da tenbankverwaltungssystemen verwendet werden kann Auf der logischen Ebene sind also bereits realisierungsabh ngige Entscheidungen zu treffen Ein sorgf ltiger Ent wurf auf der logischen Ebene gibt aber immer noch eine gewisse Freiheit bei der Wahl des konkret f r die Realisierung zu verwendenden Datenbankverwaltungssy stems solange es das verwendete Datenmodell unterst tzt Als ein typischer Vertre ter eines logischen Datenmodelles mit sehr grosser Verbreitung ist SQL zu nennen das auf dem Relationenmodell basiert und dieses erg nzt Der physische Entwurf basiert auf dem logischen Schema und resultiert im physischen Schema Ein physisches Schema beschreibt weitere implementationsabh ngige Eigen schaften eines Datenbestandes Im physischen Schema werden beispielsweise Spei cher und Zugriffssstrukturen definiert Das physische Schema ist deshalb stark vom eingesetzten Datenbankverwaltungssystem abh ngig 42 GRUNDLAGEN UND BEGRIFFE Gelegentlich wird der Begriff Schema als Zusammenfassung f r
158. m System passieren und ist nicht v llig vermeidbar Wenn sich die Realit t ndert k nnen Daten auch bei sorgf ltig sten Vorkehrungen mit der Zeit falsch werden da sie immer nur ein Abbild der Reali t t zu einem ganz bestimmten Zeitpunkt darstellen 66 DATEN RE ENGINEERING Die erw hnten Fehlerquellen bestehen zwar grunds tzlich bei jedem Anwendungssy stem im Zusammenhang mit Legacy Systemen ist man jedoch vermehrt mit solchen Schwierigkeiten konfrontiert vor allem weil die Konsistenzsicherung auf die einzel nen Anwendungsprogramme verteilt ist und in diesen oft sehr unterschiedlich ge handhabt wird Dadurch ergeben sich beispielsweise auch folgende Probleme e Nullwert Semantik Viele Systeme kennen keine Unterscheidung zwischen sogenannten Null Werten d h Werten die effektiv nicht vorhanden sind weil der entsprechende Sachverhalt nicht bekannt ist und leeren Werten So wird beispielsweise in vielen Systemen f r fehlende Daten einfach ein Er satzwert eingesetzt 0 bei numerischen Daten Spaces bei Zeichenketten Dies wird aber in unterschiedlichen Anwendungen oft nicht einheitlich ge macht e Vorgabewerte Defaults In unterschiedlichen Anwendungen werden m g licherweise verschiedene Arten von Vorgabewerten gesetzt e Datentyppr fung und konversion Over Underflow Probleme Aufgrund unsorgf ltiger Implementation k nnen Daten verf lscht werden wenn Daten typen unsorgf ltig konvertier
159. ma erlaubt zur Laufzeit die Erweiterung des Metaschemas das heisst im Repositorium k nnen Informationen abgelegt werden deren Struktur und Bedeutung zur Entwicklungszeit noch unbekannt sind Beziehung bezID ID FK o Pa 7 FK eee Projekt AttributMenge bezBesch prolD amID ___ proName prolD FK RellnBez proDatumErzeugt o rellD FK proBesch amName bezID FK proDurch amp IID FK Sa y re proVerzeichnis amBesch amiD ribRolleName e ribMinCard Sj ne ribMaxCard Attribut attID AttInMenge Relation en en a gt rellD prolD FK amlD FK re eu rellD FK attlD FK prolD FK attPName aimOrder relPName attPLen aimBesch relLName attLName L J relBesch attLTyp attLLen attBesch Fig 5 5 Metaschema von DART mmRelinBez mmAttributMenge mmBeziehung relID FK amlID bezID bezID FK ibMinCard amName ribMinCar bezName f amTyp bezBesch ribMaxCard amBesch ribRollenName rellD FK amlD FK e od mmAttribut attID mmRelation mmAttInMenge rellD ir attID FK yP amID FK relName o attLen relErzeugtVon attNullWert aimOrder relBesch attEindeutig aimBesch attBesch rellD FK Fig 5 6 Metametaschema von DART 112 WERKZEUGUNTERSTUTZUNG Kontrolle Das Kontrollmodul steuert die Interaktion mit den Benutzern Das
160. me aux cam lias Original TRANSFER19920630CD5099916952928Berliner Salon Salonorchester TRANSFER19920630CD2000000000039Nancy Wilson I ll be a song LUPM 19920901CD2000000000046Kazumi Watanabe Lonesome cat TRANSFER19920630CD2000000000053Billy Harper Soran Bushi B H TRANSFER19920630CD2000000000077Lyrical Melodies of Japan Melo LUPM 19920901CD2000000000084John Williams amp The Boston Pop TRANSFER19920630CD2000000000091Fabrizio de Andr Indians TRANSFER19920630CD2000000000152 Jean Michel Jarre Les cham LUPM 19920923CD2000000000176Stevie Wonder In square circl Fig 3 2 Beispieldaten f r visuelle Hypothesenbildung Durch blosses Ansehen dieser Daten ist es f r einen Menschen sehr rasch m glich beispielsweise folgende Hypothesen zu bilden e Attributgrenzen Obwohl die Daten auf physischer Ebene nur als unstruk turierte Zeichenketten vorliegen lassen sich sofort eine Reihe von Attribut grenzen d h eine Art Recordstruktur identifizieren Datentypen Beispielsweise repr sentiert die Teilzeichenkette beginnend an der Position 9 bis zur Position 16 wahrscheinlich ein Kalenderdatum An den Positionen 18 bis 19 ist vermutlich ein Code Tontr ger abgelegt Die Positionen 19 31 enthalten vermutlich numerische Werte Ab Position 32 sind alphanumerische Werte Interpret und Titel abgelegt Diese Hypothesen werden in Fig 3 3 durch Grenzmarkierungen deutlich unterst tzt 11 Es handelt sich dabei
161. mit der Datenmodellierung sind vor allem folgende drei Abstrak tionsmechanismen von grosser Bedeutung e Klassifikation Zusammenfassung von einzelnen Exemplaren anhand von ge meinsamen Eigenschaften zu Exemplartypen Bilden von Entit tsmengen e Aggregation Zusammenf gen von Einzelkomponenten zu einem bergeord neten Ganzen e Generalisierung Zusammenfassen von hnlichen Exemplartypen zu einem bergeordneten Exemplartyp Mittels Beziehungen werden logische Verbindungen zwischen einzelnen Entit ts mengen hergestellt Dabei spielen sowohl die Anzahl der Teilnehmer an einer solchen Beziehung bin re n re Beziehungen als auch die entsprechenden Anzahlen minimal maximal individueller Exemplare eine grosse Rolle Kardinalit ten F r weitergehende Einzelheiten zum Datenentwurf sei beispielsweise auf Zehnder 89 oder Navathe et al 92 verwiesen Im Zusammenhang mit der vorliegenden Arbeit ist die Feststellung von Bedeutung dass im Rahmen des Modellierungsprozesses bei allen Schritten Modellierungsfehler auftreten k nnen sei es weil die Realit t aus Komplexit tsgr nden vereinfacht dar gestellt wird sei es weil das verwendete Datenmodell nicht gen gend flexibel ist So bieten logische Datenmodelle typischerweise keine Konstrukte zur Festlegung von Kardinalit ten an Die drei am weitesten verbreiteten logischen Datenmodelle netzwerkartiges hierarchisches relationales erlauben beispielsweise auch keine Darstel
162. n f hrung zus tzlicher neuer Konsistenzbedingungen selten daraufhin berpr ft ob sie diesen auch entsprechen Es kann auch durchaus der Fall eintreten dass ein Anwen dungssystem widerspr chliche Konsistenzbedingungen aufweist die Gew hrleistung der sogenannten Metakonsistenz d h der Konsistenz der Konsistenzbedingungen ist ein noch weitgehend offenes Problem G hler 91 Das erstaunt nicht wenn man bedenkt dass gr ssere Datenbest nde unter Umst nden einer ganz erheblichen Zahl von Konsistenzbedingungen gen gen m ssen Es ist in den meisten F llen ausgesprochen schwierig die Konsistenzbedingungen des Ausgangssystems vollst ndig zu rekonstruieren und festzustellen wann welche Daten unter welchen Konsistenzbedinungen einem System zugef hrt wurden Bei einer Uebernahme bzw Mehrfachnutzung eines Datenbestandes muss deshalb eine Pr fung und allf llige Bereinigung anhand der Konsistenzbedingungen des Zielsystems erfolgen 3 4 KONVERSION 3 4 1 Strukturelle Anpassungen In den meisten F llen bestehen zwischen dem Ausgangs und dem Zielsystem Unter schiede im Anwendungszweck oder bei gleichem Anwendungszweck in der Art der Umsetzung und damit auch in der Datenbeschreibung und Datendarstellung Da Realit tsausschnitte auf sehr verschiedene Arten modelliert und auf Daten abgebildet werden k nnen ist selbst bei Anwendungen die zu einem eng abgrenzbaren Anwen dungsbereich geh ren und im wesentlichen den gle
163. n In einem ersten Schritt musste ein Zugriff auf die Daten auf der Ebene des Betriebssystems gefunden werden Hier konnte aufgrund mehrj h riger Erfahrung rasch die Hypothese gebildet werden dass zur Speicherung der Daten vermutlich eine System aus der Familie der xBase Systeme eingesetzt wurde Die f r solche Systeme typischen Dateinamen sowie die interne Struktur waren aus unerfind lichen Gr nden zwar ver ndert worden diese Aenderungen konnten jedoch mit Hilfe eines Programmes systematisch r ckg ngig gemacht werden so dass die Daten an schliessend mit den vorhandenen DART Analyse Werkzeugen weiter untersucht werden konnten F r diese Untersuchung wurde dann in einem zweiten Schritt ein Vergleich der physisch vorhandenen Daten mit den mit Hilfe des Ausgangssystems erzeugbaren Datendarstellungen diverse Listen angestellt Da aufgrund des Anwen dungsbereichs vermutet werden konnte dass sich die Verarbeitung im wesentlichen auf Additionen einzelner numerischer Werte beschr nkte bestand durchaus Hoff nung durch diese Vergleiche Klarheit ber einzelne Datenwerte zu erhalten Auf grund dieser Analysen gelang die Identifikation der f r eine Daten bernahme ben tig ten Datenelemente Im Verlaufe der Untersuchungen zeigte sich ein weiteres Problem das sich leider nicht befriedigend l sen liess Aufgrund einer unn tig grossen Flexibilit t des Aus gangssystems war es den einzelnen Bankmitarbeitern m glich einen von der Bank vorge
164. n spezieller Import Dienst entwickelt mit dessen Hilfe die Ausgangsdaten direkt in ein geeignetes Format f r das Zielsystem konvertiert werden konnten Da aus organisato rischen Gr nden eine Korrektur der Ausgangsdaten nie zur Diskussion stand und das es sich beim Zielsystem um eine Anwendung handelt die zur Datenverwaltung ein relationales Datenbankverwaltungssystem einsetzt konnten die Phasen drei bis f nf des MIKADO Modelles zusammengefasst werden S mtliche n tigen Anpassungen f r einen Abgleich der unterschiedlichen Bilanzstrukturen wurde mit diesem Import Dienst erledigt 6 4 4 Projektstand Uebernahmedauer Die explorative Uebernahme ist abgeschlossen Der Import Dienst wurde bankintern installiert und getestet Dabei konnten noch einige Verbesserungen angebracht wer den die sich aufdr ngten nachdem festgestellt wurde dass die Ausgangsdaten teil weise unvollst ndig waren Es gelang auch einen Teil dieser Daten bei der Ueber nahme halbautomatisch zu vervollst ndigen Anhand des Mengenger stes kann f r die Durchf hrung der effektiven Uebernahme mit einem Aufwand von einigen weni gen Tagen gerechnet werden Da s mtliche Ausgangsdaten auf Disketten vorliegen muss die effektive Daten bernahme manuell unterst tzt werden Einlegen von Disket ten Die erw hnten Abkl rungen und Entwicklungsarbeiten erstreckten sich ber eine Zeitspanne von rund einem halben Jahr 6 4 5 Beurteilung Vorgehen Die urspr nglich nur
165. n Zielsysteme entweder sehr spezielle Eigenheiten aufwiesen oder aber bereits auf relationaler Technologie basierten F r einen solchen Dienst bestand im Rahmen dieser Arbeit deshalb kein dringender Be darf 5 5 2 Realisierungskonzept Basierend auf den Erfahrungen mit dem ADABAS Import Dienst wurde nach allge meineren L sungen gesucht um eine m glichst grosse Zahl von Ausgangssystemen abdecken zu k nnen Die konkrete Anwendung des ADABAS Import Dienstes zeigte rasch dass ein Import Vorgang typischerweise mehrmals durchgef hrt werden muss insbesondere wenn von fehlenden oder falschen Datenbeschreibungen ausgegangen werden muss Aber auch wenn korrekte Beschreibungen vorliegen k nnen bei fehler hafter Konfiguration des Dienstes mehrere Durchl ufe n tig werden 1 ADABAS Adaptable DAtaBAe System ist ein weit verbreitetes nicht relationales Daten banksystem der Firma Software AG vgl Tsichritzis Lochovsky 77 2 UNIMARC ist die Bezeichnung eines standardisierten Formates f r den Austausch von Bib liotheksdaten vgl UNIMARC 94 WERKZEUGUNTERSTUTZUNG 107 Diese Erkenntnisse fiihrten zu folgendem schrittweisen iterativen Vorgehen inner halb der 3 Phase des MIKADO Modelles 3 Aufbereitung f r das Zwischensystem m gt Ausgangsdaten analysieren t Ausgangsdaten beschreiben J nicht Testen der Beschreibung nicht v Daten des Zwischensystems beschreiben
166. n einzelne Aufgaben gegliedert werden Diese Aufgaben sollten jedoch nicht zwingend in sequentieller Rei henfolge ausgef hrt werden m ssen so dass ein arbeitsteiliges Vorgehen un terst tzt wird Diese Folgerungen werden erg nzt durch eine Reihe von grunds tzlichen Anforde rungen an Vorgehensmodelle Einfachheit Komplexe Vorgehensmodelle sind schwierig anzuwenden Nur ein einfaches leicht lehr und lernbares Modell kann im praktischen Einsatz benutzt werden Zu viele und zu komplexe Phasen erschweren oder verun m glichen eine Anwendung Werkzeugunterst tzung Ein Vorgehensmodell soll ein Problem so in Teilauf gaben zerlegen dass diese durch geeignete Werkzeuge effizient unterst tzt werden k nnen Iteration Ein Vorgehensmodell f r Daten bernahmen muss erlauben Phasen die zu unbefriedigenden Resultaten gef hrt haben zu wiederholen Gegebe nenfalls m ssen sogar mehrere der bereits durchlaufenen Phasen nochmals wiederholt werden Es ist aber zu beachten dass allzu viele Iterationsm g lichkeiten im Widerspruch zur Forderung der Einfachheit stehen und dass ei ne m glichst effiziente Durchf hrung anzustreben ist Iterationen sind nur in begr ndeten F llen angebracht Einsatzbereich Ein Vorgehensmodell sollte f r eine m glichst grosse Klasse von Problemen geeignet sein Bei der Entwicklung von MIKADO wurde versucht diese Aspekte so weit wie m g lich zu ber cksichtigen VORGEHENSMODELLE 93 Gem ss dem MIKAD
167. n im laufenden Betrieb eines Anwendungssystems vorhanden sind Viele dieser Probleme k nnen dabei w hrend l ngerer Zeit unent deckt bleiben Es kann aber auch sein dass man sich ihrer bewusst ist aber aus ir gendwelchen Gr nden meistens konomischen auf eine entsprechende L sung verzichtet In ihrer Gesamtheit bilden solche Probleme aber doch oft letztendlich den Anstoss f r eine Abl sung Ausgangssystemprobleme k nnen mehrere Ursachen haben Grunds tzlich k nnen Schwierigkeiten sowohl beim Entwurf und der Implementierung inklusive der Wei terentwicklung eines Systems als auch durch den laufenden Betrieb entstehen Probleme beim Entwurf und der Implementierung Beim Entwurf eines Anwendungssystems muss zuerst durch Abstraktion eine f r die entsprechende Anwendung relevante Teilsicht auf die Realit t gebildet werden Dieser Vorgang ist nicht formalisierbar und maschinell durchf hrbar und damit fehleranf l lig Auf Probleme die im Zusammenhang mit solchen falschen Modellbildungen DATEN RE ENGINEERING 47 entstehen man konstruiert eine richtige Anwendung f r das falsche Problem wird im folgenden aber nicht eingegangen Diese Probleme stellen sich n mlich grunds tz lich bei jedem Entwicklungsvorhaben und sind deshalb nicht typisch f r die Informa tik Anhand eines geeignet abgegrenzten Realit tsausschnittes erfolgt im Rahmen der Anwendungsentwicklung eine Abbildung von Sachverhalten der Realit t auf Daten
168. n in verschiedenen Richtungen un ternommen Zum einen wurden eine Reihe von Mechanismen zur Verbesserung der weitverbreiteten Modelle namentlich f r das relationale Modell vorgeschlagen Stonebraker 84 Zum anderen wurden eine ganze Reihe neuer Datenmodelle ent 80 DATEN RE ENGINEERING wickelt Dazu sind insbesondere semantische und objektorientierte Datenmodelle zu z hlen Verschiedene Datenbankverwaltungssysteme die semantische Datenmodelle unterst tzen sind zwar als Prototypen vorhanden haben aber bisher keine Marktreife erlangt Hull King 87 Sie sind deshalb f r die Praxis noch weitgehend bedeutungs los Anders pr sentiert sich die Situation bei objektorientierten Datenmodellen Hier ist in den letzten Jahren bereits ein Markt an kommerziellen Produkten entstanden Nachteilig wirkt sich aber die Tatsache aus dass sich bisher keines dieser objektori entierten Datenmodelle als Standard etablieren konnte Objektorientierte Datenmodel le erlauben zwar eine umfassendere Datenbeschreibung als die herk mmlichen Mo delle und k nnen damit eine Daten bernahme erleichtern Garcia Molina et al 95 aufgrund fehlender Standards sowie mangelnder Datenunabh ngigkeit k nnen diese Vorteile aber nur beschr nkt genutzt werden Dem Thema Datenqualit t sollte bereits beim Entwurf eines betrieblichen Anwen dungssystems Beachtung geschenkt werden Insbesondere durch Festlegen und Ue berpr fen geeigneter Konsistenzbedingungen k nnen eine R
169. n zu sein m ssen die Meta Daten erweiterbar sein das heisst innerhalb des Repositoriums m ssen auch Metameta Daten verwaltet werden Das Repositorium bietet eine Reihe von elementaren Funk tionen f r das Bearbeiten der Nutz und Meta Daten an Erzeugen und L schen von Relationen Einf gen L schen und Aendern von Attributen Das Metaschema ist so ausgelegt dass es die Verwaltung elementarer Informationen erlaubt Dazu z hlen Angaben ber Relationen Attribute Beziehungen Attributmengen Beziehungsmen gen und Projekte Unter dem Begriff Projekt werden die Daten bezeichnet die im Rahmen einer konkreten Uebernahme aufbereitet werden sollen Es ist mit DART m glich mehrere solche Uebernahmen zu verwalten das heisst insbesondere auch dass an mehreren solchen Projekten gleichzeitig gearbeitet werden kann Um neben diesen elementaren Informationen die ber einen Datenbestand gesammelt und verwaltet werden sollen auch Informationen verwalten zu k nnen die zur Zeit der Implementation von DART noch nicht bekannt sind wurde das Konzept des Metametaschemas vorgesehen das auch in vielen kommerziellen Produkten zu finden ist Dieses Konzept f r das auch Standards von ISO bzw ANSI existieren Habermann Leymann 93 sieht weitere Schichten oberhalb der Metaebene vor WERKZEUGUNTERST TZUNG 111 Dabei ist der Grundgedanke dass jede Schicht die darunterliegende vollst ndig be schreiben kann Ein solches Metametasche
170. nbankverwaltungssystems Da der Entscheid getroffen wurde f r die Darstellung der Daten im Zwischensystem das Relationen modell zu verwenden lag es nahe f r diese Aufgabe ein relationales DBMS einzuset zen Wie bereits erw hnt wurde das auch in einem ersten Anlauf so gemacht Insbe sondere bot der Einsatz eines relationalen DBMS f r diese Zwecke auch den Vorteil einer bereits vorhandenen Transaktionsverwaltung so dass gegebenenfalls Aenderun gen an den Daten recht einfach wieder r ckg ngig gemacht werden k nnten eine Eigenschaft die sehr w nschbar ist f r ein Experimentiersystem Der Einsatz eines relationalen DBMS erwies sich jedoch als ungeeignet Dies vor allem deshalb weil mit einem solchen System den speziellen Eigenschaften des Problems zuwenig Rech nung getragen wird Innerhalb der Aufbereitungsphase ist n mlich mit h ufigen Struktur nderungen Einf gen von Attributen Aendern eines Datentyps Aufteilen von Attributen zu rechnen Diese Aenderungen m ssen berdies oft an grossen Datenbest nden durchgef hrt werden F r solche Struktur nderungen sind relationale DBMS jedoch ausserordentlich schlecht geeignet sie sind vielmehr optimiert hin sichtlich der Effizienz von Anfragen sowie f r das Einf gen einzelner Datenwerte F r die endg ltige Realisierung wurde deshalb eine Kompromissl sung gew hlt F r die Verwaltung der Meta Daten bei denen es sich im Vergleich zu den Nutzdaten ja um sehr geringe Mengen ha
171. nbestand insbesondere auch noch f r weitere Zwecke verwendet werden Solche zus tzlichen Verwendungen sind auch bereits geplant z B sollen die Daten auch so aufbereitet werden dass ber das World Wide Web auf sie zugegriffen werden kann Werkzeugunterst tzung Die f r die Uebernahme ins Zwischen bzw Zielsystem entwickelten Werkzeuge haben sich im realen Einsatz bew hrt Sie lieferten auch wesentliche Erkenntnisse zum Entwurf allgemeiner benutzbarer Werkzeuge und haben vor allem die Entwick lung von Analysediensten stark beeinflusst F r die Korrektur der Daten empfiehlt sich die Entwicklung eines eigenst ndigen Korrekturprogrammes losgel st von DART 6 3 FALLSTUDIE B ETHICS 6 3 1 Ausgangslage Problemstellung In der Schweiz gibt es zur Zeit mehr als sechstausend ffentliche Bibliotheken wobei sehr unterschiedliche Gr ssen anzutreffen sind Diese reichen von mobilen Biblio FALLSTUDIEN 129 theksbussen mit einigen hundert bibliographischen Einheiten bis hin zu Grossbiblio theken wie die ETH Bibliothek mit mehr als vier Millionen bibliographischen Ein heiten Es wird gesch tzt dass in all diesen Bibliotheken zusammen insgesamt rund 7x10 bibliographische Einheiten vorhanden sind Diese Menge w chst um rund 2 5x10 katalogisierte bibliographische Einheiten pro Jahr Clavel 94 Die gr sseren dieser Bibliotheken verf gen ber einen in der Regel ffentlich zug nglichen Katalog der zumindest
172. ndelt wird ein relationales DBMS eingesetzt Die Verwal 110 WERKZEUGUNTERSTUTZUNG tung der Nutzdaten erfolgt mit einem Datenverwaltungssystem aus der Familie der sogenannten xBase Systeme Beide Produkte stammen von der Firma Computer Associates Das eingesetzte Datenverwaltungssystem erm glicht effiziente Struktur nderungen bietet daf r aber keine Transaktionsverwaltung Um unabh ngig von einem bestimmten relationalen DBMS zu bleiben wurde der Zugriff zu den Meta Daten via ODBC Open DataBase Connectivity realisiert was einen Austausch des verwendeten DBMS stark erleichtert Meta Daten relationales DBMS Datenverwaltung Fig 5 4 Realisierungskonzept der Datenverwaltung Diese L sung bietet zudem den Vorteil dass das Format in dem die Nutzdaten abge legt sind xBase Dateien sehr weit verbreitet ist so dass auch f r eine Weiterverar beitung der Daten ausserhalb von DART oder f r sonstige Zwecke die Daten f r sehr viele Werkzeuge direkt verarbeitbar sind z B f r Analysen mit Werkzeugen die nicht Bestandteil von DART sind Das xBase Datenformat hat gegen ber einer Spei cherung in Form flacher Dateien zudem den Vorteil dass es auch Metainformatio nen enth lt Name und Datentypen der einzelnen Attribute Anzahl Tupel Repositorium Die Aufgabe des Repositoriums besteht in der Verwaltung der Nutz und Meta Daten Um f r k nftige Verwendungen m glichst offe
173. ne umfangreiche Beschreibung des Austauschformates vorhanden UNIMARC 94 Diese Beschreibung ist auf der logischen Ebene einzu ordnen 6 3 3 Vorgehen Abgrenzung und Voranalyse Als eines der gr sseren Probleme hat sich zu Beginn der Arbeit das weitgehend feh lende Anwendungswissen herausgestellt Die vorhandenen Kenntnisse als Benutzer des ETHICS Systems reichten f r ein Verst ndnis der umfangreichen Unterlagen und komplex strukturierten Daten nicht weit Es wurde deshalb entschieden f r diese Wissenserarbeitung ein eigenes Projekt zu starten Im Rahmen dieses Partnerprojek tes das nicht vom Autor der vorliegenden Arbeit durchgef hrt wurde wurde vorab durch detailliertes Studium der vorhandenen Unterlagen ein umfangreiches Glossar erstellt um sich mit der im Bibliothekswesen und vor allem auch in ETHICS verwen deten Begriffswelt vertraut zu machen Dieses Glossar hat sich insbesondere auch bei der Kommunikation mit den Betreibern des Systems sehr gut bew hrt da dadurch rasch eine gemeinsame Sprache gefunden werden konnte Basierend auf den zur Verf gung stehenden Unterlagen sowie durch detaillierte Untersuchungen der zur Verf gung stehenden Daten wurde dann mit der Rekonstruktion eines konzeptionel len Schemas begonnen Diese Arbeit gedieh recht weit aufgrund des Umfanges dieses Schemas rund 90 FEntit tsmengen mit sehr vielen Beziehungen gelang es aber aus Zeitgr nden nicht v llig dieses wirklich im Detail mit den Betreibern
174. nen wird der Entscheid tiber eine Durchf hrung der Daten bernahme gef llt In vielen F llen wird der Entschei dungsspielraum gering sein weil die Uebernahme auf jeden Fall erfolgen muss namentlich bei externen Problemausl sern Es sind aber auch F lle denkbar bei denen auf eine Uebernahme verzichtet wird sei es weil alternative Datenquellen bestehen Nacherfassen Fremdbeschaffen sei es weil eine Uebernahme auf sp ter verschoben wird weil sich dann bespielsweise die Umweltbedingungen soweit ver ndert haben werden dass eine Neubeurteilung des Problems sinnvoll wird Phase 3 Aufbereitung f r das Zwischensystem Zweck Uebernehmen der Daten aus dem Ausgangs in ein Zwischensy stem Voraussetzungen Ausgangsdatenbestand mit bekanntem physischem Schema das eine pr zise Dimensionierung des Zwischensystems erlaubt Ziel Resultate Datenbestand im gew hlten Zwischensystem Logisches Schema VORGEHENSMODELLE 97 In dieser Phase erfolgt die Uebernahme der Daten in das Zwischensystem Dabei ist sorgf ltig darauf zu achten dass dabei keine Informationen verloren gehen In dieser Phase kann aber durchaus bereits eine Reduktion der zu bernehmenden Daten erfol gen wenn diese nicht bereits im Ausgangssystem m glich oder dort zu aufwendig ist Bei dieser Uebernahme werden die Daten von allen ausgangssystemspezifischen Eigenheiten der physischen Repr sentation beispielsweise sogenannte Headerdaten bei einer Speicherung auf B
175. nformationen und zu ihrer Ueberpr fung k nnen beispielsweise folgende Quellen beigezogen werden e Programmquellen Objektcode Job Control Language e Datenschemas Nutzdaten e Verzeichnisstrukturen Makefiles Linkmaps e Programm Systemdokumentationen e Entwickler falls noch verf gbar e Benutzer Im Idealfall ist das Ausgangssystem gen gend pr zis dokumentiert so dass die f r die Daten bernahme ben tigten Informationen vorliegen und gegebenenfalls h chstens noch berpr ft werden muss ob sie noch aktuell sind Diese Situation ist bei Legacy Systemen nicht zu erwarten vielmehr wird man in praktischen F llen nur selten dar um herumkommen gewisse Informationen zu rekonstruieren Nach M glichkeit sollten zu diesem Zweck verschiedene Quellen beigezogen und die entsprechenden Informationen miteinander verglichen und allenfalls vorhandene Widerspr che aufge l st werden Bei Legacy Systemen ist man leider oft mit Situationen konfrontiert bei denen nur noch das in Betrieb stehende Anwendungssystem und seine Benutzer als wirklich zuverl ssige Informationsquelle zur Verf gung steht 3 3 4 Schemarekonstruktion Wie bereits erl utert wurde erfolgt ein moderner Daten Entwurfsprozess in mehreren Stufen konzeptionell logisch physisch wobei pro Stufe entsprechende Entwurfs dokumente Schemas anfallen Der Gedanke liegt deshalb nahe ausgehend vom in Betrieb stehenden Anwendungssystem diese Darstellungen auf den
176. ng dieses Problems sehr rasch zu ganz erhebli chen Aufwendungen f hren kann Dabei werden regelm ssig sowohl die f r eine manuelle Datenkorrektur einzusetzenden Personalkosten als auch die f r eine seri se Korrektur aufzuwendende Zeit deutlich untersch tzt Da es sich bei allen durchgef hrten Projekten um kleine Daten bernahmen handel te die von einer einzelnen Person im Rahmen von wenigen Monaten durchgef hrt werden konnten bestehen noch keine einschl gigen Erfahrungen bei gr sseren Pro jekten die nur arbeitsteilig durchgef hrt werden k nnen Das Vorgehensmodell MIKADO eignet sich nur f r Daten bernahmesituationen bei denen gen gend Zeit f r eine Zwischenphase vorhanden ist in welcher eine gr ndli che Aufbereitung der Daten vorgenommen werden kann F r Situationen bei denen eine dauernde Verf gbarkeit der Daten gew hrleistet sein muss ist dieses Vorgehen nicht anwendbar Solche direkten Daten bernahmen stellen auch wenn sie geeignet BEURTEILUNG UND AUSBLICK 143 in Teildaten bernahmen zerlegt werden zus tzliche Anforderungen f r die noch weitere Grundlagen zu erarbeiten sind 7 2 OFFENE FRAGEN AUSBLICK Daten bernahmen stellen in der heutigen Informatikpraxis ein h ufiges und wieder kehrendes Problem dar Trotzdem ist die Fragestellung noch weitgehend unbearbeitet welche Lehren aus konkreten Daten bernahmeprojekten f r die Gestaltung von neuen Anwendungssystemen zu ziehen sind Heute wird
177. ngigkeit von den aktuellen Werten in anderen Datenelementen ganz un terschiedliche Bedeutungen haben e Modellierungsunterschiede An sich gleiche Sachverhalte wurden unter Um st nden in verschiedenen Anwendungen unterschiedlich modelliert z B einmal als Attribut ein anderes mal als Entit tsmenge Eine Reihe weiterer Probleme sind in Ventrone Heiler 91 oder Hainout et al 95 zu finden Es darf auch nicht vergessen werden dass die Weiter entwicklung von Anwendungssystemen oft durch verschiedene Personen mit unterschiedlicher Ausbil dung und unter Anwendung sehr verschiedener Methoden und Werkzeuge erfolgt 48 DATEN RE ENGINEERING Probleme beim Betrieb Neben den bereits durch die Realisierung verursachten Problemen entstehen auch durch die reine Benutzung eines Anwendungssystems Probleme Diese Probleme k nnen sehr verschiedene Ursachen haben Als m gliche Fehlerquellen sind insbe sondere zu nennen e Realit tsver nderungen Die durch Daten festgehaltenen Sachverhalte sind aufgrund der sich kontinuierlich ndernden Realit t in der Regel h ufigen Aenderungen unterworfen Werden diese Realit ts nderungen nicht in den Daten nachgef hrt so werden die Daten falsch oder zumindest ungenau e Ein Ausgabe Die manuelle Eingabe von Daten in der Regel die weitaus bedeutsamste Eingabeart bei betrieblichen Anwendungssystemen stellt eine wesentliche Fehlerquelle dar Beispielsweise k nnen aufgrund von Tippfeh lern formal r
178. nnte Eine Reihe von Projekten sind mit dieser Strategie gescheitert entsprechende Hin weise sind beispielsweise in Brodie Stonebraker 95 zu finden Im Laufe der Jahre sind teilweise Systeme einer Gr ssenordnung entstanden die im Sinne dieser Alles auf einmal Strategie auch bei Einsatz erheblichster Ressourcen als grunds tzlich nicht mehr abl sbar zu betrachten sind beispielsweise Flugreserva tionssysteme 4 2 3 Die inkrementelle Strategie Im Gegensatz zur Alles auf einmal Strategie wird bei dieser Strategie eine Ueber nahme in mehreren Teilschritten durchgef hrt Dies erfordert jedoch dass das Aus gangssystem geeignet in einzelne Teile zerlegt werden kann Die Uebernahme einzel ner Teile hat zur Konsequenz dass das Ausgangssystem mit Teilen des Zielsystems unter Umst nden ber l ngere Zeit koexistieren muss Durch eine Aufteilung der Uebernahme in mehrere Teil bernahmen kann das Gesamt risiko deutlich gesenkt werden im schlimmsten Falle ist immer nur mit dem Abbruch und der Wiederholung eines einzelnen Uebernahmeschrittes zu rechnen VORGEHENSMODELLE 85 Gateways und Wrapper Die Abl sung einzelner Komponenten und die Koexistenz von Ausgangs und Ziel system stellt unter Umst nden hohe technische Anforderungen m ssen doch kom plexe Systeme oder zumindest Teile davon mit sehr unterschiedlicher Technologie miteinander ber geeignete Schnittstellen verbunden werden Zur Realisierung sol
179. nsistenzbedingungen erf llen Der Begriff Datenbe schreibung ist in diesem Kontext allerdings sehr breit zu verstehen Er umfasst in diesem Zusammenhang auch die einzelnen Anwendungsprogramme Konsistenz bedeutet aber nicht automatisch die Uebereinstimmung der Daten mit den entsprechenden Sachverhalten der realen Welt Aebi 94 Diese Uebereinstimmung kann nur im Rahmen von sogenannten Validierungsprozessen festgestellt werden Es ist zu beachten dass Validierungsprozesse nicht automatisierbar sind Es ist dabei zu unterscheiden zwischen Verifikation und Validation Verifikation Pr fung ob Daten mit ihrer Beschreibung bereinstimmen Validation Pr fung ob Daten mit den entsprechenden Sachverhalten der Realit t bereinstimmen Realit ts ausschnitt Cc g oO Ze oO E Metadaten lt c E 3 S ile T x O co 8 s jS Q gt Daten Fig 3 6 Verifikation Validation 60 DATEN RE ENGINEERING Konsistenzbedingungen lassen sich nach einer Vielzahl von Kriterien klassifizieren Wichtig im Zusammenhang mit dem Problemkreis Daten Reverse Engineering ist vor allem die Unterscheidung in modellinh rente und modellexterne Zehnder 89 bzw in statische und dynamische Konsistenzbedingungen G hler 91 Modellinh rente Konsistenzbedingungen sind solche die mit Mitteln des entsprechenden Datenmodel les formuliert und durch das Datenverwaltungssystem gepr ft werden k nnen Mo
180. nte einer Informa tikl sung so dass es schon aus rein wirtschaftlichen Gr nden n tig ist sie weiter zu nutzen Hinzu kommt dass Datenbest nde typischerweise weder nacherfasst noch eingekauft oder sonstwie nachtr glich wiederbeschafft werden k nnen so dass deren Aufbereitung und Weiternutzung zwingend notwendig ist Diese Datenaufbereitung und bernahme im folgenden mit dem Begriff Daten Re Engineering bezeichnet ist unter anderem aus folgenden Gr nden problematisch e Sowohl Ausgangs als auch Zielsysteme sind sehr verschiedenartig Damit sind einmal gemachte Erfahrungen und entwickelte L sungsverfahren nur bedingt auf In diesem Zusammenhang h ufig verwendete Schlagworte sind zur Zeit Downsizing bezie hungsweise Rightsizing Auch die aktuelle Diskussion unter dem Stichwort Client Server geh rt in dieses Problemumfeld Eine pr zise Erl uterung der verwendeten Begriffe wird in Kapitel 2 gegeben EINLEITUNG 13 andere Situationen bertragbar Eine Entkoppelung der Datenverwaltung von den Anwendungsprogrammen und damit verbunden auch eine Zentralisierung und Zusammenfassung von Datenbest nden durch den Einsatz von Datenbankverwal tungssystemen bringt oft eine Vereinfachung Es ist in diesem Zusammenhang je doch zu beachten dass nach wie vor sehr viele Anwendungen nicht auf Daten bankverwaltungssystemen basieren Neuere Untersuchungen haben zum Beispiel gezeigt dass nur f r die Verwaltung eines
181. nten eine gewisse Vertrautheit mit den Problemen geschaffen werden Im Rahmen dieser Expe rimentierphase kann in g nstigen F llen bereits die Daten bernahme erfolgen Typischerweise wird jedoch basierend auf den gewonnenen Erkenntnissen erst anschliessend eine Uebernahme des aktuellen Datenbestandes erfolgen 92 VORGEHENSMODELLE Zur Vermeidung von unkontrollierten Nebeneffekten soll das Ausgangssy stem m glichst nicht ver ndert werden daher auch der Name MIKADO Die Daten werden deshalb f r die Uebernahme vom Ausgangssystem getrennt Dies hat zur Konsequenz dass bei einer Uebernahme von Daten mit hohem Aktualit tsgrad zumindest kurzzeitig ein Betriebsunterbruch m glich sein muss Einsatz eines Zwischensystems Eine Abschottung der Daten von Eigenheiten des Ausgangs und des Zielsystems erleichtert die Aufbereitung der Daten Gewisse Arbeiten k nnen so bereits ausgef hrt werden auch wenn das Ziel system noch nicht fertig ist Diese Isolierung erleichtert namentlich auch eine Mehrfachnutzung Verwendungsflexibilitat Da zu Beginn eines Abl sungsprojektes das Zielsy stem unter Umst nden noch nicht pr zise definiert ist z B weil es noch in Entwicklung ist oder weil die Daten f r eine Mehrfachnutzung aufbereitet werden sollen soll die Anpassung ans Zielssystem so sp t wie m glich vor genommen werden Gliederung Da ein Daten bernahmeprozess unter Umst nden recht lange dauern kann muss der gesamte Vorgang i
182. nterscheiden sich zwar sowohl in der Anzahl und Benen nung der einzelnen Phasen sowie im Grad der m glichen Iterationen zwischen den einzelnen Phasen ihnen allen gemeinsam ist jedoch eine Beschr nkung auf den Ent wicklungsprozess d h ihr Einsatzbereich endet mit der Inbetriebnahme einer An wendung allenfalls kann noch eine Nachkontrolle anschliessen F r diese klassi schen Modelle findet man gelegentlich auch den in diesem Zusammenhang aller dings unkorrekten Begriff Lebenszyklusmodell Diese klassischen Vorgehensmodelle gehen davon aus dass sich die Anforderungen an eine Anwendung im Laufe des Entwicklungprozesses nicht wesentlich ver ndern Sie eignen sich deshalb gut f r Neuentwicklungen mit berblickbarer Entwicklungs zeit und pr zise festlegbarem Funktionsumfang Sie eignen sich aber schlecht f r Entwicklungsvorhaben oder f r die Pflege und Weiterentwicklung bestehender An wendungen in einem sich rasch ndernden Umfeld Um diese Beschr nkungen der klassischen Modelle aufzuheben wurden eine Reihe von Konzepten vorgeschlagen In diesem Zusammenhang sind namentlich zu erw h nen e Prototypenbildung e Pilotprojekte e Evolution re Weiterentwicklung e Inkrementelle Vervollst ndigung Diese Konzepte wurden teilweise auch zu eigenst ndigen Vorgehensmodellen ausge baut Oertly 91 Bischofberger Pomberger 92 Janes 93 Diese Konzepte sind jedoch schwierig pr zise gegeneinander abzugrenzen Als wesentliche
183. nutzung sind auch eine Reihe von juristischen Fragen zu kl ren So ist vor allem die Frage der Eigen tumsrechte an Datenbest nden gelegentlich nicht ganz einfach zu beantworten Aber auch Fragen im Zusammenhang mit der Rechtm ssigkeit von Reverse Engineering Massnahmen sind seri s abzukl ren Samuelson 90 Kindermann 92 Bei der Ue bernahme von Datenbest nden ist regelm ssig auch den Problembereichen Daten schutz und Datensicherung geb hrende Aufmerksamkeit zu schenken Im Rahmen der schweizerischen Gesetzgebung fanden einige dieser Probleme zu Beginn der neunzi ger Jahre Eingang in entsprechende Gesetzestexte Urheberrechtsgesetz Datenschutz gesetz Strafrecht 144 BEURTEILUNG UND AUSBLICK Solange es sich um rein innerbetriebliche Daten bernahmen handelt bleibt die Situa tion in der Regel bersichtlich Im Zusammenhang mit globalen Informationssyste men z B World Wide Web bei denen unter Umst nden eine Daten bernahme aus sehr unterschiedlichen Quellen oft auch ber L ndergrenzen hinweg erfolgt wird die rechtliche Situation aber rasch sehr un bersichtlich 145 LITERATURVERZEICHNIS Aebi 93 Aebi D Reverse Engineering Auch bei kleinen Projekten sinnvoll OUTPUT Nr 4 1993 S 40 41 Aebi 94 Aebi D Re Engineering und Oualit t von Daten Datenbest nde wollen umhegt und gepflegt sein OUTPUT Nr 2 1994 S 43 45 Aebi 95 Aebi D Daten bernahme FILE 2 Interner Projektbericht Ins
184. och auch F lle denkbar die eine automatische Ueberpr fung und Verbesserung beispielsweise durch einen Datenabgleich anhand von Referenzdaten erlauben 3 6 KLASSIFIZIERUNG VON DATEN BERNAHMEN Bei der Durchf hrung einer Daten bernahme m ssen eine ganze Reihe von teilweise sehr komplexen Problemen gel st werden Um ein konkret vorliegendes Daten ber nahmeproblem besser beurteilen zu k nnen ist deshalb eine Klassifizierung verschie denartiger Typen von Daten bernahmen hilfreich Eine solche Klassifizierung sollte rasch eine erste grobe Problembeurteilung erlauben Es ist deshalb angezeigt sich f r eine solche Klassifizierung auf einige wenige einfach erkennbare Kriterien zu be schr nken Die Klassifikationskriterien sollten dabei untereinander m glichst ortho gonal sein Aufgrund einer solchen Klassifizierung wird insbesondere die Wahl einer DATEN RE ENGINEERING 73 geeigneten Vorgehensweise erleichtert F r die folgende Klassifizierung wurden Kriterien ber cksichtigt die ohne grossen Aufwand beurteilt werden k nnen Auspr gungen Problemtyp T Uebernahme Ersatz eines bestehenden Anwendungs T systems durch ein neues Die vorhande nen Datenbest nde werden f r die weite re Verwendung im neuen System ber nommen Der Betrieb des alten Systems wird nach Inbetriebnahme des neuen Systems eingestellt Mehrfachnutzung Verwendung der Daten eines bestehen T den Anwendungssystems in zus tzlichen M Anwendungssyst
185. odellen nebst der Entwicklung auch der Betrieb inkl Wartung und die Ausserbetriebsetzung Abl sung bzw Betriebseinstel lung mit behandelt werden Charakteristisch f r die meisten dieser Modelle ist dass sie einzelne Phasen unter scheiden die in einer zeitlichen Abfolge durchlaufen werden Solche Abfolgen lassen sich als gerichtete Graphen sog Phasenfolgedarstellungen repr sentieren F r eine konkrete Anwendung ergibt sich genau eine Auspr gung einer solchen Phasenfolge darstellung Erste Vorgehensmodelle f r die Gliederung des Anwendungsentwicklungsprozesses entstanden in den siebziger Jahren wobei als fr heste Arbeit allgemein Royce 70 anerkannt ist Detaillierte Ausf hrungen sind aber namentlich auch in Boehm 76 zu finden Diese Arbeiten gliedern den Prozess in eine im wesentlichen linear zu durch laufende Folge von Phasen Zyklen sind h chstens zwischen zwei benachbarten Pha sen zugelassen Solche Modelle werden heute als klassische Phasenmodelle be zeichnet Gelegentlich wird f r diese Art von Modellen auch der Begriff Wasserfallmodell benutzt da die Ergebnisse einer Phase als Eingaben in die darauf folgende Phase fliessen 82 VORGEHENSMODELLE Analyse a Entwurf m Program mierung Test Fig 4 1 Wasserfallmodell schematisch Im Laufe der Jahre sind eine ganze Reihe solcher linearer Modelle mit vergleichbarem Aufbau entstanden Diese u
186. oder auch 9 Bits zu einem Byte zusammengefasst werden Daten die mit einem Anwendungssystem verarbeitet werden sollen m ssen letztend lich geeignet als Folgen einzelner Bits dargestellt codiert werden Dabei erfolgt normalerweise ausgehend von der Darstellung als Bitfolge eine Abstraktion ber mehrere Stufen Bei einer Daten bernahme stellen sich in diesem Zusammenhang insbesondere folgende Probleme e Codierung von Zeichen Zur maschinellen Verarbeitung einzelner Zeichen ei nes Alphabets m ssen diese auf Bitfolgen abgebildet werden Da insbesonde re zur Verarbeitung textueller Daten eine Vielzahl unterschiedlicher Zeichen zu verarbeiten sind aber aus Gr nden einer effizienten Verarbeitung h ufig eine Abbildung eines Zeichens auf ein Oktett vorgenommen wurde entstan den eine ganze Reihe solcher Abbildungen sogenannte Codes Einige dieser Abbildungen wurden von internationalen Gremien standardisiert Als wichtige Vertreter solcher Codes sind ASCII und EBCDIC zu nennen F r eine Daten DATEN RE ENGINEERING 63 bernahme kann diese unterschiedliche Codierung von erheblicher Bedeutung sein h ufig muss bei einer Uebernahme eine Umcodierung erfolgen Dies muss mit sehr viel Sorgfalt geschehen insbesondere wenn der im Ausgangs system verwendete Code m chtiger als derjenige des Zielsystems ist Schil ling 95 Heute k nnen auch Mehrbytecodes d h Codes die ein einzelnes Zeichen in eine Folge von mehreren Bytes abbilden
187. ohne allzu detaillierte Abkl rungen erkannt werden k nnen Neben diesen einfachen Kriterien sind f r eine seri se Beurteilung selbstverst ndlich eine ganze Reihe weiterer Problemeigenschaften von grosser Bedeutung Dazu z hlen namentlich die Zerlegbarkeit von Ausgangs und Zielsystem vorhandene Ressourcen f r die Durchf hrung einer Daten bernahme personell und materiell oder auch die Zeitverh ltnisse Diese Kriterien m ssen jedoch im konkret vorliegenden Einzelfall genau untersucht werden und eignen sich deshalb f r eine erste grobe Beurteilung nur schlecht 3 7 BEISPIEL Anhand eines bewusst sehr einfach gehaltenen Beispieles sollen einige der im Rah men einer Daten bernahme zu l senden Einzelprobleme nochmals konkret veran schaulicht werden Insbesondere soll damit gezeigt werden dass bereits in sehr einfa chen Verh ltnissen eine ganze Reihe von unterschiedlichen Aufgaben zu l sen sind Zu diesem Zweck soll ein Teilbereich eines Anwendungssystems betrachtet werden das zur Verwaltung von Studentendaten eingesetzt wird Es sei angenommen dass die Datenverwaltung des Ausgangssystems bisher ein einfaches Dateisystem nun durch ein relationales Datenbankverwaltungssystem abzu l sen sei Im weiteren sei angenommen dass bisher alle Informationen zu den einzel nen Studenten in einer einzigen Datei mit folgender Recordstruktur gespeichert wur den Notation PASCAL TYPE Student RECORD
188. olgen Zur Abkl rung der Probleme einer solchen m glichst weitgehenden Katalogintegra tion wurde 1993 ein entsprechender Projektauftrag an die Schweizerische Landesbi bliothek erteilt Da bei diesen Abkl rungen auch eine Reihe von Daten bernahme problemen untersucht werden m ssen sollten unabh ngig vom oben erw hnten Projektauftrag im Rahmen der vorliegenden Arbeit die Probleme einer Uebernahme von Daten der ETH Bibliothek in einen solchen zentralen Katalog untersucht werden Da eine solche Katalogintegration eine ganze Reihe von technischen juristischen und organisatorischen Fragen aufwirft sollten vorerst nur im Sinne einer Machbarkeits studie die auftretenden technischen Probleme studiert werden Eine konkrete Durchf hrung der Daten bernahme war nicht vorgesehen 2l Der Begriff bibliographische Einheit bezeichnet die einzeln identifizierten Objekte in einer Bibliothek Darunter fallen nebst B chern Monographien Sammelb nde auch Zeitschrif tenhefte oder b nde Karten Notenbl tter und andere Dokumente 130 FALLSTUDIEN 6 3 2 Beurteilung der Aufgabe Die geschilderte Aufgabe hat eine Reihe von speziellen Eigenschaften die f r eine Probleml sung zu ber cksichtigen waren e Zeitverhdltnisse Die Aufgabe war weitgehend zeitunkritisch Ein definierter Zeitpunkt f r das Vorliegen von Resultaten war nicht vorgegeben e Ausgangssystemunabh ngigkeit Das Ausgangssystem wurde allenfalls mit
189. olgende zwei Systeme zum Vergleich an Ihe Integrated Chameleon Architecture ICA und DBMAIN Beide werden im folgenden kurz beschrieben 5 9 2 The Integrated Chameleon Architecture ICA Mit dem Begriff The Integrated Chameleon Architecture ICA wird ein Projekt der Ohio State University USA bezeichnet Mamrak et al 89 Im Rahmen dieses Pro jektes wurden Verfahren und Werkzeuge f r die Uebernahme von Daten aus Textver arbeitungssystemen entwickelt Es wurden mehrere Personenjahre in das Projekt investiert Textdaten stellen aufgrund ihrer komplexen inneren Struktur hohe Anforderungen an eine Uebernahme da nicht nur die Texte selbst sondern auch Strukturinformationen Abs tze Formatierungen Titel Seitenaufteilungen usf bernommen und angepasst werden m ssen ICA kann als Uebersetzer Generierungswerkzeug charakterisiert werden Das Erstel len formaler Beschreibungen von Textdaten des Ausgangs bzw Zielsystems wird sowohl methodisch als auch durch Werkzeuge unterst tzt Anhand solcher Beschrei bungen k nnen Uebersetzungsprogramme generiert werden ICA wurde f r die Ue bernahme von Daten aus Textsystemen die logische Einheiten eines Textes unter scheiden Abschnitte Unterabschnitte usf und diese Einheiten hierarchisch struktu rieren entwickelt Zu dieser Klasse von Systemen z hlen insbesondere eine Reihe von sogenannten Textformatierern TeX TROFF Scribe ICA umfasst Werkzeuge f r Spezif
190. on eines m g lichst vollst ndigen logischen oder gar konzeptionellen Schemas anzustreben In der Praxis wird man sich h ufig mit unvollst ndigen Informationen auf verschiedenen Stufen zufrieden geben m ssen Konzeptionelles Schema t Logisches Schema t Physisches Schema Daten es gt Fig 3 5 M glichkeiten der Schema Rekonstruktion Untersucht man eine Reihe bisher bekannter Arbeiten zum Thema Schema Rekonstruktion so f llt auf dass je nach Ausgangssystem verschiedene Strategien zur Anwendung gelangen Arbeiten die sich mit relationalen Systemen besch ftigen beispielsweise Premerlani Blaha 92 Chiang et al 94 Cardenas Wang 85 58 DATEN RE ENGINEERING Navathe Awong 88 Davis Arora 88 oder Briand et al 88 konzentrieren sich meist darauf ausgehend von einem logischen Schema eine Rekonstruktion eines konzeptionellen Schemas durchzuf hren Dabei werden jedoch f r die vorgeschlage nen Verfahren oft zu restriktive Anforderungen an die Ausgangssysteme gestellt z B dass s mtliche Daten in dritter Normalform vorliegen m ssen dass Schl s sel Fremdschl ssel Beziehungen bekannt sind Aufgrund der Tatsache dass erst ein kleiner Anteil der heute in Betrieb stehenden Anwendungssysteme auf relationa len Datenbankverwaltungssystemen basiert haben diese Arbeiten auf aktuelle Abl sungen noch wenig Einfluss Arbeiten die sich mit dem Daten R
191. onen partitioniert d h es sind Daten aus einer Reihe von identischen Ausgangssystemen zu bernehmen es liegt eine grosse Zahl kleinerer Datenbest nde vor eine Diskette pro Kunde Eine Analyse der Ausgangsdaten legte die Vermutung nahe dass zur Anwendungs entwicklung und zur Datenverwaltung eine Variante eines xBase Systemes eingesetzt wurde Nach entsprechender Anpassung durch ein hierf r speziell entwickeltes Pro gramm konnten die Daten mit einem solchen System weiterverarbeitet werden Eine betriebsf hige Installation des Anwendungsprogrammes stand zur Verf gung 138 FALLSTUDIEN Zielsystem Das Zielsystem wurde leider weitgehend unabh ngig vom Ausgangssystem entwik kelt Die Problembereiche von Ausgangs und Zielsystem sind zwar weitgehend identisch die Strukturierung und Darstellung der Daten waren aber soweit ber haupt erkennbar sehr unterschiedlich gel st worden Das Problem der Daten ber nahme wurde beim Entwurf der neuen Anwendung nicht ber cksichtigt Zur Entwick lung der neuen Anwendung gelangte SQL Forms ein Entwicklungswerkzeug der Firma Oracle zum Einsatz Als Datenbankverwaltungssystem wird Oracle einge setzt Die neue Anwendung befand sich zur Zeit der vorliegenden Untersuchung im Endstadium der Entwicklung Art und Umfang der Daten Zugriffssebenen Die Vermutung lag nahe dass es sich bei den Ausgangsdaten im wesentlichen um eine gr ssere Anzahl numerischer Werte handelte was ein vis
192. r hat auch stets den Bezug zur Praxis gesucht und gef rdert Prof L Richter bin ich zu grossem Dank verpflichtet f r die Uebernahme des Korre ferates und f r seine konstruktiven Anmerkungen die zu einer Verbesserung der Arbeit beigetragen haben Die vorgeschlagenen Probleml sungsans tze konnten dank der freundlichen Unter st tzung mehrerer externer Informatiker auch anhand konkreter Praxisprobleme im Rahmen von drei Fallstudien berpr ft werden Besonderer Dank geb hrt hier vor allem A Sidler R N thiger und C Schucan die mir die konkreten Daten f r meine Experimente zur Verf gung stellten Dank geb hrt auch einer Reihe von Studenten deren Diplomarbeiten n tzliche Bei tr ge lieferten und die mir in unz hligen Diskussionen eine Reihe wertvoller Einsich ten vermittelt haben Namentlich sind hier C Schucan R Pfund M Br ndli R Rossi und M Hochstrasser zu nennen Aber auch allen anderen die im Rahmen von Studen tenarbeiten an diesem Projekt gearbeitet haben sei herzlich gedankt Ganz besonders ist aber auch R Largo zu erw hnen der diese Arbeit nicht nur oft sachlich unterst tzt hat sondern der stets auch um ein angenehmes Arbeitsklima besorgt war und mit dem mich die Erinnerung an viele fr hliche Stunden verbindet Ein spezieller Dank richtet sich auch an meine Eltern und meine Lebensgef hrtin Brigitte ohne sie alle w re diese Arbeit nicht entstanden INHALTSVERZEICHNIS VORWORT INHALTSVERZEICHNIS
193. rd wobei die vorhandenen Daten best nde zwar bernommen dabei aber wesentlich ver ndert und umstrukturiert werden 36 GRUNDLAGEN UND BEGRIFFE Aufbau Betrieb Ersterfassung Uebernahme Fremdbeschaffung Vorbereitung Archivierung Entsorgung Zeit Fig 2 10 Daten Lebenszyklusmodell Vorbereitung In der Phase Vorbereitung werden alle Massnahmen zusammengefasst die getroffen werden m ssen bevor ein Anwendungssystem in den produktiven Betrieb gehen kann Neben dem technischen Aufbau des Anwendungssystems ist auch festzulegen welche Daten in welcher Form wann und in welcher Qualit t gebraucht werden Im Zusammenhang mit den Daten betrifft die wohl wichtigste Frage die Regelung der Datenbeschaffung und zwar f r den Aufbau wie f r den sp teren Betrieb Neben einer internen Ersterfassung oder einer Uebernahme aus einem vorhandenen System ist insbesondere eine m gliche Fremdbeschaffung der Daten zu pr fen Dazu ist abzukl ren ob ein Marktangebot besteht oder allenfalls angeregt werden kann Bsp Adress daten Gegebenenfalls sind Datenliefervertr ge abzuschliessen Auch das Datenein gabepersonal ist zu schulen Aufbau In der Phase Aufbau wird der Grundstock der Nutzdaten vor allem Stammdaten f r die sp tere Nutzung bereitgestellt Sind die ben tigten Daten noch nicht in elektro nisch gespeicherter Form verf gbar m ssen sie in der Regel manuell eingegeben oder aufbereitet we
194. rden eintippen scannen usw was ein sehr personalintensiver Vor gang sein kann Eine rigorose Qualit tskontrolle in dieser Phase erspart viele sp tere Probleme Werden Daten fremdbeschafft so ist vor Annahme der Lieferung deren Qualit t zu pr fen In aller Regel werden die Daten nicht direkt in der Form ben tzbar sein in der sie eingekauft wurden meistens m ssen sie an die konkrete Umgebung noch strukturell angepasst werden Diese Anpassungsarbeiten sind auch zu leisten wenn Daten aus einem bestehenden System bernommen werden sollen Betrieb W hrend der Phase Betrieb werden die Daten zweckentsprechend genutzt Gleichzei tig werden aber an den Stammdaten st ndig die n tigen Aenderungen und Erg nzun gen durchgef hrt Datenpflege und der Bewegungsdatenbestand wird bei den ein GRUNDLAGEN UND BEGRIFFE 37 zelnen Gesch ftsvorf llen aufgebaut und bearbeitet Diese Phase dauert normalerwei se am l ngsten oft viele Jahre Archivierung Entsorgung Die Phase Archivierung Entsorgung f llt an wenn ein Anwendungssystem nicht l nger eingesetzt wird und die zugeh rigen Daten nicht weiter verwendet werden sollen In diesem Falle ist zu entscheiden was mit den vorhandenen Datenbest nden weiter passieren soll Ist keine unmittelbare Weiterverwendung vorgesehen so sind die Daten unter Um st nden z B aufgrund gesetzlicher Erfordernisse f r eine Langzeitaufbewahrung Archivierung vorzubereiten Dabei muss gekl rt
195. re Automatisierung Reengineering Repository Wieder verwendbarkeit Carl Hanser 281 Seiten 1993 Melton Simon 93 Melton J Simon A Understanding the new SOL A Complete Guide Mor gan Kaufmann Publishers 536 Seiten 1993 Mohn Nanduri 95 Mohn P Nanduri M Implementierung eines UNIMARC Konverters f r die ETHICS Datenstrukturen Teamsemesterarbeit ETH Z rich Institut f r In formationssysteme 1995 M ller 88 Miiller P Hrsg Lexikon der Datenverarbeitung 10 Auflage Verlag Mo derne Industrie 1988 Miiller et al 94 M ller H et al Investigating reverse engineering technologies for the CAS program understanding project IBM Systems Journal Vol 33 Nr 3 1994 S 477 500 Navathe et al 92 Navathe S et al Conceptual Database Design Benjamin Cummings 470 Seiten 1992 Navathe Awong 88 Navathe S B Awong A M Abstracting Relational and Hierarchical Data with a Semantic Data Model Proc of the 6th Int Conf on the Entity Relationship Approach Elsevier 1988 S 305 333 Neumann 95 Neumann P G Computer related Risks Addison Wesley 367 Seiten 1995 LITERATURVERZEICHNIS 153 Neumann et al 93 Neumann K et al Eine Portierungsstrategie f r ADABAS Datenbest nde und Anwendungen nach DB2 Wirtschaftsinformatik Vol 35 Nr 4 1993 S 339 345 Nigg 95 Nigg G Daten Import Schnittstelle fiir DART Semesterarbeit ETH Ziirich Institut fiir Informationssy
196. ren umfangreiche Systemdokumen tationen vorhanden F r das Zielsystem Multimedia Viewer war eine umfangreiche Systemdokumentation verf gbar die auch pr zise Angaben zu Aufbau und Darstellung der Daten inkl Beispielen enthielt 6 2 3 Vorgehen Abgrenzung und Voranalyse Wie eingangs erw hnt sollten in einem ersten Schritt zuerst Entscheidungsgrundlagen zusammengetragen werden Insbesondere sollten vorab folgende zwei Fragestellungen beantwortet werden 1 Zustand der Daten Datenqualit t Aufgrund sehr unterschiedlicher Aeusserungen von Benutzerseite waren quantitative Aussagen ber die Qualit t der Daten er w nscht 2 Probleme und Vorgehensweise f r eine allf llige Uebernahme Es sollte abgekl rt werden mit welchen Schwierigkeiten im Falle einer Uebernahme zu rechnen war falls die Daten in ein neues System bernommen werden sollten Aufgrund der zu Beginn der Untersuchung mangelhaften Informationen wurde in einem ersten Schritt versucht einen Zusammenhang zwischen den Nutzdaten und der Anwendung herzustellen Dazu erwies sich eine Analyse der laufenden Anwendung auf der Ebene der Benutzerschnittstelle als recht hilfreich Da es sich bei der unter suchten Anwendung um eine recht einfache Datenverwaltung ohne wesentliche Ver arbeitungsfunktionen handelte bestand eine erkennbare Verbindung zwischen den an der Benutzerschnittstelle eingegebenen bzw dargestellten und den gespeicherten Daten Dieser Vergleich br
197. roblemen der Kreditvergabe an und der Geldanlage von Firmenkunden Zur Unterst tzung dieser komplexen Gesch ftsvorf lle m ssen regelm ssig eine Reihe von Informationen beigezogen und ausgewertet werden Unter anderem m ssen immer wieder Analysen der wirtschaftli chen Situation der Kunden erstellt werden Dazu werden verschiedene Daten aus dem Finanzbereich der Kunden erfasst und ausgewertet Bilanz und Erfolgsrechnungsda ten Mittelflussrechnungen Aufgrund der Vielzahl solcher Analysen wurde gegen Ende der 80er Jahre von einer bankexternen Softwarefirma eine Anwendung entwik kelt die das Erfassen Speichern Aufbereiten und Ausgeben von solchen Kundenda ten f r Analysezwecke erlaubt Diese Anwendung wurde schrittweise in verschiede 136 FALLSTUDIEN nen Niederlassungen eingef hrt Sie wird als Einbenutzeranwendung auf Arbeits platzrechnern eingesetzt Die Daten der einzelnen Kunden k nnen nur auf Disketten gespeichert werden Neben dem Einsatz dieser Anwendung wurden in einzelnen Niederlassungen auch Kundendaten mit einer Reihe von anderen Anwendungen erfasst und bearbeitet Insbesondere wurden f r Analysezwecke auch verschiedene Endbenutzerwerkzeuge beispielsweise sogenannte Spreadsheet Programme eingesetzt Die Daten die mit diesen Anwendungen erfasst und ausgewertet wurden liegen in unterschiedlichen Datenformaten vor Da dieser vollst ndig dezentrale Betrieb sowohl eine Weiterentwicklung der Anwen dung als au
198. rora 85 Davis K Arora A K A methodology for translating a conventional file system into an entity relationship model Proc of the 4th Int Conf on Entity Relationship Approach IEEE Computer Society Press 1985 S 148 159 Davis Arora 88 Davis K Arora A K Converting a Relational Database Model into an Entity Relationship Model Proc of the 6th Int Conf on the Entity Relation ship Approach Elsevier 1988 S 271 285 Dippold Meier 92 Dippold R Meier A Migration und Koexistenz heterogener Datenbanken Informatik Spektrum Vol 15 Nr 15 1992 S 157 166 Eisner 88 Eisner P Strukturierte Software Wartung Diss Universit t Z rich 1988 Falkenberg Kaufmann 93 Falkenberg G Kaufmann A Ein Vorgehensmodell zum Software Reengi neering und seine praktische Umsetzung Wirtschaftinformatik Vol 35 Nr 1 1993 S 13 22 Fox et al 94 Fox C et al The Notion of Data and ist Quality Dimensions Information Processing and Management Vol 30 No 1 1994 S 9 19 Gahler 91 G hler F Ueberwachung von Konsistenzbedingungen Diss ETH Z rich 1991 Garcia Molina et al 94 Garcia Molina H et al The TSIMMIS Project Integration of Heterogeneous Information Sources Proc of 100th Anniversary Meeting of the Information Processing Society of Japan 1994 Garcia Molina et al 95 Garcia Molina H et al Object Exchange Across Heterogeneous Information Sources Proc of the 11t
199. rreichen Der Gliederung des Daten bernahmevorganges in einzelne Aufgabenbereiche wurde mit einer modularen Aufteilung des Systems in einzelne Komponenten Rechnung getragen Diese Aufteilung unterst tzte zudem in idealer Weise die Realisierung im Rahmen einzelner Studentenarbeiten Wo sinnvoll sollten einzelne Komponenten des Systems auch unabh ngig vom Rest benutzt werden k nnen Gleich zu Beginn wurde entschieden das System strikte als Einbenutzersystem zu entwerfen Dies bedeutet allerdings nicht dass ein real einsetzbares System nicht ber F higkeiten verf gen m sste die ein gleichzeitiges Arbeiten von mehreren Personen erlauben Transaktionsverwaltung Zugriffskontrolle Insbesondere bei komplexe ren Daten bernahmeproblemen muss arbeitsteilig vorgegangen werden k nnen Aufgrund der gew hlten Entwicklungsplattform waren der Einsetzbarkeit von DART hinsichtlich der Gr sse von bearbeitbaren Problemen enge Grenzen gesetzt siehe Fallstudie B Kapitel 6 Beim Entwurf von DART wurden in einer fr hen Phase zur Erreichung der angestreb ten Ziele folgende Entscheide getroffen e Datenmodell Die vermutlich bedeutsamste Entscheidung war die Wahl des Datenmodelles f r das Zwischensystem Die Wahl fiel auf das relationale Modell Dieser Entscheid wurde aus folgenden Gr nden getroffen Das relationale Modell basiert auf einer mathematischen Grundlage Codd 90 Konkret implementierte Systeme weichen zwar oft in un tersc
200. se unvollst ndige Aufz hlung von Problemen soll zeigen dass im Bereich Daten Re Engineering oft recht anspruchsvolle Aufgaben anfallen f r deren L sung sowohl eine gewisse Systematik im Vorgehen Vorgehensmodell als auch eine vern nftige Werkzeugunterst tzung ben tigt werden Erstaunlicherweise hat diese Art von Problemen bis anhin selbst unter Datenbank fachleuten recht wenig wissenschaftliche Beachtung gefunden Surprisingly enough Database Reverse Engineering DBRE has raised little interest in the database scientific community By browsing major infor mation sources such as ACM TODS VLDB and ER conferences proceedings one can hardly collect twenty papers more or less related with DBRE Most often these studies appear to be limited in scope most often dedicated to one data model and are generally based on severly unrealistic assumptions on the quality and completeness of the data structures to reverse engineer Hainout et al 92 Ein wichtiger Grund dafiir mag darin liegen dass eine Datentibernahme erst nach einer gewissen Betriebszeit einer Anwendung relevant wird Datenbanktechnik und Software Engineering sind aber Disziplinen die sich vor allem mit dem Entwurf und der Implementation von neuen Anwendungen befassen wobei die erst in der Phase Betrieb anfallenden konkreten Daten noch keine wesentliche Rolle spielen So konnte mit bestem Willen die Umstellung des Postleitzahlensystems in der
201. se wieder stark abgewichen Scholl Tresch 93 Brodie Stonebraker 95 Aufgrund der starken Verkn pfung von Daten und Funktionen verlangt der Einsatz objektorientierter Techniken ein ganz besonders diszipliniertes Vorgehen Ein verantwortungsvolles Vorgehen bei der Entwicklung sollte immer mitber cksich tigen welche Auswirkungen Entwurfsentscheidungen f r eine k nftige Abl sung haben werden Eine Aufteilung eines Anwendungssystems in Subsysteme mit klaren Schnittstellen kann eine Abl sung einzelner Komponenten wesentlich erleichtern Insbesondere sind aber auch die Nutzungsdauern der einzelnen Komponenten ver n nftig zu planen Diesen Postulaten wird erstaunlicherweise noch nicht nachgelebt Offensichtlich soll die Freude ber die Inbetriebnahme eines Anwendungssystems nicht bereits durch die Planung seiner Abl sung getr bt werden In Bezug auf die engere Problematik einer Daten bernahme sind im wesentlichen zwei Dinge wichtig ein vern nftiger Zugriff auf die Daten des Ausgangssystems sowie eine pr zise vollst ndige und nachgef hrte Beschreibung der Daten Diese Beschreibung muss insbesondere auch detaillierte Informationen zu Bedeutung und Verwendung der entsprechenden Daten umfassen Durch diese zwei Vorausetzungen kann eine Daten bernahme wesentlich erleichtert werden Die heute weitverbreiteten Datenmodelle unterst tzen diese Art von Beschreibungen nur sehr unzul nglich Zur Behebung dieses Mangels wurden Anstrengunge
202. sowie eine Beschreibung der Abbildung zwischen diesen beiden ben tigt F r die Beschreibung des Zwischensystems bot sich naheliegenderweise SQL an F r die Beschreibung der Abbildung wurde eine eigene Sprache definiert Sowohl ASN 1 als auch SQL sind sehr m chtige Sprachen die aber auch eine F lle von M glichkeiten bieten die im Rahmen des Importvorganges unwichtig sind An dererseits m ssen beim Import zus tzlich Angaben zur Semantik der Daten weiterge geben werden k nnen Diese Ausgangslage f hrte zur Entwicklung der drei sogenannten DIEDL Sprachen Data Import Export Definition Language Rossi 95 e DIEDL SD Source Definition Diese Sprache wurde als Teilmenge von ASN 1 definiert und um ein Konstrukt f r die Beschreibung der Semantik der Ausgangsdaten erweitert Sie dient zur Beschreibung der Ausgangsdaten e DIEDL TD Target Definition Diese Sprache umfasst eine Teilmenge der DDL von SQL und dient der Festlegung der Datenstrukturen des Zwischen systems e DIEDL TP Transfer Program Diese Sprache dient der Beschreibung des Zusammenhanges zwischen einem SD und einem TD Programm Diese Strukturierung erlaubt die Zusammenstellung recht flexibler Import Vorg nge m gt TD Programm Zieldaten TP SD Programm Fe Programm gt TD Programm Ausgangsdaten Zieldaten TD Programm Zieldaten
203. steme 1995 Nilsson 85 Nilsson E G The Translation of a COBOL Data Struture to an Entity Relationship Type Conceptual Schema Proc of the 4th Int Conf on Entity Relationship Approach IEEE Computer Society Press 1985 S 170 177 Odendahl 95 Odendahl S Entwicklung von Analyse Services f r DART Semesterarbeit ETH Z rich Institut fiir Informationssysteme 1995 Oertly 91 Oertly W F Evolutiondre Prototypenbildung fiir Datenbank Anwendungs komplexe Diss ETH Ziirich Verlag der Fachvereine Ziirich 1991 Paulley 93 Paulley G N Engineering an SOL Gateway to IMS Proc of the Workshop on Interoperability of Database Systems and Database Applications Universi ty of Fribourg 1993 S 132 155 Perley 93 Perley D R Migrating to Open Systems Mc Graw Hill 252 Seiten 1993 Pfenninger 95 Pfenninger A Entwicklung von Konversions Services fiir DART Semester arbeit ETH Ziirich Institut fiir Informationssysteme 1995 Pfund 94 Pfund R Entwicklung eines Werkzeuges zur Herleitung funktionaler Ab h ngigkeiten und Beziehungen vorhandener Datenbest nde Diplomarbeit ETH Z rich Institut f r Informationssysteme 1994 Piatetsky Shapiro Frawley 93 Piatetsky Shapiro G Frawley W J Knowledge Discovery in Databases MIT Press 3 Auflage 525 Seiten 1993 Premerlani Blaha 92 Premerlani W J Blaha M R An Approach for Reverse Engineering of Relational Databases Proc of th
204. strukturen Dieser Modellierungsvorgang kann zu ungeeigneten Datenbeschreibungen inkl Konsistenzbedingungen s u f hren Eine unsorgf ltige Realisierung und eine oft unkontrolliert verlaufende Weiterentwicklung f hrt letztendlich zu einer ganzen Reihe von Schwierigkeiten Darunter fallen beispielsweise e Namenskonventionen implicit Aliasing In vielen Legacy Systemen wurden fiir die Bezeichnung von Datenstrukturen keine einheitlichen Namenskonven tionen verwendet was es nachtr glich sehr schwierig macht die pr zise Be deutung von einzelnen Datenelementen die in verschiedenen Anwendungen oder sogar auch einzelnen Programmen verwendet werden herauszufinden Insbesondere das Erkennen von Synonymen und Homonymen ist oft sehr schwierig Chatterjee Segev 91 e Unterschiedliche Datentypen und Formate In verschiedenen Anwendungen werden f r an sich gleiche Datenelemente verschiedene Datentypen und oder Formate verwendet Oft entstanden dadurch auch erhebliche Redundanzen in nerhalb eines Datenbestandes man findet beispielsweise in manchen Syste men eine F lle an Varianten der Kalenderdatumsdarstellung e Field Recycling In lteren Systemen ist es oft aufwendig und schwierig die einmal festgelegten Datenstrukturen zu ndern Das f hrte dazu dass oft Da tenlemente zu anderen Zwecken als urspr nglich vorgesehen missbraucht werden mussten e Codierte Semantik In Legacy Systemen findet man oft Datenelemente die in Abh
205. sungen beispielsweise mit Re Engineering Techniken vorgenommen werden Ausgangssystem Zielsystem Uebernahme Individuelle bzw Standard Neuentwicklung Individuelle bzw Standard Anwendungsprogramme Einkauf Anwendungsprogramme Systemprogramme Einkauf Systemprogramme Ger te Einkauf Ger te Daten physisch Uebernahme Daten physisch Fig 2 4 Varianten der Komponentenabl sung Neu bzw Weiterentwicklung von Ger ten und Systemprogrammen ist aus der Sicht des Betriebes der sie einsetzt weitgehend kein Thema Anders bei Daten und indivi duellen Anwendungsprogrammen Ein Einkauf von Daten ist allerdings nur in sehr speziellen F llen m glich und oft mit erheblichen Anpassungsarbeiten verbunden Eine Neu bzw Nacherfassung von Daten kommt in der Regel schon aus rein wirt schaftlichen Gesichtspunkten nicht in Frage Oft ist aber auch das Wissen das in den Daten steckt grunds tzlich nicht rekonstruierbar so dass Daten zwingend bernom men werden m ssen GRUNDLAGEN UND BEGRIFFE 27 2 7 MEHRFACHNUTZUNG VON DATENBEST NDEN Sowohl bei Wartung und Re Engineering als auch bei der Neuentwicklung eines Anwendungssystems wird versucht soweit m glich und sinnvoll bereits bestehende Teil komponenten weiterhin zu nutzen Insbesondere wurde in den letzten Jahren vor allem dem Problem der Wiederbenutzung R
206. t 90 Im Umfeld einer Daten bernahme sind dazu jedoch zwei wesentliche Unterschiede zu beachten eine Vereinfachung und eine Erschwerung Zum einen wird eine Daten bernahme in der Regel nur einmal durchgef hrt und die Datenstruk turen von Ausgangs und Zielsystem bleiben w hrend der Uebernahme normalerweise weitgehend konstant Probleme der Koexistenz von Ausgangs und Zielsystem wer den in Kapitel 4 behandelt zum anderen liegen bei Multidatenbanksystemen in der Regel ausf hrliche Metadaten der einzelnen zu integrierenden Systeme vor Daten also die bei einem Legacy System oft vorab zu rekonstruieren und zu pr fen sind Bei einer Daten bernahme aus einem Legacy System sind zudem oft zus tzlich eine Reihe von Problemen im Zusammenhang mit der physischen Darstellung der Daten zu l sen die im Umfeld von Datenbanksystemen die normalerweise einen Datenzu griff auf einer h heren Abstraktionsebene anbieten nicht anfallen 3 4 2 Codierungs und Darstellungsprobleme Auf der Ebene der physischen Speicherung liegen Daten grunds tzlich als Folgen einzelner Bits vor Zur effizienten Verarbeitung und Speicherung fassen Computer systeme einzelne Bits zu Gruppen Bytes zusammen In den meisten heute gebr uch lichen Systemen wird diese Abstraktion durch Zusammenfassen von 8 Bits zu einem Byte vollzogen f r 8 Bit Byte wird gelegentlich auch der Begriff Oktett verwen det Man findet aber auch immer noch Maschinen im Einsatz bei denen 6 7
207. t oder zul ssige Wertebereiche ber oder unter schritten werden e Formate Subtyping Verschiedene Anwendungen speichern h ufig an sich gleiche Daten in unterschiedlichen Formaten beispielsweise findet man in Legacy Systemen oft eine ganze Reihe von Datumsformaten Weitere Beispiele von Problemen im Zusammenhang mit Datenwerten sind in Ricketts et al 89 und Aebi Largo 94 zu finden Obwohl aufgrund dieser Vielzahl von Fehlerquellen und Problembereichen damit zu rechnen ist dass viele Anwendungssysteme falsche Daten enthalten darf nicht ber sehen werden dass Systeme in vielen F llen ber eine erhebliche Fehlertoleranz verf gen Insbesondere kann aufgrund der oft vorhandenen inh renten Redundanz s a Abschnitt 3 5 2 auch mit Daten die bestimmte Schwachpunkte oder Fehler enthalten ganz gut gearbeitet werden So wird beispielsweise ein Brief mit einer falsch geschriebenen Adresse h ufig immer noch zugestellt werden k nnen Es sind aber nat rlich auch F lle denkbar bei denen nur schon ein einziges falsch eingegebe nes Zeichen z B ein Vorzeichen bei einem numerischen Wert katastrophale Aus wirkungen haben kann Die diesbez glichen Anspr che die an die Daten gestellt werden m ssen sind im konkreten Fall sehr genau zu pr fen 3 5 2 Redundanz Duplikate unvollst ndige und fehlende Daten Mehrfachspeicherungen von Daten trifft man in jedem Anwendungssystem Redun danz an sich ist ein wertfreier Begriff R
208. ten Das Kriterium Einsatzbereich unterscheidet die Daten gem ss der Art ihrer Verarbei tung und Bedeutung innerhalb eines Anwendungssystems Stammdaten Daten die der Bearbeitung einer Vielzahl von Gesch ftsvorf l len dienen Stammdaten sind zustandsorientiert und haben im allgemeinen ei ne lange Nutzungsdauer Sie dienen der Identifizierung Klassifizierung und Charakterisierung von Sachverhalten 34 GRUNDLAGEN UND BEGRIFFE Stammdaten werden gelegentlich auch als feste Daten oder Bestandsdaten bezeichnet Bewegungsdaten Daten die der Aufzeichnung einzelner Gesch ftsvorf lle dienen Bewegungsdaten sind abwicklungsorientiert und haben im allgemei nen eine kurze oder vorfallspezifische Nutzungsdauer Sie bewirken oft eine Ver nderung der Stammdaten Bewegungsdaten werden gelegentlich auch variable oder fliessende Daten genannt Anhand des Kriteriums datentechnische Aufgabe lassen sich Daten in folgende Klas sen einteilen Metadaten Nutzdaten Hilfs Steuerdaten Metadaten Daten die der Beschreibung Struktur Datentyp Wertebereich Semantik u a anderer Daten dienen Nutzdaten Daten die zur Erf llung des Anwendungszweckes direkt verwen det werden Sie stehen f r die Benutzer eines Anwendungsystems im unmittel baren Zentrum des Interesses Hilfs Steuerdaten Daten die zur Steuerung von Verarbeitungsvorg ngen zur Unterst tzung von Strukturierung und Zugriff oder zur Sicherheit dienen Sie sind oft redund
209. ten die im Zielsystem nicht mehr gebraucht wurden 2 Einf gen von neuen Attributen zur Unterst tzung von Suchm glichkeiten 3 Beseitigen von Konsistenzverletzungen 4 Korrektur und Bereinigung von Eingabefehlern Massnahmen zur Ver sch nerung der Darstellung der Daten im Zielsystem Die Aufgaben I und 2 waren recht einfach automatisch durchzuf hren wohingegen die Aufgaben 3 und 4 interaktiv gel st werden mussten Aufbereitung f r das Zielsystem Im Rahmen der Entwicklung des neuen Recherchesystems wurde ein spezieller Ex port Dienst implementiert der die Uebernahme der Vorstossdaten aus dem Zwischen system erlaubt Aufgrund der Eigenschaften des Zielsystems sind die Daten dort nicht mehr nderbar Das Zielsystem kann jedoch so oft wie n tig neu generiert werden 6 2 4 Projektstand Uebernahmedauer Sowohl die explorative als auch die effektive Durchf hrung der Daten bernahme sind abgeschlossen die Daten jedoch noch nicht ins endg ltige Zielsystem bernommen da sie vorab noch korrigiert werden sollen Ein lauff higes Zielsystem mit dem ge samten Datenbestand wurde aber bereits einmal erstellt Das weitere Vorgehen gestal tet sich wie folgt 1 Korrektur Die Ueberarbeitung der Daten vor der Uebernahme ins Zielsystem erfolgt durch Mitarbeiter der Parlamentsdienste Dieser Schritt wird wahrschein lich einige Monate in Anspruch nehmen 2 Uebernahme ins Zielsystem Die daf r ben tigten Werkzeuge sind b
210. tenverwaltungssysteme auf Kleinrechnern haben eine ausserordentlich grosse Verbreitung gefunden F r die Problematik der Daten bernahme hat das zur Konsequenz dass man mit einer Vielzahl von Ausgangslagen konfrontiert ist und zwar sowohl was den Umfang der einzelnen Datenbest nde als auch was die verwen deten Datenverwaltungssysteme angeht Anwendungssysteme die der Gruppe der Grossanwendungen zuzurechnen sind werden h ufig als sogenannte Legacy Systeme bezeichnet McClure 93 Legacy System Aelteres betriebliches Anwendungssystem mit wichtiger Funktionalit t mittels heute weitgehend berholter Technologie entwickelt gelegentlich auch als Altlast bezeichnet kann nicht einfach ersetzt werden Obwohl der Begriff Altlast im Zusammenhang mit Systemen die unter Umst nden erst seit kurzer Zeit in Betrieb stehen widerspr chlich t nt sollen im folgenden mit diesem Begriff auch Anwendungssysteme umschrieben werden die Eigenschaften der Gruppe der Kleinanwendungen aufweisen Daten bernahmeprobleme treten jedoch nicht nur bei einer Abl sung eines Legacy Systems auf dort sind sie aber allenfalls 10 F r den englischen Begriff legacy system trifft man im deutschen Sprachraum gelegentlich die Begriffe Altlast bzw Erblast oder auch Software Altsystem Wagner et al 91 In dieser Arbeit wird jedoch der englische Begriff verwendet 46 DATEN RE ENGINEERING besonders heikel sondern auch wenn ein vor
211. tiert ist bei denen der Verdacht besteht dass zu ihrer Entwicklung berhaupt keine erkennbare Methodik angewendet wurde Es ist zu beachten dass der datengetriebene Entwurfsprozess aus dem Bed rfnis heraus entstand Datenbeschreibung und Datenspeicherung von der Datenverarbei tung und Datenausgabe zu trennen und immer wiederkehrende Aufgaben zentral zu erledigen Man spricht in diesem Zusammenhang auch von Datenunabh ngigkeit Datenverwaltungssysteme die diese Datenunabh ngigkeit gew hrleisten werden als Datenbankverwaltungssysteme bezeichnet Datenbankverwaltungssystem Database Management System DBMS Datenverwaltungssystem das einen Datenbestand strukturiert und gem ss ei ner vorgegebenen Datenbeschreibung Schema unabh ngig von Anwen dungsprogrammen sicher verwaltet In der betrieblichen Praxis haben Datenbankverwaltungssysteme aufgrund dieser Vorteile eine berragende Bedeutung erlangt Viele der heute im Einsatz stehenden Datenbankverwaltungssysteme erf llen die Forderungen an die Datenunabh ngigkeit allerdings unterschiedlich gut H ufig ist man zum Beispiel aus Gr nden der Lei stungsf higkeit noch gezwungen Kompromisse einzugehen Zehnder 89 In der Praxis trifft man deshalb immer noch sehr viele Systeme die das Prinzip der Da tenunabh ngigkeit nur teilweise oder gar nicht erf llen 40 GRUNDLAGEN UND BEGRIFFE Ein konkreter Datenentwurfsprozess beginnt mit der Auswahl eines zu modellieren den Realit ts
212. tion mit Daten zu Personen und den von ihnen bearbeiteten Projekten Personennummer Name Projektnummer f r das Projekt bisher aufgewendete Zeit Fig 3 4 Beispielrelation mit funktionalen Abh ngigkeiten In dieser Relation gelten beispielsweise folgende funktionalen Abh ngigkeiten P gt Name PH gt PZeit P Name PZeit Es ist zu beachten dass diese funktionalen Abh ngigkeiten nur f r diese konkreten Daten gelten So ist im Beispiel zwar zu vermuten dass zwei Personen mit unter schiedlichen Namen auch verschiedene Personennummern haben aber die Abh ngig keit der Projektzeit von dieser Nummer gilt wohl nicht allgemein Da funktionale Abh ngigkeiten in direktem Zusammenhang mit dem Normalisie rungsgrad einer Relation stehen besteht ein grosses Interesse bei einem gegebenen Datenbestand sofern er in relationaler Form vorliegt oder in eine solche gebracht werden kann solche Abh ngigkeiten zu finden denn anhand solcher Abh ngigkeiten k nnen einerseits Aussagen ber den Normalisierungsgrad der Daten gemacht werden und andererseits kann eine Relation darauf basierend auch automatisch normalisiert werden Der naive brute force Ansatz einer Ueberpr fung aller Attributkombinatio nen einer Relation R f hrt aber zu folgender Komplexit t Mannila R ih 92 O a 2 n log n wobei gilt n Kardinalit t von R Anzahl Tupel a Grad von R Anzahl Attribute F r Gr ssen von a und n wie sie
213. titut f r In formationssysteme ETH Z rich 1995 Aebi Largo 94 Aebi D Largo R Methods and Tools for Data Value Re Engineering Int Conf on Applications of Databases Lecture Notes in Computer Science Vol 819 Springer 1994 S 400 411 Aebi Largo 95 Aebi D Largo R Re Engineering Library Data the Long Way From ADABAS to UNIMARC Proc of the 6th Int Hongkong Computer Society Database Workshop Hongkong 1995 S 82 92 Aebi Perrochon 93 Aebi D Perrochon L Towards Improving Data Ouality Proc of the Int Conf on Information Systems and Management of Data New Delhi 1993 S 273 281 Aho et al 88 Aho A et al The AWK Programming Language Addison Wesley 210 Seiten 1988 Aiken 96 Aiken P Data Reverse Engineering Mc Graw Hill 393 Seiten 1996 Batini et al 86 Batini C et al 4 Comparative Analysis of Methodologies for Database Schema Integration Computing Surveys Vol 18 No 4 1986 S 323 364 146 LITERATURVERZEICHNIS Bischofberger Pomberger 92 Bischofberger W Pomberger G Prototyping Oriented Software Develop ment Springer 215 Seiten 1992 Bitton et al 89 Bitton D et al A Feasibility and Performance Study of Dependency Infe rence Proc ofthe Int Conf on Data Engineering 1989 S 635 641 Boehm 76 Boehm B Software Engineering IEEE Transactions on Computers Vol 25 No 12 1976 S 1220 1241 Boehm 88 Boehm B A Spiral
214. tonebraker 95 e Abschotten von Komponenten so dass Aenderungen an anderen Komponen ten keine Auswirkungen auf diese isolierten Komponenten haben e Uebersetzen von Anforderungen und Daten zwischen verbundenen Kompo nenten e Konsistenzsicherung ber die Einzelkomponenten hinaus Insbesondere die letzte Aufgabe ist ausgesprochen anspruchsvoll und es sind derzeit deshalb auch nur wenige kommerziell verf gbare Produkte in der Lage sie zu erf l len so dass oft f r konkrete Probleme solche Gateways zuerst problemspezifisch entwickelt werden m ssen Wird im Ausgangssystem die Schnittstelle einer Komponente durch Einbau einer zus tzlichen Komponente mit neuer Schnittstelle berlagert wird daf r der Begriff Wrapper verwendet Wrapper Komponente die durch Kapselung einer bestehenden Komponente eines Anwendungssystems eine andere Schnittstelle zu dieser Komponente realisiert Beispielsweise kann durch Einbau einer zus tzlichen Komponente entsprechende Produkte sind kommerziell verf gbar eine zeichenbasierte Benutzerschnittstelle zu einer graphischen Benutzerschnittstelle erweitert werden graphische Benutzerschnittstelle zeichenbasierte Benutzerschnittstelle Fig 4 3 Beispiel eines Wrappers Wrapper haben vor allem im Zusammenhang mit Re Engineering Projekten Bedeu tung erlangt insbesondere beim Benutzerschnittstellen Re Engineering Sie unter scheiden sich von Gateways dadurch dass nach ihrem Einbau di
215. tungssystem IMS der Firma IBM Es entstand in den sechziger Jahren F r dieses Modell existiert keine formale Beschreibung Navathe et al 92 S 377 GRUNDLAGEN UND BEGRIFFE 39 In Laufe der letzten Jahre wurden auch eine ganze Reihe von semantischen und ob jektorientierten Datenmodellen mit entsprechenden Datenbankverwaltungssystemen entwickelt Obwohl einige dieser Systeme bereits als kommerzielle Produkte verf g bar sind ist ihre Bedeutung f r die Praxis jedoch als noch gering einzusch tzen so dass sie im Rahmen der vorliegenden Arbeit nicht weiter ber cksichtigt werden Entwurfsprozesse die ber die erw hnten verschiedenen Ebenen f hren werden auch als datengetriebene Entwurfsprozesse bezeichnet Bei diesem Vorgehen erfolgt der Entwurf soweit m glich und sinnvoll prozessunabh ngig einzig durch Beschreibung der Daten Diese Entwurfsmethodik wurde in den 70er Jahren popul r Sie unterst tzt eine weitgehende Entkopplung der Daten von den Anwendungen Davor gelangten sogenannte funktionsgetriebene Entwurfsprozesse zum Einsatz diese sind immer noch sehr weit verbreitet bei denen die Anwendungen im Zentrum des Interesses stehen und die Daten in Abh ngigkeit von den entsprechenden Anwendungsentw r fen modelliert werden Navathe et al 92 Beide Vorgehensweisen haben ihre ganz spezifischen Vor und Nachteile Es darf aber auch nicht bersehen werden dass man im Zusammenhang mit Daten bernahmeproblemen oft mit Systemen konfron
216. uelles Erkennen bzw Vermuten ihrer Semantik weitgehend verunm glichte Das Volumen pro Kunde war als eher gering einzustufen eine Vermutung die auch durch die Tatsache best tigt wurde dass das Ausgangsystem eine Speicherung der zu einem einzelnen Kunden geh renden Daten nur auf Diskette erlaubte Es handelte sich ausschliesslich um formatierte Daten Eine grobe Sch tzung ergab folgendes Mengenger st Anzahl Installationen ca 10 davon wurde eine f r die explorati ve Daten bernahme ausgew hlt Anzahl erfasste Kunden pro Installation 500 1000 Datenmenge pro Kunde ca 250 kByte Vorhandene Systembeschreibungen Da das Ausgangssystem firmenextern entwickelt worden war bestand kein Rechtsan spruch auf die entsprechenden Entwurfs und Wartungsunterlagen Insbesondere lagen keinerlei Unterlagen zur Datenbeschreibung vor Als Informationsquellen stan den deshalb im wesentlichen nur e die Benutzerschnittstelle der laufenden Anwendung Bildschirmmasken Li stenbilder e das Benutzerhandbuch e die Daten e die Benutzer zur Verfiigung Das Zielsystem war ausreichend dokumentiert Insbesondere standen sowohl ein konzeptionelles als auch ein pr zises logisches Schema zur Verf gung FALLSTUDIEN 139 6 4 3 Vorgehen Abgrenzung Voranalyse Da zu Beginn der Arbeit keinerlei Angaben ber die logische und physische Struktur der Ausgangsdaten vorhanden waren mussten diese im Rahmen einer aufwendigen Analyse rekonstruiert werde
217. um einen Ausschnitt aus einer Textdatei die Angaben ber Tontr ger enth lt Das Beispiel stammt aus einem Anwendungssystem von Radio DRS Sz 4 DATEN RE ENGINEERING Aufgrund dieser visuell sehr rasch gefundenen Hypothesen anhand eines Teildaten bestandes k nnte nun eine gezielte Ueberpr fung anhand des vollen Datenbestandes sehr effizient automatisch durchgef hrt werden Basierend auf den Resultaten einer solchen Ueberpr fung k nnte dann eine Zerlegung in einzelne Attribute erfolgen Position 1 2 3 4 5 6 12545678 90123456 78 9012345678901 234567890123456789012345678901 ITRANSFER L9920630 CD 2000000000473 Art Garfunkel Breakaway ZHMGA 19921015 CD 4006758451794 California Man ZHEU 19920707 CD 9003549331506 Hans Liner Band Liebe oder Wa RITHZ 19920707 CDi0035627500725 Laurent Voulzy The collection ILUPM 19920708 CD 8012861103228 Gloria Gaynor Love affair BEFAB 19920727 CD 4009880952054 La Camilla Everytime you lie ZHMGA 1992080 6 CD 4006759731734 Big Daddy Cutting their own g CRGC 19920911 CD 2000000105062 New Africa Mandingo Fela Ani ZHMGA 19920806 CD 0075678239724 Lemonheads It s a shame about GEKSA _ 19920909 CD 5400211001165 La Dame aux cam lias Original TRANSFER 19920630 CD 5099916952928 Berliner Salon Salonorchester TRANSFER 19920630 CD 2 000000000039 Nancy Wilson I ll be a song ILUPM 19920901 cDP000000000046 Kazumi Wat
218. und Abbildungsprogramm 7 erstellen nicht I OK Abbildungsprogramm ausf hren Daten bertragen OK v Fig 5 2 Ablauf eines Import Vorganges Eine zentrale Rolle kommt bei diesem Vorgehen den verschiedenen Beschreibungs m glichkeiten zu Einerseits sollen entsprechende Sprachen f r m glichst viele unter schiedliche Ausgangssituationen geeignet sein andererseits aber auch m glichst m chtige Abstraktionsmechanismen anbieten und zudem noch effizient bersetzt oder interpretiert werden k nnen Da das Problem des Beschreibens und Umsetzens beliebiger Daten auch im Zusam menhang mit dem Austausch von Daten in offenen Systemen auftritt Tanenbaum 92 wurde zuerst in diesem Bereich nach L sungsideen gesucht In offenen Systemen hat zur Datenbeschreibung die standardisierte Sprache Abstract Syntax Notation One ASN 1 sehr weite Verbreitung gefunden Gora Speierer 90 Steedman 93 Sie bietet Ausdrucksm glichkeiten zur systemunabh ngigen Beschreibung von Daten str men die zwischen unterschiedlichen Computersystemen ausgetauscht werden m ssen ASN 1 wurde auch f r den anwendungsunabh ngigen Datenaustausch in heterogenen Client Server Umgebungen eingesetzt G nauer Manus 91 108 WERKZEUGUNTERSTUTZUNG Nebst einer Beschreibung von Struktur und Semantik der Ausgangsdaten wird fiir den Importvorgang aber auch eine entsprechende Beschreibung der Daten des Zwischen systems
219. unden Arbeitsstation Arbeitsstation Vorstossverwaltun weitere 9 Anwendungen A SWISSBASE ae ae Se Fig 6 1 Architektur des Ausgangssystems Da SWISSBASE nicht nur ein Datenverwaltungssystem sondern auch Komponenten zur Anwendungsentwicklung insbesondere eine Programmiersprache sowie einen Masken und Listengenerator umfasst wird im folgenden mit dem Begriff SWISSBASE der Einfachheit halber sowohl die Datenverwaltungskomponente als auch die Ge samtheit des Anwendungssystems bezeichnet Ab 1993 erfolgte der Aufbau eines neuen Anwendungssystems im folgenden mit G 1 Gesch fts bersicht 1 bezeichnet zur Unterst tzung der Gesch ftskontrolle des Parlaments das auch wesentliche Funktionen der Sw ssBAsE Anwendungen umfasste Da aber einerseits der Funktionsumfang von SWISSBASE und GU 1 nicht deckungsgleich war und andererseits eine rasche Daten bernahme aus dem alten System aufgrund fehlender personeller Ressourcen nicht m glich war wurden beide Systeme parallel betrieben das heisst insbesondere auch dass die Vorstossdaten 120 FALLSTUDIEN doppelt erfasst und gespeichert wurden wobei im alten System SWISSBASE s mtli che Angaben zu einem Vorstoss gespeichert wurden im System GU 1 aber nur die formatierten die eigentlichen Texte der Vorst sse die Begr ndungen sowie die Antworten des Bundesrates wurden nicht erfasst Da s mtliche Vorstossdaten dauern
220. ung von Konsistenzbedingungen Erstellen einer pr zisen Statistik ber die einzelnen Attribute Anzahl unterschiedlicher Vor kommen Anzahl leere Eintr ge Analyse des Zieldatenbestandes hinsichtlich Struktur Analyse der Abbildungsprobleme zwischen diesen beiden Systemen Die Strukturanalyse lieferte folgende Resultate Auszug Attribut 101 102 103 104 198 199 200 201 202 203 204 205 206 208 210 300 301 302 303 304 305 306 307 D x lt 5 E gt co a Geschaftsnummer 12 Rat SR oder NR 2 Art des Vorstosses 4 Einreichungsdatum 10 Fraktion 1 ID Nr Autor 10 Autor 68 Sprecher 68 Vorstoss bernimmt 40 Titel deutsch 68 Titel franz sisch 68 Titel italienisch 68 Mitunterzeichner 68 Verfahren 11 Departement 10 Bundesrat Bundeskanzler 20 Antwort des Bundesrates 10 Behandlung im Rat am 10 Antwort deutsch 68 Antwort franz sisch 68 Antwort italienisch 68 Begr ndung deutsch 68 NR PaaS EN S L nge max eff a Oo 68 71 51 11 10 9 10 10 154 157 87 149 Bsp bei Rec 1794 3656 1639 2092 Bsp bei Rec Srwmwnwn a a a Anz Zeilen max Dok N22 sasan88 Po n ww bh nw Anz Zeilen max eff 2 973 999 1439 1829 9991 1518 1829 999 183 3767 999 234 5034 Fig 6 4 Resultate der Strukturanalyse zz zz zzoe ZZ zZ ZZ Zu ZZ Zu c Konsistenzbedingung ZZZ2Z2Z2Z2222222222222 2 c ccc c Muss Eingabe Anz
221. usl ser Je nachdem ob interne oder externe Ursachen vorliegen kann die Wahl der Mittel sehr unterschiedlich ausfallen Phase 2 Voranalyse Zweck Zugriff auf die Daten des Ausgangssystems erlangen Ueberpr fen der vorhandenen Informationen und gegebenfalls Erg nzen der selben Voraussetzungen M glichst pr zise abgegrenzter Datenbestand Zugriff zu allen vorhandenen Informationsquellen Ziel Resultate M glichst vollst ndige Beschreibung der Daten des Ausgangs systems Grundlagen f r einen Durchf hrungsentscheid In dieser Phase muss der physische Zugriff auf die zu bernehmenden Daten ge ffnet werden Die geeignetste Zugriffsebene ist festzulegen und auszutesten Gegebenen falls sind hierzu vorab geeignete Werkzeuge zu entwickeln diese k nnen sowohl f r die Durchf hrung der explorativen Durchf hrung als auch f r die sp ter durchzuf h rende effektive Durchf hrung verwendet werden Die vorhandenen Angaben ber den Ausgangsdatenbestand sind zu berpr fen und zu vervollst ndigen Alle f r die Dimensionierung des Zwischensystems n tigen Informationen m ssen bekannt sein Sind auch Fragen im Zusammenhang mit dem Stichwort Datenqualit t zu pr fen m ssen messbare Kriterien erarbeitet werden Allgemeiner gesprochen muss in dieser Phase so etwas wie ein Gef hl f r die Daten entwickelt werden Struktur Semantik Vollstandigkeit Basierend auf den in dieser Phase erarbeiteten Informatio
222. verschiedene Sche mas verwendet Die Zusammenh nge zwischen Realit t Schema s und Nutzdaten lassen sich wie folgt darstellen Realit t E D ge oO E c Se 2 Schema s S 10 5 2 Ko lt oO no 2 Nutzdaten Fig 2 12 Zusammenhang Realit t Schema s Nutzdaten Schemas bilden heute ein wesentliches Element beim Anwendungsentwurf es darf aber nicht bersehen werden dass f r ltere Systeme oft keine solchen Schemas verf gbar sind In sehr vielen Anwendungen sind die entsprechenden Angaben auf sehr unterschiedliche Quellen verteilt Programmcode Dokumentationen Auf das Problem der Schema Rekonstruktion wird daher im n chsten Kapitel n her eingegan gen 43 3 DATEN RE ENGINEERING 3 1 LEGACY SYSTEME Im Mittelpunkt dieser Arbeit stehen Datenbest nde die in eine neue Umgebung zu bernehmen sind und deshalb vorg ngig entsprechend aufbereitet werden m ssen Diese Ausgangslage ist sowohl typisch f r eine Daten bernahme im Rahmen einer Abl sung eines Anwendungssystems wenn beispielsweise die Programme neu ent wickelt oder eingekauft werden als auch f r eine Datenmehrfachnutzung wenn das Ausgangssystem weiterhin in produktivem Betrieb bleibt Im folgenden werden eine Reihe von Problemen untersucht die bei einer solchen Daten bernahme zu l sen sind Daten bernahmen werden oft im Gesamtrahmen einer Anwendungsabl sung durchgef hrt In
223. verwaltung Datenverwaltung Daten physisch Daten physisch Fig 2 7 Teilweise zerlegbares bzw monolithisches Anwendungssystem Teilweise zerlegbare Anwendungssysteme k nnen unterschiedlich gegliedert sein F r die Durchf hrung einer Daten bernahme erweisen sich insbesondere Anwendungs systeme als g nstig die eine Isolierung ihrer Datenverwaltungskomponente erlauben 2 9 ZUGRIFFSMOGLICHKEITEN AUF DATENBEST NDE Bereits recht fr h sollte im Hinblick auf eine Daten bernahme abgekl rt werden wie auf die Daten des Ausgangssystems zugegriffen werden kann Dieses an sich recht einfach erscheinende Problem kann sich unter Umst nden in der Praxis als ausgespro chen hartn ckig erweisen siehe Kapitel 6 Insbesondere wenn keine falsche oder unvollst ndige Informationen ber die Art der Speicherung der Daten im Ausgangs system vorliegen muss nach Wegen gesucht werden die Daten aus dem Ausgangssy stem herauszuholen Insbesondere ltere Systeme wurden auch oft gar nicht daf r konstruiert ihre Daten anderen Systemen zur Verf gung zu stellen Bei solchen geschlossenen Systemen muss deshalb oft ein geeigneter Zugriff erst geschaffen werden GRUNDLAGEN UND BEGRIFFE 31 Ein solcher Zugriff kann grunds tzlich auf vier verschiedenen Ebenen erfolgen e Betriebssystem e Datenverwaltungssystem e Verarbeitung e Benutzer oder externe Systemschnittstelle externe
224. vielen F llen beispielsweise wenn die vor handenen Programme durch neu entwickelte abgel st werden kann das Wissen ber die vielf ltigen Abh ngigkeiten zwischen Daten und Programmen Datendefinitionen und Datenzugriffe die Daten bernahme wesentlich vereinfachen Dies gilt nat rlich auch wenn bestehende Programme mit Hilfe von Re Engineering Techniken auf einen moderneren Stand gebracht werden In einer Reihe von Situationen steht dieses Wissen auf Programmebene jedoch nicht zur Verf gung Dies ist namentlich dann der Fall wenn Standardprogramme zu ersetzen oder neu einzuf hren sind Der Zugriff auf den Programmcode des Ausgangs bzw Zielsystems kann aber auch aus anderen beispielsweise urheberrechtlichen Gr nden verunm glicht sein Fragen die in die Problembereiche Reverse und Re Engineering von Programmen geh ren werden im folgenden nicht betrachtet F r das Reverse und Re Engineering von Daten wird davon ausgegangen dass kein vollst ndiger Programmcode des Aus gangs bzw Zielsystems f r eine seri se Analyse verf gbar ist Selbstverst ndlich sind aber Ausgangssituationen denkbar bei denen eine Datenbeschreibung in Form von Programmcode vorliegt beispielsweise in Form von Record Beschreibungen Voraussetzungen f r eine Daten bernahme sind allerdings ein Zugriff auf die Daten des Ausgangssystems sowie eine irgendwie geartete Beschreibung dieser Daten die insbesondere auch Angaben zum Verwendungszweck der Daten umfassen
225. von Daten bernahmen vorge stellt MIKADO ist ein mehrphasiges Vorgehensmodell das sich f r Daten bernah men zwischen heterogenen Ausgangs und Zielsystemen eignet Es unterst tzt die Analyse die Konversion und die Korrektur von Datenbest nden Einen wichtigen Schritt bildet dabei die Uebernahme der entsprechenden Datenbest nde in ein Zwi schensystem und damit die Losl sung von spezifischen Eigenheiten der Ausgangs bzw Zielsysteme Dazu muss allerdings zumindest kurzzeitig ein Betriebsunter bruch in Kauf genommen werden Diese Vorgehensweise bietet folgende Vorteile Die Komplexit t einer Daten bernahme wird reduziert und eine Aufbereitung der Datenbest nde f r unterschiedliche Zwecke d h f r eine Mehrfachnutzung wird erleichtert F r die praktische Durchf hrung von Daten bernahmen m ssen aufgrund der Gr sse der Datenbest nde in der Regel besondere Werkzeuge eingesetzt werden Zur Unter st tzung des Vorgehensmodells MIKADO wird die Werkzeugarchitektur DART vorgestellt und ihre konkrete Umsetzung in eine Reihe von Werkzeugen beschrieben Die Praxiseignung von MIKADO und DART wird anhand von drei konkreten Daten bernahmeprojekten nachgewiesen 11 ABSTRACT Planning development and implementation of new commercial application systems have normally to be based on already existing predecessor systems In these systems economically the existing data are often the most import component The adaption and
226. wendet Dieser hat zwar umgangssprachlich eine intuitive Bedeutung die Abgrenzung zum GRUNDLAGEN UND BEGRIFFE 21 Begriff der perfektionierenden Wartung ist jedoch oft nicht ganz klar siehe z B Stahlknecht Drasdo 95 Diese Begriffsbildungen legen durchaus den Schluss nahe Re Engineering gleichsam als Zusammenfassung aller T tigkeiten im Bereich Wartung zu betrachten Dieser Standpunkt wird beispielsweise auch in Richter 92 vertreten In der vorliegenden Arbeit wird diesem Standpunkt nicht gefolgt vielmehr wird aufgrund der folgenden Beobachtungen eine Unterscheidung zwischen Re Engi neering und Wartung getroffen e Zeitlicher Aspekt Wartungsaktivit ten k nnen unmittelbar nach der Inbe triebnahme eines Anwendungssystems beginnen von Re Engineering spricht man jedoch ausschliesslich im Zusammenhang mit Anwendungssystemen die schon ber einen l ngeren Zeitraum im Betrieb stehen e H ufigkeit Wartungsaktivit ten sind w hrend der gesamten Lebensdauer ei nes Anwendungssystems immer wieder n tig vor allem adaptive Wartung Re Engineering hingegen bezeichnet eine Reihe von Massnahmen mit denen in einem in der Regel einmaligen konzentrierten Vorgang versucht wird die Qualit t eines Anwendungssystems erheblich zu verbessern um k nftige Wartungsaufwendungen zu reduzieren e Lokale versus globale Auswirkungen Wartungsaktivit ten sind lokal orien tiert und m glichst stabilit tserhaltend Typischerweise wird nur gera
227. wischen system erleichtert werden Konsequenzen F r eine reale Daten bernahme der ETHICS Daten ist das gew hlte Vorgehen in verschiedenen Richtungen zu berdenken Sofern auch zuk nftig nur ein Interesse an einer Uebernahme von ETHICS Daten in einen zentralen Katalog besteht ist der Aufwand der durch den Umweg ber ein Zwischensystem entsteht nicht zu recht fertigen In einer solchen Situation bei der im wesentlichen der Gesamtbestand oder geeignet abgegrenzte Teile davon einmal zu bertragen ist allenfalls gefolgt von periodischen Uebertragungen von Zuw chsen lohnt sich die Entwicklung eines ei genst ndigen Uebernahmeprogrammes das direkt die ADABAS Daten in das Format des Zielsystems bertr gt Anders ist die Situation wenn mehrere Zielsysteme zu bedienen sind In diesem Falle reduziert der Umweg ber ein Zwischensystem den Aufwand auf die Entwicklung von entsprechenden Export Diensten Es ist insbesondere auch von Bedeutung dass innerhalb eines Zwischensystems eine Reihe von Aufbereitungen und Datenkorrekturen einfacher m glich sind als in den Ausgangs und Zielsystemen mit ihren propriet ren Datenformaten Die Entwicklung von speziellen Export Diensten k nnte dadurch wesentlich vereinfacht werden 6 4 FALLSTUDIE C BILANZDATEN 6 4 1 Ausgangslage Problemstellung Der Gesch ftsbereich Firmenkundengesch ft Schweiz der Schweizerischen Bank gesellschaft SBG befasst sich unter anderem auch mit P
228. y Um Uaa uar Solche Daten bernahmen sind in der Regel einfacher durchzuf hren da sie bei der Weiter entwicklung bereits eingeplant werden k nnen und die Unterschiede zwi schen Ausgangs und Zielsystem normalerweise nicht allzu gross sind Die bei einer Abl sung auftretenden Probleme sind nicht nur technischer sondern namentlich auch organisatorischer und f hrungsm ssiger Art Im Rahmen dieser Arbeit stehen Daten bernahmeprobleme und die damit zusammenh ngenden Aspekte im Mittelpunkt des Interesses Auf Probleme im Zusammenhang mit der Abl sung von Programmen und insbesondere mit der Koexistenz von Anwendungssystemen wird im folgenden nicht mehr weiter eingegangen Eine vertiefte Auseinandersetzung mit diesen Problembereichen insbesondere unter Anwendung einer inkrementellen Vorgehensweise d h Probleme der Klasse P Ty Uvi Uax ist beispielsweise in Perley 93 oder Brodie Stonebraker 95 zu finden 4 3 MIKADO EIN VORGEHENSMODELL F R DATENUBERNAHMEN 4 3 1 Grundlagen Was f r die umfassendere Problematik der Abl sung betrieblicher Anwendungssy steme gilt hat insbesondere auch f r den Problembereich Daten bernahme G ltigkeit Man sucht vergebens nach etablierten Vorgehensmodellen Daten bernahmen werden in den bereits erw hnten Arbeiten h chstens als Teilproblem im Gesamtrahmen einer Anwendungsabl sung betrachtet Dadurch wird der Problematik bei einer Da tenmehrfachnutzung in einer anderen Umgebun
229. ying Schematic and Data Heterogeneity in Multida tabase Systems IEEE Computer Vol 24 Nr 12 1991 S 12 18 Kindermann 92 Kindermann M Urheberrechtliche Voraussetzungen und Grenzen des Re verse Engineering und Schutz von Schnittstellen Wirtschaftsinformatik Vol 34 Nr 2 1992 S 175 180 Kivinen Mannila 92 Kivinen J Mannila H Approximate Dependency Inference from Relations Proc of the 4th Int Conf on Database Theory ICDT 92 Lecture Notes in Computer Science Vol 646 Springer 1992 S 86 98 Kl sch Gall 95 Kl sch R Gall H Objektorientiertes Reverse Engineering Springer 554 Seiten 1995 Kn ll Schwarze 93 Kn ll H D Schwarze M Re Engineering von Anwendungssoftware BI Wissenschaftsverlag 213 Seiten 1993 LITERATURVERZEICHNIS 151 Krueger 92 Krueger C W Software reuse ACM Computing Surveys Vol 24 Nr 2 1992 S 131 181 Kukich 92 Kukich K Techniques for Automatically Correction Words in Text ACM Computing Surveys Vol 24 Nr 4 1992 S 377 439 K ng 94 K ng P Datenbanksysteme Entwicklungsstand Anforderungen und Bedeu tung neuerer Konzepte Diss Universit t Freiburg 1994 Lano Haughton 94 Lano K Haughton H Reverse Engineering and Software Maintenance McGraw Hill 251 Seiten 1994 Lehner 91 Lehner F Softwarewartung Carl Hanser M nchen 271 Seiten 1991 Leikauf 91 Leikauf P Konsistenzsicherung durch Verwaltung
230. zept der Datenverwaltung Metaschema von DART Metametaschema von DART Architektur von ICA Architektur des Ausgangssystems Ausgangssituation Fallstudie A Beispiel von Eingabefehlern im Ausgangssystem Resultate der Strukturanalyse Resultate der Attribut berpr fung Beispiel Ausgangssituation Fallstudie C Ergebnisse der Fallstudien 85 86 87 88 90 91 93 94 105 107 108 110 111 111 116 119 120 124 125 126 136 141 10 ZUSAMMENFASSUNG Planung Entwicklung und Einf hrung neuer betrieblicher Anwendungssysteme er fordern heute blicherweise R cksichtnahme auf bereits vorhandene Vorg ngersy steme Darin bilden die Datenbest nde oft die wirtschaftlich bedeutsamste Kompo nente Anpassung und Migration dieser bereits vorhandenen Datenbest nde stellen sich als regelm ssig zu l sende Aufgaben In vielen Situationen liegen aber ber die abzul senden alten Anwendungssysteme und die zugeh rigen Datenbest nde nur unvollst ndige oder sogar falsche Angaben vor Diese Angaben m ssen deshalb soweit rekonstruiert bzw korrigiert werden dass eine Uebernahme und Weiterver wendung der Datenbest nde erm glicht wird Die vorliegende Dissertation untersucht eine Reihe von Problemen die bei Daten bernahmen zu l sen sind Basierend auf einer breit angelegten Diskussion von Aus gangssituationen und Problembereichen und entsprechenden Klassifizierungen wird das Vorgehensmodell MIKADO f r die Durchf hrung
231. zu besprechen FALLSTUDIEN 133 und zu bereinigen Da f r die vorliegende Untersuchung nur ein Testdatenbestand zur Verf gung stand konnte vieles nicht anhand der Daten berpr ft werden Dieses konzeptionelle Schema hat sich zwar als n tzlich erwiesen f r eine seri se Fertigstel lung w ren aber noch wesentliche weitere Arbeiten zu leisten Resultate hierzu sind in Aebi Largo 95 zu finden Aufgrund der erw hnten Arbeiten gelang es aber immerhin recht einfach die f r die vorliegende Problemstellung interessanten Daten zu identifizieren und vom Rest Benutzerverwaltung Beschaffung zu trennen Aufbereitung f r das Zwischensystem Die Uebertragung der Daten von ETHICS in das Zwischensystem stellte eine Reihe von Problemen Diese liessen sich im wesentlichen zwei Ursachen zuschreiben Zum einen waren Probleme der Umsetzung der Daten aus dem ADABAS spezifischen Format in 1 Normalform zu l sen zum anderen waren die Daten von anwendungs spezifischen Darstellungseigenheiten zu befreien Es steht zwar f r ADABAS Systeme auch eine relationale Schnittstelle zur Verf gung diese ist jedoch nicht Bestandteil einer normalen Installation sondern muss vielmehr als Zusatzprodukt erworben werden Die Kosten dieses Zusatzproduktes sind so erheblich dass f r die vorliegende Untersuchung nach anderen Wegen gesucht werden musste Nach gr nd lichem Studium der allenfalls n tigen Umsetzungsarbeiten wurde beschlossen f r dieses Problem
232. zungen der Eingabefelder hinweg geschrieben wurde so dass oft mitten in einzelnen W rtern ein Umbruch erfolgte Vorstosstext lt Hier wurde der Text des Vorstos gt lt ses eingegeben ungeachtet der gt lt L nge der einzelnen Eingabfelde gt lt r gt Fig 6 3 Beispiel von Eingabefehlern im Ausgangssystem Da solche Problemf lle nur mit sehr grossem Aufwand maschinell quantitativ beur teilt werden k nnen z B mittels einem Vergleich mit einem W rterbuch wurde beschlossen nur die Konsistenzfragen im Rahmen einer detaillierten Untersuchung zu beantworten Weil fast keine explizit formulierten Konsistenzbedingungen bekannt waren sich solche aber aufgrund des Anwendungsbereiches direkt ergaben beispielsweise die Pr fung eines Datums wurde f r den Ausgangsdatenbestand eine Reihe von Konsi stenzbedingungen neu formuliert So durfte beispielsweise ein Attribut das den Rat der Einreichung eines Vorstosses enth lt und zwei Zeichen lang war sinnvollerweise nur die Werte SR und NR St nde bzw Nationalrat enthalten oder ggf auch leer sein Als Qualit tsmass wurde der Einhaltungsgrad dieser Konsistenzbedin gungen festgelegt FALLSTUDIEN Die Vorphase wurde in folgende Teilaufgaben gegliedert 125 Analyse des Ausgangsdatenbestandes hinsichtlich Struktur daraus ergab sich insbesondere auch die konkrete Dimensionierung des Zwischensystems Formulierung und Ueberpr f

Re-Engineering betrieblicher Nutzdaten

Contents

Download Pdf Manuals

Related Search

Related Contents