Informationsintegration. © Prof. T. Kudraß, HTWK Leipzig 2 Einführung Traditionelle...
-
Upload
lora-boeger -
Category
Documents
-
view
107 -
download
2
Transcript of Informationsintegration. © Prof. T. Kudraß, HTWK Leipzig 2 Einführung Traditionelle...
Informationsintegration
2
© Prof. T. Kudraß, HTWK Leipzig
Einführung Traditionelle Datenbankverarbeitung zentralisiert
Administrationsvorteile Leistungs- und Verfügbarkeitsproblem
Entwicklung verteilter Informationssysteme Hohe Leistungsfähigkeit Skalierbarkeit Hohe Verfügbarkeit Verteilungstransparenz Unterstützung dezentraler Organisationsstrukturen Integrierter Zugriff auf heterogene Datenbanken
– Data Warehousing– Unternehmensportale
Einfache Systemadministration, Hohe Kosteneffektivität
3
© Prof. T. Kudraß, HTWK Leipzig
Einführung (2) Zusammenführung von Daten und Inhalten aus
verschiedenen Quellen zu einer einheitlichen Menge von Informationen
Aufnahme zusätzlicher Komponenten, um Angebot zu vergrössern und zu verbessern
Randbedingungen Einbindung soll integriert erfolgen Systeme der eingebundenen Partner bleiben autonom Für die Einbindung keine grossen Änderungen
Integrierte vs. Föderative Mehrrechner-DBS
4
© Prof. T. Kudraß, HTWK Leipzig
Überblick Grundbegriffe Integrationsansätze
Materialisierte Integration Virtuelle Integration
Architektur föderierter Systeme Integrationskonflikte Schemaintegration Integration mittels Mashups Zusammenfassung
5
© Prof. T. Kudraß, HTWK Leipzig
(Knoten)-Autonomie Grad, zu dem verschiedene DBMS unabhängig
kooperieren können Hoher Grad an Autonomie Föderiertes System (oft
lose gekoppelt) Arten der Autonomie
Design-Autonomie (Wahl des DBMS, Wahl der Ablaufumgebung) Ausführungsautonomie (vs. globales Transaktionsmanagement) Kooperationsautonomie / Kommunikationsautonomie
Autonomie als organisatorisches Problem – Beschneidung von Kompetenzen und Verantwortungen
einzelner Systemverantwortlicher
6
© Prof. T. Kudraß, HTWK Leipzig
Begriff Föderation Vgl. Beispiel Bundesrepublik Deutschland
– Bundesländer bedingt autonom– Konflikte durch konkurrierende Gesetzgebung
Weitere Föderationen– Europäische Union– Vereinigte Staaten von Amerika– Vereinte Nationen (UNO)
Charakter einer Föderation– Grad der verbleibenden Autonomie– Heterogenität der beteiligten (Teil-)Staaten
Übertragbarkeit auf Informationssysteme ?
7
© Prof. T. Kudraß, HTWK Leipzig
Architekturvarianten
8
© Prof. T. Kudraß, HTWK Leipzig
Heterogenität Hoher Grad an Autonomie führt zu einer wachsenden
Heterogenität Unterschiedlichkeit von miteinander verbundenen Informationssystemen
Dimension Heterogenität– Technische Heterogenität (syntaktische Ebene)– Datenmodellbasierte Heterogenität– Logische Heterogenität
Semantische Heterogenität (Synonyme, Homonyme) Schemabasierte Heterogenität Strukturelle Heterogenität
Heterogenitäten zu überbrücken ist die Kernaufgabe der Integration!
9
© Prof. T. Kudraß, HTWK Leipzig
Integrations-Beispiel Starke Heterogenität der Systeme
Quelle 1: Oracle-Datenbank Zugriff über JDBC
Quelle 2: CORBA Schnittstelle, über die auf den Informationsbestand zugegriffen werden kann
Quelle 3: XML-Datenbanksystem Zugriff mittels XML-Standards (XPath, XQuery)
Quelle 4: Angebot von statischen HTML-Seiten Zugriff via HTTP-Protokoll
Alle Quellen verwenden unterschiedliche Schemata
Entkopplung durch eine Zwischenschicht, die eine integrierte Sicht zur Verfügung stellt
10
© Prof. T. Kudraß, HTWK Leipzig
Anbindung: virtuell vs. materialisiert
Systeme zur Datenintegration
Materialisierte Integration Virtuelle Integration
(Semi-) Strukturierte Daten
Mediatoren-SystemeFöderierte DBS(Meta-)SuchmaschinenData Warehouses
Updates,Transaktionen Leseoperationen
Strukturierte Anfragen
Unstrukturierte Anfragen
Verteilte AnfragebearbeitungKopieren der
Daten
11
© Prof. T. Kudraß, HTWK Leipzig
Materialisierte Integration
Anwendung
Für Anfragen wird nur die zentrale Datenbasis benutzt
(periodischer) ImportIn die zentrale Datenbasis
Zentrale Datenbasis
Quellen
12
© Prof. T. Kudraß, HTWK Leipzig
Virtuelle Integration: Mediatorbasierte Informationssysteme
Anwendung 1Anwendung 1 Anwendung 2Anwendung 2
MediatorMediator
MediatorMediator
WrapperWrapper WrapperWrapper WrapperWrapper
Quelle 1 Quelle 2 Quelle 3
Daten aus verschiedenen Quellen müssen zusammengefasst werden
Schema Mapping
Schaffung leicht-gewichtiger, verwaltbarer Mediatoren
Kopplung verschiedener Mediatoren zu einer
mehrschichtigen Föderationsarchitektur
13
© Prof. T. Kudraß, HTWK Leipzig
Mediatorbasierte IS - Beispiel
Anwendung
Mediator Mediator
Wrapper Wrapper Wrapper
Handwerkermarkt Verbraucherportal Öffentliche Verwaltung
Benutzer wählt aus Kategorie>>Bohrmaschinen<< unter € 250,-
Benutzer wählt aus Kategorie>>Bohrmaschinen<< unter € 250,- Generierung der Anfrage:
SELECT Name, Preis, Bewertung WHERE Preis < 250 ANDKategorie = BohrmaschineWelche Quellen sind für
diese Anfrage relevant?-Handwerkermarkt-Verbraucherportal
14
© Prof. T. Kudraß, HTWK Leipzig
Mediatorbasierte IS – Beispiel (2)
Anwendung
Mediator Mediator
Wrapper Wrapper Wrapper
Handwerkermarkt Verbraucherportal Öffentliche Verwaltung
AnfragezerlegungÜbersetzung ins Schema der Quellen
SELECT Hersteller, Artikel, RatingWHERE Artikelkategorie = „Bohrmaschine“
SELECT Artikelname, EinzelpreisWHERE Artikelkategorie = „Bohrmaschine“ AND Preis <250
15
© Prof. T. Kudraß, HTWK Leipzig
Mediatorbasierte IS – Beispiel (3)
Anwendung
Mediator Mediator
Wrapper Wrapper Wrapper
Handwerkermarkt Verbraucherportal Öffentliche Verwaltung
Übersetzung in QuellenanfragenAbsetzen der Anfragen
SQL-Anfrage über JDBC
HTTP-Anfragen
16
© Prof. T. Kudraß, HTWK Leipzig
Mediatorbasierte IS – Beispiel (4)
Anwendung
Mediator Mediator
Wrapper Wrapper Wrapper
Handwerkermarkt Verbraucherportal Öffentliche Verwaltung
Zusammenführung der Ergebnisse einer QuelleTransformation in das gemeinsame Datenmodell und Ausführung von
Filteroperationen
JDBC – Result Set
HTML-Seite
Quellen liefern Ergebnis zurück
17
© Prof. T. Kudraß, HTWK Leipzig
Mediatorbasierte IS – Beispiel (5)
Anwendung
Mediator Mediator
Wrapper Wrapper Wrapper
Handwerkermarkt Verbraucherportal Öffentliche Verwaltung
Aufbereitung der Ergebnisse für den Benutzer
Sammeln der Ergebnisse
Übersetzung ins Informationsmodell des Portales
z.Bsp.: Artikelname -> NameVerschmelzen der Ergebnismengen
18
© Prof. T. Kudraß, HTWK Leipzig
Typen von föderierten IS
Föderierte Informationssysteme
Föderiertes SchemaKein Föderiertes Schema
Komponenten sind nicht nur Datenbanken
Komponenten sind Datenbanken
Lose gekoppelte Informationssysteme
Föderierte Datenbanksysteme
Mediator-basierteInformationssysteme
19
© Prof. T. Kudraß, HTWK Leipzig
Systemarchitektur föderierter DBS
Föderierungsdienst
Globale AnwendungenGlobale Anwendungen Globale AnwendungenGlobale Anwendungen
Lokale Anwendungen
Lokale Anwendungen
Lokale Anwendungen
Lokale Anwendungen
Föderiertes DBS
Datenbanksystem Datenbanksystem
KomponentensystemKomponentensystem
Datenbank Datenbank
Metadaten
20
© Prof. T. Kudraß, HTWK Leipzig
5-Ebenen-Schema-Architektur
Externes Schema
Föderiertes (globales) SchemaFöderiertes (globales) Schema
ExportschemaExportschema
KomponentenschemaKomponentenschema
Lokales Schema
Externes Schema
ExportschemaExportschema
KomponentenschemaKomponentenschema
Lokales Schema
Integration Anfragebearbeitung
Datenbank Datenbank
Übersetzung in gemeinsames Datenmodell
Auswahl der zu integrierenden Teile
Schemaintegration
Föderiertes Datenbanksystem
21
© Prof. T. Kudraß, HTWK Leipzig
Global-As-View Beispiel
CREATE VIEW NeuerFilm ASSELECT * FROM IMDBWHERE Jahr > 2000UNIONSELECT * FROM MyMoviesWHERE Jahr > 2000
Globales Schema
NeuerFilm(Titel, Regie, Jahr, Genre)Programm(Kino, Titel, Zeit)Nebenbedingung: Jahr > 2000
Globales Schema
NeuerFilm(Titel, Regie, Jahr, Genre)Programm(Kino, Titel, Zeit)Nebenbedingung: Jahr > 2000
Lokale Schemata
V1: IMDB(Titel, Regie, Jahr, Genre)V2: MyMovies(Titel, Regie, Jahr, Genre)
Lokale Schemata
V1: IMDB(Titel, Regie, Jahr, Genre)V2: MyMovies(Titel, Regie, Jahr, Genre)
Bekannte Nebenbedingung auf dem globalen Schema kann modelliert werden.
Bottom-Up-Integration
22
© Prof. T. Kudraß, HTWK Leipzig
Local-As-View Beispiel
CREATE VIEW V3 ASSELECT Programm.Kino, Film.GenreFROM Film, ProgrammWHERE Film.Titel = Programm.Titel
Globales Schema
Film(Titel, Regie, Jahr, Genre)Programm(Kino, Titel, Zeit)
Globales Schema
Film(Titel, Regie, Jahr, Genre)Programm(Kino, Titel, Zeit)
Lokales Schema
V3: KinoDB(Kino, Genre)
Lokales Schema
V3: KinoDB(Kino, Genre)
Assoziationen des globalen Schemas können in der Sicht hergestellt werden.
Top-Down-Integration
23
© Prof. T. Kudraß, HTWK Leipzig
Anwendungsgebiete föderierter DBS Meta-Suchmaschinen
Digitale Bibliotheken
Unternehmensfusionen Kundendatenbanken Personaldatenbanken
Krankenhausinformationssysteme Krankheitsverlauf (Akte) Verwaltung Krankenkasse
Geo-Informationssysteme
24
© Prof. T. Kudraß, HTWK Leipzig
Integrationsprozess (virtuelle Integration)
Bildung eines globalen Schemas (Schemaintegration) Generierung von Wrappern für jede Datenquelle
Softwarekomponente Mapping von lokalen Schemata auf globales Schema Kennt Anfragefähigkeiten der Quellen
Daten bleiben vor Ort Informationsquellen sind autonom
25
© Prof. T. Kudraß, HTWK LeipzigIntegrationsprozess (materialisierte Integration) Keine wirklich einheitliche und durchgängige Methodik
für die Durchführung der Integration vorhanden 5 Phasen des Integrationsprozesses:
1. Analyse der zu integrierenden Datenquellen2. Transformation der gegebenenfalls heterogenen Beschreibungen
der Daten (Datenbankschemata) in ein gemeinsames Datenmodell
3. Feststellung der sich semantisch entsprechenden Daten (Angabe sogenannter Korrespondenzen)
4. Ableitung eines integrierten Schemas5. Integration der Daten
26
© Prof. T. Kudraß, HTWK Leipzig
Binäre vs. n-äre Integration
27
© Prof. T. Kudraß, HTWK Leipzig
Probleme beim Integrationsprozess Datenbankschemata oft nicht vollständig Datenquellen oft "semistrukturiert", oder es gibt
überhaupt kein Datenbankschema In Altsystemen: Semantik der Daten in der Datenbank
nicht vollständig bekannt Korrespondenzen und Abhängigkeiten zwischen Daten
aus verschiedenen Quellen sind nicht bekannt Wie ist die Heterogenität zu überwinden?
28
© Prof. T. Kudraß, HTWK Leipzig
Kriterien für Integrationsmethoden Vollständigkeit (Completeness)
– Alle Informationen aus lokalen Schemata erhalten
Korrektheit (Correctness)– Neue Beziehungen dürften vorhandene Schemata
konsistent ergänzen
Minimalität (Minimality)– Vermeidung von Redundanz
Verständlichkeit (Understandability)– Bekanntes aus lokalem Schema ins föderierte
Schema übernehmen
Vergleich mit traditionellem DB-Entwurf?
29
© Prof. T. Kudraß, HTWK Leipzig
Klassifizierung von Integrationskonflikten
Datenmodell-Heterogenität Unterschiedliche Semantik Unterschiedliche Struktur
Schema- oder Modellierungsheterogenität Strukturelle Konflikte Extensionale Konflikte Beschreibungskonflikte
Heterogenität auf Datenebene (Datenkonflikt)
30
© Prof. T. Kudraß, HTWK Leipzig
Datenmodellkonflikte Vielzahl an Datenmodellen mit unterschied-
lichen Modellierungskonstrukten– objektorientiert, relational, XML, hierarchisch,
objektrelational
Beispiele:– Mengenwertige Attribute (objektrelational) vs.
Fremdschlüsselbeziehung (relational)– Modellierung von Spezialisierung im relationalen
Modell (mindestens 3 Varianten)
Konstrukte eines Datenmodells werden oft nicht vollständig oder falsch verwendet
31
© Prof. T. Kudraß, HTWK Leipzig
Schematische Heterogenität Unterschiedliche Modellierung gleicher Sachverhalte Strukturelle Konflikte
Modellierung: Relation vs. Attribut, Attribut vs. Wert, Relation vs. Wert
Benennung: Relationen, Attribute Geschachtelt vs. Fremdschlüssel
Männer (Id, Vorname, Nachname)Frauen (Id, Vorname, Nachname)
Männer (Id, Vorname, Nachname)Frauen (Id, Vorname, Nachname)
Person ( Id, Vorname, Nachname,Männlich, Weiblich )
Person ( Id, Vorname, Nachname,Männlich, Weiblich )
32
© Prof. T. Kudraß, HTWK Leipzig
Schematische Heterogenität (2) Tabellen – Tabellen Konflikte
Namenskonflikte (gleiche Namen aber unterschiedliche Tabellen)
Strukturkonflikte (fehlende Attribute)
Attribut – Attribut Konflikte Namenskonflikte (gleiche Namen aber unterschiedliche
Attribute) Default-Wert Konflikte IC-Konflikte (Datentypkonflikte, Bedingungskonflikte)
33
© Prof. T. Kudraß, HTWK Leipzig
Beschreibungskonflikte Unterschiedliche Auswahl an erfassten
Objekteigenschaften Homonyme und synonyme Bezeichnungen
– bei Attributen, Klassen, Relationen, Beziehungen
Datentypkonflikte Wertebereichskonflikte Skalierungskonflikte (Maßeinheiten) Genauigkeitskonflikte Konflikte durch Integritätsbedingungen Konflikte der Manipulationsoperationen
34
© Prof. T. Kudraß, HTWK Leipzig
Beispiele für Beschreibungskonflikte
Homonyme Schloss → Türschloss Schloss → Gebäude
Synonyme Personal Angestellte
Datentypen int string (für Zahlen)
Skalierungen 0,153 (Meter) 153,0 (Millimeter)
Genauigkeiten 0,543 kg 0,54321 kg
Integritäts-bedingungen
Gehalt < 6000 Gehalt < 7000
35
© Prof. T. Kudraß, HTWK Leipzig
Synonyme Verschiedene Worte mit gleicher Bedeutung
PUBLIKATION (Pubnr, Titel, Typcode)BUCHPUB (Pubnr, Verlag, Ejahr, Exemplare, ISBN)VERFASSER (Pubnr, Vname)SCHLAGWORT (Pubnr, Sname)
PUBLIKATION (Pubnr, Titel, Typcode)BUCHPUB (Pubnr, Verlag, Ejahr, Exemplare, ISBN)VERFASSER (Pubnr, Vname)SCHLAGWORT (Pubnr, Sname)
BUCH (ISBN, Titel, Autor, Vnr, Jahr, Preis, Standort)VERLAG (Vnr, Vname, Adresse)
BUCH (ISBN, Titel, Autor, Vnr, Jahr, Preis, Standort)VERLAG (Vnr, Vname, Adresse)
Quelle 1 - UNIBIB:
Quelle 2 - STADTBIB:
36
© Prof. T. Kudraß, HTWK Leipzig
Homonyme Gleiche Worte mit unterschiedlicher Bedeutung
PUBLIKATION (Pubnr, Titel, Typcode)BUCHPUB (Pubnr, Verlag, Ejahr, Exemplare, ISBN)VERFASSER (Pubnr, Vname)SCHLAGWORT (Pubnr, Sname)
PUBLIKATION (Pubnr, Titel, Typcode)BUCHPUB (Pubnr, Verlag, Ejahr, Exemplare, ISBN)VERFASSER (Pubnr, Vname)SCHLAGWORT (Pubnr, Sname)
BUCH (ISBN, Titel, Autor, Vnr, Jahr, Preis, Standort)VERLAG (Vnr, Vname, Adresse)
BUCH (ISBN, Titel, Autor, Vnr, Jahr, Preis, Standort)VERLAG (Vnr, Vname, Adresse)
Quelle 1 - UNIBIB:
Quelle 2 - STADTBIB:
37
© Prof. T. Kudraß, HTWK Leipzig
Hauptproblem: Semantische Heterogenität
Bezeichnet Unterschiede in Bedeutung, Interpretation und Art der Nutzung
Annahme bisher gleiche Bezeichnung, gleiche Semantik
Repräsentiert Objekt A die gleiche Entität wie Objekt B? (Identifikationskonflikte)
Datenkonflikt: Zwei Duplikate haben unterschiedliche Attributwerte für semantisch gleiches Attribut
Genauigkeitskonflikte
38
© Prof. T. Kudraß, HTWK Leipzig
Datenkonflikte Inkorrekte Einträge
– Tippfehler bei der Eingabe von Werten– Falsche Einträge aufgrund von Programmierfehlern
Veraltete Einträge– Unterschiedliche Aktualisierungszeitpunkte– Vergessene Aktualisierungen
Verschiedene Ausdrücke / Repräsentation von Werten– Verschiedene Datentypen (numerisch vs. nicht-
numerisch)– Unterschiedliche Schreibweisen, Genauigkeit,
Skalierung (bei gleichem Datentyp)
39
© Prof. T. Kudraß, HTWK Leipzig
Behebung von Datenkonflikten Angabe expliziter Werteabbildungen Einführung von Ähnlichkeitsmaßen Bevorzugung der Werte aus einer lokalen
Quelle Verwendung von Hintergrundwissen
– Konventionen hinsichtlich Schreibweisen– Behandlung von Homonymen und Synonymen auf
Datenebene: Wörterbücher, Thesauri, Ontologien
Wissensbasierte Verfahren
40
© Prof. T. Kudraß, HTWK Leipzig
Integrationspotential Wann ist eine Informationsintegration möglich?
Intensionale Redundanz
Wann ist eine Informationsintegration schwierig? Extensionale Redundanz
Wann ist eine Informationsintegration nützlich? Extensionale Komplementierung Intensionale Komplementierung
41
© Prof. T. Kudraß, HTWK Leipzig
Intension und Extension Intension Menge der Schemainformationen
und deren Semantik Extension Menge aller zur Intension
gehörigen Daten
ISBN Titel Autor
123456 Mobby Dick
Herman Melville
789101 Robinson
Crusoe
Daniel Defoe
122222 XML-DB
Karl May
Intension
Extension
42
© Prof. T. Kudraß, HTWK Leipzig
Intensionale Redundanz Liegt vor, wenn das Entfernen von Teilen der Intension
die Gesamtintension nicht verändert. Intensionale Redundanz auch über mehrere
Relationen und Quellen.
ISBN ID Titel Autor
3442727316 3442727316 Moby Dick Herman Melville
3491960827 3491960827 Robinson Crusoe
Daniel Defoe
3462032283 3462032283 Zwölf Nick McDonell
3883891606 3883891606 Timbuktu Paul Auster
43
© Prof. T. Kudraß, HTWK Leipzig
Intensionale Komplementierung
Informationen mehrerer (sich komplementierender) Quellen werden zu einem größeren Ganzen integriert
Intensionale Komplementierung liegt vor, wenn von zwei Intensionen mindestens eine Differenz nicht leer ist, und deren Schnittmenge nicht leer ist.
ISBN Autor
123456 Herman Melville
789101 Daniel Defoe
122222 Karl May
Titel
Mobby Dick
Robinson Crusoe
XML-DB
ISBN Autor
123456 Herman Melville
789101 Daniel Defoe
122222 Karl May
ISBN Titel
122222 XML-DB
123456 Mobby Dick
789101 Robinson Crusoe
44
© Prof. T. Kudraß, HTWK Leipzig
Extensionale Redundanz Liegt vor, wenn die Menge der von zwei Quellen
gemeinsam repräsentierten Objekte nicht leer ist.
ISBN Autor
123456 Herman Melville
122222 Karl May
ID Autor
122222 Karl Mai
123456 Herman Melville
Extensionale RedundanzExtensionale Redundanz DatenkonfliktDatenkonflikt
45
© Prof. T. Kudraß, HTWK Leipzig
Zusammenfassung Redundanz* Extensionale Redundanz ermöglicht
intensionale Komplementierung Zwei Quellen, die über gleiche Dinge sprechen, können zu
einer dichteren Quelle integriert werden (Density)
Intensionale Redundanz ermöglicht extensionale Komplementierung
Zwei Quellen mit gleichem Schema können zu einer überdeckenderen Quelle integriert werden (Coverage)
46
© Prof. T. Kudraß, HTWK Leipzig
Schemaintegration Ziel: aus mehreren Export-Schemata ein
globales konzeptionelles Schema erstellen Unterstützung durch geeignete Tools Umfasst 3 Phasen:
Vorintegration Erkennung und Behebung von Konflikten Mischen und Restrukturierung der Schemaangaben
47
© Prof. T. Kudraß, HTWK Leipzig
Schemaintegration – Beispiel
PUBLIKATION (Pubnr, Titel, Typcode)BUCHPUB (Pubnr, Verlag, Ejahr, Exemplare, ISBN)VERFASSER (Pubnr, Vname)SCHLAGWORT (Pubnr, Sname)
PUBLIKATION (Pubnr, Titel, Typcode)BUCHPUB (Pubnr, Verlag, Ejahr, Exemplare, ISBN)VERFASSER (Pubnr, Vname)SCHLAGWORT (Pubnr, Sname)
BUCH (ISBN, Titel, Autor, Vnr, Jahr, Preis, Standort)VERLAG (Vnr, Vname, Adresse)
BUCH (ISBN, Titel, Autor, Vnr, Jahr, Preis, Standort)VERLAG (Vnr, Vname, Adresse)
Quelle 1 - UNIBIB:
Quelle 2 - STADTBIB:
1. Vorintegration
2. Konflikterkennung +Behebung
3. Mischen + Restrukturierung
48
© Prof. T. Kudraß, HTWK Leipzig
Schemaintegration – Beispiel (2)
PUBLIKATION (Pubnr, Titel, Typcode)BUCHPUB (Pubnr, Vname, Jahr, Exemplare, ISBN)VERFASSER (Pubnr, Autor)SCHLAGWORT (Pubnr, Sname)
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)
BUCH (ISBN, Titel, Autor, Vnr, Jahr, Preis, Standort)VERLAG (Vnr, Vname, Adresse)
Quelle 1 - UNIBIB:
Quelle 2 - STADTBIB:
1. Vorintegration
2. Konflikterkennung +Behebung
3. Mischen + Restrukturierung
49
© Prof. T. Kudraß, HTWK Leipzig
Schemaintegration – Beispiel (3)
1. Vorintegration
2. Konflikterkennung +Behebung
3. Mischen + Restrukturierung
Schwierigkeit Integritätsbedingungen
- „Pubnr“ nur in der ersten und „Vnr“ nur in der zweiten Datenbank bekannt
- Unterschiedliche Behandlung von Autoren
- Annahme zu BUCH-ISBN kann ein „Pubnr“ Wert und zu einem Verlagsname ein „Vnr“ Wert bestimmt werden
- Liegen der ISBN bzw. Vname Wert bereits in BUCHPUB bzw. VERLAG vor ergibt sich die Zuordnung aus dem Inhalt
- Gegebenfalls neue Nummern generieren
- Attribut Autor aus BUCH extrahieren und in VERFASSER überführen
50
© Prof. T. Kudraß, HTWK Leipzig
Schemaintegration – Beispiel (4)
PUBLIKATION (Pubnr, Titel, Typcode)BUCHP (Pubnr, Vnr, Jahr, Preis, Standort-STADT, Ex-UNI, ISBN)VERFASSER (Pubnr, Autor)SCHLAGWORT (Pubnr, Sname)VERLAG (Vnr, Vname, Adresse)
PUBLIKATION (Pubnr, Titel, Typcode)BUCHP (Pubnr, Vnr, Jahr, Preis, Standort-STADT, Ex-UNI, ISBN)VERFASSER (Pubnr, Autor)SCHLAGWORT (Pubnr, Sname)VERLAG (Vnr, Vname, Adresse)
1. Vorintegration
2. Konflikterkennung +Behebung
3. Mischen + Restrukturierung
- Attribute der BUCH Relation auf BUCHP, PUBLIKATION und VERFASSER abgebildet
- Angaben von BUCHPUB befinden sich weitgehend in BUCHP, lediglich Verlagsname nun in VERLAG
51
© Prof. T. Kudraß, HTWK Leipzig
Prinzipien der Schemaintegration Korrespondenzen
– Element-Korrespondenzen (z.B. Klassen, Relationen)– Attribut-Korrespondenzen– Pfad-Korrespondenzen
Korrespondenzen auf Basis von Mengenbeziehungen– Äquivalenz– Teilmengenbeziehung / Einschluß– Überlappung– Disjunktheit
52
© Prof. T. Kudraß, HTWK Leipzig
Integrationsregeln (1)
Regel 1: Unabhängige ElementeJedes Schemaelement, zu dem es keine Korrespondenz mit einem Schemaelement des anderen Schema gibt, wird unverändert ins föderierte Schema übernommen.
53
© Prof. T. Kudraß, HTWK Leipzig
Integrationsregeln (2)
Regel 2: Äquivalente ElementeSind 2 Schemaelemente der zu integrierenden Schemata über eine Element-Korrepondenz als äquivalent bestimmt, so werden diese beiden Schemaelemente im föderierten Schema durch genau ein Schemaelement repräsentiert.
Integrationsregeln für Attribute– Attribute ohne Korrespondenz unverändert übernehmen– 2 Attribute mit Gleichheits-Korrespondenz → zu einem Attribut im
föderierten Schema zusammenfassen– Bei Teilmengen-Korrespondenz → Attribut, das Obermenge
repräsentiert, ins föderierte Schema übernehmen– Bei Überlappungs-Korrespondenz → neues Attribut anlegen, das die
Vereinigung der beiden Wertemenge repräsentiert, andere Form der Zusammenführung bei Disjunktheit (z.B. Summe, Mittelwertbildung)
54
© Prof. T. Kudraß, HTWK Leipzig
Integrationsregeln (3)
Regel 3: Pfad-IntegrationIn der Regel müssen die beiden zueinander in Korrespondenz stehenden Pfade im föderierten Schema jeweils durch einen semantisch äquivalenten Pfad abgebildet sein. Nur falls eine Pfad-Äquivalenz als Korrespondenz vorliegt, reicht es, wenn einer der beiden Pfade im föderierten Schema abgebildet ist.Sind beide Pfade vollständig im integrierten Schema enthalten, liefert die Pfad-Korrespondenz eine Integritätsbedingung, die auf Ebene des föderierten Schemas zu überwachen ist.
Beispiel– KUNDE – bestellt – WARE = ABNEHMER – versorgt– WARE – produziert – Hersteller = versorgt – PRODUZENT– abgeleitet: KUNDE – bestellt – WARE – produziert – HERSTELLER =
ABNEHMER – versorgt – PRODUZENT
55
© Prof. T. Kudraß, HTWK Leipzig
Mashup-Ansatz zur Datenintegration besondere Art von Anwendungen zur
Datenintegration neuer Ansatz gegenüber „klassischen“
Datenintegrationsansätzen wie Data Warehouses oder Query-Mediatoren
Entwicklung– potenzieller Kreis der Mashup-Entwickler viel größer
(evtl. ohne Programmierkenntnisse)– kurze Entwicklungszeit, frühzeitige Evaluierung und
Anpassung (Stunden, Tage)– Geeignet für Prototyping und agile
Entwicklungsmethoden
56
© Prof. T. Kudraß, HTWK Leipzig
Arten von Mashups Mapping-Mashups
– Integrieren Daten aus online verfügbaren Karten (maps)– Hohe Verbreitung durch Mapping-APIs (Google, Yahoo, Microsoft)
Foto- und Video-Mashups– motiviert durch Foto-Hosting-Sites (flickr) und Videoportale (YouTube) – Integration externer Daten mit Hilfe von Metadaten (z.B. für aktuelle
Nachrichten) Such- und Shopping-Mashups
– Anbieter: Google Froogle, PriceGrabber– Vergleichsinformationen zu Produkten verschiedener Anbieter– Heute Webschnittstellen zum Zugriff auf Produktinformationen (z.B.
Amazon, eBay) Nachrichten-Mashups
– Kombinieren Agenturmeldungen mit Beiträgen in Web (Blogs, Foren u.ä.)
57
© Prof. T. Kudraß, HTWK Leipzig
Mashups und Datenintegration
Datenextraktion– Verschiedene Schnittstellen von Datenprovidern– Standardisierte Protokolle und Formate
Datenfluss– extrahierte Daten transformieren und miteinander kombinieren– Benötigte Logik in Mashup-Anwendung (Servlets, PHP o.ä.)
Präsentation– Webbrowser visualisiert Mashup-Ergebnis für Client– Generieren von (X)HTML-Code, ggf. Feed-Format )RSS, Atom)
für Newsreader
58
© Prof. T. Kudraß, HTWK Leipzig
Mashup-Gesamtarchitektur
Daten-/Service-Provider (WWW, Web-APIs, Feeds)
Daten-/Service-Provider (WWW, Web-APIs, Feeds)
Mashup-Anwendung
Daten-extraktio
n
Daten-fluss
Präsen-tation
Client(Webbrowser,Feedreader)
(X)HTML, RSS, Atom, CSV, JSON
(X)HTML, JavaScript, RSS, Atom
59
© Prof. T. Kudraß, HTWK Leipzig
Mashup vs. „klassische“ Datenintegration Entwicklungsprozess
– Mashup = prototyp. Entwicklung von DI-Anwendungen– Klassische DI erfordert Vorlaufzeit (Data Cleaning, Schema
Integration) Integrationsart
– Zugriff auf Datenquellen mittels Wrapper ähnlich klassische DI– „Low-Level-Integration“: keine explizite semantische
Beschreibung der Quellen und ihrer Verbindung, stattdessen fest codierter Datenfluss
– virtuelle Integration (d.h. Extraktion und Kombination der Daten zur Laufzeit)
– geeignet eher für kleine Datenvolumina Verwendung
relativ starre Verknüpfung der Daten eher aufgabenspezifische Anwendungen (anders als ein DWH für
beliebige Analysen) Kürzere Lebensdauer
60
© Prof. T. Kudraß, HTWK Leipzig
Werkzeuge zur Mashup-Erstellung Tools zur Datenextraktion von Informationen aus
Websites Tools zur Modellierung und Ausführung von Datenflüssen
– Komponenten zur Datenverarbeitung (z.B. Transformation und Aggregation von Datenwerten und –objekten)
Anwendungen zur Unterstützung der Präsentation, d.h. zur integrierten Darstellung innerhalb eines Frontends und Interaktion mit Benutzer
Beispiele:– Extraktion: Dapper, OpenKapow Robomaker (frei verfügbar)– Datenrepräsentation: Google Mashup Editor– Datenflussmodellierung: Apatar, Microsoft Popfly, IBM Damia,
Yahoo! Pipes Literatur:
D. Aumüller, A. Thor: Mashup-Werkzeuge zur Ad-hoc-Datenintegration im Web, in: Datenbank-Spektrum 26/2008
61
© Prof. T. Kudraß, HTWK Leipzig
Zusammenfassung und Ausblick
Weiterentwicklung bestehender Schemaintegrationsverfahren
Theoretisch wohlüberlegte Ansätze häufig qualitativ unbefriedigende Ergebnisse
Berücksichtigung von Unsicherheiten bei der Datenbankintegration
Informationsintegration grosse Herausforderung Suchmaschinen im Web liefern „nur“ Dokumente, welche
Suchbegriffe enthalten Vorgestellte Systeme auf Unterstützung strukturierter
Anfragen ausgerichtet
62
© Prof. T. Kudraß, HTWK Leipzig
Literatur E. Rahm – „Mehrrechner-Datenbanksysteme“, Addison
Wesley 1994. Datenbank Spektrum (Heft 6 / Juni 2003) S. Conrad, W. Hasselbring, A. Koschel, R. Tritsch –
„Enterprise Application Integration: Grundlagen – Konzepte – Entwurfsmuster – Praxisbeispiele“, Elsevier Spektrum Akademishcer Verlag 2006.
U. Leser, F. Naumann – „Informationsintegration: Architekturen und Methoden zur Integration verteilter und heterogener Datenquellen“, dpunkt.verlag 2007.