Relationales Datenbank Design
Dieses Seminar behandelt die strukturierte und tragfähige Modellierung relationaler Datenbanken. Von der Anforderungsanalyse über das konzeptionelle Entity-Relationship-Modell bis hin zum physischen Schema lernst du, wie Datenstrukturen anomaliefrei, performant und skalierbar entworfen werden.
Für wen ist dieses Seminar
Softwareentwickler, Datenanalysten, Systemarchitekten und Requirements Engineers. Das Angebot richtet sich an Unternehmen, Behörden und Selbstständige.
Was du mitbringen solltest
Allgemeines IT-Verständnis. SQL-Grundkenntnisse sind hilfreich, aber keine Voraussetzung.
Detaillierte Inhalte
Grundlagen der Datenmodellierung und des Datenbank-Designs
- Der Datenbankentwurfsprozess: Konzeptionell, Logisch, Physisch
- Relationale Algebra und relationale Konzepte (Entitäten, Attribute, Tupel)
- Schlüsselkonzepte: Primärschlüssel (natürlich vs. künstlich/Surrogat), Fremdschlüssel, zusammengesetzte Schlüssel
- Sequenz/Identity vs. UUID als künstlicher Schlüssel: Auswirkungen auf Sortierreihenfolge, Indexfragmentierung und Verteilung
Konzeptionelles Design
- Erstellung von Entity-Relationship-Modellen (ERM)
- Bestimmung von Kardinalitäten (1:1, 1:n, m:n)
- Auflösung von m:n-Beziehungen durch Assoziationstabellen (Junction Tables)
- Modellierung von optionalen und obligatorischen Beziehungen
Normalisierung und Logisches Design
- Anomalien bei Datenmanipulation (Insert, Update, Delete Anomalien)
- Die 1. Normalform (1NF): Atomarität von Attributen
- Die 2. Normalform (2NF): Volle funktionale Abhängigkeit
- Die 3. Normalform (3NF): Vermeidung transitiver Abhängigkeiten
- Boyce-Codd-Normalform (BCNF) und Ausblick auf höhere Normalformen
Physisches Design und Implementierung
- Mapping des logischen Modells auf ein physisches RDBMS
- Wahl der optimalen Datentypen (Speichereffizienz vs. Flexibilität)
- Durchsetzung von Datenintegrität durch Constraints (CHECK, UNIQUE, NOT NULL)
- Best Practices für Namenskonventionen (Tabellen, Spalten, Indizes)
- Dokumentation des Schemas: Data Dictionary pflegen und ER-Modellierungswerkzeuge einsetzen
Komplexe Modellierungsmuster
- Abbildung von Hierarchien und Baumstrukturen (Adjacency List, Nested Sets)
- Modellierung von Historisierung (Slowly Changing Dimensions)
- Gültigkeitszeiträume und Historisierung im OLTP-Betrieb (temporale Spalten, Systemversionierung)
- Das Entity-Attribute-Value (EAV) Muster: Einsatzgebiete und Gefahren
- JSON-/JSONB-Spalten als moderne Alternative zum EAV-Muster
- Umgang mit polymorphen Assoziationen
- Mandantenfähigkeit: Multi-Tenant-Modelle im Vergleich (eigene Datenbank, eigenes Schema oder Mandanten-Spalte je Tabelle)
Denormalisierung und Performance
- Bewusste Brüche der Normalisierung für Lese-Performance
- Unterschiede in der Modellierung: OLTP (Transaktionssysteme) vs. OLAP (Data Warehouses / Star-Schema)
- Caching-Strategien und vorberechnete Aggregationstabellen
Dauer: 2 Tage
Was du danach kannst
- Ein Entity-Relationship-Modell aus einer Anforderung ableiten und Kardinalitäten korrekt bestimmen
- Ein Schema bis zur 3. Normalform normalisieren und begründen, wann eine höhere Normalform sinnvoll ist
- Zwischen Sequenz/Identity und UUID als Schlüssel bewusst entscheiden
- Historisierung, Mandantenfähigkeit und EAV-/JSONB-Alternativen für den passenden Anwendungsfall auswählen
- Gezielt denormalisieren, wo Lese-Performance es rechtfertigt — statt aus Gewohnheit
- Ein physisches Schema mit Constraints, Namenskonventionen und Dokumentation sauber umsetzen
Verwandte Seminare
- SQL Grundlagen — hilfreiche Basis, um die entworfenen Tabellen auch selbst abzufragen.
- Datenbankübergreifendes Performance-Tuning — wie sich Design-Entscheidungen später auf die Performance auswirken.
- PostgreSQL Administration — die Umsetzung des Schemas im laufenden Betrieb.
Dein Dozent
Frank Glück schult seit mehr als 30 Jahren und programmiert seit fast 40 Jahren. Seit 1999 ist er auch als Dozent für die GFU tätig.
Häufige Fragen (FAQ)
Bis zu welcher Normalform sollte in der Praxis normalisiert werden?
In der betrieblichen Praxis von OLTP-Transaktionsdatenbanken ist die 3. Normalform (3NF) oder Boyce-Codd-Normalform (BCNF) der Goldstandard. Sie verhindert Datenredundanzen, Einfüge-, Änderungs- und Löschanomalien zuverlässig, ohne das Schema durch zu viele Tabellen-Splits unnötig zu verkomplizieren.
Wann ist eine Denormalisierung sinnvoll?
Denormalisierung empfiehlt sich gezielt in Lese-intensiven Auswertungssystemen (Reporting, Data Warehouses, OLAP) oder an klar gemessenen Performance-Engpässen. Typische Muster sind vorberechnete Summen, redundante Fremdschlüssel zur Einsparung teurer Mehrfach-Joins oder die Überführung in Stern- und Schneeflockenschemata.
Welche Vorkenntnisse werden für das Datenbankdesign-Seminar benötigt?
Das Seminar richtet sich an Entwickler, Software-Architekten und Analysten. Grundlegendes Verständnis von tabellarischen Daten und einfache SQL-Kenntnisse sind hilfreich. Du erlernst die Modellierungsmethodik (Entity-Relationship-Modell, Kardinalitäten, Normalisierung) systematisch von Grund auf an realen Fallbeispielen.