Zum Inhalt springen
SemaTrain

SQL-WISSEN · Grundlagen

Relationales Modell

Wie Tabellen, Schlüssel, Beziehungen und Constraints ein konsistentes relationales Datenmodell bilden – und warum logisches Modell und konkrete Datenbankimplementierung getrennt betrachtet werden sollten.

Kurzdefinition

Im relationalen Modell werden Daten in Relationen organisiert. In Datenbanksystemen begegnen Ihnen diese Relationen typischerweise als Tabellen mit Spalten und Zeilen.

Schlüssel und Constraints beschreiben Regeln, die Identität, Beziehungen und zulässige Werte absichern.

Fachliche Einordnung

Das logische Datenmodell beschreibt fachliche Strukturen und Beziehungen. Die konkrete SQL-DDL setzt dieses Modell in einem Datenbanksystem um.

Dabei bleibt der relationale Kern vergleichbar, während Datentypen, Schlüsselgenerierung und einzelne DDL-Details vom Produkt abhängen können.

  • Primärschlüssel identifizieren Datensätze innerhalb einer Tabelle.
  • Fremdschlüssel bilden referenzielle Beziehungen zwischen Tabellen oder innerhalb derselben Tabelle ab.
  • Constraints formulieren zusätzliche Integritätsregeln.
  • NULL beschreibt das Fehlen eines Wertes und ist nicht mit der Zahl 0 oder einer leeren Zeichenkette gleichzusetzen.

Konkretes Beispiel

Ein Bestellsystem trennt Kunden und Bestellungen in zwei Tabellen. Die Bestellung verweist über eine Kunden-ID auf den zugehörigen Kunden.

SQL-Beispiel
CREATE TABLE kunde (
  id INTEGER PRIMARY KEY,
  name VARCHAR(120) NOT NULL
);

CREATE TABLE bestellung (
  id INTEGER PRIMARY KEY,
  kunde_id INTEGER NOT NULL,
  betrag DECIMAL(10,2) NOT NULL,
  FOREIGN KEY (kunde_id) REFERENCES kunde(id)
);

Kritisch unterscheiden

  • Ein logisches Modell ist nicht dasselbe wie ein physischer Ausführungsplan oder eine Indexstrategie.
  • PRIMARY KEY, FOREIGN KEY, UNIQUE und CHECK erfüllen unterschiedliche Integritätsaufgaben.
  • Ein Fremdschlüssel beschreibt eine Beziehung; die konkrete Performance-Optimierung dieser Beziehung ist eine separate Frage.

Typische Fehler und Missverständnisse

  • Tabellen nur nach Bildschirmformularen statt nach fachlichen Entitäten und Beziehungen zu strukturieren.
  • Primärschlüssel und fachliche Eindeutigkeit als dasselbe Konzept zu behandeln.
  • Produktspezifische DDL-Details als allgemeine SQL-Regel auszugeben.

Praxisfall

Kunden, Projekte und Rechnungen

Ein Unternehmen möchte Kunden, Projekte und Rechnungen speichern. Ein Kunde kann mehrere Projekte haben; eine Rechnung gehört zu genau einem Projekt.

  • Welche Tabellen würden Sie als eigenständige Relationen modellieren?
  • Welche Primär- und Fremdschlüssel benötigen Sie?
  • Welche Regeln sollten als Constraints statt nur in der Anwendung abgesichert werden?

Selbsttest

Verständnis prüfen

1. Welche Aufgabe hat ein Fremdschlüssel primär?

Antwortmöglichkeiten zu Frage 1
Antwort und Begründung anzeigen

Ein Fremdschlüssel bildet eine referenzielle Beziehung ab und unterstützt deren Integrität. Indexierung und Sortierung sind davon getrennte Themen.

2. Warum ist das relationale Modell nicht identisch mit einer konkreten SQL-Implementierung?

Antwortmöglichkeiten zu Frage 2
Antwort und Begründung anzeigen

Das Modell ist die logische Ebene. Die konkrete DDL setzt sie in einem Produkt um und kann dabei systemspezifische Details enthalten.

Transfer

Auf die eigene Praxis übertragen

Nehmen Sie eine bestehende Tabelle aus Ihrem Umfeld. Prüfen Sie, welche fachliche Entität sie abbildet, welche Schlüssel wirklich Identität ausdrücken und welche Beziehungen nur implizit statt durch Constraints beschrieben sind.

Weiterlernen

Verknüpfungen

Quellen, Prüfstand und Grenzen

Fachliche Nachvollziehbarkeit

Quellen geprüft
2026-09-18
Versionsrahmen
Gemeinsamer SQL-Kern mit explizit gekennzeichneten Varianten für SQLite 3.53.4, PostgreSQL 18 und MySQL 8.4 LTS.
Aussagebereich
Die Modellierungsgrundlagen werden systemübergreifend vermittelt. Datentypen, Schlüsselgenerierung und einzelne DDL-Details können je Produkt abweichen.
Originalität
Faktenbasis aus Primärquellen; Einordnung, Struktur, Beispiele, Selbsttests und Transfer sind eigenständige SemaTrain-Inhalte.

Grenzen

  • Produktspezifische Syntax und Verhalten können sich zwischen SQLite, PostgreSQL und MySQL unterscheiden.
  • Versionsabhängige Aussagen gelten für den im Quellenbereich ausgewiesenen Prüfstand.

Primärquellen

Projekt-Primärdokumentation

SQLite CREATE TABLE

SQLite

Version: SQLite 3.53.4

Bezug: CREATE TABLE, PRIMARY KEY, FOREIGN KEY, UNIQUE, CHECK und DEFAULT.

Projekt-Primärdokumentation

PostgreSQL 18 CREATE TABLE

PostgreSQL

Version: PostgreSQL 18

Bezug: CREATE TABLE, Spalten, Constraints und Schlüssel.

Hersteller-Primärdokumentation

MySQL 8.4 CREATE TABLE Statement

MySQL

Version: MySQL 8.4 LTS

Bezug: CREATE TABLE, Schlüssel, Constraints und MySQL-spezifische Optionen.