Material - Friedrich-Schiller
Werbung
Datenhaltung von Legacy Systemen - Verstehen im Rahmen von Reengineering Maßnahmen - Friedrich-Schiller-Universität Jena 6. Nov. 2006 Alois Hofinger © Copyright IT-Consulting Alois Hofinger 2006 Was sind Daten? Daten kennzeichnen einzelne objektive Fakten zu Ereignissen oder Vorgängen. Im Unternehmenskontext sind Daten am sinnvollsten zu beschreiben als strukturierte Aufzeichnungen von Transaktionen. Daten beschreiben lediglich einen Teil des Geschehens; sie enthalten keinerlei Werturteil oder Interpretation. Daten sind vor allem deshalb wichtig für Organisationen, weil sie das entscheidende Rohmaterial zur Schaffung von Informationen bereitstellen. Informationen kann man sich vorstellen als Daten, die etwas bewirken. Im Gegensatz zu Daten besitzen Informationen „Bedeutung und Zweck“. Aus Daten werden Informationen, wenn der Sender den Daten einen Bedeutungsgehalt hinzufügt. Quelle: Wenn Ihr Unternehmen wüßte, was es alles weiß . . .(Thomas H. Davenport, Laurence Prusak) 2 © Copyright IT-Consulting Alois Hofinger 2006 Was sind Daten? Zusammenfassend können wir demnach sagen Daten zählen zu den Vermögenswerten eines Unternehmens Sie sind das Rohmaterial von Information und Wissen Daten existieren auch nach Verschwinden des Gastsystems weiter Daten sind strukturiert unstrukturiert und sollen physisch konsistent logisch konsistent unabhängig wo sie sich befinden verfügbar sein 3 © Copyright IT-Consulting Alois Hofinger 2006 Wie werden Daten gespeichert? Die von IBM 1928 patentierte 80-spaltige Lochkarte, mit rechteckigen Löchern 4 © Copyright IT-Consulting Alois Hofinger 2006 VSAM – nur eine Zugriffsmethode 5 © Copyright IT-Consulting Alois Hofinger 2006 VSAM – nur eine Zugriffsmethode 6 © Copyright IT-Consulting Alois Hofinger 2006 Hierarchische Datenbanken: Datenbankschema Kunde Anschrift 7 Rootsegment Auftrag Rechnung Artikel Mahnung © Copyright IT-Consulting Alois Hofinger 2006 Hierarchische Datenbanken: Datenbanksatz 4711 Kunde 1 Anschrift 3710 Auftrag 2 Anschrift 4110 Auftrag 4200 Auftrag R110 Rechnung R130 Rechnung Mahnung A200 Artikel A100 Artikel 8 A200 Artikel A350 Artikel A300 Artikel © Copyright IT-Consulting Alois Hofinger 2006 For the logical parent to physical parent path, the user controls the sequence in which occurrences of the real logical child are accessed from their logical parent by defining a virtual logical child segment type as a physical child of the logical parent of the real logical child. A virtual logical child segment type is defined in the physical data base of the logical parent of the real logical child to represent the view of the real logical child when accessing the real logical child from ist logical parent. Source: IMS SADG Isn“t that real „Information Management ?“ 9 © Copyright IT-Consulting Alois Hofinger 2006 Codasyl orientierte Datenbanken: Das Netzwerk (DBTG) Modell Produkte Kunden „umgesetzt“ „gekauft“ Aufträge „enthalten“ Lagerplatz Vertreter „verkauft“ Ein „navigierendes“ System 10 © Copyright IT-Consulting Alois Hofinger 2006 Relationale Datenbanken KDNR KNAME KPLZ KSTADT KSTR 8270 Müller 81925 München Effnerstrasse 7333 Schulze 65936 Frankfurt Lyonerstrasse 8760 Adam 81905 Landau Stadtplatz 2838 Meier 81925 München Cosimastrasse 5210 Schmidt 71756 Stuttgart Paulinenstrasse 7100 Lehmann 20112 Hamburg Brahmsfelderstrasse Zugriff direkt oder assoziativ über Attributwerte (keine „Zugriffspfade“) • Zugriff über komfortable, deklarative Dialog-Schnittstelle • Zugriff aus Programmen: Spracheinbettung • Mengenorientierter Zugriff und Datenaustausch • Relationale Operationen - Selection „The data in a record depends on the Key - Projection to the record, the Whole Key, and nothing - Join but the Key, so help me Codd.“ - Union -Intersection - Difference 11 © Copyright IT-Consulting Alois Hofinger 2006 Was lässt sich über Daten aussagen? Typ (z.B. Attribut) Arten von Metadaten Semantisch (z.B. Grösse) Persistenz (z.B. DB 24) Primärtyp (z.B. numerisch) Logische Struktur (z.B. Teil von Forderungen) Physische Struktur (z.B. auf Tabelle AAM) Physisches Feld (z.B. Spalte Groesse) Name (xyz) Daten (z.B. 47) Speicherung (z.B. Long Integer) zeitlich (gebucht am 29/10/2006, 15:55:34) Anzeige (Euro 99,99) Validierung (z.B. <50) Eigentümer (z.B. Mahnwesen) Quelle (z.B. Dateneingabe: Meinrich) Wahrhaftigkeit (z.B. verifiziert) Quelle: Semantics in Business Systems, Dave McComb 12 © Copyright IT-Consulting Alois Hofinger 2006 Wie werden (wurden) Daten beschrieben? Metadaten sind Daten über Daten Dateibeschreibung (Layout) für das Datenmodell Transaktionsbeschreibungen Daten Dictionaries (meistens erstellt nach Ende eines Projektes) Information primär über Felder und Records Daten dokumentiert Datendefinition generierte Berichte Daten 13 © Copyright IT-Consulting Alois Hofinger 2006 Wie werden (wurden) Daten beschrieben? „aktives“ Dictionary Generieren von Record Layout CASE – Tools Generieren von Anwendungs-Quellkode Datendefinitionssprache (DDL) XML (Derivat von SGML) Semantic Markup für das WWW (DTD/XSD) UML XMI (XML metadata interchange) CWMI (common warehouse metadata interchange) RDF (Resource Definition Framework – Metadaten für Content) 14 © Copyright IT-Consulting Alois Hofinger 2006 Vorgeschlagene Definitionen und Standards “Semantic Interoperability” Definition: The shared meaning of a string of characters and/or symbols in some language within a context that assures the correct interpretation by all actors. “Semantic Interoperability” Standards Cross Standard Semantics and Metadata Alignment – UDEF, RDF, OWL Domain Specific “Semantic and Syntax Payload” Standards Domain Specific Implementation Conventions (subsets & extensions) OAGIS ACORD XBRL HL7 EIA-836 PLCS …. Others “Semantic Foundation” Standards ISO/IEC 11179-5, ISO 15000-5, UN Naming and Design Rules “Syntax Foundation” Standards W3C – XML, XML Schema Quelle: Enterprise Architecture Practitioners Conference, Lissabon, 24. Okt. 2006 15 © Copyright IT-Consulting Alois Hofinger 2006 Legacy Systeme als Ausgangsbasis für Reengineering Maßnahmen Definition eines Legacy Systems: „ … jedes Informationssystem, dass auf signifikante Weise sich einer Modernisierung und Weiterentwicklung widerstrebt … „ Brodie, Stonebraker, 1995 Ein Reengineering wird durchgeführt wegen: Modernisierung, M & A, Outsourcing, Aufbau eines Data Warehouses, etc. 16 © Copyright IT-Consulting Alois Hofinger 2006 Datenhaltung in Legacy Systemen – die reale Welt Hierarchische Datenbanken DL1 - VANDL1 - DL1 Entry - IMS/DL1 VSAM - - KSDS - RRDS - ESDS Invertierte Dateisysteme - V(BOMP)/DBOMP ADABAS -Stücklistenverarbeitung Codasysl orientierte Datenbanken - Versant - Objectstore - IDMS Relationale Datenbanken „quasi relational“ DB2 - Oracle - Ingres - Sybase - Informix - - CA-Universe - Total - Sesam 17 Object orientierte Datenbanken Homegrown - ATCS - RYO (Komunen) - Komplexe Objekte XML Datenbanken Branchenspezifische Datenmodelle - FSDM - IAA - DB2 aus der Erfahrung des Vortragenden . . . © Copyright IT-Consulting Alois Hofinger 2006 Reengineering von Daten und Datenbanken Dabei sind folgende Aspekte von Wichtigkeit: Physisches Datenformat und Datenhaltung Semantisches Verstehen der Daten Transaktioneller Kontext von Datenobjekten (Dateien, Datenbanken, Masken und Berichten) und Datenelementen 18 © Copyright IT-Consulting Alois Hofinger 2006 Reengineering von Daten Das Ziel eines Daten Reengineering ist die Erstellung von sinnvollen, nicht redundanten Datendefinitionen und gültigen, konsistenten Datenwerten. Datendefinitionsprobleme Kryptische, inkonsistente Namen Inkonsistente Feldlängen Inflexible Feldlängen Inkonsistente Record Layouts Hart kodierte Literale Nicht existierende, unvollständige oder ungenaue Daten Dictionaries Datenwertprobleme Inkonsistente Default Werte Das Fehlen einer Unterscheidung zwischen gültigen und fehlenden Werten Negative Werte in Feldern die immer nicht negativ sein sollen Negative Werte werden positiv, wenn Vorzeichen weggelassen werden Abschneiden von Bits mit dem höchsten Stellenwert Inkonsistente Einheiten Textwerte als „mixed case“ gespeichert, aber Tests nehmen „upper case“ an Änderungen für Datenvalidierungsregeln werden nicht auf statische oder historische Dateien propagiert 19 © Copyright IT-Consulting Alois Hofinger 2006 Reengineering von Daten Daten Reengineering Phasen Kode Analyse - Entdecken von Datendefinitionen, Flows und Regeln - Füllen eines Metadaten Repositories Daten Analyse - Entdecken von Daten Eigenschaften - Speichern der Ergebnisse in das Metadaten Repository Metadaten Synthese - „zusammenbringen“ der vorher gesammelten Informationen mit dem Ziel, „versteckte“ Datenmodelle sichtbar zu machen - Dies wird bewerkstelligt durch eine Deduktion der Verbindungen zwischen Daten und Programmen Re-Design - „Reinigen“ von Datendefinitionen - Datensatz Standardisierung - Datennamen Rationalisierung - Daten Restrukturierung - Normalisierung Berichtigung - Implementierung des Re-Designs in Source Kode und manchmal in bestehende Dateien, um bestehende Systeme mit dem Re-Design konform zu machen Exportieren der Definitionen 20 © Copyright IT-Consulting Alois Hofinger 2006 Möglichkeiten eines Reengineerings von Datenbanken DB Anwendung Kode-Konversion SQL Anwendung Daten-Konversion Sprachtransformation Nicht Relationale Datenbank 21 Datenpropagation Relationale Datenbank © Copyright IT-Consulting Alois Hofinger 2006 Möglichkeiten eines Reengineerings von Datenbanken Daten- und Kode-Konversion • Daten- und Kode-Konversion von Anwendungsprogrammen • Abbildung nichtrelationaler Datenbanken auf relationale Datenbanken • Übertragen der Daten durch Extrakt- und Ladeprogramme • Übersetzen der prozeduralen Datenbankaufrufe in relationale Datenbankaufrufe Sprachtransformation • Automatisches Umsetzen der Datenbankaufrufe nichtrelationaler Datenbanken auf relationale Datenbanken oder umgekehrt (transformieren) Synchrone oder asynchrone Datenpropagation • Nachführen von Änderungen in nichtrelationalen Datenbanken auf relationale Datenbanken oder umgekehrt 22 © Copyright IT-Consulting Alois Hofinger 2006 Abbildungsregeln zwischen Ausgangs- und Zielsystem Grundsatz Die Entitätsmengen des Ausgangssystems müssen auf eindeutige Art und Weise in den Tabellen des Zielsystems abgebildet werden 23 © Copyright IT-Consulting Alois Hofinger 2006 Extraktion von Geschäftsregeln Separieren von Softwareaktivitäten (z.B. Handhabung einer Bildschirmmaske oder Persistierung) von Geschäftswissen Extraktion von Geschäftsregeln in maschinenlesbarer Form Potentielle Modifikation von Geschäftsregeln und automatisches Generieren von neuem Kode Geschäftsregeln beschreiben Anwendungslogik in geschäftlicher Terminologie anstatt in einer obskuren Programmiersprache 24 © Copyright IT-Consulting Alois Hofinger 2006 Extraktion von Geschäftsdaten als Basis für GeschäftsregelnExtraktion Die Geschäftslogik innerhalb exisitierender Systeme verweist auf Geschäftsdaten. Die Verwendung dieser Geschäftsdaten als Grundlage für die Extraktion von Geschäftsregeln ist ein effektiver Weg zur Sicherstellung, daß die Analyse von Geschäftsregeln die Projektziele befriedigt. Die Extraktion von aussagefähigen Geschäftsdaten kann durch Werkzeuge unterstützt werden. Zum extrahieren aussagefähiger Geschäftsdaten aus einem Legacy System, wo sich die meisten Domäne-Experten bereits in Ruhestand befanden, wurde wie folgt vorgegangen: Beschaffen aller relevanten Systemartefakte, einschließlich Quellenkode, DDL, Batch und Online Steuertabellen, Skripte und JCL-Strukturen und andere Artefakte, die das System ausmachen. Verwenden eines Analyse-Werkzeuges zum Erfassen und Organisieren aller Datendefinitionen in gebräuchliche Datengruppen (z.B. Satz, Tabelle oder Segment). Die Gruppierungskriterien beinhalten Verbindungen zu externen Datenstrukturen, Übertragungsverbindungen (z.B. CALL, MOVE, usw.) und Gruppenlänge. Rationalisieren von Datengruppen durch ausfiltern von Daten, die nicht direkt oder indirekt an eine physische Datei, Datenbank, Benutzerschnittstelle oder andere externe Strukturen gebunden sind. Bewerten und ausfiltern von Datengruppen, die keine Geschäftsdaten darstellen, z.B. eine Tabelle zur Kontrolle eines Batch-Jobflusses. Auswahl einer Untermenge von Datengruppen von Interesse, basierend auf projektspezifische Ziele, in Zusammenarbeit mit Domäne-Experten. 25 © Copyright IT-Consulting Alois Hofinger 2006 Beispiel 1: Einsatz eines Query-Produktes für eine hierarchische Datenbank Was verbirgt sich hinter einem DL1-Segment? A 4K ? B C F D G E 26 © Copyright IT-Consulting Alois Hofinger 2006 Beispiel 2: Migration von VSAM nach einer relationalen Datenbank Wieviele Arten von Geschäftsdaten/Dimensionen verbergen sich in einem Control Interval? Beweggründe Ausgangssituation Vorgehen Ergebnisse Grösse des Nachtfensters? 27 © Copyright IT-Consulting Alois Hofinger 2006 Beispiel 3: Outsourcing der gesamten IT einer Grossbank und dabei stufenweise Umstellung des Kernbankensystems auf SAP Wieviele Schnittstellen/Daten hat oder braucht ein Kernbankensystem? BUSY Front End (BFE) Busy DI BUSY ON Siebel Anwend ungen SAP Batch DI Front Ends BAP90 Filialrechner BF90 Dispatcher Dispatcher Erweiterung BRE BF 90 Bestandsführung Stand 2003 nach Einführung von Lösungspaket 1 Data Mapping BUSY + HDA SAP-BCA SAP-CML Integrato r Zu bedienende Systeme 28 SAP-FI AMV ADB TOP100 ASD TOP100 OSY weitere Systeme © Copyright IT-Consulting Alois Hofinger 2006 Beispiel 4: Aufbau von konsistenten Kundeninformation (Customer Database) aus unterschiedlichen operativen Datenhaltungen Wie kann ich sicherstellen, daß die Kundendaten immer aktuell sind? Kunden Datenbank Autorisierung/ Autorisierung/ Authentisierung Authentisierung Interfaces:MQ, MQ,DB2connect DB2connect...... Interfaces: Web Web Portal Portal Bereitstellung Directory Directory Services Services Oracle Oracle Aufbereitung Clearing Clearing Stelle Stelle Anlieferung Back-End Prozesse (operative Bestände) AA Externe Externe Daten Daten BB CC Vality ValityIntegrity Integrity Services Services Kunden Kunden DB DB Kundensicht Kundensicht Referenz Referenz Extract Extract Transform Transform Load Load Interfaces Interfaces Front-End Prozesse (Web Applications) Meta Meta daten daten DB2 DB2 IMS... IMS... OS/390 OS/390 Unix Unix Netzwerk Netzwerk 29 © Copyright IT-Consulting Alois Hofinger 2006 Beispiel 5: Auslagerung von 4 Anwendungsgebieten von Firma A nach Firma B und Datenhaltung für parallele Nutzung durch Firma B und Firma A Was ist die technisch/wirtschaftlich und politisch machbare Lösung? Alternative 1 Legacy-Datenhaltung Daten ... ... relationale-Datenhaltung 30 semantisches Mapping auf eine Datenhaltung und anschließende physische Migration der Daten Daten ... Daten ... ... Legacy-Datenhaltung ... Legacy- oder relationale Datenhaltung Daten ... ... relationale-Datenhaltung Datentransformationslayer/ Datenbereitstellung Daten ... ... Alternative 2 Firma B Anwendung TP-Anwendung Firma A Anwendung TP-Anwendung Verbundpartner Anwendung Web-Anwendung © Copyright IT-Consulting Alois Hofinger 2006 Beispiel 6: Handlungsempfehlungen zum Datenmanagement einer Grossbank Wie können die Qualität der Datenhaltung und die Akzeptanz des DWH verbessert werden? Handlungsempfehlung Nutzen Aufbau eines Metadatenmodells Leichte und schnellere Abbildung fachlicher Anforderungen auf technische Datenobjekte Bankweite, eindeutige Semantik der Datenobjekte Auflösung von „Kopfmonopolen“ Kürzere Entwicklungszeiten durch gezielte Wiederverwendung bestehender Datenobjekte Einführung eines zentralen und projektübergreifenden Datenqualitätsmanagements Reduktion des manuellen Aufwands Vermeidung von Inkonsistenzen in operativen und dispositiven Datenbeständen 31 © Copyright IT-Consulting Alois Hofinger 2006 Beispiel 7: Aufbau eines Data Warehouses für die operative Abwicklung von Kreditkarten Wie kann ich die Fachbereichsanforderungen auf operative Quellensysteme im Ausland abbilden? 3rd Party-Providers Rechnungswesen DL1 DB2 Buchhaltung Mahnwesen ETL Data Warehouse DB2 Datamart X-tions Daten Marketing Datamart Mutterhaus 32 RisikoContr. © Copyright IT-Consulting Alois Hofinger 2006
