Sind Abfragesprachen für Datenbanken eine hübsche Spielerei, oder sind sie Werkzeuge von praktischem Nutzen? Sind Endbenutzer in der Lage, damit auch wirklich zu. arbeiten? Wie sieht der Entwicklungsstand angebotener Sprachen aus? Der folgende Beitrag soll Nutzen und Grenzen sowie Leistungsunterschiede von DB-Abfragesprachen erläutern.

Für fast jedes Datenbanksystem wird auch eine Abfragesprache angeboten - benutzt werden diese Sprachen jedoch selten, oft nur als Testhilfe. Warum eigentlich? Dabei gibt es doch zwei wesentliche Gründe, die nach dem verstärkten Einsatz solcher Werkzeuge verlangen:

Wachsender Informationsbedarf

Nachdem bisher weitgehend nur Verwaltungsaufgaben durch EDV-Verfahren abgedeckt wurden, steigt jetzt stetig der Bedarf an Informations- und Planungssystemen. Für Informationssysteme ist die Datenbasis meist aufgrund der bisherigen EDV-Verfahren vorhanden, nur es fehlt an den geeigneten Auswertungsmöglichkeiten.

Charakteristisch für solche Systeme aber ist, daß der Informationsbedarf vielfach nicht determinierbar ist, sondern sich aus der jeweiligen Geschäftssituation ergibt. Der Erfolg und der Nutzen eines Informationssystems ist also davon abhängig, wie schnell und wie flexibel Informationen bereitgestellt werden können. Wäre eine DB-Abfragesprache nicht geeignet, um Ad-hoc-lnformationen kurzfristig und mit wenig Aufwand zu liefern?

Mit steigender Leistungsfähigkeit und steigender Preiswürdigkeit der Hardware erwarten die Endbenutzer auch mehr und besseren Service durch die DV. Speziell der Einsatz von Online-Systemen erfordert, sich schneller an den Bedarf anpassen zu können als bisher, um das Terminal auch wirklich zum Arbeitsmittel des Benutzers werden zu lassen.

Doch die Software-Produktivität hält mit der Nachfrage nicht mit. Es geht nicht an, daß man - wie bereits in einigen Unternehmen - einen "Entwicklungsberg" von bis zu drei Jahren vor sich herschiebt. Ließen sich nicht mittels einer DB-Abfragesprache - oder besser noch mit einer echten Benutzersprache - viele Programmwünsche schneller und billiger realisieren?

Um aus diesem Problemkreis herauszukommen, ist es notwendig, Werkzeuge für eine schnellere Programmentwicklung zu erhalten. Noch günstiger wäre es, wenn die Benutzer ihren Informationsbedarf selbst befriedigen könnten. Dabei geht es nicht darum, die Benutzer zu Programmierern zu machen. Sie sollen vielmehr durch geeignete Werkzeuge in die Lage versetzt werden, den Computer so zu nutzen wie einen intelligenten

Taschenrechner, also ohne intensive Kenntnisse der Datenverarbeitung und ohne großen Programmieraufwand.

Wenn die Benutzer einen Teil ihrer Anforderungen ohne großen Aufwand selbst realisieren können, wird wieder Programmierkapazität für komplexere Anwendungen freigesetzt. Zudem wird die Unzufriedenheit über den Servicegrad der DV abgebaut. Welche Werkzeuge können den Benutzern zur "Selbstbedienung" -angeboten werden?

Reportgeneratoren bedingt nutzbar

Im Prinzip gibt es vier Möglichkeiten, Verarbeitungswünsche DV-gerecht zu formulieren:

- Programmiersprachen

- Reportgeneratoren

- DB-Abfragesprachen

- Benutzersprachen.

Während Programmierer mit allen vier Techniken arbeiten können, sind für Endbenutzer nur die zwei letztgenannten uneingeschränkt geeignet. Bild 1 stellt diese Zusammenhänge schematisch dar. Obwohl Reportgeneratoren weit verbreitet sind, zeigt doch die Erfahrung, daß sie als Werkzeuge nur begrenzt einsetzbar sind. Warum?

1. Viele Reportgeneratoren erfordern DV-technische Kenntnisse über Datenspeicherung und Programmierlogik, so daß sie der Endbenutzer nicht selbst anwenden kann. Ein Programmierer muß wieder einspringen. Häufig fehlt zudem eine interaktive Eingabemöglichkeit.

2. Reportgeneratoren bearbeiten die Datenbestände - auch Datenbanken sequentiell. Das kann zu mehrstündigen Laufzeiten für eine Auswertung führen. Für viele Aufgaben ist dies zu zeitaufwendig und zu teuer.

Speziell für Online-Anwendungen und Informationssysteme aber ist eine selektive Informationsgewinnung erforderlich. Deswegen ist sequentielles Durcharbeiten - und damit die konventionelle Dateiorganisation - nicht geeignet. Bleibt also nur eine Datenbank als geeignete Basis übrig.

Nicht jede Datenbank geeignet

Inzwischen ist die Erkenntnis weit verbreitet, daß Datenbank noch lange nicht gleich Datenbank ist.. Soll der Endbenutzer seine Informationen selbst aus einer Datenbank gewinnen können, so ist es erforderlich, daß

þer nicht die Struktur und die Zugriffspfade innerhalb einer Datenbank zu kennen braucht,

þvielfältige Zugriffskriterien ihm einen direkten Zugriff zu den gesuchten Daten anbieten (Sekundärindizierung),

þSuchoperationen mit einer Kombination von Kriterien unterstützt werden (Boolesche Operationen),

þeine Verknüpfung von Suchergebnissen in verschiedenen DB-Dateien (JOIN) möglich ist.

Strukturierte Datenbanken, seien sie hierarchisch organisiert wie DL/1 und IMS oder Netzwerk-organisiert wie Total oder die Codasyl-Systeme, bieten diese Möglichkeiten nur in recht begrenztem Maße.

Wesentlich flexibler dagegen sind relationale Datenbanken, die nicht strukturiert, sondern auf der Basis von invertierten Dateien realisiert sind wie etwa Adabas, Sesam, Datacom-DB oder das kürzlich angekündigte SQL/ DS. Hier werden Suchprozesse mit mehreren beliebig verknüpften Kriterien - auch inhaltsbezogenes ("assoziatives") Suchen - unterstützt. Und zwar durch weniger aufwendige Operationen im Indexbereich statt in den Daten.

Daten doppelt speichern?

Um eine solchermaßen geeignete Datenbasis zu erhalten, muß für einige Abfragesprachen wie etwa für QBE und SQL von IBM oder Intellect von Cullinane (ADV/Orga) ein eigener invertiert gespeicherter Datenbestand aufgebaut werden. Dieser wird durch Extraktion aus der Original-Datenbank gewonnen.

Abgesehen vom Mehrbedarf an Plattenspeicher ist dieses Verfahren nicht besonders günstig, wenn man berücksichtigt, wie oft Datenbestände extrahiert und nachgeladen werden müssen, um den Benutzern aktuelle Informationen liefern zu können.

Sinnvoller dürfte es für die meisten Aufgaben sein, wenn Dialogprogramme und Abfragesprache die gleiche- und damit gleich aktuelle - Datenbank als Basis verwenden. Dies aber setzt ein für beide geeignetes Datenbanksystem voraus.

Wir haben gesehen, daß das eine Kriterium für eine stärkere Einbeziehung der Endbenutzer in die DV-Praxis eine geeignete Datenbank ist. Das zweite Kriterium ist das erforderliche Sprachwerkzeug - eine DB-Abfragesprache oder eine Benutzersprache.

Was eine DB-Abfragesprache können soll, verrät bereits die Bezeichnung, nämlich Daten aus einer Datenbank zu extrahieren. Hierfür gibt es eine Vielzahl von Vertretern, so etwa Task für Total, GIS/VS für IMS, Adascript für Adabas, Online Query für IDMS, F1 für Sesam, Qube für System 2000 und andere.

Wenn eine solche Sprache aber wesentlich mehr kann - also noch Bedingungsabfragen, Datenmanipulation arithmetische Funktionen, Sortierung, Listaufbereitung, Terminal-Ein-/Ausgabe, Formatsteuerung etc.- dann nimmt sie den Leistungsumfang einer Programmiersprache an. Nur, daß dafür kein Programmierer erforderlich ist, sondern daß sie auch der Endbenutzer anwenden kann! Deswegen de Bezeichnung "Benutzersprache".

Ein Produkt, das diesen Vorstellungen weitgehend entspricht, ist Natural von der Software AG. Es ist zu erwarten, daß weitere Entwicklungen in dieser Richtung forciert werden. Bild 2 stellt den Leistungsumfang von DB-Abfragesprachen und Benutzersprachen anschaulich dar.

Very High Level Language

Die bisherigen Erfahrungen zeigen, daß mit Abfrage- und Benutzersprachen drastische Einsparungen möglich sind:

- Die Fomulierung eines Informationswunsches an die Datenbank dauert zwischen fünf Minuten und etwa zwei Stunden je nach Komplexitätsgrad. Das ist ein Bruchteil der sonst erforderlichen Programmierzeit und fast schneller als eine saubere verbale Problemformulierung .

-Mit einer Benutzersprache lassen sich vollständige Dialogtransaktionen in rund zehn Prozent der sonst üblichen Programmierzeit entwickelt. Anwender von Natural haben beispielsweise Teile ihrer Online-Anwendungen in dieser Sprache entwickelt. Das heißt, eine solche Sprache ist nicht nur für Endbenutzer sondern als "very high level language" auch für de Programmierung von hoher Bedeutung.

-Programmierkapazität kann eingespart werden, wenn die Endbenutzer ihre Informationswünsche selbst formieren - allerdings ist dies nicht mit jeder Abfragesprache gleichermaßen zu erreichen.

Vom Fahrrad bis zum Porsche

Stärker noch als der Leistungsumfang der Datenbanksysteme variiert der der Abfragesprachen. Deshalb kann man keine grundsätzliche Wertung über Benutzerakzeptanz der Sprachen treffen, sondern muß differenzieren. Die Sprachen unterscheiden sich in:

- Perfomance

Die Antwortzeit für eine Abfrage kann bei gleichartiger Datenorganisation um 300 Prozent variieren. Sofern ein DBMS eine Abfrage in einen sequentiellen Suchprozeß umsetzen

Suchprozeß umsetzen muß - was bei strukturierten DBs leicht passieren kann - wird das Antwortzeitverhalten gravierend schlechter.

- Hardware-Bedarf

Der Speicherbedarf zwischen den Abfragesprachen schwankt zwischen 40 und 1500 KB. Unterschiedlich ist ebenfalls der CPU-Zeitbedarf .

- Leistungsumfang

Das Leistungsspektrum der DB-Sprachen reicht von "simple query" bis zu "very high level language". Entsprechend schwankend ist. die Nutzbarkeit.

- Benutzergerechte Sprachform

Hier gibt es die größten Unterschiede hinsichtlich Sprachform, Formalismus, Schreibaufwand, Lernaufwand und Benutzerunterstützung und -führung.

Diese Kriterien zeigen auf daß Abfragesprache nicht gleich Abfragesprache ist Vielmehr existiert hier ein Spektrum, das vergleichsweise vom Fahrrad bis zum Porsche reicht.

Interessante Beurteilungsmöglichkeiten ergeben sich durch eine vergleichende Fachstudie, wie sie beispielsweise von der GES für das Seminar ,DB/DC Datenbanken im "Online-Betrieb" entwickelt wurde. Aus ihr resultieren die grundsätzlichen Anforderungen an eine DB-Abfragesprache, die in Bild 3 zusammengefaßt sind.

DB-Auswahl auch eine Ouery-Frage

Wir werden in Zukunft nicht umhinkommen, den Benutzern Möglichkeiten zu eröffnen, einen Teil ihrer Anforderungen an die DV selbst realisieren zu können, wenn wir den "Entwichlungsstau" abbauen wollen. Deswegen werden wir uns mit dem Werkzeug Abfrage-Benutzersprache intensiv auseinandersetzen müssen - aber nicht erst, wenn wir eine Datenbank haben, sondern bereits, wenn wir uns für ein DBMS entscheiden. Denn damit bestimmen wir zugleich, welche Möglichkeiten wir den Endbenutzern später zur Verfügung stellen können.

Im Zuge der Datenbank-Beratungen der GES wurde festgestellt, daß die Möglichkeit, eine DB-Abfragesprache einzusetzen, mit die Qualität dieser Sprache ein zunehmendes Gewicht bei der DB-Entscheidung gewonnen hat. Deswegen sollten die DV-Anwender darauf achten, daß sie die Optionen für die Zukunft nicht verbauen.