In der COMPUTERWOCHE vom 2. März haben wir den ersten Teil dieser Originalarbeit über Theorie und Praxis von Datenbanken unter der Frage "Theoretisches Pro und praktisches Kontra zur Datenbank?" veröffentlicht. Der zweite, abschließende Teil bringt mm fünf Thesen zum arbeits- und zeitsparenden Einsatz, die sich aus der praktischen Erfahrung des Autors herauskristallisiert haben.
These 1: Für benutzereigene Programme sind anwendungsneutrale Schnittstellen notwendig.
Die Speicherung von Daten in einem Datenbanksystem soll dem Benutzer Unabhängigkeit gewährleisten. Bei den kommerziell vertriebenen Datenbänken ist es jedoch so, daß die Daten in eine Art Betriebssystem eingebettet sind sowie in spezielle Ein- und Ausgabeprogramme. Diese Ausgabeprogramme bevorzugen gewisse Formen der Datenabfrage und häufig auch bestimmte Programmiersprachen. Die Schnittstellen zwischen der Datenbank und diesem organisatorischen Umfeld begünstigen mitgelieferte Ein- und Ausgabeverfahren und erschweren andere. Unter solchen Umständen kann von einer Unabhängigkeit der Datenanwendung nicht die Rede sein. Es mag mm Anwender geben, die eine solche Kopplung von Datenbank und einem spezifischen Betriebssystem wünschen. Für andere ist sie unnötig, wahrscheinlich überdeckt sie sogar in einigen Fällen die geringe Anpassungsfähigkeit der Schnittstelle zwischen Datenbank und Auswertungsprogrammen.
These 11: Das Datenbanksystem soll sich in die Organisation des
Rechenzentrums einordnen, ohne zu dominieren.
Mit der im vorigen Abschnitt geforderten Unabhängigkeit des Datenbanksystems von den Anwendungsverfahren läßt sich die Datenspeicherung und der Datenabruf organisch in die Organisation einfügen. Wenn beispielsweise Fortschreibung und Datenänderung von der Sache her auf den Datenbankverwalter beschränkt werden können, ergeben sich daraus wesentliche Vorteile für den Betrieb. Es genügen dann nämlich viel einfachere Steuerungsmechanismen. Im allgemeinen wird man dann die Programme für den Abruf aus der Datenbank als Unterprogramme in das ja vorhandene Betriebssystem des Rechners übernehmen können. Jedenfalls ist kein Grund vorhanden, warum für solche Anwendungen ein Datenbankbetriebssystem von hundert oder mehr KB notwendig sein soll. Ein offenes System, bei dem die Datenbank insgesamt und jede einzelne Datenbankbenutzung nur mit den tatsächlich benötigten Betriebsverfahren ausgestattet würde, gäbe den DV-Organisatoren die Möglichkeit, Aufwand und Nutzen in ein ausgewogenes Verhältnis zu bringen. Umgekehrt belastet ein geschlossenes System aus Datenbank, Ein- und Ausgabeblöcken und Steuerung unnötig den Rechenbetrieb.
These III: Die entscheidenden Kriterien für die Leistungsfähigkeit eines Datenbanksystems sollen die Geschwindigkeit und die Benutzerfreundlichkeit bei Ein- und Ausgabe von oder in Anwenderprogramme sein.
Für Rechnerprogramme kann der Hersteller eines Datenbanksystems, von Mittelwertbildung oder ähnlichem abgesehen, ohnehin keine Programme mitliefern. Und was die reinen Ausgabeprogramme auf Listen oder Bildschirm betrifft, so hat ein Rechenzentrum, das eine Datenbank betreibt, allein von der not wendigen Größe her sicherlich viele Mitarbeiter mit Programmiererfahrung, die leicht die benötigten Tabellen erstellen können. Meistens werden solche Programme aus der Zeit vor dem Einsatz des Datenbanksystems vorhanden sein. Es ist daher nicht ersichtlich, warum die Datenbankhersteller sich eher automatisierten Ausgabeverfahren als den Speicherungs- und Abrufmöglichkeiten zu wenden. Beispielsweise gibt es bei einem der renommierten und als universell deklarierten Systeme noch Schwierigkeiten beim Speichern von Gleitkommazahlen, der Benutzung von Fortran und der Eingabe im Stapelbetrieb. Was die Benutzerfreundlichkeit betrifft, so sollte es nicht nötig sein, beim Abruf beschreibende Angaben (Puffergröße, Feldangaben, Formate etc.) anzugeben, die bereits bei der Speicherung genannt worden oder berechenbar sind. Sie sollten vielmehr von der Datenbank ohne zusätzlichen Aufwand zur Information mitgeliefert werden.
These IV: Bei der Konzeption des Speicherungs- und Zugriffsverfahrens sind kurze Suchzeiten für einzelne Datensätze besser als Hierarchien, Netzwerke, Verkettungen, Kopplungen oder Zeiger.
Der Programmierer sollte mit den die Daten kennzeichnenden Merkmalen einen schnellen Zugriff zu allen logischen Einheiten haben. Dies erhöht die Flexibilität für neue, bei der Festlegung der
Speicherungsform nicht bekannte Auswertungen.
Bei schnellem Zugriff kann auf das Abspeichern von Verknüpfungen in der Datenbank weitgehend verzichtet werden. Die mit Pointern, Segmenten und dergleichen erzeugten hierarchischen Strukturen sind ohnehin nur ein theoretischer Überbau über einer linearen Speichermatrix. Sie erschweren Aufbau und Nutzung einer Datenbank sowie den Systemwechsel und erhöhen den Bedarf an Systemressourcen. Der Anwender kann in jedem Falle aus der funktionalen Abhängigkeit zwischen den Datensätzen Hierarchien im Anwenderprogramm entwickeln.
These V: Datenbank- und Management-Informations-Systeme sollten praktisch und theoretisch getrennt behandelt werden.
In den 60er Jahren wurden fast gleichzeitig die ersten Datenbanksysteme und in einer CODASYL-Gruppe (Data Base Task Group) Standards für die Datenspeicherung in Datenbanken sowie für Sprachen zur Beschreibung (DDL) und zur Verarbeitung (DML) von Daten entwickelt. Für ein technisches Objekt waren die Normungsversuche zu früh. Es wäre eher Zufall, wenn die Pioniere der Datenbanken die Entwicklung bei Hardware, Software und Benutzerbedarf gleichzeitig und hinreichend genau hätten voraussehen können. Konsequenterweise wurden die Vorschläge für die Datenspeicherung bei vielen wichtigen Datenbanksystemen nicht beachtet, und die derzeit wohl interessanteste Neuentwicklung soll das Relationsmodell als Basis haben (vergleiche Kolumne in CW vom 19. 1. 1979).
Einflußreicher war jedoch der Vorschlag, den Datenbanken eine Datenmanipulationssprache für die Verarbeitung anzugliedern. Dadurch werden die Grenzen zwischen einer Datenbank im engeren Sinn und einem Management-Informations-System verwischt. Letzteres ist aber eine spezielle Anwendung der Datenbank, an große Rechnersysteme gebunden und für Nichtprogrammierer geeignet. Datenbanken können dagegen auf Rechnern aller Größenordnungen nützliche Hilfsmittel für die Rechenzentrumsorganisation und für benutzereigene Programme sein.
Frage: Schadet den großen Datenbanken der übermäßige Bedarf an Arbeits- und Rechnerleistung?
Die bekanntesten unter den angebotenen Datenbanksystemen sind eine Ballung von Datenbanksystemen einerseits und organisatorischen sowie betrieblichen Steuerungsmechanismen und Ein-/ Ausgabeverfahren andererseits. Auch bei der Begriffsdefinition bestehen Tendenzen, diese organisatorischen Möglichkeiten unter "Datenbank" einzubeziehen. Wichtig ist jedoch, daß auch solche Datenbanksysteme notwendig sind, die den Programmierer bevorzugen, der hauptsächlich darauf Wert legt, daß ihm die Daten mit kurzen Suchzeiten in seinem Programm für Berechnungen und Ausgaben zur Verfügung steht. Datenbanken für solche Zwecke lassen sich leicht in einen, Rechenzentrumsbetrieb einfügen; Erscheinungen wie die, daß wegen des großen Aufwandes das Datenbanksystem nur in bestimmten Betriebszeiten zugelassen ist oder daß der Rechner wegen des Datenbanksystems vergrößert werden muß, können vermieden werden.
Es gibt neuere Datenbankentwicklungen mit einem Trend in die hier angeregte Form. Meinungsbildend sind jedoch einige wenige andere, und - ein psychologisches Problem? - deren große Ansprüche an Personaleinsatz und Systemressourcen scheinen ihrem Ruf eher zu nützen als zu schaden.
* Dr. Manfred Schumacher ist DV-Organisator und Datenbankverwalter bei der Bundesanstalt für Gewässerkunde in Koblenz.