Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Informationsintegration. © Prof. T. Kudraß, HTWK Leipzig 2 Einführung Traditionelle Datenbankverarbeitung zentralisiert Administrationsvorteile Leistungs-

Ähnliche Präsentationen


Präsentation zum Thema: "Informationsintegration. © Prof. T. Kudraß, HTWK Leipzig 2 Einführung Traditionelle Datenbankverarbeitung zentralisiert Administrationsvorteile Leistungs-"—  Präsentation transkript:

1 Informationsintegration

2 © Prof. T. Kudraß, HTWK Leipzig 2 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 3 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 4 Überblick Grundbegriffe Integrationsansätze Materialisierte Integration Virtuelle Integration Architektur föderierter Systeme Integrationskonflikte Schemaintegration Integration mittels Mashups Zusammenfassung

5 © Prof. T. Kudraß, HTWK Leipzig 5 (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 6 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 7 Architekturvarianten

8 © Prof. T. Kudraß, HTWK Leipzig 8 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 9 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 10 Anbindung: virtuell vs. materialisiert Systeme zur Datenintegration Materialisierte IntegrationVirtuelle Integration (Semi-) Strukturierte Daten Mediatoren-SystemeFöderierte DBS(Meta-)Suchmaschinen Data Warehouses Updates, Transaktionen Leseoperationen Strukturierte Anfragen Unstrukturierte Anfragen Verteilte Anfragebearbeitung Kopieren der Daten

11 © Prof. T. Kudraß, HTWK Leipzig 11 Materialisierte Integration Anwendung Für Anfragen wird nur die zentrale Datenbasis benutzt (periodischer) Import In die zentrale Datenbasis Zentrale Datenbasis Quellen

12 © Prof. T. Kudraß, HTWK Leipzig 12 Virtuelle Integration: Mediatorbasierte Informationssysteme Anwendung 1 Anwendung 2 Mediator Wrapper Quelle 1 Quelle 2Quelle 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 13 Mediatorbasierte IS - Beispiel Anwendung Mediator 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 AND Kategorie = Bohrmaschine Welche Quellen sind für diese Anfrage relevant? -Handwerkermarkt -Verbraucherportal

14 © Prof. T. Kudraß, HTWK Leipzig 14 Mediatorbasierte IS – Beispiel (2) Anwendung Mediator Wrapper Handwerkermarkt VerbraucherportalÖffentliche Verwaltung Anfragezerlegung Übersetzung ins Schema der Quellen SELECT Hersteller, Artikel, Rating WHERE Artikelkategorie = Bohrmaschine SELECT Artikelname, Einzelpreis WHERE Artikelkategorie = Bohrmaschine AND Preis <250

15 © Prof. T. Kudraß, HTWK Leipzig 15 Mediatorbasierte IS – Beispiel (3) Anwendung Mediator Wrapper Handwerkermarkt VerbraucherportalÖffentliche Verwaltung Übersetzung in Quellenanfragen Absetzen der Anfragen SQL-Anfrage über JDBC HTTP-Anfragen

16 © Prof. T. Kudraß, HTWK Leipzig 16 Mediatorbasierte IS – Beispiel (4) Anwendung Mediator Wrapper Handwerkermarkt VerbraucherportalÖffentliche Verwaltung Zusammenführung der Ergebnisse einer Quelle Transformation 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 17 Mediatorbasierte IS – Beispiel (5) Anwendung Mediator Wrapper Handwerkermarkt VerbraucherportalÖffentliche Verwaltung Aufbereitung der Ergebnisse für den Benutzer Sammeln der Ergebnisse Übersetzung ins Informationsmodell des Portales z.Bsp.: Artikelname -> Name Verschmelzen der Ergebnismengen

18 © Prof. T. Kudraß, HTWK Leipzig 18 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-basierte Informationssysteme

19 © Prof. T. Kudraß, HTWK Leipzig 19 Systemarchitektur föderierter DBS Föderierungsdienst Globale Anwendungen Lokale Anwendungen Lokale Anwendungen Lokale Anwendungen Lokale Anwendungen Föderiertes DBS Datenbanksystem Komponentensystem Datenbank Metadaten

20 © Prof. T. Kudraß, HTWK Leipzig 20 5-Ebenen-Schema-Architektur Externes Schema Föderiertes (globales) Schema Exportschema Komponentenschema Lokales Schema Externes Schema Exportschema Komponentenschema Lokales Schema Integration Anfragebearbeitung Datenbank Übersetzung in gemeinsames Datenmodell Auswahl der zu integrierenden Teile Schemaintegration Föderiertes Datenbanksystem

21 © Prof. T. Kudraß, HTWK Leipzig 21 Global-As-View Beispiel CREATE VIEW NeuerFilm AS SELECT * FROM IMDB WHERE Jahr > 2000 UNION SELECT * FROM MyMovies WHERE 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 22 Local-As-View Beispiel CREATE VIEW V3 AS SELECT Programm.Kino, Film.Genre FROM Film, Programm WHERE 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 23 Anwendungsgebiete föderierter DBS Meta-Suchmaschinen Digitale Bibliotheken Unternehmensfusionen Kundendatenbanken Personaldatenbanken Krankenhausinformationssysteme Krankheitsverlauf (Akte) Verwaltung Krankenkasse Geo-Informationssysteme

24 © Prof. T. Kudraß, HTWK Leipzig 24 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 Leipzig 25 Integrationsprozess (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 Datenquellen 2.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 Schemas 5.Integration der Daten

26 © Prof. T. Kudraß, HTWK Leipzig 26 Binäre vs. n-äre Integration

27 © Prof. T. Kudraß, HTWK Leipzig 27 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 28 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 29 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 30 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 31 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 32 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 33 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 34 Beispiele für Beschreibungskonflikte HomonymeSchloss TürschlossSchloss Gebäude SynonymePersonalAngestellte Datentypen intstring (für Zahlen) Skalierungen0,153 (Meter)153,0 (Millimeter) Genauigkeiten0,543 kg0,54321 kg Integritäts- bedingungen Gehalt < 6000Gehalt < 7000

35 © Prof. T. Kudraß, HTWK Leipzig 35 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 36 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 37 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 38 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 39 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 40 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 41 Intension und Extension Intension Menge der Schemainformationen und deren Semantik Extension Menge aller zur Intension gehörigen Daten ISBNTitelAutor Mobby Dick Herman Melville Robinso n Crusoe Daniel Defoe XML- DB Karl May Intension Extension

42 © Prof. T. Kudraß, HTWK Leipzig 42 Intensionale Redundanz Liegt vor, wenn das Entfernen von Teilen der Intension die Gesamtintension nicht verändert. Intensionale Redundanz auch über mehrere Relationen und Quellen. ISBNIDTitelAutor Moby DickHerman Melville Robinson Crusoe Daniel Defoe ZwölfNick McDonell TimbuktuPaul Auster

43 © Prof. T. Kudraß, HTWK Leipzig 43 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. ISBNAutor Herman Melville Daniel Defoe Karl May Titel Mobby Dick Robinson Crusoe XML-DB ISBNAutor Herman Melville Daniel Defoe Karl May ISBNTitel XML-DB Mobby Dick Robinson Crusoe

44 © Prof. T. Kudraß, HTWK Leipzig 44 Extensionale Redundanz Liegt vor, wenn die Menge der von zwei Quellen gemeinsam repräsentierten Objekte nicht leer ist. ISBNAutor Herman Melville Karl May IDAutor Karl Mai Herman Melville Extensionale Redundanz Datenkonflikt

45 © Prof. T. Kudraß, HTWK Leipzig 45 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 46 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 47 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 48 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 49 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 50 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 51 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 52 Integrationsregeln (1) Regel 1: Unabhängige Elemente Jedes 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 53 Integrationsregeln (2) Regel 2: Äquivalente Elemente Sind 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 54 Integrationsregeln (3) Regel 3: Pfad-Integration In 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 55 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 56 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 57 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 58 Mashup-Gesamtarchitektur Daten- /Service- Provider (WWW, Web- APIs, Feeds) Mashup-Anwendung Daten- extraktion 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 59 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 60 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 61 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 62 Literatur E. Rahm – Mehrrechner-Datenbanksysteme, Addison Wesley 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 U. Leser, F. Naumann – Informationsintegration: Architekturen und Methoden zur Integration verteilter und heterogener Datenquellen, dpunkt.verlag 2007.


Herunterladen ppt "Informationsintegration. © Prof. T. Kudraß, HTWK Leipzig 2 Einführung Traditionelle Datenbankverarbeitung zentralisiert Administrationsvorteile Leistungs-"

Ähnliche Präsentationen


Google-Anzeigen