In thematisch zusammenhängenden Beiträgen beschäftigt sieh Michael Bauer mit Fragen des Ob und Wie einer Datenbank-Implementierung, der Auswahl eines geeigneten TP-Monitors und der Ausbildungserfordernisse je nach Benutzerebene Außerdem stehen Themen wie Data Dictionary, Dritte Normalform, neue Hochsprachen und Datensicherheit im Mittelpunkt seiner Erörterungen

Michael Bauer, Leiter des Bereichs DV-Beratung bei der GES-Gesellschaft für elektronische Systemforschung mbH in Allensbach, ist seit vielen Jahren mit der Anwendungspraxis von Datenbank- und Online-Systemen vertraut. Er ist Autor zahlreicher Fachbeiträge zur DB/DC Thematik.

Kapitel V; Teil 1

Grundsätze für den Datenbankeinsatz

Im ersten Kapitel dieser Serie hatte ich die Überlegungen erläutert, ob und wann man eine Datenbank braucht. Hieraus ergab sich, daß zwar nicht für jede Unternehmung eine Datenbank jetzt schon sinnvoll oder gar notwendig ist, daß man aber auf lange Sicht gesehen wohl nicht an einer Datenbank vorbeikommt.

Dies ist ein Grund, warum sich auch Unternehmen, für die ein DB-Einsatz zur Zeit noch nicht in Frage kommt, trotzdem bereits jetzt schon mit der Problematik vertraut machen sollten. Wer jedoch schon die Implementierung einer Datenbank plant, sollte sorgfältige Vorkehrungen treffen, daß diese große Investition keine Fehlinvestition wird.

Eine Datenbank ist eine Millionen-Investition

Daß eine Datenbank ein teures Vergnügen ist, hat sich mittlerweile herumgesprochen. Die Größenordnungen werden zwar von Unternehmen zu Unternehmen unterschiedlich sein, aber man kann mit Sicherheit davon ausgehen, daß die Gesamtkosten in Millionen zu rechnen sind. Allein nur die sichtbare Spitze des Kosten-Eisbergs - Miete oder Kauf und Wartung für das DBMS und Randkomponenten - betragt bei 10jähriger Nutzung rund eine halbe Million Mark. Darüber hinaus fallen Ausbildung, Einarbeitung, Infrastrukturmaßnahmen, DB-Aufbau, Umstellungsarbeiten, Hardwaremehrbedarf, DB-Administration und -Wartung und anderes mehr an, die den großen, weniger sichtbaren Teil der Kosten ausmachen.

Unter diesen Gesichtspunkten sollte man strategische Maßnahmen für den effizienten Einsatz und für eine langfristige Stabilität der Datenbank treffen. Dazu kann man aus den Fehlern anderer lernen.

Da die GES seit gut einem Dutzend Jahren intensiv mit Datenbanken befaßt ist, hat sie viele Installationen kennenlernen können. Sehr viele Probleme, die wir angetroffen hatten sind auf Unkenntnis und auch auf Mangel an Vorbildern zurückzuführen. Deshalb hatten wir die wesentlichen Fehlerursachen - die "Kardinalfehler" - einmal für unsere Seminarteilnehmer zusammengestellt.

Die zehn Kardinalfehler der "Vergangenheit" bei der Einführung einer Datenbank

1. Eine DBMS-Entscheidung war häufig wunschorientiert aber nicht bedarfsorientiert Entsprechend wurde keine oder nur eine unzureichende DBMS-Evaluation durchgeführt. Das Ergebnis war dann oft ein DBMS, an das man seine Aufgaben anpassen mußte - statt umgekehrt.

2. Viele Anwendungen rechtfertigten nicht den Einsatz eines DBMS. Eine konsequente Organisation auf Basis konventioneller Dateien und Softwaretools wie beispielsweise File-Management-Systeme hätten dieselben Aufgaben insgesamt gesehen weit billiger gelöst

3. Zu großer Fortschrittsglaube und die euphorische Erwartungshaltung, mit der Einführung eines DBMS die Lösung sämtlicher DV-Probleme zu erzielen, führten zur Unterschätzung der Schwierigkeiten und zu Enttäuschungen bei Rückschlägen.

4. In den seltensten Fällen war fundiertes datenbanktechnologisches Wissen vorhanden. Daraus resultierte:

5. Man hat in vielen Fällen das technologisch Machbare falsch eingeschätzt.

6. Viele Anwender hatten - aus Unwissenheit oder aus Kostengründen - den Aufbau eines Data Dictionaries im Vorfeld einer komplexen Datenbanklösung unterlassen. Hierdurch wurden die Schnittstellen für eine integrierte Lösung auf Jahre verbaut.

7. Die Kosten für die "Infrastruktur" einer DB-Lösung wurden übersehen.

8. Durch ein "schlampiges" DB-Design wurde eine Situation geschaffen, die oftmals die Ursache für eine spätere schlechtere Performance wurde.

9. Man hatte mit Analyse- und Entwurfstechniken für konventionelle Lösungen Datenbanken entworfen, deren Design nicht stabil war. Fortgesetzter Aufwand für Umstrukturierungen und Anpassungen war die Folge.

10. Durch das Fehlen einer geeigneten Strategie hatte man sich zu sehr an ein DBMS gebunden. Dies hatte zur Folge, daß man nach einer Nutzungsphase von zirka zwei Jahren nicht mehr das DBMS hätte wechseln können.

wird fortgesetzt