Helmut Dressler: Data Management Im schlimmsten Falle … • Der »Worst Case« der Datenadministration und wie man ihm begegnen müßte • Helmut Dressler.

Präsentation zum Thema: "Helmut Dressler: Data Management Im schlimmsten Falle … • Der »Worst Case« der Datenadministration und wie man ihm begegnen müßte • Helmut Dressler."—  Präsentation transkript:

1 Helmut Dressler: Data Management Im schlimmsten Falle … • Der »Worst Case« der Datenadministration und wie man ihm begegnen müßte • Helmut Dressler & Uwe Wagner 1) Datenadministration (Aufgaben) 2) Worst Case: Aufgabe, Zielbestimmung, Risiken und Erfolgskriterien 3) Vorgehensweise in Etappen 4) Data Dictionary: aus ALT mach NEU! 5) Ohne Broker geht es nicht 6) Teststrategie 7) Begründete Aussicht auf Erfolg © by Dressler & Wagner • Mai 2002 DATA MANAGEMENT • Im schlimmsten Falle …

2 Datenadministration … auch eine »Definition ihrer Aufgaben«
(1) Regeln zur Datenmodellierung, Maßnahmen zur Redundanzfreiheit, UDM, QS-Regelung Attribute: eindeutig • »sprechend« • mit Informationstyp • Rolle • … Genehmigungs-verfahren • Metamodell-Überwachung • … Zentrales Projektbüro • Verwaltung aller Datendefinitionen • Schnittstellen • … Attribute • Entities • Relationships • Views • mehrere Strukturen in einem System • … © by Dressler & Wagner • Mai 2002 DATA MANAGEMENT • Im schlimmsten Falle …

3 Worst Case: Aufgabe, Zielbestimmung, Risiken und Erfolgskriterien
(2) Änderungsprojekt: Weil das System-Know-how nicht dokumentiert ist und nur in den Programmen steckt, aber auch die Dateistruktur als chaotisch und nicht mehr erweiterungsfähig gilt, soll sie demnächst und so schnell wie möglich durch eine neue Datenbank ersetzt werden! Rasch sollen neue Funktionen auf der neuen Datenbank implementiert und die alten Programme baldmöglichst schrittweise ersetzt werden. Sie müssen aber erst so angepaßt werden, daß sie auch mit der neuen Datenstruktur arbeiten. Es soll das kontinuierlich in kleinen Schritten und ohne Bruch geschehen und die Möglichkeit erhalten werden, daß man einfach und ohne Datenverluste zur alten Version zurückkehren kann … Alternative: Alles auf z.B. SAP/Rx umstellen und Workflow und Organisation an den Standard anpassen. (Da ginge wertvolles Know How verloren und wäre teuer.) Nicht auf einen Schlag umstellen, denn das gäbe vermutlich einen. Also etwa so(?): Neue Datenbank konzipieren und installieren In einem System mit zwei Datenbanken arbeiten, langsam ab-/aufbauen Alte Programme schrittweise umstellen und neue P-Versionen für neue DB installieren; alte DB schrittweise außer Betrieb setzen Schließlich alte Datenbank, wenn alles fertig ist, abschaffen. Kontinuierlich neue Programme für die neue DB entwickeln © by Dressler & Wagner • Mai 2002 DATA MANAGEMENT • Im schlimmsten Falle …

4 Worst Case: Aufgabe, Zielbestimmung, Risiken und Erfolgskriterien • 2
(2) So nicht (ist popancus diaboli*): Neue Datenbank konzipieren und installieren In einem System mit zwei Datenbanken arbeiten, langsam ab-/aufbauen Alte Programme schrittweise umstellen und neue P-Versionen für neue DB installieren; alte DB schrittweise außer Betrieb setzen Schließlich alte Datenbank, wenn alles fertig ist, abschaffen. Kontinuierlich neue Programme für die neue DB entwickeln * Vogelscheuche des Teufels Ständig doppelte Transaktionen! Risiko und Aufwand zu groß: In jedem Programm redundant immer wieder ähnliche Routinen verfassen … … so daß in jedem Programm zwei Zugriffsverfahren implementiert sind. … oder immer zwei Datenbanken, die exakt gleiche Informationen enthalten müßten! … und jeweils zwei betriebsbereite Versionen (neu, alt) der alten Programme. Programme mit »SchrottanteilenALT«: Die Übersicht ginge leicht verloren. Rücknahme eines (fehlerhaften) Neu-Programms, wenn die Daten nicht mehr stimmen, führte zu Konvulsionen & Verzweiflung. Immerwährende Höchstspannung aller Beteiligten. … © by Dressler & Wagner • Mai 2002 DATA MANAGEMENT • Im schlimmsten Falle …

5 Worst Case: Aufgabe, Zielbestimmung, Risiken und Erfolgskriterien • 3
(2) Zielvorgaben & Erfolgskriterien: Immer nur eine Programmversion, Ablösung alt  neu. Die neuen P-Versionen laufen ohne weitere Umstellung mit beiden Datenbanken, wenn sie es »global« oder per Input mitgeteilt bekommen, welche gerade »dran« ist. Neu Version der alten Programme nun auch vereinfacht, konsolidiert und knapp dokumentiert (Nebennutzen) Übergang Datenbank-Alt  Datenbank-Neu zum Stichtag mit einmaliger DB-Umstellung nach Testestestestestestest , dann ohne irgendeine Programmumstellung. Je nach Bedarf alte Programme später weiterhin anpassen oder ersetzen. Kontinuierlich/evolutionär neue Programme für die neue DB entwickeln. Basisideen: Programme benutzen Datensätze, diese lassen sich als Views auffassen. In der neuen Datenbank müssen u.a. die alten Informationen erhalten bleiben, aber anders (= gut & richtig) strukturiert. Die Zugriffsroutinen in den alten Programmen werden umgeschrieben, so daß sie jene Sätze=Views erhalten, aber View Manager mit dem Zugriff beauftragt werden (je Datei). Solche Zugriffsroutinen für dieselben Views werden auch für die neue Datenbank in den Brokern (VM) entwickelt: dieselben Ergebnisse bei unterschiedlicher Navigation. Wenn sie getestet sind, wird die Datenbank umgestellt und den Programmen mitgeteilt, welche DB gerade akut ist. So wird auch getestet. © by Dressler & Wagner • Mai 2002 DATA MANAGEMENT • Im schlimmsten Falle …

6 Worst Case: Aufgabe, Zielbestimmung, Risiken und Erfolgskriterien • 4
(2) Weitere Vorstellungen: Absolute 1:1-Funktionsumstellung, keinerlei „Verbesserungen“ im Zuge der Umstellung. Alte Funktionsprogramme sind in einem ersten Schritt zu analysieren und zu schematisieren, bevor sie (nach Schema) auf View-Manager-Betrieb umgestellt werden. Broker (View Manager) sollen fertig (getestet) sein, bevor sie von Funktionsprogrammen benutzt werden; man muß also einzelne Programme nur wenig testen. Der Sinn der Sache: Den alten Programmen soll, ohne daß sie es „merken“, die alte DB später „unterm Hintern“ weggezogen und durch die neue ersetzt werden. Intensiver Test der Broker durch generellen Modulprüfstand (derselbe für alle!) mit leichter Montage. Abnahme nach Fertigstellung einzelner Funktionsprogramme gleitend. Inbetriebnahme einzelner Funktionsprogramme nach Abnahme. Die Broker fragen in einer globalen Tabelle, ob sie mit der alten oder der neuen Datenbank arbeiten (zunächst nur alte). Rückkehr zur alten Technik mit der alten DB je Funktionsprogramm jederzeit möglich. Stand-by-Krisenmanagement, wenn verknotete Spaghettistrukturen entdeckt werden, die ein einzelner nicht zu entwirren versteht. Die View Manager sollen später in Servern auch variabel Listen und Formulare drucken; die heutigen Listen – batch – sollen bereits auf diese Technik (nach Gruppenwechselschema) umgestellt werden, aber genau (!) dasselbe drucken wie vorher. © by Dressler & Wagner • Mai 2002 DATA MANAGEMENT • Im schlimmsten Falle …

7 Vorgehensweise in Etappen
(3) Aufgaben – teilweise nebenläufig: (1) Dokumentation der alten Dateistruktur (A) (2) Falls Source noch vorhanden*: Erste systematische Analyse der Programme mit »Destillation« von Views (auch evtl. aus mehreren Datensätzen) (3) Ausarbeitung und Implementierung der View-Manager-Technik (Modul-Frames, Interfaces, CALL-Konventionen, Gruppenwechselverfahren für Batch) (4) Entwurf der neuen Datenbankstruktur (N) (5) Entwurf und Implementierung eines Modulprüfstands (für alle VM (A) ) (6) Implementierung der View Manager und Test mit Modulprüfstand (7) Zweite systematische Analyse der Programme auf Möglichkeiten hin zum standardisierten Einbau der VM. Spaghettizusatzprobleme lösen! (8) Testumgebung für Programmumstellung einrichten (9) Umstellung der einzelnen Programme: VM-Calls (a/n) anstatt individueller Zugriffe mit Test in der Testumgebung, Abnahme und Inbetriebnahme (a) (einzeln, denn sie sollen exakt dieselbe Leistung bringen wie vorher!) (10) Test-Implementierung der neuen Datenbank (N) (11) Erweiterung der View Manager (VM (N) ) für Zugriffe auf die neue Datenbank mit Tests über Modulprüfstand (n) (12) Testimplementierung (n) der Programme auf der neuen Datenbank (13) Datenbank-Umstellung (AN) und Inbetriebnahme der Programme (n) * KO-Kriterium © by Dressler & Wagner • Mai 2002 DATA MANAGEMENT • Im schlimmsten Falle …

8 Vorgehensweise in Etappen • 2
(3) vorher später nachher angepasst angepasst angepasst © by Dressler & Wagner • Mai 2002 DATA MANAGEMENT • Im schlimmsten Falle …

9 Data Dictionary: aus ALT mach NEU!
{ Data Dictionary: aus ALT mach NEU! (4) Werkzeug zur Speicherung von DD-Anwendungsstrukturen (Pl.) Die ganze Anwendungs-Datenstruktur: Kein Aspekt – inklusive ERD – soll nicht abbildbar sein. Also: Attribute, Relationen (Entitäten), Relationships, Sichten in beliebiger Struktur Wenn möglich: Automatische ERD-Graphik Verschachtelte, hierarchische Sichten kein Hindernis DATA DICTIONARY System { Konzept Rezept: D&W-DaDic Jede konkrete Anwender-Datenstruktur soll mit einem DD-System vollständig verwaltet werden können. Beziehungen der Attribute ALT  NEU, damit auch DB-Umstellungen dokumentiert werden können. Funktionen (Methoden) für Views/Sichten sind darstellbar View Manager (Broker) realisieren die Methoden Defaultwerthierarchie (»Daten-Vererbung«) selbstverständlich Data Dictionary Anwendungs-Struktur © by Dressler & Wagner • Mai 2002 DATA MANAGEMENT • Im schlimmsten Falle …

10 Data Dictionary: aus ALT mach NEU! • 2
(4) © D&W-DaDic © by Dressler & Wagner • Mai 2002 DATA MANAGEMENT • Im schlimmsten Falle …

11 Data Dictionary: aus ALT mach NEU! • 3
(4) DDALT: FILE AttributeALT … je FILE VIEW mit Attributen im Primärview, evtl. gar aus verschiedenen Files DefaultwerthierarchieALT DDNEU: FILE/Relation AttributeNEU … je FILE/Relation AttributNEU ist Nachfolger von AttributALT VIEWNEU mit Attributen im Primärview, sicherlich aus verschiedenen Files DefaultwerthierarchieNEU Dokumentation zweier Datenstrukturen © D&W-DaDic © by Dressler & Wagner • Mai 2002 DATA MANAGEMENT • Im schlimmsten Falle …

12 Ohne Broker geht es nicht
(5) Vom Datensatz zum VIEW: Die Herkunft ändert sich; die Verwendung bleibt (exakt) dieselbe. Wenn jedes alte Programm auf seine Weise neu navigieren müßte, wäre Chaos die Folge. Minimierung des Codes durch »redundanzfreie Einmaligkeit« der Zugriffsnavigation Nebenbei: Spaghetti- Entflechtung, Standardisierung, Dokumentation & Vorbereitung für die neue Datenbank! © by Dressler & Wagner • Mai 2002 DATA MANAGEMENT • Im schlimmsten Falle …

13 Ohne Broker geht es nicht • 2
(5) Ultimative View Manager Technik (UVMT) beispielsweise: AM.92 … ruft nun auf: Diese Technik ist nicht selbstverständlich. … SELECT und dynamische Bindung VM.05 DM.67 …druckt „View-für-View“ Listen nach dem GRUPPENWECHSEL-Schema Zwischen SELECT und END SELECT Viele Zugriffe und Aufrufe Legende: AM=Anwender-Modul VM=View Manager DM=Dienst-Modul … ruft auf: VM.07 … greift auf einzelne Views zu, z.B. WRITE …und bucht o.ä. © by Dressler & Wagner • Mai 2002 DATA MANAGEMENT • Im schlimmsten Falle …

14 DATA MANAGEMENT • Im schlimmsten Falle …
Teststrategie (6) Einige guten Prinzipien der Testmethodik sind gewahrt: Separater Test der VM-Bausteine … … durch Testdriver = Modulprüfstand … … auch (späterNEU) in mehreren Montageebenen (»Sichtsichten«) Separater Integrationstest (nur Einzelprogramme) Simple Rückkehrmöglichkeit (ALT  URALT) bei Fehlern Eigene Testumgebungen (DBALT & DBNEU) Einfacher Funktionsvergleich (ALT/NEU) : exakt dieselben Resultate Andere können berücksichtigt werden: Testdatenbibliothek: URALT  ALT  NEU { gleiche Ergebnisse! Gleitende Abnahme der Programme Testziele (=Testende-Kriterien) je Objekt definieren © by Dressler & Wagner • Mai 2002 DATA MANAGEMENT • Im schlimmsten Falle …

15 Begründete Aussicht auf Erfolg
(7) Spaghettientwirrnis Redundanzverminderung Nachträgliche Teilmodularisierung Separattests Testvergleich einfach ALT NEU Teilstandardisierung der Programme Standardisierung der Broker Gruppenwechsellogik (batch) Zukunftsfähigkeit © by Dressler & Wagner • Mai 2002 DATA MANAGEMENT • Im schlimmsten Falle …

16 Danke für Ihre Aufmerksamkeit !
D&W ANHANG Dressler & Wagner Software Engineering Competence Ihr Beraterteam für die wesentlichen Aufgaben moderner Software-Entwicklung Danke für Ihre Aufmerksamkeit ! Helmut Dressler Lauteschlägerstr. 19 64289 Darmstadt Tel Fax KNOW HOW Darstellung z.Zt.: • PQ2Checkup • • PPM-Seminar • • DB-Entwurf • • Projektmodell • • SW-Qualität • Uwe Wagner Alsbacher Str. 45 64342 Seeheim-Jugenheim Tel Fax © by Dressler & Wagner • Mai 2002 DATA MANAGEMENT • Im schlimmsten Falle …

17 (1) Fünf-Schichten-Architektur
ANHANG © by Dressler & Wagner • Mai 2002 DATA MANAGEMENT • Im schlimmsten Falle …

18 DATA MANAGEMENT • Im schlimmsten Falle …
(2) Datenbank-Entwurf ANHANG Inhaltsverzeichnis Vorwort 1. Übersicht über die Begriffswelt 2. Objekttypen 3. Beziehungstypen 4. Das Entity-Relationship-Diagramm (ERD) 5. Relationen und Relationenalgebra 6. Datenstrukturen in Datenbanken und Dateisystemen 7. Leistungen eines modernen DBMS 8. Entwurfsziele: Anzustrebende Produkte & Ergebnisse 9. Ein kleines Beispiel (Chargen) 10. Beziehungskombinatorik (mit Wein-Datenbank) 11. Entwurfsprinzipien und Modellbildung 12. Einzelne spezielle Aspekte 13. Ein großes Beispiel (“Ewige Wahrheiten”) 14. View Manager und “Sicht-Knechte” 15. Navigation in Datenstrukturen 16. Implementierung einer Datenstruktur 17. Abschließende Überlegungen Literaturverzeichnis Index nun ¤ 25,– © nur bei uns © by Dressler & Wagner • Mai 2002 DATA MANAGEMENT • Im schlimmsten Falle …

19 Ultimative View Manager Technik
(3) UVMT ANHANG Die umfaßt: Broschüre: UVMT – Theorie und Praxis (Manual) UVMT-Einführungsseminar Definition der Standardschnittstelle mit Erläuterung UVMT-Montage-Prozeduren = simpler Aufruf, starke Leistung Standard- und Muster-Module (Listen und Sourcetextdatei) in einer Host-Sprache (Natural, Cobol, C, Java, Assembler, …) Ablauffähiges Musterbau-System in der Host-Sprache Einführungsberatung (Entwurf und Betreuung beim Pilotprojekt) Review und Erfahrungs-Auswertung nach dem Pilotprojekt Ultimative View Manager Technik Copyright © by H. Dressler unsere 8 Leistungen © by Dressler & Wagner • Mai 2002 DATA MANAGEMENT • Im schlimmsten Falle …