Seit 1981 haben wir mit dem von der Darmstädter Software AG gelieferten "Adabas" ein einwandfrei funktionierendes Datenbanksystem Installiert. Die Sache aber hat eine Vorgeschichte: Zunächst entschlossen wir uns im Herbst 1980 zum Einsatz einer Datenbank und installierten, nachdem wir uns intensiv informiert hatten, im Mal 1981 das von der ADR Deutschland GmbH, Stuttgart, vertriebene Datenbanksystem "Datacom" doch nur für einige Monate.

Nach dieser Zeit hatten wir keine Hemmungen mehr, auch eine Fehlentscheidung einzugestehen. Gegen starke Widerstände einiger eigener Mitarbeiter riskierten wir eine Testinstallation mit Adabas.

Heute müssen wir uns fragen: Wie konnte es geschehen, daß wir uns im ersten Anlauf trotz gründlicher Untersuchung mehr Probleme als Lösung einhandelten?

Dazu eine Kurzdarstellung unseres Unternehmens: Endress + Hauser arbeitet im Bereich der Meß- und Regeltechnik. Im Stammhaus in Maulburg erzielten wir 1981 mit 580 Mitarbeitern einen Umsatz von 86 Millionen Mark.

Über VSAM hinaus

Zur Firmengruppe zählen weitere 26 Unternehmen und Vertretungen in Europa und Übersee. Unsere vor vier Jahren aufgebaute Leiterplattenfirma erzielte 1978 rund zweieinhalb Millionen Mark Umsatz, 1981 schon 14 Millionen Mark, und 1984 werden es 45 Millionen Mark sein.

Für unsere EDV gelten folgende Ziele bis 1985:

- Integration aller DV-Anwendungen,

- Software-Engineering zur automatisierten Entwicklung und Pflege der Anwendungen,

- Realisierung des "Information Management", eines zentralen Kommunikations- und Informationssystems unter Einschluß aller Einzeltechnologien.

Auf der heute installierten IBM/370-148 mit DOS/VSE und CICS werden folgende Programme gefahren: Produktionsplan, Materialwirtschaft, Stücklisten, Arbeitspläne, Teile der Fertigungssteuerung, Auftragsabwicklung, Buchhaltung, Lohn- und Gehaltsabrechnung, Kostenrechnung, Provisionsabrechnung, monatliche Bilanz und technisch-wissenschaftliche Berechnungen, soweit sie nicht auf Personal Computern abgewickelt werden.

Tägliche Kontrollzahlen für die Geschäftsführung gestatten die permanente Überwachung des Auftragsbestandes, des Auftragseinganges oder der Unternehmensliquidität. Alle Fachabteilungen sind im Online-Betrieb angeschlossen.

Zusätzlich erbringen wir Dienstleistungen für 15 externe RZ-Kunden, die auch teilweise online arbeiten. Für den Entschluß zum Einsatz einer Datenbank waren folgende Überlegungen maßgebend:

1. Die geplante Integration aller Anwendungen erfordert die Integration der Datenbestände.

2. Die Utilities eines DB-Systems (Recovery, Autorestart, transaktionsorientiertes Logging etc.) schaffen einen Handling-Komfort für große Datenvolumina, wie er für VSAM-Dateien nicht gegeben ist.

3. Die Datenspeicherung muß einfach sein und unabhängig von der Frage, wie die Daten einmal verknüpft werden sollen.

Relational heißt noch nicht benutzerfreundlich

Der letzte Punkt stellte die Weichen für diejenigen DB-Systeme auf dem deutschen Markt, die in die engere Auswahl kamen: Adabas und Datacom. Denn nur am Relationenmodell orientierte Datenbanken gewährleisten die geforderte Datenunabhängigkeit. Die Frage des DB-Designs stellt sich eigentlich nicht mehr, auf keinen Fall in der zwingenden und behindernden Form wie bei hierarchischen DB-Systemen. Flexibilität und Benutzerfreundlichkeit sind entscheidende Kostenfaktoren - man kann auch sagen Eckpfeiler - eines reibungslosen DB-Betriebs.

Aber da gibt es offensichtlich Unterschiede in Konzept und Architektur der auf dem Markt befindlichen DB-Systeme. Wenn man an -zig Stellen und Schrauben (sprich Parametern) drehen muß, wenn man jedes File permanent überwachen muß, weil Überläufe zum Totalzusammenbruch führen - dann erfordert dies eine systemseitige Betreuung, die keinesfalls dem Kriterium der Benutzerfreundlichkeit genügt. Ein solches System entspricht nicht den Erwartungen der 80er Jahre.

Bei unseren Untersuchungen waren wir auch nicht davon ausgegangen, daß auf dem Markt befindliche Systeme in unvertretbarem Maße instabil sein könnten. Aus heutiger Sicht können wir nur empfehlen, die Stabilität eines DB-Systems und sein Verhalten bei Abbrüchen konsequent zu testen - besonders, wenn ein ganzer Betrieb online angeschlossen werden soll.

Wir standen etwa zweimal wöchentlich vor Rätseln, für deren Lösung oft ein Spezialist herbeigeholt werden mußte. Dabei hatten wir uns umfassend informiert:

þDatapro-Unterlagen studiert,

þdie DB-Anbieter zu uns ins Haus geholt,

þVergleichszahlen geprüft, die ein Großunternehmen für alle gängigen DB-Systeme ermittelt hatte,

þDB-Anwender telefonisch und eingehend persönlich befragt.

Man kommt dabei, wie sich im Rückblick zeigt, rasch und unbewußt zu einer vorgefaßten Meinung, zu Vor-Urteilen. Und dann übernehmen alle weiteren Informationen Alibifunktion. Das läßt sich nur über eine Testinstallation objektivieren. Oder auch durch gezieltes Nachhaken.

Beispiel 1: Die Aussagen von persönlich befragten Referenzkunden hatten uns entscheidend in unserer vorgefaßten Meinung bestärkt. In einem Fall jedoch, der uns besonders auf schlußreich erschienen war, mußten wir später feststellen, daß man sich von Dingen überzeugt gegeben hatte, die niemals durchgeführt und ausprobiert worden waren.

Das Wortgepränge der Anbieter

Beispiel 2: Wenn besonders klingende Fachtermini ohne weitere Erklärung präsentiert werden, ist man leicht beeindruckt. Offen gestanden, so recht verstanden haben wir die "höhere Automationsebene des relationalen Calculus" oder das "Prinzip des asynchronen Wurzelbaumes" nicht.

Wir können nur raten, solche Wortgebilde so lange zu hinterfragen, bis man sie verstanden hat - oder bis sie sich als pseudowissenschaftliche Fassade entpuppt haben. Schließlich müssen wir die konkreten Aufgaben eines Produktionsbetriebs in den Griff kriegen.

Das Hinterfragen und Testen emfiehlt sich ebenfalls für die Stärken und Schwächen, die von den Anbietern konkurrierender Produkte ins Feld geführt werden. Unsere Erfahrung lehrt uns, daß bei sachlicher Betrachtung manche solcher Behauptungen irrelevant werden oder so stark an Bedeutung verlieren, daß ihnen keine hohe Wertigkeit als Entscheidungskriterium zukommen darf. Auch dazu ein Beispiel. Es ist nicht so leicht, sich vom File-Konzept zu lösen. Aber erst dann kann man die Vorzüge einer relationalen Datenbank verstehen. Und erst dann ist man so weit, den Vorschlag, mehrere Datenbanken einzurichten, als keineswegs nützliche Ideen zu beurteilen.

Stabilität wichtiger als Performance

Mit anderen Worten: Vorschläge und Behauptungen der Anbieter können auch aus der Beschaffenheit ihres Produkts resultieren. Man sollte solche Aussagen prüfen und testen, um deren Wert für das eigene Anwendungssystem selber beurteilen zu können.

Überhaupt haben sich unsere früheren Entscheidungskriterien mittlerweile verschoben. Höchste Wertigkeit haben heute für uns: die relationale Struktur, die Stabilität, die Flexibilität und die Benutzerfreundlichkeit. Dagegen betrachten wir als weniger bedeutend oder auch irrelevant im Zusammenhang mit relationalen Datenbanken: Hauptspeicheraufwand, Performance, Umstellungsaufwand für Dateien, Reorganisationsaufwand.

Unser Fazit: Sammeln Sie so viele Informationen wie möglich - aber trauen Sie keiner. Hinterfragen Sie die Informationen, und testen Sie das System. Testen Sie aber auch, was an behaupteten Stärken und Schwächen wirklich dran ist. Wer 200 000 Mark und mehr investiert, sollte sich dieser Investition im voraus versichern. Fünf Tage Test mit Schulung kosten weniger als etliche Monate Betriebsstörungen.

*Karl-Heinz Ritter, 39, ist Leiter des Bereiches Management Services der Endress + Hauser GmbH & Co. im badischen Maulburg.