Datenmodell für ein kleines Zuchtbuch in sieben Tabellen

Ein Zuchtbuch ist auf den ersten Blick ein langweiliges Stammdatenprojekt: Tiere, ein paar Würfe, Schauergebnisse. In der Praxis kippt es trotzdem regelmäßig in eine breite, unleserliche Excel-Ableitung mit fünfzig Spalten. Der bessere Weg ist ein normalisiertes Modell aus sieben Tabellen — klein genug für einen Verein oder eine private Zucht, groß genug, um zehn Jahre Bestandsführung sauber abzubilden.

Die sieben Tabellen

Die Aufteilung folgt der dritten Normalform und vermeidet bewusst jedes „kann man später noch dazupacken”:

• Zuechter — Person oder Zwinger, plus Kontakt und Verbandsnummer.
• Tier — ein Datensatz pro Individuum, mit Wurfreferenz, Geschlecht, Farbe, Chip-Nummer.
• Wurf — Wurftag, Mutter, Vater, Züchter, Anzahl lebend und tot.
• Eltern — N:M-Auflösung Tier ↔ Tier mit Rolle (Vater, Mutter, ggf. Amme).
• Schauergebnis — pro Bewertungstermin eine Zeile mit Note, Richter, Veranstaltung.
• Untersuchung — gesundheitliche Befunde (HD, ED, Augen, DNA-Profil) mit Datum und Befund.
• Halterwechsel — Historie der Halter eines Tieres als Zeitscheibe (tier_id, halter_id, gueltig_ab, gueltig_bis).

Drei der sieben Tabellen sind reine Beziehungstabellen (Eltern, Halterwechsel, implizit Schauergebnis). Genau das ist der Punkt: was im Tier-Datensatz eine Geschichte hätte, wandert nach außen und bleibt zeitlich auswertbar.

Warum keine breite Tier-Tabelle

Der naheliegende Anfängerfehler ist eine Tabelle Tier mit Spalten vater_name, mutter_name, letzte_schau_note, aktueller_halter. Das funktioniert für die ersten zwanzig Tiere, dann beginnt der Schmerz: Ein Halterwechsel überschreibt die Historie. Eine zweite Schau ersetzt die erste. Ein Vater, der dreimal eingesetzt wird, steht dreimal als Freitext drin — mit drei Schreibweisen.

-- Falsch: alles in einer Zeile
CREATE TABLE tier_breit (
  tier_id        serial PRIMARY KEY,
  name           text,
  vater_name     text,
  mutter_name    text,
  letzte_note    text,
  aktueller_halter text
);

Die normalisierte Variante trennt die Achsen sauber:

CREATE TABLE tier (
  tier_id     bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  rufname     text NOT NULL,
  zwingername text,
  chip_nr     text UNIQUE,
  geschlecht  char(1) CHECK (geschlecht IN ('M','W')),
  wurf_id     bigint REFERENCES wurf(wurf_id)
);

CREATE TABLE eltern (
  kind_id    bigint NOT NULL REFERENCES tier(tier_id),
  elter_id   bigint NOT NULL REFERENCES tier(tier_id),
  rolle      text NOT NULL CHECK (rolle IN ('vater','mutter','amme')),
  PRIMARY KEY (kind_id, elter_id, rolle)
);

eltern ist die klassische N:M-Auflösung gegen sich selbst. Ein Tier kann viele Nachkommen und zwei biologische Eltern haben; mit der rolle-Spalte bleibt das Modell offen genug für Ammen oder embryonale Übertragungen, ohne dass eine eigene Tabelle nötig wird.

Surrogat- oder Natürlicher Schlüssel

Die Chip-Nummer ist verlockend als Primärschlüssel — sie ist eindeutig, lebenslang, vom Tierarzt vergeben. In der Praxis ist sie es nicht: Chips werden nachträglich nachgesetzt, doppelt vergeben (selten, aber dokumentiert), und Vereinsverbände schreiben unterschiedliche Formate vor. Ein BIGINT-Surrogatschlüssel ist langweilig, aber stabil. Die Chip-Nummer bekommt ein UNIQUE-Constraint und bleibt fachlicher Identifikator. Dieselbe Logik gilt für Würfe: ein zusammengesetzter natürlicher Schlüssel aus mutter_id + wurftag mag verlockend wirken, scheitert aber an Doppelwürfen mit Eizell-Splitting.

Was das Modell bewusst weglässt

Auffallend ist, was nicht enthalten ist: kein generischer „Notizen”-Bucket, keine Statusspalte mit Mischsemantik, keine Felder für Foto-Pfade direkt in Tier. Bilder gehören in eine eigene Medien-Tabelle, sobald sie auftauchen — das ist dann Tabelle Nummer acht und ein Zeichen, dass das Modell wächst. Solange Fotos nur als Dateipfad gepflegt werden, reicht ein Feld; das ist ein vertretbarer Kompromiss bei unter 500 Tieren.

Bei Beständen ab etwa 2.000 Tieren mit zehn Jahren Historie liegt man mit diesem Modell bei rund 20.000 Zeilen in Schauergebnis und 8.000 in Halterwechsel — Größenordnungen, die jede Abfrage unter 50 ms liefert, sobald tier_id indiziert ist.

Sieben Tabellen sind genug, solange jede einzelne genau eine Frage beantwortet.