anfragebearbeitung lav und pdms - vsis homepage · pdf fileagenda 1 anfragebearbeitung...

Anfragebearbeitung LaV und PDMS

Dr. Armin Roth

arminroth.de

25.06.2012

Dr. Armin Roth (arminroth.de) II – Anfragebearbeitung LaV, PDMS 25.06.2012 1 / 26

Agenda

1 Anfragebearbeitung Local-as-ViewNutzung von LaV MappingsBucket Algorithm

2 Anfragebearbeitung PDMS


Anfragebearbeitung Local-as-View Nutzung von LaV Mappings

Spezialisierungen LaV und GaV

s-t TGDs auch GLaV Mappings(global-and-local-as-view)

GaV (global-as-view)L1(x , y), L2(y , z)→ G (x , y , z)L1(x , y), L2(y , z) ⊆ G (x , y , z)(realisiert Joins)

LaV (local-as-view)L(x , y , z)→ G1(x , y),G2(y , z)L(x , y , z) ⊆ G1(x , y),G2(y , z)(realisiert Dekomposition)

Instanz nInstanz 2Instanz 1

IIS Globales Schema

...

G G1 G2

L1 L2 L

GaV LaV



Vergleich GaV / LaV: Modellierung

GaV LaV

Jede globale Relationdefiniert als Sicht auf eineoder mehrere Relationenaus einer oder mehrerenQuellen.

Meist UNION ubermehrere Quellen

Nebenbedingungen auflokalen Quellen konnennicht modelliert werden.

Globale Relationen werdendurch mehrere Sichtendefiniert.

Definition oft nur inKombination mit anderenglobalen Relationen

Nebenbedingungen aufglobale Relationen konnennicht definiert werden.



Anfragebearbeitung – LaV

Gegeben:

Anfrage gegen globales SchemaLaV Mapping: fur jede lokale Relation genau eine Sicht aufglobales Schema

Gesucht:

Alle Tupel, die die Anfragebedingungen erfullenAber: Daten sind in lokalen Quellen gespeichert!

Anfrageumschreibung durch Einbeziehung der Sichten

Kombiniere geschickt die einzelnen Sichten zu einer Anfrage, sodass deren Ergebnis einen Teil der Anfrage beantworten.

Gesamtergebnis: UNION der Ergebnisse mehrererAnfrageumschreibungen



LaV – Anfragebearbeitung

Ausschnitt Globales Schema Lehrt(prof,kurs_id, sem, eval, univ) Kurs(kurs_id, titel, univ)Quelle 1: Alle Datenbankveranstalt. CREATE VIEW DB-kurs AS SELECT K.titel, L.prof, K.kurs_id, K.univ FROM Lehrt L, Kurs K WHERE L.kurs_id = K.kurs_id AND L.univ = K.univ AND K.titel LIKE „%_Datenbanken“

Quelle 2: Alle Humboldtvorlesungen CREATE VIEW Hum-VL AS SELECT K.titel, L.prof, K.kurs_id, K.univ FROM Lehrt L, Kurs K WHERE L.kurs_id = K.kurs_id AND K.univ = „Humboldt“ AND L.univ = „Humboldt“ AND K.titel LIKE „%VL_%“

Globale Anfrage SELECT titel, kurs_id FROM Kurs K WHERE L.univ = „Humboldt“

Umgeschriebene Anfrage SELECT titel, kurs_id FROM DB-kurs D WHERE D.univ = „Humboldt“ UNION SELECT titel, kurs_id FROM Hum-VL

Frage: Warum hier doch Quelle 2 einbeziehen?



LaV – Anfragebearbeitung

Gegeben: Anfrage Q und Sichten V1,V2, . . . ,Vn

(uber dasselbe Schema!)

Gesucht: Umgeschriebene Anfrage Q ′, die

bei Optimierung mit materialized views aquivalent ist: Q = Q ′

bei Integration: maximal enthalten ist:Q ⊇ Q ′ und es existiert kein Q ′′ mit Q ⊇ Q ′′ ⊇ Q ′, wobeiQ ′′ 6= Q ′

Problem: Wie definiert und testet man Aquivalenz bzw. maximalcontainment von Anfrageergebnissen fur alle moglichenDatenbankinstanzen D, also Q ′(D) ⊆ Q(D)?

Losung: Query Containment Check [CM77](Pradikate abbildbar, Ergebnisvariablen abbildbar,Selektionspradikate kompatibel)



Anfrageumschreibung

Prinzipiell:

Umgeschriebene Anfrage:Konjunktive Anfrage (Kombination) aus SichtenPrufe jede Kombination aus Sichten auf Query ContainmentUnendlich viele Kombinationen, da eine Sicht auch mehrfach ineine Umschreibung eingehen kann.

Verbesserung:

Satz: Umschreibung mit maximal so vielen Sichten wieRelationen in Anfrage (ohne range-Pradikate) [LRO96].Geschickte Vorauswahl der Sichten: Nutzbarkeit



LaV – Nutzen der Sichten

Wann sind Sichten nutzbar?

Mindestens eine Relationen mit Anfrage gemeinsamSicht liefert mindestens Ergebnisvariablen der AnfragePradikate sind schwacher oder gleich (aquivalenteUmschreibung)Pradikate sind starker (contained Umschreibung)

Wann sind Sichten nutzlich?

Bei Optimierung mit materialzed views: Schnellere AusfuhrungBei Integration mit LaV: Zusatzliche Tupel, zusatzlicheAttribute



Beispielschema

Globales Schema Prof(name, bereich) Kurs(kurs_id, titel, univ) Lehrt(prof,kurs_id, sem, eval, univ) Eingeschrieben(stud, kurs_id, sem) Vertiefung(stud, fach) Arbeitet(prof, fach) Betreut(prof, stud)

Prof

fach

stud

name

Kurs

name name

bereich

lehrteval

sem

Betreut

Eingeschrieben

sem

VertiefungArbeitet

titel kurs_id



Anfrageumschreibung – Beispiel

Globale Anfrage SELECT B.prof, B.stud, E.sem FROM Eingeschrieben E, Lehrt L, Betreut B WHERE E.kurs_id = L.kurs_id AND E.sem = L.sem AND B.prof = L.prof AND B.stud = E.stud AND E.sem ≥ „WS98“

Quelle 9: CREATE VIEW StudProf3 AS SELECT L.prof, E.stud, E.sem FROM Eingeschrieben E, Lehrt L WHERE E.kurs_id = L.kurs_id AND E.sem = L.sem AND E.sem ≥ „WS99“

Frage:• nutzbar?• nützlich?

Umschreibung SELECT B.prof, B.stud, S.sem FROM StudProf3 S, Betreut B WHERE B.prof = S.prof AND B.stud = S.stud

Stärkere Bedingung

Umschreibung ist contained aber nicht äquivalent⇒ OK für Datenintegration, aber ungünstig für materialized views


Anfragebearbeitung Local-as-View Bucket Algorithm

Bucket Algorithm (BA) [LRO96]

Idee: Reduktion der Anzahl der Kombinationen durch geschickteVorauswahl

Jede Relation der Anfrage erhalt einen bucket (Korb).

Schritt 1: Fuge in jeden bucket alle Sichten, die fur die Relationnutzbar sind

Schritt 2: Prufe alle Sichten-Kombinationen (alsoAnfrageumschreibungen) auf containment mit der gegebenenAnfrage, die aus jedem bucket genau eine Sicht enthalten.



Bucket Algorithm – Beispiel

Bucket 1: Lehrt(prof, kurs_id, sem)

Bucket 2: Eingeschrieben(stud, kurs_id, sem)

Bucket 3: Kurs(kurs_id, titel)

V2 V4

V1 V4

V1 V2

V1 (stud, titel, sem, kurs_id) :− E(stud,kurs_id,sem), K(kurs_id,titel), kurs_id ≥ 500, sem ≥ WS98V2 (stud, prof, sem, kurs_id) :− E(stud, kurs_id, sem), L(prof, kurs_id, sem)V3 (stud, kurs_id) :− E(stud, kurs_id, sem), sem ≤ WS94V4 (prof, kurs_id, titel, sem) :− L(prof, kurs_id, sem), K(kurs_id, titel), E(stud, kurs_id, sem), sem ≤ WS97

Anfrage: Q (stud, kurs_id, prof) :- L(prof, kurs_id, sem), E(stud,kurs_id,sem), K(kurs_id, titel), sem ≥ WS95, kurs_id ≥ 300

Ergebnis des Algorithmus:Umgeschr. Anfrage: V1,V2 UNION V2,V4

Kombinationen V2, V1, V1 → V1,V2 V4, V1, V4 → Ø V2, V2, V4 → V2,V4 V2, V2, V1 → V1,V2 V2, V1, V4 → Ø V4, V1, V1 → Ø V4, V2, V4 → V2,V4 V4, V2, V1 → Ø



Bucket Algorithm – Kombinationen

Wieviele Kombinationen?

|B1| × |B2| × . . .× |Bn| (n = |Q|)Falls m = Anzahl der Sichten: mn

Wichtig: Jede der exponentiell vielen Kombinationen liefertpotentiell einen Teil des Ergebnisses!

Kombination Q ′ = V1, . . . ,Vm ist eine Anfrageumschreibung Q ′,falls Q ′ ⊆ Q.


Anfragebearbeitung PDMS

Agenda

1 Anfragebearbeitung Local-as-ViewNutzung von LaV MappingsBucket Algorithm

2 Anfragebearbeitung PDMS



PDMS-Beispiel

19. Januar 2006 Armin Roth, Humboldt-Universität zu Berlin 13

P1 fachuniv dozfaktitelkurs_idKurs

P2

P5

titelkurs_idKurs sem fakevalkurs_idprofLehrt

univ dozfaktitelkurs_idDB_Kurs

fach ortprofArbeitet

art titelevent_idEvent

fachfakFak

P4 P6

P6.Event(kurs_id, fach, titel) ⊆P2.Kurs(kurs_id, titel), P2.Lehrt(prof, kurs_id, sem, eval, fak), P2.Fak(fak, fach)

P4.Arbeitet(prof, fach, ort) ⊆P2.Lehrt(prof, kurs_id, sem, eval, fak), P2.Fak(fak, fach)

P2.Kurs(kurs_id, titel), P2.Lehrt(prof, kurs_id, sem, eval, fak),P2.Fak(fak, fach) ⊆P1.Kurs(kurs_id, titel, fak, univ, fach, doz)

P5.DB_Kurs(kurs_id, titel, fak, univ, doz) ⊆P1.Kurs(kurs_id, titel, fak, univ, fach, doz)

P1.

Kurs

(kur

s_id

, tite

l, fa

k, u

niv,

fach

, doz

) ⊆P

6.Ev

ent(k

urs_

id, f

ach,

tite

l)

P5.

DB_

Kurs

(kur

s_id

, tite

l, fa

k, u

niv,

doz

) ⊆P6

.Eve

nt(k

urs_

id, a

rt, ti

tel)



Anfragebearbeitung: Rule-Goal Tree [HIST03]

Goal-Knoten



Goal-Knoten : Prädikate (umformulierter) Anfrage(n) + zugehörige VergleichsprädikateRule-Knoten : entsprechen Peer-Mappings

P.q(x, y)

Q

P.L(x, y), x > 0

P RL

P.R(x, y), x > 0

Q: q(x, y) :– P.R(x, y), x > 0

M: R(x, y) ⊆ L(x, y)

M

Pradikate (umformulierter)Anfrage(n) + zugehorigeVergleichspradikate

Rule-Knoten




P.q(x, y)

Q

P.L(x, y), x > 0

P RL

P.R(x, y), x > 0

Q: q(x, y) :– P.R(x, y), x > 0

M: R(x, y) ⊆ L(x, y)

M

entsprechen Peer-Mappings




P.q(x, y)

Q

P.L(x, y), x > 0

P RL

P.R(x, y), x > 0

Q: q(x, y) :– P.R(x, y), x > 0

M: R(x, y) ⊆ L(x, y)

M



GaV-Anfrageumformulierung


GaV-Anfrageumformulierung

[] Peer001.q(kurs_id, titel, fak, univ, fach, doz)() Q

[] Peer001.Kurs(kurs_id, titel, fak, univ, fach, doz)() M1→2

[] Peer002.Kurs(kurs_id, titel)[] Peer002.Lehrt(prof__1, kurs_id, sem__2, eval__3, fak)[] Peer002.Fak(fak, fach)

P1 fachuniv dozfaktitelkurs_idKurs 20%

P2


fachfakFak

40%

M1→2

Q: P1.q(kurs_id, titel, fak, univ, fach, doz) :–P1.Kurs(kurs_id, titel, fak, univ, fach, doz)

P2.Kurs(kurs_id, titel), P2.Lehrt(prof, kurs_id, sem, eval, fak),P2.Fak(fak, fach) ⊆P1.Kurs(kurs_id, titel, fak, univ, fach, doz)



LaV-Anfrageumformulierung


LaV-Anfrageumformulierung


[] Peer001.Kurs(kurs_id, titel, fak, univ, fach, doz)() M1→2

[] Peer002.Kurs(kurs_id, titel)[] Peer002.Lehrt(prof__1, kurs_id, sem__2, eval__3, fak)

() M2→4[] Peer004.Arbeitet(prof__1, fach, ort__6)

[unc] Peer002.Fak(fak, fach)[] Peer002.Fak(fak, fach)

P2



fachfakFak

40%

10%

P4P4.Arbeitet(prof, fach, ort) ⊆P2.Lehrt(prof, kurs_id, sem, eval, fak), P2.Fak(fak, fach)



Behandlung von Zyklen

Equality-Mappings bedeuten Zyklen:Q1(P1) = Q2(P2)⇔Q1(P1) ⊆ Q2(P2) ∧ Q1(P1) ⊇ Q2(P2)

First-order Logic-Semantik:Anfragebearbeitung bei Zyklenunentscheidbar [HIST03, CGLR04]

Abbruchkriterien (z.B. mehrfache Verwendung eines Mappings):verliert u.U. Antworten [Sch06]



Beispiel Zyklus


P1 fachuniv dozfaktitelkurs_idKurs

P2

P5


univ dozfaktitelkurs_idDB_Kurs


art titelevent_idEvent

fachfakFak

P4 P6

Mapping-Zyklus



Beispiel Zyklus



[] Peer001.Kurs(kurs_id, titel, fak, univ, fach, doz)() ML1

[] LS001_1.Kurs(kurs_id, titel, fak, univ, fach, doz)() M1→2

[] Peer002.Kurs(kurs_id, titel)() M2→6

[] Peer006.Event(event_id__4, art__5, titel)() M6→5

[] Peer005.DB_Kurs(kurs_id__8, titel, fak__9, univ__10, doz__11)() ML5

[] LS005_1.DB_Kurs(kurs_id__8, titel, fak__9, univ__10, doz__11)() M6→1

[] Peer001.Kurs(event_id__4, titel, fak__12, univ__13, art__5, doz__14)() ML1

[] LS001_1.Kurs(event_id__4, titel, fak__12, univ__13, art__5, doz__14)() M1→5

[] Peer005.DB_Kurs(event_id__4, titel, fak__12, univ__13, doz__14)() ML5

[] LS005_1.DB_Kurs(event_id__4, titel, fak__12, univ__13, doz__14)[unc] Peer002.Lehrt(prof__1, kurs_id, sem__2, eval__3, fak)[unc] Peer002.Fak(fak, fach)

() ML2[] LS002_1.Kurs(kurs_id, titel)

[] Peer002.Lehrt(prof__1, kurs_id, sem__2, eval__3, fak)() ML2

[] LS002_1.Lehrt(prof__1, kurs_id, sem__2, eval__3, fak)() M2→4

[] Peer004.Arbeitet(prof__1, fach, ort__6)() ML4

[] LS004_1.Arbeitet(prof__1, fach, ort__6)[unc] Peer002.Fak(fak, fach)

[] Peer002.Fak(fak, fach)() ML2

[] LS002_1.Fak(fak, fach)() M1→5

[] Peer005.DB_Kurs(kurs_id, titel, fak, univ, doz)() ML5

[] LS005_1.DB_Kurs(kurs_id, titel, fak, univ, doz)

M1→2 wird nicht mehr genutzt: Abbruch des Zyklus



Ableitung des Anfrageplanes

Verzweigender Goal-Knoten: UNION

Verzweigender Rule-Knoten: JOIN


Ableitung des Anfrageplanes Verzweigender Goal-Knoten: UNION Verzweigender Rule-Knoten: JOIN

P1.Kurs

P1.q

Q

P2.Kurs P2.Lehrt

P4.Arbeitet

Peer002.q

UNION

JOIN

UNION

UNION

P2.Fak

JOIN

(deckt P2.Lehrt und P2.Fak ab)



Effizienzprobleme durch Redundanzen

Redundante Mapping-Pfadefuhren zu stark verzweigtenRule-Goal Trees

Beispiel [Sch06]

31 PeersRang ca. 5 (Anzahl vonPeers, zu denen ein PeerMappings hat)34378 Union- und 17035Join-Operationen


Effizienzprobleme durch Redundanzen

Redundante Mapping-Pfade führen zu stark verzweigten Rule-Goal TreesBeispiel [Schw06]:

31 PeersRang ca. 5 (Anzahl von Peers, zu denen ein Peer Mappings hat)34378 Union- und 17035 Join-Operationen



Optimierung mit limitierter

Ressourcennutzung [Rot12]

22 Armin Roth Berlin, 01.04.2011

Experimente (100 Peer PDMS )

GREEDY WEIGHTED



Literatur

[CGLR04] Diego Calvanese, Giuseppe De Giacomo, Maurizio Lenzerini, and Riccardo Rosati.Logical foundations of peer-to-peer data integration.In Proc. of the Symposium on Principles of Database Systems (PODS), 2004.

[CM77] A. K. Chandra and P. M. Merlin.Optimal implementation of conjunctive queries in relational databases.In Proc. of the ACM Symposium on Theory of Computing (STOC), 1977.

[HIST03] Alon Y. Halevy, Zachary Ives, Dan Suciu, and Igor Tatarinov.Schema mediation in peer data management systems.In Proc. of the Int. Conf. on Data Engineering (ICDE), 2003.

[LRO96] A. Y. Levy, A. Rajaraman, and J. J. Ordille.Query-answering algorithms for information agents.In Proc. of the National Conf. on Artificial Intelligence (AAAI), 1996.

[Rot12] Armin Roth.Efficient Query Answering in Peer Data Management Systems.PhD thesis, Humboldt Universitat zu Berlin, 2012.

[Sch06] Martin Schweigert.Entwurf eines Peer Data Management Systems mit Steuerungs- und Simulationskomponente.Master’s thesis, Humboldt-Universitat zu Berlin, 2006.In German.


anfragebearbeitung lav und pdms - vsis homepage · pdf fileagenda 1 anfragebearbeitung...

Documents