Data Warehousing. Answering Queries using Views. Anfrageplanung mit materialisierten Views. Materialisierte Views mit Aggregation

Transkript

1 Data Warehousing Answering Queries using Views Materialisierte Views mit Aggregation Anfrageplanung mit materialisierten Views Ulf Leser Wissensmanagement in der Bioinformatik

2 Inhalt dieser Vorlesung Einführung Theorie Answering Queries using Views Materialisierte Views in DWHs Query Rewriting Bedingungen, Joins, Gruppierungen Anfrageoptimierung mit MVs Materialisierte Views in Oracle Ulf Leser: Data Warehousing, Vorlesung, SoSe

3 Beispiel Product product_id product_name pg_id pg_name Time day_id day month_id month year_id year Sales Product_id Day_id Shop_id amount price Localization shop_id shop_name region_id region_name Ulf Leser: Data Warehousing, Vorlesung, SoSe

4 Teil 1. Materialisierte Sichten (MV) Grundidee Viele Anfragen wiederholen sich häufig Bilanzen, Bestellungsplanung, Produktionsplanung Kennzahlenberechnung Viele Anfragen sind Variationen derselben Anfrage Alle Verkäufe nach Produkt, Monat und Region Alle Verkäufe in Region X nach Produkt, Monat und Shop Materialisierter View Einmaliges Berechnen und Speichern der Anfrage Transparente Verwendung in folgenden Anfragen Ulf Leser: Data Warehousing, Vorlesung, SoSe

5 Arbeiten mit einem Cube führt zu... SELECT L.shop_id, P.product_id, T.day_id, sum(amount*price) FROM sales S, time T, product P, localization L WHERE S.day_id = T.day_id AND S.product_id = P.product_id AND S.shop_id = L.shop_id AND P.shop_id = 159 GROUP BY L.shop_id, P.product_id, S.time_id Roll-Up SELECT L.shop_id, P.product_id, T.day_id, sum(amount*price) FROM sales S, time T, product P, localization L WHERE S.day_id = T.day_id AND S.product_id = P.product_id AND S.shop_id = L.shop_id AND L.region_name = NRW GROUP BY L.shop_id, P.product_id, S.time_id SELECT L.shop_id, P.product_id, T.day_id, sum(amount*price) FROM sales S, time T, product P, localization L Slice WHERE S.day_id = T.day_id AND S.product_id = P.product_id AND S.shop_id(+) = L.shop_id AND L.region_name = NRW AND T.year = 1999 GROUP BY L.shop_id, P.product_id, S.time_id Ulf Leser: Data Warehousing, Vorlesung, SoSe

6 Materialisierter View CREATE MATERIALIZED VIEW all_groups AS SELECT L.shop_id, P.product_id, T.day_id, sum(amount*price) FROM sales S, time T, product P, localization L WHERE S.day_id = T.day_id AND S.product_id = P.product_id AND S.shop_id = L.shop_id GROUP BY L.shop_id, P.product_id, S.time_id SELECT * FROM all_groups A WHERE A.shop_id = 159 OK SELECT * FROM all_groups A WHERE A.region_name = NRW Nein SELECT * FROM all_groups A WHERE A.region_name = NRW AND A.year = 1999 Nein Ulf Leser: Data Warehousing, Vorlesung, SoSe

7 MV Themen und Probleme Wahl von Views zur Materialisierung MVs kosten: Platz und Aktualisierungsaufwand Wahl der optimalen MVs hängt von Workload ab Ziel ist Auswahl der optimale Menge von MV Automatische Aktualisierung von MV Aktualisierung bei Änderungen U.U. schwierig: Aggregate, Joins, Outer-Joins,... Ziel ist inkrementelle Aktualisierung Automatische Verwendung von MV Theorie der Answering Queries using Views Schwierigkeit hängt von Komplexität der Anfrage / Views ab Ziel ist transparente und kostenoptimale Verwendung Ulf Leser: Data Warehousing, Vorlesung, SoSe

8 Teil 2. Answering Queries using Views Gegeben Eine Query q Eine Menge V von materialisierten Views Fragen Kann man q unter Verwendung von V beantworten? Kann man q nur mit V beantworten? Kann man q mit V vollständig beantworten? Ist es günstig, Views aus V zur Beantwortung von q zu verwenden? Welche? Schwierige Probleme Ulf Leser: Data Warehousing, Vorlesung, SoSe

9 Datalog Notation Im Folgenden: Nur konjunktive Anfragen Equi-joins und Bedingungen mit =,<,> zw. Attr. und Wert Kein NOT, EXISTS, GROUP BY,, X>Y,... Schreibweise: Datalog (Prolog, Domänenkalkül) q(x,y):-sales(x,a,b,c),time(a,y,d),d>1999 SELECT Klausel Regelkopf, Exported Variables FROM Klausel Relationen werden zu Prädikaten Attribute werden über Position statt Name adressiert WHERE Klausel Joins werden durch gleiche Variablen angezeigt Bedingungen werden explizit angegeben Gleichheitsbedingungen Attribut-Wert werden durch Konstante in Literal angegeben Ulf Leser: Data Warehousing, Vorlesung, SoSe

10 SQL Datalog SELECT S.price, L.region_name FROM sales S, time T, localization L, product P WHERE S.day_id = T.day_id AND S.product_id = P.product_id AND S.shop_id = L.shop_id AND L.shop_name = KB AND T.year > 1999 SELECT FROM WHERE Joins q(p,rn) :- sales(sid,pid,tid,lid,p,...), time(tid,d,m,y), localization(lid, KB,RN), product(pid,pn,pgn), Y > 1999 Ulf Leser: Data Warehousing, Vorlesung, SoSe

11 Begriffe q(p,rn) :- sales(sid,pid,tid,lid,p,...), time(tid,d,m,y), localization(lid, KB,RN), product(pid,pn,pgn), Y > 1999 q ist der Kopf (oft synonym für ganze Query) Variablen sind in GROSSBUCHSTABEN sales, time,.. sind Prädikate sales(sid,...), time(tid,...) sind Literale Eine Query kann ein Prädikat mehrmals enthalten - mehrere Literale desselben Prädikats Literale sind eindeutig Ulf Leser: Data Warehousing, Vorlesung, SoSe

12 Query Containment Gegeben Query q View v (zunächst nur einer) Anfrageäquivalenz Ist Ergebnis von v identisch dem Ergebnis von q? Kurz: Ist v äquivalent zu q, v q Anfragecontainment ( enthalten in ) Ist das Ergebnis von v im Ergebnis von q enthalten? Kurz: Ist v in q enthalten, v q Rückführung v q, q v v q Definition von äquivalent, enthalten in für Queries? Ulf Leser: Data Warehousing, Vorlesung, SoSe

13 Definition Definition Sei S ein Schema. Seien q 1 und q 2 Anfragen gegen S Eine Instanz von S ist eine beliebige Datenbank D mit Schema S, geschrieben D S Das Ergebnis einer Query q in einer Datenbank D S, geschrieben q(d S ), ist die Menge aller Tupel, die die Ausführung von q in D S ergibt (siehe Domänen / Tupelkalkül) q 1 ist äquivalent zu q 2, geschrieben q 1 q 2, gdw. q 1 (D S ) = q 2 (D S ) für jede mögliche D S q 1 ist enthalten in q 2, geschrieben q 1 q 2, gdw. q 1 (D S ) q 2 (D S ) für jede mögliche D S Semantische Definition: Es zählt das Ergebnis einer Query, nicht die Syntax Ulf Leser: Data Warehousing, Vorlesung, SoSe

14 Beispiele Regelkopf wird hier unterschlagen product(pid,pn,pgid, Wasser ) product(pid,pn,pgid,pgn) product(pid,pn,pgid,pgn), PGN> Wasser sales(sid,pid,...,p,...), P>80, P<150 sales(sid,pid,...,p,...), P>100,P<=150,P<170,P>=150 sales(sid,pid,...,p,...), q product(pid,pn,...) q product(pid,pn,pgid,pgn) localization(sid,sn,rid,rn) product(pid,pn,pgid,pgn) sales(sid,pid,...,p,...), P>100, P<150 sales(sid,pid,...,150,...) sales(sid,pid,...,p,...) (Bei Projektion auf sales) Ulf Leser: Data Warehousing, Vorlesung, SoSe

15 Weitere Beispiele q 1 (B,D) :- path(a,b), path(b,c), path(c,d), path(d,e) q 2 (A,C) :- path(a,b), path(b,c), path(c,d) q 1 q 2 q 1 (C,B) :- path(a,b), path(c,a), path(b,c), path(a,d) q 2 (X,Z) :- path(x,y), path(y,z) q 1 q 2 q 1 (A,C) :- path(a,b), path(b,c) q 2 (A,C) :- threenodepath(a,b,c) q 1 q 2 q 1 (B,D):-path(A,B),path(B,C),path(C,D),path(A,E),path(E,D) q 2 (A,C):-path(A,C),path(C,E),path(E,A),path(A,B),path(D,B)? q 1 q 2 Ulf Leser: Data Warehousing, Vorlesung, SoSe

16 Wie kann man Containment beweisen? Definition: Sei q eine Query: q(e 1,E 2,...,E n ) :-.... Dann ist exp(q)={e 1,E 2,...E n } die Menge der exportierten Variablen von q Definition: Ein Containment Mapping (CM) zwischen zwei Queries q 1, q 2 ist eine Funktion h: sym(q 2 ) a sym(q 1 ) mit Jede Konstante in q 2 wird auf dieselbe Konstante in q 1 abgebildet Jede exportierte Variable in q 2 wird auf eine exportierte Variable in q 1 abgebildet Jedes Literal in q 2 wird auf mindestens ein Literal in q 1 abgebildet Der Kopf von q 2 wird auf den Kopf von q 1 abgebildet Die Bedingungen von q 1 implizieren die Bedingungen von h(q 2 ) Ulf Leser: Data Warehousing, Vorlesung, SoSe

17 CM Query Containment Theorem q 1 q 2 gdw. es ein CM von q 2 nach q 1 gibt Lemma q 1 q 2 gdw. es ein CM von q 2 nach q 1 und ein CM von q 1 nach q 2 gibt Beweise Literatur Richtungen beachten! Containment Mapping von q 2 nach q 1 Bedingungen von q 1 implizieren Bedingungen von q 2 Ulf Leser: Data Warehousing, Vorlesung, SoSe

18 Beispiel q 1 q 2? q 2 (A,C) :- path(a,b), path(b,c), path(c,d) q 1 (B,D) :- path(a,b), path(b,c), path(c,d), path(d,e) Mapping: A A, B B, C C, D D q 2 (A,C) :- path(a,b), path(b,c), path(c,d) q 1 (B,D) :- path(a,b), path(b,c), path(c,d), path(d,e) Mapping: A B, B C, C D, D E Ulf Leser: Data Warehousing, Vorlesung, SoSe

19 Beispiel q 2 (DID,P) :- sales(sid,tid,p,...),time(tid,d,...),d>28,d<31 q 1 (Y,Z) :- sales(x,y,z...),time(y,u,...), U>1,U<30 CM: SID X, TID Y, P Z, D U h(d)=u Aber: U>1 U<30 h(d)>28 h(d)<31 Q 1 Q 2 Ulf Leser: Data Warehousing, Vorlesung, SoSe

20 Wie findet man CMs? q v dann und nur dann, wenn es ein Containment Mapping von v nach q gibt Wie findet man Containment Mappings? Problem ist NP vollständig Prinzip: Alles ausprobieren Ulf Leser: Data Warehousing, Vorlesung, SoSe

21 Suchraum v = a(...),b(...),b(...),c(...) q = b(...),c(...),a(...),b(...),d(...) Lit. nummerieren v = a(...),b 1 (...),b 2 (...),c(...) q = b 1 (...),c(...),a(...),b 2 (...),d(...)... jedes Literal von v muss auf mindestens ein Literal in q gemapped werden... Möglichkeiten: a a b 1 b 1 b 1 b 2 b 2 b 1 b 2 b 2 c c Ulf Leser: Data Warehousing, Vorlesung, SoSe

22 V = a(...), b(...), b(...), c(...) Suchbaum a b 1 b 2 b 1 b 2 b 1 b 2 c c c c Ulf Leser: Data Warehousing, Vorlesung, SoSe

23 Voraussetzungen Definition Seien R, S zwei Literale. R wird dominiert von S bzgl. h, R h S, wenn h ein Containment Mapping von S nach R ist Note: Wenn so ein h existiert, ist es eindeutig Seien h 1,h 2 zwei Containment Mapping. h 1 und h 2 heißen kompatibel, wenn gilt: (x A) h 1 (x B) h 2 A=B Seien h 1,h 2 zwei kompatible C. Mapping. Dann ist h = h 1 h 2 die kanonische Union der beiden Mappings Ulf Leser: Data Warehousing, Vorlesung, SoSe

24 Grobablauf Algorithmus durchläuft den Suchbaum Depth-First und versucht, ein wachsendes CM aufzubauen Sei h das aktuelle Mapping, l das aktuelle Literal aus q 2 Berechne alle von l dominierten Zielliterale aus q 1 Teste für diese Zielliterale (t) Kompatibilität von h und (l t) h und (l t) sind kompatibel Ist l das letzte, noch nicht gemappte Literal?» Ja, terminiere und melde Erfolg h = h (l t) Pushe alle Kinder von t Untersuche nächstes Literal von q 2 h und (l t) sind nicht kompatibel Sind noch Geschwister von t vorhanden?» Ja testen» Nein terminiere und melde Misserfolg Ulf Leser: Data Warehousing, Vorlesung, SoSe

25 Datenstruktur Positionen im Suchbaum wird in einem Stack gespeichert Stackelemente sind Tripel: (X,Y,Z) X: CM bis zu dieser Position (alle Väter/ Vorgängerliterale sind gemapped) Y: Weitere Mappingkandidaten im aktuellen Zweig (= noch nicht untersuchte Geschwister) Z:Literaleaus q 2, die noch nicht gemapped sind (= Noch nicht besuchte Level des Suchbaums) Ulf Leser: Data Warehousing, Vorlesung, SoSe

26 Depth-First Algorithmus Input: Two queries q 1, q 2 ; Output: True, if q 1 q 2, else false; 1: R = new stack(); 2: L = {l l q 2 }; % Alle Literale in q 2 3: l = L.first(); % Schon erledigte Lits von q 2 4: H = {h l q 1 l h l } % Alle von l dominierten in q 2 5: R.push([], H, L\l); % Startpunkt 6: repeat 7: (h,h,l) = R.pop(); % Hier weitermachen 8: if H= then % Keine Kandidaten - aufhören 9: return false; 10: else 11: g = H.first(); 12: R.push(h, H\g, L); % Geschwister später untersuchen 13: if compatible(h,g) then % CM kann erweitert werden 14: if L = then 15: return true; % Blatt erreicht - fertig 16: else 17: l = L.first(); % Innerer Knoten, Kinder pushen 18: H = {h l q 1 l h l }; 19: R.push(h g, H, L\l); 20: end if; 21: end if; 22: end Ulf Leser: if; Data Warehousing, Vorlesung, SoSe : until R = ; % Irgendwo Kand. ausgegangen

27 Beispiel v(a,b) = a(a,c),b(c,b),c(b,a) q(x,y) = a(x,y),b 1 (Y,Z),b 2 (Y,X),c 1 (Z,X),c 2 (X,X) CM bis Position Aktuelles CM Gemappte Lit von v Zielliterale in q A X,C Y A X,C Y, C Y,B Z A X,C Y, C Y,B X A X,C Y,C Y,B X, B Z,A X A X,C Y,C Y,B X, B X,A X a(a,c) a(x,y) a(a,c),b(c,b) a(x,y),b 1 (Y,Z) a(a,c),b(c,b) a(x,y),b 2 (Y,X) a(a,c),b(c,b),c(b,a) a(x,y),b 2 (Y,X),c 1 (Z,X) a(a,c),b(c,b),c(b,a) a(x,y),b 2 (Y,X),c 2 (X,X) Z nicht exportiert B X,B Z nicht komp. Ulf Leser: Data Warehousing, Vorlesung, SoSe

28 Beispielbaum a b 1 b 2 c 1 c 2 c 1 c 2 a a a a b 1 b 2 c 1 a b 2 b 2 c 2 a(a,c) a(x,y) a(a,c),b(c,b) a(x,y),b 2 (Y,X) a(a,c),b(c,b),c(b,a) a(x,y),b 2 (Y,X),c 2 (X,X) a(a,c),b(c,b) a(x,y),b 1 (Y,Z) a(a,c),b(c,b),c(b,a) a(x,y),b 2 (Y,X),c 1 (Z,X) Ulf Leser: Data Warehousing, Vorlesung, SoSe

29 Zusammenfassung Query Containment ist NP-vollständig schon für konjunktive Anfragen Diverse Erweiterungen bekannt Query containment mit UNIONs, Safe Negation, GROUP BY, Rekursion,... I.d.R. noch höhere Komplexitätsklassen Theoretisches Problem mit einigen Anwendungen DWH: Materialisierte Views Informationsintegration: Quellenbeschreibung Mobile Datenbanken: Semantic Caching Ulf Leser: Data Warehousing, Vorlesung, SoSe

30 Teil 3. Anwendung im DWH Grundkonzept Ableitbarkeit und Kompensation Von Bedingungen VonJoins Von Gruppierungen Ulf Leser: Data Warehousing, Vorlesung, SoSe

31 Aufgabe Gegeben Query q View(s) v Gesucht Eine Methode, q mit Hilfe von v zu beantworten Trick Was nicht passt, wird passend gemacht Ulf Leser: Data Warehousing, Vorlesung, SoSe

32 Anwendung Möglichkeit 1: q nicht in v, v nicht in q Kein (erkennbarer) Zusammenhang zwischen Queries v wird nicht für q benutzt Möglichkeit 2: v und q äquivalent v als Ergebnis von q ausgeben Test auf Äquivalenz sehr teuer (2 x Containment) Benutzung nur bei syntaktischer Äquivalenz Ulf Leser: Data Warehousing, Vorlesung, SoSe

33 Anwendung Möglichkeit 3: v in q aber nicht umgekehrt v ist ein partielles Ergebnis für q Jedes Tupel von v ist korrekte Antwort für q, aber v berechnet nicht alle korrekten Antworten Erweiterung von v i.d.r. nicht hilfreich Berechnung von q\v nicht trivial Nur selten einfache (und damit schnelle) Lösungen Keine Verwendung (in Datenbanken), aber: Informationsintegration Datentransformationen Ulf Leser: Data Warehousing, Vorlesung, SoSe

34 Anwendung 2 Möglichkeit 4: q in v aber nicht umgekehrt Ergebnis von q vollständig enthalten in v Nicht alle Tupel von v sind korrekte Ergebnisse für q, aber v berechnet alle Ergebnisse von q Manche Tupel müssen aus Ergebnis entfernt werden Probleme Vollständigkeit: v enthält alle Tupel auch alle Attribute? Ableitbarkeit: Wie findet man Filter F auf v, so das F(v) q? Ulf Leser: Data Warehousing, Vorlesung, SoSe

35 3.1 Vollständigkeit v v q q Query Containment, q v Erweitertes Query Containment Containment macht Aussage über gestreiften Bereich CM Bedingungen müssen erweitert werden Ulf Leser: Data Warehousing, Vorlesung, SoSe

36 Erweitertes CM Definition: Ein erweitertes Containment Mapping (CM) zwischen zwei Queries q 1, q 2 ist eine Funktion h: sym(q 2 ) a sym(q 1 ) mit Jede Konstante in q 2 wird auf dieselbe Konstante in q 1 abgebildet Jede exportierte Variable in q 2 wird auf eine exportierte Variable in q 1 abgebildet Jedes Literal in q 2 wird auf mindestens ein Literal in q 1 abgebildet Der Kopf von q 2 wird auf den Kopf von q 1 abgebildet Die Bedingungen von q 1 implizieren die Bedingungen von h(q 2 ) Das Urbild jeder exportierten Variable in q 1 existiert in h und ist in q 2 exportiert In Zukunft: CM = Erweitertes Containment Mapping Ulf Leser: Data Warehousing, Vorlesung, SoSe

37 3.2 Ableitbarkeit Jetzt hat man alle Attribute, aber zu viele Tupel Wie findet man die richtigen? Ableitbarkeit Wenn q v, dann gilt: q h(v) Gesucht: Formel F: F h(v) q Der allgemeine Fall ist unentscheidbar wegen Unentscheidbarkeit der Prädikatenlogik Deswegen viele Einschränkungen... Ulf Leser: Data Warehousing, Vorlesung, SoSe

38 Ableitbarkeit Annahme: q und v enthalten dieselben Literale und Joins v 1 (P,PN,SN) :- s(sid,pid,lid,p),p(pid,pn),l(lid,sn) v 2 (P,PN,SN) :- s(sid,pid,lid,p),p(pid,pn),l(lid,sn) P>100, P<300, SN= Kreuzberg q 1 (P,PN,SN) :- s(sid,pid,lid,p),p(pid,pn),l(lid,sn), PN= Gerolsteiner q 2 (P,PN,SN) :- s(sid,pid,lid,p),p(pid,pn),l(lid,sn), P>100, P<200, SN= Kreuzberg q 3 (P,PN,SN) :- s(sid,pid,lid,p),p(pid,pn),l(lid,sn), SN= Kreuzberg v 2... q 1 v 1 PN= Gerolsteiner q 1 v 2 P<200 q 2 v 1... q x v 2... q 3 Ulf Leser: Data Warehousing, Vorlesung, SoSe

39 3.2.1 Ableitbarkeit von Bedingungen Annahme: q v Einfachster Filter Es gilt: q h(v) Dann gilt immer: q h(v) q Frage: ist h(v) q berechenbar? Ulf Leser: Data Warehousing, Vorlesung, SoSe

40 Ableitbarkeit von Bedingungen 2 v(a,b) :- r(a,b,c,d),b<40,c>60 q(a,b) :- r(a,b,c,d),b<30,c>70 q aus v ableitbar? Verschärfung B<30 auf Ergebnis von v berechenbar Verschärfung C>70 nicht auf Ergebnis von v berechenbar Funktioniert nur, wenn die notwendigen Variablen von v exportiert werden Ulf Leser: Data Warehousing, Vorlesung, SoSe

41 Ableitbarkeit von Bedingungen 3 Annahmen q v mit CM h: v q Nur einfache Bedingungen Seien B={B 1,B 2,...B n } die Bedingungen aus q (ohne Joinbedingungen) Algorithmus Für alle Bedingungen B i mit h(v) B i Wenn B i Variablen enthält, deren Urbild in v nicht exportiert ist: Abbruch (nicht kompensierbar) Sonst: q h(v) B Komplexität von Test auf O(n) für Bedingungen der Art: X=5, X<5, X>5 O(n 3 ) für Bedingungen der Art: X=Y, X<Y,X>Y Ulf Leser: Data Warehousing, Vorlesung, SoSe

42 3.2.2 Ableitbarkeit von Joins Bisher Literale und Joins stimmen überein Keine Aggregation Ableitbarkeit hängt von Bedingungen ab Nun Keine Bedingungen, Keine Aggregation Mismatch bei Literalen oder Joins Problem Zusätzliche Joins i.d.r. Filter auf Ergebnissen Lossless Joins Ulf Leser: Data Warehousing, Vorlesung, SoSe

43 Beobachtungen Notwendige Bedingungen für q v Alle Prädikate von v müssen in q vorkommen Alle Ebenen im Suchbaum sind nicht-leer v darf nicht mehr Joins enthalten als q Sonst kann es kein CM geben Das ist auch hinreichend, wenn jedes Prädikat nur einmal in q vorkommt Also keine Self-joins Suchbaum degeneriert, Test ist linear Containment ist linear für konjunktive Anfragen ohne Self-joins Ulf Leser: Data Warehousing, Vorlesung, SoSe

44 Beispiele v(p,pn,sn,tid) :- s(sid,pid,lid,tid,p),p(pid,pn),l(lid,sn) q 1 (P,PN,SN,TID) :- s(sid,pid,lid,tid,p),p(pid,pn) q 2 (P,PN,SN,TID) :- s(sid,pid,lid,tid,p),p(pid,pn),l(lid,sn), t(tid,d,m,y) q 3 (P,PN,SN,TID) :- s(sid,pid,lid,tid,p),p(pid,p),l(lid,sn) q 1 v Inner Join mit l(lid,sn) Filter auf v Berechnung der gefilterten Tupel möglich, aber nicht (immer) trivial (Berechnung q 1 \v) q 2 v Inner Join mit t() Filter auf q 2 q 2 v t(tid,d,m,y) q 3 v Join s(...,p),p(pid,p) Filter auf q 3 q 3 v PN=P (σ PN=P (V)) Ulf Leser: Data Warehousing, Vorlesung, SoSe

45 Kompensation Annahme: Sei q v Potentielle Problem q enthält Literale, die v nicht enthält q enthält Joins, die v nicht enthält Theoretisch einfachste Kompensation Wende q auf v an: q q(v(d)) In RDBMS Architektur schwierig zu implementieren Wenn v und q jedes Prädikat nur einmal enthalten Berechne Prädikate P von q, die nicht in v Berechne Joins J von q, die nicht in v Dann: q h(v) P J Ulf Leser: Data Warehousing, Vorlesung, SoSe

46 Kompensation 2 Annahme: Sei q v Also existiert CM h: v q h bildet jedes Literal aus v auf genau ein Literal aus q ab Algorithmus Berechne h Berechne Literale R=(R 1,R 2,...) aus q, die nicht im Bild von h sind Prüfe alle Attribute A R x, R x R, die als Bild in h enthalten sind, d.h., es gibt ein (X A) h Wenn X exp(v): Abbruch (nicht kompensierbarer Join zw q\r und R) Für alle {(X A,Y A)} h Wenn X exp(v) oder Y exp(v): Abbruch (nicht komp. Join in q\r) Sonst: q h(v) R Vorsicht: Es kann mehrere h geben Müssen alle getestet werden Ulf Leser: Data Warehousing, Vorlesung, SoSe

47 Beispiel v(p,pn,sn,tid) :- s(sid,pid,lid,tid,p),p(pid,pn),l(lid,sn) q 2 (P,PN,SN,TID) :- s(sid,pid,lid,tid,p),p(pid,pn),l(lid,sn), t(tid,d,m,y) q 3 (P,PN,SN,TID) :- s(sid,pid,lid,p),p(pid,p),l(lid,sn) q 2 und v R={t} (TID TID) h, aber TID exp(v) Keine zusätzlichen Joins in q 2 q 2 v(p,pn,sn,tid),t(tid,d,m,y) q 3 und v R= (P P),(PN P) h, aber P,PN exp(v) q 3 v(p,pn,sn,tid),p=pn Ulf Leser: Data Warehousing, Vorlesung, SoSe

48 Zusammenfassung bis hier Containment: q v Im allgemeinen schwierig zu zeigen Trivial, wenn q kein Prädikat mehr als einmal enthält Wenn q v Berechnung der Kompensation B für Bedingungen Berechnung der Kompensation J für Joins Wenn B und J existiert, dann: q h(v) B J Ulf Leser: Data Warehousing, Vorlesung, SoSe

49 3.2.3 Ableitbarkeit von Gruppierungen Annahmen q und v haben die Form SELECT G 1, G 2,...,G n, sum(a 1 ),...sum(a n ) FROM... WHERE... GROUP BY G 1, G 2,... G n Ohne Gruppierung / Aggregation gilt: q v Bzw. q h(v) B J G 1,G 2,...,G n sind die Gruppierungsattribute Welche q kann man unter Verwendung eines v (schneller) beantworten? Ulf Leser: Data Warehousing, Vorlesung, SoSe

50 Intuition Sei v SELECT T.year_id, T.month_id, T.day_id, sum(...) FROM Sales S, Time T WHERE... GROUP BY T.year_id, T.month_id, T.day_id Welche Gruppierungen in einer Query q können mit v berechnet werden? Year Month Day SUM Ulf Leser: Data Warehousing, Vorlesung, SoSe

51 Beobachtung In v sind alle Kombinationen von G= {YEAR_ID, MONTH_ID, DAY_ID} mit Summe vorhanden Aufsummierung für jede Untermenge von G möglich SELECT T.year_id, T.month_id, sum(...) FROM v GROUP BY T.year_id, T.month_id SELECT T.year_id, T.day_id, sum(...) FROM v GROUP BY T.year_id, T.day_id Year Month SUM Year Day SUM Ulf Leser: Data Warehousing, Vorlesung, SoSe

52 Orthogonale Gruppierungen Sei v SELECT T.month_id, P.pg_id, R.shop_name, sum(...) FROM Sales S, Time T, Product P, Region R WHERE... GROUP BY T.month_id, P.pg_id, R.shop_name Month PG_ID Shop_ name KB Mitte... KB Mitte... KB Mitte... SUM SELECT P.pg_id, R.shop_name, sum(...) FROM v GROUP BY P.pg_id, R.shop_name SELECT P.month_id, sum(...) FROM v GROUP BY P.month_id Ulf Leser: Data Warehousing, Vorlesung, SoSe

53 Direkte Ableitbarkeit Satz Sei v ein View mit Gruppierungsattributen G v und q eine Query mit Gruppierungsattributen G q und q und v haben äquivalente SPJ Klauseln q ist direkt ableitbar aus v, q 1 v, gdw. G q G v und G q = G v - 1 oder G q = G v \a x a y mit a x G v, a y G v und a y ist funktional abhängig von a x Funktionale Abhängigkeit Foreign Key Constraints Zusicherung wie CREATE DIMENSION... ATTRIBUTE DETERMINES... Ulf Leser: Data Warehousing, Vorlesung, SoSe

54 Direkte Ableitbarkeit Satz q ist ableitbar aus v, q v, gdw. q ist direkt ableitbar aus v oder Es existieren Views v 1...,v n so, dass: q v n... v 1 v Folgerung Jede Untermenge einer Menge von Gruppierungsattributen ist aus dieser ableitbar Ulf Leser: Data Warehousing, Vorlesung, SoSe

55 Ableitbarkeit bei funkt. Abhängigkeiten SELECT T.month_id, P.pg_id, R.shop_name, sum(...) FROM Sales S, Time T, Product P, Region R WHERE... GROUP BY T.month_id, P.pg_id, R.shop_name SELECT T.year_id, P.pg_id, R.shop_name, sum(...) FROM v, Time T WHERE v.month_id = T.month_id GROUP BY T.year_id, P.pg_id, R.shop_name SELECT T.month_id, P.pg_name, R.shop_name FROM v, Product P WHERE v.pg_id = P.pg_id Erfordert Rewriting mit zusätzlichen Joins Eventuell weitere Aggregationen Abh. innerhalb einer Klassifikationssstufe: Keine Agg. Abh. zwischen K-stufen: Agg. entlang der Hierarchie Ulf Leser: Data Warehousing, Vorlesung, SoSe

56 month_id month_id, pg_name Aggregationsgitter () Direkte Ableitbarkeit pg_name shop_name month_id, shop_name pg_name, shop_name month_id, pg_name, shop_name Ableitbarkeit Ulf Leser: Data Warehousing, Vorlesung, SoSe

57 Aggregationsgitter: Verwendung Gegeben eine Menge Z von Queries mit Gruppierung Gesucht: Optimale Menge Z von Views, mit der sich alle Queries berechnen lassen Optimal: Maximale Zeitersparnis Optimal: Minimaler Platzverbrauch/ Aktualisierungszeit Ein(!) mögliches Vorgehen Erstellen des kompletten Aggregationsgitter des Models Markierung der Gruppierungsmengen aus Z Wahl von Z Kleinster gemeinsamer Vorfahr aller Knoten aus Z Hoher Platzverbrauch, da alles aus kleiner Granularität berechnet U.U. hoher Nach-Berechnungsaufwand Menge von Nachkommen, so dass alle Z erreichbar sind U.U. hoher Platzverbrauch, da mehrere Views materialisiert werden Ulf Leser: Data Warehousing, Vorlesung, SoSe

58 4 Klassifikationsstufen () A B C D A,B A,C A,D B,C B,D C,D A,B,C B,C,D A,B,D A,C,D A,B,C,D Ulf Leser: Data Warehousing, Vorlesung, SoSe

59 Auswahlmöglichkeiten Kleinster gemeinsamer Vorfahr Mehrere zur Auswahl Materialisierung mit hoher Granularität Zwei Aggregationen pro Query Menge von Vorfahren Mehrere zur Auswahl Mehrere Materialisierungen zu aktualisieren Eine Aggregation pro Query Ulf Leser: Data Warehousing, Vorlesung, SoSe

60 Platzverbrauch Größe des Aggregationsgitter wächst exponentiell in Anzahl Klassifikationsstufen 2 n mögliche Gruppierungen Identisch zur Anzahl Gruppierungen des CUBE Operators Platzverbrauch einer materialisierten Gruppierung hängt ab von Anzahl Klassifikationsknoten der beteiligten Gruppierungsattribute Durch nicht-speichern der 0-Summen kann Platz gespart werden (... having SUM()!= 0... ) Keine Auswirkung auf abgeleitete Summen Ersparnis abhängig von Füllgrad des Würfels. Bedingt die Wahrscheinlichkeit, dass eine konkrete Kombination von Klassifikationsknoten in der Gruppierung vorhanden ist Ulf Leser: Data Warehousing, Vorlesung, SoSe

61 Viewauswahl Abgeschätzt werden muss Platzverbrauch Aktualisierungskosten für gegebene ETL Prozesse Gewinn für gegebene Workload Verschiedene Algorithmen sind vorgeschlagen worden Optimale Lösungen bilden i.d.r. NP harte/vollständige Probleme Heuristiken (Greedy, Simulated Annealing,...) Literatur Ulf Leser: Data Warehousing, Vorlesung, SoSe

62 Zusammenfassung Ableitbarkeit Feststellung der Ableitbarkeit Im allgemeinsten Fall unentscheidbar NP vollständig schon für sehr eingeschränkte Anfrageklassen (konjunktive Anfragen) Joinableitbarkeit linear für viele Anfragen des täglichen Lebens Gruppierungsableitbarkeit (ohne Having) linear Vorsicht vor nicht-ableitbarer Aggregatfunktionen (z.b: median) Offene Frage Gegeben eine Query q und mehrere materialisierte Views, die zur Ableitung von q dienen können Welcher Views sollen verwendet werden wenn überhaupt? Welcher Ausführungsplan ist am schnellsten? Kostenbasierte Anfrageoptimierung mit MVs Ulf Leser: Data Warehousing, Vorlesung, SoSe

63 Teil 4. Anfrageoptimierung mit MVs ([TCL+00]) Kostenbasierte Anfrageoptimierung Anfrage parsen Aufzählen von Query Execution Plans (QEP) Joinreihenfolge Joinmethode Operatorreihenfolge etc. Bottom-Up Bewertung von Teilplänen Konstruktion vollständiger Pläne aus besten Teilplänen Dynamische Programmierung Ulf Leser: Data Warehousing, Vorlesung, SoSe

64 Anfrageoptimierung mit MVs Wie passen materialisierte Views in dieses Bild? Sketch Materialisierter View ist ein potentieller Teilplan Bei Bottum-Up Konstruktion der Teilpläne auch materialisierte Views berücksichtigen Matching: Gibt es für den aktuellen Teilplan einen / mehrere geeignete MVs? Hinzufügen von Kompensationsoperationen notwendig? Bewertung der Kosten (MV + Kompensation) Auswahl des MV, wenn er zu schnellerer Ausführung führt Ulf Leser: Data Warehousing, Vorlesung, SoSe

65 Beispiel (Snowflakeschema) SELECT Y.year, sum(amount) FROM Sales S, Product P, Days D, Months M, Years Y WHERE P.name= Gerolsteiner AND P.product_id = S.product_id AND T.day_id = D.day_id AND D.month_id = M.id AND M.year_id = Y.id AND Y.year in (1998, 1998, 1999) GROUP BY Y.year CREATE MATERIALIZED VIEW v_time AS SELECT Y.id, Y.year, M.id, M.month, D.id, D.day FROM Year Y, Month M, Day D WHERE Y.id = M.year_id AND M.id = D.month_id Ulf Leser: Data Warehousing, Vorlesung, SoSe

66 Ausführungsplan Query GROUP BY year_id σ year in (1997,1998, 1999) Month Year Day Sales σ p_name= Gerolsteiner' Product Ulf Leser: Data Warehousing, Vorlesung, SoSe

67 Sales Alternativplan GROUP BY year_id Product Year Month Day Ulf Leser: Data Warehousing, Vorlesung, SoSe σ p_name= Gerolsteiner' σ year in (1997,1998, 1999)

68 Alternativen bewerten GROUP BY year_id GROUP BY year_id Sales σ p_name= Gerolsteiner' Product Sales σ p_name= Gerolsteiner' σ year in (...) V_time σ year in (1997,1998, 1999) Product Year Month Day Ulf Leser: Data Warehousing, Vorlesung, SoSe

69 Einschränkungen Matching muss sehr schnell gehen Exponentielle Algorithmen vermeiden I.d.R. werden bei weitem nicht alle Pläne aufgezählt Z.B. nur Left-Deep Joins, nur binäre Joins Gezieltes Suchen nach MVs muss eingebaut werden Matching erkennt nicht alle Fälle Abhängig von Datenbanksystem Beispiele für Einschränkungen Keine Funktionen in Bedingungen Keine Negation Keine Self-joins... Praxis: Test vieler Spezialfälle Ulf Leser: Data Warehousing, Vorlesung, SoSe

70 Teil 5. MVs in Oracle Anlegen von materialisierten Views Aktualisierungstechniken Rewriting mit MV Ulf Leser: Data Warehousing, Vorlesung, SoSe

71 Definition von MVs CREATE MATERIALIZED VIEW product_sales_mv BUILD IMMEDIATE REFRESH FAST ENABLE QUERY REWRITE AS SELECT P.prod_name, SUM(S.amount), COUNT(*) FROM sales S, products P WHERE S.product_id = P.id GROUP BY P.prod_name; Materialisierter View wird als Tabelle angelegt Indexierung, Partitionierung, STORAGE Klauseln, etc. Aktualisierung erfolgt über Trigger und Deltas Query Rewrite muss explizit erlaubt werden Ulf Leser: Data Warehousing, Vorlesung, SoSe

72 Reengineering Materialisierte Views können über existierende Tabellen gelegt werden CREATE MATERIALIZED VIEW sum_sales_tab ON PREBUILT TABLE ENABLE QUERY REWRITE AS... Nachträgliche Benutzung der Rewrite / Aktualisierungsmechanismen Ulf Leser: Data Warehousing, Vorlesung, SoSe

73 Aktualisierungsstrategien Mastertabellen Im MV referenzierte Tabellen Wann wird aktualisiert On Demand Nur bei Aufruf von speziellen Funktionen im Package DBMS_MVIEW On Commit Beim Abschluss von Transaktionen, die mindestens eine Mastertabelle verändern Wie wird aktualisiert COMPLETE Komplette Neuberechnung des Views bei Änderungen an mindestens einer Mastertabelle FAST Inkrementelles Nachführen von Änderungen FORCE Ausführung von FAST, wenn möglich; sonst COMPLETE Ulf Leser: Data Warehousing, Vorlesung, SoSe

74 FAST Refresh Erfordert das explizite Anlegen eines MV Logs CREATE MATERIALIZED VIEW LOG ON sales WITH SEQUENCE, ROWID (prod_id, cust_id, time_id, channel_id, promo_id, quantity_sold, amount_sold) INCLUDING NEW VALUES; Legt Trigger auf Mastertabellen an MV-Log speichert Deltas von Änderungen FAST Refresh spielt diese Deltas in MV ein Diverse Einschränkungen A materialized view log must be present for each detail table. The rowids of all the detail tables must appear... If there are no outer joins, you... If there are outer joins,... Ulf Leser: Data Warehousing, Vorlesung, SoSe

75 Rewrite Methoden Oracle versucht Rewriting auf mehrere Arten Text Match Full Text Match und Partial Text Match Rein syntaktischer Match Groß-/ Kleinschreibung Leerzeichen Reihenfolge von Bedingungen Keine logische Implikation, kein Mapping, etc. General Query Rewrite Nicht anwendbar bei Complex materialized views Unterschiedliche Methoden ja nach Art des MV Viele Einschränkungen - Dokumentation Ulf Leser: Data Warehousing, Vorlesung, SoSe

76 General Query Rewrite Ulf Leser: Data Warehousing, Vorlesung, SoSe

77 Zusammenfassung MVs Hochkomplexes Thema Ultimative Anfragebeschleunigung möglich keinerlei Berechnung mehr Trade-Off zwischen Performancegewinn Platzbedarf, Aktualisierungskosten Query Rewrite in RDBMS funktioniert mit Heuristiken Ulf Leser: Data Warehousing, Vorlesung, SoSe

78 Literatur [TCL+00] Zaharioudakis, M., et al. (2000). "Answering Complex SQL Queries Using Automatic Summary Tables". SIGMOD [BDD+98] Bello, R. G., et al. (1998). "Materialized Views in ORACLE". 24th VLDB [Leh03], Kapitel 7.2, 8.2 [AHV95] Abiteboul, S., Hull, R. and Vianu, V. (1995). "Foundations of Databases". Reading, Massachusetts, Addison-Wesley. Ulf Leser: Data Warehousing, Vorlesung, SoSe