Datenbankmodellierung richtig machen

1. Einleitung – Datenmodellierung ist Architektur

In vielen IBM-i-Landschaften sind Datenbanken historisch gewachsen: DDS-Dateien, logische Files, keine expliziten Foreign Keys, Integrität ausschließlich im RPG-Code. Solange ein System isoliert arbeitet, „funktioniert“ das oft überraschend lange – die strukturellen Kosten werden erst sichtbar, wenn Integration Realität wird.

Typische Auslöser:

• Ein neues Java- oder .NET-Frontend greift direkt auf Db2 for i zu.
• Ein Data-Warehouse extrahiert periodisch Daten (ETL/ELT).
• Eine Microservice-Architektur wird schrittweise eingeführt.
• Zwei Unternehmen mit eigenem IBM-i-System fusionieren.
• Mandantenfähigkeit wird nachträglich gefordert.
• Externe Services replizieren Daten (CDC, Sync, Integration Hubs).

2. Entitäten richtig verstehen

Eine Entität besitzt eine stabile Identität, einen klar definierten Lebenszyklus und eine eigene fachliche Verantwortung. Tabellen sind lediglich die technische Umsetzung – nicht der Ursprung des Modells.

Lebenszyklus als wichtigstes Entscheidungskriterium

Der entscheidende Test lautet: Hat dieses Objekt einen eigenen, unabhängigen Lebenszyklus?

Beispiel:

• Ein Auftrag wird angelegt, geändert, bestätigt, fakturiert, storniert, archiviert.
• Eine Auftragsposition existiert normalerweise nur im Kontext des Auftrags → sie ist Teil des Aggregats.

CREATE TABLE orders (
 id CHAR(36) CCSID 1208 NOT NULL DEFAULT GENERATE_UUID(),
 /* ... */
 PRIMARY KEY (id)
);

CREATE TABLE order_positions (
 id CHAR(36) CCSID 1208 NOT NULL DEFAULT GENERATE_UUID(),
 order_id CHAR(36) CCSID 1208 NOT NULL,
 /* ... */
 PRIMARY KEY (id),
 CONSTRAINT fk_positions_order
 FOREIGN KEY (order_id) REFERENCES orders(id)
 ON DELETE CASCADE
);

Wird eine Position später eigenständig referenziert (z. B. Reklamation, Lagerbeleg, Qualitätssicherung, gesetzliche Aufbewahrung), sollte sie eine eigene Entität mit eigenem Lebenszyklus werden – aber bewusst, mit klarer fachlicher Begründung.

3. Primary Key – Identität ≠ Bedeutung

Der Primärschlüssel hat nur eine Aufgabe: dauerhaft eindeutige Identifikation – technisch, stabil, unveränderlich. Er ist kein Anzeigefeld und sollte keine Geschäftsregeln codieren.

Warum „sprechende“ / natürliche Schlüssel langfristig teuer werden

• Fusionen / Carve-outs → Kollisionen in Nummernkreisen
• Mandantenfähigkeit nachträglich → Präfixe oder Komposit-Schlüssel werden „hineingequetscht“
• Änderung von Geschäftsregeln (z. B. Format der Kundennummer) → Kaskadenänderungen in abhängigen Tabellen
• Replikation / CDC / Event-Sourcing → Konflikte bei dezentraler Vergabe

Empfohlene Schlüssel-Strategien (praxisnah)

• BIGINT IDENTITY (Db2 for i: GENERATED ALWAYS AS IDENTITY) – kompakt, performant, ideal für viele Core-Tabellen.
• UUID – gut für verteilte Systeme/Offline-Erfassung. Db2 for i kann per GENERATE_UUID() UUID v4 erzeugen; zeitbasierte UUID v7 müssen (Stand heute) typischerweise in der Anwendung erzeugt werden.
• Fachlicher Schlüssel (Kundennr, Artikel-Nr, …) als UNIQUE + ggf. CHECK (und bei Bedarf mandantenbezogen).
• Komposit-PKs (Mandant + Nummer) nur gezielt einsetzen (z. B. reine Relationstabellen) – nicht als Standard für Kernentitäten.

-- Speicherung als VARBINARY(16), Anzeige als CHAR(36):
-- 1) Text (CHAR(36)) -> VARBINARY(16): VARBINARY_FORMAT(...)
-- 2) VARBINARY(16) -> Text (CHAR(36)): VARCHAR_FORMAT_BINARY(...)

CREATE TABLE kunde (
 id_bin VARBINARY(16) NOT NULL DEFAULT VARBINARY_FORMAT(GENERATE_UUID(), 'XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX'),
 mandant_id SMALLINT NOT NULL,
 kundennr VARCHAR(20) NOT NULL,
 name1 VARCHAR(70) NOT NULL,
 name2 VARCHAR(70),
 created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
 rowchg_ts TIMESTAMP NOT NULL GENERATED ALWAYS FOR EACH ROW ON UPDATE AS ROW CHANGE TIMESTAMP,

 PRIMARY KEY (id_bin),
 CONSTRAINT uq_kunde_mandant UNIQUE (mandant_id, kundennr),
 CONSTRAINT chk_kundennr_len CHECK (LENGTH(kundennr) BETWEEN 3 AND 20)
);

Beispiel aus einem Fusionsszenario

In einem Integrationsprojekt zweier IBM-i-Systeme mit identischem Kundennummernkreis
mussten abhängige Tabellen temporär um Mandantenkennzeichen erweitert werden,
bevor eine konsolidierte Datenbasis entstehen konnte.
Ein technischer Surrogate Key hätte diesen Zwischenschritt vermieden.

4. Systemintegration, Mandantenfähigkeit und Fusion

Integration, Föderation und Replikation sind der Härtetest jedes Datenmodells. Sobald Daten zwischen Systemen bewegt, konsolidiert oder in Echtzeit synchronisiert werden, zeigt sich, ob Identität stabil ist.

Häufige Integrationsfallen

• Überlappende fachliche Nummernkreise (Kunde 4711 in System A und B).
• Nachträgliche Mandantenfähigkeit → jede FK-Beziehung muss erweitert werden.
• Dezentrale Datenerfassung ohne global eindeutige IDs → Konflikte bei Merge/Sync.

Typisches Praxisproblem in IBM-i-Umgebungen

Logische Files simulieren faktisch Primär- oder Fremdschlüssel, ohne dass deklarative
SQL-Constraints existieren. Sobald externe Tools direkt via SQL arbeiten,
treten Inkonsistenzen sichtbar zutage.

5. Modernisierung bestehender Legacy-Tabellen (IBM i)

Viele klassische DDS-Dateien haben keinen SQL-Primary-Key oder verlassen sich auf implizite Eindeutigkeit über logische Dateien. Eine schrittweise Modernisierung ist möglich – ohne Big-Bang.

Pragmatischer Modernisierungspfad

1. Neue technische ID-Spalte hinzufügen (z. B. BIGINT Identity oder CHAR(36) UUID).
2. Bestehende Sätze befüllen (bei UUID: per GENERATE_UUID()).
3. Primärschlüssel setzen.
4. Alten fachlichen Schlüssel als UNIQUE absichern.
5. Fremdschlüssel schrittweise auf die neue ID umstellen (zuerst in neuen Tabellen/Services).
6. Constraints erst nach Datenbereinigung aktivieren/validieren.

-- 1) Spalte hinzufügen
ALTER TABLE kundend ADD COLUMN id CHAR(36) CCSID 1208;

-- 2) Bestehende Datensätze befüllen (nur wo noch NULL)
UPDATE kundend
 SET id = GENERATE_UUID()
 WHERE id IS NULL;

-- 3) PK setzen
ALTER TABLE kundend
 ADD CONSTRAINT pk_kundend PRIMARY KEY (id);

-- 4) Fachlichen Schlüssel sichern (Beispiel)
ALTER TABLE kundend
 ADD CONSTRAINT uq_kundend_mandant_kundennr UNIQUE (mandant, kundennr);

Wichtig: Vor dem Setzen von NOT NULL und Constraints Dubletten, NULL-Werte und historische Artefakte bereinigen – sonst scheitert die Aktivierung.

6. Referenzielle Integrität in die Datenbank

Foreign-Key-Constraints gehören in die Datenbank – nicht nur in die Anwendung. Batch-Jobs, ETL-Prozesse, Reporting-Tools, direkte SQL-Zugriffe und zukünftige Microservices umgehen sonst die Anwendungslogik.

„Dann haben wir die Logik doppelt.“ – Nein.

Ein Foreign Key ist keine Business-Logik, sondern eine strukturelle Invariante:
Ein Kind-Datensatz darf ohne existierenden Parent nicht existieren.

Anwendungscode steuert Verhalten.
Die Datenbank garantiert Struktur.

Ohne Constraint verteilt sich die Prüfung auf mehrere Codepfade – und wird irgendwann vergessen.
Mit Constraint ist sie einmal definiert, global wirksam und nicht umgehbar.

Das ist keine doppelte Logik.
Das ist saubere Architektur.

ALTER TABLE aufpos
 ADD CONSTRAINT fk_aufpos_auftrag
 FOREIGN KEY (auftrag_id)
 REFERENCES aufkopf (id)
 ON DELETE CASCADE
 ON UPDATE RESTRICT;

7. Beziehungen korrekt modellieren

1:n – Klassischer Fall

Ein Kunde hat mehrere Aufträge.

kundend (id PK)
aufkopf (id PK, kunde_id FK → kundend.id)

m:n – in der Praxis selten „nur“ eine Kreuztabelle

In der Realität hat die Verbindungstabelle fast immer eigene Attribute (Menge, Preis zum Zeitpunkt, Rabatt, Status, Positionsnummer, …) und wird damit selbst zur Entität.

CREATE TABLE auftrag_position (
 id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
 auftrag_id BIGINT NOT NULL,
 artikel_id BIGINT NOT NULL,
 positionsnr INTEGER NOT NULL,
 menge DECIMAL(11,3) NOT NULL,
 vk_preis DECIMAL(12,4) NOT NULL,
 rabatt_prozent DECIMAL(5,2) NOT NULL DEFAULT 0,
 status CHAR(1) NOT NULL DEFAULT 'O', -- O=offen, L=geliefert, R=retour ...

 CONSTRAINT fk_pos_auftrag FOREIGN KEY (auftrag_id) REFERENCES aufkopf(id) ON DELETE CASCADE,
 CONSTRAINT fk_pos_artikel FOREIGN KEY (artikel_id) REFERENCES artikel(id) ON DELETE RESTRICT,
 CONSTRAINT uq_posnr UNIQUE (auftrag_id, positionsnr),
 CONSTRAINT chk_menge_pos CHECK (menge > 0)
);

8. Tabelle erweitern oder neue Tabelle?

Faustregel: Sobald Wiederholung, Historisierung, externe Referenzen oder eigener Lebenszyklus ins Spiel kommen → neue Tabelle.

9. Entity-Attribute-Value (EAV) – wann ja, wann nein

EAV speichert Attribute zeilenweise statt spaltenweise. Das verschiebt Struktur in die Daten – mit spürbaren Folgen für Typisierung, Constraints, Abfragekomplexität und Performance.

CREATE TABLE artikel_eav (
 artikel_id BIGINT NOT NULL,
 attribut VARCHAR(80) NOT NULL,
 wert VARCHAR(4000),
 PRIMARY KEY (artikel_id, attribut)
);

Warum EAV im Kerndatenbereich fast immer weh tut

• Typverlust: alles wird Text (oder CLOB) → Sortierung, Vergleiche, Aggregationen werden unsauber oder teuer.
• Keine saubere Validierung pro Attribut: NOT NULL, CHECK, FOREIGN KEY sind nur noch schwer/indirekt möglich.
• Abfragen werden kompliziert: Self-Joins oder Pivot-Logik (MAX(CASE ...)) statt einfacher Spaltenzugriffe.
• Indexes werden ineffizient: viele Zugriffe landen auf (entity, attribut) und müssen dann Werte filtern/casten.
• BI/Reporting eskaliert: Jede neue Kennzahl wird zum Modellierungsprojekt.

Wann EAV (oder eine kontrollierte Variante) vertretbar ist

• Sehr große Anzahl potenzieller Attribute (z. B. Produktkonfiguratoren, Custom Fields in SaaS).
• Die meisten Attribute sind bei den meisten Entitäten leer.
• Attribute werden vom Endkunden selbst definiert.
• Performance-Anforderungen sind moderat oder es gibt gezielte Materialisierungen/Views für Reporting.

Wenn schon EAV, dann bitte „kontrolliert“

Ein praxistauglicher Ansatz ist: Metadaten + typisierte Werte. Damit kannst du zumindest Typen/Validierung und saubere Indizes abbilden.

CREATE TABLE attribut_def (
 attribut_id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
 attribut_key VARCHAR(80) NOT NULL,
 datentyp CHAR(1) NOT NULL, -- 'S'tring, 'N'umeric, 'D'ate/'T'imestamp, 'B'oolean ...
 required SMALLINT NOT NULL DEFAULT 0,
 allowed_regex VARCHAR(200),
 CONSTRAINT uq_attr_key UNIQUE (attribut_key),
 CONSTRAINT chk_datentyp CHECK (datentyp IN ('S','N','T','B'))
);

CREATE TABLE artikel_attr (
 artikel_id BIGINT NOT NULL,
 attribut_id BIGINT NOT NULL,
 val_s VARCHAR(4000),
 val_n DECIMAL(31,10),
 val_ts TIMESTAMP,
 val_b SMALLINT,
 PRIMARY KEY (artikel_id, attribut_id),
 CONSTRAINT fk_attr_def FOREIGN KEY (attribut_id) REFERENCES attribut_def(attribut_id),
 CONSTRAINT chk_one_val CHECK (
 (CASE WHEN val_s IS NULL THEN 0 ELSE 1 END) +
 (CASE WHEN val_n IS NULL THEN 0 ELSE 1 END) +
 (CASE WHEN val_ts IS NULL THEN 0 ELSE 1 END) +
 (CASE WHEN val_b IS NULL THEN 0 ELSE 1 END)
 = 1
 )
);

-- Für Performance: Indexe nach typischen Filterpfaden (z. B. attribut_id + val_n, attribut_id + val_s, ...)

SELECT
 e.artikel_id,
 MAX(CASE WHEN d.attribut_key = 'Farbe' THEN e.val_s END) AS farbe,
 MAX(CASE WHEN d.attribut_key = 'Groesse' THEN e.val_s END) AS groesse,
 MAX(CASE WHEN d.attribut_key = 'Gewicht' THEN e.val_n END) AS gewicht
FROM artikel_attr e
JOIN attribut_def d ON d.attribut_id = e.attribut_id
GROUP BY e.artikel_id;

10. Normalisierung pragmatisch erklärt

Normalisierung reduziert Redundanz und verhindert Update-Anomalien – besonders wichtig bei Stammdaten.

auftrag (
 aufnr,
 kundennr,
 kundenname,
 kundenstrasse,
 kundenplz,
 kundenort,
 ...
)

Adressänderung muss in allen Aufträgen des Kunden nachgezogen werden → fehleranfällig.

Normalformen kurz & pragmatisch:

• 1NF – atomare Werte, keine wiederholenden Gruppen
• 2NF – keine Teilabhängigkeiten vom Schlüssel
• 3NF / BCNF – keine transitiven Abhängigkeiten
• 4NF / 5NF – meist nur bei sehr komplexen m:n-Beziehungen relevant

11. Anti-Patterns im Überblick

• Sprechende Primärschlüssel als Standard
• VARCHAR(5000) oder CLOB für alles (fehlende Typisierung)
• Komma-separierte Listen oder JSON als Ersatz für relationale Kernstruktur
• NULL als „leer“, „nicht zutreffend“, „0“-Ersatz ohne klare Semantik
• Historisierung ohne von/bis oder Versionsmodell
• Status-Flags als CHAR(1) ohne CHECK oder Lookup
• Spalte1 … Spalte10 („repeating groups“)
• Integrität nur in RPG/Java/.NET – nicht deklarativ in der DB
• Soft-Delete ohne Archivierungs-/Purging-Strategie
• EAV für Kerndaten statt strukturierter Modellierung

ALTER TABLE aufkopf
 ADD CONSTRAINT chk_status
 CHECK (status IN ('O','B','F','S')); -- offen, bestätigt, fakturiert, storniert

12. Praktische Checkliste

• Jede Kernentität hat einen technischen, stabilen Primärschlüssel (Identity oder UUID)?
• Fachliche Schlüssel sind als UNIQUE-Constraint (ggf. mandantenbezogen) gesichert?
• Alle wichtigen Beziehungen haben deklarative FOREIGN KEY Constraints?
• ON DELETE / ON UPDATE Strategie ist bewusst gewählt und dokumentiert?
• Keine kommagetrennten Listen oder JSON als Ersatz für relationale Struktur?
• Historisierung / Audit-Trail / Gültigkeitszeiträume sind geklärt?
• Statuswerte sind via CHECK oder Lookup validiert?
• Mandantenfähigkeit ist als separates Attribut modelliert (und nicht „in den PK gequetscht“)?
• EAV wird nur für echte Customizing-Fälle genutzt – nicht für Kerndaten?
• NOT NULL wird konsequent eingesetzt, wo sinnvoll?

13. Fazit

Quellen & Weiterführende Ressourcen

• IBM i 7.5 SQL Reference (Online)
• Db2 for i: GENERATE_UUID()
• Db2 for i: Referential Constraints
• Db2 for i: CREATE TABLE … OR REPLACE
• Martin Fowler: Patterns of Enterprise Application Architecture (Catalog)
• E. F. Codd (1970): A Relational Model of Data for Large Shared Data Banks (ACM DOI)
• PostgreSQL: Constraints (gute Vergleichslektüre)
• RFC 9562: UUIDs (inkl. Version 7)