12 Föderative Datenbanksysteme

12.2 Semantische Heterogenität

Selbst wenn alle LDBS identisch sind, also keine Heterogenität in den Datenmodellen sowie der internen Realisierung besteht, bleibt das schwierige Problem der semantischen Heterogenität (Kap. 10.2) zu lösen. Dieses ist in erster Linie eine Folge der Entwurfsautonomie, welche den unabhängigen Entwurf des logischen (und physischen) Aufbaus der einzelnen Datenbanken gestattet. Im Rahmen der Schemaintegration wird versucht, die semantische Heterogenität zu beheben und eine möglichst widerspruchsfreie Datenbankstruktur anzubieten. Bei lose gekoppelten FDBS ist die Behandlung semantischer Heterogenität Aufgabe der Benutzer. Bevor auf diese Ansätze eingegangen wird, sollen hier zunächst die wichtigsten Formen der semantischen Heterogenität näher vorgestellt werden.

Nach [KS91] äußert sich semantische Heterogenität in Form von Schemakonflikten sowie Datenkonflikten. Schemakonflikte können weiterhin unterteilt werden in Namenskonflikte, strukturelle Konflikte sowie Konflikte bei Integritätsbedingungen. Datenkonflikte beruhen entweder auf unterschiedlicher Datenrepräsentation oder fehlenden bzw. widersprüchlichen Datenbankinhalten. Diese Konfliktarten sollen im folgenden näher diskutiert werden. Wir nehmen dazu an, daß die LDBS das relationale Modell unterstützen (bzw. dieses als CDM verwendet wird). Einige der Konflikte können mit folgendem Beispiel illustriert werden.

Beispiel 12-1

Wir betrachten zwei relationale Datenbanken UNIBIB und STADTBIB zur Verwaltung bibliographischer Angaben. Es werden lediglich die Relationen- und Attributnamen spezifiziert, wobei Primärschlüssel durch Unterstreichung gekennzeichnet sind. 

UNIBIB         PUBLIKATION (Pubnr, Titel, Typcode)
               BUCHPUB (Pubnr, Verlag, Ejahr, #Exemplare, ISBN) 
               VERFASSER (Pubnr, Vname)
               SCHLAGWORT (Pubnr, Sname) 
STADTBIB       BUCH (ISBN, Titel, Autor, Vnr, Jahr, Preis, Standort) 
               VERLAG (Vnr, Vname, Adresse)
Beide Datenbanken weisen ähnliche Informationen auf, jedoch bestehen in der Informationsstrukturierung und -benennung sowie im Umfang einige Unterschiede. In der Datenbank STADTBIB werden so lediglich Bücher verwaltet, während in der UNIBIB unterschiedliche Publikationen Aufnahme finden (jeweils mit einem Typcode gekennzeichnet). Außerdem werden in der UNIBIB Schlagworte unterstützt; Angaben zum Buchpreis liegen nur in der STADTBIB vor. Weitere Unterschiede werden im Text aufgezeigt.

Für relationale Datenbanken beziehen sich Schemakonflikte v.a. auf Relationen und Attribute. Namenskonflikte treten in zwei Varianten auf: Synonyme und Homonyme. Synonyme liegen vor, wenn zwei identische bzw. semantisch äquivalente Objekte (Relationen, Attribute) unterschiedliche Namen tragen. Unterschiedliche Objekte mit demselben Namen dagegen repräsentieren Homonyme. In obigem Beispiel sind die Attribute "Verlag" in BUCHPUB (UNIBIB) und "Vname" in VERLAG (STADTBIB) Synonyme, ebenso "Ejahr" (BUCHPUB) und "Jahr" (BUCH). Die Attribute "Vname" in VERFASSER bzw. in VERLAG sind dagegen Homonyme (Verfasser- vs. Verlagsname).

Strukturelle Konflikte treten in vielfältiger Weise auf. So können semantisch äquivalente Informationen (Objekte, Beziehungen) entweder als Relationen oder als Attribute repräsentiert werden. Dabei ist eine Abbildung auf unterschiedlich viele Relationen sowie unterschiedlich viele Attribute möglich. Im Beispiel liegt so in STADTBIB eine eigene Relation VERLAG vor, während in UNIBIB "Verlag" ein einfaches Attribut ist. Umgekehrt werden Angaben zu Autoren in UNIBIB innerhalb einer eigenen Relation geführt (VERFASSER), um mehrere Autoren pro Publikation gleichrangig berücksichtigen zu können, während in STADTBIB ein einfaches Attribut (Autor) verwendet wird. Buchangaben sind primär in den Relationen BUCHPUB bzw. BUCH repräsentiert, welche unterschiedlich viele Attribute aufweisen. Insgesamt sind die bibliographischen Angaben über unterschiedlich viele (4 vs. 2) Relationen verstreut.

Konflikte bezüglich Integritätsbedingungen beziehen sich auf Relationenebene auf Unterschiede bei der Definition der Primärschlüssel und weiteren Schlüsselkandidaten, die Festlegung der Fremdschlüssel sowie unterschiedliche Aktionen zur Wartung der referentiellen Integrität sowie sonstige anwendungsspezifische Integritätsbedingungen, wie sie in SQL92 mit der CHECK-Klausel definiert werden können. Auf Attributebene können Unterschiede beim Datentyp, dem Wertebereich, bei Default-Werten, bezüglich der Zulässigkeit von Nullwerten sowie allgemeinen CHECK-Bedingungen Probleme bereiten.

Im Beispiel liegen unterschiedliche Primärschlüssel vor. In UNIBIB wird hierzu eine in der anderen Datenbank unbekannte "Pubnr" verwendet, während in STADTBIB Bücher über ihre ISBN identifiziert werden. Dieses Attribut existiert auch in UNIBIB, könnte dort jedoch optional besetzt werden (bei Zulässigkeit des Nullwertes). Dann wären möglicherweise übereinstimmende Bücher nicht ausfindig zu machen. Auch bei den Attributen bezüglich Titel-, Autoren- oder Verlagsangaben könnten unterschiedliche Datentypen bzw. sonstige Abweichungen bezüglich Integritätsbedingungen vorliegen, welche die Vergleichbarkeit einschränken.

Datenkonflikte betreffen Unterschiede hinsichtlich der DB-Inhalte, welche auf Schemaebene nicht erkennbar sind. Eine Konfliktursache liegt dabei in der Verwendung unterschiedlicher Datenrepräsentationen, wie sie auch bei übereinstimmenden Datentypen und Wertebereichen möglich ist. So kann bei Preisangaben die Vergleichbarkeit durch Verwendung unterschiedlicher Währungen und Mehrwertsteuer-Berücksichtigung erschwert werden. Für Namen (z.B. Autorennamen) können unterschiedliche Regelungen vorliegen bezüglich der Reihenfolge von Vor- und Nachnamen, der Verwendung von Trennzeichen zwischen Namensteilen, der Behandlung akademischer Titel, etc. So dürfte es z.B. schwierig sein, automatisch zu erkennen, daß die Angaben "Prof. Dr. Theo Härder", "Härder, Theo" und "HAERDER THEO" jeweils dieselbe Person bezeichnen.
Ähnliche Datenkonflikte entstehen durch falsche bzw. unvollständige DB-Inhalte, wie sie z.B. durch Eingabefehler oder unzureichende Informationen entstehen können (z.B. Autorennamen "T. Härder", "Harder, Th."). Widersprüchliche DB-Inhalte ergeben sich auch, wenn repliziert vorliegende Daten nicht zeitgleich geändert werden (z.B. Verlagsadresse).