1. In welche generelle Richtungen wird sich die Datenbanktechnologie in den nächsten fünf Jahren entwickeln?

2. Wie könnte aus heutiger Sicht für den Anwender eine vernünftige Strategie für die Migration zu künftigen Datenbanksystemen (hinsichtlich relationaler Konzepte, verteilter DBs) aussehen?

3. Das heutige Kosten-Leistungs-Verhältnis der Hardware ermöglicht zunehmend eine Verteilung auf Rechnerkapazitäten, die im Verbund miteinander stehen. Als Problem bleibt die Positionierung der Daten. Welche Varianten sind in den nächsten Jahren denkbar?

4. Anwender klagen bei heutigen verteilten DB-Systemen neben Konsistenzproblemen vor allem über mangelhafte Performance. Welche Lösungen befinden sich für die nächsten Jahre in der Pipeline, um den Flaschenhals der Datenübertragung abzubauen?

Michael Bauer, Geschäftsführer der Innova Forum GmbH, in Randolfszell

Zu Frage 1:

Ich erwarte eine Weiterentwicklung der Datenbank-Technologie in den nächsten Jahren in vier Bereichen:

Veränderung des Einsatzspektrums und der Anforderung an die DB-Systeme.

Neben dem bisherigen Einsatz für operative Aufgaben - das heißt regelmäßige Verarbeitung im Batch- und Online-Betrieb - werden Datenbanken zunehmend für flexible, auskunfts-orientierte Informationssysteme benötigt Weiterhin finden Datenbanken ein neues Einsatzgebiet in der Verwaltung umfangreicher Text- und Dokumentationsbestände, die im Rahmen der fortschreitenden Automatisierung des Büros anfallen Für dieses so geänderte Anforderungsprofil werden relationale Datenbanken die geeignete Lösung bieten.

Bei dieser zunehmenden Auswirkung und Integration der Informationsverarbeitung werden der Informationsplanung sowie der systematischen Datenanalyse und -modellierung eine entscheidende Rolle zukommen.

Verstärkte Entwicklung DB-gestützter Software und deren Integration

Hierzu gehören neben den heute vorhandenen Query- und Reportfunktionen:

- Mächtige, endbenutzer-geeignete Auswertungssysteme mit Komponenten künstlicher Intelligenz wie zum Beispiel natürliche Sprache, Spracherkennung und automatische Pfadanalyse;

- Sprachen der vierten Generation, die die Anwendungsentwicklung spürbar verbessern. Heute schon angebotene Produkte wie ADS, Ideal, Mantis oder Natural sind erst der Anfang und können noch erheblich weiterentwickelt werden. Besonders wichtig ist eine aktive Zusammenarbeit mit einem Data Dictionary, die heute noch unzureichend ist;

- Endbenutzersysteme für Planung, Analysen und Entscheidungsunterstützung auf Basis einer leistungsfähigen Datenbank;

- Dokumenten-Verwaltung, -Recherche und -Verteilung im Zusammenwirken mit Bürokommunikationssystemen.

Eine zentrale Rolle zur Koordinierung der gesamten Informationsverarbeitung wird dabei einem Data Dictionary zufallen, das mit allen Werkzeugen zusammenarbeiten können soll. Die Leistungsfähigkeit aller dieser Werkzeuge ist wiederum abhängig von der Mächtigkeit der zugrundeliegenden DB-Systeme. Dies wird besonders von relationalen Datenbanken geboten.

Unterstützung der verteilten Datenverarbeitung

Mit der weitergehenden Verbesserung des Preis/Leistungs-Verhältnisses der Hardware wird die Rechnerkapazität sowohl regional als auch funktional stärker verteilt werden. Letzteres wird besonders im Bereich der Büroautomation ausgeprägt sein. Da hierfür die Verfügbarkeit und Integrität des Gesamtbestandes an Daten gewährleistet sein muß, werden verteilte DB-Systeme entwickelt beziehungsweise verbessert werden. Wesentliche Aspekte dabei: globales Data Dictionary, automatische Redundanzpflege, dynamische Umverteilung, Datenunabhängigkeit.

Warum relationale Datenbanken eine günstige Basis für verteilte Datenbanksysteme bilden, ergibt sich aus der Antwort auf die vierte Frage.

Verbesserung der Performance de Datenbank

Heutige Anwender spüren zwei wesentliche Probleme, die den DB-Einsatz behindern. Das eine ist die Handhabungsseite, das andere die Performance. Relationale Datenbanken können zwar die Handhabung wesentlich erleichtern, aber sie verschärfen zugleich das Performance-Problem.

Entspannung ist zu erwarten durch die regelmäßige Verbesserung des Preis/Leistungs-Verhältnisses der Hardware und durch neue Hardware-Einrichtungen wie zum Beispiel Parallel File Processors, intelligente Disk-Controller oder Halbleiterspeicher.

Zu Frage 2:

Aus der Beantwortung der ersten Frage läßt sich erkennen, daß die Zukunft sicherlich den relationalen Datenbanken gehört - allerdings noch nicht die Gegenwart.

Ein konsequent relationales DBMS wie DB2 benötigt erheblich mehr Ressourcen als ein herkömmliches. Für hochbelastbare Transaktionssysteme oder Massenverarbeitungen im Batch, die heute bereits die Grenze der Rechnerkapazität erreichen ist ein solches DBMS noch nicht ein setzbar. Deshalb liegt sein Einsatz schwerpunkt heute noch bei abfrageorientierten Informationssystemen, die keine so intensive Nutzung aufweisen.

Doch das wird sich ändern: Die regelmäßige Verbesserung der Leistungsfähigkeit der Hardware läßt erwarten, daß innerhalb der nächsten fünf Jahre genügend Hardware Leistung zu vertretbarem Preis verfügbar sein wird. Dann wird der Resourcen-Bedarf kein Thema mehr sein, und die Vorteile relational DB-Systeme - leichte Implementierung, Flexibilität, hohes Maße an (...) tenunabhängigkeit - überwiegen.

Anwender konventioneller I Systeme wie zum Beispiel IMS m müssen sich deshalb schon heute mit Frage einer späteren Konvertiert auseinandersetzen. Welche Strategien kann man hierfür einschlagen? Eine Strategie besteht darin, die Anwendungsprogramme so DB-unabhängig wie möglich zu entwickeln; eine andere darin, auf Umsetzprogramme - sogenannte "Transparency Features" - zu hoffen.

Bei vielen Unternehmen wird es bereits mit Erfolg praktiziert, die DB-spezifischen Befehle in einem oder wenigen Zugriffsmodulen zu konzentrieren. Eine Umstellung dieser Module ist dann zu vertretbaren Kosten möglich. Dieses Vorgehen ist besonders geeignet, wenn man mit konventionellen Programmiersprachen arbeitet.

Statt dessen könnte man auch mit Sprachen der vierten Generation eine DB-Unabhängigkeit erzielen; allerdings ist die DB-Portabilität bei den heutigen Produkten noch mangelhaft. Bei einigen Systemen zur Anwendungsentwicklung wie zum Beispiel Mantis, Natural oder UFO ist zwar eine gewisse DB-Portabilität bereits realisiert, doch müssen wir in dieser Hinsicht noch verstärkte Anstrengungen der Anbieter fordern.

Auch mit der KDBS-Schnittstelle der öffentlichen Verwaltung kann. man DB-unabhängige Programme er stellen. Doch erscheint mir die Sprachform der Schnittstelle, die ein zelsatz-orientiert und prozedural ist, wenig zukunftsträchtig. Wer noch nicht fest mit einem DBMS "verheiratet" ist, kann auch - statt auf die Zukunft zu warten - ein schon heute praktikables DBMS mit weitgehend relationalen Eigenschaften einsetzen zum Beispiel Adabas, Datacom oder Sesam.

Eine interessante Synthese zweier Konzepte stellt das IDMS/R dar, dessen relationale Komponente in dem Maße benutzt werden kann, wie es vom Hardware-Verbrauch und die Perfomance vertretbar ist. Es ermöglicht also ein "Hinübergleiten" von einer Codasyl- zu einer relationalen Datenbank.

Fazit: In den nächsten Jahren werden relationale Datenbanken für alle Anwendungen - auch operative attraktiv werden. Alle Anwender sind gut beraten, sich den Weg dahin nicht mit einer festen Bindung an ein konventionelles DBMS zu verbauen.

Zu Frage 3:

Bei verteilter Verarbeitung sollten die Daten jeweils bei dem Rechner gespeichert sein, auf dem die Programme ablaufen, die darauf zugreifen müssen. Das klingt theoretisch gut, ist aber unrealistisch. Denn besonders zentrale Stammdatenbestände werden oft von mehreren Rechnern gleichzeitig benötigt.

Bei redundanzfreier Verteilung der Daten müssen deshalb häufiger "remote" DB-Zugriffe durchgeführt werden, was heute noch mit einem hohen Zeitaufwand verbunden ist. Werden die Daten dagegen dupliziert, so daß an jedem Rechner alle benötigten Daten gespeichert sind, entsteht das Problem der gleichmäßigen Aktualität. Besonders deutlich wird das Problem bei PCs wo keiner mehr weiß, welche Daten in welchem Aktualitätsgrad sich auf welchem PC befinden.

Die gleichzeitige Änderung aller Kopien eines Datensatzes in allen Datenbanken ist zwar technisch möglich, aber sehr aufwendig. Zu dem mangelt es den heutigen DB-Systemen noch an der Funktion zur automatischen Redundanzführung.

Als Konsequenz ergibt sich, daß fallweise zu entscheiden ist, welches der beiden Verteilungskonzepte - oder eine entsprechende Kombination daraus - für welche Daten angewendet werden soll.

Für die Zukunft sehe ich keine neuen Möglichkeiten, sondern nur eine Verschiebung in Richtung redundanzfreier verteilter Datenbanken in dem Maße, wie die Übertragungsmedien schneller und billiger werden. Eine Notwendigkeit für verteilte Datenbanken wird deshalb ein globales Directory, das den Verteilungsprozeß steuert, überwacht und gegebenenfalls optimiert.

Zu Frage 4:

Jeder Zugriff auf eine entfernte Datenbank kostet heute zusätzlich zirka 70 000 Instruktionen und zwei Nachrichtenübertragungen. Die CPU-Zeit kann man noch verschmerzen, aber die Zeit für die Datenübertragung schlägt von auf die Antwortzeit am Terminal durch. Wenn es dann noch für eine Aufgabe notwendig ist, eine Vielzahl von Sätzen von einer entfernten Datenbank zu holen und durchzuarbeiten, wird der Aufwand unzumutbar.

Wir können einerseits erwarten, iß der Zeitaufwand für die Nachrichtenübertragung durch neue Übertragungstechniken und neue Postdienste sinken wird. Wann und in welchem Umfang vermag ich aber nicht vorherzusagen. Andererseits können wir durch den Einsatz relationaler DB-Systeme den Nachrichtentransfer zwischen verteilten Datenbanken minimieren. Denn die Mächtigkeit der relationalen Algebra ermöglicht es, jeden Informationswunsch in einer einzigen Anweisung zu formulieren. Ebenso erleichtert das relationale Konzept eine Verknüpfung getrennter Datenbestände miteinander.

Dr. Joachim Niedereichholz; Professor am Institut für Wirtschaftsinformatik der Johann Wolfgang Goethe Universität, Frankfurt

Zu Frage 1:

Im Bereich der Datenbanken werden generell die relationalen Systeme und Entwicklungen tonangebend sein. Es ist unverkennbar, daß die Datenbankszene seit den Ankündigungen VON SQL/DS und DB2 durch IBM in den Jahren 1981 beziehungsweise 1983 in ein zweites Stadium eingetreten ist. Das erste Stadium, das bereits Ende der 60er Jahre begann, war durch den Einsatz von Datenbanksystemen vom hierarchischen, netzwerkartigen und invertierenden Typ gekennzeichnet. Einige Systeme verfolgten bereits relationale oder quasi-relationale Prinzipien (zum Beispiel Adabas, Datacom, Sesam).

Das zweite Stadium ist durch die Ankündigung und den beginnenden Einsatz der relationalen Datenbankprodukte SQL/DS und DB2 von IBM gekennzeichnet. Wenn auch diese Systeme nicht die ersten ihrer Art am Markt waren, so zeigt doch die Historie, daß eine bestimmte Ära erst eingeleitet wird, wenn IBM die sie bestimmenden Konzepte forciert anbietet. Dies zeigen viele Entwicklungen, die oft mit einprägsamen Bezeichnungen auf den Markt zukamen wie beispielsweise VS, PC oder LAN.

Die Frage nach der künftigen Datenbanktechnologie kann zum Beispiel anhand der wahrscheinlichen Richtungen der DB2-Entwicklung aufgerollt werden, wobei bekannt ist, daß es Konkurrenzprodukte gibt, die vergleichbare Entwicklungen oft früher beinhalteten.

Die üblichen DB-Verbesserungen im Rahmen der Softwarewartung wirken nicht spektakulär und sind relativ genau vorauszusehen. Als Beispiel, was als ,.übliche" Verbesserung gelten kann, sollen einige wichtige Erweiterungen von QMF Release 2 dienen. Dazu zählen die Verbesserungen bei der Erstellung von Berichten, ein neuer Unterbefehl "Draw" für SQL, die Angabe des Druckers sowie die Ausführung von QMF-Prozeduren im Stapelbetrieb.

Auch ein Einblick in die Verbesserungen und Erweiterungen von SQL/DS für VSE und VM im Rahmen des angekündigten Release 3 ist interessant. Als wesentliche Punkte sind hier zu nennen die Aufzeichnung aller verbrauchten System-Ressourcen mit einer SQL/DS Accounting Facility, die Reorganisation der Katalog-Indizes mit Hilfe eines neuen Dienstprogrammes sowie die Access Module Preallocation, um die pro DBSPACE möglichen 255 Access-Module-Tabellen im voraus anzulegen.

Unter weitergehenden Verbesserungen werden im allgemeinen drastische Veränderungen verstanden, die zum Beispiel DB2 auf das Leistungsniveau von IMS Fast Path Adabas oder Datacom hochheben. Derartige Bemühungen und Ergebnisse sind erst gegen Ende der 80er Jahre zu erwarten, gibt doch IBM heute kund, daß man in punkto DB2 grundsätzlich "quality in the perspective of complexity" sehen müsse.

Ein relationales System wie DB2 ist prädestiniert, um in verteilter DB-Umgebung eingesetzt zu werden. Ein laufendes Folgeprojekt von System R zu System R* weist auch den Weg, daß Entwicklungen angelaufen sind. Folgende Richtungen können sie einschlagen:

1. Stärkere Einbindung des PC für DB2-File-Transfer-Funktionen.

2. In einem späteren Stadium können Down-Loading-Möglichkeiten für DB2-Tabellen in PCs mit beschränkten DB2-Fähigkeiten folgen.

3. Die Verteilung von DB2-Datenbanken auf Rechner im SNA-Verbund kann sowohl im duplizierten und partitionierten Modus als auch in beiden Modi erwartet werden.

Dies kann jedoch erst erfolgen, wenn Katalogverbesserungen eingetreten sind und die Leistung im nichtverteilten Sinn befriedigend angehoben wurde.

Die Koexistenz mit IMS wird noch auf lange Zeit bestehen bleiben, dl kein Mittel (Bridge, Migrationshilfe) in Sicht ist oder nur andeutungsweise diskutiert wird, das operationale IMS-Datenbanken (leicht) in operationale und auswertungsorientierte DB2-Datenbanken überführen ließe.

Zu Frage 2:

Wenn ein älteres System eingesetzt wird (hierarchisch, netzwerkartig), sollte man den Übergang in die relationale Welt genau untersuchen planen und dabei bedenken, daß überall nur mit Wasser gekocht wird.

Meist wird der sofortige Übergang auf ein anderes System nicht not wendig sein; zumal er große Instabilität bei den DB-Anwendungen mit sich bringt.

Zu einigen Netzwerk-Systemen kann man die Fähigkeit relationale Sicht hinzufügen; dies ist sicher meist sinnvoller als ein DBS-Wechsel zu einem völlig anderen System. An; gemein gilt ja, daß etablierte DB-Anwendungen ab einer gewissen Größenordnung kaum noch abzulösen sind.

Zusätzliche Sprachschnittstellen nach Konzepten der 4. Generation die auch von Herstellern ohne eigenes DBS-Produkt angeboten werden, können die Produktivität nichtrelationaler Datenbanken erhöhen.

Eine duale DBS-Strategie, das heißt das Betreiben eines relationalen und eines nicht-relationalen DBS kann durchaus überlegt werden - hinsichtlich Leistung, Preis und Integrität. Eine allgemeine, aussagekräftige Empfehlung zur Migration gibt es jedoch nicht.

Zu Frage 3:

Es empfiehlt sich eine vorsichtige Vorgehensweise, da Totallösungen organisatorisch oft gar nicht notwendig beziehungsweise möglich sind.

Eine Verteilung der DV-Leistung und Datenhaltung auf mehrere Rechnerkapazitäten bringt größere Organisationsänderungen mit sich. Zur Positionierung der Daten sind Replikation und Partitionierung als grundsätzliche Möglichkeiten anwendbar.

Eine Partitionierung schränkt die Verfügbarkeit ein, da Teile der DB ausfallen können. Andererseits ist die Verfügbarkeit höher als bei zentralen DBS, da auch bei Nichtverfügbarkeit mit Teilen der DB gearbeitet werden kann.

Für eine Replikation sprechen verbesserte Verfügbarkeit und Flexibilität der Datennutzung. Eine vollständige Replikation kann andererseits unpraktisch und zu aufwendig für die Volumina kommerzieller Anwendungsumgebungen sein. Aus diesem Grund sollten beide Prinzipien miteinander verbunden werden.

Aus heutiger Sicht empfiehlt es sich als Strategie nur wichtige Daten repliziert zu halten, zum Beispiel um in Filialen über Preislisten up-to-date zu verfügen.

Zu Frage 4:

Mangelhafte Performance entsteht im wesentlichen durch das Update-Problem. Schlecht verteilte Datenbankschemata können sogar mehr Datenbewegung verursachen als eine nicht verteilte Datenbank.

Für das Transaktionsmanagement müssen die Algorithmen noch effizienter werden, zum Beispiel durch die Optimierung anhand alternativer Suchpläne .

Das Leitungs- und Leitungskostenproblem beim Transport umfangreicher DB-Updates wird auf Jahre hinaus noch nicht zufriedenstellend gelöst werden.

Bei der Synchronisation sollte keine strenge Konsistenz aller Kopien der Daten gefordert werden, da sie dann entsprechend teuer und aufwendig ausfällt. In vielen kommerziellen Anwendungen kann man sich mit einer schwächeren Konsistenz zufrieden geben: Das heißt, daß ein anfangs tagesmäßiges Kopieren der notwendigen Datenupdates aus der Zentrale zu den replizierten/partitionierten Daten vor Ort ausreichend ist. Mehr muß vom Problem der (zum Beispiel Buchungssystem) genau begründet werden.

Paul Wey, Mitarbeiter im zentralen Beratungsbereich des EDV Studio Ploenzke, Wiesbaden

Zu Frage 1:

Eine datenbanktechnologische Revolution wird trotz wesentlicher Fortschritte im Bereich der Computertechnologie (Non-von-Neumann-Rechner, Mehrprozessorarchitektur, Rechner der 5. Generation) in den nächsten fünf Jahren wahrscheinlich nicht stattfinden.

Die Entwicklung der heute für einen Einsatz im administrativen und betriebswirtschaftlichen Bereich verfügbaren Datenbanksysteme verläuft evolutionär und ist geprägt durch:

- Verbesserung und Funktionserweiterung bewährter Systeme, so daß diese sich in ihrem Leistungsumfang immer mehr angleichen werden.

- Verbreitung relationalorientierter Systeme und ihre noch notwendige Funktionserweiterung im Hinblick auf Erhaltung der strukturellen Integrität.

- Wachsende Bedeutung von Produkten des Systemumfeldes (Sprachen der 4. Generation, Endbenutzersprachen, IDV, Mikro-Mainframe-Link, Data Dictionaries) und deren Integration beziehungsweise enge Anbindung an DB-Systeme.

Die Entwicklung von Datenbanksystemen für "nicht-kommerzielle" sogenannte Non-Standard-Anwendungen (wissenschaftliche Anwendungen, Grafik-, Bild-, Sprachverarbeitung, CAD/CAM, Expertensysteme) steht erst am Anfang. Diesen Anwendungen ist gemeinsam, daß sie wesentlich höhere Anforderungen an Semantik und Integritätsbedingungen der Datenmodelle stellen. Hier sind entweder umfangreiche Erweiterungen verfügbarer kommerzieller Systeme notwendig oder Neuentwicklungen erforderlich, wobei sowohl die Erfahrungen mit den traditionellen Systemen als auch neue Erkenntnisse aus der Theorie der DB-Systeme berücksichtigt werden.

Zu Frage 2:

Die relational-orientierten Systeme werden aufgrund ihrer Eignung für weite Bereiche zukünftiger Informationsverarbeitung sicherlich an Bedeutung gewinnen. Andererseits gibt es weltweit eine Vielzahl von Anwendungen, die zufriedenstellend oder sogar sehr gut auf der Basis traditioneller Systeme (Netzwerk hierarchisch) arbeiten. Drei Konzepte lassen sich für eine Zusammenführung der beiden Entwicklungen unterscheiden:

- Koexistenz verschiedener DB-Systeme mit der Möglichkeit, Daten aus dem "klassischen System" zu extrahieren (zum Beispiel DB2 und IMS).

- Erweiterung des klassischen Systems" um eine integrierte relationale Komponente (zum Beispiel IDMS/R).

-- Einsatz einer Datenbanksprache mit Datenmanipulationsmöglichkeiten nach dem Relationenmodell auf der Basis eines klassischen Systems (zum Beispiel Ankündigung für UDS, Natural mit DL /1).

Für die Software-Entwicklung bietet in diesem Zusammenhang die Entwicklung eines unternehmensspezifischen DB-Systems unabhängigen Datenmodells eine Reihe von Vorteilen. Die Daten werden ausschließlich aus fachlicher Sicht strukturiert, DV-technische Aspekte bleiben außer acht.

Die Beschreibung der Datenstruktur (konzeptionelles Schema, Informationsstruktur) ist implementierungsunabhängig. Unter Beachtung bestimmter Regeln und Entwurfsgrundsätze läßt sich daraus eine systemspezifische Datenstruktur und damit das Systemdesign ableiten, sei es nun relational- oder netzwerk-orientiert.

Zu Fragen 3 und 4:

Bei den Konzepten zur verteilten Datenhaltung lassen sich grundsätzlich drei Möglichkeiten unterscheiden:

- Bei der Partitionierung ist der Datenbestand redundanzfrei über alle beteiligten Rechner verteilt.

- Bei der Replikation ist der gesamte Datenbestand redundant auf jedem Rechner vorhanden.

- Bei der Partiellen Replikation sind Teilmengen des Datenbestandes redundant auf mehreren Rechnern vorhanden, es sind jedoch nicht alle Daten auf jedem Rechner gespeichert.

Von einem verteilten Datenbanksystem kann eigentlich nur dann gesprochen werden, wenn die Benutzer beziehungsweise Anwendungsprogramme von der Kenntnis über die tatsächliche Verteilung der Daten befreit sind. Das verteilte System erscheint wie ein zentrales Datenbanksystem. Dies setzt voraus, daß die Informationen über die Verteilung in speziellen Systemkatalogen verwaltet werden, die wiederum nach den oben genannten Möglichkeiten organisiert sein können.

Probleme bietet die Erhaltung konsistenter Datenbankzustände und da mit verbunden die Synchronisation konkurrierender Zugriffe. Dies er fordert umfangreiche Kommunikation aller Rechner untereinander und führt sowohl zu höheren Kommunikationskosten als auch zur Verlängerung der Antwortzeiten.

Entscheidenden Einfluß au Leistung und Kosten des verteilter Datenbanksystems hat somit die Wahl der Datenverteilung, die sich aus den Anwendungserfordernissen ableitet. Hierzu ist eine sorgfältige Analyse der Daten und Anwendungen unter den Gesichtspunkten Zugriffshäufigkeit, Änderungsintensität und Lokalität erforderlich.

Für eine Vielzahl von Anwendungen wird wohl eine partielle Replikation der Datenbestände und vollständige Replikation der Systemkataloge sinnvoll sein. Allgemein bieten sich Daten, die geringen Änderungen unterworfen sind, für eine Replikation und Daten mit hoher Zugriffslokalität für eine Partitionierung an.

Besondere Bedeutung bei verteilten Datenbanksystemen erlangen Hilfsmittel zur Leistungsmessung, um die Effizienz der Verteilung von Daten und Verarbeitungsleistung beurteilen zu können. Systeme der Zukunft könnten solche Informationen verwenden, um sich selbst zu optimieren und damit eine dynamische Verteilung der Last über die Rechner zu ermöglichen, Dies setzt jedoch voraus, daß die heute meist lose, über herkömmliche Nachrichtenleitungen realisierte Rechnerkopplung durch eine enge, schnelle Rechner-zu-Rechner-Verbindung abgelöst wird.