Händler-Datenbank (SQL-Beispiel)/Selektion

aus GlossarWiki, der Glossar-Datenbank der Fachhochschule Augsburg
Wechseln zu:Navigation, Suche

Dieser Artikel erfüllt die GlossarWiki-Qualitätsanforderungen nur teilweise:

Korrektheit: 3
(zu größeren Teilen überprüft)
Umfang: 4
(unwichtige Fakten fehlen)
Quellenangaben: 4
(fast vollständig vorhanden)
Quellenarten: 5
(ausgezeichnet)
Konformität: 5
(ausgezeichnet)

Die nachfolgenden Beispiele können beispielsweise mit SQLite oder PostgreSQL getestet werden. Installieren Sie dazu die zugehörige Händler-Datenbank.

1 Die Selektionsfunktion

Eine Selektionsfunktion entfernt Zeilen (= Tupel) aus einer Tabelle.

In jeder Relationalen Algebra gibt es unendlich viele (üblicherweise abzählbar viele) partielle Selektionsfunktionen.

Es sein [math]b[/math] eine Funktion, die jedem Tupel der Art [math](a_1:v_1, \ldots, a_n:v_n)[/math] einen booleschen Wert (true/[math]\top[/math], false/[math]\bot[/math], unknown/[math]U[/math]) zuweist. Dabei seien [math]a_1, \ldots a_n[/math] Attributnamen und [math]v_1, \ldots v_n[/math] Werte der zugehörigen Domänen [math]D_1, \ldots D_n[/math]. Die Selektionsfunktion

[math]σ_b: R \rightharpoonup R[/math]

überprüft für jedes Tupel [math](a_1:v_1, \ldots, a_n:v_n)[/math] einer Relation [math]r[/math], die nur Tupel dieser Art enthält, ob die Bedingungsfunktion [math]b[/math] für das jeweilige Tupel den Wert true liefert:

[math]b((a_1:v_1, \ldots, a_n:v_n)) = \top[/math]

Ist dies der Fall, so wird das entsprechende Tupel in die Ergebnisrelation eingefügt, anderenfalls wird es „entfernt“.

Für Relationen, die Tupel anderer Bauart enthalten, d. h. andere Attribute oder gleichnamige Attribute mit nicht-kompatiblen Domänen, ist die Selektionsfunktion [math]σ_b[/math] nicht definiert.

2 Beispiele bezüglich der Händler-Datenbank

In SQL muss in der SELECT-Klausel immer eine Projektionsliste angegeben werden, auch wenn gar keine Projektion benötigt wird. Da es in den folgenden Beispielen nur um die Selektion geht (WHERE-Klausel), wird jeweils die Projektionsklausel SELECT * verwendet. In produktivem Code sollte man dies vermeiden und in SELECT-Klausel immer alle benötigten Attribute explizit aufzählen, da sich die Anzahl und die Reihenfolge der Attribute einer Tabelle im Laufe der Zeit ändern kann (Schemaevolution).

2.1 Selektion aller Tupel der Tabelle haendler (Identität)

SELECT *
FROM   haendler
WHERE  true
[math]\texttt{haendler}[/math]→  [math]σ_{\top}(\texttt{haendler})[/math]
h_idh_nameh_ortschaft
1 Maier Königsbrunn
2 Müller Königsbrunn
3 Maier Augsburg
4 Huber NULL
5 Schmidt Hamburg
→  
h_idh_nameh_ortschaft
1 Maier Königsbrunn
2 Müller Königsbrunn
3 Maier Augsburg
4 Huber NULL
5 Schmidt Hamburg

2.2 Selektion von keinem einzigen Tupel der Tabelle haendler

SELECT h_id, h_name, h_ortschaft
FROM   haendler
WHERE  false
SELECT h_id, h_name, h_ortschaft
FROM   haendler
WHERE  null
[math]\texttt{haendler}[/math]→  [math]σ_{\bot}(\texttt{haendler})[/math]
h_idh_nameh_ortschaft
1 Maier Königsbrunn
2 Müller Königsbrunn
3 Maier Augsburg
4 Huber NULL
5 Schmidt Hamburg
→  
h_idh_nameh_ortschaft

2.3 Selektion aller Händler aus Königsbrunn

SELECT *
FROM   haendler
WHERE  h_ortschaft = 'Königsbrunn'
[math]\texttt{haendler}[/math]→  [math]σ_{\texttt{h_ortschaft} = \texttt{'Königsbrunn'}}(\texttt{haendler})[/math]
h_idh_nameh_ortschaft
1 Maier Königsbrunn
2 Müller Königsbrunn
3 Maier Augsburg
4 Huber NULL
5 Schmidt Hamburg
→  
h_idh_nameh_ortschaft
1 Maier Königsbrunn
2 Müller Königsbrunn

2.4 Selektion aller Händler, deren Name mit 'M' beginnt

SELECT *
FROM   haendler
WHERE  h_name LIKE 'M%'
SELECT *
FROM   haendler
WHERE  h_name SIMILAR TO 'M_*'
-- POSIX Regular Expressions (Postgres)
SELECT * 
FROM   haendler
WHERE  h_name ~ '^M'
[math]\texttt{haendler}[/math]→  [math]σ_{\texttt{h_name LIKE 'M%'}}(\texttt{haendler})[/math]
h_idh_nameh_ortschaft
1 Maier Königsbrunn
2 Müller Königsbrunn
3 Maier Augsburg
4 Huber NULL
5 Schmidt Hamburg
→  
h_idh_nameh_ortschaft
1 Maier Königsbrunn
2 Müller Königsbrunn
3 Maier Augsburg

2.5 Selektion aller Händler, die mindestens drei Warenangebote haben

Es ist auch möglich, komplexe Unteranfragen zur Selektion zu verwenden, wenn diese einen booelschen Wert als Ergebnis liefern. Im folgenden Beispiel wird für jeden Händler mittels eine Aggregationsfunktion gezählt,

wie viele Warenangebote er hat, d. h., wie oft seine h_id in der Tabelle liefert vorkommt. Diejenigen Händler, für die dieser

Wert größer oder gleich drei ist, werden in der Ergebnistabelle aufgelistet.

SELECT *
FROM   haendler
WHERE  (SELECT COUNT(*) 
        FROM   liefert
        WHERE  haendler.h_id = liefert.h_id 
       )
       >= 3
[math]\texttt{haendler}[/math]→  [math]σ_{γ_{\texttt{COUNT(*)}}(σ_{\texttt{haendler.h_id} = \texttt{liefert.h_id}}(\texttt{liefert})) \gt 3}(\texttt{haendler})[/math]
h_idh_nameh_ortschaft
1 Maier Königsbrunn
2 Müller Königsbrunn
3 Maier Augsburg
4 Huber NULL
5 Schmidt Hamburg
→  
h_idh_nameh_ortschaft
1 Maier Königsbrunn
2 Müller Königsbrunn
4 Huber NULL

2.6 Selektion aller Händler, deren Ortschaft auf 'burg' endet

SELECT *
FROM   haendler
WHERE  h_ortschaft LIKE '%burg'
SELECT *
FROM   haendler
WHERE  h_ortschaft SIMILAR TO '_*burg'
-- POSIX Regular Expressions (Postgres)
SELECT * 
FROM   haendler
WHERE  h_ortschaft ~ 'burg$'
[math]\texttt{haendler}[/math]→  [math]σ_{\texttt{h_ortschaft LIKE '%burg'}}(\texttt{haendler})[/math]
h_idh_nameh_ortschaft
1 Maier Königsbrunn
2 Müller Königsbrunn
3 Maier Augsburg
4 Huber NULL
5 Schmidt Hamburg
→  
h_idh_nameh_ortschaft
3 Maier Augsburg
5 Schmidt Hamburg

Achtung: Dies ist eine teure Operation, da die Gesamte Händler-Tabelle durchlaufen und jeder Händlername überprüft werden muss. Endtrunkierung sollte grundsätzlich vermieden werden. Stattdessen sollte man einen Volltextindex verwenden, der Endtrunkierung unterstützt.

2.7 Selektion aller liefert-Tupel, bei denen die Lieferzeit bekannt ist

SELECT * 
FROM   liefert 
WHERE  l_lieferzeit IS NOT NULL;
[math]\texttt{liefert}[/math]→  [math]σ_{\texttt{l_lieferzeit IS NOT NULL}}(\texttt{liefert})[/math]
h_id w_id l_preis l_lieferzeit
1 1 200.00 1
1 1 194.00 6
1 2 100.00 NULL
1 3 150.00 7
1 4 10.00 1
1 5 5.00 1
2 1 160.00 NULL
2 1 190.00 1
2 2 180.00 NULL
2 3 170.00 4
3 1 195.00 2
3 2 190.00 1
4 1 150.00 3
4 3 180.00 5
4 3 199.00 1
→  
h_id w_id l_preis l_lieferzeit
1 1 200.00 1
1 1 194.00 6
1 3 150.00 7
1 4 10.00 1
1 5 5.00 1
2 1 190.00 1
2 3 170.00 4
3 1 195.00 2
3 2 190.00 1
4 1 150.00 3
4 3 180.00 5
4 3 199.00 1

2.8 Selektion aller liefert-Tupel, bei denen die Lieferzeit unbekannt ist

SELECT * 
FROM   liefert 
WHERE  l_lieferzeit IS NOT NULL;
[math]\texttt{liefert}[/math]→  [math]σ_{\texttt{l_lieferzeit IS NOT NULL}}(\texttt{liefert})[/math]
h_id w_id l_preis l_lieferzeit
1 1 200.00 1
1 1 194.00 6
1 2 100.00 NULL
1 3 150.00 7
1 4 10.00 1
1 5 5.00 1
2 1 160.00 NULL
2 1 190.00 1
2 2 180.00 NULL
2 3 170.00 4
3 1 195.00 2
3 2 190.00 1
4 1 150.00 3
4 3 180.00 5
4 3 199.00 1
→  
h_id w_id l_preis l_lieferzeit
1 2 100.00 NULL
2 1 160.00 NULL
2 2 180.00 NULL

2.9 Weitere – eher sinnlose – Anfragen an die liefert-Tabelle

Für welche liefert-Tupel ist die Lieferzeit und Händler-ID überein?

SELECT * 
FROM   liefert 
WHERE  h_id = l_lieferzeit;
[math]σ_{\texttt{h_id = l_lieferzeit}}(\texttt{liefert})[/math]
h_id w_id l_preis l_lieferzeit
1 1 200.00 1
1 4 10.00 1
1 5 5.00 1

Für welche liefert-Tupel ist unbekannt, ob die Lieferzeit und Händler-ID übereinstimmen?

SELECT * 
FROM   liefert 
WHERE  (h_id = l_lieferzeit) IS UNKNOWN;
[math]σ_{\texttt{(h_id = l_lieferzeit) IS UNKNOWN}}(\texttt{liefert})[/math]
h_id w_id l_preis l_lieferzeit
1 2 100.00 NULL
2 1 160.00 NULL
2 2 180.00 NULL

Man kann Selektionsbedingungen auch in die Select-Klausel an Stelle der Where-Klausel schreiben. Dann erfolgt allerdings keine Selektion, sondern die Testergebnise werden als zusätzliche Attribute ausgegeben.

SELECT h_id, w_id, l_preis, l_lieferzeit,
       (h_id=w_id AND l_preis > l_lieferzeit) AS "h_id=w_id AND l_preis > l_lieferzeit",
       (h_id=w_id OR  l_preis > l_lieferzeit) AS "h_id=w_id OR  l_preis > l_lieferzeit",
       (h_id=w_id OR  l_preis < l_lieferzeit) AS "h_id=w_id OR  l_preis < l_lieferzeit"
FROM   liefert
[math]π_{\texttt{h_id},\, \texttt{w_id}, \texttt{l_preis},\, \texttt{l_lieferzeit},\, \texttt{h_id=w_id AND l_preis} \gt \texttt{l_lieferzeit AS "h_id=w_id AND l_preis} \gt \texttt{l_lieferzeit"},\, \ldots}(\texttt{liefert})[/math]
h_id w_id l_preis l_lieferzeit h_id=w_id AND
l_preis > l_lieferzeit
h_id=w_id OR
l_preis > l_lieferzeit
h_id=w_id OR
l_preis < l_lieferzeit
1 1 200.00 1 truetruetrue
1 1 194.00 6 truetruetrue
1 2 100.00 NULLfalseNULLNULL
1 3 150.00 7 falsetruefalse
1 4 10.00 1 falsetruefalse
1 5 5.00 1 falsetruefalse
2 1 160.00 NULL falseNULLNULL
2 1 190.00 1 falsetruefalse
2 2 180.00 NULL NULLtruetrue
2 3 170.00 4 falsetruefalse
3 1 195.00 2 falsetruefalse
3 2 190.00 1 falsetruefalse
4 1 150.00 3 falsetruefalse
4 3 180.00 5 falsetruefalse
4 3 199.00 1 falsetruefalse

Für welche liefert-Tupel ist die Lieferzeit gleich (=) NULL?

SELECT * 
FROM   liefert 
WHERE   l_lieferzeit =  NULL; -- an Stelle von l_lieferzeit IS  NULL
[math]σ_{\texttt{ l_lieferzeit = NULL}}(\texttt{liefert})[/math]
h_id w_id l_preis l_lieferzeit

Der Test auf Gleicheit eines Wertes mit NULL liefert stets den Wert UNKNOWN. Daher ist das Ergebnis der Anfrage leer. Korrekt wäre der Test l_lieferzeit IS NULL.

2.10 Noch einmal Tests mit NULL

Fehlerhafter Test = NULL:

SELECT 1 AS ergebnis
WHERE  5 + NULL =  NULL;
[math]\texttt{leere_tabelle}[/math]→  [math]σ_{\bot}(\texttt{haendler})[/math]
→  
ergebnis

Korrekter Test IS NULL:

SELECT 1 AS ergebnis
WHERE  5 + NULL IS  NULL;
[math]\texttt{leere_tabelle}[/math]→  [math]σ_{\bot}(\texttt{haendler})[/math]
→  
ergebnis
1

Diese Anfragen sind nicht standard-konform, werden aber sowohl von Postgres als auch von SQLite unterstützt. Laut SQL-Standard muss eine Select-Anweisung eine From-Klausel enthalten.[1] Das heißt, müsste man eine Tabelle (z. B. mit Namen one) definieren, die genau Zeile enthält, und in diese beiden Queries eine passende FROM-Klausel (z. B. FROM one) einfügen.

3 Quellen

  1. DIS 9075-2 (2014): DIS 9075-2:2014(E) – Information technology — Database languages — SQL — Part 2:Foundation (SQL/Foundation); Organisation: Internationale Organisation für Normung (ISO); Web-Link; 2014; Quellengüte: 4 (Technischer Bericht), <query specification>, S. 476, <table expression>, S. 390
  1. Kowarschick (MMDB-Skript): Wolfgang Kowarschick; Vorlesung Multimedia-Datenbanksysteme – Sommersemester 2018; Hochschule: Hochschule Augsburg; Adresse: Augsburg; Web-Link; 2018; Quellengüte: 4 (Skript)
  2. Kowarschick (MMDB): Wolfgang Kowarschick; Vorlesung „Multimedia-Datenbanksysteme“; Hochschule: Hochschule Augsburg; Adresse: Augsburg; Web-Link; 2016; Quellengüte: 3 (Vorlesung), https://kowa.hs-augsburg.de/mmdb/mmdb-beispiele/haendler-datenbank/

4 Siehe auch