Von bestehenden Datenbanksystemen, selbst wenn sie nicht mehr alle Anforderungen der Anwender abdecken, trennen sich die Benutzer nur sehr ungern. Zu diesem Ergebnis kommt Günther Flaig, Leiter der Systemprogrammierung bei Brunata Wärmemesser. Für Kurt Blank von der INC Aktiengesellschaft ist der reale Vorteil einer Umstellung auf ein adäquateres DB-System im allgemeinen nicht zu messen: Finanzielle Belastung und Manpower-Aufwand sind seiner Meinung nach normalerweise höher zu veranschlagen. Die allgemeine Kritik an den verfügbaren Datenbankprodukten führt Blank auf ihre falsche Plazierung, nämlich außerhalb des Betriebssystems, zurück. Der Münchener DV-Berater Claus Weichselbaumer bringt gar einen "Softwarebrief" ähnlich dem Kfz-Brief in die Diskussion. kul

Kurt Blank, INC Aktiengesellschaft für Betriebswirtschaft und Datenverarbeitung, Köln

Der Sturm der Datenbanksoftware auf den Markt S ist mehr oder weniger vorüber. Der Streit der Theorien und Technologien ist abgeschlossen. Der Markt hat seine eigenen Gesetze.

Eine echte Alternative im Sinne eines Fortschritts wäre die Auslagerung des Datenbanksystems ins Data-Management, weil die Datenbanksystemspezifischen Definitionen, DB-Design und Aufrufe die Anwendungsprogramme im Aufbau und Ablauf stark beeinflussen. Die Neutralität der Anwendungssoftware gegenüber Systemspezifikas aller Art sollte verteidigt werden.

Die Datenbanksoftware gehört genauso wie die CCW-Ketten in das Data-Management, wobei hier letzteres umfassender verstanden werden muß. Dieses könnte, bezogen auf die Datenbanksoftware, folgende Struktur haben:

Programmschnittstelle:

- Definition der Informationsdatenfelder als Satzbeschreibung mit Funktions-, Schlüssel- und Return-code-Feldern

- Aufrufe der Datenbankdienste über die üblichen Data-Management-Makros

Logisches Data-Management:

- Datenbankbezogen: externe Beschreibung der Datenfelder der Datenbank, Zugriffspfade und Organisation

- Programmbezogen: externe Beschreibung der Datenfelder und Zugriffsberechtigung

Physisches Data-Management:

- physischer Zugriff, Data-Sharing und Logging als Time-sharing oder Interruptsystem

Datenbanksystem, Datenbankstrukturen und Datenbankaufrufe sind in jeder Hinsicht eine Zwangsjacke für den Anwender und die Anwendungen.

Es gibt auf dem Markt Alternativen von Datenbanksystemen nach Aufwand und unterschiedlichen Technologien. Für die speziellen Anforderungen der Datenhaltung eines Unternehmens ist das eine mehr oder weniger geeignet , als das andere.

So hat beispielsweise ein Fertigungsbetrieb andere Anforderungen an die Datenhaltung als eine Bibliothek. Doch keiner wird es sich leisten können, wenn er sich für ein Datenbanksystem entschieden hat, seine Anwendungen auf ein anderes Datenbanksystem umzustellen.

Der reale Vorteil einer Umstellung auf ein adäquateres DB-System ist im allgemeine nicht zu messen und liegt meines Erachtens unter dem finanziellen und Manpower-Aufwand, den man dabei betreiben müßte. Das Sicherheitsrisiko und den reibungslosen Ablauf für den Produktionsbetrieb möchte ich nur nebenbei erwähnen. Deshalb sind die alternativen Datenbanksysteme keine Lösung.

Mit allen auf dem Markt befindlichen Systemen können die Anforderungen an die Datenhaltung mehr oder weniger gut gelöst werden. Größtenteils hängt dies von der Analyse der Probleme und der Beherrschung des Datenbanksystems ab.

Meine Erfahrung aber ist, daß dem User nicht alle verfügbaren Techniken des jeweiligen Datenbanksystems bekannt sind. Die anstehenden datentechnischen Probleme werden zu sehr unter den sachlogischen Zusammenhängen gesehen und realisiert, die Alternativen von unkonventionellem Design, die die verarbeitungslogischen und physischen Zugriffe besser berücksichtigen, nicht erkannt. Ein Datenbankdesign muß die Daten eines Informationsbestandes nur einmal enthalten und zugleich alle Zugriffspfade der Informationsgewinnung berücksichtigen. Gegen diese Anforderungen wird oft verstoßen.

Die Auslagerung der Datenbankzugriffe und des Designs aus den Programmen sollte von dem verantwortlichen Management konsequent betrieben werden, weil damit die Programme wieder nur anwendungsbezogen erstellt werden, die DB-Designer eine echte Chance für ein Redesign haben und Einsparungen bei der Programmierung gewonnen werden. Wir sind mit den Dienstleistungen unseres Datenbanksystems zufrieden, der Aufwand ist jedoch zu hoch. Die allgemeine Kritik an den Datenbanksystemen liegt nur an der falschen Plazierung der Systeme, nämlich außerhalb des Betriebssystems.

Claus Weichselbaumer, Geschäftsführer der PAMCP-Systems Unternehmens- und EDV-Beratungs-GmbH, München

Bei den Ersten dabei zu sein, die ein neues Datenbanksystem einsetzen, hat für manche DV-Manager und Softwareentwickler sicherlich seinen Reiz.

Zu dem unbestrittenen Vorteil, vom Hersteller als Pilotkunde privilegiert behandelt und besonders unterstützt zu werden, kommt noch der Prestigegewinn und der Knowhow-Vorsprung, den man sich im Vergleich zu anderen aufbaut.

Mit dieser teilweise kritischen Anmerkung soll ausgedrückt werden, daß es nicht immer objektiv begründbare Entscheidungen sind, die dazu führen, Erstanwender zu werden.

Die Entscheidung für ein neuentwickeltes Datenbanksystem muß die Aspekte Personal, Ausbildung und. Erfahrung, funktionale Vollständigkeit des DB-Systems, der DB-Dienstprogramme, der Dialog-Abfrage-Software (Online-Query-Language} und des Listenprogrammgenerators, Sicherheit und Verfügbarkeit sowie Leistungsfähigkeit und Leistungsbedarf berücksichtigen.

Zum Einsatz etablierter Datenbanksysteme läßt sich qualifiziertes Personal am Arbeitsmarkt finden. Dadurch wird der mühsame Weg von der Ausbildung bis zum erfahrenen Umgang mit dem Datenbanksystem oft billiger. Die ersten Trainingskurse für ein neues System bieten meist keine oder nur wenig Erfahrungen im Umgang mit dem System. Weder der Aufwand, den einzelne Funktionen verursachen, noch die Auswirkungen spezieller Anwendungsformen auf Lauf- und Antwortzeiten können gelehrt werden. So kommt es, daß erste Anwendungen meist mit Schwierigkeiten zu kämpfen haben, die spätere Benutzer nicht mehr zu erwarten haben. Auch der Hersteller lernt das von ihm vertriebene System erst durch Einsatzfälle kennen.

Der Funktionsvorrat erster Versionen von Softwareprodukten ist meist ein Kompromiß zwischen Freigabetermin und Vollständigkeit. Für Erstanwender ist deshalb eine frühzeitige Überprüfung, ob der Funktionsvorrat der ersten Version und die Ausprägung einzelner Funktionen seinen Ansprüchen genügen, notwendig. Eine funktionale Ergänzung eines Datenbanksystems auf Benutzerprogrammebene kann teuer zu stehen kommen. Fehlende oder nur ansatzweise realisierte Funktionen lassen sich meist aus der Versionsplanung des Herstellers ableiten. Zusätzlich muß berücksichtigt werden, daß sich das Softwareumfeld eines neue Datenbanksystems ebenfalls über Versionen entwickelt und auch hier zu Beginn der Markteinführung mit Schwächen und funktionaler Unvollständigkeit zu rechnen ist.

Trotz aller Maßnahmen der Qualitätssicherung, die heute herstellerseitig zum Standard gehören, kann man bei neuen Systemen nicht davon ausgehen, daß sie von Anfang an fehlerfrei arbeiten. Mit der Freigabe der ersten Version beginnt die Fortsetzung der Tests beim Kunden. Insbesondere bei Datenbanksystemen, bei denen ein Datenverlust oder die Inkonsistenz des Datenbestandes gravierende Folgen für eine Vielzahl von Anwendungen nach sich ziehen können, sind bei der Beurteilung der Backup- und Recovery-Funktionen besonders hohe Maßstäbe anzusetzen.

Fehler im Datenbanksystem reduzieren naturgemäß dessen Verfügbarkeit. Erstanwender müssen einfach damit rechnen, daß sie in der Anfangszeit mit Verfügbarkeitsproblemen konfrontiert werden. Aus diesem Grund empfiehlt es sich auch nicht, komplexe Anwendungen mit hohen Verfügbarkeitsanforderungen auf der Basis der ersten Version eines Datenbanksystems einzusetzen.

Neue Softwareprodukte zeichnen sich meist dadurch aus, daß sie für vergleichbare Funktionen des Vorgängersystems mehr Aufwand an CPU-Zeit und Ein-/Ausgaben verursachen. Dies wird meist damit begründet, daß die Funktionen des neuen Produkts ja viel leistungsfähiger sind, als die des alten Systems. Daß mehr Sicherheit und Komfort geboten werden. Unter Leistungsfähigkeit darf aber nicht nur die Leistungsfähigkeit der Funktionen verstanden werden, vielmehr muß berücksichtigt werden, wie sparsam das Datenbanksystem mit den Betriebsmitteln umgeht und wie wirksam die realisierten Algorithmen hinsichtlich der Erzielung hoher Transaktionsraten sind.

In diesem Zusammenhang muß gefragt werden, ob die Entscheidung für den Einsatz des neuen Datenbanksystems nicht gleichzeitig die Zwangsentscheidung für eine leistungsfähigere CPU und eine umfangreichere Plattenperipherie beinhaltet. Da sich Hersteller derzeit aber wohl außerstande sehen, zu Softwareprodukten anzugeben, welchen Leistungsbedarf einzelne Funktionen/Teilfunktionen bei unterschiedlichen Randbedingungen haben (wie wäre es denn mit einem Softwarebrief, ähnlich dem Kfz-Brief?), erleben Anwender immer wieder böse Überraschungen, weil sie die Konsequenzen einer Softwareentscheidung hinsichtlich der erforderlichen Leistungskapazität der Hardware meist nicht abschätzen können.

Günther Flaig, Leiter Systemprogrammierung, Brunata Wärmemesser, Stuttgart

Datenbanken - ja, so hieß bei uns die Entscheidung vor ungefähr acht Jahren. Damals gab es für einen IBM-360-Anwender mit DOS als Betriebssystem keine ernstzunehmende Alternative zu DL/ 1. Seit dieser Zeit sind alle Anwendungssysteme, die bei uns entwickelt wurden, darauf ausgelegt, daß sich der gesamte Datenpool in DL/ 1-Datenbanken befindet.

Wir sind uns durchaus im Klaren darüber, daß DL/ 1 nicht mehr das Nonplusultra ist, was Datenbanken angeht. Dies gilt gegenüber hierarchischen Systemen von anderen Herstellern und erst recht bei "neuen" relationalen Modellen.

Aber selbst wenn wir zu der Ansicht gelangen, daß die technischen Möglichkeiten, die unser System bietet, nicht mehr ausreichend sind - es werden uns sehr schnell Grenzen gesetzt, was die Realisierung einer Umstellung angeht. Bestehende Anwendungssysteme (Batch und Online) sind, selbst wenn sie seit Jahren laufen und nicht mehr alle Bedürfnisse der Anwender abdecken nur sehr schwer totzukriegen. Die Einführung eines neuen Datenbanksystems ist also nur für neue Anwendungssysteme möglich. Dies führt zu der Forderung, daß Know-how sowohl für das bestehende als auch für das neue System im Haus vorhanden sein muß. Um gleichzeitig die Pflege von bestehenden Programmen mit dem alten DB-System und für neue Systeme mit einem alternativen DB-System zu gewährleisten, ist fast eine Verdoppelung der Wartungskapazität erforderlich. Selbst wenn dies für ein Unternehmen unserer Größenordnung finanzierbar wäre, woher nimmt man das Know-how? Die Ergebnisse von Softwareentwicklungen, die neue Techniken nur aufgrund von Schulungsmaßnahmen einsetzen, sind zur Genüge bekannt aus den Anfangszeiten von DL/ 1 und CICS. Wer geht einem EDV-Organisator, der ein neues System plant, zur Hand und sagt ihm, welche Konsequenzen seine Planungen für das zukünftige Systemverhalten voraussichtlich haben werden? Wenn nirgends im Haus Erfahrungen vorhanden sind, wird sich dieser Organisator an bekannte Größen halten und weiterhin das alte DB-System verwenden.

Nicht zu vernachlässigen ist bei einem altbekannten System auch das Wissen, das sich beim Bedienungspersonal in den Fachabteilungen und beim Operating angesammelt hat (Entscheidung zwischen Restart- und Recoveryverfahren und deren richtige Anwendung).

Vergleichbare Forderungen wie an die Wartungskapazität werden auch an die Datenbestände selbst gestellt. Alle wichtigen Daten müssen online zur Verfügung stehen und zwar gleichzeitig in Form der alten Datenbank für bestehende Systeme und für neue Systeme in Form der neuen Datenbank. Dies führt zu einer Verdoppelung der vorhandenen Plattenkapazität noch ohne Berücksichtigung möglicher zusätzlicher Kapazitätsforderungen, die neue Systeme oft mit sich bringen.

Für unser Unternehmen als kleiner User eines "Großsystems" 4341-2 ist die Unterstützung, die der EDV-Hersteller den Anwendern seiner Software bietet - auch bei einer eventuell erforderlichen Betriebssystemumstellung - nicht zu verachten. So ist ein Wechsel von DOS-CICS-DL/1 nach MVS-CICS-IMS/DB durchaus überschaubar, weil! er bei höheren Programmiersprachen (PL/ 1 - Cobol durch Neuumwandlung der Programme ohne Datenbankkonversion durchführbar ist Sollte sich bei uns im Haus irgendwann der mündige Enduser zeigen, der seine Daten selber aufbereiten möchte, so glauben wir, daß wir mit DL/ 1 Datenbanken als Datenbasis für neue DB-Produkte des Herstellers immer noch richtig liegen.

Trotz der "Rückständigkeit" von DL/ 1 als Datenbanksystem werden wir noch einige, Jahre damit leben können beziehungsweise müssen.