Datenbankmodellierung richtig machen

Primary Keys, referenzielle Integrität und saubere Beziehungen – strategisch fundiert für IBM i, Db2 for i und moderne Backend-Architekturen.

1. Datenmodellierung ist Architektur

In vielen IBM-i-Landschaften sind Datenbanken historisch gewachsen: DDS-Dateien, logische Files, RPG-Programme mit gewachsener Prüf-Logik, kaum explizite Foreign Keys und Datenintegrität, die „schon immer“ in der Anwendungsschicht abgesichert wurde. Solange ein System isoliert läuft, funktioniert das häufig erstaunlich lange. Die Rechnung kommt später – meistens dann, wenn Integration, Reporting oder Modernisierung ernst wird.

Typische Auslöser, bei denen Modellschwächen sichtbar werden:

• Ein neues Java-, .NET- oder Web-Frontend greift per SQL direkt auf Db2 for i zu.
• Ein Data-Warehouse extrahiert regelmäßig ERP-Daten über ETL oder ELT.
• Eine alte 5250-Anwendung wird schrittweise um APIs, Microservices oder Integrationshubs ergänzt.
• Zwei Unternehmen mit eigenen IBM-i-Systemen fusionieren.
• Mandantenfähigkeit oder Konzernfähigkeit wird nachträglich gefordert.
• Externe Systeme replizieren Daten per CDC oder Synchronisationsprozess.

Dann reicht es nicht mehr, dass „das RPG-Programm schon aufpasst“. Direkte SQL-Zugriffe, neue Services, Batch-Jobs und Reporting-Tools umgehen diese Logik häufig. Was im Monolithen versteckt funktioniert hat, wird in einer integrierten Architektur plötzlich sichtbar – inklusive Dubletten, verwaister Sätze, unklarer Schlüssel und widersprüchlicher Statuswerte.

2. Entitäten richtig schneiden

Eine Entität ist kein Tabellenname. Eine Entität ist ein fachliches Objekt mit stabiler Identität, eigener Verantwortung und einem nachvollziehbaren Lebenszyklus. Tabellen sind nur die technische Umsetzung dieses fachlichen Modells.

Beispiel Auftrag:

• Ein Auftrag wird angelegt, geändert, bestätigt, geliefert, fakturiert, storniert und archiviert.
• Eine Auftragsposition existiert zunächst nur im Kontext dieses Auftrags.
• Wird die Position später eigenständig referenziert – etwa durch Reklamation, Lagerbeleg, Qualitätssicherung oder gesetzliche Aufbewahrung – braucht sie klare eigene Identität.

CREATE TABLE orders (
    id BIGINT GENERATED ALWAYS AS IDENTITY,
    order_no VARCHAR(30) NOT NULL,
    customer_id BIGINT NOT NULL,
    order_status CHAR(1) NOT NULL DEFAULT 'O',
    created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
    PRIMARY KEY (id),
    CONSTRAINT uq_orders_order_no UNIQUE (order_no),
    CONSTRAINT chk_orders_status CHECK (order_status IN ('O','C','I','S'))
);

CREATE TABLE order_positions (
    id BIGINT GENERATED ALWAYS AS IDENTITY,
    order_id BIGINT NOT NULL,
    position_no INTEGER NOT NULL,
    item_id BIGINT NOT NULL,
    quantity DECIMAL(11,3) NOT NULL,
    net_price DECIMAL(15,4) NOT NULL,
    PRIMARY KEY (id),
    CONSTRAINT fk_pos_order
      FOREIGN KEY (order_id) REFERENCES orders(id)
      ON DELETE CASCADE,
    CONSTRAINT uq_pos_no UNIQUE (order_id, position_no),
    CONSTRAINT chk_pos_quantity CHECK (quantity > 0)
);

Das fachliche Modell kommt zuerst. Wer ohne fachliche Abgrenzung Tabellen entwirft, produziert später unklare Verantwortlichkeiten: Welche Tabelle ist führend? Welche Spalte ist Wahrheit? Welcher Prozess darf löschen? Welche Daten müssen revisionssicher bleiben?

3. Primary Key: Identität ist nicht Bedeutung

Ein Primärschlüssel hat eine einzige Aufgabe: einen Datensatz dauerhaft, eindeutig und stabil zu identifizieren. Er ist kein Anzeigefeld, keine Geschäftsregel und kein Nummernkreis für Menschen.

Warum sprechende Schlüssel langfristig teuer werden

• Fusionen: Zwei Systeme kennen dieselbe Kundennummer für unterschiedliche Kunden.
• Mandantenfähigkeit: Aus kundennr wird plötzlich mandant + kundennr.
• Regeländerungen: Nummernformate ändern sich, Präfixe kommen dazu, alte Nummern bleiben trotzdem historisch relevant.
• Replikation: Dezentrale Systeme vergeben Nummern unabhängig voneinander.
• Schnittstellen: Externe Systeme speichern den Schlüssel und erwarten Stabilität.

Empfohlene Schlüsselstrategie

UUIDs auf Db2 for i sinnvoll speichern

GENERATE_UUID() liefert auf Db2 for i einen formatierten CHAR(36)-Wert. Für Indexgröße und Speicher kann eine binäre Speicherung als BINARY(16) oder VARBINARY(16) sinnvoll sein. Die Konvertierung gelingt mit VARBINARY_FORMAT (verfügbar in neueren Releases).

CREATE TABLE customers (
    id_bin VARBINARY(16) NOT NULL
      DEFAULT VARBINARY_FORMAT(GENERATE_UUID(),
        'XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX'),
    tenant_id SMALLINT NOT NULL,
    customer_no VARCHAR(30) NOT NULL,
    name1 VARCHAR(80) NOT NULL,
    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_customer_tenant_no UNIQUE (tenant_id, customer_no),
    CONSTRAINT chk_customer_no_len CHECK (LENGTH(customer_no) BETWEEN 3 AND 30)
);

-- Lesbar ausgeben
SELECT VARCHAR_FORMAT_BINARY(id_bin,
       'XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX') AS customer_uuid,
       tenant_id,
       customer_no,
       name1
FROM customers;

4. Integration, Mandantenfähigkeit und Fusion

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

Häufige Integrationsfallen

• Überlappende Nummernkreise: Kunde 4711 existiert in System A und System B – aber es sind unterschiedliche Kunden.
• Nachträgliche Mandantenfähigkeit: Jede eindeutige Regel und fast jede Beziehung muss neu bewertet werden.
• Fachliche Schlüssel als technische Kopplung: Änderungen im Geschäft ziehen technische Migrationen nach sich.
• Keine deklarativen Constraints: ETL- oder Reporting-Prozesse entdecken Inkonsistenzen, die die Anwendung nie zugelassen hätte – theoretisch.
• Keine Änderungsstrategie: Ohne saubere Änderungszeitpunkte werden Delta-Extraktion und CDC unnötig kompliziert.

5. Legacy-Tabellen auf IBM i modernisieren

Viele klassische IBM-i-Anwendungen basieren auf DDS-Dateien und logischen Files. Das ist nicht automatisch schlecht. Problematisch wird es, wenn implizite Annahmen nicht als SQL-Constraints sichtbar sind. Moderne Tools sehen dann Tabellen, aber keine klaren Regeln.

Pragmatischer Modernisierungspfad

1. Bestandsdaten analysieren: Dubletten, NULL-Werte, ungültige Status, verwaiste Kinddatensätze.
2. Technische ID ergänzen: BIGINT IDENTITY oder UUID, je nach Integrationsanforderung.
3. Bestehende Sätze sauber befüllen.
4. Fachliche Schlüssel als UNIQUE absichern.
5. Referenzen schrittweise auf technische IDs umstellen – zuerst in neuen Tabellen und Services.
6. Foreign Keys, CHECK-Constraints und NOT NULL erst nach Datenbereinigung aktivieren.
7. Kompatibilitäts-Views bereitstellen, damit alte Programme nicht sofort umgebaut werden müssen.

-- Beispielhaft: technische UUID-Spalte ergänzen
ALTER TABLE kundend
  ADD COLUMN id CHAR(36) CCSID 1208;

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

-- Danach erst Datenqualität prüfen:
-- 1) Gibt es NULL-Werte?
-- 2) Gibt es Dubletten im fachlichen Schlüssel?
-- 3) Gibt es abhängige Tabellen ohne passenden Parent?

ALTER TABLE kundend
  ALTER COLUMN id SET NOT NULL;

ALTER TABLE kundend
  ADD CONSTRAINT pk_kundend PRIMARY KEY (id);

ALTER TABLE kundend
  ADD CONSTRAINT uq_kundend_mandant_kundennr
  UNIQUE (mandant, kundennr);

6. Referenzielle Integrität gehört in die Datenbank

Foreign-Key-Constraints sind keine doppelte Business-Logik. Sie sind strukturelle Invarianten: Ein Kind-Datensatz darf nicht auf einen nicht existierenden Parent zeigen. Diese Regel gehört dorthin, wo alle Zugriffe vorbeikommen – in die Datenbank.

IBM beschreibt referenzielle Constraints genau in diesem Sinne: Sie stellen sicher, dass Werte einer abhängigen Tabelle nur dann gültig sind, wenn sie auf passende Werte in einer Parent-Tabelle verweisen. Nach Definition werden sie systemweit bei Änderungen über SQL und andere Schnittstellen erzwungen.

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 – der Klassiker

Ein Kunde hat mehrere Aufträge. Der Auftrag referenziert den Kunden. Nicht umgekehrt.

customers (id PK)
orders    (id PK, customer_id FK -> customers.id)

m:n – fast nie nur eine dumme Kreuztabelle

Viele m:n-Beziehungen bekommen in der Praxis eigene Attribute: Menge, Preis zum Zeitpunkt, Rabatt, Status, Reihenfolge, Quelle, Gültigkeit. Dann ist die Verbindungstabelle selbst eine Entität.

CREATE TABLE order_item (
    id BIGINT GENERATED ALWAYS AS IDENTITY,
    order_id BIGINT NOT NULL,
    item_id BIGINT NOT NULL,
    position_no INTEGER NOT NULL,
    quantity DECIMAL(11,3) NOT NULL,
    price_at_order DECIMAL(15,4) NOT NULL,
    discount_percent DECIMAL(5,2) NOT NULL DEFAULT 0,
    PRIMARY KEY (id),
    CONSTRAINT fk_oi_order FOREIGN KEY (order_id)
      REFERENCES orders(id) ON DELETE CASCADE,
    CONSTRAINT fk_oi_item FOREIGN KEY (item_id)
      REFERENCES items(id) ON DELETE RESTRICT,
    CONSTRAINT uq_oi_position UNIQUE (order_id, position_no),
    CONSTRAINT chk_oi_quantity CHECK (quantity > 0)
);

8. Neue Tabelle oder neue Spalte?

Eine der häufigsten Modellierungsfragen lautet: Reicht eine neue Spalte – oder brauchen wir eine neue Tabelle?

9. EAV, JSON und Custom Fields

Entity-Attribute-Value, kurz EAV, speichert Attribute zeilenweise statt spaltenweise. Das wirkt flexibel, verschiebt aber Struktur aus dem Modell in die Daten. Typisierung, Constraints, Indizes und Reporting werden dadurch deutlich schwieriger.

CREATE TABLE item_eav (
    item_id BIGINT NOT NULL,
    attribute_name VARCHAR(80) NOT NULL,
    attribute_value VARCHAR(4000),
    PRIMARY KEY (item_id, attribute_name)
);

Warum EAV bei Kerndaten weh tut

• Typverlust: Zahlen, Datumswerte und Flags landen als Text.
• Schwache Validierung: NOT NULL, CHECK und FOREIGN KEY greifen nur indirekt.
• Komplexe Abfragen: Aus einfachen Spalten werden Self-Joins, Pivot-Logik und MAX(CASE ...).
• Schwieriges Reporting: BI-Tools wollen stabile Spalten, nicht dynamische Attributlisten.
• Indexprobleme: Ein Index auf attribute_name hilft nicht automatisch für Wertvergleiche mit Typumwandlung.

Wann EAV oder JSON vertretbar sein kann

• Sehr viele potenzielle Zusatzattribute, von denen die meisten leer sind.
• Attribute werden kundenspezifisch oder mandantenspezifisch definiert.
• Die Daten sind nicht Teil zentraler Integritätsregeln.
• Reporting erfolgt über kontrollierte Views, Materialisierungen oder definierte Exportmodelle.

CREATE TABLE attribute_def (
    attribute_id BIGINT GENERATED ALWAYS AS IDENTITY,
    attribute_key VARCHAR(80) NOT NULL,
    data_type CHAR(1) NOT NULL,
    required SMALLINT NOT NULL DEFAULT 0,
    PRIMARY KEY (attribute_id),
    CONSTRAINT uq_attribute_key UNIQUE (attribute_key),
    CONSTRAINT chk_attribute_type CHECK (data_type IN ('S','N','T','B'))
);

CREATE TABLE item_attribute (
    item_id BIGINT NOT NULL,
    attribute_id BIGINT NOT NULL,
    val_string VARCHAR(4000),
    val_number DECIMAL(31,10),
    val_timestamp TIMESTAMP,
    val_boolean SMALLINT,
    PRIMARY KEY (item_id, attribute_id),
    CONSTRAINT fk_item_attr_def
      FOREIGN KEY (attribute_id) REFERENCES attribute_def(attribute_id),
    CONSTRAINT chk_exactly_one_value CHECK (
      (CASE WHEN val_string IS NULL THEN 0 ELSE 1 END) +
      (CASE WHEN val_number IS NULL THEN 0 ELSE 1 END) +
      (CASE WHEN val_timestamp IS NULL THEN 0 ELSE 1 END) +
      (CASE WHEN val_boolean IS NULL THEN 0 ELSE 1 END) = 1
    )
);

10. Normalisierung pragmatisch erklärt

Normalisierung reduziert Redundanz und verhindert typische Datenanomalien. In der Praxis geht es nicht darum, jedes Modell akademisch bis zur fünften Normalform zu treiben. Es geht darum, Stammdaten sauber zu halten und Redundanz nur bewusst einzusetzen.

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

Ändert sich die Kundenadresse, muss sie in allen Aufträgen nachgezogen werden. Wird sie nur teilweise aktualisiert, entstehen widersprüchliche Daten. Das ist die klassische Update-Anomalie.

11. Anti-Patterns im Überblick

• Sprechende Primärschlüssel als Standard.
• VARCHAR(5000), CLOB oder JSON als Universaltyp für strukturierte Kerndaten.
• Kommagetrennte Listen in einer Spalte.
• Statuswerte als CHAR(1) ohne CHECK oder Lookup-Tabelle.
• NULL ohne klare Semantik: unbekannt, nicht zutreffend, leer, noch nicht berechnet?
• Spalten wie telefon1, telefon2, telefon3 statt eigener 1:n-Struktur.
• Historisierung ohne valid_from, valid_to, Version oder Audit-Konzept.
• Soft Delete ohne Archivierungs- und Purge-Strategie.
• Datenintegrität ausschließlich in RPG, Java oder .NET.
• EAV für Kerndaten statt für echte Customizing-Szenarien.

ALTER TABLE aufkopf
  ADD CONSTRAINT chk_aufkopf_status
  CHECK (status IN ('O','B','F','S'));

-- O = offen, B = bestätigt, F = fakturiert, S = storniert

12. Praktische Checkliste

13. Fazit

Quellen & weiterführende Ressourcen