Verteilte Datenbanken bei INGRES
Verteilte Datenbanken bei INGRES
21 Verteilte Datenbanken bei INGRES
21.2.2 Zugriff
auf eine ferne INGRES-Datenbank mit INGRES/NET
21Verteilte Datenbanken bei INGRES
Zur INGRES-Produktpalette
gehören drei Produkte,
die verteilte
Datenbanken unterstützen: INGRES/NET,
INGRES/STAR und
INGRES Gateways. Zuerst
werden wir
INGRES/NET beschreiben, das einen
verteilten Zugriff auf
Datenbanken ermöglicht. Danach wird
INGRES/STAR erörtert,
das tatsächlich
verteilte Datenbanken unterstützt.
Im
Zusammenhang mit INGRES/STAR wird gezeigt, wie
Datenbankobjekte (Tabellen und
Views) Teile eines vernetzten
Systems werden können. Außerdem wird das Zwei-Phasen-Commit
beschrieben. Am Ende des
Kapitels werden Eigenschaften von
Gateways erörtert, die die
Verbindung zwischen heterogenen
Datenbanken ermöglichen.
21.1 Einleitung
Der Begriff der verteilten Datenbanken ist ein allgemeiner
Begriff, dessen genaue
Bedeutung erst durch zusätzliche
Erklärungen eingeordnet werden kann. Dieser Begriff wird
für drei voneinander unterschiedliche Typen von Datenbanken
benutzt.
Der erste Typ stellt
den sogenannten verteilten
Zugriff dar. Bei dem
verteilten Zugriff befindet
sich der
Datenbank-Server auf einem
Rechner, während
INGRES-DB-Anwendungen (RBF, QBF usw.)
auf anderen Rechnern
im Netz liegen. Der
verteilte Zugriff bei INGRES wird durch
das Produkt INGRES/NET unterstützt.
Die
tatsächlich verteilten Datenbanken, die bei INGRES
mit
dem Produkt INGRES/STAR realisiert
sind, haben die
Eigenschaft, dem Anwender den Eindruck zu
vermitteln, mit
einer einzigen Datenbank
an einem Rechner
zu arbeiten,
obwohl die Daten durchaus auf
verschiedene Rechner im Netz
verteilt werden können.
Den dritten Typ
stellen die sogenannten heterogenen
Datenbanken dar.
Diesen Typ kennzeichnet eine andere
Verteilungsart von
Datenbanken. Das heterogene
System
beinhaltet die Datenbanken, die sich auf unterschiedlichen
Rechnern befinden und mit
DB-Produkten verschiedener
Hersteller erzeugt wurden. INGRES Gateways unterstützen die
Verbindung zwischen den INGRES-Datenbanken einerseits
und
relationalen bzw. nicht
relationalen Datenbanken anderer
Hersteller andererseits.
Im Vergleich mit anderen relationalen Datenbanksystemen
hat
INGRES einen technologischen
Vorsprung besonders bei den
verteilten Datenbanken. Sowohl mit
INGRES/NET (1983) als
auch mit INGRES/STAR (1986)
war INGRES die erste Firma
überhaupt, die diese
beiden Technologien entwickelt
und
freigegeben hat. Dasselbe gilt für die
Unterstützung der
heterogenen Datenbanken mit Hilfe von Gateways.
In den bisherigen Kapiteln des
Buches haben wir
immer
angenommen, daß die
verwendete Datenbank lokal
ist, d.h.
Datenbank-Anwendungen,
Datenbank-Server und Datenbank selbst
befinden sich auf einem
Rechner. In den
nachfolgenden
Abschnitten wird das nicht mehr der
Fall sein.
21.2 INGRES/NET
INGRES/NET ermöglicht
den Anwendern, von einem Rechner auf
eine Datenbank, die auf einem anderen, im Netz befindlichen
Rechner gespeichert ist, zuzugreifen. Dieser Zugriff
verläuft transparent, d.h. der
Anwender hat den Eindruck,
mit einer lokalen Datenbank zu
arbeiten.
Abbildung 21-1 zeigt die
INGRES/NET-Architektur.
Abb. 21-1
INGRES/NET-Architektur
21.2.1 GCA
GCA ("GCF Application Interface") ist eine
Schnittstelle,
die
auf GCF ("General Communication Facility") basiert und
den
INGRES-DB-Anwendungen einerseits
und INGRES-DB-Servern
andererseits die Kommunikation
miteinander ermöglicht. Dabei
können Datenbank-Server und
Datenbank-Anwendung sich auf
einem oder auf unterschiedlichen
Rechnern im Netz befinden.
Die
Kommunikation zwischen
einer Datenbank-Anwendung und
einem Datenbank-Server besteht
aus zwei Schritten: Zuerst
muß die Datenbank-Anwendung den
Datenbank-Server ausfindig
machen, und erst dann
findet die Kommunikation zwischen
den beiden statt. Für jeder den oben
genannten Schritte
existiert ein
Server: Der Namens-Server für das Auffinden
von
Datenbank-Servern und der Kommunikations-Server für die
Herstellung der Kommunikation.
Wenn eine
Datenbank-Anwendung auf eine
Datenbank
zugreift, muß zuerst
mit Hilfe des Namens-Servers, der
Datenbank-Server, der diese
Datenbank verwaltet, gefunden
werden. Dieses Verfahren gilt
auch für den Fall, daß sich
der
Datenbank-Server und die
Datenbank-Anwendung auf einem
Rechner befinden. Im
Unterschied zum Namens-Server wird
der
Kommunikations-Server nur dann
aktiv, falls sich die
DB-Anwendung und der
DB-Server nicht auf
einem Rechner
befinden.
Der
Kommunikations-Server ist die
wichtigste Komponente
von INGRES/NET. Er ermöglicht den Zugriff auf
Standard-Protokolle für Rechnernetze. Die Implementierung
des
Kommunikations-Servers enthält die
obersten vier
Schichten des ISO-Standard
Protokolls für Rechnernetze:
- die
Applikations-Schicht,
- die
Präsentations-Schicht,
- die
Sitzungs-Schicht und
- die
Transport-Schicht.
Die
Transport-Schicht des Kommunikations-Servers enthält
GCF-Funktionen, die abhängig vom Netztyp (TCP/IP, DECnet
usw.) sind. Die Sitzungs-Schicht
verwaltet die Eigenschaften
der einzelnen Sitzungen, während die Präsentations-Schicht
die
Datenumwandlung durchführt, falls
sich Daten nicht
in
demselben Format wie Daten des
gegewärtigen Rechners
befinden. Die oberste Schicht des
Kommunikations-Servers -
die Applikations-Schicht - ist die
GCA.
21.2.2 Zugriff auf eine ferne INGRES-Datenbank mit INGRES/NET
Um
auf eine INGRES-Datenbank,
die sich auf einem anderen
Rechner im Netz befindet, zuzugreifen, müssen
folgende
allgemeine Voraussetzungen erfüllt
werden:
- INGRES/NET muß sowohl auf
dem lokalen als auch auf dem
fernen Rechner installiert werden;
- mit Hilfe des Dienstprogramms netu muß der
INGRES-Systemadministrator
den fernen Rechner, wo
sich
die Datenbank befindet,
definieren.
Der Zugriff auf eine
ferne Datenbank setzt einige
weitere
Bedingungen voraus:
- der Benutzer muß eine
Kennung auf dem fernen
Rechner
haben bzw. die öffentliche Kennung des fernen
Rechners
benutzen können;
- mit Hilfe des Dienstprogramms netu muß die Autorisierung
für die existierende bzw.
öffentliche Kennung definiert
werden.
Die Syntax eines Kommandos für
den Zugriff auf eine ferne
Datenbank ist
kommando [schalter_liste] knoten::db_name
kommando ist ein
Betriebssystemkommando für den Aufruf eines
INGRES-Dienstprogramms (qbf, rbf usw.). schalter_liste ist
eine Liste von Schaltern, die für das angegebene Kommando
erlaubt sind. knoten
kennzeichnet den Namen
des fernen
Rechners, auf dem sich die Datenbank
db_name befindet.
Beispiel 21.1
ingmenu ararat::beispiel
In Beispiel 21.1 wird mit dem
Dienstprogramm ingmenu auf die
Datenbank beispiel, die sich
auf dem fernen Rechner ararat
befindet zugegriffen.
Die
Verwendung von INGRES/NET bringt einige Einschränkungen
bezüglich der INGRES-Dienstprogramme mit
sich. Folgende
Dienstprogramme dürfen u.a. für die
fernen Datenbanken nicht
benutzt werden:
- accessdb,
- createdb,
- destroydb und
- rollforwarddb.
21.3 INGRES/STAR
Eine generelle Eigenschaft von
INGRES ist, daß immer eine
Sammlung von Tabellen als eine Datenbank betrachtet
wird.
Dem Benutzer ist es
erlaubt nur Objekte
einer einzigen
Datenbank zu einem Zeitpunkt
bearbeiten zu können.
INGRES/STAR hebt diese
Einschränkung auf; der Benutzer hat
mit
Hilfe von INGRES/STAR die
Möglichkeit, gleichzeitig
auf mehrere Datenbanken zuzugreifen. Damit erscheinen alle
Datenbanken, die sich
im Netz befinden als eine
einzige
Datenbank.
Die
Funktionalität von INGRES/STAR ermöglicht
damit den
gleichzeitigen Zugriff auf
mehrere Datenbanken. Um
aber
auf
andere Datenbanken im Netz zugreifen zu können, muß
INGRES/NET verwendet werden. Damit
braucht man sowohl
INGRES/NET als auch INGRES/STAR
für den gleichzeitigen
Zugriff auf mehrere Datenbanken im
Netz (Abb. 21-2).
Abb. 21-2
INGRES/STAR-Architektur
In
einer INGRES/STAR-Umgebung existieren
insgesamt drei
Arten von Datenbanken:
- lokale Datenbanken,
- die verteilte Datenbank und
- die
Koordinations-Datenbank.
Lokale Datenbanken
sind alle herkömmlichen
INGRES-Datenbanken. Die verteilte Datenbank ist die Menge
aller Datenbanken,
die dem Benutzer
als eine Datenbank
erscheint. Jede verteilte Datenbank enthält mehrere lokale
Datenbanken, die jede für sich auch
Teil mehrerer verteilten
Datenbanken sein können.
Die Koordinations-Datenbank ist
eine spezifische Datenbank
der INGRES/STAR-Umgebung, die
INGRES/STAR-Kataloge enthält.
INGRES/STAR hat
weder den direkten
Zugriff auf lokale
Datenbanken noch verwaltet sie sie direkt. Alle Zugriffe
werden über den lokalen DB-Server
durchgeführt, der auch für
die Verwaltung der Datenbank(en)
zuständig ist.
Mit
dem INGRES-Dienstprogramm createdb ist es möglich,
eine verteilte Datenbank zu erzeugen. Dieses Dienstprogramm
erstellt eine leere verteilte Datenbank, der dann
Objekte
(Tabellen, Views) folgendermaßen
zugewiesen werden können:
- durch die Eintragung von Objekten, die in einer lokalen
Datenbank schon existieren;
- durch die Erstellung neuer Objekte auf der
INGRES/STAR-Ebene,
die dann automatisch in
der verteilten Datenbank
eingetragen werden;
- durch die Erstellung neuer Objekte in einer
lokalen
Umgebung, die anschließend in der verteilten Datenbank
eingetragen werden (können aber
nicht müssen).
Aus der obigen Diskussion folgt,
daß nicht jedes Objekt
einer lokalen Datenbank Teil einer verteilten Datenbank sein
muß. Dies ist vorteilhaft, weil damit Objekte einer lokalen
Datenbank privat gehalten werden
können.
Die Eintragung eines existierenden Objektes einer lokalen
Datenbank in der verteilten
Datenbank wird mit der Anweisung
REGISTER AS LINK durchgeführt. Diese Anweisung hat
folgende
Syntax:
REGISTER objekt_typ objekt_name [(sp_1
[,sp_2,...])]
AS LINK [FROM
[ben_name.]lokal_objname]
[WITH [NODE=knoten_name, DATABASE=db_name]
[,DBMS=server_name]];
objekt_typ kann entweder das Schlüsselwort TABLE (für eine
Tabelle) oder VIEW (für ein View) sein, während objekt_name
der
Aliasname des Objektes
in der INGRES/STAR-Umgebung
ist. ben_name ist der
Name des Eigentümers des Objektes
lokal_objname. knoten_name kennzeichnet den Namen des
Rechners, auf dem sich die
Datenbank db_name befindet,
während server_name
entweder die Zeichenkette "INGRES
Gateways" (für nicht INGRES-Datenbanken) oder "INGRES"
sein
kann.
Beispiel 21.2
REGISTER TABLE arb
AS LINK FROM peter.arbeiten
WITH
NODE=montblanc, DATABASE=beispiel;
In Beispiel 21.2 wird
die Tabelle arbeiten,
die sich in
der lokalen Datenbank beispiel und auf
dem fernen Rechner
montblanc befindet, in der verteilten Datenbank
unter dem
Namen arb aufgenommen.
21.3.1 Zwei-Phasen-Commit
Zwei-Phasen-Commit ist
ein Mechanismus, der
seit der
Version 6.3 von INGRES unterstützt wird. Dieser Mechanismus
gewährleistet, daß
Datenbanken in einer
verteilten
Umgebung nach einer Transaktion
konsistent bleiben.
Zwei-Phasen-Commit wird
verwendet, wenn innerhalb
einer
Transaktion Änderungen
an zwei oder
mehreren im Netz
befindlichen Datenbanken
durchgeführt werden.
Zwei-Phasen-Commit arbeitet in vier
Schritten, die in zwei
Gruppen (Phasen) unterteilt sind. Der erste Schritt wird
vom
koordinierenden Programm veranlaßt,
indem überprüft
wird, ob jede lokale Datenbank
ihr zugehörige Anweisungen
ausführen kann. Im
zweiten Schritt sichert
jede lokale
Datenbank die für die
Anweisung notwendigen Ressourcen und
schickt anschließend die Bestätigung an das koordinierende
Programm zurück. Die erste
Phase wird abgeschlossen, wenn
alle betreffenden
lokalen Datenbanken die
Bestätigung
zurückgeschickt haben.
Im dritten Schritt veranlaßt das
koordinierende Programm die
Durchführung jeder Anweisung in den entsprechenden lokalen
Datenbanken. Im vierten
Schritt wird die Ausführung
der
Anweisungen von jeder lokalen Datenbank bestätigt. Nur
wenn
alle lokalen Datenbanken
die Ausführung der
Anweisungen
bestätigt haben, wird die zweite
Phase als erfolgreich
abgeschlossen betrachtet.
In
der zweiten Phase kann es vorkommen, daß die Anweisung
für
eine lokale Datenbank nicht ausgeführt
werden kann.
In diesem Fall wird
eine entsprechende Meldung
an das
koordinierende Programm
geschickt, das anschließend das
Zurücksetzen aller übrigen Anweisungen der zu bearbeitenden
Transaktion veranlaßt.
Damit sorgt das koordinierende
Programm dafür, daß entweder
alle Anweisungen einer
Transaktion ausgeführt oder
zurückgesetzt werden.
INGRES bietet zwei Anweisungen
- PREPARE TO COMMIT und
- CONNECT,
die
der eingebetteten SQL-Sprache angehören und das
Zwei-Phasen-Commit unterstützen. Diese beiden
Anweisungen
entsprechen jeweils
der beiden Phasen
des Zwei-
Phasen-Commit: Die Anweisung PREPARE TO COMMIT
realisiert
die erste und die Anweisung CONNECT
die zweite Phase.
Das
koordinierende Programm muß
vom Benutzer selbst
geschrieben werden. Alle Einzelheiten, die das Schreiben
eines spezifischen Koordinationsprogramms betreffen, finden
Sie in den entsprechenden
INGRES-Manualen.
21.4 Gateways
INGRES Gateways sind Schnittstellen zwischen
INGRES-Anwendungen einerseits und nicht
INGRES-Datenbanken
andererseits. Mit INGRES
Gateways kann ein Benutzer
das
ganze Spektrum von INGRES-Applikationen (DB-Anwendungen,
Benutzer-Applikationen usw.) verwenden, um auf Daten einer
nicht INGRES-Datenbank zuzugreifen.
Gateways existieren zu den folgenden
fremden DB-Systemen:
- Rdb,
-
RMS,
- DB2
- SQL/DS,
- IMS,
- VSAM-Dateien,
- dBASE III (auf dem PC) und
- DBC/1012 von
Teradata.
INGRES Gateways können, abhängig
davon, ob das fremde
Datenbanksystem die SQL-Sprache
unterstützt oder nicht in
- SQL-Gateways und
- nicht SQL-Gateways
unterteilt
werden.
SQL
Gateways verbinden ein
relationales fremdes DB-System
mit den INGRES-front-ends.
Merkmal von SQL-Gateways ist, daß
abgesehen vom Gateway selbst nur noch das front-end von
INGRES verwendet wird. D.h. die
Verwaltung und der Zugriff
auf nicht INGRES-Daten erfolgt durch
das fremde DBMS.
Weil SQL-Implementierungen auf
unterschiedlichen DB-Systemen
verschieden sind,
unterstützt
INGRES-SQL-Gateways die
Sprache Open SQL, die
eine Untermenge von
SQL ist.
Mit
Open SQL ist es
möglich,
INGRES-DB-Anwendungen und
INGRES-Benutzer-Applikationen für
die Manipulation von Daten
fremder relationaler DB-Systeme zu
benutzen.
Nicht-SQL-Gateways ermöglichen den Zugriff auf
nicht
relationale DBMS. Im
Unterschied zu SQL-Gateways benötigen
nicht-SQL-Gateways sowohl INGRES-front end als auch
das
INGRES-DBMS. Nicht-SQL-Gateway ist
ein Teil des INGRES-DBMS.
Der Zugriff auf Daten
erfolgt direkt, ohne Unterstützung
eines fremden DBMS.