Prof. Dr. J. Niedereichholz, Lehrstuhl für Betriebswirtschaftslehre und Informationssysteme an der Universität Frankfurt,

Geschäftsführender Direktor des Institutes für Wirtschaftsforschung.

Die Datenbankszene läßt sich mit einem Satz charakterisieren: "Die Lage ist ernst,

aber nicht hoffnungslos." Der Einsatz eines Datenbanksystems (DBS) erzeugt viele Probleme, vor denen die Anwender oft eine begründete Scheu haben. Zu nennen sind unter

anderem: Schulungskosten, Tuning-Probleme, Kompatibilitätszwänge, Sicherheitsprobleme, Probleme verteilter Datenbanken, irreversibler Charakter der Entscheidung, psychologische und soziale Probleme der Einführung etc. Drei Problemkreise sollen vor dem Erfahrungshintergrund des Autors bei DBS-Vergleichen skizziert werden:

- DB-Erstanwender

- DB-Aufsteiger und - Wechsler

- Aufkommen relationaler DBSe,

DB-Erstanwender stehen (hauptsächlich auf IBM und Siemens bezogen) vor einer verwirrenden Fülle von DBS-Angeboten: Soll man adabas, CICS, datacom, DL/1, IDMS, ISOGEN, MARK IV, NIMS, S2000, TOTAL, UDS oder weitere Systeme in die Auswahl einbeziehen?

Generell gilt die Empfehlung, in der Auswahlphase gründlich vorzugehen. Der Einsatz eines Datenbanksystems bindet stark: "Drum prüfe, wer sich ewig bindet!"

In den entscheidenden Phasen einer DBS-Auswahl werden die folgenden Feststellungen immer wieder bestätigt:

Wenn die DBS-Auswahl ein sinnvolles Ergebnis bringen soll, muß der Anwender das eigene, augenblickliche sowie das geplante zukünftige Anwendungsspektrum einigermaßen genau kennen. Die entsprechende Analyse-Phase muß gründlich betrieben werden.

Oft ist der Sprung zum DBS nicht unbedingt notwendig. Man muß prüfen, ob er nicht durch eine gewisse DB-Euphorie nur suggeriert wird.

Eventuell kann die Entscheidung hinausgeschoben werden, bis man über die angestrebten, zukünftigen Anwendungen mehr Klarheit besitzt. Übliche Überbrückungslösungen sind zum Beispiel die Beibehaltung von VSAM-Dateien (eventuell mit zusätzlichem Secondary Indexing), der Einsatz von CICS oder eines ähnlichen Produktes, die Entscheidung für ein Data Dictionary oder ähnliches.

- Für DB-Aufsteiger und -Wechsler gilt ebenfalls die Aussage, daß das gegenwärtige und das geplante Anwendungsspektrum genau bekannt sein muß. Viele DBOMP-Anwender stehen der "DL/1-Schwelle" kritisch gegenüber und vergleichen DL/1 (=IMS) intensiv mit anderen DBS-Produkten. Diese Anwender haben auf DBOMP-Basis (meist mit beträchtlichen Investitionen von Mannjahren) eine beachtliche DB-Anwendung auf die Beine gestellt und wollen diese sinnvoll weitergeführt sehen. In dieser Klemme gilt es, sich auf einfache, aber sichere Lebensweisheiten zurückzuziehen:

Man sollte lieber mit dem alten DB-Produkt noch eine Weile weiterleben, als überschnell (und gutgläubig) eine Entscheidung für ein Folge-DBS treffen.

Wenn starke Konkurrenz zu DL/1 existiert, wird dies sicher seinen Grund haben. Diesem auf die Spur zu kommen ist nicht schwielig. Es ist sehr sinnvoll, Überlegungen zur Auswahl anzustellen.

In der Endphase einer Auswahl stehen meist am Markt bewährte DBS, das mehr als 200mal instalTAL und andere contra DL/1. Ein DBS, das mehr als 200 mal installiert ist, gilt als bewährt und zukunftssicher. DBSe mit geringer Installationszahl (kleiner 20) trifft man meist nur bei besonders triftiger Begründung (sehr preisgünstig, besonderes Entgegenkommen des Herstellers, extrem schnell oder dergleichen) noch in der Endphase an.

Ein DBS, das erst kurze Zeit am Markt ist, läßt man lieber durch andere Anwender austesten. Systeme, die etwa 8 bis 10 Jahre am Markt sind, werden ihre Version 8 bis 10 erreicht haben (nach der Richtlinie: etwa eine größere Versionsfortschreibung pro Jahr). Diese Systeme können als ausgereift gelten; sie stehen auf der Höhe ihres Produktlebenszyklus.

DB-Benchmarkttests sind sehr sinnvoll, aber teuer. Kleine Anwender werden sich diesen Aufwand nicht leisten können. Die DB-Testerfahrung des Autors besagt, daß Testergebnisse oft nur den Eindruck, den man von dem System vor dem Test hatte, bestätigen. Testergebnisse können sehr schnell veralten, im Prinzip mit jeder kleinen Versionsänderung, mit jedem ZAP.

Eine einfache, aber je nach Einstellung sehr wichtige Frage ist die, ob bei der DBS-Generierung Änderungen am Betriebssystem notwendig sind (Einspielen eines SVCs, Ändern einiger Tabellen oder dergleichen). Falls man dies grundsätzlich ablehnt, fallen einige DBSe gleich aus der Auswahl heraus.

DBS-Hersteller, die während einer Auswahl zu aufdringlich drängeln, haben dies nötig. Entsprechende Vorsicht ist ratsam.

DBS-Hersteller, die den Vertrieb durch ein Einmannbüro bestreiten lassen, sollte man erst mal Zeit für den Aufbau geben.

- Die Zeit der marktmäßig vertriebenen relationalen DBSe scheint zu kommen (S/38). Viele Anwender fragen sich, ob sie bei Auswahl- und Umstellungsentscheidungen diese Systeme abwarten sollen.

Hier hilft eine einfache Weisheit: "Der Spatz in der Hand ist mehr Wert als die Taube auf dem Dach." Relationale DBSe wollen ein Höchstmaß an Benutzerkomfort bieten, bloß scheint noch nicht so recht festzustehen, wie dieser implementiert werden soll. Sie werden in der Form effizienter, ausgetesteter DBSe (zum Beispiel mit Konvertierungsroutinen IMS > System R) noch etwas auf sich warten lassen. S/38 ist ein Vorbote.

Die Beschäftigung mit relationalen Modellierungsgedanken ist sehr anzuraten. Sie schult den Sinn für einen guten DB-Strukturentwurf - auch bei existierenden, konventionellen DBSen. Zudem können einige DBSe (etwa adabas, NIMS, UDS) auch nach relationalen Prinzipien eingesetzt werden.

Relationale DB-Systeme werden verstärkten Auftrieb erhalten, wenn hardwaremäßig realisierte DE-Prozessoren (auf der Basis von Assoziativprozessoren) angeboten werden. Technologisch gesehen ist die Zeit hierfür reif. Technologische und marktstrategische Gründe stimmen jedoch meist zeitlich nicht überein.