LÜNEBURG - Die Methodik des Datenbank-Designs aus nutzerorientierter Sicht war eines der Hauptthemen der Lüneburger Jahreskonferenz des Orgware-Benutzerrings (OBR) - siehe dazu auch CW 28. Die beiden Methodenberater der Wilhelmshavener ADV/Orga GmbH Heinz Münzenberger und Karl Anton Dreibholz unterrichteten eine Minderheit der Tagungsteilnehmer von knapp 100 interessierten sich gerade zehn - über eine DB-Design-Methodik, die bei ADV/Orga in Zusammenhang mit einem Auftrag des Koblenzer Bundesamtes für Wehrtechnik und Beschaffung erarbeitet worden war.
An das Plenum der Orgware-Benutzer gewandt, meinte ADV-Bereichsleiter Gunther Lüth einleitend, wenn bei diesem Orgware-unabhängigen Entwurfskonzept von einer "Methodik" die Rede sei, so bedeute dies, daß hier unter anderem eine erste Diskussionsgrundlage über Nutzen und Schwierigkeiten einer eventuellen Übernahme dieses Ansatzes ins Orgware-System geliefert werde. Münzenberger begann seine Ausführungen im DB-Design-Workshop mit dem Versuch einer Definition dessen, was Datenbank-Design ist.
Nach seiner Ansicht handelt es sich dabei um "die Modellierung des Inhalts, der Struktur und der Semantik von Daten in eine Form, die vom DBMS akzeptiert wird". Warum es wichtig sei, das Augenmerk darauf zu lenken, mahnte Münzenberger, belege eine 1978 in 89 repräsentativen Unternehmen Westeuropas durchgeführte Befragung: 67 Prozent der untersuchten Unternehmen, ergab die Analyse, machten ihre Datenbankentwürfe - logische wie physische - rein intuitiv, 22 Prozent benutzten einzelne Tools und nur elf Prozent systematische Technik und Methodik.
Kriterium Flexibilität
Ein Datenbankentwurf muß - schilderte Münzenberger das Pflichtenheft der Design-Entwickler- eine genaue Abbildung der Realität sein, alle existierenden Prozesse unterstützen, erweiterbar sein und flexibel, um neue Anwendungen zu unterstützen. Andernfalls sehe sich der Anwender konfrontiert mit fehlenden oder ineffizienten Daten sowie häufigen Reorganisationen und teuren Umstrukturierungen.
Die von ADV/Orga erarbeitete Design-Methodik, die Dreibholz den Workshop-Teilnehmern sodann vorstellte, weist die drei Hauptphasen Konzeption, Definition und Realisierung auf. Ihrerseits besteht die Konzeption aus
- Informationsanalyse,
- logischem Modell,
- Realisierungsmöglichkeiten und
- physischem Modell;
Definition aus
- logischem Modell,
- physischem Modell und
- Realisierungsplanung;
Realisierung aus
- Datenbank Software,
- Implementierungsplanung und
- Implementierungsmaßnahmen.
Auf nächstniedrigerer Modulebene sind sodann Checklisten abzuarbeiten (mit Checkpoints an jedem Schrittende), wobei für jeden Einzelpunkt nochmals eine "Untercheckliste" existiert, die zu demonstrieren allerdings im Interesse der Übersichtlichkeit für die Workshop-Teilnehmer unterblieb. Es folgen drei Beispiele für den Inhalt der "Haupt"-Checkliste:
Beispiel A aus der Phase "Konzeption"
Realisierungsmöglichkeiten
þBerücksichtigen Forderungen und Restriktionen
þPrüfen Machbarkeit
þErarbeiten Realisierungsvorschlag für DB-Software
þAufzeigen Auswirkungen
Beispiel B aus der Phase "Definition"
Physisches Modell (Ausschnitt)
þAbleiten physische Zugriffspfade
þErarbeiten Speicherungskonzept
þEntwerfen Datensicherungskonzept
þAnalysieren DB/DC-Schnittstellen
Beispiel C aus der Phase "Realisierung"
Implementierungsplanung (Ausschnitt)
þFestlegen Speicherzuordnung
þFestlegen Generierungsmaßnahmen für DB-Software
þFestlegen Einführungsstrategie
þFestlegen Abläufe im RZ-Netz
Ihm sei, meinte Münzenberger, ein ähnliches Vorgehensmodell mit insgesamt 240 Einzelschritten nicht bekannt. Sein Blick über den Zaun förderte noch mehr zutage: Unter den verschiedenen DB-Design-Techniken habe DBDA (Data Base Design Aid) von IBM nur geringe Bedeutung und werde auch unbedeutend bleiben DB-Prototype werde es ähnlich ergehen. Eine bessere Zukunft prophezeite Münzenberger den Verfahren Entity Relationship und Normalisierung; vor allem aber seien logisch-physische Umsetzer im Kommen.
Was man mit dieser Methodik erarbeitet habe, sei, sagten die ADV/Orga-Vertreter, im Kern eine ausgefeilte Checkliste, ein systemunabhängiges Vorgehensmodell von der logischen Konzeption bis zur physischen Realisierung, man könne auch sagen "DV-Richtlinien". Es lohne sich durchaus, meinte Design-Mitentwickler Dr. Ernest Bula vom Schweizer Zweig der ADV/Orga, sich an diese Richtlinien zu halten.
Eingebaute DB-Auswahl
Grund: Das für die Bundesbehörde entwickelte Konzept enthalte keine allein schon in der Definition der Datenmodelle implizierte Festlegung auf ein konkretes Datenbanksystem. Die Ebene der Systemunabhängigkeit werde nämlich heute in den meisten Fällen allzu früh überschritten; und so sehe man sich der Restriktion gegenüber, mit einem vorgegebenen DB-System und seinen Zugriffsmöglichkeiten operieren zu müssen. Zudem stelle das ADV/Orga-Konzept neben dem logischen und physischen Entwurfsansatz auch einen Komplex zur Verfügung, mit dessen Hilfe das im Einzelfall bestgeeignete existente DB-System ausgewählt werden könne.
Über den erwarteten Nutzen und vermutete Anwendungsschwierigkeiten der "DV-Richtlinien" stimmte das Plenum des Orgware-Benutzerrings nach Unterrichtung über die Workshop-Ergebnisse - ab; genauer gesagt, es stimmten alle diejenigen ab die sich ein Urteil zutrauten, die anderen beschieden sich mit der Vergabe von "Passé-Punkten". Die Einführung der vorgestellten Methodik des Datenbank-Designs ins eigene Unternehmen hätte in den Augen der OBR-Mitglieder folgende Nutzeffekte:
- Zielorientiertes Vorgehen (30 Stimmpunkte)
- Prozeß wird nachvollziehbar (24 Stimmpunkte)
- Transparenz des Design-Prozesses (20 Stimmpunkte)
- Vollständigkeit der Ergebnisse (16 Stimmpunkte)
- Abgegebene Punkte insgesamt 153 darunter 28 Passé-Punkte.
Anwendungsschwierigkeiten dagegen erwarten die OBR-Members vor allem dadurch, daß des Konzept nicht in Orgware 4 integriert ist (25 Stimmpunkte), Umstrukturierung vorhandener Datenbanken erfordert (23 Stimmpunkte) oder einfach Aufwand verursacht (21 Stimmpunkte). Hier wurden insgesamt 151 Punkte vergeben, von denen 44 auf Unentschiedene entfielen.