Die Integration der verteilten Datenbankverarbeitung in das System "Sesam" steigert, wie sich gezeigt hat, den Durchsatz der gesamten betrieblichen Datenverarbeitung erheblich. Der "Distributed Database Handler" von Sesam-DCN arbeitet die Datenbankzugriffe verschiedener Anwender auf verschiedene lokale Sesam-Datenbanken überlappt ab. Diese Asynchronität nützt mit einem Minimum an Verwaltungsaufwand die Ein-/Ausgabezeiten eines eventuellen anderen Zugriffs aus. Messungen von Sesam-DCN-Anwendungen ergaben bei rein lokaler Datenbankverarbeitung eine Durchsatzsteigerung um 100 Prozent. Sesam-DCN läßt dem Anwender die Freiräume, die er braucht.

Neben der an einem zentralen Rechenzentrum orientierten Datenverarbeitung gewinnen dezentrale oder verteilte Verarbeitungsformen an Bedeutung.

Eine verteilte Datenbankverarbeitung ermöglicht das Abarbeiten von Anwenderaufgaben auf Basis einer oder mehrerer Datenbanken, wobei deren Abfrage, Verarbeitung und Speicherung in einem Verbund autonomer, räumlich getrennter DV-Anlagen erfolgt.

Dabei geht es immer - und interdependent - um die vier Themenkreise: zu erledigende Aufgaben, DV-Anlagen, Datenbanken und räumliche Verteilung (Orte). Siehe dazu Bild 1.

Die dezentrale Datenbankverarbeitung ist dagegen nur eine Vervielfältigung der zentralen Organisationsform auf einzelne Orte. Ihr fehlt der Verbund zwischen den einzelnen DV-Anlagen.

Das relationale Datenbanksystem Sesam erlaubte bislang die zentrale und dezentrale Verarbeitung. Mit dem neuen Produkt Sesam-DCN wird ein erster Schritt in Richtung verteilte Datenbankverarbeitung getan.

Die verteilte Datenbankverarbeitung bietet gegenüber der zentralen die Vorteile einer

- anpassungsfähigeren DV-Organisation (sie paßt sich mehr als bisher der Organisationsstruktur des Anwenders an und läßt internen, sachbezogenen Abläufen mehr Spielraum),

- Durchsatzsteigerung (die Last der DV-Anwendungen wird von mehreren DV-Anlagen parallel abgewickelt),

- erhöhten Verfügbarkeit (der Ausfall eines Rechners blockiert nicht mehr den Ablauf aller DV-Anwendungen),

- Senkung von Transport- und Kommunikationskosten.

Theoretisch-praktische Problemkreise

Dies trifft natürlich auch für die dezentrale Verarbeitung zu, welche jedoch einen entscheidenen Nachteil aufweist: Die Datenbanken sind einzelnen Rechnern exklusiv zugeordnet. Eine verteilte Datenbankverarbeitung mit Sesam-DCN hebt diese Einschränkung auf.

Den Vorteilen stehen aber auch verschiedene Problemkreise gegenüber, die zum Teil weder in der Theorie noch in der Praxis umfassend gelöst wurden. Beim Einsatz der verteilten Datenbankverarbeitung müssen sie aber berücksichtigt werden. Dazu gehören

- Zeitbedarf der Kommunikation zwischen DV-Anlagen,

- Organisation rechnerübergreifender Arbeitsabläufe für die Datenbankverwaltung,

- Heterogenität von Hard- und Software.

Sesam-DCN wurde daher so konzipiert, daß die Probleme der verteilten Datenbankverarbeitung überschaubar und lösbar bleiben. Beispielsweise wird die Heterogenität der Hard- und Software dadurch reduziert, daß Sesam-Datenbanken in einem Transdata-Netz von BS2000-Rechnern verarbeitet werden.

Siemens bietet Sesam-DCN als anwendungsneutrales Zusatzprodukt zu Sesam an. Es ist daher bei Anwendern aus dem Industrie- und Behördenbereich einsetzbar. Im folgenden soll skizziert werden, welche Verarbeitungsmöglichkeiten Sesam-DCN bietet, und welche Überlegungen beim Design der Anwendungen eine Rolle spielen.

Generelle Designüberlegungen

Eine Datenbankanwendung mit Sesam wird - gleichgültig, ob lokale oder per Sesam-DCN verteilte Verarbeitung vorliegt - durch drei Ebenen charakterisiert:

Benutzersichten auf die (verteilten) Datenbanken: Benutzersichten sind Datenbankausschnitte, die durch Anwenderprogramme bearbeitet werden.

Datenbankkonzept: Das Datenbankkonzept ist gleichsam die Summe aller Benutzersichten. Es beschreibt den Datenbankinhalt anwendungsneutral und entsprechend dem Relationenmodell in Tabellenform.

Interne Speicherstruktur: Die interne Struktur einer Datenbank ist die Umsetzung des Datenbankkonzeptes auf die erforderliche Belegung von peripheren Speichermedien. Hier kommt der Einfluß des Rechnerverbundes hinzu.

Diese systemtechnisch orientierte Betrachtungsweise (Bild 2) liefert nur sehr grobe Anhaltspunkte, nach welchen Kriterien eine verteilte Datenbankverarbeitung zu konzipieren ist. Sie müssen im konkreten Anwendungsfall aus der Sicht der Zielvorgaben, der zu lösenden Aufgaben gesehen werden. Außerdem steckt die vorhandene Organisationsstruktur des Anwenders den Rahmen für das Datenbankdesign ab.

Bei der Einführung der verteilten Datenbankverarbeitung mit Sesam-DCN laufen wie bei jedem DV-Projekt die Schritte der Analyse des Ist- und Sollzustandes ab, deren Ergebnisse wiederum in einer Synthesephase das anzustrebende Design der Datenbankanwendung liefern. Wendet man Grundsätze der klassischen Organisationslehre auf den Einsatz von Sesam-DCN an, so spielen folgende Designkriterien eine Rolle:

Aktionsträger:

Menschen oder Maschinen, welche mit Sesam-DCN verteilte Datenbanken bearbeiten.

Objekte:

Güter oder Dienstleistungen, die vom Sesam-DCN-Anwender erstellt werden.

Funktionen:

Tätigkeiten, die zur Erstellung von Gütern und Dienstleistungen nötig sind.

Phasen:

(Optimaler) Ablauf von Tätigkeiten zur Erstellung von Gütern und Dienstleistungen; Kombination von Objekt und Funktion.

Rang:

Verhältnis zwischen einzelnen Sesam-DCN-Anwendern hinsichtlich ihrer Entscheidungsbefugnis.

Sachmittel:

Hard- und Softwarebasis für den Einsatz von Sesam-DCN.

Räumliche Gegebenheiten:

In diesem Fall die Verteilung von BS2000-Anlagen auf einzelne Orte.

Diese Kriterien prägen entscheidend die konkrete Einsatzform von Sesam-DCN (Bild 3).

Die Kriterien Aktionsträger, Objekte, Funktionen, Phasen und Rang beeinflussen die Art, in der eine bestimmte Aufgabenstellung zu erledigen ist (Bild 3). Da DV-Anlagen ihre Arbeit mittels Programmen erledigen, bestimmen die genannten Kriterien auch die Eigenschaften der zu implementierenden Anwenderprogramme.

Die Bedienung der Programme per Bildschirmmasken, Meldungstexten etc. muß sich an denjenigen (Aktionsträgern) orientieren, die damit arbeiten müssen. Auf Sesam-Datenbanken greifen die Anwenderprogramme mit der Sesam-Datenmanipulationssprache zu. Der Zugriff erfolgt über Benutzersichten, sogenannten logischen Dateien, welche folgende Eigenschaften aufweisen:

- Auswahl der benötigten Daten mit den relationalen Datenbankoperationen Feldauswahl (projection), Satzauswahl (selection) und Satzverbund (join).

- Satzauswahl anhand logischer Auswahlbedingungen mittels UND/ ODER-Verknüpfung und Bedingungen wie GROESSER, KLEINER.

- Suchen, Lesen, Neuaufnehmen, Ändern und Löschen von Datenbankinformationen.

Die Anwenderprogramme können mit den Programmiersprachen Cobol, RPG, Fortran, PL/I, Algol und Assembler erstellt werden. Dem Trend zur verstärkten Dialoganwendung trägt Sesam-DCN dadurch Rechnung, daß neben der Stapel- auch Online-Verarbeitung verteilter Sesam-Datenbanken möglich ist. Diese kann im Teilnehmermodus und in Verbindung mit dem TP-Monitor UTM auch im Teilhabermodus geschehen (Bild 4).

Die Anwenderprogramme enthalten keine rechner- oder rechnernetzbezogenen Angaben. Die Programmlogik ist so, als wären gleichsam alle Datenbanken an einem Rechner. Man spricht in diesem Zusammenhang von transparenten Anwender spontanen Zugriff auf verteilte Datenbanken. Es sind alle bislang für lokale Verarbeitung verfügbaren Funktionen einsetzbar.

Sesam-Datenbanken sind Instrumente für eine integrierte Datenspeicherung. Die Datenorganisation darf sich daher nicht an einzelnen Anwenderprogrammen orientieren. Sie muß vielmehr eine Zusammenfassung aller Benutzersichten (logischen Dateien) zu einem anwendungsneutralen Datenbankkonzept darstellen.

Bei verteilten Datenbanken kommt hinzu, daß ein Datenbankkonzept eine globale Sicht über alle, auf verschiedene Rechner verteilten Datenbanken bieten muß. Diese globale Sicht besteht aus zwei Arten von Beschreibungen (Bild 5):

Database Directory (DB-DIR): Verbale Beschreibung der Verteilungsregeln (welche lokal verarbeitbare Datenbank an welchem BS2000-Rechner installiert ist).

Attributkataloge für die einzelnen (lokalen) Datenbanken: Ein Attributkatalog beschreibt den linearen oder relationalen Aufbau einer einzelnen Datenbank. Bildlich gesehen gleicht sie einer großen Tabelle mit eindeutigem Primärschlüssel und einfachen Feldern (= Attributen).

Eine verteilte Sesam-Datenbank besteht demnach aus Verteilungsregeln und einzelnen Datenbanken.

Ist nun für eine konkrete Anwendung das Datenbankkonzept zu entwerfen, so gelten generell die selben Designkriterien wie für Benutzersichten. Nur sind sie global, mithin über alle Benutzersichten hinweg anzuwenden. Keine Beachtung findet das Kriterium Aktionsträger, da es nur für die Schnittstellen der Anwenderprogramme relevant ist.

Die Auswirkungen der übrigen Kriterien können hier nur schematisch an einfachen Beispielen skizziert werden. Ein Datenbankkonzept einer verteilten Sesam-Datenbank kann geprägt sein von den beim Anwender

- auszuführenden Funktionen (Bild 6):

Die Datenbanken einzelner Orte haben einen unterschiedlichen Aufbau. Die gesamte Datenstruktur wurde aufgeteilt (partitioned by structure).

- herzustellenden Produkten oder Dienstleistungen (Bild 7):

Bei Anwendung des Objekt-Kriteriums werden an einem Ort alle Funktionen ausgeführt, um beispielsweise Dienstleistungen für einen Landkreis auszuführen. Die Daten sind nicht der Struktur, sondern den Werten nach auf einzelne Orte verteilt (partitioned by value).

- geltenden Arbeitsabläufen (Phasen):

Das Datenbankkonzept spiegelt eine Mischung aus Funktions- und Objektorientierung dar. Dieser Fall wird wohl sehr häufig anzutreffen sein. Eine derartige Mischform kommt in Bild 8 zum Ausdruck: Objekt-Kriterium bei Filialen, Funktion zwischen Zentrale und Filiale.

- geltenden Kompetenzaufteilungen (Bild 8):

Das Rang-Kriterium kommt überall dort zur Anwendung, wo neben einer Zentrale eine Reihe von Filialen existiert.

Das geschilderte Datenbankkonzept einer verteilten Sesam-Datenbank zeichnet sich dadurch aus, daß man

- die Datenverteilung an die organisatorischen Gegebenheiten sowie an

- Änderungen der Organisationsstruktur anpassen kann und man

- gegenüber der lokalen Verarbeitung wenig technisches Zusatzwissen braucht.

Die Beschreibung des Datenbankkonzeptes erfolgt im geführten Dialog. Für Dokumentationszwecke kann man sich Database Directory und Attributkataloge ausdrucken lassen.

Design interner Speicherstrukturen

Beim Design des Datenbankkonzeptes modelliert man auf gedanklicher Ebene ein Spiegelbild der Unternehmens- oder Behördenbereiche, in denen eine verteilte Sesam-Datenbank zum Einsatz kommen soll. Im nächsten Schritt wird das Gedankenmodell auf die Hard- und Softwarekonfiguration umgesetzt. Hier steht eindeutig der als Designkriterium bereits erwähnte Sachmittelaspekt im Vordergrund.

Aus Datenbanksicht betrifft dies den Bereich der internen Speicherstrukturen verteilter Sesam-Datenbanken. Daraus resultieren Fragen der Art:

Sind die einzelnen Datenbanken so über das Netz verteilt, daß meistens lokal zugegriffen werden kann?

Sind Kopien von Datenbanken an einzelnen Orten zu halten, um die Performance oder Verfügbarkeit zu verbessern?

Muß eine Kopie an Änderungen im Original sofort oder in Periodischen Abständen angepaßt werden?

Hat die einzelne Datenbank optimale interne Strukturen?

Ist eindeutig geregelt, welche Person oder Dienststelle sich um die Installation der verteilten Datenbank (meist organisationsübergreifend) zu kümmern hat?

Technisch gesehen hat eine verteilte Datenbank folgende interne Speicherstruktur (Bild 9):

- Eine verteilte Datenbank besteht aus einem Database Directory und einzelnen Datenbanken.

- Das Database Directory (Verteilungsregeln) befindet sich an jedem Rechner, der auf die verteilte Datenbank zugreifen will.

- Eine einzelne lokale Datenbank hat den Sesam-typischen internen Aufbau mit Trennung von System- und Benutzerdaten, Sekundärindizes, Datenkomprimierung, Freiplatzverwaltung etc.

Aus der Vielzahl möglicher Architekturkonzepte wurde mit Sesam-DCN die eben beschriebene Lösung gewählt, da sie eine Reihe von Vorteilen aufweist: Die verteilte Datenbank wird mit einem Minimum an zusätzlichem Peripheriebedarf möglich. Rechnerübergreifende Synchronisationsmaßnahmen sind generell nicht nötig, es sei denn, es werden Datenbankkopien im Rechnerverbund gehalten.

Eine flexible interne Speicherstruktur erlaubt somit das Umverteilen der Daten bei geänderten Einsatzanforderungen. Bei Ausfall eines Rechners bleiben die Daten der anderen Rechner im Zugriff. Ferner geschieht die Datenbankadministration hauptsächlich vor Ort mit den Dienstprogrammen des Datenbanksystems.

Systemunterstützt kann auch die periodische Aktualisierung von nichtlokalen Datenbankkopien erfolgen. Sesam-DCN enthält ein Dienstprogramm (Sedi72R), welches die für eine Original-Datenbank protokollierten Änderungen in die nichtlokale Kopie einbringt. Damit erspart sich der Anwender Aufwendungen für Datenträgerversand oder den Transfer einer Protokolldatei per Leitung. Die Speicherstrukturen einer verteilten Sesam-Datenbank eröffnen auch einem lokal oder dezentral arbeitenden Anwender die verteilte Datenbankverarbeitung.

Die bisherigen Ausführungen zum Design der Anwenderprogramme, des Datenbankkonzeptes und der internen Speicherstrukturen zeigten auf, welche Kriterien während der Einführung der verteilten Datenbankverarbeitung zu beachten sind. Für einen bestmöglichen Einsatz von Sesam-DCN gilt es auch, die Abläufe während des Produktiveinsatzes von verteilten Datenbanken ins Auge zu fassen. Im Vordergrund steht dabei die Darstellung, um welche Komponenten Sesam-DCN den BS2000-Rechnerverbund ergänzt.

Da Anwenderprogramme transparent sind, also ein Datenbankzugriff ohne rechnernetzspezifische Angaben erfolgt, muß das Datenbanksystem die Steuerung der Zugriffswege übernehmen. Sesam und Sesam-DCN erledigen dies mittels eines Distributed Database Handler (verteilte Datenbankzugriffskomponente). Er setzt sich zusammen (vgl. Bild 10) aus:

SesRDA, -UTMR:

In das Anwenderprogramm oder die UTM-Anwendung zu bindender Konnektionsmodul

SesnetM:

Sesam-Network-Manager zur Verteilung der Datenbankzugriffe auf den richtigen BS2000-Rechner

SesnetR:

Sesam-Network-Receiver zu Koordination von Aufträgen anderer Rechner

Sesam:

Lokal arbeitender Database Handler.

Der Distributed Database Handler ist das Basiswerkzeug für den Einsatz der verteilten Datenbankverarbeitung. Er erlaubt das Design unterschiedlicher Einsatzformen. Die generellen Möglichkeiten werden nun umrissen.

Der Netz-Manager SesnetM befindet sich im Homerechner, also am Ort des Anwenderprogrammes. Er schickt den Datenbankzugriff mit Hilfe des BS2000 und von Transdata-Komponenten zum benötigten Rechner. Das Datenbanksystem braucht im Homerechner nicht installiert zu sein, wenn keine lokalen Datenbanken dort vorhanden sind. Als Rechnertypen sind Anlagen der Systeme 7.500 und 7.700 verwendbar.

SesnetR und Sesam müssen am Remote-Rechner, am Ort der benötigten nichtlokalen Datenbank, vorhanden sein. Als Betriebssystem wird BS2000, als Rechnertypen die Modelle 7.500 oder 7.700 benötigt. Ein Zugriff auf eine nichtlokale Datenbank fährt über SesnetM, SesnetR und Sesam. Ein lokaler Zugriff geht direkt an Sesam und die benötigte Datenbank. Die Verbindung zwischen SesnetM und SesnetR stellen Kommunikationsmethoden des BS2000 und des Transdata-Produktspektrums her.

SesnetM und SesnetR tauschen nur das Nötigste an Informationen aus, um die Parallelität der Verarbeitung und den Durchsatz bestmöglich zu gestalten. Dennoch ist bei nichtlokalem Zugriff mehr Kommunikationsaufwand nötig als bei rein lokaler Verarbeitung, wo nur rechnerinterne Kommunikation anfällt.

In Bild 10 ist eine einfache Form des Distributed Database Handler zu sehen. Er läßt sich bei verschiedensten Rechnerverbundkonfigurationen einsetzen. Als Konfigurationsgrundtypen gibt es die

- Multi-Home-Rechnerkopplung (Bild 10 und die

- Multi-Remote-Rechnerkopplung (Bild 12).

Eine Kombination dieser Typen ergibt die unterschiedlichsten Rechnerverbundformen (Beispiele: irreguläres Netz oder vollvermaschtes Netz).

Anwenderprogramme, Datenbankkonzept und Speicherstrukturen weisen dabei die beschriebenen Eigenschaften auf. Zusammen mit dem zugrundeliegenden Rechnerverbund gestatten sie eine anpassungsfähige DV-Organisation. Die Gesamtverfügbarkeit steigt, da einzelne DV-Anwendungen auf unterschiedlichen, auch autonom ablauffähigen Rechnern untergebracht sind.

Als zentrales Designproblem gilt es, die Kommunikation zwischen den Rechnern so "performant" wie möglich zu gestalten. Daraus resultieren Anforderungen wie

- die einzelnen Datenbanken einer verteilten Sesam-Datenbank dort zu installieren, wo diese am meisten benötigt werden,

- die Hard- und Kommunikationssoftware mit den höchsten Übertragungsraten zu wählen,

- den direkten Weg zwischen zwei Rechnern, am besten eine Channel to Channel-Verbindung zu wählen.