Ausgangspunkt Architekturen Ziel Konflikte Transparenz Datenintegration 1

(1)

Datenintegration

Web Informationssysteme Wintersemester 2002/2003

Donald Kossmann

Ausgangspunkt

• Daten liegen in verschiedenen Datenquellen (Extremfall: jede URL eigene Datenquelle)

– 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, ...

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

Ziel

• 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.

Transparenz

SQL LDAP

SQL EXCEL

SQL XML

XML / 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)

(2)

Data Warehouse

SQL LDAP

SQL

EXCEL XML

Data Warehouse (SQL oder XML)

Data Warehouse

• Vorteile

– Spezielle Aufbereitung der Daten möglich (Voraggregation, Indexierung, ...) – 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), UniSQL, ...

– XML Story noch unklar!

wrapper

wrapper wrapper wrapper

Mediator / Wrapper Architektur

SQL LDAP

SQL

EXCEL XML

Mediator (Xquery Engine)

XQuery XML

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 (!???)

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.

(3)

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 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

Decomposition IV

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

} }

• „Intelligenter“ Wrapper erkennt lokalen Join

• Hierzu kostenbasierter Optimierer notwendig

(4)

Decomposition V

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>

} }

• Wrapper unterstützt Parameter

• Mediator führt sogenannten BindJoin aus

• Wiederum kostenbasierter Optimierer notwendig

Anfrageplan

wrapper (rezension.xml)

wrapper (www.book.rdb) BindJoin

Constructor

(Rezension) (Rezension, Book)

(Rezension, Book)

(Rezension)

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

wrapper (rezension.xml)

wrapper (www.book.rdb) BindJoin

Constructor

(Rezension) (Rezension, Book)

(Rezension, Book)

(Rezension)

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

(5)