Dokument 1 - RWTH Aachen University

2.2 Datenintegration 13
Exportschema
1
Lokales
Schema 1
Wrapper
Applikation
Zentraler
Datenbestand
Lokales
Schema 2
Anfrage bzw.
Ergebnisse
Exportschema
Globales Schema
Exportschema
2
Wrapper Wrapper
...
Exportschema
n
Lokales
Schema n
Abbildung 2.2: Vereinfachte Architektur eines Datenintegrationssystems
man als gegeben betrachten muss und nicht ändern kann. Diese lokalen Schemata werden durch
Wrapper-Programme in Exportschemata transformiert, die einerseits ein einheitliches Datenmodell
benutzen und andererseits nur den Teil des lokalen Schemas enthalten, der für das globale
Schema relevant ist. In der von Sheth und Larson [1990] angegebenen Architektur wird zwischen
lokalem Schema und Exportschema noch das Komponentenschema erwähnt, bei dem die
unterschiedlichen Datenmodelle der lokalen Schemata in ein einheitliches Datenmodell überführt
werden soll. Auf die Darstellung des Komponentenschemas in der Abbildung wurde aus
Gründen der Übersichtlichkeit verzichtet.
Im globalen Schema werden die Exportschemata der einzelnen Datenquellen zusammengeführt
bzw. vereinigt. Das globale Schema wird auch föderiertes oder integriertes Schema genannt
[Conrad, 2002]. Dies ist der wesentlichste Schritt der Schemaintegration, bei dem vor allem
folgende Konflikte gelöst werden müssen [Spaccapietra et al., 1992; Jarke et al., 2000a; Conrad,
2002]:
Extensionale Konflikte: Auch wenn zwei Schemata die gleichen Objekte der realen Welt beschreiben,
müssen die dazugehörenden Datenbestände (die Extensionen) nicht gleich sein.
Die Datenbestände können in einer Teilmengenbeziehung zueinander stehen, sich überlappen
oder sie können disjunkt sein.
Beschreibungskonflikte: Die gleichen Objekte können in den Schemata auf unterschiedliche
Weise beschrieben sein. So kann man z.B. für die Darstellung einer Adresse entweder
ein Attribut oder mehrere Attribute für Postleitzahl, Ort, Straße usw. vorsehen. Objekte
können auch durch unterschiedliche Mengen von Attributen charakterisiert werden. Auch