DE69523142T2

DE69523142T2 - Verteiltes datenbanksystem

Info

Publication number: DE69523142T2
Application number: DE69523142T
Authority: DE
Inventors: Anders Bjoernerstedt; Mikael Samuelsson
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 1994-02-08
Filing date: 1995-02-06
Publication date: 2002-01-31
Anticipated expiration: 2015-02-07
Also published as: AU1723695A; EP0744055A1; MX9602918A; MX9702366A; SE9400410L; KR970701393A; US5761672A; TW346580B; KR100293795B1; JPH09508734A; NO963281L; NO963281D0; AU687168B2; WO1995022111A1; FI963107L; SE515344C2; CN1140500A; FI963107A0; SE9400410D0; FI963107A7

Description

Technisches Gebiet

Die vorliegende Erfindung betrifft allgemein ein verteiltes objektorientiertes Datenbanksystem, in dem unterschiedliche Teile der Datenbank jeweils durch einen einer Anzahl von miteinander verbundenen Prozessoren gehandhabt wird, und wobei die unterschiedlichen Datenbankteile eine Anzahl von Objekten enthalten.
Insbesondere betrifft die Erfindung eine Datenbankverteilung, was in dem gegenwärtigen Zusammenhang bedeutet, wie Objekte adressiert und in dem Datenbanksystem verteilt werden.

Stand der Technik

In einem Objekt orientierten, verteilten Datenbanksystem kann es sein, dass jeder der enthaltenen Prozessoren auf Objekte in seinem eigenen Datenbankabschnitt und auch in den Datenbankteilen von anderen Prozessoren zugreifen muss. Für jedes Objekt gibt es daher Information bezüglich des Subnetzwerks und des Prozessors, in dem das Objekt existiert, Information bezüglich eines Agenten in einem anderen Prozessor, der einen erwünschten Dienst ausführt, z. B. ein Objekt holt, und Information darüber, wo genau in dem Speicher des Prozessors das fragliche Objekt angeordnet ist. Wenn alle diese Informationen auf allen Prozessoren verfügbar ist, hat dies sehr große Adressierungstabellen zur Folge, und Massenaktualisierungen der Adresse der Objekte über das gesamte Datenbanksystem, wenn ein Objekt erzeugt wird, entfernt oder bewegt.
EP 405 829 betrifft ein Telekommunikationssystem, in dem die Software mittels unabhängiger Softwarekomponenten in Form von Objekten implementiert ist. Eine Funktion "runtime linker (Laufzeitverknüpfer)" in einem "Runtime(Laufzeit)-System" zeichnet die Objekte auf und speichert einen Datenpointer auf die Daten des Objekts. Um mit einem anderen Objekt zu kommunizieren, überträgt ein Quellobjekt eine Nachricht an das Laufzeitsystem. Die Nachricht umfasst einen Namen und eine Identität des Verfahrens und des Zielobjekts.
Das Laufzeitsystem dient nur einem einzelnen Prozessor oder einer Gruppe von Prozessoren und ruft das Zielobjekt mittels der Identität des Verfahrens und des Datenpointers auf, falls das Zielobjekt zu einer Gruppe von Objekten gehört, die durch das Laufzeitsystem bedient werden. Falls das Zielobjekt auf einem anderen Prozessor angeordnet ist, sendet das Laufzeitsystem die Nachricht zu anderen Prozessoren aus. In jedem der empfangenden Prozessoren sucht das Laufzeitsystem seine "linker table(Verknüpfungstabelle)" für den symbolischen Namen des Zielobjekts, und falls aufgefunden, ruft es das Zielobjekt auf Grundlage des in der Nachricht identifizierten Verfahrens und der Datenpointerinformation in dem Laufzeitverknüpfer auf. Zwischenprozessorennachrichten umfassen eine Quellprozessorbezeichnung, und das Laufzeitsystem eines jeden der Prozessoren speichert den Namen des Quellprozessors und den symbolischen Namen des Quellobjekts, wenn eine Zwischenprozessornachricht empfangen wird.
Eine "Alias-Tabelle" enthält alle "Alias-Namen" des lokalen Prozessors registriert. Falls ein Namen nicht in der Alias- Tabelle aufgelistet ist, wird eine Untersuchung mit Bezug darauf getätigt, ob das Zielobjekt in der Verknüpfertabelle angeordnet ist. Falls die Antwort Nein ist, wird eine Untersuchung in einer Zieltabelle durchgeführt, und falls der Name des Zielprozessors bekannt ist, wird eine Nachricht an den Zielprozessor ausgesendet.
In der US 4,901,231 ist ein Multiprozessorsystem beschrieben, das über einer Vielzahl von Prozessoren ausgeführt wird. Ein Benutzerprozess in einem Prozessor kann auf Systemresourcen in den anderen Prozessoren zugreifen. Wenn ein Prozessor auf eine lokale Datei zugreift, wird der Zugriff i. a. mittels einer Nutzerdateitabelle getätigt. Wenn der Benutzerprozess auf eine entfernt liegende Datei zugreift, wird der Zugriff über eine Port-Tabelle, über einen mittels der Port-Tabelle identifizierten virtuellen Kanal zu einem Teilprozess, und dann über die Benutzerteiltabelle und Systemdateitabelle des Teilprozesses getätigt.
Die US 5,187,790 betrifft ein Computersystem mit einer Vielzahl von gleichzeitig laufenden Prozessen, einschließlich mindestens eines Serverprozesses und einer Vielzahl von Client Prozessen. Jeder Prozess weist eine Liste von Identitäten auf, die Objektzugriffsrechte repräsentieren. Jedes Objekt weist eine Zugriffsprüfliste auf, mit Identitäten, die für ein Bestimmen des Prozessors zu verwenden sind, der auf das Objekt zugreifen kann.

Zusammenfassung der Erfindung

Es ist eine allgemeine Aufgabe der vorliegenden Erfindung, ein System des auf dem Wege der Einleitung definierten Typs bereitzustellen, das mit einer geringen Menge von Adressinformation arbeiten kann, die zu speichern ist, zu erhalten und zu verteilen.
Es ist eine weitere Aufgabe der Erfindung, ein System des auf dem Wege der Einführung definierten Typs bereitzustellen, das eine einfache manuelle Konfiguration in einer Anwendung erlaubt (d. h. ein Programm, das in der Datenbank schreibt und liest), und auch in der Datenbank, und das im Falle der Erzeugung eines Objekts eine nicht notwendige Bemerkung abgibt bezüglich des Prozessors, zu dem es gehört, d. h. dies soll vordefiniert sein.
Weitere Aufgaben der Erfindung sind es, ein System des mittels der Einführung definierten Typs bereitzustellen, das eine flexible Verteilung erlaubt, und eine Redundanzänderung, das Dienstaufrechterhaltunb und Verfügbarkeit garantiert, d. h. es dürfen nicht zu viele Adressinformationen sein, die im Falle einer Redundanzänderung zu aktualisieren sind.
Gemäß einem ersten Gesichtspunkt der Erfindung werden diese Aufgaben in einem objektorientierten, verteilten Datenbanksystem gelöst, in dem unterschiedliche Teile einer Datenbank durch ein in einer Anzahl von miteinander verbundenen Prozessoren gehandhabt werden. Die unterschiedlichen Datenbankteile umfassen eine Anzahl von Objekten. Für jedes solches Objekt besteht globale Information bezüglich des Prozessors, in dem das Objekt lokalisiert ist, und lokaler Information darüber, wo das Objekt in dem eigenen Prozessor lokalisiert ist.
In Übereinstimmung mit der Erfindung ist die globale Information identisch für und in jedem Prozessor in dem System lokalisiert und umfasst Information bezüglich einer Anzahl von Verteilungseinheiten, von denen jede Information bezüglich einer Anzahl von Instanzen einer bestimmten Objektklasse enthält, angeordnet in einem bestimmten Prozessor, und Information, mittels der die Adresse zu diesem Prozessor gefunden werden kann.
Die Objekte sind adressierbar, entweder mittels Schlüsselwerten, falls ein Objekt, auf das zuzugreifen ist, nicht in dem gleichen Prozessor vorhanden ist, wie ein zugreifender Prozess, oder mittels Objektidentitäten einschließlich lokaler und globaler Objektidentitäten, wobei jede lokale Objektidentität ein erstes Informationsfeld enthält, das den eigenen Prozessor identifiziert, und ein zweites Informationsfeld, das das Objekt identifiziert, und wobei jede globale Objektidentität ein erstes Informationsfeld umfasst, das eine Verteilungseinheit identifiziert, und ein zweites Informationsfeld, das das Objekt identifiziert.
Jeder Prozessor umfasst eine erste Tabelle, die lokale Objektidentitäten enthält, die auf Objekte in dem gleichen Prozessor zeigen, und eine zweite Tabelle, die eine erste Spalte für Verteilungseinheitsnummern enthält, und eine zweite Spalte, die allgemein auf Prozessoren zeigt, und eine dritte Tabelle, die objektidentifizierende Schlüsselwerte enthält, mit einem jeden Prozessor verknüpft, und eine vierte Tabelle, die eine erste Spalte für globale Objektidentität und eine zweite Spalte für Pointer auf ein entsprechendes Objekt in dem Speicher des Prozessors enthält.
Gemäß einem zweiten und dritten Gesichtspunkt werden die aufgeführten Aufgaben der Erfindung mit einem Verfahren gelöst, um auf ein Objekt zuzugreifen, das zu einer speziellen Klasse in einem verteilten objektorientierten Datenbanksystem in Übereinstimmung mit dem ersten Gesichtspunkt gehört.
In Übereinstimmung mit der Erfindung umfasst das Verfahren gemäß des zweiten Gesichtspunkts
ein Beginnen einer Suche für das Objekt, zuerst in dem eigenen Prozessor, mittels eines Schlüsselwertes und einer Objektklassennummer in der dritten Tabelle, und,
falls diese Suche ergibt, dass das Objekt nicht in dem gleichen Prozessor vorhanden ist,
erzeugen, mittels einer Transformationsfunktion, einer logischen Verteilungseinheitsnummer, die Information bezüglich einer Anzahl von Instanzen der Klasse des Objektes identifiziert, die in einem bestimmten Prozessor lokalisiert sind, und Adressinformation bezüglich dieses Prozessors,
Erzeugen einer entsprechenden physikalischen Verteilungseinheitsnummer, durch Kombinieren von Information bezüglich der Klasse des Objekts und der lokalen Verteilungseinheitsnummer,
Identifizieren des Prozessors in der Datenbank, in der das gesuchte Objekt lokalisiert ist, Durchsuchen mittels der physikalischen Verteilungseinheitsnummer in der zweiten Tabelle,
Senden der Nachricht mit einer Objektklassennummer und einem Schlüssel und Operationsinformation zu dem fraglichen Prozessor,
lokales Suchen in der dritten Tabelle des gefundenen Prozessors nach dem Objekt, auf das zuzugreifen ist, mittels des Schlüsselwertes,
Zurückliefern einer Kopie des gefundenen Objektes zu dem Prozessor, der den Zugriff angefordert hat.
In Übereinstimmung mit der Erfindung umfasst ein Verfahren gemäß dem dritten Gesichtspunkt
ein Beginnen einer Suche in der ersten Tabelle des lokalen Prozessors, um zu versuchen, um dort das Objekt mittels der lokalen Objektidentität zu finden, und,
falls diese Suche ergibt, dass das Objekt nicht in dem eigenen Prozessor lokalisiert ist,
Umwandeln der lokalen Objektidentität in eine globale Objektidentität,
Suchen in der zweiten Tabelle des Prozessors, in dem das Objekt, auf das zuzugreifen ist, lokalisiert ist, mittels der Verteilungseinheit, die in der globalen Objektidentität enthalten ist,
Senden einer Nachricht zu dem fraglichen Prozessor, in der die globale Objektidentität enthalten ist,
Suchen der Objektidentität in der vierten Tabelle in dem mittels der globalen Objektidentität gefundenen Prozessor,
Zurückliefern einer Kopie der gefundenen Objektidentität zu dem Prozessor, der den Zugriff begonnen hat.

Kurze Beschreibung der Zeichnungen

Die Erfindung und verschiedene Ausführungsbeispiele davon werden nun genauer mit Bezug auf die beigefügten Figuren beschrieben:
Fig. 1 zeigt schematisch ein verteiltes Datenbanksystem,
Fig. 2 dient einer Veranschaulichung von Adressierungsprinzipien in einem bekannten System der in Fig. 1 gezeigten Art,
Fig. 3 soll die allgemeinen Adressierungsprinzipien gemäß der Erfindung in einem Datenbanksystem des in Fig. 1 gezeigten Typs veranschaulichen,
Fig. 4 und 5 veranschaulichen schematisch eine Adressierung gemäß der Erfindung in dem Fall, dass das gesuchte Objekt in dem gleichen Prozessor bzw. in einem anderen Prozessor angeordnet ist,
Fig. 6a-c zeigen die Inhalte in Objekteinheiten, die in den in Fig. 4 bzw. 5 gezeigten Prozessoren involviert sind,
Fig. 7 zeigt Adressierungstabellen, die in Verbindung mit den Prozessoren gemäß Fig. 4 und 5 verwendet werden,
Fig. 8 zeigt eine Datei, in der eine Zuordnung von Konsequenzen von Verteilungseinheiten auf unterschiedliche Prozessoren spezifiziert ist,
Fig. 9 zeigt eine Datei, die die Verteilung von Verteilungseinheiten für jede Objektklasse beginnt,
Fig. 10 veranschaulicht die Prinzipien für ein Laden von Verteilungseinheiten auf mehreren Prozessoren mittels der Information in Fig. 8 und 9,
Fig. 11 veranschaulicht einen Zugriff eines Objekts mittels eines Schlüssels im Falle, dass das Objekt nicht lokal in dem gleichen Prozessor existiert wie der zugreifende Prozess,
Fig. 12 zeigt eine Ansicht einer physikalischen Identität einer Verteilungseinheit,
Fig. 13 zeigt schematisch eine Tabelle, die in Verbindung mit einer Übersetzung der Nummer einer Verteilungseinheit in eine Netzwerkadresse verwendet wird und dieses veranschaulicht,
Fig. 14 veranschaulicht zwei Fälle von Suchprozessen, gerichtet auf ein Masterobjekt in einem anderen Prozessor, und Abzielen auf ein transparentes Übertragen eines Kopieobjektes dieses Masterobjekts zu dem eigenen Prozessor,
Fig. 15 zeigt eine schematische Tabelle, verwendet für den Suchprozess in einem der Fälle gemäß Fig. 14, und dieses veranschaulicht,
Fig. 16 veranschaulicht die Übertragung des Kopieobjekts, nachdem der Suchprozess gemäß Fig. 14 eine Detektion des Masterobjekts vergeben hat,
Fig. 17 zeigt ein Flussdiagramm, das einen der Fälle der Suchprozesse zusammenfasst, die mit Bezug auf Fig. 11 bis 16 beschrieben wurden,
Fig. 18 zeigt ein Flussdiagramm, das den zweiten Fall der Suchprozesse zusammenfasst, die mit Bezug auf Fig. 11 bis 16 beschrieben wurden.

Bevorzugte Ausführungsbeispiele

In Fig. 1 ist schematisch ein verteiltes Datenbanksystem veranschaulicht, von dem angenommen wird, dass es objektorientiert ist, d. h. dass dessen Daten als Objekte organisiert sind. Ein Objekt ist in diesem Zusammenhang eine zusammengehaltene Datenmenge, die entweder direkt gelesen werden kann, oder durch ein Aufrufen von Verfahren in dem Objekt. Konzepte, die unterhalb in dieser Verbindung verwendet werden, sind Objektklasse oder Typ, Attribute und Instanzen. Ein Beispiel einer Objektklasse können Objekte sein, die Information von Telefonteilnehmern darstellen. Dieses Objekt kann dann Attribute, wie beispielsweise Telefonnummer und die Nummer der Leitungsschaltung enthalten. Instanzen des Objektes bilden unterschiedliche Teilnehmer.
Das System umfasst drei Unternetzwerke, bezeichnet 2, 4 bzw. 6. Die Unternetzwerke 2, 4 und 6 umfassen vier, sechs bzw. acht Prozessoren, mit denen in jedem Unternetzwerk einer mit 8, 10 bzw. 12 bezeichnet ist. Die Prozessoren in jedem Unternetzwerk sind miteinander verbunden mittels Verbindungen, die mit 14, 16 bzw. 18 bezeichnet sind, für die jeweiligen Unternetzwerke 2, 4 und 6. Die Unternetzwerke 2, 4 und 6 sind mittels Verbindungen 20 und 22 miteinander verbunden.
Jeder der Prozessoren, der in dem verteilten Datenbanksystem enthalten ist, kann in dem jeweiligen zugehörigen Teil, in Fig. 1 nicht gezeigt, der Gesamtdatenbank eine Anzahl von Objekten enthalten, auf die möglicherweise von den anderen Prozessoren zugegriffen werden muss. In Verbindung mit jedem Objekt besteht herkömmlicherweise, neben Teilinformation bezüglich des Unternetzwerks und des Prozessors, in dem das Objekt lokalisiert ist, und Teilinformation bezüglich eines Agenten in einem anderen Prozessor, der einen erwünschten Dienst durchführt, auch Teilinformation bezüglich wo genau das fragliche Objekt in dem Speicher des Prozessors angeordnet ist. Die gerade erwähnte Teilinformation bezüglich eines Agenten in einem anderen Prozessor wird im Folgenden in manchen Fällen als "Kommunikationsprozess" bezeichnet. Die Dienste, die in dem vorliegenden Fall interessieren können, wie unterhalb genauer beschrieben, sind Objekte in dem Speicher des Prozessors, und Handhaben der Kommunikation zwischen dem eigenen Prozessor und einem anderen Prozessor.
Falls die Gesamtinformation, die aus diesen Teilinformationen besteht, für alle Prozessoren verfügbar wäre, hätte das sehr große Adressierungstabellen zur Folge, und würde Massenaktualisierungen der Adresse der Objekte über dem gesamten Datenbanksystem erforderlich machen. Dies ist in Fig. 2 veranschaulicht, das einen Teil des Datenbanksystems zeigt, nämlich das Unternetzwerk 2. Jeder der vier Prozessoren 8 ist schematisch mit einer Adressierungstabelle 24 gezeigt, die die gleiche für alle Prozessoren ist. Jede Adressierungstabelle 24 weist Pointer auf alle Objekte in dem eigenen Prozessor und in allen anderen Prozessoren auf, die in dem Datenbanksystem enthalten sind. Dies ist mittels einiger Pfeile 26 veranschaulicht, die auf einige Objekte 28 zeigen. Zum Zwecke einer Klarheit wurden solche Pfeile von den Prozessoren entfernt, die in der Figur rechts angeordnet sind. Jedesmal, wenn ein neues Objekt erzeugt wird, muss dessen Adresse auf alle anderen Prozessoren verteilt werden, oder alternativ in einem zentralen Katalog aufgezeichnet werden, von dem die Adressinformation bei einem Zugriff erhalten werden kann. Dieses ergibt große Flexibilität mit Bezug auf die Verteilung von Objekten, erzeugt jedoch sehr große Adressierungstabellen.
In Fig. 2 ist auch ein Pfeil 30 enthalten, der auf eine der Adressierungstabellen 24 zeigt, um die Einführung eines Objektidentifizierungsschlüsselwertes in die fragliche Tabelle anzuzeigen, vorgesehen dazu, einen Zugriff auf eines der in dem Datenbanksystem enthaltenen Objekte zur Folge zu haben.
Kurz gesagt, basiert die Erfindung auf dem Gedanken, dass globale Information, die i. a. anzeigt, auf welchem Prozessor ein Objekt lokalisiert ist, für eine größere Anzahl von Objekten gemeinsam ist. Wie dies unterhalb detaillierter beschrieben wird, ist diese globale Information identisch für alle Prozessoren. Zum Zwecke einer Klarheit ist dies in Fig. 3 in der Form einer Adressierungstabelle veranschaulicht, die nur für einen der Prozessoren bei 32 gezeigt ist.
Die globale Information 32 umfasst Information bezüglich einer Anzahl von Verteilungseinheiten, von denen jede Information bezüglich einer Anzahl von Instanzen einer bestimmten Objektklasse enthält.
In Fig. 3 werden einige dieser Verteilungseinheiten mit 34 bezeichnet. Für jede solche Verteilungseinheit 34 ist auch in der Tabelle 32 aufgeführt, zu welchem Prozessor sie gehört. Der Schlüsselwert, der in Verbindung mit Fig. 2 erwähnt wurde, ist, wie bei 36 gezeigt, in einen Index entsprechend einer bestimmten Verteilungseinheit 34 transformiert. Die Tabelle 32 wird daher für jede Verteilungseinheit 34 einen Adresspointer enthalten, der auf einen bestimmten Prozessor zeigt, zu dem die fragliche Verteilungseinheit gehört. Eine Anzahl solcher Adresspointer sind in Fig. 3 bei 38, 40, 42 bzw. 44 gezeigt. Insbesondere zeigt dieser Pointer auf eine weitere Tabelle 46, die in jedem Prozessor angeordnet ist, für die weitere Adresspointer 48 auf Objekte zeigen, die in den Verteilungseinheiten 34 in der entsprechenden Unterdatenbank zeigen. Einige dieser Objekte sind als Punkte 50 gezeigt.
Ausführungsbeispiele des Adressierungsprinzips gemäß der Erfindung werden nun detaillierter mit Bezug auf die folgenden Figuren beschrieben.
Wie dies aus einer Anwendungsebene zu sehen ist, kann eine Datenbankaufzeichnung auf zwei Weisen adressiert werden, nämlich mittels eines Schlüssel oder mittels einer Datenobjektidentität.
In Fig. 4 ist ein Nutzerprozess mit 52 bezeichnet, und ein Prozessor mit 54 bezeichnet. Der Prozess 52 greift mittels eines Schlüsselwertes auf ein Attribut 56 eines Objekts 58 zu, das in dem Speicher des Prozessors 54 enthalten ist. Der Zugriff, durch einen Pfeil 60 bezeichnet, wird durch ein Verfahren in einem Agentenobjekt 62 getätigt, erzeugt zum Zwecke des Nutzerprozesses 52. In Reaktion darauf gibt das Objekt 58, Pfeil 64, eine lokale Objektidentität, die in dem Attribut 56 gespeichert ist, zurück, die auf ein anderes Objekt 66 in dem Speicher des Prozessors 54 Bezug nimmt. Die Bezugnahme wird mittels eines Pfeils 68 bezeichnet. Der Prozess 22 öffnet nun das Objekt 66 mittels der lokalen Objektidentität und erzeugt ein zweites Agentenobjekt 70, enthaltend ein Verfahren, mittels dem Attribute in dem Objekt 66 gelesen werden können, Pfeil 72. In Fig. 4 wird eine Objektidentität somit für eine Adressierung eines Objekts in dem gleichen Prozessor verwendet.
Der Umweg über das Objekt 58 zum Erreichen des Objekts 66 in Fig. 4 setzt voraus, dass es von Beginn an bekannt ist, dass eine Referenz in dem Objekt 58 zu dem Objekt 66 gesucht werden soll, und ist nur ein Beispiel. In objektorientierten Datenbanken sind Daten allgemein auf solche Weise modelliert, dass ein Zugriff ein "Navigieren" in der Datenbank erfordert, d. h. einem Folgen von Referenzen von Objekt zu Objekt.
Die Situation in Fig. 5 unterscheidet sich von der in Fig. 4 darin, dass das Objekt, auf das zuzugreifen ist, in einem anderen Prozessor 74 lokalisiert ist, wo es mit 66' bezeichnet ist. In diesem Fall ist in dem Speicher des Prozessors 54 eine Kopie 66" des Objekts 66' erzeugt, und der Nutzerprozess 52 greift auf Attribute in der Kopie 66", bezeichnet durch einen Pfeil 72', mittels des Agentenobjekts 70 zu. Dieses wird im Weiteren detaillierter beschrieben.
Wie es sich aus dem Obigen ergibt, kann die Objektidentität durch die Anwendung zum Zugreifen auf Objekte verwendet werden, lokal oder in einem anderen Prozessor. Falls das Objekt nicht lokal in dem eigenen Prozessor existiert, wie beispielsweise in Fig. 5, wird der verteilte Zugriff auf einen anderen Prozessor für die Anwendung transparent gehandhabt, sogenannte versteckte Verteilung. Die Objektidentität wird dann durch eine Verteilungslogik der Datenbank in eine globale Objektidentität umgewandelt. Die Objektidentität kann jedoch auch durch die Anwendung in ihrem eigenen Verteilungsprotokoll verwendet werden, sogenannte offene Verteilung, wird jedoch dann zuerst für eine externe Verwendung durch die Anwendung umgewandelt, insbesondere in die globale Objektidentität.
Mit Bezug auf Fig. 6a kann eine Objektidentität der oben diskutierten Art zwei Felder enthalten, z. B. jedes für 32 Bits. Das erste Feld identifiziert die Verteilungseinheit, zu der das Objekt gehört, und das andere Feld zeigt eine serielle Nummer an, die das Objekt identifiziert. Die Identität der Verteilungseinheit wird durch ein Unterstützungssystem außerhalb des Datenbanksystems erzeugt, und die serielle Nummer wird bei einer Instantiierung des Objekts in einem Anwendungssystem zugeordnet, d. h. Programme, die in der Datenbank lesen und schreiben. Die Verwendung zwischen dem extern sichtbaren Namen des Objekts und der Verteilungseinheit wird in einer Designphase bestimmt und wird dann während der Lebensdauer des Anwendungssystems nicht geändert.
In dem Beispiel von Fig. 4 weist die Objektidentität einen Wert, z. B. 0, in dem ersten Feld auf, um anzuzeigen, dass das Objekt, d. h. 66, in dem eigenen Prozessor angeordnet ist, und daher wird die Bezeichnung "lokale Objektidentität" dafür verwendet, vgl. Fig. 6b. Im Falle gemäß Fig. 5 und mit Bezug auf Fig. 6c wird die Objektidentität in eine globale Objektidentität umgewandelt, wie erwähnt. Wie es unterhalb genauer beschrieben wird, wird dies durch ein Vergeben eines Verteilungseinheitswertes an das erste Feld in der Objektidentität durchgeführt, was dafür verwendet werden kann, den Prozessor herauszufinden, zu dem das Objekt gehört.
Mit Bezug auf Fig. 7 und auf das in Verbindung mit Fig. 3 bis 5 beschriebene, enthält jeder Prozessor vier Tabellen 779, 80, 82 bzw. 84.
Die Tabelle 79 ist eine Tabelle für objektidentifizierende Schlüsselwerte. Die Tabelle 79 wird in dem Fall gemäß Fig. 4 verwendet, durch den Prozess 52, zum Finden des Objekts 58 mittels eines Pointers, der in der Tabelle im Zusammenhang mit dem momentanen Schlüsselwert lokalisiert ist. Obwohl nicht gezeigt, versteht es sich, dass solch eine Schlüsseltabelle 79 für jede geschlüsselte Objektklasse in jedem Prozessor vorhanden sein kann.
Die Tabelle 80 umfasst die lokalen Objektidentitäten, die auf Objekte in dem gleichen Prozessor zeigen, im Folgenden "der eigene Prozessor" bezeichnet. In dem Fall gemäß Fig. 4 sieht der Datenbasismanager die null in dem ersten Feld und greift auf die Tabelle 80 zu, so dass das Objekt 66 gefunden wird. Die Tabelle 82 enthält zwei Spalten 86 und 88, die erste Spalte 86 für eine Verteilungseinheitsnummer, und die zweite Spalte 88, die allgemein auf einen anderen Prozessor zeigt, oder, logisch, auf einen Datenbankmanager in diesem anderen Prozessor. In dem vorliegenden Beispiel wird angenommen, dass die zweite Spalte auf einen Kommunikationsanschluss der in dem US-Patent 5,606,659 beschriebenen Art zeigt und im Zusammenhang steht mit einer Aktivitätsverarbeitung in dem zweiten Prozessor. Insbesondere, und kurz gesagt, ist ein Kommunikationsanschluss gemäß dem US-Patent, im Folgenden aus Einfachheitsgründen nur Port genannt, dazu vorgesehen, einen Resourcentyp zu bezeichnen, der zu dem Kommunikationsmechanismus eines Betriebssystems gehört, und den eine Aktivität verwendet, um eine Verbindung einzurichten. Das Konzept einer Aktivität wird in der gleichen US-Patentanmeldung verwendet, um eine Kette von Aufgaben zu definieren, die in einem Betriebssystem als ein Ergebnis eines unabhängig externen oder internen Ereignisses erzeugt wird, plus der Summe der Resourcen, die die Kette während ihrer Ausführung verwendet. Durch eine Aufgabe wird darüber hinaus ein Phänomen bezeichnet, immer noch in dem fraglichen US-Patent, das auf einen Prozess ausgerichtet ist, so dass eine Methode in einem Objekt, das der Prozess besitzt, ausgeführt wird, wobei eine Aufgabe in diesem Zusammenhang in der Lage ist, neue Aufgaben zu erzeugen, die auf andere Prozesse oder den eigenen Prozess gerichtet sind.
Die Tabelle 84, die der Tabelle 46 in Fig. 3 entspricht, enthält zwei Spalten 84', 84", von denen die erste für die globale Objektidentität steht, und die andere für Pointer auf entsprechendes Objekt in dem Speicher des Prozessors.
In der untenstehenden Beschreibung des Falls gemäß Fig. 5 wird das Konzept "Port" der Klarheit halber durch das zugeordnete Konzept "Prozessor" oder "Datenbankmanager" gemäß der obigen Erläuterung ersetzt.
Im Fall von Fig. 5 greift der Datenbankmanager in dem eigenen Prozessor 54 allgemein gesagt auf die Tabelle 82 dieses Prozessors zu und findet den Prozessor 74 in Übereinstimmung mit dem Pfeil 89. Eine Nachricht wird an den Datenbankmanager in dem anderen Prozessor 74 übersendet, wobei die Nachricht i. a. einen Indikator enthält, der anzeigt, ob das Objekt mittels eines Schlüssels oder einer globalen Objektidentität gesucht werden soll. Falls die globale Objektidentität bekannt ist, was in Fig. 5 angenommen wird, fährt der Datenbankmanager in dem Prozessor 74 mit dem Suchprozess fort, gemäß Pfeil 90, durch Zugreifen auf die Tabelle 84 des Prozessors 74 mit der globalen Objektidentität der Spalte 84' für globale Objektidentitäten. Auf der gleichen Linie wie die gefundene globale Objektidentität in Tabelle 84, jedoch in der anderen Spalte 84", wird der Pointer auf das Objekt 66' gefunden, in Übereinstimmung mit einem Pfeil 92.
Falls alternativ der Indikator anzeigt, dass die Suche mittels eines Schlüssels zu tätigen ist, wie beispielsweise im Falle, dass keine globale Objektidentität vorhanden ist, richtet der Datenbankmanager in dem Prozessor 74 den Suchprozess gemäß Pfeil. 94 auf die Tabelle 79 des Prozessors 74. Mittels des Schlüsselwertes des gesuchten Objekts 93 wird die Adresse dieses Objektes dort gefunden, in Übereinstimmung mit Pfeil 95.
Falls im Falle nach Fig. 5 weitere Objekte in dem Speicher des Prozessors 74 sein sollten, die zur gleichen Verteilungseinheit gehören, d. h. Objekte mit der gleichen Nummer der Verteilungseinheit, jedoch einer anderen seriellen Nummer, wird der Prozess zum Prozessor 74 übertragen.
Mit Bezug auf Fig. 8-18 werden nun zwei praktische Ausführungsbeispiele beschrieben, wobei u. a. die Verwendung der Tabellen 79, 80, 82, 84 detaillierter in Erscheinung treten wird.
In der Objektklassenbeschreibung unten wird eine beständige Objektklasse in einer verwendeten Sprache spezifiziert, um Objektklassen zu beschreiben, z. B. DELOS, was erwähnt wird in dem Journal Tele, Nr. 4/93, in einem Artikel mit dem Titel "Development of Software" von Göte Andersson. Insbesondere besteht die Frage eines Objekts der Klasse Subscriber, das 2 Attribute enthält, von denen eines ein primärer Schlüssel ist, d. h. ein Verteilungsattribut.
OBJECT TYPE Subscriber IS
PERSISTENT PROPERTIES
PRIMARY KEY subscrNum;
- -MDP-sequence 0..logicalMDPhigh
ATTRIBUTES
subscrNum. SubscriberNumber;
iAge: Integer
END;
TYPE SubscriberNumber IS STRING (ISO8859) END;
In dieser Darstellung definiert die erste Zeile die Objektklasse, d. h. Subscriber die nächste Zeile bezeichnet Speichereigenschaften. Danach folgt ein Statement des Namen des Attributs PRIMARY KEY, d. h. subscrNum.
In der Definition --MDP-sequence 0...logicalMDPhigh steht MDP (Master Data Partition) für Verteilungseinheit. Die Definition ist eine Information bezüglich der maximalen Verteilbarkeit der Objektklasse, d. h. der Maximalanzahl von Verteilungseinheiten der fraglichen Objektklasse. Die fragliche Information wird zum Erzeugen von Eingabedaten für einen Konfigurierungsschritt verwendet, der unterhalb genauer beschrieben ist, und um zu erlauben, dass das System während einer Laufzeit überprüfen kann, dass die Funktion keyToMDP, ebenso unterhalb detaillierter beschrieben, keine Werte außerhalb des deklarierten Bereichs zurückliefert.
In der ersten Zeile unter ATTRIBUTES ist aufgeführt, dass subscrNum den Typ Subscriberwumber aufweist, und in der zweiten Zeile, dass die Methode subscrNum mit dem Namen iAge vom Typ Integer ist. In beiden Fällen besteht die Frage von vordefinierten Typen.
In der letzten Zeile in der Repräsentation wird mit "IS STRING" eine Eigenschaft des Attributtyps SubscriberNumber genauer definiert, nämlich dass das Attribut als eine Abfolge von Ziffern bezeichnet ist.
Aus der obigen Objektklassenbeschreibung, und auch aus der folgenden ähnlichen Beschreibung von Methoden im Zusammenhang mit der Objektklasse, wird ein Code erzeugt, in einer speziellen Datendefinitionssprache, durch einen Compiler für diese Sprache. Die folgende Beschreibung, und auch die obige Beschreibung, ist beispielhaft auf die Verwendung von Agentenobjekten basiert, die in der veröffentlichten, schwedischen Patentanmeldung 9302175-6 beschrieben sind, um einen Datenzugriff zu erhalten, im Falle einer Verwendung der Zugriffsmethode gemäß der Erfindung. In dieser schwedischen Patentanmeldung wird auch eine Erzeugung von Code beschrieben, wie sie hier angezeigt ist, und daher ist an dieser Stelle keine genauere Beschreibung erforderlich. Das fragliche Agentenobjekt wird als DOA bezeichnet, in der gleichen US-Patentanmeldung, was für "Data Objekt Agent" steht, und die gleiche Bezeichnung wird hier weiter manchmal verwendet.
Bei einer Methode zum Umwandeln des Schlüsselwertes in eine Verteilungseinheit wird das Methodenrahmenwerk durch DELOS erzeugt, es muss jedoch der Anwendungsentwickler angeben, wie der Schlüssel in eine Verteilungseinheitsnummer zu übersetzen ist. Der Algorithmus bildet Teil der DOA-Klasse und ist unabhängig von der adressierten Objektklasse. Im vorliegenden Fall wird angenommen, dass der primäre Schlüssel = die Telefonnummer 1111122. Die fragliche Methode wird durchgeführt durch:
DicosDbMDP
Subscriber: keyToMdp (key)
wobei keyToMdp als eine Transformationsfunktion bezeichnet wird, die unterhalb genauer beschrieben wird.
In dem vorliegenden Beispiel wird angenommen, dass die zwei riiedrigstwertigen Ziffern 22 mit einem Wertebereich von 00 → 99 maskiert werden. Die maskierten Werte werden somit eine Verteilungseinheitsnummer 22.
Die Methode wird durch beide Operationen create(instance) und open(instance) verwendet, d. h. Erzeugung bzw. Öffnung von Instanzen.
Um auf ein Objekt zuzugreifen, d. h. Lesen oder Schreiben, wird eine lokale Kopie des Objekts installiert, vgl. 66" in Fig. 5, in dem ausführenden Prozessor, wie es sich aus der obigen Beschreibung mit Bezug auf Fig. 5 ergibt. In diesem Zusammenhang wird auf zwei Typen von Kopien Bezug genommen, nämlich "lazy" (ruhende) Kopien und "agile" (aktive) Kopien. Default (Voreinstellung), was immer verwendet werden kann, ist "lazy", was impliziert, dass das Objekt in Verbindung mit einem Zugriff geholt wird. "Agile" Kopien werden vorab konfiguriert, und die Einheit für eine aktive Replizierung ist eine gesamte Verteilungseinheit.
Für eine Installationskonfiguration soll eine Alloziierung von Masterdaten und Aktivkopien für einen erwünschten Prozessor getätigt werden. Dieses wird für jede Verteilungseinheit durchgeführt durch Feststellen, dass eine Sequenz von Master- oder aktiven Verteilungseinheiten einem Prozessor bzw. einem Prozessorpool zugeordnet werden soll, d. h. einem System von mehreren Prozessoren in einem verteilten Datenbanksystem. Dieses ist in einer Datei angegeben, die die Form aufweist, die in Fig. 8 gezeigt ist.
In Fig. 8 zeigt die erste Spalte Master- oder Aktiv-MDP an. Die zweite Spalte zeigt eine physikalische MDP-Sequenz an, wobei die zwei Unterspalten der zweiten Spalte eine Objektklasse und MDP-Nummer anzeigt. In z. B. der ersten Zeile ist 9914 eine Objektklassennummer, die die Objektklasse identifiziert, und 0 und 49 bezeichnen die Verteilungseinheitsnummer, d. h. es wird angezeigt, dass eine Frage besteht bezüglich 50 Verteilungseinheiten einer Objektklasse mit der Klassennummer 9914. Die letzte Spalte gibt den Prozessor an, in dem die Master- oder Aktiv- Verteilungseinheit in Frage zu installieren ist.
Weiterhin ist Information erforderlich über die Verteilungseinheitsverteilung für jede Objektklasse, als Eingabedaten für ein Lademodul, die in das System zu laden ist. Durch das Konzept Lademodul wird hier das gleiche bezweckt, wie in der oben erwähnten schwedischen Patentanmeldung. Die fragliche Verteilungseinheitsverteilung wird durch eine Datei bestimmt, die die Form hat, die in Fig. 9 gezeigt ist, wobei die Datei ihre Werte von Fig. 8 erhält.
In Fig. 9 zeigt die erste Spalte einen Klassennamen (objectType) an, und die zweite Spalte bezeichnet eine Objektklassennummer (dbClassld). Für die dritte Spalte tritt die Zahl von Verteilungseinheiten für die Objektklasse (logicalMDPhigh) auf, wobei die Numerierung der Verteilungseinheiten mit 0 beginnt. Beide Objektklassen sind hinsichtlich der Anzahl von Objekten, die erzeugt werden können, unbegrenzt, jedoch zeigt die Tabelle an, dass die Anzahl von Verteilungseinheiten, d. h. die Maximalanzahl von Prozessoren, auf die die Objekte verteilt werden können, 100 ist für Subscriber und 10 für Lic.
Fig. 8 und 9 umfassen Konfigurationsdaten mit Verteilungseinheitszuordnungsinformation für alle Objektklassen. Die Information soll in alle Prozessoren in lokale Datenbanken geladen werden. Insbesondere wird die Verteilungseinheitszuordnungsinformation durch die Datenbank zur Klasse Objekt geladen, durch eine Initiierungsfunktion in der Datenbank während der Bandladephase. Somit ist dies in der grundlegenden Funktionalität enthalten.
Fig. 10 soll veranschaulichen, wie dieses Laden physikalisch vorgeht. Der Einfachheit halber sind nur zwei der in Fig. 8 enthaltenen Prozessoren gezeigt, nämlich die Prozessoren 4 und 2, vgl. Zeilen 1 und 3 in Fig. 8.
Insbesondere wird gezeigt, wie Verteilungseinheiten 100 für die Objektklasse Subscriber in die Prozessoren #4 und #2 geladen werden, die in jeder Subdatenbank 102 bzw. 104 enthalten sind. In den Speicher des Prozessors #4 werden Masterverteilungseinheiten 106 innerhalb der Sequenz 0 → 49 geladen, wohingegen in den Speicher des Prozessors #2 aktive Verteilungseinheiten 105 mit der Sequenz 0 → 33 geladen werden.
Die oben definierte Objektklasse wird in eine Datenbank installiert durch
void Subscriber::install ("1111122")
Object instance, d. h. erzeugt durch
subx = Subscriber:: create ("1111122").
Die Objektinstanz, die somit zur Verteilungseinheit 22 gehört, wie es sich aus dem Obigen ergibt, wird in dem Speicher des Prozessors #4 gemäß der Verteilungseinheitszuordnung zu Prozessoren initiiert. Der Schlüssel wird in Übereinstimmung mit dem Obigen in eine Verteilungseinheitsnummer gemäß einem Algorithmus transformiert. Der Algorithmus ist eine Funktion, die den primären Schlüsseldatentyp als einen Eingangsparameter verwendet, und eine ganze Zahl zwischen 0 und logicalMDPhigh zurückgeliefert. Die Funktion sollte mögliche Schlüsselwerte gleichmäßig auf Verteilungseinheiten verteilen, die identifiziert wurden, es obliegt jedoch dem Objektklassendesigner, einen geeigneten Algorithmus auszuwählen, der das eigene Design berücksichtigt.
Das Objekt wird für ein Aktualisieren geöffnet durch
subx = Subscriber : openupdate("1111122")
Die Datenbank wird den verteilten Zugriff transparent für die Anwendung über Datenbankmanager handhaben, eine sogenannte versteckte Verteilung, wie es vorhergehend erwähnt wurde.
Die Suche nach einen Objekt in einem verteilten Datenbanksystem beginnt zuerst in dem lokalen Prozessor, um zu versuchen, das momentane Masterobjekt mittels der Tabellen 79 oder 80 in Fig. 7 zu finden, in Abhängigkeit davon, ob die Suche durchgeführt werden sollte mittels eines Schlüssels oder der lokalen Objektidentität.
Fig. 11 veranschaulicht detaillierter, wie auf ein Objekt mittels eines Schlüssels zugegriffen wird, falls das Objekt nicht lokal in dem gleichen Prozessor wie der zugreifende Prozess vorhanden ist. Insbesondere sucht der Prozess, mit 110 bezeichnet, der in einem anderen Prozessor ausgeführt wird, Pfeil 112, in einer lokalen Schlüsseltabelle 114, entsprechend der Schlüsseltabelle 79 in Fig. 7, in einer Subdatenbank 116 mit einem Prozessor 118. Der Datenbankmanager der Datenbank 116 ruft die Transformationsfunktion keyToMdp(key) durch die oben erwähnte DOA-Methode Subscriber::keyToMDP(key) auf, Pfeil 120, unter Verwendung des Schlüssels als Parameter, was eine logische MDP-Nummer ergibt. Daraufhin wird eine physikalische MDP- Nummer erzeugt, durch Kombinieren der Klassennummer der Instanz und der logischen MDP-No gemäß Fig. 12. Diese physikalische MDP-No bildet das erste Feld der globalen Objektidentität, vgl. Fig. 6c.
Daraufhin wird der Prozessor, zu dem die Verteilungseinheit gehört, in der Tabelle 82 nachgeschlagen, vgl. Fig. 7. Dann wird eine Nachricht zu dem Prozessor gesendet, wo das Objekt vorhanden ist, oder tatsächlich zu dem Port, der durch den Datenbankmanagerprozess in diesem Prozessor veröffentlicht wurde. Die Nachricht umfasst eine Objektklasse und einen primären Schlüssel, da die Verteilungseinheitsnummer nicht genug für eine eindeutige Identifizierung des Objekts ist. Es ergibt sich auch durch die Nachricht, was mit dem Objekt gemacht werden soll, um in der Lage zu sein, ein Lese- oder Schreibschutz zu setzen, falls erforderlich. In dem vorliegenden Fall wird ein Schreibschutz gesetzt.
Die Verteilungseinheitsidentität wird verwendet für ein Auffinden einer Netzwerkadresse mittels interner Datenbanktabellen, die auf alle Prozessoren in einem verteilten Datenbanksystem verteilt sind. Das Prinzip dieser Tabellen ist schematisch in Fig. 13 gezeigt, ohne mit der Realität in Übereinstimmung sein zu müssen. In einer tatsächlichen Realisierung sind die Tabellen komprimierter.
In Übereinstimmung mit Fig. 13 bestehen diese Tabellen in jedem Prozessor aus einer Suchtabelle 130, und einer zweiten Tabelle entsprechend der Tabelle 82 in Fig. 7. Die Suchtabelle 130 umfasst eine Zeile für jede Objektklasse, wo die Nummer der Objektklasse aufgeführt ist. Die Tabelle 82 umfasst eine Zeile für jede Verteilungseinheit, die installiert ist, wobei sich die Zeile über drei Spalten erstreckt. Jede Zeile zeigt in der ersten Spalte eine Objektklassennummer an, in der zweiten Spalte eine Verteilungseinheitsnummer, und in der dritten Spalte einen Portnamen zu einem Objekt. Insbesondere ergibt es sich aus der zweiten Tabelle, dass für die Objektklassennummer myClass id 102 Verteilungseinheiten vorhanden sind, mit zuordneter Identifikation des Portnamens zu einem Objekt.
Mit Wissen über die Klassennummer des gesuchten Objektes startet der Verteilungsmanager in dem eigenen Prozessor (Pfeil 132) eine Suche in der Tabelle 130, bis die fagliche Objektklassennummer myClass id gefunden wurde, nach einem Suchprozess, angezeigt durch Pfeile 134. Dieses führt seinerseits, gemäß einem Pointer 136, zu dem Satz von Objektklassennummern MyClass id in der Tabelle 82, wobei angenommen wird, dass eine Suche, angezeigt durch einen Pfeil 138, zu der Verteilungseinheit Nr. 100 führt. In Übereinstimmung mit dem Pfeil 140 ergibt dies zuletzt eine Adressierung des momentanen Prozessors, in dem das gesuchte Objekt vorhanden ist.
In Fig. 14 und 16 ist detaillierter eine transparente Verteilung der kurz mit Bezug auf Fig. 7, 11 und 13 beschriebenen Art detaillierter veranschaulicht.
Die Situation in Fig. 14 beginnt mit der Annahme, dass der Verteilungsmanager in dem Prozessor, von dem die Verteilung begannen hat, einen Suchprozess entweder einer Art, die eine globale Objektidentität verwendet, oder einer Art, die einen Schlüssel verwendet durchgeführt hat, und welches oben mit Bezug auf Fig. 13 beschrieben wurde, wobei dies mit MDP100 + myKey bei Pfeil 142 bezeichnet ist.
In dem Prozessor, mit 150 bezeichnet, wird ein Schnittstellenagent 152 durch den Verteilungsmanager erzeugt, bezeichnet 154 in der Datenbank 156, einschließlich des Prozessors 150. Die Nachricht wird in ein Exportformat gepackt, das dann, Pfeil 158, zu dem anderen Prozessor gesendet wird, bezeichnet 160, welcher in einer entsprechenden Subdatenbank 162 ein gesuchtes Masterobjekt enthält. Wenn eine Nachricht an der Datenbank 162 ankommt, wird sie durch einen Schnittstellenagenten 168 empfangen, erzeugt durch seinen Verteilungsmanager 166. Wenn der Kommunikationsprozess aktiviert wurde, der die verteilte Kommunikation zwischen den Prozessoren handhaben soll, wird die Nachricht ausgepackt und eine lokale Suche nach dem Objekt wird durchgeführt.
Falls die Nachricht die globale Objektidentität enthält, wird die Suche in Übereinstimmung mit Pfeilen 170 und 172 über die Tabelle 174 der Datenbank 162 durchgeführt. Die Tabelle 174 entspricht der Tabelle 84 in Fig. 7, die Pfeile 170, 172 zeigen den gleichen Prozess an wie Pfeil 90 in Fig. 7. Das gefundene Objekt ist bei 175 gezeigt.
Der alternative Suchprozess in dem Prozessor 160 mit einer Objektklassennummer und einem primären Schlüssel, in dem Fall, dass die globale Objektidentität des gesuchten Objektes nicht bekannt sein sollte, ist durch die Tabellen in Fig. 15 veranschaulicht. Wie im Falle bei Fig. 13, ist nur das Prinzip schematisch in Fig. 15 für eine Verwendung dieser Tabellen gezeigt, ohne eine Übereinstimmung mit der Realität zu beanspruchen. In einer realen Implementierung sind diese Tabellen hier auch stärker komprimiert.
Tabellen gemäß Fig. 15 sind in jedem Prozessor enthalten und bestehen in Übereinstimmung mit der Figur aus einer Suchtabelle 180 und einer zweiten Tabelle entsprechend der Tabelle 79 in Fig. 7. Die Tabelle 180 enthält eine Zeile für jede Objektklasse, wobei die Nummer der Objektklasse in dieser Zeile angezeigt ist. Die Tabelle 79 enthält eine Zeile für jeden Schlüssel, der installiert ist, wobei die Zeilen sich über drei Spalten erstrecken. Jede Zeile bezeichnet in der ersten Spalte eine Objektklassennummer, in der zweiten Spalte einen Schlüssel, und die dritte Spalte enthält einen Pointer auf ein Datenbankobjekt.
Wie in Fig. 15 veranschaulicht ist, führt der Datenbankmanager in dem Prozessor #4 einen Suchprozess durch, mittels der Objektklassennummer my Class Id des gesuchten Objekts, die gemäß einem Pfeil 182 in der Tabelle 180 beginnt, über Pfeile 184 zu der Objektklassennummer my Class Id in Frage führt, und über einen Pfeil 186 zu dem Satz von Objekten und der Klassennummer my Class Id führt. Zuletzt wird durch ein Suchen gemäß der Pfeile 188 ein Schlüssel Primary Key mit einem zugeordneten Pointer 190 zu dem gesuchten Objekt gefunden.
Die Tabellen in Übereinstimmung mit Fig. 15 sind weiter in Fig. 14 schematisch als ein Block 79 gezeigt.
Die Situation in Fig. 14 beginnt mit der Annahme, dass der Verteilungsmanager in der Subdatenbank 156, wovon die Verteilung begonnen wird, mittels der Tabellen 130, 82 einen Suchprozess durchgeführt hat, einer Art, die ähnlich dem ist, die oben mit Bezug auf Fig. 13 beschrieben wurde. Wie zuvor, wird in dem eigenen Prozessor 150 ein Schnittstellenagent 152 durch den Verteilungsmanager 154 in der Subdatenbank 156 des Prozessors 150 erzeugt. Die Nachricht wird in ein Exportformat gepackt, was dann zu dem anderen Prozessor 160 in Übereinstimmung mit dem Pfeil 158 gesendet wird, dessen Datenbank 162 das gesuchte Masterobjekt, mit 192 bezeichnet, enthält.
Wenn die Nachricht an der Subdatenbank 162 ankommt, wird sie durch den Schnittstellenagenten 168 empfangen. Wenn der Kommunikationsprozess aktiviert wurde, der die verteilte Kommunikation zwischen den Prozessoren handhaben soll, wird die Nachricht entpackt, und eine lokale Suche nach dem Objekt, in Übereinstimmung mit dem Suchprozess, der oben mit Bezug auf Fig. 15 beschrieben wurde, wird mittels der Tabellen 182 und 79 der Datenbank 162 durchgeführt.
Wenn das Masterobjekt 175 bzw. 192 gefunden wurde, wird ein Schreibschutz daran angebracht. Der Schreibschutz muss von dem Datenbankmanager am Prozessor 160 erhalten werden, der das Masterobjekt enthält, da eine Zuweisung eines Schutzes für einen anderen Prozessor automatisch durch den Datenbankmanager in der Datenbank durchgeführt wird. Simultan, mit Bezug auf Fig. 16, wird ein Ruhekopierobjekt 200 zurückgeliefert, Pfeil 202, zur Datenbank 156, die den Prozessor 150 enthält, wo die Suchtransaktion initiiert wurde, vgl. auch 66" in Fig. 5. Bei 204 ist der Prozessor 150 des Prozesses gezeigt, der den Zugriff gestartet hat.
Der oben mit Bezug auf Fig. 11 bis 16 für eine transparente Verteilung beschriebene Prozess wird nun der Einfachheit halber mittels der Flussdiagramme aus Fig. 17 und 18 zusammengefasst.
In Fig. 17 wird eine Suche nach dem Objekt mittels einer Klassennummer plus Schlüssel, Schritt 250, gestartet.
Die Suche wird zuerst in dem lokalen Prozessor durchgeführt, um zu versuchen, dort das momentane Masterobjekt zu finden. Dieses wird in der lokalen Schlüsseltabelle 79, vgl. Fig. 7, durchgeführt, mittels des Schlüssels. Falls in Schritt 25 festgestellt wird, dass das Objekt in dem gleichen Prozessor angeordnet ist, fährt der Prozess in Übereinstimmung mit Pfeil 253 zum Endschritt in Fig. 17 fort, unterhalb genauer beschrieben.
Falls im Schritt 252 festgestellt wird, dass das Objekt nicht in dem gleichen Prozessor gefunden werden kann, wird in Übereinstimmung mit dem, was auf Fig. 11 beschrieben wurde, in Schritt 254 eine lokale Verteilungseinheit mittels der Transformationsfunktion keyToMDP(Schlüssel) erzeugt, und in Schritt 256 eine physikalische Verteilungseinheit durch die Kombination einer Objektklassennummer und logischen Verteilungseinheit gemäß Fig. 12.
Danach wird in Schritt 258 eine Suche nach der Portidentität zu dem Datenbankprozess in dem Prozessor gesucht, in der Subdatenbank, wo das gesuchte Objekt lokalisiert ist. Insbesondere wird diese Suche durchgeführt mit einem Suchen mittels Tabellen gemäß Fig. 13.
In Schritt 260 wird eine Nachricht zu dem fraglichen Port gesendet. In der Nachricht sind Objektklassennummer und Schlüssel enthalten, da die Verteilungseinheitsnummer nicht genug ist, um das Objekt eindeutig zu identifizieren. Es ergibt sich weiter aus der Nachricht, was mit dem Objekt zu tun ist, um in der Lage zu sein, einen Lese- oder Schreibschutz bei Bedarf anzufügen.
Nachdem das gesuchte Objekt durch ein lokales Suchen in der Tabelle 79 in Fig. 14 des gefundenen Prozessors durchgeführt wurde, wird ein Kopieobjekt in Schritt 262 zu dem Prozessor zurückgeliefert, der den Zugriff gestartet hat, vgl. das, was mit Bezug auf Fig. 16 beschrieben wurde, und wird dort installiert.
In Schritt 264 wird zuletzt der Datenbankagent DOA in Übereinstimmung mit dem erzeugt, was in der US- Patentanmeldung 08/264059 beschrieben wurde, und wird zu dem Anwendungsprozess zurückgeliefert.
In Fig. 18 wird eine Suche nach dem Objekt mittels der Objektidentität gestartet, Schritt 266.
Die Suche wird zuerst in dem lokalen Prozessor durchgeführt, um zu versuchen, dort das momentane Masterobjekt zu finden, mittels der lokalen Objektidentität und der lokalen Tabelle 80, vgl. Fig. 7. Falls in Schritt 268 herausgefunden wird, dass das Objekt lokal vorhanden ist, schreitet der Prozess direkt zum letzten Schritt in Fig. 18 voran, gemäß Pfeil 269.
Falls in Schritt 168 herausgefunden wird, dass das Objekt nicht in dem gleichen Prozessor angeordnet ist, wird die lokale Objektidentität durch die Anwendung in eine globale Objektidentität umgewandelt, in Schritt 270, in Übereinstimmung mit dem, was in Verbindung mit Fig. 5 beschrieben wurde.
Danach wird eine Portidentität in Schritt 272 zu dem Datenbankprozess in dem Prozessor gesucht, in der Subdatenbank, wo das gesuchte Objekt lokalisiert ist. Insbesondere wird diese Suche durchgeführt durch ein Suchen mittels der Verteilungseinheitsnummer, in Tabelle 82 in Fig. 7, enthalten in der globalen Objektidentität.
In Schritt 274 wird eine Nachricht zu dem fraglichen Port gesendet. In der Nachricht ist die globale Objektidentität enthalten. Es ergibt sich auch aus der Nachricht, was mit dem Objekt zu tun ist, um es zu ermöglichen, einen Lese- oder Schreibschutz bei Bedarf anzubringen.
Nachdem das gesuchte Objekt durch eine lokale Suche in der Tabelle 174 in Fig. 14 des gefundenen Prozessors gefunden wurde, wird ein Kopieobjekt in Schritt 276 zum Prozessor zurückgeliefert, der den Zugriff gestartet hat, vgl. das, was mit Bezug auf Fig. 16 beschrieben wurde, und wird dort installiert.
In Schritt 278 wird zuletzt ein Datenbankagent DOA erzeugt und zu dem Anwendungsprozess zurückgeliefert.

Claims

1. Ein verteiltes objektorientiertes Datenbanksystem, einschließlich einer Datenbank und einer Anzahl von miteinander verbundenen Prozessoren (4, 6, 8; 54, 74) zum Handhaben unterschiedlicher Teile der Datenbank, wobei die Datenbankteile eine Anzahl von Objekten enthalten, wobei mit jedem solchen Objekt globale Information darüber in Zusammenhang steht, in welchem Prozessor das Objekt angeordnet ist, und lokale Information darüber, wo das Objekt in dem eigenen Prozessor angeordnet ist,

dadurch gekennzeichnet, dass

die globale Information identisch für und angeordnet in jedem Prozessor in dem System ist, und Information umfasst bezüglich der Anzahl von Verteilungseinheiten, von denen jede Information bezüglich einer Anzahl von Instanzen einer bestimmten Objektklasse enthält, angeordnet in einem bestimmten Prozessor, und Information, mittels derer die Adresse dieses Prozessors gefunden werden kann,

wobei die Objekte adressierbar sind, entweder mittels Schlüsselwerten, falls ein Objekt, auf das zuzugreifen ist, nicht in dem gleichen Prozessor vorliegt wie ein zugreifendes Objekt, oder mittels Objektidentitäten einschließlich lokaler und globaler Objektidentitäten, wobei jede lokale Objektidentität (Fig. 6b) ein erstes Kommunikationsfeld enthält, das den eigenen Prozessor identifiziert, und ein zweites Informationsfeld, das das Objekt identifiziert, und wobei jede globale Objektidentität (Fig. 6a) ein erstes Informationsfeld enthält, das eine Verteilungseinheit identifiziert, und ein zweites Informationsfeld, das das Objekt identifiziert,

wobei jeder Prozessor eine erste Tabelle (80) umfasst, die lokale Objektidentitäten enthält, die auf Objekte in dem gleichen Prozessor zeigen, eine zweite Tabelle (82), die eine erste Spalte (86) enthält für Verteilungseinheitsnummern, und eine zweite Spalte (88), die allgemein auf Prozessoren zeigt, eine dritte Tabelle (79), die einem jeden Prozessor zugeordnete objektidentifizierende Schlüsselwerte enthält, und einer vierten Tabelle (84) mit einer ersten Spalte (84') für eine globale Objektidentität und einer zweiten Spalte für Zeiger auf ein entsprechendes Objekt in dem Speicher des Prozessors.

2. In einem verteilten objektorientierten Datenbanksystem, einschließlich einer Datenbank, und einer Anzahl von miteinander verbundenen Prozessoren zum Handhaben unterschiedlicher Teile der Datenbank, wobei die Datenbank Teile einer Anzahl von Objekten enthält, wobei jedem Objekt globale Information darüber zugeordnet ist, in welchem Prozessor das Objekt angeordnet ist, und lokale Information darüber, wo das Objekt in dem eigenen Prozessor angeordnet ist,

ein Verfahren zum Zugreifen auf ein Objekt, das zu einer bestimmten Klasse gehört, umfassend:

Bereitstellen der globalen Information, identisch für und angeordnet in jedem Prozessor in dem System, und Einschließen von Information bezüglich einer Anzahl von Verteilungseinheiten, von denen jede Information bezüglich einer Anzahl von Instanzen einer bestimmten Objektklasse enthält, und Information, mittels der die Adresse dieses Prozessors gefunden werden kann,

Bereitstellen der Objekte, adressierbar entweder mittels derer Schlüsselwerte, falls ein Objekt, auf das zuzugreifen ist, nicht in dem gleichen Prozessor vorhanden ist wie ein zugreifender Prozess, oder mittels Objektidentitäten, einschließlich globaler und lokaler Objektidentitäten, wobei jede lokale Objektidentität ein erstes Informationsfeld enthält, das den eigenen Prozessor identifiziert, und ein zweites Informationsfeld, das das Objekt identifiziert, und wobei jede globale Objektidentität ein erstes Informationsfeld enthält, das eine Verteilungseinheit identifiziert, und ein zweites Informationsfeld, das das Objekt identifiziert,

Bereitstellen jedes Prozessors, um eine erste Tabelle (80) zu umfassen, enthaltend lokale Objektidentitäten, die auf Objekte in dem gleichen Prozessor zeigen, eine zweite Tabelle (82) enthaltend eine erste Spalte (86) für Verteilungseinheitsnummern, und eine zweite Spalte (88), die allgemein auf Prozessoren zeigt, eine dritte Tabelle (79), die objektidentifizierende Schlüsselwerte enthält, einem jeden Prozessor zugeordnet, und entsprechende Objektklassennummern, und eine vierte Tabelle (84), die eine erste Spalte (84') für eine globale Objektidentität enthält, und eine zweite Spalte für Zeiger auf ein entsprechendes Objekt in dem Speicher des Prozessors,

Beginnen eines Suchens (250) für das Objekt zuerst in dem eigenen Prozessor mittels eines Schlüsselwertes und einer Objektklassennummer in der dritten Tabelle (79), und

falls diese Suche ergibt, dass das Objekt nicht in dem gleichen Prozessor (252) vorliegt,

Erzeugen (254), mittels einer Transformationsfunktion, eine logische Verteilungseinheitsnummer, die Information bezüglich einer Anzahl von Instanzen der Klasse des Objekts identifiziert, die in einem bestimmten Prozessor angeordnet sind, und einer Adressinformation bezüglich dieses Prozessors,

Erzeugen (256 einer entsprechenden physikalischen Verteilungseinheitsnummer durch Kombinieren von Informationen bezüglich der Klasse von dem Objekt und der logischen Verteilungseinheitsnummer,

Identifizieren (258) des Prozessors, in dessen Datenbank das gesuchte Objekt angeordnet ist, durch Suchen mittels der physikalischen Verteilungseinheitsnummer in der zweiten Tabelle (82),

Senden (26) einer Nachricht, die eine Objektklassennummer- und Schlüssel- und Betriebsinformation enthält, an den fraglichen Prozessor,

lokales Suchen einer dritten Tabelle (79) des gefundenen Prozessors nach dem Objekt, auf das mittels des Schlüsselwertes zuzugreifen ist,

Rückliefern (262) einer Kopie des gefundenen Objekts an den Prozessor, der den Zugriff angefordert hat.

3. In einem verteilten objektorientierten Datenbanksystem einschließlich einer Datenbank, und einer Anzahl von miteinander verbundenen Prozessoren zum Handhaben unterschiedlicher Teile der Datenbank, wobei die Datenbank Teile einer Anzahl von Objekten enthält, wobei einem jeden globale Information darüber zugeordnet ist, in welchem Prozessor das Objekt angeordnet ist, und lokale Information darüber, wo das Objekt in dem eigenen Prozessor angeordnet ist,

ein Verfahren zum Zugreifen auf ein Objekt, das zu einer bestimmten Klasse von Objekten gehört, umfassend:

Bereitstellen der globalen Information, identisch für und angeordnet in jedem Prozessor in dem System, und Information enthaltend bezüglich einer Anzahl von Verteilungseinheiten, von denen eine jede Information bezüglich einer Anzahl von Instanzen einer bestimmten Objektklasse enthält, und Information, mittels der die Adresse dieses Prozessors gefunden werden kann,

Bereitstellen des Objekts, das entweder mittels Schlüsselwerten adressierbar ist, falls ein Objekt, auf das zuzugreifen ist, nicht in dem gleichen Prozessor vorhanden ist, wie ein zugreifender Prozess, oder mittels der Objektidentitäten, einschließlich lokaler und globaler Objektidentitäten, wobei jede lokale Objektidentität ein erstes Informationsfeld enthält, das den eigenen Prozessor identifiziert, und ein zweites Informationsfeld, das das Objekt identifiziert, und wobei jede globale Objektidentität ein erstes Informationsfeld enthält, das eine Verteilungseinheit identifiziert, und ein zweites Informationsfeld, das das Objekt identifiziert,

Bereitstellen jedes Prozessors, so dass er eine erste Tabelle (80) umfasst, enthaltend lokale Objektidentitäten, die auf Objekte in dem gleichen Prozessor zeigen, eine zweite Tabelle (82), die eine erste Spalte (86) für Verteilungseinheitsnummern enthält, und eine zweite Spalte (88), die allgemein auf Prozessoren zeigt, eine dritte Tabelle (79), die objektidentifizierende Schlüsselwerte enthält, die einem jeden Prozessor zugeordnet sind, und entsprechende Objektklassennummern, und eine vierte Tabelle (84), die eine erste Spalte (84') für eine globale Objektidentität enthält, und eine zweite Spalte für Zeiger auf ein entsprechendes Objekt in dem Speicher des Prozessors,

Starten eines Suchens (268) in der ersten Tabelle (80) des lokalen Prozessors, um zu versuchen, dort das Objekt zu finden, mittels der lokalen Objektidentität, und,

falls diese Suche ergibt, dass das Objekt nicht in dem eignen Prozessor angeordnet ist,

Umwandeln (270) der lokalen Objektidentität in eine globale Objektidentität,

Durchsuchen der zweiten Tabelle (82) des Prozessors, in dem das Objekt, auf das zuzugreifen ist, angeordnet ist, mittels der Verteilungseinheit, die in der globalen Objektidentität enthalten ist,

Senden (274) einer Nachricht an den fraglichen Prozessor, in der die globale Objektidentität enthalten ist,

Durchsuchen der vierten Tabelle (174, 84) nach der Objektidentität in dem Prozessor, gefunden mittels der globalen Objektidentität,

Zurückliefern (276) einer Kopie der Objektidentität an den Prozessor, der den Zugriff gestartet hat.