4 Architektur von Verteilten Datenbanksystemen

4.3 Katalogverwaltung

Wie im zentralen Fall werden auch in Verteilten DBS die Schemaangaben zum DB-Aufbau sowie weitere Metadaten wie Zugriffsberechtigungen, Paßwörter oder Statistiken (Relationengrößen, Werteverteilungen, Zugriffshäufigkeiten etc.) in einem Katalog verwaltet. Aufgrund der eingeführten Schemaarchitektur kann im verteilten Fall zwischen lokalem und globalem Katalog unterschieden werden. Ein lokaler Katalog entspricht im wesentlichen dem Katalog eines zentralisierten DBS und enthält insbesondere das LKS und LIS eines Knotens. Der globale Katalog dagegen umfaßt u.a. das GKS und GVS und ist damit maßgebend zur Gewährleistung von Verteilungstransparenz. Insbesondere lassen sich mit ihm logische Objektnamen des globalen konzeptionellen Schemas transparent für den Benutzer auf physische Adressen abbilden. Der globale Katalog dient ferner zur systemweiten Verwaltung von Benutzern und Zugriffsrechten. Die Katalogdaten werden vor allem bei der Übersetzung, Optimierung und Ausführung von DB-Anfragen benötigt (Kap. 6).

In relationalen Datenbanksystemen hat es sich durchgesetzt, den Katalog selbst als Datenbank zu führen, auf die mit der DB-Anfragesprache zugegriffen werden kann. Zudem lassen sich dann die Mechanismen zur Transaktionsverwaltung (Synchronisation, Logging, Recovery) auch auf den Katalog anwenden. Der SQL-92-Standard schreibt ein sogenanntes INFORMATION-SCHEMA vor, das aus verschiedenen Sichten (Views) auf den eigentlichen Katalog ("Definition Schema") besteht [[DD92], [MS92]]. Zur Unterstützung von Datenunabhängigkeit bzw. Verteilungstransparenz sind im INFORMATION_SCHEMA keine Angaben bezüglich des internen Schemas (z.B. existierende Indexstrukturen) und Verteilungsschemas vorgesehen. Diese Angaben befinden sich lediglich im Katalog selbst, dessen Aufbau jedoch nicht standardisiert ist, sondern herstellerspezifisch festgelegt werden kann.

Bei der Verwaltung des Katalogs ist neben dem Aufbau des Katalogs vor allem zu klären, wo dieser gespeichert werden soll. Dabei ist generell vorzusehen, daß jeder Knoten einen lokalen Katalog bezüglich der bei ihm vorliegenden Objekte führt. Damit können für lokale Daten auch für den Katalogzugriff Kommunikationsvorgänge vermieden werden. Dies ist bei der oft hohen Lokalität des Datenzugriffs für das Leistungsverhalten sehr wesentlich. Weiterhin wird ein hohes Maß an Knotenautonomie unterstützt. Für die Speicherung des globalen Katalogs bestehen im wesentlichen folgende Alternativen:

Von diesen Alternativen erscheint der letzte Ansatz am vielversprechendsten, da er den höchsten Grad an Knotenautonomie bewahrt. Allerdings werden dabei für nicht-lokale Daten Kommunikationsvorgänge bereits für Katalogzugriffe erforderlich. Dieser Nachteil kann durch eine Pufferung (Caching) nicht-lokaler Katalogdaten abgeschwächt werden. Damit läßt sich für häufiger benötigte Katalogdaten anderer Rechner ebenfalls Kommunikation vermeiden.

Bei der Pufferung nicht-lokaler Katalogdaten besteht ein ähnliches Änderungsproblem wie bei replizierten Katalogen, da gepufferte Kopien nach einer Änderung an einem anderen Knoten ungültig sind. Im Zusammenhang von (replizierter) Pufferung von Objekten spricht manedoch üblicherweise von der Notwendigkeit einer Kohärenzkontrolle [Ra93b]; Anzahl und Ort der Kopien sind im Gegensatz zu replizierten Katalogen (Datenbanken) nicht vorbestimmt sondern ergeben sich dynamisch durch die Referenzverteilung im System. Zur Kohärenzkontrolle für gepufferte Katalogdaten werden im wesentlichen zwei Alternativen eingesetzt:

Ein Sonderfall bei der lokalen Katalogverwaltung ergibt sich, wenn Objekte (Relationen) über mehrere Knoten partitioniert oder repliziert sind. In diesem Fall empfiehlt sich, die Kataloginformation der Objekte repliziert an allen Knoten zu führen, an denen sie (teilweise) gespeichert werden [Li81]. Denn dann können die Katalogzugriffe für lokal vorliegende Objekte weiterhin lokal abgewickelt werden.