Informationsintegration Anwendungsszenarien

InformationsintegrationAnwendungsszenarien

20.10.2004

Felix Naumann

20.10.2004 Felix Naumann, VL Informationsintegration, WS 05/06 2

Überblick

Beispiele der Informationsintegration Data Warehouse Föderierte Datenbanken

Potential und Probleme der Informations-integration Redundanz Komplementierung


Real-life Informationsintegration

Überblick: Zwei wesentliche Modelle Data Warehouses

Materialisierte Integration Am Beispiel Buchhändler (Folien von Prof. Leser)

Föderierte Datenbanken Virtuelle Integration Am Beispiel einer Life Sciences DB (DiscoveryLink) Weitere Beispiele


Data Warehouse

Eine oder mehrere (ähnliche) Datenbanken mit Bücherverkaufsinformationen

Daten werden oft aktualisiert Jede Bestellung einzeln Katalog Updates täglich

Management benötigt Entscheidungshilfen (decision support)

Komplexe Anfragen

Quelle: Ulf Leser, VL Data Warehouses


Bücher im Internet bestellen

BackupDurchsa

tzLoad-

balancing

Portfolio

UmsatzWerbun

g

Datenbank


Zielkonflikt


Die Datenbank dazu

OrderOrder_idBook_idamountsingle_price

OrdersIdDay_idCustomer_idTotal_amt

DayIddaymonth_id

MonthIdMonthyear_id

Yearidyear

Customeridname

BookidBook_group_id

Bookgroupidname



Fragen eines Marketingleiters

OrderOrder_idbook_idamountsingle_price


DayIddaymonth_id

MonthIdMonthyear_id

Yearidyear

Customeridname

BookidBook_group_id

Bookgroupidname

Wie viele Bestellungen haben wir jeweils im Monat vor Weihnachten, aufgeschlüsselt nach Produktgruppen?



Technisch

OrderOrder_idBook_idamountsingle_price


DayIddaymonth_id

MonthIdMonthyear_id

Yearidyear

Customeridname

BookidBook_group_id

Bookgroupidname


SELECT Y.year, PG.name, count(B.id)FROM year Y, month M, day D, order O, orders OS, book B, bookgroup BGWHERE M.year = Y.id and

M.id = D.month andO.day_id = D.id andOS.order_id = O.id andB.id = O.book_id andB.book_group_id = BG.id andday < 24 and month = 12

GROUP BY Y.year, PG.product_nameORDER BY Y.year


Technisch

SELECT Y.year, PG.name, count(B.id)FROM year Y, month M, day D, order O, orders OS,

book B, bookgroup BGWHERE M.year = Y.id and

M.id = D.month andO.day_id = D.id andOS.order_id = O.id andB.id = O.book_id andB.book_group_id = BG.id andday < 24 and month = 12

GROUP BY Y.year, PG.product_nameORDER BY Y.year

6 Joins• Year: 10 Records• Month: 120 Records• Day: 3650 Records• Orders: 36.000.000 • Order: 72.000.000• Books: 200.000• Bookgroups:100

Problem!• Schwierig zu optimieren (Join-Reihenfolge) • Je nach Ausführungsplan riesige Zwischenergebnisse• Ähnliche Anfragen – ähnlich riesige Zwischenergebnisse



In Wahrheit ... noch schlimmer

Es gibt noch: Amazon.de Amazon.fr Amazon.it ...

Verteilte Ausführung Count über Union mehrerer gleicher Anfragen in

unterschiedlichen Datenbanken


HILFE!


In Wahrheit ...



Technisch: Eine VIEWCREATE VIEW christmas AS

SELECT Y.year, PG.name, count(B.id)FROM DE.year Y, DE.month M, DE.day D, DE.order O, ... WHERE M.year = Y.id and...GROUP BY Y.year, PG.product_nameORDER BY Y.year

UNION

SELECT Y.year, PG.name, count(B.id)FROM EN.year Y, EN.month M, EN.day D, DE.order O, ...WHERE M.year = Y.id and... SELECT year, name, count(B.id)

FROM christmasGROUP BY year, nameORDER BY year



Probleme

Count über Union über verteilte Datenbanken? Integrationsproblem

Berechnung riesiger Zwischenergebnisse bei jeder Anfrage? Datenmengenproblem



Lösung des Integrationsproblems?

Zentrale Datenbank

• Aber Probleme:– Zweigstellen schreiben übers Netz– Schlechter Durchsatz– Lange Antwortzeiten im operativen Betrieb



Lösung Datenmengenproblem?

Denormalisierte Schema

• Aber Probleme:– Jeder lesende / schreibende Zugriff erfolgt auf eine

Tabelle mit 72 Mill. Records– Lange Antwortzeiten im operativen Betrieb



Zielkonflikt


Tatsächliche Lösung

• Redundante, transformierte Datenhaltung• Asynchrone Aktualisierung

Aufbau eines Data Warehouse



Weitere Anwendungsgebiete: Data Warehouses „Customer Relationship Management“ (CRM)

Identifikation von Premiumkunden Personalisierung / Automatische Kundenberatung Gezielte Massen-Mailings (Direktvertrieb)

Controlling / Rechnungswesen Kostenstellen Organisationseinheiten Personalmanagement

Logistik Flottenmanagement, Tracking

Gesundheitswesen Studienüberwachung, Patiententracking



Überblick


Probleme und Potential der Informationsintegration Redundanz Komplementierung


Föderierte Datenbanken Mehrere autonome Informationsquellen Mit unterschiedlichsten Inhalten

Gene, Proteine, BLAST, etc. Und unterschiedlichsten Schnittstellen

HTML-Form, flat file, SQL, etc. Wissenschaftler (Biologe) benötigt z.B. möglichst viele

Informationen über ein bestimmtes Protein Funktion, Veröffentlichungen, verwandte Proteine usw.

Sehr komplexe Anfragen Üblicher Ansatz: Browsing, Note-Taking, Copy & Paste Föderierte Datenbanken (wie DiscoveryLink) helfen.


Frage eines Biologen

Finde alle menschlichen EST Sequenzen, die nach BLAST zu mindestens 60% über mindestens 50 Aminosäuren identisch sind mit mouse-channel Genen im Gewebe des zentralen Nervensystems.

Quelle für das komplette Beispiel: A Practitioner’s Guide to Data Management and Data Integration in Bioinformatics, Barbara A. Eckman in

Bioinformatics by Zoe Lacroix and Terence Critchlow, 2003, Morgan Kaufmann.


Verschiedene Informationsquellen

Beteiligte Informationsquellen Mouse Genome Database (MGD) @ Jackson Labs SwissProt @ EBI BLAST tool @ NCBI GenBank nucleotide sequence database @ NCBI

Alle Quellen sind frei verfügbar


Herkömmlicher Ansatz: Browsing

1. Suche „channel“ Sequenzen im Gewebe des ZNS durch MGD HTML Formular



MGD Resultat 14 Gene aus 17

Experimenten



Details zu jedem der 14 Gene ansehen

Durchschnittlich fünf SwissProt Links pro Gen



Betrachten jedes SwissProt Eintrages

Durch Klick BLAST Algorithmus anwerfen



Betrachten jedes BLAST Resultats um nicht-menschliche

Treffer zu eliminieren, andere Bedingungen zu

prüfen (>60% Identität, etc.)



Für jeden verbleibenden Eintrag Komplette EST

Sequenz bei GenBank holen


Idee der Integration

Bildung eines globalen Schemas (Schemaintegration) Gespeichert als Datenbankschema in

DiscoveryLink Generierung von Wrappern für jede

Datenquelle Softwarekomponente Mapping von lokalen Schemata auf globales

Schema Kennt Anfragefähigkeiten der Quellen


DiscoveryLink Architektur


Eigenschaften föderierter IS (und DiscoveryLink)

Daten bleiben vor Ort. Informationsquellen sind autonom (und wissen oft

nicht von ihrer Integration). Anfragen werden deklarativ an das globale Schema

gestellt. Anfrage wird so verteilt wie möglich ausgeführt.

Je nach Mächtigkeit der Quellen DiscoveryLink gleicht etwaige mangelnder Fähigkeiten aus.


Föderierter DBMS Ansatz

„Einfache“ SQL-Anfrage um alle vorigen Schritte zu vereinen:SELECT g.accnum,g.sequenceFROM genbank g, blast b, swissprot s, mgd mWHERE m.exp = “CNS” AND m.defn LIKE “%channel%”AND m.spid = s.id AND s.seq = b.query AND b.hit = g.accnum AND b.percentid > 60 AND b.alignlen > 50

„Finde alle menschlichen EST Sequenzen, die nach BLAST zu mindestens 60% über mindestens 50 Aminosäuren identisch sind mit mouse-channel Genen im Gewebe des zentralen Nervensystems.“


Föderierter DBMS Ansatz

Effiziente Ausführung durch Optimierer Herkömmliche Optimierung Wrapper helfen mit

Kostenmodell domänenspezifischen Funktionen

Sichere Ausführung Wiederholbar Transaktional


Weitere Anwendungsgebiete: Föderierte Datenbanken Meta-Suchmaschinen Unternehmensfusionen

Kundendatenbanken Personaldatenbanken

Grid Krankenhausinformationssysteme

Röntgenbilder Krankheitsverlauf (Akte) Verwaltung Krankenkasse...

Verteiltes Arbeiten („groupware“) Peer Data Management und P2P


Überblick


Probleme und Potential der Informationsintegration Redundanz Komplementierung


Integrationspotential

Wann ist Informationsintegration möglich? Intensionale Redundanz

Wann ist Informationsintegration schwierig? Extensionale Redundanz

Wann ist Informationsintegration nützlich? Extensionale Komplementierung Intensionale Komplementierung


Intension & Extension

Definition: Intension Die Intension eines Informationssystems ist die

Menge der Schemainformationen und deren Semantik (Bedeutung).

Definition: Extension Die Extension eines Informationssystems ist die

Menge aller zur Intension gehörigen, zugreifbaren Daten.


Intension & Extension

Die Intension einer Datenbank Schema für eine Menge

von Entitäten/Dingen Semantik

Die Extension einer Datenbank Zustand Menge von Entitäten

ISBN Titel Autor

3442727316 Moby Dick

Herman Melville

3491960827 Robinson Crusoe

Daniel Defoe

3462032283 Zwölf Nick McDonell

3883891606 Timbuktu Paul Auster

Buch


Redundanz und Komplementierung

Redundanz hilft zur Verifikation Nur bei gewisser Redundanz kann

Komplementierung genutzt werden Komplementierung ist gut

Hier liegt der eigentliche „Sinn“ der Informationsintegration.

Informationen mehrerer (sich komplementierender) Quellen werden zu einem größeren Ganzen integriert.


Intensionale Redundanz

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

Intensionale Redundanz liegt vor, wenn das Entfernen von Teilender Intension die Gesamtintension nicht verändert.



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

Intensionale Redundanz trotz unterschiedlicher Label?

Ja, denn Semantik zählt!



ISBN Autor

3491960827 Daniel Defoe

3442727316 H Melville

3462032283 Nick MacDonell

3883891606 Paul Auster

ISBN Autor

3442727316 Herman Melville


3462032283 Nick McDonell


Quelle 2Quelle 1

Intensionale Redundanz auch über mehrere Relationen und Quellen.


Potential Intensionaler Redundanz

Verifikation

ISBN Autor


3442727316 H Melville



ISBN Autor





Quelle 2Quelle 1



Integration

ISBN Titel



3462032283 Zwölf

3883891606 Timbuktu

ISBN Autor





Quelle 2Quelle 1



Integration

Titel

Moby Dick

Robinson Crusoe

Zwölf

Timbuktu

ISBN Autor





Quelle 1 + 2


Intensionale Komplementierung

ISBN Titel



3462032283 Zwölf

3883891606 Timbuktu

ISBN Autor





Quelle 2Quelle 1

Intensionale Komplementierung liegt vor, wenn von zwei Intensionen- mindestens eine Differenz ist nicht leer ist,- und deren Schnittmenge nicht leer ist.


Potential Intensionaler Komplementierung

ISBN Titel

3462032283 Zwölf

3499139278 Leviathan


ISBN Autor





Quelle 2Quelle 1

???

???

Verdichtung: Mehr Informationen über einzelne Objekte


Potential Intensionaler Komplementierung

Autor Titel

MacDonell Zwölf

Auster Leviathan

H Melville Moby Dick

ISBN Autor





Quelle 2Quelle 1

???

???

Verdichtung nicht immer leicht.


Extensionale Redundanz

Extensionale Redundanz liegt vor, wenn die Menge der von zweiQuellen gemeinsam repräsentierten Objekte nicht leer ist.

ISBN Autor



Quelle 2Quelle 1

ID Author





ID Author



ISBN Autor



Quelle 2Quelle 1

Extensionale Redundanz nur über Teile der Quellen.


Probleme Extensionaler Redundanz

Extensionale Redundanz ist nur auf „real-world“ Objekten definiert,nicht auf den Daten über sie.

ID Author

3491960827 Daniel Düsentrieb


ISBN Autor



Quelle 2Quelle 1


Daten-Konflikt


Extensionale Komplementierung

Extensionale Komplementierung liegt vor, wenn die Differenz der repräsentierten Objekte zweier Quellen nicht leer ist.

ISBN Autor



ISBN Autor



Quelle 2Quelle 1


Potential Extensionaler Komplementierung

Höhere Überdeckung



ISBN Autor



Quelle 1 + Quelle 2


Extensionaler Komplementierung mit Extensionaler Redundanz

ISBN Autor



Quelle 2Quelle 1

ID Author




Probleme Extensionaler Komplementierung und Redundanz



ISBN Autor



Quelle 1 + Quelle 2

Datenkonflikt


Der Allgemeine Fall

Quelle 1 A(V) B(W) C(X) D(Y) a1 b1 c1 d1

a2 b2 - d2

Quelle 2 A(V) D(W) E(X) F(Z) a2 d2 c2 - a3 d3 e3 f3

Extensionale Komplementierung

Intensionale Komplementierung



Quelle 1 & 2 A(V) B/D(W) C/E(X) D(Y)F(Z) a1 b1 c1 d1 - a2 f(b2,d2) c2 d2 - a3 d3 e3 - f3


Zusammenfassung Redundanz

Intensionale Redundanz ermöglicht extensionale Komplementierung Zwei Quellen mit gleichem Schema können zu einer

überdeckenderen Quelle integriert werden Coverage

Extensionale Redundanz ermöglicht intensionale Komplementierung Zwei Quellen, die über gleiche Dinge sprechen können zu

einer dichteren Quelle integriert werden. Density

Insgesamt ist das Ziel der Integration eine vollständigere Quelle (completeness)


Zusammenfassung: Data Warehouse

Aufbau eines Data Warehouse



Zusammenfassung: Föderierte DBMS/IS

Documents

Informationsintegration Anwendungsszenarien