Datenintegration Ausgangspunkt Konflikte Ziel Transparenz

Ausgangspunkt
• Daten liegen in verschiedenen Datenquellen
(Extremfall: jede URL eigene Datenquelle)
Datenintegration
Web Informationssysteme
Wintersemester 2002/2003
Donald Kossmann
– Mietautos bei www.hertz.com
– Hotel bei www.holiday-inn.com
– Flüge bei www.lufthansa.com
• Datenquellen sind heterogen
–
–
–
–
–
Relationale Datenbanken
Web Anwendungssystem (Web Dienst)
LDAP Server
XML Datenbank
Filesystem, EXCEL, ...
Ziel
Konflikte
• Struktur
– DB1: book(isbn, author), pub(isbn, title)
– DB2: book(isbn, author, title), pub(isbn, title)
• Typen, Formate, Namen
– DB1: deutsches Zahlenformat: 10.000,00
– DB2: US Zahlenformat: 10,000.00
• Einheiten
– DB1: alle Preise in EUR
– DB2: Währung wird bei Preis mit angegeben
• Betrachte die Welt, als ob es nur eine große,
homogene Datenquelle gäbe.
• Diese Datenquelle versteht XML, XQuery!
• Transparenz!
– Einheitliche Schnittstelle (XML / XQuery)
– Benutzer weiß nicht, wo und in welcher Form
die Daten liegen
– Benutzer definiert Anfrage in seiner Sprache
und mit seinen Maßeinheiten.
Architekturen
Transparenz
• Data Warehouse
– Große integrierte Datenbank, Anfragen ans DW
– Periodischer Refresch der Datenquellen
XML / Xquery
• Datenbankföderation
SQL
XML
– Keine Replikation, Anfragen an Datenquellen
– Zusätzliche Middleware, ggf. P2P Verarbeitung
EXCEL
LDAP
SQL
SQL
• Mischformen
– Materialisierung mancher Informationen
– Onlinezugriff auf andere Informationen
• (Apriori alles in eine Datenbank / Anwendung packen)
1
Data Warehouse
Data Warehouse
• Vorteile
– Spezielle Aufbereitung der Daten möglich
(Voraggregation, Indexierung, ...)
– Entkopplung von OLAP und OLTP
– Gute Laufzeiten für Anfragen
Data Warehouse
(SQL oder XML)
• Nachteile
EXCEL
XML
SQL
SQL
LDAP
–
–
–
–
Konsistenz der Daten
ETL ist schwierig (Problem nur verschoben!)
Zusätzlicher Datenbankentwurf im DW notwendig
Hohe Kosten
Föderierte Datenbanken
• Hauptidee: Verwende „Wrapper“
Mediator / Wrapper Architektur
– Verstecken Heterogenität, Transformationen
Bieten einheitliche Sicht auf Daten
– Bekommen Teilanfrage - liefern Ergebnis
– Implementieren Optimierungen
(Caching, Push-Down von Anfragen, ...)
XQuery
XML
Mediator
(Xquery Engine)
• Verteilte Anfragebearbeitung im „Mediator“
– Zerlege „globale Anfrage“ in Teilanfragen
– Bestimme „Plan“ zum Joinen der Teilergebnisse
• Relationale Technologie ausgereift
– Produkte: Data Joiner (IBM), UniSQL, ...
– XML Story noch unklar!
Wieso verwendet man XML?
• Vorteile
– XML 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 XML! Verfügbarkeit von Wrappern!
• Nachteil
– Xquery -> SQL Übersetzung sehr schwierig!
– Es gibt bereits Produkte, die auf relational basieren
• XML, wo nötig - SQL, wo möglich (!???)
wrapper
wrapper
SQL
XML
wrapper
EXCEL
SQL
wrapper
LDAP
Beispiel
• Datenquelle 1 (relationale Datenbank)
– Book(ISBN, Title, Price, Publisher)
– BookAuthor(ISBN, Name)
• Datenquelle 2 (XML)
– <!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
Beispielanfrage
• Finde Rezensionen von den Büchern von
Kossmann, die mehr als USD 50 kosten.
for $r in document(„www.rezension.xml“),
$b in document(„www.book.rdb/book“)[price > 50],
$a in document(„www.book.rdb/author“)[. = „Kossmann“]
where $r/@isbn = $b/isbn AND $b/isbn = $a/isbn
return
<rezension> { $b/title } { $r/comment } </rezension>
Normalisierung
for $r in document(„www.rezension.xml“) return {
for $b in document(„www.book.rdb/book“) return {
for $a in document(„www.book.rdb/author“) return {
if ($r/@isbn = $b/isbn AND $b/isbn = $a/isbn
AND $b/price > 50 AND $a = „Kossmann“) then
<rezension> { $b/title } { $r/comment } </rezension>
}}}
Decomposition
for $r in document(„www.rezension.xml“) return {
for $b in document(„www.book.rdb/book“) return {
for $a in document(„www.book.rdb/author“) return {
if ($r/@isbn = $b/isbn AND $b/isbn = $a/isbn
AND $b/price > 50 AND $a = „Kossmann“) then
<rezension> { $b/title } { $r/comment } </rezension>
}}}
• Annahme: Wrapper sind dumm! Können nur „doc“
• Alles andere macht der Mediator
Decomposition II
for $r in document(„www.rezension.xml“) return {
for $b in document(„www.book.rdb/book“)
where $b/price > 50 return {
for $a in document(„www.book.rdb/author“)
where $a = „Kossmann“ return {
if ($r/@isbn = $b/isbn AND $b/isbn = $a/isbn
<rezension> { $b/title } { $r/comment } </rezension>
}}}
• Schiebe einfache Prädikate in den Wrapper
Decomposition IV
Decomposition III
for $r in document(„www.rezension.xml“) return {
for $b in wrap(„SELECT * FROM book WHERE price > 50“)
return {
for $a in wrap („SELECT * FROM author
WHERE name = ‚Kossmann‘“) return {
if ($r/@isbn = $b/isbn AND $b/isbn = $a/isbn
<rezension> { $b/title } { $r/comment } </rezension>
}}}
• Wrapper schiebt Prädikate in die Datenquelle
for $r in document(„www.rezension.xml“) return {
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
<rezension> { $b/title } { $r/comment } </rezension>
}}
• „Intelligenter“ Wrapper erkennt lokalen Join
• Hierzu kostenbasierter Optimierer notwendig
3
Decomposition V
Anfrageplan
for $r in document(„www.rezension.xml“) return {
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 {
<rezension> { $b/title } { $r/comment } </rezension>
}}
Constructor
(Rezension, Book)
BindJoin
(Rezension)
• Wrapper unterstützt Parameter
• Mediator führt sogenannten BindJoin aus
• Wiederum kostenbasierter Optimierer notwendig
Verteilte Mediatoren
(Rezension)
wrapper
(rezension.xml)
• Erfordert etwas aufwendigere Optimierung
• Erfordert Flexibilität in der Installation
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
<rezension> { $b/title } { $r/comment } </rezension>
• Kontext ist das gesamte Internet!
wrapper
(www.book.rdb)
Verteilter Anfrageplan
• DQ / Wrapper kommunizieren direkt
(ohne Mediator)
• Spart Kommunikationskosten
– Rezension direkt zur relationalen Datenbank
– anstatt Umweg durch Mediator
(Rezension, Book)
Constructor
(Rezension, Book)
BindJoin
(Rezension)
(Rezension)
wrapper
(rezension.xml)
(Rezension, Book)
wrapper
(www.book.rdb)
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
Local as View
• DQ/Wrapper = Menge (parametrisierten) Sichten
(Sicht = Anfrage, die Wrapper beantworten kann)
• Definition einer DQ unabhängig von anderen DQ
• Beispiel: www.book.rdb 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
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!
– Verwendung des Caches: wiederum AQUV!
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“
– XML basierte Tools kommen aber bald auf den Markt
• Updates: ungelöstes Problem
5