12 Föderative Datenbanksysteme

12.1 Schemaarchitektur

Die Schemaarchitektur eines zentralisierten DBS nach ANSI/SPARC (Kap. 2.1.2) sowie die Schemaarchitektur von Verteilten DBS (Kap. 4.2) unterstützen keine ausreichend hohe Autonomie und Heterogenität der LDBS, wie für föderative DBS erforderlich. Eine besser geeignete Schemaarchitektur, welche für unterschiedliche Typen von FDBS anwendbar ist, zeigt Abb. 12-2. Dabei existiert an jedem Knoten, wie bei zentralisierten und Verteilten DBS, ein internes sowie ein konzeptionelles Schema (LIS bzw. LKS). Ebenso greifen Benutzer i.a. über externe Schemata auf die Datenbanken zu. Neu hinzugekommen sind drei Schematypen: Komponenten-, Export- sowie föderative Schemata.

Abb. 12-2: Schemaarchitektur von föderativen DBS [SL90]

Komponenten-Schemata sind erforderlich, wenn die LDBS unterschiedliche Datenmodelle verwenden; sie dienen daher zur Behandlung von Heterogenität (bei den Datenmodellen). Die Komponenten-Schemata basieren auf einem gemeinsamen Datenmodell (Common Data Model, CDM). Jedes lokale konzeptionelle Schema eines anderen Datenmodells wird durch eine Schema-Translation in ein äquivalentes konzeptionelles Schema des CDM (das Komponenten-Schema) transformiert. In der Praxis ist das relationale Datenmodell als ein geeigneter Kandidat für das CDM anzusehen, da bereits ein Großteil der Datenbanken relational aufgebaut ist (und die Schema-Translation damit entfällt) und auch für nicht-relationale Datenbanken (hierarchische und netzwerkartige Datenbanken) meist eine Transformation ins Relationenmodell möglich ist [HK89]. Als sinnvolle Alternative werden vielfach auch semantische Datenmodelle (z.B. Entity-Relationship-Modelle) bzw. objekt-orientierte Modelle angesehen, da sie eine hohe Modellierungsmächtigkeit unterstützen, welche im Transformationsprozeß (sowie zur Schemaintegration) genutzt werden kann [SL90]. Allerdings besteht hier aus praktischer Sicht das Problem, daß eine Vielzahl solcher Modelle existiert und keines dieser Modelle eine signifikante Marktbedeutung erreicht hat. Zudem liegen meist noch Defizite hinsichtlich der Unterstützung mächtiger mengenorientierter DB-Operationen vor.

Export-Schemata werden an jedem Knoten auf dem Komponenten-Schema der lokalen Datenbank definiert. In ihnen wird festgelegt, welche Objekte der lokalen Datenbank im Rahmen einer Föderation externen Benutzern zugänglich gemacht werden sollen (ein Export-Schema pro Föderation). Weiterhin können die zulässigen Operationen durch entsprechende Zugriffsrestriktionen eingeschränkt werden. Die Export-Schemata dienen damit zur Unterstützung der LDBS-Autonomie, insbesondere der Kooperationsautonomie.

Ein föderatives Schema umfaßt die Schemaangaben mehrerer Export-Schemata, und zwar von den an der Föderation beteiligten LDBS. Weiterhin enthält das föderative Schema Angaben zur Datenverteilung, um Operationen auf dem föderativen Schema auf die einzelnen LDBS abbilden zu können (diese Angaben könnten auch in einem separaten Verteilungsschema geführt werden, analog zu Verteilten DBS). Im allgemeinen Fall können unterschiedliche Föderationen gebildet werden, um die Bedürfnisse verschiedener Benutzergruppen abzudecken. Mit externen Schemata kann eine weitergehende Einschränkung der sichtbaren Daten und der zulässigen Operationen für einzelne Benutzer erreicht werden. Benutzer, die lediglich auf eine lokale Datenbank zugreifen, tun dies weiterhin über (in Abb. 12-2 nicht gezeigte) externe Schemata, welche direkt auf das betreffende LKS abgebildet werden.

Die Rolle der föderativen Schemata (sowie der externen Schemata) hängt davon ab, ob ein eng oder ein lose gekoppeltes FDBS realisiert werden soll. Im Falle einer engen Kopplung wird versucht, die Unterscheidung zwischen mehreren Datenbanken durch eine Schemaintegration aufzuheben. In diesem Fall entspricht das föderative Schema einem globalen konzeptionellen Schema, mit dem eine weitgehende Verteilungstransparenz - ähnlich wie bei Verteilten DBS - erreicht werden soll. Die Schemaintegration ist transparent für die Benutzer und wird durch globale Datenbankadministratoren (GDBA) vorgenommen. Das globale Schema besteht dabei nicht nur aus der Vereinigung der einzelnen Export-Schemata, sondern es wird vor allem eine Behandlung der semantischen Heterogenität vorgenommen.
Im Falle der lose gekoppelten FDBS erfolgt keine Schemaintegration, sondern die Unterscheidung mehrerer Datenbanken bleibt für den Benutzer sichtbar. Jeder Benutzer erzeugt sich aus den benötigten Export-Schemata selbst ein föderatives Schema, das nun auch als Import-Schema bezeichnet wird. Dies geschieht typischerweise durch Operationen einer speziellen Multi-DB-Anfragesprache, mit der auch Beziehungen zwischen Objekten verschiedener Export-Schemata definiert werden können (s.u.). Zusätzliche externe Schemata sind bei der losen Kopplung i.a. nicht erforderlich, da das Import-Schema bereits auf die spezifischen Bedürfnisse eines Benutzers abgestimmt werden kann.

Im folgenden diskutieren wir zunächst, welche Arten der semantischen Heterogenität in FDBS vorliegen können. Danach skizzieren wir den Prozeß der Schemaintegration in eng gekoppelten FDBS sowie den Einsatz einer Multi-DB-Anfragesprache in lose gekoppelten FDBS. Abschließend gehen wir auf die Transaktionsverwaltung in FDBS ein.