DE69422657T2

DE69422657T2 - Föderalisierte Architektur und System zur Informationsverwaltung

Info

Publication number: DE69422657T2
Application number: DE69422657T
Authority: DE
Inventors: Son K. Dao; Nader Ebeid
Original assignee: Hughes Electronics Corp
Current assignee: DirecTV Group Inc
Priority date: 1993-05-20
Filing date: 1994-05-19
Publication date: 2000-08-31
Anticipated expiration: 2014-05-20
Also published as: CA2123822A1; EP0625756B1; CA2123822C; US5596744A; EP0625756A1; DE69422657D1; JPH07141399A

Description

Diese Erfindung betrifft allgemein eine Architektur und ein Verfahren, das bei Computerdatennetzwerken nützlich ist, und genauer gesagt eine verzweigte (globale) Architektur sowie System, die erweiterbar und flexibel sind, um Benutzer mit transparenten, integrierten Datenbankmanagementsystemen (DMBS) zu versorgen, die über ein entferntes Netzwerk verteilt sind.
Während des letzten Jahrzehnts haben große Organisationen und Umgebungen anfangs heterogene und miteinander inkompatible Informationssysteme auf eine unkoordinierte Weise verwendet; unabhängig voneinander und ohne Berücksichtigung, daß sie eines Tages miteinander integriert werden müßten. Als ein Ergebnis davon sind Informationssysteme komplexer und komplexer geworden und sind durch verschiedene Arten von Heterogenität gekennzeichnet. Z. B. können unterschiedliche Modelle von Datenbankmanagementsystemen (DBMS) verwendet werden, um Daten zu repräsentieren, wie etwa das hierarchische, das Netzwerk- und das relationale Modell. Neben Datenbanken speichern viele Softwaresysteme (wie etwa Tabellenkalkulationen, Multimedia-Datenbanken und Wissensbasen) andere Arten von Daten, jeweils mit ihrem eigenen Datenmodell. Ferner können dieselben Daten von verschiedenen Benutzern mit unterschiedlichen Abstraktionsgraden betrachtet werden. Wegen solcher Unterschiede finden es Benutzer schwierig, die Bedeutung all der Datenarten zu verstehen, die ihnen angeboten werden. Analysten, Bediener und die gegenwärtige Datenverarbeitungstechnologie sind nicht in der Lage, diese diverse Information mit erheblicher Menge zu organisieren, zu verarbeiten und intelligent zu analysieren. Diese Ineffizienz führt häufig zu verspäteten Berichten an Entscheidungsträger, verpaßten Mitteilungen und nicht ausgewerteten Daten.
Eines der Bedürfnisse besteht im Zugang zu und im Managen von existierenden und neuen geowissenschaftlichen Daten. Diese Daten werden auf einer Anzahl von unterschiedlichen DBMSs und Bilddateien gesammelt und zum Zwecke der Beobachtung von globalen Erdvorgängen ausgewertet. Die erdwissenschaftlichen Daten werden von unterschiedlichen Informationssystemen gesammelt, wozu Daten gehören, die betreffen: das Klima, das Land, den Ozean usw., die jeweils aus relationalen Datenbanken, Bildern und Dateien bestehen. Diese Systeme wurden unabhängig voneinander entworfen und arbeiten auf vollständig unterschiedliche Arten bezüglich der Art der Speicherung und des Zugangs zu Daten. Ferner sind sie auf unterschiedliche Hardwareplattformen zugeschnitten. Folglich müssen die Benutzer zwecks eines Zugangs zu den Daten erlernen, wie unterschiedliche Systeme abgefragt werden können. Dies vergrößert die Ausbildungskosten und reduziert die Produktivität der Benutzer. Ferner hat die Mehrzahl der Benutzer nicht das Computerwissen, das notwendig ist, um die unterschiedlichen individuellen Systeme innerhalb einer kurzen Zeit zu erlernen, was sie davon abhält, auf verstreute Daten zuzugreifen und in einigen Fällen sogar vom Wissen, welche Daten überhaupt für sie zur Verwendung bereitgehalten werden.
Die gleichen Probleme treten bei der Anwendung des computerintegrierten Manufacturing (CIM) auf. CIM stellt ein sehr komplexes Netzwerk von physikalischen Aktivitäten dar, von Entscheidungsprozessen und Informationsflüssen. Die meisten Herstellungsbetriebe besitzen unabhängig voneinander entworfene und verteilte Informationsbasen. In einer solchen Umgebung kann eine Verbesserung der Arbeitsproduktivität erreicht werden, indem ein kurzer Zugriff zu allen notwendigen lokalen oder verteilten Daten ermöglicht wird. Den gegenwärtigen CIM-Systemen fehlt eine verteilte, d. h. globale Datenbank, die Information enthält, die für alle Phasen der Herstellung notwendig ist, d. h. für das Design, die Verarbeitung, die Montage und die Prüfung. Normalerweise werden Herstellungsprozesse unabhängig von den anderen Phasen behandelt. Dies ist in dem Sinne unerwünscht, daß Daten oder Kenntnisse von einem Verfahren nicht zur Verwendung von einem anderen erhältlich sind. Es besteht die Notwendigkeit, die Daten zu integrieren, derart, daß sie global für die Benutzer und Verfahren eines CIM-Systems zugänglich sind.
Folglich besteht ein dringendes Bedürfnis, diese verteilten Daten zu integrieren und einen gleichförmigen Zugriff zu den Daten bereitzustellen, die Integrität der Daten zu wahren, und ihren Zugang und ihre Nutzung zu kontrollieren. Anstatt von den Benutzern zu verlangen, daß diese eine Vielzahl von Schnittstellen erlernen, um zu unterschiedlichen Datenbanken Zugang zu erhalten, ist es bevorzugt, daß eine einzige Schnittstelle bereitgestellt wird, die Zugang zu jedem der DBMSs ermöglicht und Abfragen unterstützt, die sich auf Daten beziehen, die von mehr als einem Informationssystem gemanagt werden.
Die vergangene und gegenwärtige Forschung und Entwicklung bei verteilten Datenbanken erlaubt einen integrierten Zugang, indem eine homogene Ebene über die darunterliegenden Informationssysteme (UISs) bereitgestellt wird. Herkömmliche Ansätze zur Unterstützung dieser Ebene zielen auf die Definition einer einzigen gleichförmigen Datenbanksprache und eines Datenmodells, das mit allen Eigenschaften der UISs zurechtkommt. Die beiden Hauptansätze sind bekannt als Sichtintegration und als Mehrdatenbank-Sprache.
Der Sichtintegrationsansatz schlägt die Verwendung eines relationalen, eines objektorientierten (OO) oder eines logischen Modells sowohl zur Definition von Ansichten (virtuell oder als selektive Ansicht) der Schemata von mehr als einer Zieldatenbank als auch zum Formulieren von Abfragen gegenüber diesen Ansichten vor. Der Sichtintegrationsansatz ist ein Mechanismus zum Vergleichmäßigen der Schema-Inkompabilitäten der UISs. In diesem Zusammenhang werden alle UISs in äquivalente Schemata in dem standardmäßigen, relationalen OO- oder logischen Datenmodell konvertiert. Die Auswahl des gleichförmigen Datenmodells basiert auf seiner Ausdrucksfähigkeit, seiner Darstellungskraft und auf seiner unterstützten Umgebung. Dieses Verfahren ist aus Sicht des Benutzers sehr leistungsfähig. Es isoliert den Benutzer vom Design und den Veränderungen des darunterliegenden Informationsmanagementsystems (IMS). Somit erlaubt es dem Benutzer, mehr Zeit in einer Anwendungsumgebung zuzubringen. Jedoch ist der Sichtintegrationsansatz nur begrenzt anwendbar (niedriger Grad von Heterogenität), da es viele Situationen gibt, in denen die Semantik der Daten stark von der Weise abhängt, in der die Anwendungen sie manipulieren, was nur teilweise durch das Schema ausgedrückt ist. Viele gegenwärtige Anwendungen auf Gebieten, auf denen herkömmliche DBMSs nicht verwendbar sind, fallen in diesen Bereich (Multimedia- Anwendungen, die Text, Grafik und Bilder umfassen, sind typische Beispiele). Ferner gibt es keine erhältlichen Tools für den halbautomatischen Aufbau und die Wartung der gleichförmigen Ansicht, was für den Erfolg dieses Verfahrens unbedingt notwendig ist.
Bei dem Ansatz der Mehrdatenbank-Sprache muß ein Benutzer oder eine Anwendung den Inhalt jedes UIS verstehen, um Zugang zu der geteilten Information zu erhalten und um Konflikte von Fakten in einer Weise zu lösen, die für jede Anwendung speziell ist. Es gibt kein globales Schema, um Hilfe bezüglich der Meta- Daten zu erhalten. Die Einfachheit der Wartung und die Möglich keit, mit inkonsistenten Datenbanken zu arbeiten, machen diesen Ansatz sehr attraktiv. Der hauptsächliche Nachteil dieses Ansatzes besteht darin, daß die Last des Verständnisses der darunterliegenden IMSs auf dem Benutzer lastet. Demnach gibt es einen Kompromiß zwischen diesem Ansatz der Mehrdatenbank- Sprache und dem oben diskutierten Ansatz der Sichtintegration. Diese Erfindung adressiert die Nachteile, die mit den beiden oben beschriebenen Ansätzen verbunden sind.
Aus den Proceedings der IEEE, Band 75, Nr. 5, Mai 1987, New York, Seiten 695-705, M. Templeton et al.: "Mermaid - A Front-End to Distributed Heterogeneous Databases" ist ein verbessertes Computerdatennetzwerk bekannt, das ein Kommunikationsmedium besitzt, das eine Mehrzahl von Datenbanken, die Daten enthalten, gemeinsam mit einer Mehrzahl von Benutzern verbindet, von denen jeder eine globale Datenanfrage für den Zugang und das Abrufen von Daten aus den Datenbanken gemäß einem einzigen Abfrageprotokoll erzeugen kann, wobei das Netzwerk eine global integrierte Datenabfrage-Controller-Architektur zur Steuerung und Zuordnung der Übertragung der von dem Benutzer erzeugten globalen Datenanfrage zu einzelnen der Mehrzahl von Datenbanken und zum Empfang der angeforderten und von den Datenbanken erhaltenen Daten aufweist, und zum Integrieren in eine einzige Antwort und zum Übertragen der integrierten einzigen Antwort an den anfordernden Benutzer. Das System erlaubt es dem Benutzer, von vielfachen Datenbanken, die unter verschiedenen relationalen DBMSs, die auf unterschiedlichen Maschinen laufen, Daten mit einer gemeinsamen Sprache zu manipulieren, entweder ARIEL oder SQL. Eine Mehrzahl von lokalen Datenbanken DBMSs wird mit einem Ethernet verbunden, wobei jede der DBMSs individuell über einen DBMS-Treiber zugänglich ist, der einen Controller und einen Übersetzer aufweist, der eine in dem Ethernet verwendete, verteilte Zwischensprache (DIL) in die DBMS- Abfragesprache übersetzt.
Jeder Benutzer ist mit dem Ethernet über eine Benutzerschnittstelle verbunden, die einen ARIEL- oder SQL-Parser und einen Übersetzer aufweist, der DIL erzeugt. Ein Verteiler, der einen Optimierer und einen Controller enthält, ist zur Verarbeitung einer gültigen Anfrage vorgesehen, die von einem Benutzer erhalten wird, und zum Planen der Ausführung. Der Optimierer kann eine DIL-Anfrage in verschiedene Unteranfragen aufteilen, wenn der Controller diese zu einem oder zu mehreren von DBMS-Treibern zur Ausführung sendet. Der Controller wartet dann auf Antworten von den DBMS-Treibern. Sämtliche Information über das Schema, die Datenbanken, die Benutzer, die Host-Computer und das Netzwerk ist in einem DD/D (Datenwörterbuch/Wörterbuch) enthalten, das in einer Datenbank gespeichert ist und worauf über einen speziellen Treiber zugegriffen wird. Insbesondere enthält das DD/D Daten, die die physikalischen Charakteristika, sowohl der Daten in den lokalen Datenbanken als auch des Systems, enthalten als auch die Leistungscharakteristik des Netwerkes, das die verschiedenen Teile verbindet, sowie die Fähigkeiten der unterschiedlichen DBMSs. Jeder der DBMS-Treiber könnte der DD/D-Treiber sein. Der Übersetzer und Optimierer greifen auf den DD/D zu, um zu übersetzen und eine Anfrage zu planen. Jede Anfrage oder Unteranfrage wird durch den Optimierer-Controller an einen oder an mehrere der DBMS-Treiber zur Ausführung gesandt. Der Controller wartet dann auf Antworten von den DBMS-Treibern. Die von den betreffenden DBMSs erhaltenen Antworten werden dann in ein gemeinsames Ergebnis integriert, das für den Benutzer zugänglich ist.
Vor diesem Hintergrund ist es eine Aufgabe der gegenwärtigen Erfindung, eine verteilte (globale) Netzwerkarchitektur und ein System zu schaffen, was erweiterbar ist und flexibel, um Benutzern einen transparenten, integrierten Zugang zu heterogenen DBMS zu schaffen, die über ein entferntes Netzwerk verteilt sind. Ferner soll die Architektur und das System zur Verwendung in mehrfachen Managementsystemen mit großem Informationsumfang, die geographisch verteilt sind, angepaßt sein, wie etwa Befehl und Kontrolle, computerintegriertes Manufacturing, medizinische Informationssysteme und viele Anwendungen und intelligente Analyse und Entscheidungsunterstützungsdomänen, die einen effektiven und transparenten Zugang zu vorhandenen Quellen mit hohem Datenvolumen schaffen sollen, die mit unterschiedlichen, geographisch verteilten DBMSs gesammelt und gespeichert werden. Ferner soll das System nicht nur eine Föderation von bereits existierenden Datenbanken unterstützen, sondern auch die Hinzufügung von neuen Datenbanken zu dem System. Die Informationsmanagementarchitektur und das System sollen eine standardisierte Abfragesprache und eine Standardschnittstelle bereitstellen, die von jedem Benutzer zu benutzen ist.
Diese Aufgabe wird durch ein Computerdatennetzwerk gemäß Anspruch 1 gelöst.
Die hier beschriebene und beanspruchte Architektur des verteilten Informationsmanagements (FIM) erlaubt es dem Endbenutzer, auf geographisch verteilte Vielfach-Informationsmanagementsysteme zuzugreifen. Sie ermöglicht dem Endbenutzer eine einheitliche Ansicht von darunterliegenden Informationsmanagementsystemen. Die Datenverteilung und die Lagetransparenz sind durch die FIM-Architektur gemäß der gegenwärtigen Erfindung unterstützt. Dies bedeutet, daß der Endbenutzer nicht wissen muß, wie die Daten verteilt sind, und daß er ihre Lage nicht kennen muß, um auf relevante Daten zuzugreifen und diese zu teilen. Ferner kann die FIM-Architektur gemäß der gegenwärtigen Erfin dung sowohl existierende als auch neue Informationsmanagementsysteme miteinander integrieren.
Zu den Vorteilen der Erfindung gehören die folgenden:
1) Die Erfindung erlaubt einen verteilten Zugang ohne eine Veränderung der darunterliegenden, vorhandenen Datenbanken;
2) die Erfindung erlaubt eine Verringerung der Ausbildungskosten und -zeit zum Erlernen der unterschiedlichen DBMSs, was zu einer Verbesserung der Produktivität der Benutzer führt;
3) die Erfindung kann Daten verwenden, teilen und kombinieren, die sonst an vielen verschiedenen physikalischen und logischen Orten verstreut wären;
4) die Erfindung erlaubt es dem Gesamtsystem, neue Informationsmanagementsysteme mit einem Minimum an Veränderungen zu entwickeln und einzuschließen und
5) die Erfindung ist in der Lage, mit normalerweise inkompatiblen, unterschiedlichen Datenbankanbietern zu verkehren und sich daran anzupassen.
Ein neuer Aspekt der Erfindung ist deshalb die verteilte Architektur, gekoppelt mit der Architektur des Zwischenstandort-Transaktionsservices (Inter-Site Transaction Service) (ISTS), um einen transparenten Zugang zu einer großen Anzahl von DBMSs zu erlauben, während die lokale Autonomie der darunterliegenden DBMSs beibehalten wird. Mit dieser Architektur der Erfindung kann die FIM gemäß der gegenwärtigen Erfindung auf unterschiedlicher Hardware, auf unterschiedlichen Betriebssystemen, Kommunikationsnetzwerken und DBMSs laufen. Ferner kann das System gemäß der gegenwärtigen Erfindung entwickelt werden, um neue Ziel-DBMSs bei minimalen Veränderungen einzuschließen. Die verteilte Architektur der gegenwärtigen Erfindung ist nicht auf die Integration von relationalen DBMSs begrenzt, sondern kann auch Legat-DBMSs wie etwa hierarchische oder Netzwerk- DBMSs, räumliche Informationssysteme oder geographische Informationssysteme und Textabfragesysteme integrieren.
Die gegenwärtige Erfindung ermöglicht deshalb eine intelligente Integration einer Informationsumgebung, um einen nahtlosen Zugang zu ausgedehnten heterogenen Informationsmanagementsystemen zu unterstützen, wobei relationale, räumliche und Textsysteme gehören. Die Erfindung weist die folgenden Merkmale auf, um diese Umgebung zu unterstützen:
(1) Eine verzweigte Architektur, die einen transparenten Zugang zu Vielfach-Datenbanksystemen unterstützt. Sie versorgt den Endbenutzer mit einer vereinheitlichten Ansicht der darunterliegenden Datenbanksysteme. Die lokale Autonomie der darunterliegenden Datenbanksysteme wird vollständig in der verteilten Architektur beibehalten. Das bedeutet, daß die Benutzer noch dieselbe Anwendung verwenden können, um auf die lokalen Datenbanken zuzugreifen, und daß nur eine minimale Änderung an dem lokalen Datenbanksystem notwendig ist, um relevante Daten zu teilen und entfernt darauf zuzugreifen. Die Architektur weist verschiedene verteilte Abfrage-Optimierungsverfahren für fragmentierte und sich wiederholende Daten auf. Diese Optimierungsfähigkeit verbessert die Gesamtabfragekosten, indem die Übertragungs- und die Verarbeitungskosten des Gesamtsystems reduziert werden. Ferner verwendet die Architektur fragmentierte Abhängigkeitsinformation, was als semantische Abfrageoptimierung bezeichnet ist, um die Gesamtkosten zu verbessern. Ferner ist eine hohe Ebene von verteilten Transaktionsleistungen vorgesehen, um die Netzwerk-Kommunikationsprotokolle der niedrigeren Ebene von den verteilten Anfrage-Verarbeitungsprotokollen zu trennen. Das detaillierte Design dieser Architektur und das verteilte Informationsmanagement (Federated Information Management) (FIM) sind unten erläutert.
(2) Die Ausdehnung der normalerweise passiven Rolle der herkömmlichen Quelle des Datenwörterbuches (DD) in aktive und intelligente Rollen. In der aktiven Rolle hält das intelligente Datenwörterbuch (Smart Data Dictionary) (SDD) der gegenwärtigen Erfindung automatisch eine Datenkonsistenz ein, wenn neue Anwendungen oder Datenbanken hinzugefügt werden. Um die Fähigkeiten des Urteilens und Problemlösens in einer kohärenten Weise zu unterstützen, verwendet das SDD ein multidimensionales Referenzmodell, das multiple integrierte Ebenen von Abstraktionen erlaubt, wozu eine große Vielzahl von Datenarten (Text, Raum usw.) gehört. Die folgenden Konzepte werden vorzugsweise in das SDD-Design einbezogen, um eine größere Effizienz und Flexibilität der Aufnahme, Speicherung und Manipulierung solcher Meta- Daten zu erhalten:
(a) Die modulare Architektur von SDDs und die multidimensionale Informationsstruktur für Multimedia-Daten und Wissensabstraktionen.
(3) Die flexible SDD-Architektur erlaubt es dem System, neue Informationssysteme nach und nach aufzunehmen. Jedoch wird der SDD in einer weit verzweigten Informationsumgebung zu einem Engpaß, und das dargestellte Wissen wird zu einer großen, komplexen und nicht handhabbaren Hierarchie. Die gegenwärtige Erfindung minimiert diese Risiken, indem sie eine kooperative Umgebung für eine Vielzahl unabhängiger SDDs entwickelt. In diesem kooperativen Modell zur Integration und Wartung nehmen wir an, daß jeder SDD unabhängig laufen kann und immer noch mit anderen SDDs bezüglich geeigneten Wissens zusammenwirken kann, ohne sämtliche der fremden SDD-Meta-Daten vollständig zu integrieren. Jeder SDD enthält die Meta-Daten über eine spezielle Domäne, wozu viele Datenbanken gehören können; ferner wird er Wissen über seine nächsten Nachbarn enthalten, jedoch nicht über alle Nachbarn. Trotz vielfacher Anforderungen wie etwa die Konsistenz von Meta-Daten, vielfache Daten-/Wissensansichten, Kommunikations- und Daten-/Wissenstransformation, wird die Kooperation der vielfachen SDDs eine unabwendbare Charakteristik des weiträumig integrierten Informationssystems sein.
Die obigen Technologien und Führungskonzepte erlauben ein neues Zusammenwirken von existierenden Technologien (verteilten Systemen, wissensbasierten Systemen, objektorientierten Systemen, heterogenen Datenbanken und lernenden Maschinen). Darüber hinaus bilden sie eine Basis für eine intelligente Integration von Informationsdesign, die eine erhebliche technische Verbesserung gegenüber bestehenden Technologien bedeutet. Die neuen Merkmale der Konstruktion und des Betriebs der Erfindung werden den Fachleuten beim Lesen der folgenden Beschreibung unter Bezugnahme auf die Zeichnung deutlich, in der eine bevorzugte Ausführung der Erfindung dargestellt ist und in der gleiche Bezugsziffern gleiche Teile bezeichnen.
Fig. 1 ist ein Diagramm, das einen Modus eines Datenkommunikationsnetzwerkes zwischen einzelnen Benutzern oder Anwendungen sowie der darunterliegenden Informationssysteme gemäß der gegenwärtigen Erfindung verdeutlicht;
Fig. 2 ist ein Diagramm, das die Komponentenarchitektur und den Arbeitsablauf eines verteilten Informationsmanagers gemäß der gegenwärtigen Erfindung zeigt;
Fig. 3 ist ein Diagramm, das die Komponentenarchitektur und den Arbeitsablauf zwischen einem verteilten Informationsmanager und einem dazugehörigen lokalen Informationsmanager gemäß der gegenwärtigen Erfindung zeigt;
Fig. 4 ist ein Diagramm, das die Komponentenarchitektur und den Arbeitsablauf eines begrenzten Informationsmanagers gemäß der gegenwärtigen Erfindung zeigt;
Fig. 5 ist ein Diagramm, das ein Bulk-Load Copy Protocol (BCP) gemäß der gegenwärtigen Erfindung zeigt;
Fig. 6 ist ein Diagramm, das die Komponentenarchitektur und den Arbeitsablauf zwischen einem Smart Data Dictionary Cache Memory Management und einem Smart Data Dictionary Server gemäß der gegenwärtigen Erfindung zeigt;
Fig. 7 ist ein Diagramm, das die Komponentenarchitektur und den Arbeitsfluß einer Cache Memory Management-Einrichtung gemäß der gegenwärtigen Erfindung zeigt;
Fig. 8 ist ein Diagramm, das ein Client-/Server-Modell gemäß der gegenwärtigen Erfindung zeigt;
Fig. 9 ist ein Diagramm, das eine Hierarchial Star Distributed Processing Topology gemäß der gegenwärtigen Erfindung zeigt;
Fig. 10 ist ein Diagramm, das eine Hierarchial Distributed Processing Topology gemäß der gegenwärtigen Erfindung zeigt und
Fig. 11 ist ein Diagramm, das eine Distributed Transaction Service Hierarchy Topology gemäß der gegenwärtigen Erfindung zeigt.
Wie oben beschrieben unterstützt der verteilte Ansatz gemäß der gegenwärtigen Erfindung eine vollständige Transparenz für die Datenverteilung und Heterogenität zwischen Informationssystemen. Er hält ferner die Autonomie der lokalen Ebene ein, indem die Notwendigkeit zu Veränderungen bei allen teilnehmenden Ebenen minimiert wird. Diese flexible Architektur erlaubt es dem System, sich in der Zukunft zu entwickeln und isoliert die Benutzer von Veränderungen der darunterliegenden Hardware, vom IMS und von der logischen und physikalischen Datenbankstruktur. Wenn Benutzer eine einzige Benutzer- Schnittstellen- und Zugangsmethode erlernt haben, können sie auf alle Datenbanken unabhängig von ihrer Lage und ihrem Aufbau zugreifen. Dies vergrößert die Produktivität und spart Schulungskosten ein.
Die gegenwärtige Erfindung in ihrer Ausführung in einem Federated Information Management System (FIMS), das entworfen ist, um Daten von vielfachen Relational DataBase Management Systems (RDBMS) abzurufen, wird jetzt in seiner bevorzugten Ausführung beschrieben.
FIMS präsentiert dem Benutzer die Vorstellung einer einzigen, integrierten, nicht verteilten Datenbank durch eine gleichförmige Schnittstelle, eine strukturierte Abfragesprache (SQL) oder eine graphische Benutzerschnittstelle (GUI). Fig. 1 beschreibt die generelle FIMS-Architektur. Sie besteht aus den folgenden Hauptkomponenten.
Das Query Browser und Editor Modul (QuBE) 10 stellt für den Benutzer 12 eine gleichförmige Schnittstelle bereit, um auf vielfache Datenbanken zuzugreifen. Benutzer können ihre Abfragen entweder unter Verwendung von SQL oder GUI formulieren.
Der Distributed Information Manager (DIM) 14 zerlegt die globale Anfrage in eine Mehrzahl von Anfragen. Er erzeugt einen verteilten Zugriffsplan (DAP), der auf der Basis der Verarbeitung der Ebenen und der Netzwerk-Kommunikationskosten optimiert wird. Dieser Zugangsplan wird in verschiedene lokale Ausführungspläne (LEP) aufgeteilt, jeder für eine Ebene.
Insbesondere erzeugt der Benutzer eine globale Anfrage unter Verwendung von QuBE. Soweit es den Benutzer betrifft, wird er oder sie nur auf eine einzige (virtuelle) Datenbank zugreifen. QuBE sendet die globale Anfrage zum DIM. Auf der Basis der in dem Smart Data Dictionary (SDD) 16 gespeicherten Meta-Daten zerlegt der DIM 14 die globalen Anfragen, wie unten beschrieben, in vielfache lokale Anfragen. Er optimiert die Gesamtkosten zum Ausführen der globalen Anfrage, indem die Anzahl von Daten, die zwischen lokalen Ebenen übertragen werden müssen, minimiert wird, und indem der geeignete Ort zum Ausführen des lokalen Zugangsplans ausgewählt wird. Er wird dann die Ausführung von lokalen Vielfachanfragen koordinieren.
Der DIM 14 besteht aus zwei Komponenten hoher Ebene: dem Query Decomposer und Optimierer 14A und dem Distributed Processing Coordinator 14B.
Fig. 2 zeigt die DIM-Unterkomponenten niedriger Ebene sowie den Informationsfluß dazwischen. Der Query Decomposer und Optimierer (QDO) 14A zerlegt die Anfrage in Anfragen für lokale Ebenen. Auf der Basis der Verarbeitungskosten einer Ebene und der Übertragungskosten entwirft der QDO einen Ausführungsplan, um die Gesamtausführungskosten der Anfrage zu minimieren.
Der syntaktische und semantische Parser (SPP) 18 überprüft und validiert die Syntax einer Anfrage. Er identifiziert und verifiziert die Verbindungsanschlußmöglichkeit. Er greift auf das Smart Data Dictionary (SDD) 16 zu, um Information über das Federated Semantic Schema (FSS) und das Export Semantic Schema (ESS) der darunterliegenden Datenbanken zu erhalten. Das FSS und das ESS repräsentieren die lokale Schema-Information, die gemeinsame Ansicht und die Zwischenbeziehungen zwischen Entitäten (Ansichten, Objekte) aus multiplen, lokalen Schemata.
Der Optimierer 14A führt eine vorsichtige Planung und Kontrolle der Zeit durch, die notwendig ist, um die Anfrage für den Zugang zu Daten in Vielfachdatenbanken zu verarbeiten. Dies ist bei lokalen DBMSs wichtig, wird jedoch noch wichtiger, wenn Daten über ein Netzwerk bewegt werden müssen. Der Optimierer 14A ruft die Datenverteilungsinformation (d. h. fragmentiert, wiederholt oder teilweise fragmentiert und teilweise wiederholt), die Übertragungskosten und die Verarbeitungskosten von dem SDD 16 ab. Er verwendet dann einen Integrated Replicated Semi-Join-Algorithmus, um die Gesamtausführung zu planen. Der gesamte Ausführungsplan wird in die folgenden Schritte aufgeteilt:
Lokale Reduzierung. Auf der Basis der Aussagen, die in der globalen Anfrage spezifiziert sind, reduziert dieser Schritt die Anzahl von Daten soweit wie möglich, bevor die Daten zu anderen Orten gesendet werden.
Fragmentreplizierung. Der Optimierer entscheidet, welche Fragmente kopiert werden müssen, um die Gesamtausführungskosten der Anfrage zu minimieren.
Local Query Execution. Der Teil der lokalen Anfrage, die betroffen ist, wenn das kopierte Fragment ausgeführt wird, und das Zwischenergebnis werden zum Heimatort gesandt. Der Heimatort wird als Default für den Ort den Benutzers verwendet, es sei denn, der Benutzer spezifiziert dies anders.
Ergebnisintegration. Der Heimatort integriert die Zwischenergebnisse, die von den lokalen Orten gesendet wurden. Der Execution Plan Generator (EPG) 20 übersetzt den Ausführungsplan für jeden Ort von einer internen Datenstruktur auf die Distributed Intermediate Structured Query Language (DISQL), eine Erweitung von SQL. Für jeden lokalen Ort wird der lokale Ausführungsplan in drei Daten aufgespalten, die SQL-Anweisungen als auch Schema- und andere Daten enthalten.
Der lokale Ausführungsplan schließt Schnittstellen mit der Ziel-DBMS ein. Es gibt zwei Hauptmodi der Koordination zwischen dem DIM 14 und den LIMs 22, um den lokalen Ausführungsplan aus zuführen, nämlich den autonomen und den vollständig koordinierten Modus.
In dem autonomen Modus sendet der DIM 14 einfach an jeden LIM 22 seinen lokalen Ausführplan, der unabhängig und parallel ausgeführt wird. Es gibt keine Koordination zwischen DIM und LIMs in dem autonomen Modus. Jeder LIM koordiniert seinen eigenen lokalen Ausführplan, wozu Schnittstellen mit lokalen DBMS und ein Zusammenwirken mit anderen LIMs gehören.
In dem vollständigen koordinierten Modus koordiniert der DIM alle lokalen Ausführpläne, indem jeder lokale Ausführschritt zwischen LIMs seriell umgesetzt wird. D. h., daß an jedem LIM keine Koordination durchgeführt werden muß, da er nur mit dem DIM und nicht mit anderen LIMs zusammenwirkt. Eine Parallelverarbeitung von jedem LIM wird in diesem Fall verhindert, und der DIM wird zu einem Engpaß.
Intuitiv führt der autonome Modus wegen Parallelität zu einer besseren Performance. Jedoch können Blockier-Probleme während der Kommunikation zwischen LIMs auftreten, da das Kopieren von Fragmenten adressiert werden muß. Blockier-Probleme können entweder durch ein Betriebssystem oder durch ein Interrupt Client/Server gelöst werden. In einem weit verzweigten Netzwerk und einer großen heterogenen Umgebung ist die Verwendung von Interrupts, die von den darunterliegenden Betriebssystemen unabhängig sind, gegenwärtig nicht möglich. Z. B. unterstützt der Sybase Open Server keine Interrupts, sondern stellt dem Benutze: lediglich UNIX-Interrupts zur Verfügung, die zum Betreiben von LIMs in einem Betriebssystem nicht verwendbar sind.
Die gegenwärtige Erfindung verwendet dann einen Ansatz, der eine Diatributed Processing Coordinator (DPC) 24 Komponente in dem DIM 14 verwendet, um einen halbkoordinierten Modus be reitzustellen, der auf der Logik jedes lokalen Ausführschritts beruht. Dies bedeutet, daß der autonome Modus nur dann verwendet wird, wenn keine Blockier-Situation erwartet wird. Ansonsten wird der vollständig koordinierte Modus verwendet.
Die Grundausführschritte werden dann von dem DPC 24 im Halbkoordinationsmodus koordiniert, wie im folgenden anhand von Fig. 3 und 4 beschrieben:
Der erste Schritt besteht darin, jedem LIM 22 seinen lokalen Ausführplan zu senden. Der lokale Ausführplan besteht in der Form von drei Dateien, die jedem LIM 22 unter Verwendung des Werkzeugs 26 zur Dateifernübertragung zugesandt werden, das von dem unten beschriebenen Inter-Site Transaction Service (ISTS) bereitgestellt wird. Die erste Datei 28A ist eine Datendatei, die Fragment- und Verteilungsinformation enthält, die notwendig ist, um die lokale Anfrage auszuführen. Die zweite Datei 28B enthält SQL-Anweisungen, um die lokalen Daten zu reduzieren, wodurch die lokale Anfrage vereinfacht und die zwischen LIMs übertragenen Daten minimiert werden. Die dritte Datei 28C enthält die auszuführende lokale Anfrage.
Der zweite Schritt besteht darin, jedem LIM 22 eine Anfrage zum Ausführen seiner lokalen Reduktionsanfrage zu senden. Es gibt keine Wechselwirkung zwischen LIMs während der lokalen Reduktion. Dieser Schritt wird asynchron durchgeführt, wobei die LIMs parallel arbeiten können.
Der dritte Schritt besteht darin, jedem LIM eine Anfrage zum Kopieren relevanter Fragmente zu senden. Diese Information bezüglich der in Kopie benötigten Fragmente ist in dem Datenfile 28A enthalten, das dem LIM 22 während des obigen Schrittes 1 gesendet wurde. Dieser Schritt wird sequentiell durchgeführt, so daß jeweils nur ein LIM eine Fragmentreplizierung durchführt. Dies verhindert Blockier-Situationen, indem sicherge stellt wird, daß alle LIMs als Server zugänglich sind, um die Fragmentdaten zu erhalten. In Abhängigkeit vom Zeitverhalten ist es möglich, daß ein LIM noch seinen lokalen Reduktionsplan ausführt, während ein anderer LIM versucht, ihm Fragmentdaten zu senden. In diesem Fall wird dem LIM, der die Fragmentdaten sendet, garantiert, daß er nur eine begrenzte Zeit warten muß, bevor seine Anfrage bearbeitet wird.
Der vierte Schritt besteht in der Anforderung, daß jeder LIM 22 seine lokale Anfrage ausführt. Dieser Schritt wird asynchron durchgeführt, was eine parallele Ausführung vielfacher LIMs ermöglicht.
Der fünfte Schritt besteht darin, jedem LIM 22 außer dem Heimort eins Anfrage zu senden, an den Heimort sein Zwischenergebnis von dem obigen Schritt vier zu senden. Dieser Schritt wird synchron ausgeführt, um sicherzustellen, daß der Heimort alle Zwischenergebnisse erhält.
Der sechste Schritt besteht darin, an den Heimort eine Anfrage zu senden, die von anderen Orten erhaltenen Zwischenergebnisse mit den eigenen Zwischenergebnissen zu kombinieren und das Endergebnis an den DIM 14 zurückzusenden. Dieser Schritt wird auch synchron durchgeführt, um zu verhindern, daß globale Abfragen am DIM 14 auf ihre Ausführung warten, bevor die Ergebnisse erhalten sind, wodurch eine Blockier-Situation entstehen würde.
Als siebter und letzter Schritt archiviert der DPC 24 die Ergebnisse und ordnet sie dieser ihrem Schema und Index für ein späteres Abrufen durch die Anwendung zu.
Der Local Information Manager (LIM) 22 führt den lokalen Ausführplan aus, überwacht diesen und kommuniziert mit fremden DBMS zum Datenabruf. Die spezifische LIM-Architektur wird jetzt erläutert.
Für jedes DataBase Management System (DBMS) ist ein LIM 22 notwendig, um die Abbildung von der globalen Ansicht auf die lokale Ansicht bereitzustellen, die Übersetzung von DISQL zu der DBMS-Zielsprache sowie die Schnittstelle für das Ziel-DBMS bereitzustellen. Die Unterkomponenten des LIM sind: der Local Controller; der Local Reduction Processor; der Subquery Processor; der Result Integrator; der Relation Replicator; und das Relational DBMS Interface. Die bevorzugte modulare Architektur der LIMs erleichtert den Aufbau von neuen LIMs. Z. B. werden gemeinsame Eigenschaften von relationalen Datenbanken wie etwa "verbinden",. "projizieren" und "auswählen" in geeignete Module modularisiert, die von den LIMs für jede andere sonst inkompatible Datenbank gemeinsam benutzt werden können.
Der Local Controller (LC) 22A kontrolliert die Ausführung des lokalen von dem DIM 14 gesandten Plans, indem die Vorgänge der anderen Komponenten der LIMs koordiniert werden. Wie oben erwähnt kann dies synchron oder asynchron erfolgen. In beiden Modi werden genau dieselben Komponenten verwendet, außer daß die Ausführzeit im synchronen Modus von dem DIM 14 kontrolliert wird. Ein lokaler Ausführplan wird in fünf diskrete Schritte aufgespaltet: lokale Reduktion; Fragmentreplikation; lokale Ausführung; Ergebnisübertragung und Ergebnisintegration. Die letzten beiden Schritte sind beide exklusiv, da der Heimatort die Ergebnisintegration durchführt, jedoch niemals die Ergebnisse übertragen muß. Im synchronen Modus wird jeder Schritt direkt von dem DIM über die ISTS ausgeführt, während im asynchronen Modus alle Schritte von dem LC 22A über ISTS ausgeführt werden, wobei jedoch keine Koordination durch den DIM notwendig ist.
Der Local Reduction Processor (LRP) 22B ist für die Ausführung der SQL-Anweisungen im dem lokalen von dem DIM 14 er haltenen Reduktionsfile verantwortlich. Bevor die Ausführung gestartet wird, müssen die internen Datenstrukturen der LIMs mit der von dem Datenfile erhaltenen Information initialisiert werden, die von dem DIM 14 erhalten wurde. An diesem Punkt wird der LIM mit der notwendigen Information für den gesamten lokalen Plan initialisiert, nicht nur mit dem lokalen Reduktionsschritt. Diese Information schließt Teile ein wie: Ergebnisfragmente; lokale Fragmente; und replizierte Fragmente, die während der Ausführung verwendet werden, sowie das Schema für solche Fragmente. Die Information in dem Datenfile bestimmt ferner die Bestimmung der Orte zum Senden der Zwischenergebnisse und Fragmente während der wiederholten Schritte 3 und 5. Der LIM greift ferner auf den SDD 16 zu, um Meta-Daten über das Schema aller lokalen Beziehungen zu erhalten, die in dem lokalen Plan verwendet werden. Sobald die obige Initialisierung beendet ist, führt der LRP 22B jede der SQL-Anweisungen, die in dem lokalen Ausführfile enthalten sind, aus. Diese SQL- Anweisungen sind typischerweise entweder Anweisungen wie "erzeuge" oder "wähle aus". Die "erzeuge"-Anweisungen werden verwendet, um eine temporäre Relation zum Halten von von anderen LIMs erhaltenen Fragmenten zu erzeugen. "Wähle aus" -Anweisungen werden verwendet, um Daten von lokalen Relationen zu reduzieren, bevor sie auf andere Orte repliziert werden.
Der Fragment Replicator (FR) 22C verwendet einen ISTS, eine Bulk-Load Copy Protocol (BCP) 30, um fragmentierte Relationen zwischen LIMs wirkungsvoll zu replizieren. Wie in Fig. 5 gezeigt, kann der BCP 30 ferner in eine Anwendungsebene aufgeteilt werden, die RDBMS-unabhängig ist, sowie in eine untere Datenbankebene, die tatsächlich Teil des Relational DataBase Interface ist.
Der BCP wird vorzugsweise mit zwei Zielen implementiert:
Ortsbeweglichkeit über die RDBMSs und Leistungseffizienz. Die Ortsbeweglichkeit wird erreicht, indem die Anwendungsebene von allen LIMs wiederverwendbar ist. Unglücklicherweise muß die Datenbankebene für jedem DBMS speziell angepaßt werden. Die Effizienz wird verbessert, indem nur ein Zugang zu jeder Relation unabhängig von der Anzahl der Empfänger repliziert werden muß. Dies wird erreicht, indem die Relationsdaten jedem Empfänger so übertragen werden, wie sie von der Datenbank ausgelesen werden. Die Effizienz wird ferner verbessert, indem ermöglicht wird, daß die Datenbankebene angepaßt wird, wodurch die Vorteile von allen speziellen Gesamtübertragungseinrichtungen genutzt werden, die von den darunterliegenden RDBMS unterstützt werden. Z. B. besteht in Sybase das effizienteste Verfahren des Einbringens von Daten bzw. des Herausziehens von Daten in bzw. aus einer Relation in der Verwendung der "Großlade"-Werkzeuge. Dagegen besteht in Oracle der effizienteste Weg zum Einbringen von Daten in eine Relation in der Verwendung einer SQL-Anfrage und von Array-Bindungen. Der effizienteste Weg zum Einbringen der Daten in Uracle besteht in der Verwendung des SQLLoader- Werkzeuges.
Die Amaendungsebene der BCP 30 wirkt mit der Datenbankebene über einen ASCII-Puffer 32 zusammen, der eine Unabhängigkeit von dem zum Abruf der Daten verwendeten Verfahren ermöglicht. Eine Folge von Pufferwerkzeugen konvertiert Daten aus der in dem Output verwendeten Repräsentation (z. B. Reihen von Daten im Speicher von Oracle) auf ASCII und von ASCII auf die für den Input verwendete Darstellung (z. B. Sqlloader-Datenfile in Oracle). Die tatsächlichen Daten, die über das Netzwerk gesandt werden, enthalten Relationsschema- und andere Informationen wie etwa: Anzahl von Reihen; Größe von Daten usw.
Nach den obigen Schritten der lokalen Reduktion und der Fragmentreplizierung werden alle relevanten Fragmente kopiert und in temporären Relationen an den Zielorten gespeichert. Der Local Query Processor (LQP) 22D ist für die Ausführung der Anfragen in dem lokalen Anfragefile verantwortlich, das von dem DIM 14 erhalten wird. Bevor diese Anfragen ausgeführt werden, muß der LQP 22D alle Fragmente derselben Relation kombinieren (diejenigen, die lokal abgerufen wurden, und diejenigen, die von anderen LIMs repliziert wurden). Der LQP 22D erzeugt die SQL-Anweisungen, die notwendig sind, um die Fragmente zu kombinieren und führt sie unter Verwendung des RDBI aus. Nachdem die Fragmente kombiniert sind, wird die lokale Anfrage unter Verwendung des RDBI ausgeführt, und die Zwischenergebnisse werden in einer Datei gespeichert.
Die Komponente Result Transmitter (RT) 22E verwendet einfach das Übertragungsprotokoll für entfernte Dateien (RFT), das von dem ISTS 34 bereitgestellt wird, um die Datei, die die obigen Zwischenergebnisse enthält, zu dem Heimatort zu übertragen.
Der Result Integrator (RI) 22F kombiniert alle Zwischenergebnisse, die von den anderen LIMs (über ihre Ergebnisübertrager) erhalten wurden, mit seinem eigenen Zwischenergebnis- Output mit Hilfe seines Local Query Processors 22D. Er wird dann die kombinierten Ergebnisse an den DIM 14 zurückgeben. Im asynchronen Modus werden die kombinierten Ergebnisse zu dem DIM 14 in einem separaten Schritt zurückgegeben, indem der DIM 14 zu einem Server wird und der LIM 22 zu einem Client wird. Wie oben diskutiert kann dies möglicherweise zum Auftreten einer Blockier-Situation führen, da der DIM 14 die Ausführung einer anderen Anfrage starten kann, bevor er die Ergebnisse von der vorherigen Anfrage erhalten hat. Dies ist akzeptabel, sofern der DIM 14 unterbrochen werden kann, ansonsten wird der LIM 22 darauf warten, seine kombinierten Ergebnisse zu übertragen, während der DIM 14 auf die Ausführung der nächsten Anfrage bei demselben LIM 22 wartet, wodurch so eine Blockierung erzeugt wird. Ein Betrieb im synchronen Modus vermeidet dieses Problem, indem die kombinierten Ergebnisse an den DIM 14 als eine Antwort auf die Anfrage zur Ergebniskombination zurückgegeben werden. Auf diese Weise kann der DIM 14 die Ausführung keiner anderen Anfrage starten, bevor die Ergebnisintegration an dem Heimatort vollständig ist und die kombinierten Ergebnisse an den DIM 14 zurückgegeben sind.
Zu diesem Zeitpunkt versteht es sich, daß die gegenwärtige Erfindung auch eine Architektur einschließt, bei der wenigstens ein LIM unter einem DIM gleichfalls ein DIM ist, so daß dieselbe Architektur rekursiv wiederholt wird, wobei der zweite DIM als ein LIM für seinen darüberliegenden DIM arbeitet und als ein DIM für seine darunterliegenden LIMs. Mit anderen Worten kann dieselbe Architektur, die hier zwischen einem DIM und einer Folge von LIMs beschrieben wurde, auf eine rekursive Weise repliziert werden, indem wenigstens einer der darunterliegenden LIMs durch einen DIM ersetzt wird und die Replizierung fortgesetzt wird, soweit notwendig, um die LIMs in eine logische oder physikalische antwortende Einheit zu gruppieren.
Der Smart Data Dictionary Server (SDD) 16 enthält Information wie etwa: Schema; Datenverteilung; Ortskonfiguration; Domänenkenntnis und zwischenörtliche Beziehungen. Der SDD 16 selbst ist eine Datenbank, die Meta-Daten enthält, die zur Unterstützung des DIM 14 und des LIM 22 bei der Verarbeitung der Anfragen verwendet werden können. Eine SDD-Datenspeicherung kann durch ein UNIX-Filesystem oder durch ein Object-Oriented DataBase Management System (OODBMS) wie etwa ITASCA erreicht werden.
Der SDD-Server 16 unterstützt Anfragen von einem entfernten Ort auf die SDD-Meta-Daten, die in einem UNIX-Filesystem gespeichert sind. Der DIM 14 und der LIM 22 können aus der Entfernung auf den SDD-Server 16 zugreifen, um Meta-Daten zur Syntaxprüfung, zur Übersetzung, zum Optimieren und zum Koordinieren der globalen und lokalen Anfragen abzurufen. In Fig. 1 arbeitet der SDD-Server 16 als ein Ersatz für den wissensbasierten Manager für den SDD, der, in einem UNIX-Filesystem speichert.
Der SDD enthält Meta-Daten wie etwa: Datenverteilungsinformation, Schemabeschreibung und FIM-Systemkonfiguration. Der DIM verwendet das Schema und die Datenverteilung, um die Ausführpläne zu erzeugen. Der LIM verwendet das Schema, um lokale Anfragen auszuführen und die lokalen Anfragen auf andere Orte abzubilden. Eine Cache-Speicherung der Meta-Daten an dem Verarbeitungsort wird die Kommunikations- und Zugangskosten deutlich reduzieren. Z. B. kann bei einer Verwendung des Cache Memory Management (CMM) der DIM 14 auf die relevanten Daten zugreifen und diese im Cache speichern, die von der nächsten Anfrage verwendet werden könnten. Dies wird eine überflüssige Kommunikation mit dem SDD 16 zum Abrufen des Schemas eliminieren. Jeder LIM 22, DIM 14 und SDD-Server 16 verwendet das gleiche CMM.
Fig. 6 verdeutlicht die CMM- und die SDD-Server-Architektur.
Insbesondere erfolgt sämtlicher Zugang auf das SDD-Schema über das CMM, das das Schema für die zuletzt verwendeten Relationen im Speicher hält. Falls die Daten nicht im Cache- Speicher enthalten sind, ruft das CMM die Relation lokal transparent ab (d. h. von einem File oder DBMS) oder von einem anderen entfernten Server, oder beides. Anfragen auf das Cache können sich entweder auf spezielle Relationen (wie etwa Relationsname, Feldidentifizierung, Anzahl von Fragmenten usw.) oder auf das gesamte Schema beziehen. Zum Zwecke der Effizienz laden der DIM und die LIMs normalerweise das Schema für alle in einer Anfrage verwendeten Relationen während der Initialisierüngshierarchie, die einen Unterbau der globalen Ansicht darstellt, die in einer speziellen Ebene beginnt. Das Cache kann eine lineare Suche verwenden, um auf Information zuzugreifen und kann in einer modularen Architektur gebaut sein, was einen einfachen ERsatz von Algorithmen erlaubt, um das Cache abzusuchen und Kandidaten durch wichtigere selektiv auszulagern. Die Zeit der letzten Verwendung, die Zeit der Einbringung in das Cache und die Anzahl von Zugriffen werden für jeden Cache-Eintrag festgehalten, um solche Algorithmen zu unterstützen. Die Größe des Speichers, der von dem Cache verwendet ist, ist eine Funktion der Anzahl von Relationen in seiner Belegung. Jedoch muß die maximale Anzahl von Relationen, die aufgenommen werden kann, bei der Initialisierung des Cache spezifiziert werden. Der SDD- Server hat zwei Distributed Transaction Services (ISTS): "Sende Katalog" und "Sende Schema", um die Arbeitsweise des SDD-Cache- Speichermanagements zu unterstützen. Der Service "Sende Katalog" sendet dem Client eine Kopie des Relationskataloges. Der Katalog enthält eine Liste von Relationen, von denen jede einer Zugriffsart und einem Servernamen zugeordnet ist. Falls ein Schema nicht im Cache-Speicher vorhanden ist, bestimmt die Zugriffsart, auf welche Weise die Daten abzurufen sind, wie etwa von einem lokalen File, von einer lokalen RDBMS oder von einem anderen Server. Obwohl der Katalog vor der Ausführung des ersten Zugriffs auf das Cache abgerufen werden kann, ist es bevorzugt, daß er bei allen Prozessen nach dem Hochfahren übertragen wird. Der Katalog wird vorzugsweise so aufrechterhalten, daß er mit allen Orten zur selben Zeit konsistent ist. Der Ser vice "Sende Katalog" ist ein spezieller Speicher für die Speicherübertragung zwischen dem Server und dem Client.
Der Service "Sende Schema" akzeptiert Anfragen für multiple Relationen auf unterschiedlichen Ebenen in der Hierarchie. Der SDD-Server enthält das gleiche Cache wie andere Client/Server. Meta-Daten werden zunächst unter Verwendung des Cache-Speichers gesucht. Falls die Meta-Daten nicht im Cache gefunden werden, verbindet das CMM mit dem Server, der den Meta-Daten in dem Katalog zugeordnet ist, und ruft die angeforderten Meta--Daten ab. Der Server kann lokal oder entfernt vorhanden sein. Die modulare CMM-Architektur stellt die Fähigkeit zur Anpassung an verschiedene Speichermanagements bereit, wie etwa: OODBM, relationales, datei- und wissensbasiertes Management.
Fig. 7 zeigt die Interaktionen zwischen verschiedenen Komponenten des CMM 36 und dem Server. Der Hauptteil der SDD- Serveranfragen wird sich auf Schema-Zugang beziehen, wofür der größte Teil der Arbeit von den lokalen Zugangsverfahren des Cache auf eine transparente Weise zu dem Dienstleister geschaffen wird.
Die Inter-Site Transaction Services (ISTS) 34 stellen die Zwischenbeziehungen zwischen Orten bereit. Eine Folge von verteilten Übertragungsdienstleistungen wird bereitgestellt, um einen verteilten Zugang, lokale Zugangspläne, Ausführung, und einen SDD-Meta-Daten-Zugang bereitzustellen. Die Komponenten Distributed Processing Coordinator (DPC), der lokale Controller (LC) und das CMM (Cache Memory Management) verwenden die ISTS, um die Zwischenprozeß-Kommunikationen zu unterstützen.
Insbesondere unterstützt der ISTS 34 die Zwischenverbindung zwischen unterschiedlichen Komponenten: DIM 14; LIMs 22 und dem SDD--Server 16, die an unterschiedlichen Orten vorhanden sein können und über unterschiedliche Netzwerk-Protokolle wie etwa TCP/IP, XN25 usw. kommunizieren können. Eine Folge von Inter-Site Transaction Services 34 unter Verwendung des Sybase Client/Open Servers wird vorzugsweise entwickelt, um diese Kommunikation zu unterstützen.
Die Sybase-Client/Open-Server-Software stellt die Transparenz von Netzwerk-Protokollen niederer Ebene bereit und managt die Ressourcen jeder Verbindung. Der Sybase-Client/Open-Server besteht aus Open Client, einer programmierbaren Bibliothekschnittstelle zur Verwendung durch Client-Anwendungen, und der Sybase-Open--Server zur Verwendung durch Server beliebiger Art. Diese beiden Schnittstellen ermöglichen einen funktionell reichhaltigen Satz von Bibliotheksroutinen. Sie stellen das notwendige Werkzeug zur Implementierung von transparenten Client/Server-Kommunikationen zwischen unterschiedlichen Datenbank-Produkten wie etwa Oracle und Ingres zur Verfügung, sowie zwischen Nicht-Datenbank-Servern, z. B. einem UNIX-File-System auf heterogenen Computern und Netzwerken. Die Schnittstellen können auf getrennten Prozessoren und Plattformen laufen, die über eine Vielzahl von Übertragungsprotokollen (TCP/IP, XN25 usw.) für Local Area Networks (LAN) kommunizieren, oder gemeinsam auf einem einzigen Prozessor wie in Fig. 8 laufen. Eine Netzwerkunterstützung ist in die Produkte eingebaut. Die Teilprozeß-Architektur des Open Server stellt eine hohe Leistung als ein geteilter Datenbank-Server bereit.
Es ist bevorzugt, daß die verteilte Verarbeitungsarchitektur der ISTS wenigstens zwei Hauptkommunikationstopologien aufweist: Hierarchical Distributed Processing Topology (HDPT) und Hierarchical Start Distributed Processing Topology (HSDPT) zur Verbindung des Query Browser and Editor (QuBE); des Knowledge Base Manager (KBM) oder des SDD-Servers; des DIM und der LIMs- Komponenten.
Die Hierarchical Distributed Processing Topology (HDPT) ist ein abstraktes Modell, das in Fig. 9 gezeigt ist, das verwendet wird, um die verteilte Verarbeitung der Anfrage gemäß der gegenwärtigen Erfindung zu unterstützen. Dieses Modell verbessert die Verläßlichkeit und reduziert das Ausmaß das Kommunikation und der Verarbeitungsengpässe auf Kosten der zwischenörtlichen Kommunikation und der Komplexität des LIM. Falls die Kommunikationskosten vernachlässigbar sind, dann ist der in Fig. 10 beschriebene HDPT geeigneter.
In der Hierarchical Start Distributed Processing Topology (HSDPT) gemäß Fig. 9 gibt es keine Kommunikation zwischen den LIMs 22, und die gesamte Koordination wird von dem DIM 14 durchgeführt. Diese Topologie vereinfacht die LIM-Entwicklung, und es gibt keine Kosten der Kommunikation zwischen den LIMs. Der DIM wird zu einem Engpaß und ist für einen Ausfall sehr anfällig.
Im allgemeinen hängt die Entscheidung der Auswahl einer Topologie gegenüber einer anderen Topologie von der speziellen Anwendungsumgebung ab.
Die gegenwärtige Erfindung nutzt den Vorteil der Sybase- Open-Server-Merkmale, um die Kommunikation zwischen Client und Server, Server und Server und Server und Client in einer heterogenen Umgebung zwischen DIM, LIMs, KBM und QuBE zu unterstützen. Jede ISTS 38 besteht, wie in Fig. 11 dargestellt, aus einem Paar von Client Request und Server Service. Die ISTS paßt in die Application Layer der standardmäßigen OSI-Protokolle und besteht aus drei Unterebenen:
(a) Application Interface Layer: stellt die Schnittstelle auf hoher Ebene für jede Anwendung zur Verfügung, die die Zwischenprozeß-Kommunikation erfordert. Routinen auf dieser Ebene sind normalerweise unabhängig von der speziellen Hardware und Software und sind deshalb von den unterschiedenen Anwendungen wieder verwendbar;
(b) Distributed Transaction Layer: unterstützt die notwendigen Dienstleistungen für verteilte Datenbanken. Routinen auf dieser Ebene sind normalerweise hardware- und/oder software-spezifisch und müssen deshalb beim Zusammenwirken mit unterschiedlichen DBMSs oder Betriebssystemen modifiziert werden;
(c) Network Communications Layer: ist die Ebene, die die logische/physikalische Verbindung und die Zwischenverbindung zwischen Orten bereitstellt. Der Sybase-Client/Open-Server kann auf dieser Ebene verwendet werden.
Die ISTS kann in einer Hierarchie organisiert sein, wie in Fig. 11 gezeigt, die sowohl eine Klassenhierarchie als auch eine zusammengesetzte Hierarchie codiert. Gestrichelte Linien repräsentieren eine Beziehung zwischen Dienstleistungen "der Art von", während ausgezogene schwarze Linien eine Beziehung zwischen Dienstleistungen "Teil von" repräsentieren. Z. B. hat eine Sprachschnittstelle drei Hauptkomponenten: einen Parser, einen Übersetzer und gemeinsame Werkzeuge, die "Teil von" sind, jedoch keine Unterklasse einer Sprachschnittstelle sind. Andererseits sind die Oracle- und Sybase-Übersetzer "der Art von" oder Unterklassen von Sprachübersetzern.
Es ist bevorzugt, daß die Haupt-ISTS-Gruppen umfassen:
(1) Ein Network Interface, das eine Verbindung sowie Protokolle hoher Ebene bereitstellt, wie etwa entfernte Dateiübertragung, entferntes Gesamtkopieren, Meta-Datenverarbeitung und verteilte Anfrageverarbeitung. Die Verbindungsdienstleistungen bestehen auf der DTS-Ebene und unterstützen Verbindungen und Kommunikationen mit anderen Servern/Clients. In der be vorzugten Ausführung sind die Verbindungsdienstleistungen auf die offenen Sybase-Client/Server-Bibliotheken aufgesetzt und stellen die Netzwerkbausteine für die meisten anderen Dienstleistunge bereit. Protokolle bestehen auf der Anwendungsebene und verwenden sowohl Verbindungsdienstleistungen als auch andere Dienstleistungen aus der Hierarchie. Z. B. verwendet das BCP- Protokoll in der Netzwerk-Schnittstelle die BCP-Dienstleistungen als Teil der relationalen Datenbankschnittstelle.
(2) Ein Language Interface, das die Abbildung von einer Sprache auf eine andere, wie etwa von DISQL auf Sybase-SQL oder Oracle-SQL, erlaubt. Einige gemeinsame Arbeitsweisen können zwischen Sprachschnittstellen gemeinsam genutzt werden, jedoch ist es höchstwahrscheinlich bevorzugt, daß jede einen separaten Parser und Übersetzer erfordert.
(3) Ein Database Interface, das Zugang zu den darunterliegenden Datenbanken erlaubt, und das Vorgänge wie Verbindung, Anfrageausführung (öffne, prüfe Syntax, führe aus) und Ergebnisabruf (verbinde, nächste Reihe) unterstützt. Die Schnittstelle stellt ferner Massenzugriffsverfahren bereit (ein, aus, Puffer), sofern sie existieren.
(4) Ein Distributed Query Processing Interface, das die Dienstleistungen bereitstellt, die notwendig sind, um den DIM (Optimierer) und den Betrieb des Distributed Processing Controllers und des Local Controllers (verteilte Anfrageausführung, lokale Anfrageausfürung, lokale Reduktion usw.) zu unterstützen.
Die ISTS-Ebenenarchitektur unterstützt eine offene und modulare Implementierung für das Zusammenwirken von heterogenen Informationsmanagementsystemen. Sie benutzt die Vorteile von Software von seiten Dritter. Veränderungen in einer Ebene werden andere Ebenen nicht beeinflussen. Wenn z. B. ein Kommunika tionspaket durch ein anderes ersetzt würde, würden andere Ebenen der Implementierung intakt bleiben. Die oben beschriebene Erfindung kann natürlich viele Variationen, Modifikationen und Veränderungen erfahren, die sich alle im Rahmen der zugehörigen Ansprüche befinden.

Claims

1. Computerdatennetzwerk mit einem Kommunikationsmedium, das eine Mehrzahl von Datenbanken miteinander verbindet, die Daten mit einer Mehrzahl von Benutzern (12) enthalten, von denen jeder eine globale Datenanfrage für den Zugang und das Abrufen von Daten aus den Datenbanken gemäß einem einzigen Abfrageprotokoll erzeugen kann, wobei das Netzwerk eine global integrierte Datenabfrage-Controller-Architektur zur Steuerung und Zuordnung der Übertragung der von dem Benutzer (12) erzeugten globalen Datenanfrage zu einzelnen der Mehrzahl von Datenbanken und zum Empfang der angeforderten von den Datenbanken erhaltenen Daten aufweist, und zum Integrieren in eine einzige Antwort und zum Übertragen der integrierten einzigen Antwort an den anfordernden Benutzer (12), mit:

- einer intelligenten Datenwörterbucheinrichtung (SDD) (16), die eine Datenbank von Daten repräsentierenden Schemata, Datenverteilungen, lokalen Konfigurationen und zwischenörtlichen Beziehungen von Daten zwischen den Datenbanken in dem Netzwerk für jede einzelne Datenbank in dem Netzwerk enthält;

- eine Dateninformationsmanagereinrichtung (DIM) (14), die sowohl mit der intelligenten Datenwörterbucheinrichtung (SDD) (16) kommuniziert, um daraus Daten auszulesen, als auch mit dem Benutzer (12), um daraus die globale Datenanfrage zu erhalten und um Antwortdaten dorthin zu übertragen, um die globale Datenanfrage in einen lokalen Ausführplan (LEP) zum Auslesen von Daten aus jeder Datenbank aufzuspalten, die Daten als Antwort auf die globale Datenanfrage in Übereinstimmung mit den in der intelligenten Datenwörterbucheinrichtung (SDD) (16) enthaltenen Daten aufweist, und um diesen Teil des lokalen auszu führenden Ausführplans (LEP) zu der geeigneten Datenbank zur Ausführung zu übertragen, und um daraus Daten als Reaktion auf den lokalen Ausführplan (LEP) zu erhalten;

- einer Mehrzahl von lokalen Informationsmanagereinrichtungen (LIM) (22), die jeweils mit den Dateninformationsmanagereinrichtungen (DIM) (14) und mit der intelligenten Datenwörterbucheinrichtung (SDD) (16) kommunizieren, um den Datenfluß zu und von einer spezifizierten Datenbank in dem Netzwerk als Antwort auf den von der Dateninformationsmanagereinrichtung (DIM) (14) erhaltenen Anteil des lokalen Ausführplans (LEP) zu kontrollieren, und um ausgelesene Daten als Antwort auf den Anteil des lokalen Ausführplans zu der Dateninformationsmanagereinrichtung (DIM) (14) zu übertragen und

- wobei jede lokale Informationsmanagereinrichtung (LIM) (22) ferner geeignet ist, in Übereinstimmung mit den in der intelligenten Datenwörterbucheinrichtung (SDD) (16) enthaltenen Daten eine Datenabfrageanforderung zur Ausführung durch eine andere lokale Informationsmanagereinrichtung (LIM) (22) und zum Erhalten von Daten daher als Reaktion darauf zu erzeugen, um diesen Anteil des lokalen Ausführplans (LEP) zu vervollständigen, der hiervon zur Ausführung erhalten wurde.

2. Netzwerk nach Anspruch 1, bei dem die Mehrzahl von Benutzern (12) mit einzelnen einer Mehrzahl von Knoten und zugehörigen Datenbanken verbunden sind, um die von den Datenbanken angeforderten Daten über die Knoten zu erhalten und in eine einzige Antwort zu integrieren, um die integrierte einzige Antwort zu dem anfordernden Benutzer (12) zu übertragen.

3. Netzwerk nach Anspruch 1 oder 2, gekennzeichnet durch wenigstens einen lokalen Informationsmanager-Controller (LIM) (22), der den Datenfluß zu und von wenigstens zwei lokalen Datenbanken kontrolliert und dazu geeignet ist, den Teil des lokaler Ausführplans (LEP), der von dem Dateninfotmationsmanager (DIM) (14) erhalten wurde, aufzuspalten in einen sublokalen Ausführplan, um Daten als Reaktion auf den Teil des lokalen Ausführplans (LEP) auszulesen, der von dem Dateninformationsmanager (DIM) (14) von jeder der kontrollierten lokalen Datenbanken erhalten wurde.

4. Netzwerk nach irgendeinem der Ansprüche 1 bis 3, bei dem der Dateninformationsmanager (DIM) (14) eine Syntax- und Semantik-Parser-Einrichtung (SSP) (18) aufweist, die mit dem intelligenten Datenwörterbuch (SSD) (16) zusammenwirkt, um Daten, die lokale Schema-Information und die Zwischen-Relationen zwischen den Daten repräsentieren, auszulesen, und um die globale Datenanfrage unter Verwendung solcher von dem intelligenten Datenwörterbuch (SSD) (16) abgefragter Daten bezüglich Syntax und Semantik zu überprüfen und zu validieren.

5. Netzwerk nach irgendeinem der Ansprüche 1 bis 4, bei dem der Dateninformationsmanager (DIM) (14) eine Datenoptimierungseinheit (14a) umfaßt, die mit dem intelligenten Datenwörterbuch (SSD) (16) zusammenwirkt, um daraus Daten auszulesen, die lokale Schemainformation und Interrelationen zwischen Daten repräsentieren, und um die Anzahl von Daten zu minimieren, die zwischen lokalen Datenbanken übertragen werden müssen, und um die geeignete lokale Datenbank zum Verarbeiten jedes Teils des lokalen Ausführplans (LEP) auszuwählen.

6. Netzwerk nach irgendeinem der Ansprüche 1 bis 5, bei dem der Dateninformationsmanager (DIM) (14) einen lokalen Aus führplan-Steuercontroller aufweist, der mit jeder der lokalen Datenbanken zusammenwirkt, um jeder lokalen Datenbank den Teil des lokalen Ausführplans (LEP) zu übersenden, der notwendig ist, um Antwortdaten aus jeder der lokalen Datenbanken auszulesen.

7. Netzwerk nach irgendeinem der Ansprüche 1 bis 6, bei dem der lokale Informationsmanager (LIM) (22) ferner einen lokalen Controller (LC) (22a) zur Steuerung der Ausführung des Teils des lokalen Ausführplans (LEP) aufweist, der von dem Dateninformationsmanager (DIM) (14) gesandt wurde, indem alle internen Operationen koordiniert werden.

8. Netzwerk nach Anspruch 1, bei dem:

- die Dateninformationsmanagereinrichtung (DIM) (14) eine Syntax- und Semantik-Parser-Einrichtung (SSP) (18) aufweist, die mit der intelligenten Datenwörterbucheinrichtung (SSD) (16) zusammenwirkt, um Daten, die lokale Schema- Information und die Zwischen-Relationen zwischen Daten darstellen, auszulesen, und um die Syntax der globalen Datenanfrage unter Verwendung solcher von der intelligenten Datenwörterbucheinrichtung (SSD) (16) ausgelesenen Daten syntaktisch zu analysieren und zu validieren;

- die Dateninformationsmanagereinrichtung (DIM) (14) ferner eine Optimierungseinrichtung (14a) umfaßt, die mit der intelligenten Datenwörterbucheinrichtung (SSD) (16) zusammenwirkt, um Daten auszulesen, die lokale Schema-Information und die Zwischen-Relationen zwischen Daten repräsentieren, und um die Menge von Daten zu minimieren, die zwischen den lokalen Datenbanken übertragen werden müssen, und um die geeignete lokale Datenbank zur Verarbeitung jedes Teils des lokalen Ausführplans (LEP) auszuwählen;

die Dateninformationsmanagereinrichtung (DIM) (14) ferner eine lokale Ausführplan-Steuereinrichtung (LEP) aufweist, die mit jeder der lokalen Datenbanken zusammenwirkt, um jeder lokalen Datenbank einen Teil des lokalen Ausführplans (LEP) zu senden, der notwendig ist, um Antwortdaten aus jeder lokalen Datenbank zu extrahieren;

wenigstens eine lokale Informationsmanagereinrichtung (LIM) (22) den Datenfluß zu und von wenigstens zwei lokalen Datenbanken steuert und geeignet ist, den Teil des lokalen Ausführplans (LEP), der von der Dateninformationsmanagereinrichtung (DIM) (14) erhalten wurde, in einen sublokalen Ausführplan aufzuspalten, um Daten als Antwort auf den Teil des lokalen Ausfführplans auszulesen, der von der Dateninformationsmanagereinrichtung (DIM) (14) von jeder der gesteuerten lokalen Datenbanken erhalten wurde und

- die lokale Informationsmanagereinrichtung (LIM) (22) ferner eine lokale Controllereinrichtung (LC) (22a) zum Steuern der Ausführung des Teils des lokalen Ausführplans, der von Dateninformationsmanagereinrichtung (DIM) (14) gesendet wurde, aufweist, indem alle internen Operationen koordiniert werden.

9. Netzwerk nach irgendeinem der Ansprüche 1 bis 8, bei dem die lokalen Controller (LC) (22a) synchron arbeiten.

10. Netzwerk nach irgendeinem der Ansprüche 1 bis 8, bei dem die lokalen Controller (LC) (22a) asynchron arbeiten.

11. Verfahren zum Steuern und Lenken der Übertragung von nutzergenerierten globalen Datenanfragen zu einzelnen einer Mehrzahl von Datenbanken, und um die von den Datenbanken angeforderten Daten zu erhalten und in eine einzige Antwort zu integrieren, und um die integrierte einzige Antwort zu dem anfordernden Benutzer (12) in einem Computerdatennetzwerk zu übertragen, wobei das Verfahren die Schritte aufweist:

- in dem intelligenten Datenwörterbuch (SSD) speichern eines lokalen Datenbankprofils, das Daten enthält, die Schema, Datenverteilung, lokale Ortskonfiguration und zwischenörtliche Relationen von Daten zwischen den lokalen Datenbanken in dem Netzwerk für jede lokale Datenbank in dem Netzwerk repräsentieren;

- Kommunizieren mit dem lokalen Datenbankprofil des intelligenten Datenwörterbuchs (SSD), um daraus Daten auszulesen, um die globale Datenanfrage in einen lokalen örtlichen Ausführplan (LEP) aufzuspalten, um Daten aus jeder lokalen Datenbank, die Daten als Antwort auf die globale Datenanfrage gemäß den in dem intelligenten Datenwörterbuch (SSD) enthaltenen lokalen örtlichen Datenbankprofil enthält, auszulesen;

- Übertragen des Teils des auszuführenden lokalen örtlichen Ausführplans (LEP) zu der geeigneten lokalen Datenbank zur Ausführung;

- Erhalten von Daten von jeder lokalen Datenbank als Antwort auf den lokalen Ausführplan (LEP) und Erzeugen einer globalen Antwort-Datenbank, die solche Antwortdaten enthält, die von jeder lokalen Datenbank erhalten wurden und

- Bereitstellen eines Zugangs für den Benutzer (12) zu der globalen Antwort-Datenbank gemäß dem einzigen globalen Anfrageprotokall.

12. Verfahren nach Anspruch 11, umfassend die Schritte:

- Erzeugen einer Mehrzahl von lokalen Informationsmanager-Einrichtungen (LIM) (22) für jede der lokalen Datenbanken, jede fit dem lokalen örtlichen Datenbankprofil des intelligenten Datenwörterbuchs (SSD), um den Datenfluß zu und von einer spezifizierten lokalen Datenbank in dem Netzwerk als Antwort auf den Teil des lokalen örtlichen Ausführplans (LEP) zu kontrollieren, der von der lokalen örtlichen Datenbank erhalten wurde und

- in Übereinstimmung mit den in der intelligenten Datenwörterbucheinrichtung (SSD) enthaltenen Daten Erzeugen einer Datenausleseanfrage zur Ausführung durch irgendeine andere lokale örtliche Datenbank, die notwendig ist, um den Teil des lokalen örtlichen Ausführplans zu vervollständigen, der davon zur Ausführung erhalten wurde.

13. Verfahren nach Anspruch 11 oder 12, bei dem der Schritt des Aufspaltens der globalen Anfrage ferner umfaßt:

- syntaktisches Analysieren und Validieren der Syntax der globalen Anfrage;

- Identifizieren der geeigneten lokalen örtlichen Datenbank, die die angeforderten Daten enthält, indem die intelligente Datenwörterbuchdatenbank (SSD) angesprochen wird, um Information über das lokale Abfrageprotokoll und über das Datensemantik-Schema zu erhalten, das für jede einzelne lokale örtliche Datenbank erstellt wurde, und um eine Mehrzahl von lokalen örtlichen Datenbankanfragen zum Auslesen der Antwortdaten aus jeder der lokalen Datenbanken, die solche Antwortdaten enthalten, zu erzeugen;

- Optimieren der Mehrzahl von lokalen Anfragen, um einen lokalen Ausführplan (LEP) zu erzeugen, der die Gesamtzeit zum Ausführen der globalen Anfrage optimiert, indem die Anzahl von Daten minimiert werden, die zwischen lokalen Orten übertragen werden müssen, und indem der geeignete Ursprungsort zum Verarbeiten des lokalen Ausführplans (LEP) ausgewählt wird;

- Koordinieren der Ausführung des Teils des lokalen Ausführplans (LEP), der auf jede der lokalen Datenbanken zutrifft, indem:

(a) jeder lokalen Informationsmanager-Einrichtung (LIM) (22) der Teil des lokalen Ausführplans (LEP) gesandt wird, der auf Datenanfragen von seiner zugeordneten lokalen Datenbank anwendbar ist;

(b) jeder lokalen Informationsmanager-Einrichtung (LIM) (22) eine Anfrage gesandt wird, um einen lokalen Ausführplan auszuführen;

(c) jeder lokalen Informationsmanager-Einrichtung (LIM) (22) eine Anfrage zur Vervielfältigung von relevanten Antwortdatenfragmenten gesendet wird;

(d) eine Anfrage an jede lokale Informationsmanager-Einrichtung (LIM) (22) gesendet wird, um eine lokale Datenanfrage asynchron bei der zugeordneten lokalen Datenbank auszuführen;

(e) eine Anforderung an jeden lokalen Informationsmanager (LIM) (22) gesendet wird, um synchron Antwortdaten auf die lokale Datenanfrage zu dem lokalen Informationsmanager (LIM) (22) für den Ursprungsort zu senden, außer bei der Ursprungsdatenbank und

(f) die erhaltenen Daten zur Übertragung an den anfordernden Benutzer (12) archiviert werden.