SQLite - SQL Wortschatz und SQL Syntax

Der in SQLite umgesetzte SQL-Sprachstandard basiert auf der internationalen Norm SQL-92 .  Wie andere Datenbanksysteme auch, die SQL-92 umsetzen, realisiert SQLite nur einen Teil dieses Sprachstandards. Einer der möglichen Gründe dafür ist, dass durch SQL-92, entsprechend der Möglichkeiten von SQL, der SQL-Sprachstandard umfassend definiert ist und SQLite selbst von der Intention her nicht diesen kompletten Sprachumfang bietet. Der SQL-Wortschatz und die SQL-Syntax, soweit in SQLite vorhanden, halten sich aber an die Norm SQL-92. Genau das ist mit der Aussage "SQLite setzt eine Untermenge des SQL-92 Sprachstandards um" gemeint.

Schlüsselwörter und Kommandos

Zunächst einmal sollte man sich einen Überblick über die in SQLite verfügbaren SQL-Schlüsselwörter verschaffen, denn diese bilden in ihrer Gesamtheit den Wortschatz von SQLite. Es gibt darin auch einige leichte Abweichungen gegnüber dem SQL-92 Sprachstandard, die aus Kompatibilitätsgründen zu anderen Datenbanksystemen zusätzlich in SQLite eingeführt worden sind. Aus den Schlüsselwörtern werden die SQL-Kommandos gebildet, also Sätze in der Sprache SQL.

Die SQLite-Referenz

Wie man aus dem Wortschatz einer Sprache gültige Sätze baut, ist ja bekanntlich durch die Syntax dieser Sprache festgelegt. Die SQL-Syntax in SQLite wird innerhalb der SQLite-Referenz mittels Syntaxdiagrammen beschrieben. Nachfolgend wird deshalb kurz der Umgang mit diesen Syntaxdiagrammen erläutert:

Wie Syntaxdiagramme gelesen werden

Ein Syntaxdiagramm wird von links nach rechts gelesen. Es gibt  genau einen Einstriegspunkt  und genau einen Ausstiegspunkt pro Diagramm, repräsentiert durch jeweils einen kleinen Kreisring entsprechend auf der linken bzw. rechten Seite des Diagramms. Ausgehend vom Einstiegspunkt auf der linken Seite des Diagramms trifft man zunächst auf eine Linie, die man mit einer "Einbahnstrasse" vergleichen kann. Die erlaubte "Fahrtrichtung" wird durch einen kleinen Pfeil auf bzw. am Ende dieser Linie angezeigt. Die "Fahrt" entgegengesetzt der erlaubten "Fahrtrichtung" ist grundsätzlich verboten ;-), weshalb auf manchen Linien die Richtungsanzeige  einfach weggelassen wird, wenn die erlaubte Fahrtrichtung auch ohne diese offensichtlich ist.  Soweit es möglich ist, kann man diese "Einbahnstrassen" befahren, solange man will, jedoch muss  das Diagramm letztlich über den Ausstiegspunkt  am rechten Diagrammrand verlassen werden, wenn die ganze "Fahrerei" einen Sinn ergeben soll. Es soll nicht unerwähnt bleiben, dass in einem Syntaxdiagramm "absolutes Halteverbot" besteht. Wenn man anhalten will, dann muss man das Diagramm zwangsläufig verlassen.

Auf dem Weg durch dieses "Einbahnstrassensystem" fährt man ab und an durch einen grossen Kreisring bzw.  durch ein Rechteck, dessen rechte und linke Seite  jeweils durch einen halben Kreisring gebildet werden. Die innerhalb dieser geometrischen Symbole stehenden Zeichen sind während der "Durchfahrt" durch das Symbol genauso aufzuschreiben ( auf ein Stück Papier, in die Kommandozeile usw. ).

Beispiel: Das leere SQL-Kommando

Als ein erstes Beispiel folgt die einfachstmögliche Wegbeschreibung für ein gültiges SQL-Kommando durch das oben gezeigte Syntaxdiagramm:

Beginne am Einstiegspunkt und verfolge die Linie entsprechend der Richtungsangabe. Biege die nächstmögliche Abzweigung ab, verfolge die Linie bis zur nächsten Kreuzung und halte dich dann rechts.

Tatsächlich! Schreibt man nichts, dann ist das bereits ein gültiger Satzbau in SQL, nämlich ein Satz mit einem "leeren Kommando", welches nichts bewirkt.

Ändert man die vorhergegangene Wegbeschreibung dahingehend ab, dass man sich an der Kreuzung nicht rechts hält, sondern links und sich im weiteren Verlauf der Wegstrecke dann ausschliesslich noch rechts hält, so kommt dabei folgendes heraus:

sqlite>;

Ein Semikolon kennzeichnet das Ende eines SQL-Kommandos, in diesem Fall das Ende eines leeren Kommandos. Auch dies ist ein gültiger Satzbau in SQL. Beweis: Es lässt sich ein gültiger Weg durch das Syntaxdiagramm zeigen, der genau diese Befehlszeile "produziert".  Wie sieht es mit der folgenden Befehlszeile aus, ist das ein gültiger SQL-Satzbau oder nicht?

sqlite>;;;

Natürlich gültig! Beweis: dreimal im Kreis um den stmt-Block herumfahren und dann das Diagramm verlassen!

Gültiger Satzbau ist nicht gleich sinnvoller Satz

Ob ein  gültiger SQL-Satzbau auch einen sinnvollen SQL-Satz darstellt, ergibt sich selbstverständlich erst aus der Bedeutung der in diesem Satz verwendeten Sprachmittel und dem Kontext, in welchem dieser Satz überhaupt "gesagt" wird. Wie z.B. bereits angedeutet, wird durch das Semikolon ein SQL-Kommando  abgeschlossen. Man kann das Semikolon auch weglassen, ohne das der SQL-Satzbau dadurch ungültig wird, was sich anhand des entsprechenden Syntaxdiagramms leicht nachweisen lässt. In dem speziellen Kontext der SQLite-Shell-Eingabezeile jedoch ist es nicht sinnvoll, das Semikolon wegzulassen, weil die SQLite-Shell das gewünschte Kommando erst dann ausführt, wenn sie eben dieses Semikolon am Schluss des Kommandos vorfindet. In einem anderen Kontext kann man das Semikolon jedoch möglicherweise weglassen, wenn man will, man kann es in diesem Fall aber genau so gut auch hinschreiben.  SQL-92 lässt grüssen!

Syntaxdiagramm-Verschachtelung

Soweit so gut, leere SQL-Kommandos sind auf Dauer nicht besonders interessant. Betrachtet man das oben abgebildete Syntaxdiagram, so fällt das Rechteck auf, durch das man ebenfalls hindurchfahren kann. Dieses Rechteck steht für ein weiteres Syntaxdiagramm, dessen Bezeichnung eben in diesem Rechteck aufgeführt ist. Im konkreten Fall steht dort "sql-stmt", wobei "stmt" für das englische Wort "statement" steht. Die Bezeichnungen der Diagramme sind jedoch nur Schall und Rauch, man könnte sie auch mit "xyz" bezeichnen, solange dadurch eindeutig feststeht, welches Diagramm für die Weiterfahrt zu benutzen ist.  Natürlich sind sinnvolle Namen besser für den "Kopf".

Um also das Rechteck "sql-stmt" durchlaufen zu können, sucht man  zunächst in den Syntaxdiagrammen nach dem entsprechend bezeichneten Diagramm und durchfährt es in der bekannten Weise. Verlässt man dann dieses Diagramm, so landet man wieder in demjenigen Diagramm, aus  dem man gerade hergekommen war, und verlässt in diesem damit nun auch das eben durchlaufene Rechteck. Es ist normal, dass mit zunehmender Komplexität des zu "bauenden" gewünschten SQL-Kommandos auch die Anzahl der zu durchlaufenden verschiedenen Diagramme steigt.

Mehrdeutige Diagrammsymbolik

Die Verwendung der verschiedenen SQL-Kommandos wird in der SQLite-Dokumentation also mit Hilfe von Syntaxdiagrammen beschrieben. Aber aufgepasst! Die Syntaxdiagramme der SQLite-Dokumentation halten die hier beschriebene Bedeutung der geometrischen Symbole nicht in allen Diagrammen konsequent ein. Man findet dort halbrunde Rechtecke, die einmal die hier beschriebene Bedeutung haben und ein anderes Mal die Bedeutung, die hier dem normalen Rechteck zugewiesen wurde und das alles durchaus auch in ein und demselben Diagramm. Die jeweilige Bedeutung wird in diesen Fällen dann aber zumindest typografisch gekennzeichnet. Man kann damit gut zurechtkommen. Das ist aber leider noch nicht alles; in manchen der halbrunden Rechtecke stehen Bezeichner, die weder für sich selbst stehen, noch auf ein anderes Diagramm verweisen. Wodurch diese Bezeichner dann zu ersetzen sind, bleibt dem gesunden Menschenverstand überlassen und dem Wissen um Literale und Objekt-Identifizierer.

Literale und Objekt-Identifizierer

Literale

Ein Literal ist eine Zeichenfolge, die für sich selbst steht. Man unterscheidet:

String-Literal:  Eine in einfache Anführungszeichen eingeschlossene Zeichenkette, z.B. 'dies ist ein String-Literal' . Kommt in einem String-Literal selbst ein einfaches Anführungszeichen vor,  so ist innerhalb des Literals dieses Anführungszeichen durch zwei direkt aufeinanderfolgende einfache Anführungszeichen darzustellen, also z.B. 'Opa''s Kino lebt'.

Numerisches-Literal: Hierfür gibt es in der SQLite-Dokumentation ein eigenes Syntaxdiagram.  Beispiele:  4.123 oder  6.1E-10 oder  -1 .

Binäres-Literal: Ein x gefolgt von einem String-Literal, das nur Ziffernzeichen sowie die Buchstaben  a .. f enthalten darf und dessen Anzahl Zeichen stets eine gerade Zahl sein muss. Es handelt sich nämlich um eine hexadezimal kodierte Byte-Folge und die Darstellung eines Bytes im Hexadezimal-System erfordert genau zwei Hexadezimal-Zeichen.  Beispiele:  x'ab' oder  x'1234' oder  x'00ff00' usw.

Objektidentifizierer

Objekt-Identifizierer sind Namen, mit denen Datenbank-Objekte bezeichnet werden. Also Namen für Tabellen, für Spalten, für Indizes  usw.  Diese Objekt-Identifizierer können frei erfunden werden mit der Einschränkung, dass nicht alle Zeichen erlaubt sind und dass vor Allem die Namen der SQL-Schlüsselwörter für eigene Wortschöpfungen tabu sind.  Davon gibt es jedoch eine Abweichmöglichkeit: Denkt man z.B. einmal an eine Tabelle, in welcher Daten über Personen gespeichert werden sollen, so könnte es dort ein Feld  für das Alter des Menschen geben.  Leider ist das Wort 'Alter' auch ein SQL-Schlüsselwort. Umschliesst  man allerdings den Feldnamen mit doppelten Anführungszeichen, nämlich im gegeben Fall "Alter", dann ist die Verwendung dieses Namens in dieser Weise möglich.

Datentypen und Datentyp-Affinität

Schliesslich muss man noch die Datentypen kennen, die SQLite verarbeiten kann.  Durch die Datentypen ist definiert,  welche Werte in der Datenbank gespeichert werden können und welche Operationen damit möglich sind. SQLite hat bezüglich Datentypen ein gegenüber anderen Datenbanksystem abweichendes Konzept, welches auf der Verwendung von fünf Datentyp-Primitiven beruht. In der SQLite-Dokumentation werden diese Primitive als "Speicher-Klassen" bezeichnet, was man hier zunächst einmal als Synonym für "Datentypen" betrachten kann. Diese fünf Datentypen sind: integer, real, text, blob und NULL.

Datentyp-Primitive

integer: Ganzzahlen; die Länge variiert zwischen 1 Byte und 8 Byte und wird von SQLite automatisch anhand des jeweils vorliegenden Ganzzahl-Wertes festgelegt.

real: 8 Byte Fliesskommazahlen

text: Zeichen , standardmässig bis zu 1 Milliarde

blob: Bytes,  standardmässig bis zu 1 Milliarde

null: Repräsentation nicht vorhandener Informationen

Datentyp-Affinität

Während in anderen Datenbanksystemen wesentlich mehr Datentypen vorhanden sind, wird in SQLite nach einem bestimmten Verfahren jeder mögliche Datentyp auf einen dieser fünf Primitive abgebildet, sofern es sich nicht bereits um solch ein Primitiv handelt. Beispiel:   Der Datentyp   "char"  wird  auf das Primitiv  "text" abgebildet,  oder  der Datentyp "charint" wird auf das Primitiv "integer" abgebildet.  Sofern man also bereits mit einem anderen Datenbanksystem vertraut ist, kann man im Grunde die bekannten Datentyp-Namen weiter benutzen. Dieses Konzept wird in der SQLite-Dokumentation  Datentyp-Affinität genannt.

Kommentare

Zur Kommentierung von SQL-Anweisungen gibt es zwei Möglichkeiten:

-- Diese komplette Zeile ist ein Kommentar

/* Hier beginnt ein mehrzeiliger Kommentar ...
... eine weitere Kommentarzeile
... hier endet der Kommentar */