Grundsätze des
Datenbankdesigns

Normalisierung ist das systematische Verfahren, Redundanzen aus einem Datenbankschema zu entfernen und Abhängigkeiten klar zu strukturieren. Das Ziel: Jede Information wird an genau einer Stelle gespeichert. Das verhindert Inkonsistenzen bei Änderungen und vereinfacht die Pflege.

Für operative Datenbanken (OLTP) ist die dritte Normalform (3NF) in der Regel das sinnvolle Ziel. BCNF und höhere Normalformen sind theoretisch elegant, erzwingen aber oft so viele Tabellen, dass die Abfragestruktur darunter leidet.

Typischer Fehler: mehrwertige Attribute in einer Spalte

-- Telefonnummern als komma-separierter String 
CREATE TABLE Kunden 
( 
KundeID INT, 
Name NVARCHAR(100), 
Telefon NVARCHAR(200) -- '030-123,089-456' 
);

CREATE TABLE Kunden 
( 
KundeID INT NOT NULL, 
Name NVARCHAR(100) NOT NULL 
); 
CREATE TABLE KundenTelefon 
( 
TelefonID INT NOT NULL, 
KundeID INT NOT NULL, 
Nummer NVARCHAR(30) NOT NULL, 
Typ NVARCHAR(20) -- 'Mobil', 'Büro' 
);

Kontrollierte Denormalisierung

Für analytische Abfragen (OLAP) oder Reporting-Datenbanken ist Denormalisierung oft bewusst sinnvoll: Vorberechnete Aggregatspalten, redundante Schlüsselspalten oder flache Wide-Tables reduzieren die Anzahl der JOINs und beschleunigen Lesezugriffe erheblich.

Der Primärschlüssel ist die Grundlage jeder Tabelle. Er identifiziert jede Zeile eindeutig, bestimmt die physische Speicherreihenfolge (Clustered Index) und dient als Ankerpunkt für alle Fremdschlüsselbeziehungen. Die Wahl der Schlüsselstrategie beeinflusst Performance, Wartbarkeit und Integrationsfähigkeit nachhaltig.

Natürliche vs. Ersatzschlüssel

Zusammengesetzte Primärschlüssel

Für reine Verknüpfungstabellen (Many-to-Many) ist ein zusammengesetzter PK aus den beiden Fremdschlüsseln oft die richtige Wahl – er erzwingt die Eindeutigkeit der Kombination ohne zusätzliche Spalte und der Index ist bereits der Clustered Index.

-- Many-to-Many: Bestellung ↔ Produkt 
CREATE TABLE BestellungProdukt 
( 
BestellungID INT NOT NULL, 
ProduktID INT NOT NULL, 
Menge INT NOT NULL, 
Einzelpreis DECIMAL(10,2) NOT NULL, 
CONSTRAINT PK_BestellungProdukt 
PRIMARY KEY (BestellungID, ProduktID) 
);

Der Datentyp einer Spalte beeinflusst Speicherverbrauch, Indexgröße, Sortierverhalten und die Möglichkeit impliziter Typkonvertierungen bei Abfragen. Falsch gewählte Typen sind eine häufige Ursache für ungenutzte Indizes.

Zahlen

Zeichenketten

Datum und Uhrzeit

Referentielle Integrität stellt sicher, dass Beziehungen zwischen Tabellen konsistent bleiben: Ein Fremdschlüsselwert muss immer auf einen existierenden Primärschlüsselwert verweisen. Die Durchsetzung dieser Regel in der Datenbank selbst – nicht nur im Anwendungscode – ist ein zentrales Designprinzip.

Fremdschlüssel mit CASCADE-Optionen

CREATE TABLE Bestellungen 
( 
BestellungID INT NOT NULL IDENTITY(1,1), 
KundeID INT NOT NULL, 
Bestelldatum DATETIME2(0) NOT NULL DEFAULT SYSDATETIME(), 
Status TINYINT NOT NULL DEFAULT 1, 
CONSTRAINT PK_Bestellungen 
PRIMARY KEY (BestellungID), 
CONSTRAINT FK_Bestellungen_Kunden 
FOREIGN KEY (KundeID) 
REFERENCES Kunden (KundeID) 
ON DELETE NO ACTION -- Löschen verhindern, wenn Bestellungen existieren 
ON UPDATE CASCADE -- KundeID-Änderung wird weitergegeben 
);

CHECK Constraints

CHECK Constraints erzwingen fachliche Regeln direkt in der Datenbank und sind zuverlässiger als Validierungslogik in der Anwendung.

ALTER TABLE Bestellungen 
ADD CONSTRAINT CK_Bestellungen_Status 
CHECK (Status IN (1, 2, 3, 4)); -- 1=Offen, 2=Bestätigt, 3=Versendet, 4=Storniert 
 
ALTER TABLE Produkte 
ADD CONSTRAINT CK_Produkte_Preis 
CHECK (Preis >= 0); 
 
ALTER TABLE Bestellungen 
ADD CONSTRAINT CK_Bestellungen_Datum 
CHECK (Lieferdatum > Bestelldatum);

Konsistente Namensgebung ist keine ästhetische Frage, sondern eine Frage der Wartbarkeit. In einer Datenbank mit hunderten Tabellen und tausenden Spalten entscheiden Namenskonventionen darüber, ob ein neuer Entwickler in zehn Minuten oder in zwei Tagen produktiv wird.

Empfohlene Konventionen für SQL Server

Schemas sinnvoll nutzen

SQL Server unterstützt Schemas als Namensraum-Konzept unterhalb der Datenbank. Statt alles in dbo zu legen, können Schemas funktionale Bereiche klar trennen – und separate Berechtigungen auf Schemaebene vergeben werden.

-- Schemas für funktionale Bereiche 
CREATE SCHEMA Sales; 
CREATE SCHEMA Inventory; 
CREATE SCHEMA HR; 
GO 
 
-- Tabellen im jeweiligen Schema 
CREATE TABLE Sales.Bestellung ( ... ); 
CREATE TABLE Sales.Bestellposition ( ... ); 
CREATE TABLE Inventory.Produkt ( ... ); 
CREATE TABLE HR.Mitarbeiter ( ... ); 
 
-- Berechtigungen auf Schemaebene 
GRANT SELECT ON SCHEMA::Sales TO ReportingUser;

NULL bedeutet in SQL nicht „leer" oder „null", sondern „unbekannt". Das hat weitreichende Konsequenzen: Vergleiche mit NULL ergeben weder TRUE noch FALSE, sondern UNKNOWN – was dazu führt, dass Zeilen aus Ergebnismengen verschwinden, die intuitiv erwartet werden.

-- Findet KEINE Zeilen, auch wenn Lieferdatum NULL ist! 
SELECT * FROM Bestellungen 
WHERE Lieferdatum = NULL; 
 
-- Auch diese Bedingung greift nicht: 
SELECT * FROM Bestellungen 
WHERE Lieferdatum != NULL;

-- Findet alle Bestellungen ohne Lieferdatum 
SELECT * FROM Bestellungen 
WHERE Lieferdatum IS NULL; 
 
-- COALESCE für Standardwert bei NULL 
SELECT 
BestellungID, 
COALESCE(Lieferdatum, 'noch nicht geliefert') 
AS LieferstatusText 
FROM Bestellungen;

Designentscheidung: NOT NULL als Standard

Spalten sollten standardmäßig NOT NULL definiert werden. NULL sollte nur dann erlaubt sein, wenn das Fehlen eines Wertes fachlich bedeutsam ist – zum Beispiel ein optionales Lieferdatum oder ein noch nicht zugewiesener Sachbearbeiter. Jede nullable Spalte erhöht die Komplexität von Abfragen und die Fehleranfälligkeit der Anwendungslogik.

Einige Designentscheidungen, die auf den ersten Blick neutral oder rein strukturell erscheinen, haben direkte Auswirkungen auf die Abfrageperformance. Sie lassen sich im Nachhinein oft nur mit erheblichem Aufwand korrigieren.

Schmale Primärschlüssel – schmale Indizes

Der Clustered Index Key wird in jedem Non-Clustered Index als Zeiger mitgeführt. Ein breiter PK (z.B. NVARCHAR(50) oder ein zusammengesetzter Schlüssel aus drei Spalten) vergrößert daher jeden weiteren Index der Tabelle proportional. Ein schmaler INT oder BIGINT als PK minimiert den Index-Footprint der gesamten Tabelle.

Tabellen von Anfang an mit Indizes planen

Indizes sollten nicht nachträglich „bei Bedarf" ergänzt werden, sondern beim Schemaentwurf mitgeplant werden. Spalten, die regelmäßig in WHERE-Klauseln, JOIN ON-Bedingungen oder ORDER BY vorkommen, sind primäre Indexkandidaten. Jeder nicht vorhandene Index bei einer häufigen Abfrage kostet permanent Laufzeit – nicht nur beim ersten Auftreten.

CREATE TABLE Sales.Bestellung 
( 
BestellungID INT NOT NULL IDENTITY(1,1), 
KundeID INT NOT NULL, 
Bestelldatum DATETIME2(0) NOT NULL DEFAULT SYSDATETIME(), 
Status TINYINT NOT NULL DEFAULT 1, 
Gesamtbetrag DECIMAL(12,2) NOT NULL, 
CONSTRAINT PK_Bestellung PRIMARY KEY (BestellungID), 
CONSTRAINT FK_Bestellung_Kunde 
FOREIGN KEY (KundeID) REFERENCES Sales.Kunde (KundeID) 
); 
GO 
 
-- Häufige Filterung nach KundeID → Index 
CREATE INDEX IX_Bestellung_KundeID 
ON Sales.Bestellung (KundeID); 
 
-- Häufige Filterung nach Datum + Status → zusammengesetzter Index 
CREATE INDEX IX_Bestellung_Datum_Status 
ON Sales.Bestellung (Bestelldatum, Status) 
INCLUDE (KundeID, Gesamtbetrag); -- Covering: kein Key Lookup für diese Abfrage

Tabellengröße und Wachstum einschätzen

Eine Tabelle, die heute 10.000 Zeilen hat, kann in fünf Jahren 50 Millionen Zeilen haben. Designentscheidungen sollten dieses Wachstum berücksichtigen: Ist INT für den PK groß genug? Werden Archivierungsstrategien (Partitionierung, historische Tabellen) benötigt? Wird eine Löschstrategie für veraltete Datensätze gebraucht?

Temporale Tabellen für Historisierung

Ab SQL Server 2016 unterstützt SQL Server System-Versioned Temporal Tables – Tabellen, die automatisch jede Änderung mit Zeitstempeln historisieren. Das ist eine sauberere Alternative zu selbst gebauten Audit-Triggern.

CREATE TABLE Sales.Produkt 
( 
ProduktID INT NOT NULL, 
Bezeichnung NVARCHAR(200) NOT NULL, 
Preis DECIMAL(10,2) NOT NULL, 
-- Systemzeitstempel – werden automatisch gepflegt 
GueltigVon DATETIME2(7) GENERATED ALWAYS AS ROW START NOT NULL, 
GueltigBis DATETIME2(7) GENERATED ALWAYS AS ROW END NOT NULL, 
PERIOD FOR SYSTEM_TIME (GueltigVon, GueltigBis), 
CONSTRAINT PK_Produkt PRIMARY KEY (ProduktID) 
) 
WITH (SYSTEM_VERSIONING = ON (HISTORY_TABLE = Sales.Produkt_History)); 
 
-- Historischen Preis zu einem bestimmten Zeitpunkt abfragen 
SELECT Bezeichnung, Preis 
FROM Sales.Produkt 
FOR SYSTEM_TIME AS OF '2024-06-01 12:00:00' 
WHERE ProduktID = 42;