Referent : Axel SchönSeminar : Benutzerzentrierte Datenbankanfragen

(1)

Seminar : Benutzerzentrierte Datenbankanfragen

(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

New York

London

Paris

Sonstige Level1

(max. Werte)

Level 3 Level 2

Level 4 (andere Werte)

(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)

„hart“ „weich“

„hartes“ Kriterium „weiches“ Kriterium Notwendigkeit ^MÜSSENerfüllt sein SOLLTENerfüllt sein

Kriterien komplett erfüllt exaktes Ergebnis

(„exact-match“) exaktes Ergebnis +

Annäherndes Ergebnis

Kriterien nicht komplett

erfüllt kein Ergebnis

Schlüsselwort ^WHERE ^PREFERRING

(10)

„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

SELECT * FROM reise

PREFERRING dauer AROUND 14;

ziel dauer

New York 14

Prag 7

London 7

Barcelona 16

London 12

Paris 10

(13)

Beispiel : AROUND

SELECT * FROM reise

Beispiel : BETWEEN

SELECT * FROM reise

PREFERRING dauer BETWEEN 12 AND 16;

ziel dauer

New York 14

Prag 7

London 7

Barcelona 16

London 12

Paris 10

(14)

Beispiel : AROUND

SELECT * FROM reise

Beispiel : BETWEEN

SELECT * FROM reise

Beispiel : LOWEST

SELECT * FROM reise

PREFERRING LOWEST(preis);

ziel preis

New York 700

Prag 300

Barcelona 350

London 450

Paris 450

(15)

Beispiel : AROUND

SELECT * FROM reise

Beispiel : BETWEEN

SELECT * FROM reise

Beispiel : LOWEST

SELECT * FROM reise

PREFERRING LOWEST(preis);

Beispiel : HIGHEST

SELECT * FROM reise

ziel preis

New York 700

Prag 300

Barcelona 350

London 450

Paris 450

(16)

Nicht-numerische Präferenz-Konstruktoren :

Beispiel : POS

SELECT * FROM reise

PREFERRING ziel = ‘New York‘;

Ziel dauer

New York 14

Prag 7

London 7

Barcelona 16

London 12

Paris 10

(17)

Beispiel : POS

SELECT * FROM reise

Beispiel : NEG

SELECT * FROM reise

PREFERRING ziel <> ‘Prag‘;

Ziel dauer

New York 14

Prag 7

London 7

Barcelona 16

London 12

Paris 10

(18)

Beispiel : POS

SELECT * FROM reise

Beispiel : NEG

SELECT * FROM reise

PREFERRING ziel <> ‘Prag‘;

Beispiel : POS/NEG

SELECT * FROM reise

PREFERRING ziel = ‘New York‘

ELSE ziel <> ‘Prag‘;

Ziel dauer

New York 14

Prag 7

London 7

Barcelona 16

London 12

Paris 10

(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 :

SELECT * FROM reise

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 :

SELECT * FROM reise

Ergebnis :

Berlin / Frankfurt (Level 2) Hannover (Level 1) 0

1 2 3 4 5 6 7

Ziel Dauer Abflugort New York 10 Hannover New York 14 Frankfurt Barcelona 16 Hannover

Rom 12 Berlin

New York 7 Hannover

(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 :

SELECT * FROM reise

PREFERRING ( ziel = ‘New York‘

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

ELSE ziel = ‘London‘

Ergebnis : Pareto-optimale Menge

Ziel dauer

New York 14

Prag 7

London 7

Barcelona 16

London 12

Paris 10

ziel dauer level distanz

New York 14 1 0

London 12 2 2

Barcelona 16 3 2

(24)

Qualitätskontrolle:

• mit BUT ONLY kann man die Ergebnisse einschränken/kontrollieren

Beispiel :

SELECT * FROM reise

AND dauer AROUND 14

BUT ONLY DISTANCE(dauer) <= 2;

ziel dauer

New York 14 New York 7 Barcelona 15

(25)

Qualitätskontrolle:

• mit BUT ONLY kann man die Ergebnisse einschränken/kontrollieren

Beispiel : Ergebnis :

SELECT * FROM reise

AND dauer AROUND 14

BUT ONLY DISTANCE(dauer) <= 2;

ziel dauer

New York 14 New York 7 Barcelona 15

Rom 12

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 }

Indifferenz :

r : Instanz eines

relationalen Schemas R P : Präferenzrelation

(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 ≻_P1y) ∧ (x ≻_P2y)

≻_P0 = ≻_P1 ∪ ≻_P2 x ≻_P0 y ≡ (x ≻_P1y) ∨ (x ≻_P2y)

≻_P0 = ≻_P1 ‒ ≻_P2 x≻_P0 y ≡ (x ≻_P1y) ‒ (x ≻_P2 y)

• Priorisierte : ≻_P1,2= ≻_P1 ⊳ ≻_P2

x ≻_P1,2y ≡ (x ≻_P1 y) ∨ [(x ∼_P1y) ∧ (x ≻_P2y)]

(30)

Beispiel : Winnow-Operator

• relationales Schema R : Reise(Ziel, Dauer, Preis)

• Präferenz-Relation P1: (z, d, p) ≻_P1 (z`, d`, p`) ≡ z = z` ∧ d = d` ∧ p < p`

Ziel Dauer Preis

New York 7 700

New York 7 500

Barcelona 14 800

Rom 12 700

New York 7 600

(31)

Beispiel : Winnow-Operator

• relationales Schema R : Reise(Ziel, Dauer, Preis)

• Präferenz-Relation P1: (z, d, p) ≻_P1 (z`, d`, p`) ≡ z = z` ∧ d = d` ∧ p < p`

• Ergebnis der Anfrage : ω_P1(Reise)

New York 7 700

New York 7 500

Barcelona 14 800

Rom 12 700

New York 7 600

New York 7 500

Barcelona 14 800

Rom 12 700

(32)

• Ergebnis der Anfrage : ω_P1²(Reise) • Ergebnis der Anfrage : ω_P1³(Reise)

liefert ZWEITbestes Ergebnis liefert DRITTbestes Ergebnis

Iteratives Ranking :

• durch iteratives verschachteln des Winnow-Operators, ist Ranking möglich ω_P¹(r) = ω_P(r)

ω_Pⁿ(r) = ω_P(r ‒ ω_P²(r ‒ ω_P³(r ‒ … ) ) )

Beispiel : (siehe Beispiel Winnow-Operator)

New York 7 600

New York 7 700

(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

(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

(39)

D

ANKE FÜR EURE

A

UFMERKSAMKEIT