Eine Lanze für Zugriffs- und Abfragesprachen brechen diejenigen Datenbankbenutzer, die bereits seit längerer Zeit mit einem System arbeiten. Treten auch hin und wieder beim praktischen Einsatz Probleme auf, so überwiegen insgesamt doch die positiven Erfahrungen. Eine Möglichkeit für den Endbenutzer, sich endlich vom Programmierer zu befreien, sieht Heinz Rau von der Nestlé Gruppe allerdings nicht: "Über Prozeduralsprachen sind wir noch nicht richtig hinaus, und die gehören in die Hand des Profiprogrammierers." Demgegenüber erscheint es Dr. Klaus Rumpf, Grünenthal GmbH, durchaus denkbar, mit Hilfe dieser Tools durch die Hintertür in der Fachabteilung DV-Spezialisten heranzuziehen. Resümiert Josef Kraus, Leiter Systemberatung, Applied Data Research: "ln die bestehende Datenorganisation und in die DV-Umgebung integrierte Abfragesprachen sind eine Hilfe für alle Arten von Endbenutzern.
Dr. Klaus Rumpf Datenbankadministrator, Grünenthal GmbH, Stolberg
Die Grünenthal GmbH ist ein Pharmaunternehmen mittlerer Größe. Als Vertriebs-Informations/Steuerungssystem wird seit etwa zehn Jahren das DBMS Sesam von Siemens eingesetzt.
Eine wesentliche Komponente des neuen Sesam ist die Abfragesprache Drive, die von sich behauptet, eine komfortable Benutzeroberfläche auch für die Fachabteilung zu bilden. Bereits die ersten Vorführungen dieser Sprache haben mich - als Fachmann - begeistert.
So gab es bisher beispielsweise eine Programmschnittstelle, über die Cobol-Programme mit der Datenbank kommunizieren konnten. Die dabei eingesetzte, total abstrakte Sprache war auch vom Eingeweihten nicht ohne Handbuch einsetzbar.
Über die Abfragesprache Sesam war es dem eingeweihten Anwender möglich, auch in der Fachabteilung im Dialog mit der Datenbank Abfragen zu stellen und Direktänderungen durchzuführen.
Drive enthält als wesentliche Elemente: logische Verzweigungen, Schleifenbildung, Rechenoperationen, Lesen von Dateien, Aufbereiten von Ausgaben. Man kann mit Drive im Dialog direkt (im Query-Modus) mit der Datenbank arbeiten, aber auch Programme, sogenannte Prozeduren, schreiben, abspeichern und zum Ablaufen wieder aufrufen.
Die Sprache ist nicht schwer zu lernen und, weil sie sich sehr nahe an umgangssprachliche Formulierungen anlehnt leicht zu behalten. Durch die Abkehr von einer abstrakten Syntax zur umgangssprachlichen Formulierung soll verstärkt der Anwender in der Fachabteilung angesprochen werden. Dieser ist nicht in der Lage, eine Prozedur zu schreiben, weil diese Tätigkeit immer noch mit dem Bereich "Programmieren" verbunden ist.
Dennoch ist eine solche Abfragesprache von großem Nutzen und kann, richtig eingesetzt, viel Zeit sparen:
In der DV-Abteilung werden kleinere Probleme, insbesondere Ad-hoc-Anforderungen, mit Drive gelöst. Der Programmierer, der die beiden Sprachmittel Cobol und Drive kennt, entscheidet fallweise, womit er schneller zurande kommt und spart somit Zeit.
Dann gibt es eine Menge Anwendungen, die mit kleinen Abwandlungen immer wieder eingesetzt werden können. Hier bietet sich Drive ganz besonders an: Der Programmierer erstellt eine Prozedur und übergibt sie dem Anwender in der Fachabteilung. Dieser bekommt eine kurze Schulung, wie er die Prozedur für die jeweilige Anforderung selbst abändern kann. Weil die Sprache ähnlich der Umgangssprache ist, kann auch der DV-unerfahrene Mitarbeiter leichter behalten, worauf es ankommt. Wenn er also nicht gerade DV-feindlich ist, sollte diese Art der Übergabe problemlos sein und die DV-Abteilung wird von manchem Kleinkram entlastet.
Wenn man Glück hat, läßt sich auf diesem Wege sogar durch die Hintertür ein Programmierer in der Fachabteilung heranziehen. Denn vom Begreifen einer Prozedur über das sinnvolle Abändern und Abkuppeln ist es nicht weit zum selbständigen Schreiben neuer Prozeduren. Man braucht dazu nur jemanden in der Fachabteilung, der etwas Logik, Gefühl für die Zusammenhänge in einem Programm und einen gesunden Spieltrieb mitbringt. Wir hatten dieses Glück, und nach einer praxisorientierten Schulung im Haus (keine teuren Programmierkurse) war nach vier Nachmittagen in der Fachabteilung ein Mann soweit, daß er sich traute, mit dem System zu spielen.
Die Folge: In kurzer Zeit hat dieser Mitarbeiter, der an der vordersten Front tätig ist und aus eigener Erfahrung weiß, wo es hapert, eine Reihe nützlicher Prozeduren geschrieben, die nach eiigenem Bekunden der Fachabteilung sehr viel Zeit sparen.
Josef Kraus Leiter Systemberatung, Applied Data Research, München
Die Ablauforganisation eines Unternehmens hat sich in den letzten Jahren durch den verstärkten DV-Einsatz erheblich verändert. Die hochqualifizierten Mitarbeiter in den Fachabteilungen stellen Forderungen nach Instrumenten, mit deren Hilfe verfügbare
Informationen ungeplant und "ad hoc" von der DV zur Verfügung gestellt werden können.
Legen wir ein DBMS als gemeinsamen Informationspool eines Unternehmens zugrunde, so geht es letztlich nur noch um die Frage der Informationsbereitstellung: "Zu welcher Zeit an wen, was"?
Daraus lassen sich grundlegende technische Forderungen an die Basis solcher Systeme ableiten:
-Die Datenadministration muß integrierter Bestandteil eines solchen Systems sein. Zentrale Zugriffskontrolle, fachabteilungsgerechte Feldterminologie und stabile, normalisierte Datenstrukturen sind unabdingbar, da DV-spezifisches Fachwissen und DV-Terminologien, sowie Kenntnis der Datenstrukturen für den Sachbearbeiter unzumutbar sind. Daß dies nur auf Grundlage relationaler Systeme möglich ist, wird heute weitgehend akzeptiert.
- Das Query-System muß ohne festgelegte Sprachformate, Sequenzen von Kommandos oder andere fixe Funktionsvorgänge in beliebigen selbst zu wählenden Sprachen, ja sogar selbst definierbaren Dialekten und ohne vorbereitende Arbeiten durch die DV (temporäre File-Kopplungen Definition von statischen "dataviews", Extrakte) benutzbar sein. Der Anwender weiß in den wenigsten Fällen von vornherein, was er exakt benötigt, und will an derartigen Systemen meist empirisch arbeiten.
- Eine Endbenutzerabfragesprache kann selbst entscheidende positive Voraussetzungen für ihre Akzeptanz beim Benutzer schaffen, wenn sie neben den genannten Kriterien auch von der Performance her "schnelle" Antworten zu liefern in der Lage ist, "tutorial features" für das Selbststudium und ausgefeilte "Help"-Funktionen besitzt.
Aber es ziehen ja nicht nur die Fachabteilungen aus dem Einsatz eines solchen Werkzeugs ihren Nutzen, sondern auch die DV benötigt geeignete Instrumente, um die geforderten Dienste für die Fachabteilung leisten zu können:
- Ein vollständiges, flexibles (durch "user entities" erweiterbares) Data Dictionary, das Informationen über die gespeicherten Daten enthält, gibt die Möglichkeit, diese administrativ sinnvoll und authorisiert zuzuteilen.
- Ist es außerdem im eingesetzten DBMS-System möglich die Daten über getrenntes Datenmanagement (auf beispielsweise verschiedenen Datenbanken - Multi-DBMS) dezidiert aufgabengebietsweise zuzuordnen, so erleichtert dies weitergehende Überlegungen zur Problematik:
"Trennung Test/Produktionsdaten "," Mandantenfähigkeit des Datenbestandes" und, "Erhöhen der Datensicherheits-/ -schutzfähigkeit".
- Sollte dabei auch die DV selbst als Endbenutzer in das Gesamtsystem miteinbezogen werden können, so sei für diesen Einsatzzweck beispielsweise die Notwendigkeit erwähnt, gerade in der Datenadministration ungeplante Anfragen über das Datengerüst und, "Ad hoc" -informationen über das gesamte im DD beschriebene DV-Environment erhalten zu können. Dies bedingt "wahlfreien" Zugriff auch auf die Dateien des Data Dictionary und eine gemeinsame Datenorganisationsform für Benutzerdaten und DD.
Unter diesen wesentlichen Voraussetzungen sind Abfragesprachen, in die bestehende Datenorganisation und in die DV-Umgebung integriert, eine Hilfe für alle Arten von Endbenutzern.
Bei dieser gesamten Thematik muß beachtet werden, daß gerade bei spontanen, ungeplanten und, "ad hoc" nötigen Informationsanforderungen der Endbenutzer in seiner Arbeit unterstützt wird und sich so Akzeptanzprobleme gegen Softwaresysteme grundsätzlich abbauen lassen.
Heinz Rau Ressortleiter DV, Nestlé Gruppe, Frankfurt
Abfragesprachen in der Nähe von Datenbanksystemen haben zwei Eigenschaften, die sie von Cobol unterscheiden: Sie sind feld-, nicht satzorientiert und sie haben einen Instant-Compiler, das heißt, sie sind interaktiv. Ersteres bedeutet, daß bestehende Programme unverändert bleiben können, wenn neue Programme zusätzliche Datenfelder benötigen, letzteres, daß man den gesamten Sprachumfang von Cobol mit der Leichtigkeit und Schnelligkeit des Hobby-Programmierers am Homecomputer einsetzen kann. Wer das nicht glaubt, dem sei der Umgang mit Natural, gestützt auf das Datenbanksystem Adabas, empfohlen.
Insbesondere wer Dialogprogrammierung mit Cobol und Cics im Makrolevel betreibt oder betrieben hat, ist zunächst begeistert von den neuen Möglichkeiten. Produktivitätssteigerungen um den Faktor zehn sind hier wohl wirklich nicht übertrieben, nicht weil die neuen Sprachen so fortschrittlich sind, sondern weil die früheren als Monstrosität bezeichnet werden müssen.
Was stellt sich nun bei näherem Hinsehen heraus? Zunächst unbestreitbar ein Vorteil in der Programmierung von Dialoganwendungen, gleichgültig welche Technik bisher eingesetzt wurde. Die erforderlichen Kenntnisse der DB-Technik werden auf ein Minimum reduziert, die gesamte Zugriffsmechanik für den Programmierer erscheint transparent. Nur der DB-Manager braucht noch die vollen technischen Kenntnisse für Störungsanalyse und -behebung sowie Tuning-Empfehlungen.
Im Batcheinsatz sieht s etwas heikler aus. Nicht alle DB-Abfragesprachen sind uneingeschränkt batchfähig. Natural ist es, wenn auch mit Schönheitsfehlern (zulässige Programmgröße, Kontakte zum Betriebssystem). Trotzdem werden bei uns alle neuen Batchprogramme in Natural geschrieben, es sei denn, es gelingt dem Programmierer, spezielle technische Gründe für Cobol anzuführen.
Und damit ist das Akzeptanzproblem angesprochen. Es gibt ein solches, exakt das gleiche wie damals beim Übergang von. Assembler auf Cobol. Je mehr Cobol-Erfahrung, desto schmerzlicher wird das Fehlen des guten alten "GOTO" empfunden, das glücklicherweise in keiner neuen DB-orientierten Sprache mehr enthalten ist. Es gibt aber auch bessere Gründe, Cobol nachzutrauern: Es ist heute eine bemerkenswert stabile Sprache, Precompiler übernehmen die Gruppenverarbeitung, Tuningprogramme ermöglichen Ablaufanalysen. Die neuen Sprachen haben natürlich noch nicht diesen Entwicklungsstand, holen aber rasch auf.
Noch ein Wort zum Endbenutzer, der sich endlich vom Programmierer befreien will. Er wird weiterhin enttäuscht. Über Prozeduralsprachen sind wir noch nicht richtig heraus, und die gehören in die Hand des Profiprogrammierers. Die jetzt erkennbaren, nichtprozeduralen Sprachen (Fill-inthe-blanks-Methode wie Supernatural) werden zwar Abhilfe schaffen, bei komplexen Anwendungen jedoch sehr schnell am Ende sein.
Ein beliebter, technisch stichhaltiger Einwand gegen Hochsprachen ist schließlich die Maschineninanspruchnahme. Wer ihn ernst nimmt, muß sofort zurück zu Assembler Wer rechnet, merkt, daß die größere Maschine die preiswertere Lösung ist. Assembler-Unterprogramme für besonders heiße Daten beeinträchtigen die Berechtigung der Hochsprachen in keiner Weise. Sie sollten jedoch erst erlaubt werden, wenn Meßergebnisse ein echtes Laufzeitproblem aufzeigen.