Daten-orientierte Integration - Department of Information Systems

1
7. Daten-orientierte Integration
Schema-Integration:
• Zusammenführung lokaler Schemata zu einem föderierten Schema
zur Überwindung von Heterogenität
• Anforderungen an die Integration:
? Vollständigkeit: alle Elemente der lokalen Schemata werden abgebildet
? Korrektheit: jedes Element des föderierten Schemas hat eine Entsprechung
in (≥) einem lokalen Schema
? Minimalität: kein Realweltkonzept soll im föderierten Schema mehrfach
repräsentiert sein
? Verständlichkeit: durch Beibehaltung der Begriffe der lokalen Schemata
2
7.1 Vorgehen bei der Datenintegration
a) Top-Down:
? Schritte:
1) Vorgabe eines föderierten Schemas
2) Abbildung der lokalen Schemata auf dieses
? Eigenschaft: i.allg. unvollständig (Attribute z.T. nicht abbildbar)
b) Bottom-up:
? die lokalen Schemata werden verknüpft (ggf. sukzessiv, z.B. binär)
3
Top-down- vs. Bottom-up-Integration
globales (föderiertes) Schema
(Referenzschema)
externes Schema
föderiertes Schema
Abbildung
lokales
lokales
Schema
Schema
Datenbank
externes Schema
Exportschema
Exportschema
Komponentenschema
Komponentenschema
lokales Schema
lokales Schema
Datenbank
Datenbank
Datenbank
Integrationsrichtung
4
7.2 Datenmodellierungskonflikte
• Konflikte der Modellierungsparadigmas: OO,relational,XML,. . . (s. Kap. 1)
• Schemakonflikte
? extensionale Konflikte
? strukturelle Konflikte
? Beschreibungskonflikte
• Datenkonflikte (vgl. Kap. 1)
5
Extensionale Schema-Konflikte
• mögliche Beziehungen von Objekt-Mengen A und B zu Klassen KA bzw. KB :
? äquivalente Mengen, A = B: kein Konflikt
? Teilmengenbeziehung, A ⊆ B (oder umgekehrt):
∗ extensionaler Konflikt, z.B. Mitarbeiter, Manager
∗ Lösung: Vererbung KA erbt von KB (oder umgekehrt)
? überlappende Mengen, A ∩ B 6= ∅ und A − B 6= ∅ und B − A 6= ∅:
∗ extensionaler Konflikt, z.B. Mitarbeiter, Kunde
∗ Lösung KA und KB erben von neuer Klasse KA∪B
? disjunkte Mengen: A ∩ B = ∅ (aber gleicher Typ!)
∗ extensionaler Konflikt, z.B. MitarbeiterMS, MitarbeiterDO
∗ Lösung KA und KB erben von neuer Klasse KA∪B
6
Strukturelle Schema-Konflikte
• mancher Realweltaspekt lässt sich unterschiedlich modellieren
• z.B. durch Vererbung oder Delegation
• dies führt zu strukturellen Konflikten
• Lösung: für einen Ansatz enscheiden und den anderen darauf abbilden
7
Beschreibungskonflikte
• unterschiedliche Attribute, z.B. Punkt (x, y) bzw. (ω, r) (→ Abbildung)
• Homonyme und Synonyme (→ Wörterbücher, Ontologien)
• unterschiedliche Datentypen für semantisch gleiche Attribute (→ Abbildung)
• Wertebereichskonflikte
? z.B. Geschlecht dargestellt durch m/w oder 0/1
? z.B. Y2K-Problem: Jahr in Darstellung JJJJ oder JJ (z.B. 1979 oder 79)
? Lösung durch Umrechnungs-Funktion oder -Tabelle
• Skalierungskonflikte (→ Umrechnungsfunktion, z.B. lm = 100 ∗ lcm)
• Genauigkeitskonflikte (→ runden?)
• Konflikte bzgl. der Integritätsbedingungen
• Konflikte der Manipulationsoperationen:
Komponentensysteme erlauben nicht die gleichen Änderungen
8
Beispiel: Beschreibungskonflikte
Homonyme:
Synonyme:
Datentypen:
Skalierung:
Genauigkeit:
Integritätsbedingung:
Prozess (Geschäftsprozess)
Mitarbeiter
int
1,75 m
0,5276 kg
Gehalt < 8000
Prozess (jur. Prozess)
Angestellte
String
175 cm
0,53 kg
Gehalt < 9000
9
Datenkonflikte
• inkorrekte Einträge:
? z.B. durch Tippfehler oder Programmfehler
? Lösung: durch Ähnlichkeitsmaß (problematisch, ggf. interaktiv)
• veraltete Einträge:
? z.B. durch unterschiedliche oder vergessene Aktualisierung
? Lösung: a) aktuellstes System (falls ∃) oder b) lokales System bevorzugen
• unterschiedliche Schreibweisen:
? z.B. Weseler Strasse, Weselerstr., Weseler Straße, . . .
? Lösung: durch Ähnlichkeitsmaß (s.o.),
Hintergrundwissen (z.B. Schreibweise von Namen)
10
7.3 Architektur föderierter Informationssysteme
Globale
Anwendung
Globale
Anwendung
Globale
Anwendung
Föderierungsdienst
Lokale
Anwendung
Metadaten
Datenverwaltung
Datenverwaltung
Daten
Daten
Lokale Datenbank A
Lokale Datenbank B
Föderiertes Datenbanksystem
Lokale
Anwendung
11
Föderierungskernsystem
• übernimmt (z.T.) typische Datenbankaufgaben:
? Transaktionsverwaltung
? Anfragebearbeitung und -optimierung
? Integritätskontrolle
? Recovery
• in der Praxis wird wegen des hohen Aufwands
z.T. nur die benötigte Funktionalität realisiert
12
Schema-Architektur
föderiertes DBMS: 5-Ebenen
externes Schema
externes Schema
konventionelles DBMS: 3-Ebenen
externes Schema 1
föderiertes Schema
externes Schema n
Exportschema
Exportschema
Komponentenschema
Komponentenschema
lokales Schema
lokales Schema
Datenbank
Datenbank
konzeptionelles Schema
internes Schema
13
5-Ebenen-Schema-Architektur eines föderierten DBMS
• lokales Schema: entspricht konzeptionellem Schema eines konventionellen DBMS
• Komponentenschema: Übersetzung eines lok. Schemas in gemeinsame Sprache
• Exportschema: nach außen relevanter Teil eines Konponentenschemas
• föderiertes Schema: entspricht konzeptionellem Schema des Gesamtsystems
• externes Schema: entspricht View auf das föderierte System
• die unteren 3 Ebenen entsprechen dem internen Schema des Gesamtsystems
• die Beschränkung auf den nach außen relevanten Teil eines lokalen Schemas
erfolgt oft vor der Übersetzung in die gemeinsame Sprache
14
7.4 Prinzipien der Schema-Integration
1) Bestimmung der Inter-Schema-Korrespondenzen
? Element-Korrespondenzen:
∗ semantische Beziehungen zwischen Schema-Elementen
∗ z.B. Klassen, Relationen,. . .
? Attribut-Korrespondenzen:
∗ semantische Beziehungen zwischen Attributen der Schema-Elemente
? Pfad-Korrespondenzen:
∗ vergleichen einfache oder zusammengesetzte
Beziehungen der zu integrierenden Schemata
2) Festlegung von Integrationsregeln
15
Beispiel: Korrespondenzen bei der Schema-Integration
Kunde
KName
KAdr
Ware
bestellt
*
*
WarenBez
WPreis
Hersteller
produziert
*
1
HName
HAdr
Branche
Bestellung
BestMenge
Abnehmer
Name
Adresse
Produzent
beliefert
*
Lieferung
Ware
Preis
Menge
PName
*
PAdr
Verband
betreut
*
1 VBranche
Element−Korrespondenzen farbig hervorgehoben
und Attribut−Korrespondenzen farbig
und Pfad−Korrespondenzen farbig
Mengen jeweils gleich!
16
Beispiele für Integrationsregeln
1) jedes Schema-Element, zu dem es im anderen Schema keine Korrespondenz gibt,
wird unverändert übernommen
2) äquivalente Schema-Elemente werden im föderierten Schema
genau einmal repräsentiert
a) zugehörige Attribute ohne Korrespondenz werden übernommen
b) äquivalente Attribute werden zusammengefasst
c) bei Teilmengen-Korrespondenz zwischen Attributen wird das ObermengenAttribut übernommen
d) bei Überlappungs- oder Disjunktheits-Korrespondenz zwischen Attributen wird
ein neues Attribut, das die Vereinigungsmenge repräsentiert, im föderierten
Schema verwendet (ggf. auch Summe, Mittelwert, . . . )
3) korrespondierende Pfade werden im föderierten Schema durch einen semantisch
äquivalenten Pfad abgebildet (→ ggf. Integritätsbedingung)
• weitere Regeln für überlappende und disjunkte Schema-Elemente in Kürze
17
Beispiel: Ergebnis der Schema-Integration
Kunde
KDName
KAdr
Ware
bestellt
*
*
WarenBez
WPreis
Menge
BestMenge
produziert
HName
HAdr.
* Branche
1
*
betreut
Bestellung
Hersteller
Verband
1
in Nachbehandlung ggf. entfernt
VBranche
18
Integrationsregeln für korrespondierende Schema-Elemente
A
B
A=B
sonst
B
A
A
A
B
A
A
B
B
19
Beispiel : Integration korrespondierender Schema-Elemente
Abteilung A
AuftragA
Integriertes Schema
Eilauftrag
Auftrag
Spezialauftrag
AuftragA
AuftragB
Spezialeilauftrag
Abteilung B
Spezialauftrag
Eilauftrag
Kurzauftrag
AuftragIntern
Spezialeilauftrag
AdHocAuftrag
AuftragB
Sonderauftrag
AdHocAuftrag
Kurzauftrag
AuftragIntern
• Ad-hoc-Aufträge sind spezielle Eilaufträge
• Interne Aufträge sind stets Spezialaufträge
Sonderauftrag
20
7.5 Data Cleaning
• hohe Datenqualität ist essentiell für erfolgreiche Datenintegration
• daher verwende Data Clean(s)ing (bekannt aus Data Warehouses)
• Tools: z.B. WizRule
• man unterscheidet:
? Single-Source-Probleme in einzelner Datenquelle
? Multiple-Source-Probleme in mehreren Quellen
21
Data-Cleaning-Prozess
• iterative Wiederholung der folgenden Schritte:
1) Datenanalyse: (i.d.R. von Hand) Probleme erkennen
2) Definition von Transformationen: zur Lösung der Probleme
3) “Verifikation”:
? (ggf. stichprobenartig) prüfen, ob Transformationen funktionieren
4) Transformation
5) Speicherung bzw. Nutzung der bereinigten Daten
22
7.6 Integration von Instanzen
• d.h. Duplikaterkennung
• insbesondere bei mehreren Datenquellen
• abhängig von extensionaler Korrespondenz (Äquivalenz: 1:1, Disjunkheit: 1:0)
• nutze gemeinsame identifizierende Attribute (sofern vorhanden)
• sonst ist i.allg. keine Zuordnung möglich
23
Beispiel: Integration von Instanzen
Personal
Mitarbeiter
PersNr
ThMu201169K17
ThMu170684R42
...
Name
Müller
Müller
...
Vorname
Thomas
Thomas
...
Gehalt
2734
2734
...
Name
Müller
Müller
...
Vorname
Thomas
Thomas
...
GebDat
20.11.1969
17.06.1984
...
• keine gemeinsame identifizierende Attributkombination
• aber: PersNr enthält Geburtsdatum
integrierte Tabelle
PersNr
ThMu201169K17
ThMu170684R42
...
Name
Müller
Müller
...
Vorname
Thomas
Thomas
...
Gehalt
2734
2734
...
GebDat
20.11.1969
17.06.1984
...
Gehalt
2734
2734
...
24
7.7 Transaktionen in föderierten Systemen
• falls nur lesende Zugriffe des föderierten Systems und absolute Konsistenz nicht
erforderlich: Verzicht auf globale Transaktionsverarbeitung
• ansonsten anzustreben: ACID-Eigenschaften
?
?
?
?
Atomicity: Transaktion ganz oder gar nicht ausgeführt
Consistency: Transaktion bewahrt Konsistenz des Datenbestandes
Isolation: Eindruck, allein auf der DB zu arbeiten
Durability: Änderungen erfolgreicher Transaktionen sind persitent
• typische Realisierung: 2-Phasen-Commit-Protokoll
? am Ende der Gesamt-Transaktion werden alle Teil-Transaktionen
nach Bereitschaft zum Commit gefragt
? wenn alle bereit: überall Commit
? ansonsten: überall Rollback
• 2-Phasen-Commit wird von üblichen DBMS unterstützt
25
Probleme bei Transaktionen in föderierten Systemen
• neben globalen Transaktionen gibt es auch lokale
• hierdurch können Deadlocks schwer erkannt werden
Globale Transaktionen T i
Tj
Globaler Transaktionsmanager
Server
T i1
Lokale
Transaktionen
...
Server
T i2
T j1
DBMS
T j2
DBMS
...
Komponenten−
system 1
Komponenten−
system n
Lokale
Transaktionen
26
Beispiel: Deadlock im föderierten System
• Komponentensystem 1 speichert a und b
• Komponentensysten 2 speichert c und d
• Transaktionen:
? global: GT1: r1(a), r1(d),
? lokal: LT3: w3(b), w3(a),
GT2: r2(c), r2(b)
LT4: w4(d), w4(c)
• mögliche Reihenfolge: r1(a), w3(b), r2(c), w4(d) Deadlock
• keiner kann den Deadlock erkennen:
? in System 1: GT2 wartet auf LT3; LT3 wartet auf GT1; GT1 wartet hier nicht
? in System 2: GT1 wartet auf LT4; LT4 wartet auf GT2; GT2 wartet hier nicht
? der globale Transaktionsmanager weiß nichts von den lokalen Transaktionen
• Lösung? ggf. Rollback bei Timeout
27
7.8 Java Database Connectivity (JDBC)
• API für SQL-Statements aus Java-Code heraus
• Ergebnisse von Anfragen werden elementweise verarbeitet
• in Klasse java.sql.Statement: ResultSet executeQuery(String sql)
• auch Updates möglich (INSERT, UPDATE, DELETE)
• in Klasse java.sql.Statement: int executeUpdate(String sql)
• Java-Compiler kann SQL-Statements (Strings!) nicht überprüfen
(→ ggf. Laufzeitfehler)
28
Beispiel: JDBC
import java.net.URL; import java.sql.*;
class JDBCbsp{
public static void main(String argv []){
try { // erstelle URL einer ODBC-Datenquelle
String url = "jdbc:odbc:meineQuelle";
// verbinde mit Datenquelle
Connection con = DriverManager.getConnection(url,"username","passwd");
// erstelle SELECT-Statement und führe es aus
Statement stmt = con.createStatement();
ResultSet rs = stmt.executeQuery("SELECT pnr, name FROM Personal");
while (rs.next()){ // bearbeite Ergebnis-Kollektion elementweise
// extrahiere und verarbeite Attributwerte des aktuellen Tupels
int pnr = rs.getInt(1);
String name = rs.getString(2);
System.out.print("Personalnr: "+pnr);
System.out.println(", Name: " + name);}
stmt.close(); con.close();}
catch (java.lang.Exception e){e.printStackTrace();}
}
}
29
7.9 Multidatenbanksprachen
• Status: in Entwicklung
• Motivation:
? SQL erlaubt keine direkte Verknüpfung mehrerer Datenbanken
? Notlösung: Verknüpfung durch Programmlogik
? Abhilfe: Multidatenbanksprache, z.B. SchemaSQL, SQL/MED
• Eigenschaften von Multidatenbanksprachen
? lokale Schemata sind sichtbar
? jeder Benutzer definiert eigenes föderiertes Schema und externe Schemata
• Produkt: (z.B.) IBM DB2 Information Integrator
30
7.9.1 SchemaSQL
• Behandlung von Daten und Metadaten
• Restrukturierung der Schemata möglich
• Aggregation über mehrere Attribute und Relationen
• umfasst SQL
• neuer Operator →: geht von DB zu Relation bzw. von Relation zu Attribut über
31
Beispiel: SchemaSQL
Datenbank Filiale MS:
Gehalt
Position
Leiter
Sekretärin
Leiter
Sekretärin
Abteilung
Personal
Personal
Vertrieb
Vertrieb
Gehalt
61000
32000
79000
34000
Datenbank Filiale HB:
Gehalt
Position
Leiter
Sekretärin
Personal
66000
31500
Vertrieb
74000
31500
Datenbank Filiale DO:
Personal
Position
Leiter
Sekretärin
Gehalt
63000
33000
Vertrieb
Position
Leiter
Sekretärin
Gehalt
81000
35000
Datenbank Filiale BO:
Gehalt
Abteilung
Personal
Vertrieb
Leiter
68000
69000
Sekretärin
36000
31000
create view globalSchema::Gehalt(Filiale, Position, Abteilung, GdGehalt) as
select "MS", T.Position, T.Abteilung, T.Gehalt
from MS::Gehalt T
union select "DO", T.Position, R, T.Gehalt
from DO→R, DO::R T
union select "HB", T.Position, A, T.A
from HB::Gehalt T, HB::Gehalt→A
where A <> "Position"
union select "BO", A, T.Abteilung , T.A
from BO::Gehalt T, BO::Gehalt→A where A <> "Abteilung"
32
7.9.2 SQL/MED
• Zugriff auf extern verwaltete Daten (Management of External Data)
• DBMS verwaltete externe Daten; inkl. Transaktionen, Recovery, . . .
• hierzu verwendete Konzepte:
? Datalinks
? Foreign Data Wrapper / Foreign Data Server
33
Datalinks
• neuer SQL/MED-Datentyp DATALINK referenziert Datei (durch URL)
Anwendung
SQL
Dateiverwaltung
Daten mit URLs
SQL−Server mit
Datalink−Erweiterung
relationale
DB
Kontrollpfad für
referenzierte Dateien
Datalink−
Manager
Datei
hierarchisches
Dateisystem
34
Datalink-Kontrolloptionen
• Link-Kontrolle (j/n): wenn eingeschaltet, greifen die folgenden Optionen
• Integritätskontrolle:
? ALL: referenzierte Daten können nur über SQL manipuliert werden
? SELECTIVE: Manipulation über Dateisystem möglich, solange nicht verlinkt
? NONE: Manipulation nur über Dateisystem
• Leserechte: vom Dateisystem (FS) oder DBMS (DB) vergeben
• Schreibrechte: vom Dateisystem (FS) vergeben oder
ausgeschlossen (BLOCKED, → kein update-in-place)
• Recovery (j/n)
• Unlink: bei Auflösung eines Links wird:
? RESTORE: Zugriffsrecht wieder auf Zustand vor dem Link gesetzt
? DELETE: Datei gelöscht
? NONE: Zugriffsrecht nicht geändert
35
Arbeiten mit Datalinks
• SQL-Server liefert ggf. URL als Teil eines Ergebnisses
• Anwendung greift über Dateiverwaltung auf die zugehörige Datei zu
• die Dateiverwaltung übergibt die Kontrolle an den Datalink-Manager (DLM)
• die Zugriffsrechte werden so geändert, dass nur der DLM Zugriff hat
• Konstruktor DLVALUE erzeugt einen Datalink
• DLURLCOMPLETE liefert die URL einer Datei
36
Beispiel: Arbeiten mit Datalinks
• Einfügen:
INSERT INTO Filme (Titel,Dauer,Film)
VALUES ("EAI leicht gemacht", 90, DLVALUE("http://wwu.de/filme/eai.mp4"))
• Suchen:
SELECT Titel, DLURLCOMPLETE(Film)
FROM Film
WHERE Titel LIKE "%EAI%"
• Unlink / Ersetzen:
UPDATE Filme
SET Film = DLVALUE("http://meinserver.de/filme/eai2.mp4")
WHERE Titel = "EAI leicht gemacht"
37
Foreign Data Wrapper und Foreign Data Server
• realisieren Kommunikation mit externer Datenquelle (DB-Tabelle)
• Verwaltungsinformationen in Data Dictionary des SQL-Servers:
?
?
?
?
SQL-Schemata
Foreign-Server-Deskriptoren
Foreign-Table-Deskriptoren
Foreign-Wrapper-Deskriptoren
• SQL-Erweiterungen für Anlegen dieser Informationen
• externe Tabellen können mit SQL wie lokale verwendet werden
• Interaktionsmodi: Dekomposition oder Pass-Through
SQL−
SQL/MED
Server
API
Foreign
Data
Wrapper
Foreign
Data
Server
Foreign
Data