Seminar : Benutzerzentrierte Datenbankanfragen. Referent : Axel Schön

Transkript

1

2 Kapitel 1 : Prolog Kapitel 2 : Preference SQL Kapitel 3 : Chomicki Framework Kapitel 4 : Epilog

3

4 Was sind präferenzgestützte Datenbankanfragen? Beispiel: Familie Vielflieger will in den Urlaub fliegen sie haben genaue Vorstellungen (Abflugdatum, Reiseziel, Reisedauer) Problem: Datenbankanfrage liefert kein Ergebnis zu spezielle Wünsche Lösung: Einbindung von ungefähren Präferenzen / Kriterien liefert bestmögliches, annäherndes Ergebnis benutzerfreundlichere Suche

5 Preference SQL & Chomicki Framework gleiche math. Grundlage Ausdruck der Präferenzrelation P : P(x,y) = x P y x ist besser als y oder x dominiert y strikt partielle Ordnung : Diese Ordnung ist erfüllt, wenn P irreflexiv : x. x x transitiv : x, y, z. (x y y z) x z ist. Dadurch ist sie auch zwangsläufig asymmetrisch : x, y. x y y x

6 Der besser als -Graph : Bsp.: Reiseziel Level 1 (max. Werte) New York Level 2 London Level 3 Paris Level 4 (andere Werte) Sonstige Sonstige Frankfurt Hannover Level 3 Level 2 Level 1 Abflugort

7

8 Preference SQL = Standard SQL + Präferenzen Standard SQL ermöglicht es nicht Präferenzen direkt zu spezifizieren lediglich exakte (harte) Kriterien können eingebunden werden Benutzer muss wie die Datenbank denken Preference SQL ermöglicht erst tolerantere (weiche) Kriterien normale Benutzer drücken sich lieber erklärend statt präzise aus handelt nach dem Best Matches Only -Prinzip

9 Preference SQL = Standard SQL + Präferenzen hart weich hartes Kriterium weiches Kriterium Notwendigkeit MÜSSEN erfüllt sein SOLLTEN erfüllt sein Kriterien komplett erfüllt Kriterien nicht komplett erfüllt exaktes Ergebnis ( exact-match ) kein Ergebnis exaktes Ergebnis + Annäherndes Ergebnis Schlüsselwort WHERE PREFERRING

10 Preference SQL = Standard SQL + Präferenzen hart weich Beispiel : hartes Kriterium SELECT * FROM reise WHERE ziel = New York ; Beispiel : weiches Kriterium SELECT * FROM reise PREFERRING ziel...

11 Präferenz-Konstruktoren : Numerische Konstruktoren : AROUND BETWEEN LOWEST HIGHEST Nicht-numerische Konstruktoren : POS NEG POS/POS NEG/NEG POS/NEG EXPLICIT

12 Numerische Präferenz-Konstruktoren : Beispiel : AROUND PREFERRING dauer AROUND 14; ziel dauer New York 14 Prag 7 London 7 Barcelona 16 London 12 Paris 10

13 Numerische Präferenz-Konstruktoren : Beispiel : AROUND PREFERRING dauer AROUND 14; Beispiel : BETWEEN PREFERRING dauer BETWEEN 12 AND 16; ziel dauer New York 14 Prag 7 London 7 Barcelona 16 London 12 Paris 10

14 Numerische Präferenz-Konstruktoren : Beispiel : AROUND PREFERRING dauer AROUND 14; Beispiel : BETWEEN PREFERRING dauer BETWEEN 12 AND 16; ziel preis New York 700 Prag 300 Barcelona 350 London 450 Paris 450 Beispiel : LOWEST PREFERRING LOWEST(preis);

15 Numerische Präferenz-Konstruktoren : Beispiel : AROUND PREFERRING dauer AROUND 14; Beispiel : BETWEEN PREFERRING dauer BETWEEN 12 AND 16; ziel preis New York 700 Prag 300 Barcelona 350 London 450 Paris 450 Beispiel : LOWEST PREFERRING LOWEST(preis); Beispiel : HIGHEST PREFERRING HIGHEST(preis);

16 Nicht-numerische Präferenz-Konstruktoren : Beispiel : POS PREFERRING ziel = New York ; Ziel dauer New York 14 Prag 7 London 7 Barcelona 16 London 12 Paris 10

17 Nicht-numerische Präferenz-Konstruktoren : Beispiel : POS PREFERRING ziel = New York ; Beispiel : NEG PREFERRING ziel <> Prag ; Ziel dauer New York 14 Prag 7 London 7 Barcelona 16 London 12 Paris 10

18 Nicht-numerische Präferenz-Konstruktoren : Beispiel : POS PREFERRING ziel = New York ; Beispiel : NEG PREFERRING ziel <> Prag ; Ziel dauer New York 14 Prag 7 London 7 Barcelona 16 London 12 Paris 10 Beispiel : POS/NEG PREFERRING ziel = New York ELSE ziel <> Prag ;

19 Aufbau komplexer Präferenzen : Gleiche Priorität : Pareto Akkumulation (AND) alle Präferenzen weisen die gleiche Priorität auf maximale Werte von Präferenzen heißen Pareto-optimale Menge Beispiel : PREFERRING ziel = New York AND abflugort = Hannover AND dauer AROUND 14; Ziel Dauer Abflugort New York 10 Hannover New York 14 Frankfurt Barcelona 16 Hannover Rom 12 Berlin New York 7 Hannover

20 Beispiel : PREFERRING ziel = New York AND abflugort = Hannover AND dauer AROUND 14; Ergebnis : 0 Ziel Dauer Abflugort New York 10 Hannover New York 14 Frankfurt Barcelona 16 Hannover Rom 12 Berlin New York 7 Hannover Hannover (Level 1) Berlin / Frankfurt (Level 2) New York (Level 1) Barcelona / Rom (Level 2)

21 Aufbau komplexer Präferenzen : Geordnete Priorität : hintereinandergeschaltete Präferenzen (CASCADE) jede Präferenz weist ein anderes Level an Priorität auf 1. Präferenz höchste Priorität n. Präferenz niedrigste Priorität Beispiel : PREFERRING ( ziel = New York AND abflugort = Hannover AND dauer AROUND 14) CASCADE preis AROUND 1000 CASCADE veranstalter IN ( Tui, Neckermann );

22 Ein Tupel in der Ergebnismenge spricht nicht nur für seine Qualität, sondern auch für die seiner Konkurrenten. Qualitätsfunktionen : TOP (Präferenz) : Boolean-Aussage für das beste Ergebnis LEVEL (Präferenz) : Level-Aussage für dieses Ergebnis gegenüber des besten Ergebnisses (nicht-numerisch) DISTANCE (Präferenz) : Abstand-Aussage für dieses Ergebnis gegenüber des besten Ergebnisses (numerisch)

23 Beispiel : LEVEL/DISTANCE SELECT ziel, dauer, LEVEL(ziel), DISTANCE(dauer) FROM reise PREFERRING ziel = New York ELSE ziel = London AND dauer AROUND 14; Ziel dauer New York 14 Prag 7 London 7 Barcelona 16 London 12 Paris 10 Ergebnis : Pareto-optimale Menge ziel dauer level distanz New York London Barcelona

24 Qualitätskontrolle: mit BUT ONLY kann man die Ergebnisse einschränken/kontrollieren Beispiel : PREFERRING ziel = New York AND dauer AROUND 14 BUT ONLY DISTANCE(dauer) <= 2; ziel dauer New York 14 New York 7 Barcelona 15 Rom 12 New York 7

25 Qualitätskontrolle: mit BUT ONLY kann man die Ergebnisse einschränken/kontrollieren Beispiel : Ergebnis : PREFERRING ziel = New York AND dauer AROUND 14 BUT ONLY DISTANCE(dauer) <= 2; ziel dauer New York 14 New York 7 Barcelona 15 Rom 12 New York 7 ziel dauer New York 14 Barcelona 15 Rom 12

26 Implementierung : integriert zwischen Applikation und SQL Datenbank : 1. Preference ODBC/JDBC übersetzt Preference SQL in Standard SQL (SQL 92) 2. Preference SQL Optimizer optimiert die Anfrage nach BMO 3. Standard ODBC/JDBC optimiert die Anfrage ein 2. Mal und leitet sie an Datenbank weiter Anfragen ohne Preference SQL werden sofort an Datenbank weitergeleitet

27

28 Framework : logischer Aufbau für die Formulierung von Präferenzen als Präferenz Formeln Einbettung von Präferenzen in relationale Algebra durch einen Winnow-Operator, der eine Präferenz als Parameter besitzt Zur Erinnerung : Präferenz P P(x,y) = x P y Winnow-Operator : ω P (r) = { x r y r. y P x } r : Instanz eines relationalen Schemas R P : Präferenzrelation Indifferenz : Wenn x = y, gilt : P(x,y) = x P y (Gleiche Priorität)

29 Komplexe Präferenzen : Zwei Wege der Zusammensetzung: Unidimensional Präferenz-Relationen über EINE Datenbank Multidimensional Präferenz-Relation über MEHRERE Datenbanken Sorten : Boolesche : P0 = P1 P2 x P0 y (x P1 y) (x P2 y) P0 = P1 P2 x P0 y (x P1 y) (x P2 y) P0 = P1 P2 x P0 y (x P1 y) (x P2 y) Priorisierte : P1,2 = P1 P2 x P1,2 y (x P1 y) [(x P1 y) (x P2 y)]

30 Beispiel : Winnow-Operator relationales Schema R : Reise(Ziel, Dauer, Preis) Ziel Dauer Preis New York New York Barcelona Rom New York Präferenz-Relation P1: (z, d, p) P1 (z`, d`, p`) z = z` d = d` p < p`

31 Beispiel : Winnow-Operator relationales Schema R : Reise(Ziel, Dauer, Preis) Ziel Dauer Preis New York New York Barcelona Rom New York Präferenz-Relation P1: (z, d, p) P1 (z`, d`, p`) z = z` d = d` p < p` Ergebnis der Anfrage : ω P1 (Reise) Ziel Dauer Preis New York Barcelona Rom

32 Iteratives Ranking : durch iteratives verschachteln des Winnow-Operators, ist Ranking möglich ω 1 P (r) = ωp (r) ω n P (r) = ωp (r ω 2 P (r ωp 3 (r ) ) ) Beispiel : (siehe Beispiel Winnow-Operator) Ergebnis der Anfrage : ω P1 2 (Reise) Ziel Dauer Preis New York liefert ZWEITbestes Ergebnis Ergebnis der Anfrage : ωp1 3 (Reise) Ziel Dauer Preis New York liefert DRITTbestes Ergebnis Ranking-Operator : η P (r) = { (x, n) x ω P n (r) }

33 Winnow-Auswertung : Drei Algorithmen : Nested Loops (NL) : 1. schaltet zwei Schleifen mit je einer Relation ineinander 2. vergleicht so jedes Tupel der äußeren Relation R einmal mit jedem Tupel der inneren Relation S 3. die dominierenden / unvergleichbaren Tupel kommen in die Ergebnismenge Blocked Nested Loops (BNL) : Abwandlung von NL vergleicht hier die kompletten Blöcke (n-tupel) der Relationen geringerer Zeitaufwand und Speicherplatz benötigt, weil weniger Vergleiche Sort-Filter-Skyline (SFS) : Abwandlung von BNL vor Beginn von BNL wird die äußere Relation R topologisch sortiert

34

35 Gemeinsamkeiten : mathematische Grundlage komplexe Präferenzen Auswertung der der Präferenzrelationen Unterschiede : Aufbau des Systems : Preference SQL : arbeitet eng mit SQL Standard zusammen Chomicki : lediglich theoretisch nach logischen Gesetzen aufgebaut Ranking : Preference SQL : nur über Umwege möglich Chomicki : iterativ möglich

36 Preference SQL Chomicki Framework Benutzerfreundlichkeit ++ Praxisnähe ++ Flexibilität + ++ Integrationsmöglichkeit o +

37 Familie Vielflieger will : nicht in technische Details involviert werden benutzerfreundliche Systeme eine Auswahl an guten Ergebnissen nach ihren Vorlieben Ergebnisse Unternehmen : müssen sich nach den Kunden (wie den Vielfliegers) richten

38 Familie Vielflieger will : nicht in technische Details involviert werden benutzerfreundliche Systeme eine Auswahl an guten Ergebnissen Ergebnisse nach ihren Vorlieben Unternehmen : müssen sich nach den Kunden (wie den Vielfliegers) richten DENN

39 DANKE FÜR EURE AUFMERKSAMKEIT