Folie: 1 © by Dressler & Wagner Mai 2002DATA MANAGEMENT Im schlimmsten Falle … Helmut Dressler: Data Management Im schlimmsten Falle … Der »Worst Case«

© by Dressler & Wagner • Mai 2002 DATA MANAGEMENT • Im schlimmsten Falle …

Folie: 1

Helmut Dressler:

Data ManagementIm 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

www.hduw.de


Folie: 2

Datenadministration… auch eine »Definition ihrer Aufgaben«

❶ Meta-DatenmodellDaten-administration

❷Vereinheitlichungvon Namen undBedeutungen❸ Datenkatalog(Data Dictionary)❹ AbstimmungzwischenAnwendungen

❺ AktiveQualitätssicherung

(1)

Regeln zur Datenmodellierung, Maßnahmen zur Redundanzfreiheit, UDM, QS-Regelung

Attribute: eindeutig •

»sprechend« • mit

Informationstyp • Rolle • …

Attribute • Entities • Relationships • Views

• mehrere Strukturen in einem System • …

Zentrales Projektbüro •

Verwaltung aller Datendefinitionen • Schnittstellen •

…

Genehmigungs-verfahren •

Metamodell-Überwachung • …


Folie: 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 …

Nicht auf einen Schlag umstellen, denn das gäbe

vermutlich einen.

• 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.)

• 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


Folie: 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

• 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. …

Ständig doppelte Transaktionen!

* Vogelscheuche des Teufels


Folie: 5


• 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 ManagerView Manager mit dem Zugriff beauftragt werden (je Datei). Solche Zugriffsroutinen für dieselben Views werden auch für die neue Datenbank in den

Brokern (VMVM) 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.


Folie: 6

• 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.



Folie: 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 (AN) und Inbetriebnahme der Programme (n)

* KO-Kriterium


Folie: 8

Vorgehensweise in Etappen • 2 (3)

auch einProgrammnoch einProgramm

einProgrammvorher

nachher

auch einProgramm noch einProgramm

einProgrammverschiedeneBroker

später

auch einProgramm noch einProgramm

einProgrammverschiedeneBroker2.Version

angepasst

angepasst

angepasst


Folie: 9

Data Dictionary: aus ALT mach NEU! (4)

DATA DICTIONARY

System

Data DictionaryAnwendungs-

Struktur {

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

{• 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

Konzept Rezept: D&W-DaDicD&W-DaDic


Folie: 10

Data Dictionary: aus ALT mach NEU! • 2 (4)

Lexikon& Hilfeseparat , auch überObjektinformationenObjektinformationen

AttributAttributAttribute jeAttribute jeFileFileAttributgruppeAttributgruppe

RelationshipRelationshipFile-GruppeFile-Gruppe

View / SichtView / Sicht(primär & sekundär)(primär & sekundär)Dateipflege(naldz), Anwendung = »SICHT« = Liste, Maske, Funktion, MethodeDateipflege(naldz), Anwendung = »SICHT« = Liste, Maske, Funktion, Methode

File/RelationFile/RelationRolle von…

Defaultwert-hierarchiezeigt …… aufVorgänger/Vorgänger/NachfolgerNachfolgerObjekt-Objekt-InformationenInformationen

View-SichtView-SichtAttributeAttributeim Primär-Viewim Primär-View

View/ Sicht jeView/ Sicht jeAnwendungAnwendung© D&W-DaDic© D&W-DaDic


Folie: 11

Data Dictionary: aus ALT mach NEU! • 3 (4)

DDDDALTALT:: FILE AttributeALT … je FILE

VIEW mit Attributen im Primärview, evtl. gar aus verschiedenen Files

DefaultwerthierarchieALT

DDDDNEUNEU:: FILE/Relation AttributeNEU … je FILE/Relation

AttributNEU ist Nachfolger von AttributALT

VIEWNEU mit Attributen im Primärview, sicherlich aus verschiedenen Files

DefaultwerthierarchieNEU

Lexikon& Hilfeseparat , auch überObjektinformationenObjektinformationen

AttributAttributAttribute jeAttribute jeFileFileAttributgruppeAttributgruppe

RelationshipRelationshipFile-GruppeFile-Gruppe

View / SichtView / Sicht(primär & sekundär)(primär & sekundär)Dateipflege(naldz), Anwendung = »SICHT« = Liste, Maske, Funktion, MethodeDateipflege(naldz), Anwendung = »SICHT« = Liste, Maske, Funktion, Methode

File/RelationFile/RelationRolle von…

Defaultwert-hierarchiezeigt …… aufVorgänger/Vorgänger/NachfolgerNachfolgerObjekt-Objekt-InformationenInformationen

View-SichtView-SichtAttributeAttributeim Primär-Viewim Primär-View

View/ Sicht jeView/ Sicht jeAnwendungAnwendungDokumentation zweier Datenstrukturen

© D&W-DaDic© D&W-DaDic


Folie: 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.

DATADICTIONARY(2 Views der neuenBROKER-Schicht

(3) Programmänderungen:Zugriff nur nochmittels Broker

ALT

NEU

(1) DataDictionaryALT + NEU (DB-Entwurf)(4) Migration

P01P02P03P04P05P06P07P08P09P10P11P12{}

Minimierung des Codes durch »redundanzfreie

Einmaligkeit« der Zugriffsnavigation

Nebenbei:Spaghetti-

Entflechtung, Standardisierung,Dokumentation

&Vorbereitung für die neueDatenbank!


Folie: 13

Ohne Broker geht es nicht • 2 (5)

• Ultimative View Manager Technik (UVMT) beispielsweise:

AM.92

VM.05 DM.67

… ruft nun auf:… SELECT

und dynamischeBindung

Zwischen SELECTund END SELECTViele Zugriffe und Aufrufe

…druckt „View-für-View“ Listen nach dem GRUPPENWECHSEL-Schema

…und bucht o.ä.

VM.07

… ruft auf:

… greift aufeinzelne Views zu,z.B. WRITE

Diese Technik Diese Technik ist nicht ist nicht

selbstverständlich.selbstverständlich.

Legende:AM=Anwender-ModulVM=View ManagerDM=Dienst-Modul


Folie: 14

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


Folie: 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


Folie: 16

Danke für Ihre Aufmerksamkeit !

D&W ANHANG

Software Engineering Competence

Ihr Beraterteam für die wesentlichen

Aufgaben moderner Software-Entwicklung

Helmut Dressler

Lauteschlägerstr. 19

64289 Darmstadt

Tel. 49.6151.715945

Fax 49.6151.788538

eMail: [email protected]

Dressler & Wagner

Uwe Wagner

Alsbacher Str. 45

64342 Seeheim-Jugenheim

Tel. 49.6257.903348

Fax 49. 6257.903347

eMail: [email protected]

KNOW HOW Darstellung z.Zt.:

• PQ2Checkup • • PPM-Seminar • • DB-Entwurf •

• Projektmodell •• SW-Qualität •

www.hduw.de


Folie: 17

(1) Fünf-Schichten-Architektur ANHANG

(2) E/A - »logische Masken« / Client(3) Funktionen: E/A-Steuerung, (Batch?)Dienste, Ablauflogik, Algorithmen,(1) Individuelle graphische Oberfläche (GUI)evtlevtl. auch im. auch imI…NetI…Net… eigentlichdie wichtigstenTrennlinien

DB

}}VerarbeitungenFunktionen fürpersistenteObjekte}}}}

c) Präsentation und Eingabeb) GUI-neutraleAufbereitung derSchnittstellea) Das Benutzer-Programm ist aktivd) LogischeDatenzugriffe aufSichten und Viewse) PhysischeDatentzugriffe, evtlmit “Inline-Batch”Schnittstellen

DataDataContainerContainer

(4) Broker • View Manager• »Sicht-Knechte«(5) DB-Zugriffe / Server / Batch

Anwender-Dialoge


Folie: 18

(2) Datenbank-Entwurf ANHANG

Inhaltsverzeichnis

Vorwort1. Übersicht über die Begriffswelt 2. Objekttypen3. Beziehungstypen4. Das Entity-Relationship-Diagramm (ERD)5. Relationen und Relationenalgebra6. Datenstrukturen in Datenbanken und Dateisystemen7. Leistungen eines modernen DBMS8. Entwurfsziele: Anzustrebende Produkte & Ergebnisse 9. Ein kleines Beispiel (Chargen)10. Beziehungskombinatorik (mit Wein-Datenbank)11. Entwurfsprinzipien und Modellbildung12. Einzelne spezielle Aspekte13. Ein großes Beispiel (“Ewige Wahrheiten”)14. View Manager und “Sicht-Knechte”15. Navigation in Datenstrukturen16. Implementierung einer Datenstruktur 17. Abschließende Überlegungen LiteraturverzeichnisIndexnun ¤ 25,– © nur bei uns


Folie: 19

(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

Copyright © by H. Dressler

unsere unsere 88LeistungenLeistungen

Documents

Folie: 1 © by Dressler & Wagner Mai 2002DATA MANAGEMENT Im schlimmsten Falle … Helmut Dressler: Data Management Im schlimmsten Falle … Der »Worst Case«