12 Föderative Datenbanksysteme

12.3 Schemaintegration

Ziel der Schemaintegration in eng gekoppelten FDBS ist es, aus mehreren Export-Schemata ein globales konzeptionelles Schema zu erstellen. Damit soll die Unterscheidung mehrerer unabhängiger Datenbanken für den Benutzer des globalen Schemas verborgen werden. Die Schemaintegration erfolgt durch einen oder mehrere GDBA. Dieser Prozeß ist, sofern er überhaupt erfolgreich durchgeführt werden kann, weitgehend manuell vorzunehmen. Denn vor allem die durch die semantische Heterogenität verursachten Konflikte können nur zu einem geringen Teil automatisch behandelt werden. Allerdings soll der Integrationsprozeß durch geeignete Tools für die GDBA soweit als möglich erleichtert werden.

In [BLN86] wurden zur Schemaintegration unterschiedliche Integrationsstrategien gegenübergestellt (Abb. 12-3). Dabei wird zwischen binären und n-stelligen Ansätzen unterschieden je nachdem, ob jeweils zwei oder mehrere (n) Schemata pro Integrationsschritt zusammengeführt werden. Bei der n-stelligen Vorgehensweise kann versucht werden, alle Schemata auf einmal zu integrieren ("one shot"), oder mehrere iterative Integrationsschritte vorzunehmen. In letzterem Fall werden die Zwischenergebnisse vorhergehender Integrationsschritte mit noch nicht berücksichtigten Schemata zusammengeführt. Binäre Strategien erfordern bei mehr als zwei Schemata stets mehrere Integrationsschritte, welche linear oder balanciert (bzw. nicht-linear) ausgeführt werden können (Abb. 12-3). Bei der Beschränkung auf je zwei Schemata kann jeweils nur eine Teilmenge der Schemainformation berücksichtigt werden. Dafür vereinfacht sich der Integrationsprozeß, was auch eine Tool-Unterstützung erleichtert.

Abb. 12-3: Strategien zur Schemaintegration

Die eigentliche Schemaintegration umfaßt die Phasen der Vorintegration, Erkennung und Behebung von Schemakonflikten sowie Mischen und Restrukturierung der Schemaangaben [BLN86]. Im Rahmen der Vorintegration werden die Integrationsstrategie (s.o.) sowie die Reihenfolge, in der die Schemata integriert werden, festgelegt. Weiterhin werden in den beteiligten Schemata die Schlüsselkandidaten bestimmt, um etwaige Abhängigkeiten zwischen den Schemata erkennen zu können. Zudem werden potentiell äquivalente Wertebereiche sowie Transformationsabbildungen (mapping functions) zwischen ihnen (falls erforderlich) festgelegt. Transformationsfunktionen sind auch zur Angleichung unterschiedlicher Repräsentationen vorzusehen (Behebung von Datenkonflikten). Damit kann z.B. eine Umwandlung zwischen numerischen und nicht-numerischen Datentypen oder eine Vereinheitlichung von Preisangaben unterschiedlicher Währungen erfolgen. Um Änderungen auf derart transformierten Daten zu ermöglichen, sind Umkehrfunktionen zu spezifizieren, welche die Transformation rückgängig machen.

In der Phase der Konflikterkennung und -behandlung sind die aufgrund semantischer Heterogenität entstandenen Probleme festzustellen und zu beheben. Dabei ist die Behandlung von Namenskonflikten am unproblematischsten, da hierzu die Umbenennung der betroffenen Objekte genügt. Die Erkennung von Homonymen ist dabei am einfachsten und leicht automatisierbar. Dagegen existiert für die Behandlung struktureller Konflikte sowie von Konflikten hinsichtlich Integritätsbedingungen keine allgemein anwendbare Vorgehensweise. Dies muß manuell durch den GDBA geschehen unter Berücksichtigung der Anwendungssemantik. Allenfalls für häufig vorkommende Transformationsschritte (z.B. Abbildung von Attributen nach Relationen und umgekehrt) kann eine Teilunterstützung erfolgen.

Noch weniger automatisierbar ist die abschließende Phase des Mischens und Restrukturierens. Dabei sollen die Angaben der einzelnen Schemata zusammengeführt werden, so daß keine Informationen verlorengehen (Vollständigkeit). Das erzeugte Schema soll ferner minimal sein, das heißt, möglichst keine Redundanz aufweisen, sowie für den Benutzer leicht verständlich sein. Die Beseitigung der Redundanz ist besonders wesentlich für Änderungsoperationen, da die in den lokalen Datenbanken vorliegende Redundanz nun nicht mehr vom Benutzer zu warten ist. Vielmehr kann durch automatische Anwendung der Änderungen auf allen betroffenen Kopien die globale Konsistenz der Daten sichergestellt werden.

Beispiel 12-2

Für die beiden Datenbanken aus Beispiel 12-1 soll eine Schemaintegration vorgenommen werden. Durch die Beschränkung auf zwei Schemata entfällt die Wahl einer Integrationsstrategie. Zur Vorintegration nehmen wir an, daß für das Attribut ISBN in BUCHPUB keine Nullwerte zugelassen sind (Schlüsselkandidat). Nach Auflösung der Namenskonflikte (kursiv gezeigte Attribute) erhalten wir folgende Relationen: 

      PUBLIKATION (Pubnr, Titel, Typcode)
      BUCHPUB (Pubnr, Vname, Jahr, #Exemplare, ISBN) 
      VERFASSER (Pubnr, Autor)
      SCHLAGWORT (Pubnr, Sname) 
      BUCH (ISBN, Titel, Autor, Vnr, Jahr, Preis, Standort) 
      VERLAG (Vnr, Vname, Adresse)
Die Behebung der anderen Konflikte wird dadurch erschwert, daß die beiden Datenbanken auf Primär- bzw. Fremdschlüsseln basieren, die in der anderen Datenbank unbekannt sind. So ist "Pubnr" nur in der ersten, "Vnr" nur in der zweiten Datenbank bekannt. Ähnliches gilt für die einfachen Attribute "Typcode", "#Exemplare" oder "Standort", die keine übergreifende Bedeutung haben. Probleme bereitet auch die unterschiedliche Behandlung von Autoren.
Zur Behandlung dieser Schwierigkeiten nehmen wir an, daß die Unterschiede über vom GDBA zu spezifizierende Transformationsfunktionen angeglichen werden können. Insbesondere sei es möglich, zu einer Buch-ISBN einen Pubnr-Wert sowie zu einem Verlagsnamen einen Vnr-Wert zu bestimmen. Liegen der ISBN- bzw. Vname-Wert bereits in der BUCHPUB- bzw. VERLAG-Relation vor, ergibt sich die Zuordnung aus dem Inhalt dieser Relationen. Anderenfalls sind durch die Transformationsabbildung neue Nummern zu generieren, die noch nicht vergeben sind. Mit einer weiteren Transformationsfunktion sei es möglich, aus dem Attribut "Autor" in BUCH die Namen der einzelnen Verfasser zu extrahieren und, falls erforderlich, in dieselbe Repräsentation wie für das Attribut "Autor" in VERFASSER zu überführen. Unter diesen Voraussetzungen kann folgender Integrationsansatz gewählt werden, der dem Benutzer den direkten Zugriff auf den gemeinsamen Buchbestand der zwei Bibliotheken gestattet: 

      PUBLIKATION (Pubnr, Titel, Typcode)
      BUCHP (Pubnr, Vnr, Jahr, Preis, Standort-STADT, #Ex-UNI, ISBN)
      VERFASSER (Pubnr, Autor)
      SCHLAGWORT (Pubnr, Sname) 
      VERLAG (Vnr, Vname, Adresse).
Dabei wurden die Attribute der BUCH-Relation unter Anwendung der Transformationen für ISBN und Autor auf die neue Relation BUCHP sowie die Relationen PUBLIKATION (Titel) und VERFASSER (Autor) abgebildet. Die Angaben der Relation BUCHPUB finden sich weitgehend in BUCHP; lediglich der Verlagsname wird jetzt in VERLAG geführt (Anwendung der Transformationsfunktion auf Vname). Die Attribute "Standort" und "#Exemplare" wurden umbenannt, um anzudeuten, daß sie sich auf jeweils eine bestimmte Bibliothek beziehen. Das globale Schema ist vollständig, minimal und redundanzfrei, da jedes Attribut (bis auf die Fremdschlüssel "Pubnr" und "Vnr") genau einmal vorkommt.

Eine Reihe neuerer Forschungsarbeiten favorisiert zur Schemaintegration ein objektorientiertes Datenmodell für das globale Schema [Ah91, HD92, FL93]. Denn die im Vergleich zum Relationenmodell größere Modellierungsmächtigkeit erleichtert die Behandlung von Schema- und Datenkonflikten. Als besonders hilfreich werden Abstraktionskonzepte wie die Generalisierung angesehen, mit der hierarchische Teilmengenbeziehungen zwischen Satztypen (Objektklassen) definiert werden können[55]. Weiterhin lassen sich durch Definition objekttypspezifischer Methoden (Funktionen) mächtige Transformationen realisieren, wie sie z.B. in obigem Beispiel bereits vorausgesetzt wurden. Auf der anderen Seite entsteht durch die Wahl eines mächtigen (objekt-orientierten) Datenmodells das Problem, daß Konzepte und Operationen des globalen Modells von den LDBS nicht unterstützt werden. Dieses Problem kann jedoch auch bei einem relationalen globalen Datenmodell auftreten, wenn die LDBS etwa auf dem hierarchischen Datenmodell beruhen. In solchen Fällen muß i.a. eine eingeschränkte Funktionalität in Kauf genommen werden (womit die Verteilungstransparenz beeinträchtigt wird).

Ein weiteres (bereits erwähntes) Problem der Schemaintegration liegt darin, daß dieser Prozeß weitgehend manuell erfolgen muß. Um semantische Konflikte beheben zu können, sind seitens der GDBA genaue Kenntnisse über den Aufbau aller an einer Föderation beteiligten Datenbanken erforderlich. Dieses zentralisierte Wissen dürfte jedoch vor allem bei Datenbanken unterschiedlicher Unternehmen bzw. Organisationen oft nicht vorliegen bzw. preisgegeben werden, da hiermit eine Einschränkung der Autonomie verbunden ist. Generell wird der manuelle Ansatz der Schemaintegration bei einer größeren Anzahl von Datenbanken schnell unpraktikabel. Schwierigkeiten bereiten dabei vor allem Änderungen in den lokalen Schemata, die aufgrund der Autonomie jederzeit möglich sind. Sofern diese Änderungen die Export-Schemata betreffen, ist eine teilweise Wiederholung der Schemaintegration vorzunehmen, was einen enormen Verwaltungsaufwand verursacht.

[55] In Beispiel 12-2 entspricht so der Satztyp BUCHP einer Teilmenge (Spezialisierung) des Satztyps PUBLIKATION. Die Definition einer Generalisierungshierarchie zwischen diesen Satztypen impliziert, daß Attribute und sonstige Eigenschaften von PUBLIKATION auch für BUCHP-Objekte gelten ("vererbt" werden).