Ausgangspunkt. Datenintegration. Ziel. Konflikte. Architekturen. Transparenz

Transkript

1 Ausgangspunkt Datenintegration Web Informationssysteme Wintersemester 2002/2003 Donald Kossmann Daten liegen in verschiedenen Datenquellen (Extremfall: jede URL eigene Datenquelle) Mietautos bei Hotel bei Flüge bei Datenquellen sind heterogen Relationale Datenbanken Web Anwendungssystem (Web Dienst) Server Datenbank Filesystem,,... Struktur Konflikte DB1: book(isbn, author), pub(isbn, title) DB2: book(isbn, author, title), pub(isbn, title) Typen, Formate, Namen DB1: deutsches Zahlenformat: ,00 DB2: US Zahlenformat: 10, Einheiten DB1: alle Preise in EUR DB2: Währung wird bei Preis mit angegeben Ziel Betrachte die Welt, als ob es nur eine große, homogene Datenquelle gäbe. Diese Datenquelle versteht, XQuery! Transparenz! Einheitliche Schnittstelle ( / XQuery) Benutzer weiß nicht, wo und in welcher Form die Daten liegen Benutzer definiert Anfrage in seiner Sprache und mit seinen Maßeinheiten. Transparenz / Xquery Architekturen Data Warehouse Große integrierte Datenbank, Anfragen ans DW Periodischer Refresch der Datenquellen Datenbankföderation Keine Replikation, Anfragen an Datenquellen Zusätzliche Middleware, ggf. P2P Verarbeitung Mischformen Materialisierung mancher Informationen Onlinezugriff auf andere Informationen (Apriori alles in eine Datenbank / Anwendung packen) 1

2 Data Warehouse Vorteile Data Warehouse Spezielle Aufbereitung der Daten möglich (Voraggregation, Indexierung,...) Data Warehouse ( oder ) Entkopplung von OLAP und OLTP Gute Laufzeiten für Anfragen Nachteile Konsistenz der Daten ETL ist schwierig (Problem nur verschoben!) Zusätzlicher Datenbankentwurf im DW notwendig Hohe Kosten Föderierte Datenbanken Hauptidee: Verwende Wrapper Verstecken Heterogenität, Transformationen Bieten einheitliche Sicht auf Daten Bekommen Teilanfrage - liefern Ergebnis Implementieren Optimierungen (Caching, Push-Down von Anfragen,...) Verteilte Anfragebearbeitung im Mediator Zerlege globale Anfrage in Teilanfragen Bestimme Plan zum Joinen der Teilergebnisse Relationale Technologie ausgereift Produkte: Data Joiner (IBM), Uni,... Story noch unklar! Mediator / Wrapper Architektur XQuery Mediator (Xquery Engine) Vorteile Wieso verwendet man? ist Mutter aller Datenformate Ergebnisse kann man leicht weiterverarbeiten (Z.B. Präsentation im Browser) Xquery ideale Anfragesprache zur Integration Kein globales Schema erforderlich! Prädikate auf Text. Alle machen! Verfügbarkeit von Wrappern! Nachteil Xquery -> Übersetzung sehr schwierig! Es gibt bereits Produkte, die auf relational basieren, wo nötig -, wo möglich (!???) Beispiel Datenquelle 1 (relationale Datenbank) Book(ISBN, Title, Price, Publisher) BookAuthor(ISBN, Name) Datenquelle 2 () <!ELEMENT rezension (comment)> <!ELEMENT comment (#PCDATA)> <!ATTLIST rezension isbn CDATA #REQ> Finde alle Rezensionen von den Büchern von Kossmann, die mehr als USD 50 kosten. 2

3 Beispielanfrage Finde Rezensionen von den Büchern von Kossmann, die mehr als USD 50 kosten. for $r in document( ), $b in document( )[price > 50], $a in document( )[. = Kossmann ] where $r/@isbn = $b/isbn AND $b/isbn = $a/isbn return Normalisierung for $b in document( ) return { for $a in document( ) return { AND $b/price > 50 AND $a = Kossmann ) then Decomposition Decomposition II for $b in document( ) return { for $a in document( ) return { AND $b/price > 50 AND $a = Kossmann ) then Annahme: Wrapper sind dumm! Können nur doc Alles andere macht der Mediator for $b in document( ) where $b/price > 50 return { for $a in document( ) where $a = Kossmann return { Schiebe einfache Prädikate in den Wrapper Decomposition III for $b in wrap( SELECT * FROM book WHERE price > 50 ) return { for $a in wrap ( SELECT * FROM author WHERE name = Kossmann ) return { Wrapper schiebt Prädikate in die Datenquelle Decomposition IV for $b in wrap( } } SELECT b.* FROM book b, author a WHERE b.price > 50 AND a.name = Kossmann AND b.isbn = a.isbn ) return { if ($r/@isbn = $b/isbn Intelligenter Wrapper erkennt lokalen Join Hierzu kostenbasierter Optimierer notwendig 3

4 Decomposition V for $b in wrap( } } SELECT b.* FROM book b, author a WHERE b.price > 50 AND a.name = Kossmann AND b.isbn = a.isbn AND b.isbn = $r ) return { Wrapper unterstützt Parameter Mediator führt sogenannten BindJoin aus Wiederum kostenbasierter Optimierer notwendig (rezension.xml) Anfrageplan Constructor BindJoin ( Verteilte Mediatoren DQ / Wrapper kommunizieren direkt (ohne Mediator) Spart Kommunikationskosten Rezension direkt zur relationalen Datenbank anstatt Umweg durch Mediator Erfordert etwas aufwendigere Optimierung Erfordert Flexibilität in der Installation Verteilter Anfrageplan (rezension.xml) Constructor BindJoin ( Transparenz document Funktion verletzt Transparenz Wie bearbeitet man die folgende Anfrage? for $r in //rezension, $b in //book[price > 50], $a in //author[. = Kossmann ] where $r/@isbn = $b/isbn AND $b/isbn = $a/isbn return Kontext ist das gesamte Internet! Global as View Definiere Sicht in einem globalen Schema //book ~ document(.. ) union document()... Zusätzlicher Anfragetransformationsschritt ersetze globale Wurzel durch Sichtdefinition Vorteil: sehr einfach zu implementieren Nachteil: man muss alle Quellen explizit im globalen Schema registrieren 4

5 Local as View DQ/Wrapper = Menge (parametrisierten) Sichten (Sicht = Anfrage, die Wrapper beantworten kann) Definition einer DQ unabhängig von anderen DQ Beispiel: implementiert //book, //author Aufgabe (das ist schwer!) Beantworte Anfrage mit Hilfe von Sichten (AQUV) Literatur: Alon Halevy, VLDB Journal, 2001 Bonus: Cache = Menge materialisierter Sichten Verwendung des Caches: wiederum AQUV! Data Cleaning Zitate zählen! Gleiche Referenzen erkennen D. A. K., D. Kossmann, Donald Kossmann Was ist mit Kossman? Lösungsansatz Semiautomatische Werkzeuge Besondere Operatoren: z.b. Match Techniken des Maschinellen Lernens, Statistik Literatur: Galhardas et al., VLDB 2001 Wer das Problem löst, wird sehr reich! Fazit Verteilte (Xquery) Anfragebearbeitung Wrapper verstecken Heterogenität ( Unter den Teppich Kehren Prinzip) Mediator bündelt Ergebnisse, kompensiert fehlende Anfragefunktionalität in DQ Herausforderung: Push-Down in Datenquellen schwieriges Optimierungsproblem AQUV ein Baustein Kommerzielle Tools arbeiten relational basierte Tools kommen aber bald auf den Markt Updates: ungelöstes Problem 5