4 Architektur von Verteilten Datenbanksystemen

4.4 Namensverwaltung

Sämtliche Datenbankobjekte in einem Verteilten DBS müssen systemweit eindeutige Namen besitzen, die zudem möglichst stabil sein sollten. Daneben sollte die Namensvergabe Ortstransparenz unterstützen, so daß sich insbesondere nach Migration eines Objektes (Änderung des speichernden Knotens) keine Auswirkungen für bestehende Programme ergeben. Weiterhin sollte ein bestimmtes Programm ohne Modifikation an allen Knoten eines Verteilten DBS ablauffähig sein. Zur Unterstützung von Knotenautonomie gilt es zudem, eine lokale Namensvergabe bei Erzeugung neuer Objekte zu ermöglichen, also ohne durch Kommunikation mit anderen Knoten die globale Eindeutigkeit sicherzustellen. Schließlich muß es auch in Verteilten DBS möglich sein, daß verschiedene Benutzer (unterschiedliche) Objekte mit demselben (logischen) Namen erzeugen.

Zur Unterstützung von Verteilungstransparenz ist es wünschenswert, daß Benutzer die für zentralisierte DBS gültigen Namenskonventionen weiterhin benutzen können. Zentralisierte SQL-Implementierungen verwenden oft eine zweiteilige Namensstruktur für DB-Objekte[14] (Relationen, Sichten, ...), bei der ein logischer Objektname folgendermaßen aufgebaut ist:

[<Benutzername>.]<Objektname>.

Dabei sind sämtliche DB-Objekte dem erzeugenden Benutzer zugeordnet. Die Angabe des Benutzernamens ist nur für Zugriffe auf Objekte eines anderen Benutzers erforderlich. Dieser Ansatz ermöglicht, daß verschiedene Benutzer Objekte mit dem gleichen Objektnamen erzeugen können.

Im (geographisch) verteilten Fall garantiert diese Namensstruktur jedoch keine globale Eindeutigkeit von Objektbezeichnungen, da Benutzernamen i.a. nicht systemweit eindeutig sind. Prinzipiell läßt sich dieses Problem dadurch beheben, indem auf das globale konzeptionelle Schema (GKS) zugegriffen wird, um die Eindeutigkeit eines Objektnamens sicherzustellen. Dies ist am ehesten möglich bei einem Name-Server-Ansatz, bei dem sämtliche Namen des GKS (sowie die physische Lokation der Objekte) an einer zentralen Stelle geführt werden. Dies entspricht einer zentralisierten Katalogverwaltung und verursacht wiederum Kommunikationsverzögerungen zur Namensvergabe und verletzt die Knotenautonomie. Ähnlich problematisch ist die vollständige Replikation des GKS, vor allem bei hoher Rechneranzahl. Denn hierbei sind die durch Erzeugen neuer Objekte bedingten Änderungen des GKS systemweit zu synchronisieren und zu propagieren.

Die Alternative besteht in einem hierarchischen Namenskonzept, bei dem die Objektbezeichnungen zur Erlangung globaler Eindeutigkeit um Knotennamen erweitert werden. Wir bezeichnen solchermaßen erweiterte, systemweit eindeutige Bezeichnungen als globale Objektnamen. Eine mögliche Struktur globaler Objektnamen sieht folgendermaßen aus[15]:

[ [<Knotenname>. ]<Benutzername>.]<Objektname>.

Dabei sei <Knotenname> die Bezeichnung des Rechners, an dem das Objekt erzeugt wurde ("birth site") [Li81]. Ist dieser Name nicht spezifiziert, wird defaultmäßig der Rechner verwendet, an dem die betreffende DB-Operation gestartet wird. Damit kann für lokal erzeugte Objekte die Angabe von Objektnamen wie im zentralen Fall erfolgen. Insbesondere braucht bei der Erzeugung eines neuen Objektes kein Knotenname angegeben werden; zudem läßt sich die globale Eindeutigkeit bereits mit dem lokalen Katalog überprüfen. Für den Zugriff auf nicht-lokale Objekte ist jedoch die Spezifizierung des Knotennamens erforderlich, was Zusatzmaßnahmen zur Gewährleistung von Verteilungstransparenz verlangt (s.u.).

Insgesamt sind drei Arten von Knoten bei der Verwaltung und Speicherung von Objekten beteiligt (Abb. 4-4): der Knoten, an dem ein Objekt erzeugt wurde (birth site), der (oder die) Knoten, an dem Katalogdaten zu dem Objekt verwaltet werden (catalog site), und schließlich die Knoten, an denen das Objekt gespeichert ist (store site). Es handelt sich dabei um eine logische Sichtweise, da ein einzelner Knoten durchaus die verschiedenen Funktionen auf sich vereinen kann (was zur Reduzierung von Kommunikationsvorgängen auch wünschenswert ist). Wesentlich dabei ist, daß der im globalen Objektnamen explizit bezeichnete Geburtsknoten unabhängig vom Speicherungsort ist. Dies ermöglicht Ortstransparenz, da die physische Lokation eines Objektes wechseln kann (Migration von Objekten), ohne daß der globale Namen zu ändern ist. Auch werden Objekte stets an einem Knoten erzeugt, können aber über mehrere Knoten partitioniert oder repliziert gespeichert werden.

Abb. 4-4: Geburts-, Katalog- und Speicherknoten von Objekten [CS91]

Die physische Adresse eines Objektes wird über die globalen Katalogdaten (Verteilungsschema) bestimmt und ist von der gewählten Katalogarchitektur abhängig. Anstatt einer zentralisierten oder replizierten Speicherung dieser Angaben bietet es sich bei der eingeführten Namensstruktur an, diese am "birth site" zu hinterlegen [Li81], so daß dann Geburts- und Katalogknoten zusammenfallen. Dies führt zu einer Partitionierung der globalen Katalogdaten, wobei die globalen Objektnamen direkt spezifizieren, wo die Verteilungsinformation für ein Objekt vorliegt. Dieser partitionierte Ansatz zur Katalog- und Namensverwaltung wurde in R* verwendet. Da zur Unterstützung von Knotenautonomie die globalen Katalogdaten auch an den Speicherknoten zu führen sind, kann es bei Speicherung eines Objektes an mehreren Knoten (Replikation, Fragmentierung) bzw. wenn aufgrund von Datenmigration Speicher- und Geburtsknoten differieren jedoch auch zu einer begrenzten Replikation von Katalogdaten kommen.

Durch die Hinzunahme des Geburtsknotens in globalen Objektnamen ergeben sich jedoch Probleme hinsichtlich der Gewährleistung von Verteilungstransparenz. Denn um auf extern erzeugte Objekte zugreifen zu können, ist die Spezifikation von Knotennamen erforderlich. Soll ein Anwendungsprogramm bzw. eine DB-Operation unverändert an mehreren Rechnern ausführbar sein, sind daneben sämtliche DB-Objekte vollständig zu spezifizieren, um eine korrekte Namensauflösung zu erreichen. Der üblicherweise verwendete Ansatz, um Programme und DB-Operationen ohne Spezifikation von Knotennamen erstellen zu können, liegt in der Definition sogenannter Synonyme (Alias-Namen). Diese werden vom DBS benutzerspezifisch verwaltet und gestatten die Abbildung von einfachen Objektnamen in vollqualifizierte globale Objektnamen. Die Knotenangaben befinden sich dabei lediglich in den Synonymtabellen des DBS, die typischerweise vom Datenbankadministrator für die lokalen Benutzer angelegt werden[16]. Synonyme werden u.a. in R* [Li81] und vielen kommerziellen Systemen (Tandem NonStop SQL [Ta89], DB2, Oracle etc.) verwendet.

Die sich damit ergebenden Einzelschritte bei der Namensauflösung (name resolution) sind in Abb. 4-5 noch einmal zusammengefaßt. Zunächst erfolgt die Umsetzung logischer Namen in globale Objektnamen mit der im lokalen Katalog vorliegenden Synonymtabelle. Liegt kein Synonym vor, erfolgt die defaultmäßige Vervollständigung (Benutzername, Knotenname) zu einem globalen Namen. Der globale Objektname spezifiziert den Geburtsknoten, an dem auch die globale Verteilungsinformation für das betreffende Objekt vorliegt. Damit kann dann schließlich die physische Adresse (Speicherknoten) der zu referenzierenden Daten ermittelt werden.

Abb. 4-5: Namensauflösung in Verteilten DBS


[14] In SQL92 wurde eine erweiterte Namensstruktur eingeführt (s. Übungsaufgaben).
[15] Ein ähnliches Namensschema wird in [Da92] diskutiert.
[16] Alternativ läßt sich auch mit den externen Schemata (bzw. Sichten im Relationenmodell) Verteilungstransparenz erreichen. In diesem Fall sind die logischen Namen der externen Schemata in die globalen Namen des GKS zu transformieren. Synonyme stellen dagegen eine Indirektion auf Ebene der konzeptionellen Schemata dar.