Sind die bestehenden Datenbanksysteme mühsam aufgeblasene Software-Ungetüme? Der Erfolg des IBM-"Datenbank-Computers" System 138, meint Dr. Hannes Merten (Geschäftsführer der Münchener Sedlmayr & Partner Beratungsgesellschaft), zwinge "konservative" Datenbank-Entwickler, ihre Konzepte zu überdenken: "Erstmalig gibt es mit dem System /38 einen Computer, bei dem Datenbankfunktionen dort realisiert sind, wo sie hingehören - im Betriebssystem." Merten hat sich auf einem IBM-Seminar für Unternehmensberater über das System /38 informiert. Er reflektiert im folgenden Beitrag die Datenbank-Aspekte des Systems und arbeitet die Unterschiede zu IBMs "großen" Datenbanksystemen CICS und DL/1 beziehungsweise IMS heraus.
Alle vorhandenen Datenbanksysteme versuchen, außerhalb des Betriebssystems, dem Computer zu zusätzlichen Funktionen zu verhelfen. Dabei mußten Kompromisse gemacht werden:
þZugriffsmethoden, wie Verkettung und Sekundärindizierung, mußten im Datenbanksystem (DB-System) realisiert werden anstatt im Data Management System (VSAM) des Betriebssystems. Das geht natürlich langsamer und muß außerdem vom DB-System gesteuert werden.
þUm mehreren Benutzern dienen zu können, muß das DB-System als eigenständiges Programm in eigener Partition (oder was dasselbe ist als eigene Task oder auf eigenem Befehlszähler) laufen. Mit den Benutzern, also den anderen Partitionen, muß dann eine Verständigung erfolgen (Inter-Task-Communication). Diese Verständigung wird von den herkömmlichen Betriebssystemen nur mangelhaft unterstützt und wäre überflüssig, wenn das DB-System wie beim System /38 im Betriebssystem "sitzt".
þMit der Bedienung mehrerer Benutzer hängt zusammen, daß Warteschlangen verwaltet werden müssen und daß die Benutzer möglichst überlappend bedient werden, daß also eine Unterbrechung bei Benutzer 1 (etwa wegen Ein-/Ausgabe) dazu benutzt wird, Benutzer 2 zu bearbeiten etc., wie es beim Multiprogramming der Fall ist. Diese Funktionen sind außerhalb der Betriebssysteme nur schwer zu realisieren, und deshalb hapert es bei den vorhandenen DB-Systemen mit Mehrfachbenutzbarkeit und entsprechendem Durchsatz ganz erheblich. Die eigentliche Datenbank-Idee, gleichzeitiges Arbeiten vieler Benutzer mit einer integrierten und gemeinsamen Datenbasis, wird von den DB-Systemer so eigentlich gar nicht realisiert. Wer die Versprechungen trotzdem in praxi ernst nimmt, stellt fest, daß alles stillsteht weil das DB-System der zentrale Flaschenhals ist.
òWer eine Datenbank hat, wird über kurz oder lang auch Terminals anschließen. Oft ist auch der Wunsch, Dialoganwendungen einzuführen, Anlaß für den Einsatz eines DB-Systems. So oder so stellt sich jetzt die Frage, wer die Kommunikation mit den Terminals steuert und verwaltet. Man kann sich für die Herstellersysteme CICS oder IMS/DC (IBM) oder Asmus (Siemens) entscheiden oder sich ein System am "freien Markt" besorgen, etwa Shadow Taskmaster Complete oder Environ 1, wobei dann die Inkompatibilität zu Hardware und DB-System zu beachten sind.
All das kann ein System /38-Anwender getrost vergessen, sein Betriebssystem erledigt das, es ist somit "ereignisorientiert" und enthält vollständiges "Multi-tasking" .
Das System folgt dem "relationalen Modell"
Das System /38 wurde hier anhand der Nachteile vorhandener Systeme beschrieben. Positiver formuliert: Das System enthält integriert in Hardware und Betriebssystem die benötigten Datenbank- und Datenkommunikationsfunktionen, es ist ein komplettes DB/DC-System. Ob die Funktionen besonders gut oder mäßig implementiert sind, ist dabei zunächst einmal unerheblich, sie sind an der richtigen Stelle realisiert. Für die Performance ist zusätzlich von Vorteil, daß große Teile des Betriebssystems einschließlich der Datenbankfunktionen als Mikcrocode realisiert sind.
Die Ankündigung der IBM, das System /38 enthalte ein relationales DB-System, stimmt. Zwar sind hier wesentliche Einschränkungen hinsichtlich der Vollständigkeit der übernahme des Konzepts zu machen, aber die Quintessenz des relationalen Datenmodells, keine festen Zugriffswege und freie Definition der benötigten Daten dann, wenn sie gebraucht werden, ist realisiert.
Hierzu unterscheidet das System ,'38 die folgenden Ebenen:
þZentraler Feldkatalog über alle "Dateien" hinweg. Eine Besonderheit gegenüber vorhandenen Datenbanksystemen, da bei diesen die Felder meist bei ihrer Definition bereits Sätzen oder Dateien fest zugeordnet werden. Auf die in der "Feldreferenzdatei" hinterlegte Beschreibung eines Feldes wird in den Programmen automatisch bei der Compilierung zugegriffen, und zwar sowohl bei der Verwendung in Dateien als auch für die Bildschirm-Ein und -Ausgabe.
þ"Physikalische Dateien" enthalten die tatsächlich gespeicherten Daten. Zu ihrer Definition sind nur die Felder aus der Feldreferenzdatei für die Felder anzugeben, die die Sätze der physikalischen Datei enthalten sollen. Je physikalische Datei ist nur eine Satzart möglich, hier werden System /3-Anwender umdenken müssen.
þ"Logische Dateien" beschreiben die vom Benutzer tatsächlich benötigten Daten. Sie enthalten nur die gemäß Suchbedingungen tatsächlich benötigten Sätze und aus diesen nur die gewünschten Felder. Logische Dateien können mehrere Satzarten enthalten und somit Daten aus verschiedenen physikalischen Dateien. Allerdings kann ein logischer Satz immer nur Felder aus einem physikalischen Satz enthalten, er kann also nicht eine gemeinsame Menge aus Sätzen verschiedener physikalischer Dateien enthalten. Hier ist somit das relationale Datenmodell nicht voll realisiert.
Am besten kann man die Anwendung von logischen Dateien verstehen, wenn man an ein Sortierprogramm denkt. Auch hier ist die Selektion von Sätzen aus der zu sortierenden Datei sowie die Auswahl von Feldern möglich. Diese Prinzipien werden beim System /38 erweitert. An Stelle des Sorts tritt der Datenbankbefehl "CREATE logische Datei".
Zu beachten ist, daß logische Dateien physikalisch nie existieren, sondern nur die Daten beschreiben, die zum Abfragezeitpunkt tatsächlich selektiert und an den Benutzer übergeben werden sollen. Physikalisch enthalten logische Dateien nur die Schlüssel beziehungsweise Adressen der vom Benutzer gewünschten Sätze, sie enthalten somit Zugriffswege ("Adressort"). Dabei kann der Benutzer bestimmnen, ob diese Zugriffswege immer gespeichert und gepflegt werden ("Immediate") oder nur temporär aufgebaut werden, wenn die logische Datei benötigt wird ("Rebuild"). Im letzten Fall kann es lange dauern, bis die erste Antwort kommt. Das ist der Preis, wenn man als Benutzer auf feste Zugriffswege und den damit verbundenen Updateaufwand verzichtet. Aber man hat wirklich beliebige Abfragemöglichkeiten.In diesem Zusamnenhang wird auch der Vorwurf gegen das relationale Datenmodell, es sei nur auf einer "Supermaschine" realisierbar, plausibel.
Anzumerken ist, daß selbstverständlich jedes beliebige Feld der physikalischen Datei Suchbegriff in der logischen Datei sein kann. Hierzu verwendet das System 138 aber nicht die Technik der Sekundärindizierung, also des Aufbaus zusätzlicher Indices für eine Datei, sondern eine in der Praxis völlig neue Technik. Das Prinzip liegt darin, Suchbäume zu erstellen, in der Theorie auch als "Sussenguthverfahren" bekannt. Der Autor muß hinzufügen, daß er hier nicht ganz sicher ist, da keine eindeutigen Aussagen durch IBM zu erhalten waren.
Benutzerschnittstellen und RPG III
Die Kommunikation mit der Datenbank erfolgt bei bisherigen Datenbanksystemen vom Benutzerprogramm aus über Datenmanipulationssprachen (DML), vom Terminal aus mit Abfragesprachen.
Letzterem entspricht beim System /38 das "Query"-Dienstprogramm, welches im Prinzip mit Abfragesprachen wie "IQL" bei IMS vergleichbar ist, allerdings leistungsfähiger ist, etwa durch die automatische Verwendung des Zentralen Feldkatalogs für die Überschriften und Feldaufbereitung. Selbstverständlich ist die Ausgabe auf Bildschirm und/oder Drucker möglich. Der Bediener wird bei der Erstellung der Abfragen im Dialog geführt, kann sich also nicht "verhaspeln". Damit ist wirklich eine Benutzung durch Nicht-EDV-Personal möglich. Zu beachten ist auch, daß "Query" durch die Eigenschaft Datenbank-Computer für jeden /38-Anwender verfügbar ist, jeder andere Computerbenützer muß sich erst zusätzlich zum Computer ein Datenbanksystem mit Abfragesprache zulegen.
Wesentliche Unterschiede ergeben sich zwischen dem System /38 und vorhandenen DB-Systemen bei der Datenmanipulationssprache: Vorhandene DB-Systeme stellen eine Reihe von Datenbankbefehlen zur Verfügung, die im Programm genutzt werden können, bei UDS von Siemens sogar in der konfortabelsten Form als Erweiterung des Cobol-Compilers.
Das System /38 teilt die Funktionen der Datenmanipulation hingegen auf: Die Suchlogik liegt im wesentlichen außerhalb des Programms im Bereich der Definition der logischen Datei. Hier kann flexibel definiert werden (CREATE Befehl), welche Daten überhaupt verarbeitet werden sollen. Die Befehle zur Änderung, zum Hinzufügen und zum Löschen von Daten hingegen sind in der Programmiersprache RPG III enthalten. Sie haben hier keine Sonderstellung, sondern entsprechen der normalen Programmlogik einer beliebigen Programmiersprache. Die Programme "verarbeiten" somit Daten, und der Progammierer meint, er hätte es mit normalen Dateien zu tun. Die Schnittstelle zur Datenbank wird damit wesentlich vereinfacht, ein wichtiger Aspekt, wenn man die Komplexität der Schnittstelle der Codasyl-Datenbanksysteme kennt.
Zu beachten ist, daß die Datendefinition in RPG III-Programmen überflüssig ist, es genügt, die benötigten logischen Dateien anzugeben. Deren Fehler werden dann automatisch in den Code eingefügt. Das gibt es auch bei Codasyl-Datenbanksystemen hinzu kommt beim System /38, daß die Felder automatisch auch in der Ausgabe stehen wenn die logische Datei als "zum Andern" eröffnet wird.
Das Sicherheitssystem ist noch unvollständig
Das System /38 verfügt als eigener Teil des Betriebssystems über die sonst im
Rahmen der Datenbanksysteme implementierten Maßnahmen zur Datensicherung und zum Datenschutz.
Der Datenschutz erlaubt je Benutzer die Kontrolle der Zugriffsberechtigung für alle "Objekte" des Systems. Objekte können sein Bildschirme, Bibliotheken, Programme Befehle und Daten. Bei den Daten ist die niedrigste Schutzebene die logische Datei, nicht die Feldebene. Durch die freie Zuordbarkeit von Feldern in logischen Dateien und somit auch das Weglassen von Feldern kann aber de facto der Schutz auf Feldebene realisiert werden.
Bei der Datensicherheit sind die Maßnahmen zur Vermeidung des gleichzeitigen Änderns von Sätzen voll realisiert. Dabei erfolgt der Satzschutz, wenn keine weiteren Angaben durch den Benutzer gemacht werden, durch den vom System festgelegten Modus. Diesen Modus kann der Benutzer durch Befehle ergänzen oder verschärfen, zum Beispiel durch die Befehle "Shared read only", "Exclusive Update", "Exclusive". Diese Befehle können direkt logischen Dateien zugeordnet werden, die Sicherheitsstufen werden also im Gegensatz zu vorhandenen DB-Systems bereits Datei-Eigenschaften. Diese Eigenschaften können dann bei Bedarf durch die Benutzerprogramme überlagert werden, so kann eine grundsätzlich als "shared read only" definierte Datei mit "exclusive" eröffnet werden.
Bis hierhin ist das Sicherheitssystem als sehr komplett, allein beim "logging" und beim Wiederanlauf läßt das System /38 den Anwender hoch im Stich. Es gibt keine vom System verwaltete Log-Datei, die die mit der Datenbank durchgeführten Änderungen enthält. Der Grund hierfür liegt vielleicht in der Tatsache daß nicht jeder IBM /38-Anwender eine Bandstation hat und vielleicht auch nicht haben soll denn man ist ja" voll plattenorientiert". Andererseits traut man sich vielleicht nicht, Platz auf der Platte für das "logging" zu opfern; die Diskette schließlich ist zu lagsam
Mit dem fehlenden "logging" fehlt auch die Grundlage für vom System unterstützte Wiederanlaufverfahren.IBM schreibt folglich brav: "Wiederanlauf muß integrierter Bestandteil jedes Anwendungs-Designs sein" und "hängt sehr stark von der jeweiligen Anwendungs-anforderung ab". Anschließend wird betont: "Das Wiederanlaufverfahren muß in jeder Anwendung vorhanden sein." (Dabei wird darauf verwiesen daß die Standardbuchhaltung für das System /38 ein komplettes Wiederanlaufverfahren enthält und daß man dieses als Muster nehmen könne.)
Armer Anwender, selbstverständlich gehört das "logging" vollständig und der Wiederanlauf zum größten Teil ins System und nicht in die Anwendung, wenn man ein Datenbank-Computer sein will. Der Autor ist aber ziemlich sicher, daß so etwas noch kommt und daß IBM einfach noch nicht fertig ist mit der Softwareentwicklung.
Das System /38 ist ein virtuelles System. Ein umfangreiches Spoolsystem ist vorhanden. Das Betriebssystem hat neben Prioritäts- und Interrupt-Steuerung auch eine Zeitscheibe. Es hat eine völlig neue und umfangreiche Job-Control Language, CL für Control Language genannt. Dies ist in sich eine kleine Programmiersprache, zum Beispiel mit arithmetischen Befehlen. CL-Programme müssen nicht wie normale Job-Control-Statements zum Ablaufzeitpunkt interpretiert werden, sondern sind umgewandelt und damit sehr schnell. Es gibt Hilfen bei der Programmentwicklung vergleichbar mit EDT im BS2000 oder mit TSO, hinzu kommen Testhilfen im Dialog. Für die Dateiverwaltung und Auswertung gibt es das DFÜ-Dienstprogramm, das sich bereits bei den Systemen /32 und 134 bewährt hat. Kernspeicher gibt es bis zu 1536 B (davon werden aber etwa 400 KB vom System benötigt zur "Aufrechterhaltung des Betriebs"). Plattenkapazität ist verfügbar bis zu 2285 Millionen Bytes. Da kann man schon Datenbanken realisieren, und so mancher stolze DV-Kunde mit vielen Tausendern von Miete kommt ins Staunen.
Dafür müßte er sich aber beiden Programmiersprachen umstellen denn es gibt nur RPG III. Das ist für größere Anwender eine Klippe, allein schon psychologisch.
Neue Balkone für altes DOS-Haus
Das System /38 ist unter Datenbankaspekten, aber auch sonst revolutionär. Zum ersten Male hat IBM die neue Computergeneration auf den Markt gebracht, von der /370-Anwender immer gemunkelt haben (Future System etc.). Es gibt zwar auch bei anderen Herstellern kleinere Systeme, die gleich als Datenbanksystem angekündigt wurden, hier aber mit den konventionell aufgepfropften DB-Systemen, also ohne Integration ins Betriebssystem. IBM hat also wieder einmal die Führung übernommen.
Trotzdem bleibt ein merkwürdiger Beigeschmack. Ausgerechnet die kleinen IBM-BDV-Anwender werden mit der neuen Generation traktiert. Sicherlich ist das System komfortabel und leicht zu benutzen, aber es benötigt Planung. IBM sagt selber, bisher wäre beim System /3 das Verhältnis Design und Organisation zur Programmierung 30:70 gewesen, und beim System /38 wäre es genau umgekehrt. Hier werden also erhebliche qualitative Kapazitäten benötigt, die bei BDV-Kunden nicht immer vorhanden sein dürften.
Den DV-Kunden der IBM wird hingegen ein hardwaremäßig gutes und preiswertes System 4300 vorgesetzt, aber mit Uraltsoftware DOS/VS mit einem E für Extended, da sind wieder mal ein paar Balkone hinzugefügt worden. Auch VM erscheint dabei als das Wahre, bei allerdings zugegebenermaßen guten Dialogfähigkeiten. Man muß also fragen, ob das System /38 nicht das System 4300 sein müßte, also ein Produkt des Bereichs DV der IBM; ob nicht hier die Revolution notwendiger wäre. Für die BDV- /3-Anwender hätte hingegen vielleicht ein erweitertes System /34 genügt. Also: System /38, die richtige Systemsoftware auf der falschen Maschine?
Noch ein Wort zu den Konsequenzen für die Datenbanksystementwicklung. Die IBM-Leute haben bewiesen, daß sie den richtigen Weg kennen und realisiert haben. Damit dürfte ein relationales DB-System, allein oder als Teil neuer Systemsoftware für die IBM-DV-Kunden nur noch eine Frage der Zeit sein, unter dem Titel "System R" ist es auch bereits entwickelt. IMS und DL/1, aber auch CICS dürften somit nur noch eine begrenzte Zeit weiterentwickelt werden, auch wenn IBM gerade in einem Leserbrief in der COMPUTERWOCHE dementiert hat. Wer jetzt noch ohne Not und Terminzwang diese Produkte erstmalig einsetzt, ist selber schuld. Wer kann; sollte warten; nach Meinung des Autors kann es nur noch maximal zwei Jahre dauern.
Auch dürfte jetzt endgültig klar sein, daß IBM nicht mehr auf den Codasyl-Zug aufsteigt. IBM wird also bereits den neuen relationalen Standard setzen, bei vor Codasyl überhaupt richtig Standard geworden ist. Dies ist wichtig für die Nicht-IBM-Anwender, die über Codasyl auf Kompatibilität hoffen.
Der Autor Dr. Hannes Merten ist Gesellschafter und Geschäftsführer der Sedlmayr & Partner Beratungsgesellschaft für Betriebswirtschaft und EDV- Anwendung mbH, München. Merten ist Referent der Datenbank-Seminare des Control-Data-lnstituts, Frankfurt.