SQL-Grundlagen

01

Relationale Datenbanken und SELECT-Grundlagen

Die Begriffe relationaler Datenbanken

Eine relationale Datenbank speichert Daten in Tabellen (aus Zeilen und Spalten) und verknüpft Tabellen über Schlüsselwerte. In der Theorie heißen dieselben Dinge anders, deshalb lohnt es sich, die Paare zu kennen.

Relationen haben feste Eigenschaften: Es kann keine zwei identischen Tupel geben, weder Tupel noch Attribute haben eine Reihenfolge, und jeder Wert ist atomar, lässt sich also nicht weiter zerlegen.

Auch bei den Schlüsseln gibt es verschiedene Arten.

Die Regeln, die dafür sorgen, dass die Daten immer korrekt bleiben, heißen Integritätsbedingungen. Die wichtigsten sind die Entitätsintegrität (ein Primärschlüssel darf weder NULL noch doppelt sein), die referenzielle Integrität (ein Fremdschlüsselwert muss in der referenzierten Tabelle vorkommen oder NULL sein) und die Domänenintegrität (ein Spaltenwert muss in seiner festgelegten Domäne liegen).

Die theoretischen Operationen relationaler Datenbanken heißen Relationenalgebra. So passen die Teile von SQL zu diesen Operationen:

Die vier Arten von SQL-Anweisungen

SELECT und WHERE

Das Grundgerüst von SELECT sieht so aus:

SELECT [DISTINCT] spalte [AS alias], ...
FROM   tabelle
WHERE  bedingung
ORDER BY spalte [ASC | DESC];

• DISTINCT entfernt doppelte Zeilen aus dem Ergebnis (als doppelt gilt eine Zeile nur, wenn die ganze SELECT-Liste gleich ist)
• Einen Alias vergibst du mit AS; enthält er Leerzeichen oder Sonderzeichen, setzt du ihn in doppelte Anführungszeichen
• Zum Verketten von Zeichenketten nutzt Oracle || und SQL Server + (die Funktion CONCAT gibt es in beiden)

Diese Operatoren verwendest du in WHERE:

Verknüpfst du mehrere Bedingungen, gibt es eine Rangfolge. Laut Oracle-Dokumentation gilt: Klammern → Vergleichsoperatoren → NOT → AND → OR. AND kommt vor OR, deshalb wird A OR B AND C als A OR (B AND C) ausgewertet. Wenn du dir unsicher bist, setz lieber Klammern.

ORDER BY: Sortieren und wohin NULL kommt

ORDER BY sortiert standardmäßig aufsteigend (ASC), und du kannst nach Spaltenname, Alias oder der Position in der SELECT-Liste (1, 2 …) sortieren. Unterschiede gibt es bei NULL: Oracle behandelt NULL als größten Wert und setzt es bei aufsteigender Sortierung ans Ende, SQL Server als kleinsten Wert und setzt es an den Anfang. In Oracle kannst du die Position mit NULLS FIRST bzw. NULLS LAST selbst festlegen.

In welcher Reihenfolge eine SELECT-Anweisung verarbeitet wird

Eine SELECT-Anweisung wird nicht in der Reihenfolge verarbeitet, in der sie geschrieben ist. Wenn du diese Reihenfolge kennst, beantworten sich Fragen wie „Warum kann ich in WHERE keinen Alias verwenden?“ oder „Warum geht SUM nicht in WHERE?“ auf einen Schlag. Geh in der Grafik unten die Schritte durch.

SELECT   DEPT_CODE, SUM(SALARY) AS TOTAL
▶FROM     EMP
WHERE    SALARY >= 260
GROUP BY DEPT_CODE
HAVING   SUM(SALARY) >= 280
ORDER BY TOTAL DESC;

Zusammengefasst: FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY. Der Alias entsteht erst in SELECT, deshalb kannst du ihn nur im danach folgenden ORDER BY verwenden.

02

Funktionen und GROUP BY / HAVING

Mit SELECT hast du Spalten geholt. Jetzt bearbeitest du Werte (Funktionen) und fasst sie zusammen (GROUP BY).

Einzeilenfunktionen: ein Wert pro Zeile

Es gibt zwei Arten von Funktionen: Einzeilenfunktionen, die für jede Zeile genau ein Ergebnis liefern, und Mehrzeilenfunktionen (Aggregatfunktionen), die mehrere Zeilen zu einem einzigen Ergebnis zusammenfassen. Einzeilenfunktionen kannst du überall verwenden – in SELECT, WHERE und ORDER BY –, und du kannst Funktionen auch ineinander verschachteln.

Addierst du in Oracle eine Zahl zu einem Datum, wird in Tagen gerechnet: HIRE_DATE + 1 ist der nächste Tag, HIRE_DATE + 1/24 eine Stunde später. Und noch etwas: Oracle behandelt eine leere Zeichenkette (‘’) als NULL, während SQL Server zwischen leerer Zeichenkette und NULL unterscheidet.

Typkonvertierung und CASE

Datentypen lassen sich auf zwei Arten umwandeln: per expliziter Konvertierung, bei der du selbst eine Funktion aufrufst (Oracle: TO_CHAR, TO_NUMBER, TO_DATE; SQL Server: CAST, CONVERT), und per impliziter Konvertierung, bei der die Datenbank das von sich aus erledigt. Implizite Konvertierung ist bequem, kann aber anders umwandeln als erwartet oder verhindern, dass ein Index genutzt wird. Gewöhn dir deshalb an, explizit zu konvertieren.

Soll je nach Bedingung ein anderer Wert herauskommen, verwendest du CASE. Es gibt den einfachen CASE-Ausdruck, der mit einem einzelnen Wert vergleicht, und den gesuchten CASE-Ausdruck mit Bedingungen. Oracle hat außerdem die Funktion DECODE, die dasselbe erledigt.

SELECT NAME,
       CASE WHEN SALARY >= 350 THEN 'High'
            WHEN SALARY >= 280 THEN 'Mid'
            ELSE 'Low' END AS GRADE,       -- ohne ELSE: NULL
       DECODE(DEPT_CODE, 'D10', 'Vertrieb', 'D20', 'Entwicklung', 'Sonstige') AS DEPT_NAME
FROM   EMP;

Funktionen für NULL

Aggregatfunktionen und NULL

Aggregatfunktionen wie COUNT, SUM, AVG, MAX und MIN fassen mehrere Zeilen zu einem einzigen Wert zusammen. Merk dir eine Regel: Alle außer COUNT(*) ignorieren NULL. Wechsle in der Grafik unten die Funktion.

Steht DISTINCT in einer Aggregatfunktion, wird jeder Wert nur einmal gezählt (COUNT(DISTINCT DEPT_CODE)). Erfüllt keine einzige Zeile die Bedingung, liefert COUNT 0, während SUM, AVG, MAX und MIN NULL zurückgeben.

GROUP BY und HAVING

GROUP BY fasst Zeilen mit gleichen Werten zusammen und aggregiert pro Gruppe. Danach gibt es pro Gruppe nur noch eine Zeile, und daraus ergeben sich ein paar Regeln:

• Jede Spalte in der SELECT-Liste, die nicht in einer Aggregatfunktion steht, muss auch in GROUP BY stehen
• In GROUP BY verwendest du keine SELECT-Aliase – laut Verarbeitungsreihenfolge gibt es den Alias da noch nicht (das neueste Oracle 23ai erlaubt es zwar, Prüfungen gehen aber von der klassischen Regel aus)
• Auch NULL bildet eine eigene Gruppe
• GROUP BY garantiert keine Sortierung – brauchst du eine Reihenfolge, nimm ORDER BY

Bedingungen für Gruppen schreibst du in HAVING. WHERE filtert Zeilen, bevor gruppiert wird, HAVING filtert Gruppen danach. Deshalb gehören Bedingungen mit Aggregatfunktionen nur in HAVING. Braucht eine Bedingung keine Aggregatfunktion, filterst du besser schon in WHERE – dann müssen weniger Zeilen verarbeitet werden.

SELECT   DEPT_CODE, COUNT(*) AS HEADCOUNT, AVG(SALARY) AS AVG_SAL
FROM     EMP
WHERE    SALARY >= 250          -- zuerst Zeilen filtern
GROUP BY DEPT_CODE
HAVING   COUNT(*) >= 2;         -- nach dem Gruppieren Gruppen filtern