Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

03.10.1980

"Wir haben uns die Datenbank Auswahl etwas kosten lassen"

Mit Klaus Möllgaard, Leiter der Programmierung bei der Rütgerswerke AG,

Frankfurt, sprach CW-Mitarbeiter Günter Schilling

Der Einsatz von Datenbanken steckt hierzulande noch in den Anfängen. Dies mag nicht zuletzt daran liegen, daß viele Anwender glauben, der mit der Einführung einer Datenbank verbundene Aufwand würde sich nicht so bald - oder sogar nie - in einem zusätzlichen Nutzen für die Endbenutzer auswirken. Würden Sie diese Meinung aufgrund der bei Ihnen gemachten Erfahrungen grundsätzlich teilen?

Der Aufwand, der im Zusammenhang mit der Einführung einer datenbankorientierten EDV entsteht, ist. in der Tat beträchtlich. Daher ist zu verstehen, daß viele Unternehmen diesen Schritt bisher gescheut haben. Man muß, damit die von Ihnen erwähnten Risiken nicht eintreten, genau wissen, warum man ein Datenbanksystem einsetzen will. Von dieser Anforderungssituation ausgehend sollte man die am Markt angebotenen Systeme genau untersuchen, darauf das ausgewählte System installieren und nach dessen Kriterien seinen DB-Betrieb aufbauen.

Aus welchem Grund wollten Sie ein Datenbanksystem einsetzen?

In unserem Falle bestand die Zielsetzung darin, künftig Dialoganwendungen zu entwickeln. Der bis dahin ausnahmslos praktizierte Batch-Betrieb konnte nicht das sein, was wir unseren Benutzern weiterhin für Jahre ausschließlich anbieten wollten. Das Betreiben von anspruchsvollen Dialoganwendungen bedeutet aber, daß während des Tages auf bestimmte Dateien sowohl von Batch- als auch von Dialoganwendungen zugegriffen wird. Verlangt man nun, daß solche Dateien tagsüber auch fortgeschrieben werden sollen, entstehen schnell große Probleme. Durch diese und eine Reihe anderer Gründe kamen wir sehr bald zu der Erkenntnis, daß die Einführung eines TP-Monitors für uns nur in Verbindung mit einem Datenbanksystem praktikabel sein konnte.

Sollte Ihrer Meinung nach die Einführung eines Datenbanksystems schrittweise erfolgen?

Die Einführung eines DB-Systems kann nicht darin bestehen, daß die gesamte Menge der bestehenden Anwendungssysteme von den herkömmlichen Zugriffsformen auf Datenbankzugriff umgestellt wird. Das wäre nicht zu schaffen, und hierin liegt auch kein Nutzen. Wir können uns nur vorstellen daß der Weg zum integrierten DB/DC-System allmählich vollzogen wird: Zunächst nur ein Projekt, parallel dazu die Schulung weiterer Mitarbeiter dann ein weiteres Projekt, wobei Zug um Zug die für neue Anwendungen benötigten Dateien auf DB-Files umgestellt werden. Dies wiederum bedingt eine Umstellung der auf diese Dateien zugreifenden alten Batch-Programme auf Datenbank-Zugriff. So sieht unserer Meinung nach der geordnete Übergang auf ein DB-System aus.

Sind dann auch die Benutzer rundum zufrieden?

Was den Nutzen für den Endbenutzer angeht, so ist in unserem Fall festzustellen, daß die Datenbank nicht in das Bewußtsein des Endbenutzers gedrungen ist. Der sieht nach wie vor nur seine Anwendungen. Sein Nutzen liegt darin, daß die Anwender künftig über eine neue Qualität verfügen, da es sich um Anwendungen mit Dialogfunktionen handeln wird.

Herr Möllgaard, vor dem Einsatz der DB/DC-Software haben Sie eine Wirtschaftlichkeitsberechnung durchgeführt. Mußten Sie bereits Abstriche machen?

Unsere Erwartungen wurden bis jetzt voll bestätigt. Ich sage dies, obwohl bis heute erst ein Anwendungsgebiet, nämlich das zentrale Kontokorrent, über die Datacom-Software abgewickelt wird. Weitere Anwendungen sind in der Entwicklung.

Läßt sich der Datenbank-Nutzer überhaupt messen?

Ein Wirtschaftlichkeitsnachweis kann unseres Erachtens nur über die jeweilige Anwendungssoftware, welche sich der DB/DC-Software als Hilfsmittel bedient, erbracht werden. In unserem Falle waren dies geplante Dialoganwendungen, für die eine Wirtschaftlichkeit vorgerechnet wurde. Für die bereits im Einsatz befindliche Anwendung, das zentrale Kontokorrent, wurde diese Wirtschaftlichkeitsforderung erfüllt.

Können Sie noch andere Vorteile des Datenbank-Einsatzes nennen?

Wir hatten in unserem RZ-Betrieb darunter zu leiden, daß der gleichzeitige Zugriff auf Dateien von unterschiedlichen Anwendungen aus behindert wird, wenn Datensätze verändert werden. Das führte besonders während der Spitzenbelastungszeiten zu Engpässen. Das Datenbanksystem beseitigt diesen Engpaß und erhöht somit die Rechnerleistung. Des weiteren führt das Datenbanksystem langfristig zu einer besseren Ausnutzung der Plattenspeicherkapazität durch weniger Datenredundanz. Die Existenz eines Datenbanksystems wirkt sich schließlich günstig auf die Neukonzeption von Anwendungssystemen aus und hier insbesondere auf die Datenorganisation, den System-Entwurf und die System-Implementierung. Dabei sind die Hilfen, die aus der Verwendung der Datenbank-Software resultieren, um so größer, je komplexer die Anwendungen und damit deren Datenorganisation ist.

Wie sind Sie bei der Auswahl der Datenbank-Software vorgegangen?

Wir haben uns die Auswahl des DB/DC-Systems, die mit dem praktischen Test einer nicht kleinen Pilotanwendung endete, etwas kosten lassen. An diesem Entscheidungsprozeß waren in einem Zeitraum von drei Monaten immerhin sieben Mitarbeiter der RDO beteiligt, die einschließlich Schulung rund 1500 Arbeitsstunden auf dieses Projekt verwendet haben. Wir orientierten uns dabei an einem umfangreichen Kriterienkatalog, den wir vorher aufgestellt hatten. Wir halten diese Vorgehensweise auch im nachhinein für richtig.

Was stand denn in diesem Katalog?

Unser Kriterienkatalog enthielt unter anderem Fragen nach der Systemarchitektur der Datenbank-Software den Systemfunktionen, den unterstützten Programmiersprachen und -techniken, den Schutz-, Sicherungs- und Service-Funktionen sowie nach dem Hardware-Bedarf. Diese vorwiegend systembezogenen Kriterien wurden dann noch um einige allgemeine Anforderungen, wie Benutzerfreundlichkeit, Installationsaufwand, Schulungsaufwand und Dokumentation ergänzt.

Warum haben Sie sich für die Datenbank-Software der Datacom-Produkt-Familie entschieden?

Neben der Auseinandersetzung mit Datacom und der Realisierung unserer Pilotanwendung haben wir beträchtliche Zeit darauf verwendet, spezielle Lösungsansätze, die im Datacom enthalten sind, mit den Systemberatern des Anbieters zu diskutieren. Am Ende haben sich einige Punkte als für uns besonders bedeutsam herausgestellt. Als relationales Datenbank-Verwaltungs-System verfügt Datacom/DB über ein großes Funktionenspektrum. Es besteht eine strikte Trennung zwischen den Benutzer- und Steuerdaten. Daraus ergaben sich eine Reihe von Vorteilen, wie größerer Datendurchsatz bei Abfrage- und Verwaltungsvorgängen und einfache Umorganisation der Datenbank. Dadurch ist sichergestellt, daß DB-Erweiterungen sowie Hard- und Software-Umstellungen mit verhältnismäßig geringem Aufwand durchgeführt werden können.

Auf einfaches Arbeiten legen sie offenbar großen Wert?

Mit dem Einsatz der Datenbank-Softwere mußte das bis dahin bei uns praktizierte Dateienkonzept nicht verlassen werden. Es existieren nach wie vor einfache sequentielle Dateien - in relationaler Sprache "Flat Files" genannt. Dies erleichterte den RDO-Mitarbeitern in Organisation und Programmierung das Arbeiten mit Datenbanken.

Welche Argumente sprechen für den DC-Teil der Datacom-Software?

Bei Einsatz von Datacom/DC werden Dialoganwendungen in unterschiedlichen Tasks einer einzigen OS-Partition unter Steuerung des Monitors abgearbeitet. Die Zuteilung verfügbarer CPU-Zeit zu den einzelnen Tasks ist somit Sache des Monitors und nicht des OS-Betriebssystems. Das hat sehr schnelle Tasks-Wechsel mit positiver Auswirkung auf das Antwortzeit-Verhalten zur Folge. Da Datacom/DC ein DC-Monitor ist, in dem der Befehl "Lesen Benutzer-Eingabe von Terminal" nicht vom Dialog-Programm, sondern vom Monitor gegeben wird - unseres Wissens der einzige Monitor mit dieser Konzeption -, hängt die Lebensdauer einer Task nicht mehr von der langsamen oder schnellen Terminal-Eingabe des Benutzers ab. Sie beginnt erst mit der Übergabe der Eingabe-Transaktion durch den Monitor und ist dadurch kurz, was zu einer besseren Nutzung des Hauptspeichers und wiederum zu schnellen Antwortzeiten führt.

Das Datenbankproblem vieler Anwender sind die DB/DC-Schnittstellen. Waren bei Ihnen Anpassungen erforderlich?

Datenbank- und Datenkommunikationssystem liegt ein einheitliches Konzept zugrunde; man merkt, daß hier aus einem Guß entwickelt wurde. Für den Anwender bedeutet dies Vorteile beim Erstellen von Anwendungsprogrammen, denn der Programmierer hat es bei seiner Arbeit immer mit einer einheitlichen Syntax für DB- und DC-Zugriffe zu tun. Zudem müssen keine Schnittstellen-Anpassungen durchgeführt werden.

Zu einer Kritik an Ihrer Datenbank-Software konnten wir Sie nicht provozieren. Worauf sind Sie am meisten stolz?

Wie der Verlauf des Pilotprojektes zeigt, ist die Realisierung einer ersten, echten DB/DC-Anwendung in relativ kurzer Zeit möglich gewesen. Uns blieb somit erspart, sichtbare Ergebnisse trotz großer Anstrengung erst nach Jahren aufweisen zu können wie man dies schon einige Male von anderen Unternehmen gehört hat.