Während die Software-Industrie in ihren selbstkreierten Schlagworten schwelgt, die allesamt den Begriff "Datenbank" umranken, plagt der Anwender sich mit den Problemen des DV-Alltags. Ein Fachvokabular allein genügt da nicht: Die Daten sollen anwendungsunabhängig gespeichert, gesichert und dennoch dem Enduser zugänglich sein; selbst bei großen Informationsmengen erwartet der Experte von "seinem" DB-System geringe Turn-around-Zeiten sowie hohe Restart/Restore-Leistungen - ohne die Benutzerfreundlichkeit dadurch allerdings zu schmälern. "Die Qualität steigt mit der Transparenz", resümiert Peter Brentle von Panavia Aircraft.

Zunächst einmal gilt es in dem "Gestrüpp der Fachbegriffe" Unterscheidungen zu treffen: sogenannte herkömmliche Daten-Management-Systeme, relationale DBM-Systeme, verteilte Datenbanken und Expertensysteme.

Als herkömmliches Datenbank-Management-System setzt die Colonia das IBM-Produkt IMS ein. Der ursprüngliche Anforderungskatalog, den wir für den Einsatz dieses Systems erstellten, umfaßt die folgenden Oberpunkte:

- zugriffsoptimierte Abspeicherung der Datenstrukturen

- einfaches und wirksames Interface zwischen Anwendung und Datenbank,

- Integritätssicherung (die allerdings von jedem DBMS gewährleistet sein sollte).

Was die Zugriffssicherheit anbelangt, so hat unser Unternehmen eine eigene personen- und funktionsbezogene Kontrolle, das "Colonia Security System", entwickelt.

Bei der Datensicherung ist der Punkt Restart-/Recovery-Fähigkeit zu betonen und damit die bereits erwähnte Integrität zum Trägersystem.

Bezüglich der Performance verlangen wir von unserem DBM-System die Fähigkeit, große Datenmassen in einer angemessenen Turn-around-Zeit bewältigen zu können. Der Benutzer muß auch im online-Zugriffsverfahren mit optimalen Verarbeitungszeiten rechnen können.

Karl-Heinz, Kronenberger Leiter Datenschutz und Datensicherheit, Colonia Versicherungsgruppe, Köln

Das hier erzielte Ergebnis bestimmt zu gleich die Verfügbarkeit des Systems. Für unser Haus gesprochen, läßt sich konstatieren: Auch bei vielen Benutzern erzielt das System hohe Durchsatzraten.

Generell hat IMS die Anforderungen erfüllt, die wir an das DBMS stellten. Darüber hinausgehende Verbesserungen haben wir durch hausintern entwickelte Modifikationen realisiert - beispielsweise durch unser "Split-Konzept":

Hierbei werden die Datenbestände gesplittet, als Teilbestände auf mehreren Platten gespeichert und der Zugriff dadurch optimiert.

Im Bereich der relationalen Datenbanken setzen wir in einer Testphase DB2 ein. Von diesem System erwarten wir unkomplizierte Auswertungsmöglichkeiten nach wechselnden Kriterien für Endbenutzer sowie Flexibilität bezüglich Änderungen und Erweiterungen von Datenbeständen. Was die weiteren Anforderungen an das relationale DBMS betrifft, so decken sie sich mit den bereits im Zusammenhang mit herkömmlichen DBM-Systemen genannten Punkten.

Verglichen mit IMS gestaltet sich der Einsatz von DB2 durch den gebotenen Servicegrad maschinenaufwendiger. Expertensysteme schließlich werden in unserem Unternehmen ebenso wenig eingesetzt wie verteilte Datenbanken; gegen letztere spricht hier die Organisationsstruktur der Colonia, die sich für verteilte DBs nicht eignet, wie eine Untersuchung von 1979 gezeigt hat.

Bei der Frage nach den Kriterien, die eine Datenbank in der Praxis bieten muß, um Nutzen zu bringen, gilt es zunächst zwischen den verschiedenen Anwenderinteressen zu unterscheiden. Während der Enduser, also der Mensch, der täglich an seinem Terminal arbeitet, dem detaillierten Aufbau des Systems kaum Aufmerksamkeit entgegenbringen wird, muß den Systementwickler als Anwender die Funktionsfähigkeit der Datenbank sehr wohl kümmern. Von ihm wird nämlich erwartet, daß das Informationssystem arbeitet - und zwar mit einem Optimum an Benutzerfreundlichkeit. Fällt die Datenbank einmal aus oder erbringt nicht die geforderte Leistung, so weiß der Enduser nicht, ob es sich hierbei um eine Schwäche der Systementwicklung oder des Informationssystems handelt.

Darüber hinaus macht natürlich eine Datenbank allein die Leistungsfähigkeit einer DV-Anlage noch nicht aus; ein Entwicklungstool muß auf dem System aufbauen, wie beispielsweise "Natural" auf "Adabas". Als besonders wichtig stellt sich außerdem dar, daß die Funktionen nicht hochkomplex sind, die der Endanwender dann möglicherweise gar per Parameter steuern muß. Anders gesagt: Die Qualität des Systems steigt mit dessen Transparenz; auf das oben bereits erwähnte "Natural" bezogen heißt das: Die Grundfunktionen müssen so angelegt sein, daß das System relativ wenig Steuerung erfordert.

Peter Brentle, Leiter DV/Org., Panavia Aircraft GmbH, München

Ein weiteres Kriterium bei der Beurteilung von Datenbanken richtet sich an deren Performance. Meiner Meinung nach weicht die Bedeutung der "internen" Performance langsam zurück - zugunsten der Anwenderfreundlichkeit, da die Hardware diesen Mangel immer mehr ausgleichen wird. Dabei darf allerdings der Gap zwischen Performance und Funktionalität nicht zu groß werden.

Technische Anforderungen an Datenbanken schließen weiter Standardfunktionen wie beispielsweise Recovery, Reorganisation oder verteilte Datenbanken selbstverständlich ein, um dem Datenbank-Administrator immensen Zeitaufwand für das Handling zu ersparen. Derartige Anforderungen sind im übrigen bereits hinlänglich katalogisiert. Aber ein anderer Punkt: Die Schnittstellen müssen "durchsichtig" sein, um Connectivity der Systeme zu ermöglichen. Dies wird insbesondere vor dem Hintergrund der Verknüpfung von PC- und Mainframe-Datenbanken insgesamt - auf welcher Ebene auch immer - bedeutsam.

Schließlich verdient das Zusammenspiel zwischen Fachabteilung und DV Beachtung. Wenn Datenverarbeitung nur eingesetzt wird, um Arbeitsabläufe in den Fachabteilungen zu automatisieren, dann werden die Anwendungen kaum Spitzenergebnisse zeitigen. Fachbereiche und DV müssen nicht nur aufeinander zugehen, in den Endusern muß vielmehr mit dem eingesetzten DB-System und Anwendungstool ein Verantwortungsgefühl für die eigenen Daten entwickelt werden. Denn die Qualität der operationalen Daten hängt in hohem Maße von der Motivation der Benutzer im Umgang mit seiner Anwendung ab.

Martin Blümel, DV-Leiter, Bayernwerk AG, München

Bei der Bayernwerk AG haben wir bislang keine Datenbank eingesetzt. Jetzt stehen wir am Anfang unserer Überlegungen zu Datenbanken als neuem Instrument der Informationsverarbeitung - primär für den Bereich Betriebsdatenerfassung und -verarbeitung.

Im Bereich Betriebsdatenerfassung verfügen wir über ein gewachsenes, altes Programmsystem, das in Assembler erstellt wurde und nach dem Prinzip der Stapelverarbeitung operiert. Zwar haben wir unsere Anlage auf den Dialogmodus des Siemens-Betriebssystems BS2000 umgestellt, doch im Bereich Betriebsdatenverarbeitung handelt es sich dabei nach wie vor um Stapelverarbeitung - jedes Programm ist für bestimmte Aufgaben konzipiert. Fest steht jedenfalls, daß wir mit dem System, wie es derzeit läuft, nicht zufrieden sind. Deshalb planen wir eine Neukonzeption und wollen mit dem Einsatz einer Datenbank einen sicheren Schritt in die Zukunft unternehmen.

Natürlich bedeutet ein derartiges System zunächst eine Menge Arbeit, denn der Datenbestand muß neu strukturiert werden. Unser DV-System wird mehr belastet werden - die Hardware-Kapazität wird folglich ausgebaut werden müssen. Das geht dann wohl zunächst zulasten der Performance.

Als Vorteil einer Datenbank stellen sich uns folgende Punkte dar:

- die Datenspeicherung ist anwendungsunabhängig,

- daraus ergibt sich eine höhere Flexibilität,

- Daten und Verfahren werden integriert,

- Mehrfachspeicherungen können wir reduzieren, bestenfalls sogar völlig vermeiden,

- die Datensicherheit wird optimiert. (Dies ist für uns besonders wichtig, da wir gegenwärtig mit Isam-Dateien arbeiten, bei denen unbemerkt Kettenbrüche auftreten können.)

Mit der Datenbank eng verknüpft sehen wir eine Abfragesprache der vierten Generation. Eine solche Abfragesprache ist meines Erachtens ein wirkungsvolles und auch notwendiges Instrument der DB-Nutzung. Der Informationsbestand ließe sich somit wirkungsvoller nutzen und die Programmierung könnte schneller erfolgen. Von einer Abfragesprache der vierten Generation verlangen wir darüber hinaus, daß sie übersichtlich strukturiert ist, mathematische Funktionen beinhaltet und einen hohen Grad an Benutzerfreundlichkeit aufweist.

Natürlich stellt sich dabei auch die Frage, ob man dieses DB-Tool dem Einsatz des Endbenutzers überlassen sollte? Die Tendenz zeichnet sich hier eher in Richtung "Nein" ab, denn könnte der User hier nach Gutdünken schalten und walten, so würde die Datenverarbeitung - insbesondere bei universeller Nutzung - schnell zum totalen Selbstbedienungsladen werden. Einzelanwender könnten das gesamte System blockieren. Das kann nicht in unserem Interesse liegen, zumal schon jetzt der freizügige Dialogbetrieb von BS2000 den Fachabteilungen einen hohen Freiheitsgrad einräumt. Die Ressourcenplanung ist hier weit schwieriger als in einem Stapelbetrieb. Sinnvoll eingesetzt ermöglicht eine Abfragesprache der vierten Generation meiner Meinung nach aber einen weiteren richtigen Schritt hin zur Erleichterung der Programmierung und damit auch zur schnelleren Dialogbedienung der Anwender.

Abschließend noch einige Bemerkungen zum Data Dictionary, einem der zahlreichen Schlagwörter, das in der DV-Welt umherschwirrt. Als effektiv kann sich wohl nur ein aktives Data Dictionary erweisen; auch könnte ein solches System Fortschritte in der Dokumentationsmisere bringen. Es besteht dabei allerdings die Gefahr, daß Eintragungen wegen des großen Arbeitsaufwandes nur unvollständig oder überhaupt nicht vorgenommen werden. Damit würde der Nutzen eines Data Dictionaries wohl sehr in Frage gestellt.