Zum Inhalt springen
SemaTrain

SQL-WISSEN · Modellierung

Datenmodellierung, Schlüssel und Normalisierung

Wie fachliche Entitäten, Schlüssel, Beziehungen und Normalisierung zusammenwirken, um ein nachvollziehbares relationales Datenmodell zu bilden.

Vom Fachmodell zur Relation

Relationale Modellierung beginnt mit fachlichen Strukturen und Beziehungen. Tabellen und Constraints setzen diese logische Struktur anschließend in einem konkreten Datenbanksystem um.

Kandidatenschlüssel und der ausgewählte Primärschlüssel drücken Identität beziehungsweise Eindeutigkeit aus; Fremdschlüssel modellieren referenzielle Beziehungen. Technische Schlüsselwahl und fachliche Eindeutigkeitsregeln sollten deshalb bewusst getrennt dokumentiert werden.

Normalisierung als Strukturierungsprinzip

Normalisierung ordnet Attribute und Beziehungen so, dass vermeidbare Redundanzen und daraus entstehende Änderungsprobleme reduziert werden. Historische Normalformen beschreiben dafür schrittweise Anforderungen an relationale Strukturen.

Normalisierung ist kein Synonym für möglichst viele Tabellen und keine automatische Performanceoptimierung. Die fachlichen Abhängigkeiten bestimmen die Modellierungsentscheidung; physische Optimierung ist eine separate Ebene.

Didaktisches Zerlegungsbeispiel

Eine einzige Tabelle mit Teilnehmerdaten, Kursdaten, Termindaten und Anmeldedaten wiederholt dieselben Stammdaten an vielen Stellen. Ein relationales Modell kann diese Verantwortlichkeiten in eigenständige Relationen aufteilen und über Schlüssel verbinden.

Für die hier behandelten grundlegenden Normalisierungsschritte sind insbesondere funktionale Abhängigkeiten und Geschäftsregeln des Fachmodells zu analysieren; weiterführende Normalformen berücksichtigen zusätzliche Abhängigkeitstypen.

Mögliche Relationen eines Kursmodells
-- Teilnehmer(id, name, ...)
-- Kurs(id, titel, ...)
-- Termin(id, kurs_id, datum, ...)
-- Anmeldung(teilnehmer_id, termin_id, ...)

Kritisch unterscheiden

  • Ein Primärschlüssel ist nicht automatisch identisch mit jeder fachlichen Eindeutigkeitsregel.
  • Normalisierung betrifft logische Struktur und Abhängigkeiten; Indexierung betrifft physische Zugriffspfade.
  • Eine n:m-Beziehung wird im relationalen Modell typischerweise über eine eigene Zuordnungsrelation ausgedrückt.

Typische Fehler und Missverständnisse

  • Bildschirmmasken eins zu eins in Tabellen zu übersetzen, ohne Entitäten und Abhängigkeiten zu analysieren.
  • Normalisierung ausschließlich als Performanceverfahren zu behandeln.
  • Surrogatschlüssel einzuführen und dadurch fachliche Eindeutigkeitsregeln unberücksichtigt zu lassen.

Praxisfall

Kursverwaltung strukturieren

Eine Tabelle enthält Teilnehmername, E-Mail, Kurstitel, Termin, Trainer und Anmeldestatus in jeder Zeile. Stammdaten wiederholen sich für jede Anmeldung.

  • Welche fachlichen Entitäten erkennen Sie?
  • Welche Beziehungen bestehen zwischen ihnen?
  • Welche Eindeutigkeits- und Fremdschlüsselregeln sollten unabhängig von Performancefragen formuliert werden?

Selbsttest

Verständnis prüfen

1. Was ist ein Hauptziel relationaler Normalisierung?

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

Normalisierung strukturiert Relationen anhand fachlicher Abhängigkeiten. Sie ist keine Garantie für einen bestimmten Ausführungsplan.

2. Warum ersetzt ein Surrogat-Primärschlüssel keine fachliche UNIQUE-Regel?

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

Ein technischer Schlüssel identifiziert eine Zeile. Fachliche Eindeutigkeit kann zusätzlich eine eigene Constraint-Regel benötigen.

Transfer

Auf die eigene Praxis übertragen

Wählen Sie eine stark denormalisierte Tabelle aus einem Projekt und markieren Sie wiederholte Fakten. Formulieren Sie anschließend die fachlichen Abhängigkeiten, bevor Sie Tabellen oder Schlüssel verändern.

Weiterlernen

Verknüpfungen

Passende Kurseinheiten

Verwandte Wissensseiten

Quellen, Prüfstand und Grenzen

Fachliche Nachvollziehbarkeit

Quellen geprüft
2026-09-27
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. Relationen, Schlüssel und Constraints werden mit dem SQL-Produktkontext verbunden. Normalisierung wird als relationales Modellierungsprinzip aus der grundlegenden Forschung eingeordnet und nicht als pauschale Performance-Regel dargestellt.
Originalität
Faktenbasis aus Primärquellen; Einordnung, Struktur, Beispiele, Selbsttests und Transfer sind eigenständige SemaTrain-Inhalte.

Grenzen

  • Die Seite vermittelt Modellierungsprinzipien und ersetzt keine vollständige formale Behandlung aller Normalformen und Abhängigkeitstheorien.
  • 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.