Eine Schulverwaltung will Schüler und Kurse speichern, doch die Datenbank ist noch leer. Mit sql create table entsteht zuerst die Struktur, erst danach kommen die Daten.
Kurz gesagt: CREATE TABLE Name (Spalte Datentyp, …) legt eine Tabelle an. Spalten stehen in runden Klammern, durch Kommas getrennt. Ein Primärschlüssel identifiziert jede Zeile, Constraints schützen die Daten. SQLite kann nachträglich nur wenig ändern, daher gehören die wichtigen Regeln gleich in die erste Definition.
Der Artikel steigt mit der einfachsten Tabelle ein und geht dann über Datentypen und Constraints bis zu den Grenzen von ALTER TABLE. Weitere Grundlagen bündelt die Übersicht zum Thema datenbanken lernen.
Eine einfache Tabelle mit CREATE TABLE anlegen
CREATE TABLE gehört zur Data Definition Language. Die SQLite-Einführung von ZetCode beschreibt DDL als die SQL-Anweisungen, die das Datenbankschema festlegen. SQLite kennt dafür CREATE, ALTER TABLE und DROP. Wer DDL erklären soll, sagt also: DDL definiert die Struktur, nicht den Inhalt.
Die Spaltenliste steht laut einem Tutorial der Universität Wien in runden Klammern, die einzelnen Spalten sind durch Kommas getrennt. Die Zahl der Spalten und ihre Reihenfolge werden beim Bau der Tabelle festgelegt. Das spricht dafür, vor dem ersten Befehl auf Papier zu klären, welche Eigenschaften eine Zeile haben soll.
- Tabellennamen wählen: Der Name steht direkt nach CREATE TABLE und bezeichnet eine Sache aus dem Alltag, etwa Kurs oder Schueler.
- Spalten aufzählen: Jede Spalte erhält einen Namen und einen Datentyp.
- Schlüsselspalte markieren: Eine Spalte wird mit PRIMARY KEY gekennzeichnet.
- Anweisung abschließen: Die Klammer wird geschlossen, am Ende steht ein Semikolon.
Die kleinste sinnvolle Tabelle des Schulbeispiels sieht so aus:
CREATE TABLE Kurs (
Id INTEGER PRIMARY KEY,
Name TEXT,
Fach TEXT
);
Datentypen für die Spalten wählen
Jede Spalte braucht einen Datentyp, der festlegt, welche Art Wert sie aufnimmt. Welche Typen es gibt, hängt vom Datenbanksystem ab. Für den Unterricht lohnt der Blick auf SQLite, weil es ohne Server läuft, und auf MySQL, weil es in vielen Lehrbüchern vorkommt.
| System | Genannte Datentypen | Planungsnutzen |
|---|---|---|
| SQLite | NULL, INTEGER, REAL, TEXT, BLOB | Kleine, überschaubare Auswahl: ganze Zahlen als INTEGER, Namen und Kürzel als TEXT. |
| MySQL | Beispiele: varchar, int, date | Feinere Typen, etwa ein eigener Typ für Datumswerte wie ein Geburtsdatum. |
Die SQLite-Typen stammen aus der ZetCode-Einführung, die MySQL-Beispiele aus der CREATE-TABLE-Anleitung von W3Schools.
Wer zwischen Systemen wechselt, sollte die Typnamen nicht blind übernehmen. Auch andere Anleitungen nennen ähnliche Grundtypen: das Wiener Tutorial führt für PostgreSQL integer, text, varchar, char, date, time und timestamp an, IONOS nennt VARCHAR, BOOLEAN, INT und DATE. Für Schulprojekte reichen meist ganze Zahlen, Text und Datum.
Das Schulbeispiel planen und Primärschlüssel setzen
Bevor weitere Tabellen entstehen, hilft ein Entwurf: Welche Dinge gibt es, und woran erkennt man eine Zeile eindeutig? Das Beispiel besteht aus Kursen und Schülern. Jede Tabelle erhält eine eigene Schlüsselspalte, damit sich Zeilen sicher ansprechen lassen.
Der Primärschlüssel ist laut W3Schools die Spalte, die jede Zeile eindeutig identifiziert. In SQLite genügt dafür Id INTEGER PRIMARY KEY direkt in der Spaltenliste, wie es auch das ZetCode-Beispiel mit einer Tabelle Cars zeigt. Für Kurs und Schueler ist eine fortlaufende ganze Zahl die einfachste Wahl. Namen eignen sich schlecht als Schlüssel, weil sie sich wiederholen können.
Die zweite Tabelle folgt im nächsten Abschnitt, weil sie auf Kurs verweist. Deshalb gilt die Reihenfolge: zuerst die Tabelle, auf die verwiesen wird, danach die verweisende.
Constraints für NOT NULL, DEFAULT und Fremdschlüssel
Constraints sind Regeln, die in der Tabellendefinition stehen und fehlerhafte Einträge verhindern. Das ist wichtig, weil Datentypen allein wenig Schutz bieten: Laut dem Wiener Tutorial gibt es keinen Datentyp, der nur positive Zahlen zulässt. Solche Einschränkungen müssen als Constraint formuliert werden.
- PRIMARY KEY: kennzeichnet die Spalte, die jede Zeile eindeutig identifiziert (W3Schools).
- NOT NULL: Die Spalte darf nicht leer bleiben. Ohne diese Angabe darf ein Eintrag fehlen; das Wiener Tutorial nennt den leeren Wert NULL.
- DEFAULT: Wird kein Wert eingetragen, setzt die Datenbank den beim Bau der Tabelle voreingestellten Wert (Universität Wien).
- UNIQUE und FOREIGN KEY: UNIQUE verlangt je Spalte verschiedene Werte, FOREIGN KEY … REFERENCES verknüpft eine Spalte mit dem Primärschlüssel einer anderen Tabelle.
Für Schüler ergibt sich damit folgende Definition. Nachname und Vorname sind Pflicht, die E-Mail-Adresse darf nur einmal vorkommen, und KursId verweist auf Kurs. Die Zuordnung ist hier bewusst vereinfacht: Jeder Schüler gehört zu einem Kurs.
CREATE TABLE Schueler (
Id INTEGER PRIMARY KEY,
Nachname TEXT NOT NULL,
Vorname TEXT NOT NULL,
Email TEXT UNIQUE,
Status TEXT DEFAULT ‘aktiv’,
KursId INTEGER,
FOREIGN KEY (KursId) REFERENCES Kurs(Id)
);
Wer nicht sicher ist, ob eine Spalte Pflicht sein soll, entscheidet besser früh. Warum, zeigt der nächste Abschnitt: Nachträglich Regeln zu ergänzen, ist in SQLite nicht möglich.
Tabellen nachträglich mit ALTER TABLE ändern
ALTER TABLE ändert laut ZetCode die Struktur einer bestehenden Tabelle. SQLite unterstützt allerdings nur eine begrenzte Teilmenge dieser Anweisung. Für den Schulalltag bedeutet das: kleine Erweiterungen gehen, grundlegende Umbauten nicht.
Was in SQLite funktioniert
Unterstützt sind das Umbenennen der Tabelle und das Hinzufügen einer Spalte. Eine neue Spalte für die Klasse ergänzt man so:
ALTER TABLE Schueler ADD COLUMN Klasse TEXT;
Die neue Spalte erscheint am Ende der Tabelle. Vorhandene Zeilen behalten ihre Einträge.
Wo SQLite aufhört
Laut ZetCode ist es in SQLite nicht möglich, eine Spalte umzubenennen, eine Spalte zu entfernen oder Constraints hinzuzufügen oder zu entfernen. Der Grund für sorgfältiges Planen liegt hier: Ein vergessenes NOT NULL lässt sich in SQLite nicht nachträglich ergänzen. Andere Systeme gehen weiter. So beschreibt das Wiener Tutorial für PostgreSQL das Entfernen einer Spalte mit dem Zusatz CASCADE, der abhängige Objekte mit entfernt. Wer mit MySQL arbeitet, sollte die Möglichkeiten im Handbuch des eigenen Systems nachlesen, statt SQLite-Grenzen zu übertragen.
Als Ausweg bei SQLite bleibt eine neu definierte Tabelle mit den gewünschten Regeln. Der Ablauf:
- Prüfen: Reicht Umbenennen der Tabelle oder eine zusätzliche Spalte? Dann genügt ALTER TABLE.
- Neu definieren: Sonst die Tabelle mit korrekter Struktur und allen Constraints neu mit CREATE TABLE anlegen.
- Daten übernehmen: Die vorhandenen Zeilen mit Abfragen und Einfügebefehlen in die neue Tabelle bringen, wie sie sql insert update delete behandelt.
- Aufräumen: Erst wenn die neue Tabelle stimmt, die alte mit DROP entfernen.
Ergebnis prüfen und weiterarbeiten
Nach dem Ausführen lohnt ein Kontrollblick auf die Struktur. Ein Datenbank-Browser zeigt Spaltennamen, Datentypen und Schlüssel übersichtlich an. Wer keine Software installieren möchte, kann die Befehle auch in einem sql trainer online ausprobieren.
- Spalten vergleichen: Stimmen Namen und Datentypen mit dem Entwurf überein?
- Schlüssel kontrollieren: Trägt jede Tabelle eine Primärschlüssel-Spalte?
- Pflichtfelder prüfen: Sind Nachname und Vorname mit NOT NULL gesichert?
- Verweis testen: Zeigt KursId auf die Schlüsselspalte der Tabelle Kurs?
Erst wenn diese Punkte stimmen, sollten Daten eingetragen werden, denn Strukturfehler bei gefüllten Tabellen kosten in SQLite am meisten Aufwand.
Frequently asked questions
Darf ein Tabellenname mehrfach vorkommen?
Nein. Laut IONOS muss der Name einer Tabelle innerhalb einer Datenbank eindeutig sein, damit das System sie ansprechen kann.
Was bewirkt IF NOT EXISTS?
Mit dieser Klausel passiert nichts, wenn die Tabelle schon existiert, und es erscheint keine Fehlermeldung. Das hilft bei Skripten, die mehrfach laufen.
Kann man eine Tabelle aus einer Abfrage erzeugen?
Ja. Die Form CREATE TABLE … AS legt laut ZetCode eine neue Tabelle auf Basis einer SELECT-Anweisung an.
Gibt es einen Datentyp nur für positive Zahlen?
Nein. Laut dem Tutorial der Universität Wien begrenzt kein Datentyp den Wertebereich auf positive Zahlen. Dafür braucht es ein Constraint.
