In thematisch zusammenhängenden Beiträgen beschäftigt sich Michael Bauer mit Fragen des Ob und Wie einer Datenbank-Implementierung, der Auswahl eines geeigneten TP-Monitors und der Ausbildungserfordernisse je nach Benutzerebene Außerdem stehen Themen wie Data Dictionary, Dritte Normalform, neue Hochsprachen und Datensicherheit im Mittelpunkt seiner Erörterungen.

*Michael Bauer, Leiter des Bereichs DV-Beratung bei der GES-Gesellschaft für elektronische Systemforschung mbH in Allensbach, ist seit vielen Jahren mit der Anwendungspraxis von Datenbank- und Online-Systemen vertraut. Er ist Autor zahlreicher Fachbeitrage zur DB/DC-Thematik.

Kapitel VIII, Teil 1:

Werkzeuge für schnelleren DB/DC-Einsatz

In den meisten Unternehmen existiert inzwischen ein mehr oder weniger großer "Anwendungsstau"; das heißt notwendige Anwendungen müssen auf ihre DV-technische Realisierung warten während ein Großteil der Programmierkapazität für die Wartung alter Anwendungssysteme verbraucht wird. Und die Tendenz ist steigend!

Eine der Ursachen dafür ist der steigende Informationsbedarf, der mit der Einführung von Online-Systemen ausgelöst wurde. Die Einbettung von Terminals in den täglichen Arbeitsablauf der Sachbearbeiter macht es erforderlich, die notwendigen Informationen gezielt bereitzustellen, statt sie aus dicken Auswertungen herauszusuchen. Zwangsläufigwerden mehr Programme als bei Batchverarbeitung notwendig.

Durch Terminals erst einmal an diese neue Dimension der Datenverarbeitung gewöhnt, erkennen die Fachbereiche immer weitere Möglichkeiten, die Abwicklung der Geschäftsvorfälle in einem Unternehmen mit Computerleistung zu verbessern. Der Informationsbedarf steigt.

Trend zu Informationssystemen

Eine weitere Ursache ist der Trend, Informationssysteme zu schaffen. Nachdem die meisten Unternehmen ihre operativen Aufgaben weitgehend durch EDV-Verfahren abgedeckt haben, nehmen sie sich nun verstärkt dispositive Aufgaben vor. Kontrolle, Planung und Entscheidungsfindung im Unternehmen sollen durch den Computer intensiver unterstützt werden. Dazu entstehen "Informationssysteme" für Marketing, Disposition, Vertriebssteuerung und ähnliche Funktionen.

Die Daten für diese Systeme sind zwar meistens schon in der EDV gespeichert; lediglich die entscheidungsrelevanten Informationen müssen noch daraus gewonnen werden. Dabei ist charakteristisch, daß diese Informationen

- nach vielfältigen Gesichtspunkten zusammengestellt werden sollten,

- sofort verfügbar sein müssen,

- häufig nicht vorher bestimmbar sind.

James Martin beispielsweise erwartet, daß sich der Anteil an Computerleistung für informationsorientierte Aufgaben von heute zirka 20 Prozent auf zirka 60 Prozent in fünf Jahren erhöht haben wird.

Datenbanken gegen stagnierende Softwareproduktivität?

Der Informationsbedarf steigt also sowohl quantitativ als auch qualitativ; das heißt in Richtung einer flexiblen, gezielten und schnellen Informationsbereitstellung. Auf der anderen Seite kann unsere klassische DV-Entwicklung nicht mit der Steigerung der Anforderungen mithalten. Wir haben zwar mit höheren Programmiersprachen, mit modernen Entwurfsmethoden (zum Beispiel Strukturierter Programmierung) und mit interaktiver Programmierung die Produktivität bereits erheblich verbessern können, aber die Möglichkeiten sind jetzt weitgehend ausgeschöpft. Doch durch einen Datenbankeinsatz ergeben sich zwei weitere Maßnahmen zur Produktivitätssteigerung:

1.) Die Endbenutzer können mittels einer DB-Abfragesprache einen Teil ihres Informationsbedarfs selbst befriedigen.

2.) Auf Basis von Datenbanksystemen sind Entwicklungswerkzeuge möglich, die Programmentwicklung und -test gravierend beschleunigen.

Ebensowenig, wie sich der Geschäftsverlauf nur in vordefinierten Bahnen bewegt, ist auch der Informationsbedarf für dispositive Kontrolle und Entscheidung planbar. Kommt es zu einer überraschenden Situation im Geschäfts- oder Produktionsablauf (zum Beispiel ein Lieferant fällt wegen plötzlichen Konkurses aus, die Einkaufspreise eines Produktes verteuern sich über Nacht etc.), ist die Überraschung groß. Jetzt müssen gezielte Informationen für eine Situationsanalyse oder für die Planung von Lösungsalternativen bereitgestellt werden. Mit der klassischen Programmentwicklung dauert es viel zu lange und kostet zuviel. Wenn aber die Daten in einer Datenbank gespeichert sind, kann man sie mit einer DB-Sprache relativ schnell auswerten (siehe dazu Abbildung 1).

Zumindest ist das die Idee. Doch wie sieht es in der Praxis aus?

Nicht jede Datenbank ist geeignet

Obwohl es für jedes Datenbanksystem Abfragesprachen gibt, sind sie oft gar nicht installiert: Ist eine vorhanden, so wird sie häufig nur von den Programmierern als Testhilfe und nicht von den Endbenutzern zur Informationsbeschaffung verwendet. Ein Grund ist, daß viele Datenbanksysteme schon von ihrem Konzept für eine flexible Informationsbereitstellung weniger geeignet sind. Dies gilt insbesondere für strukturierte Datenbanken, bei denen die Zugriffspfade von vornherein statisch angelegt werden müssen.

Soll ein Endbenutzer seine Informationen selbst aus einer Datenbank gewinnen können, so ist erforderlich, daß

- er Strukturen und Zugriffspfade innerhalb der Datenbank nicht zu kennen braucht,

- Daten über vielfältige Suchkriterien gezielt gefunden werden können (Sekundärindizierung),

- verknüpfte Suchbedingungen (Boolesche Operationen) nicht zu seriellem Durcharbeiten der Datenbank führen, sondern mit Hilfe invertierter Listen abgewickelt werden,

- eine Verknüpfung von Suchergebnissen in verschiedenen DB-Dateien möglich ist (Join),

- zusätzliche Suchkriterien auch nachträglich noch problemlos geschaffen werden können.

Hinsichtlich dieser Anforderungen haben sich relationale Datenbanken auf Basis invertierter Dateien, (zum Beispiel Adabas, Sesam, SQL/DS) als günstiger erwiesen. Deshalb haben sich bereits einige Unternehmen zu ihrem "alten" DBMS für Informationssysteme noch ein relationales DBMS zugelegt. (wird fortgesetzt)