Was ist Datenmodellierung?

Datenmodellierung ist ein Prozess, der Entitäten, Attribute und Beziehungen abbildet, bevor entschieden wird, wie eine Datenbank sie speichert. Die Entitäten sind der leichte Teil – jedes Produkt kennt seine Benutzer, Bestellungen und Beiträge. Das Handwerk steckt in den Beziehungen: welcher Datensatz auf welchen zeigt, wie viele, und wo diese Kante physisch liegt. Stimmen die Kanten, schreiben sich die Abfragen von selbst; stimmen sie nicht, kämpft jedes Feature gegen das Schema.

Das Wichtigste in Kürze

Dieselben Beziehungen, beide Welten

Zuerst relational – der Fremdschlüssel trägt Eins-zu-viele, und Viele-zu-viele muss über eine Verknüpfung zerlegt werden:

-- 1:N — der Fremdschlüssel lebt auf der "viele"-Seite
CREATE TABLE books (
  id        bigint PRIMARY KEY,
  title     text   NOT NULL,
  author_id bigint NOT NULL REFERENCES authors(id) ON DELETE CASCADE
);

-- M:N — kein einzelner FK drückt das aus; eine Verknüpfungstabelle hält beide Schlüssel
CREATE TABLE book_genres (
  book_id  bigint REFERENCES books(id),
  genre_id bigint REFERENCES genres(id),
  added_at timestamptz DEFAULT now(),     -- Verknüpfungen können Attribute tragen
  PRIMARY KEY (book_id, genre_id)         -- zusammengesetzter Schlüssel: eine Kante, einmal
);

Dokumentwelt, dasselbe Modell: Die Eins-zu-viele-Kante ist ein typisierter Pointer, die Viele-zu-viele-Kante eine Relation – keine Verknüpfungstabelle zu erfinden, und die Kante wird im Anwendungscode deklariert:

// JavaScript / Node.js — Back4app JS SDK
// One-to-many: a Pointer. Many-to-many: a Relation.
const author = await new Parse.Query('Author').get(authorId);

const book = new Parse.Object('Book');
book.set('title', 'Dune');
book.set('author', author);              // Pointer — typed one-to-many edge
await book.save();

const genres = book.relation('genres');  // Relation — many-to-many, unbounded
genres.add([sciFi, classics]);
await book.save();

// Flutter / Dart — Back4app Flutter SDK
// One-to-many: a Pointer. Many-to-many: a Relation.
final book = ParseObject('Book')
  ..set('title', 'Dune')
  ..set('author', author.toPointer()); // Pointer — typed one-to-many edge
await book.save();

book.addRelation('genres', [sciFi, classics]); // Relation — many-to-many
await book.save();

// iOS / Swift — Back4app Swift SDK
// One-to-many: a Pointer. Many-to-many: a Relation.
var book = Book()
book.title = "Dune"
book.author = try author.toPointer()   // Pointer — typed one-to-many edge
let saved = try await book.save()

let relation = try saved.relation("genres")
try await relation.add([sciFi, classics]).save() // Relation — many-to-many

// Android / Kotlin — Back4app Android SDK
// One-to-many: a Pointer. Many-to-many: a Relation.
val book = ParseObject("Book").apply {
  put("title", "Dune")
  put("author", author)                 // Pointer — typed one-to-many edge
}
book.save()

val genres = book.getRelation<ParseObject>("genres") // Relation — many-to-many
genres.add(sciFi)
genres.add(classics)
book.save()

Konzeptionell vs. logisch vs. physisch: die drei Ebenen

Die Disziplin, die diese Ebenen erzwingen: Streiten Sie nicht über Indizes, solange das Team noch uneins ist, was eine “Bestellung” überhaupt ist.

Jede Beziehung, jede Umsetzung

Die Tabelle, die in den Suchergebnissen nie gebaut wurde – jeder Kantentyp mit seiner Umsetzung in beiden Welten:

Kardinalitätsnotation, zum Lesen von Diagrammen: Der Krähenfuß zeichnet einen Strich für “eins” und eine dreizinkige Gabel für “viele”; die ER-Tradition schreibt 1 und N an die Linien; UML schreibt Multiplizitäten wie 1 und *. Drei Dialekte, eine Grammatik.

Normalisieren, denormalisieren oder einbetten?

Relationale Modellierung beginnt bei der Normalisierung – Daten so aufteilen, dass jeder Fakt genau einmal existiert, was Schreibvorgänge vor Anomalien schützt. Analytische und dokumentorientierte Modellierung biegt das bewusst: Denormalisierung dupliziert lesestarke Felder, um Joins zu vermeiden, und Einbetten ist die dokumenteigene Verwandte der Denormalisierung. Die Checkliste Einbetten vs. Referenzieren verdichtet sich auf drei Fragen: Zusammen gelesen? Von einem Elternteil besessen? In der Größe begrenzt? Dreimal ja heißt einbetten; ein einziges Nein heißt referenzieren. Und über allem steht die moderne Regel, die allgemeine Ratgeber überspringen: Listen Sie zuerst die Abfragen auf. Ein Modell ist richtig, wenn die Zugriffsmuster, die es bedienen muss, billig sind – die Entitäten allein können Ihnen das nicht sagen.

Typische Anwendungsfälle

• Ein neues Backend entwerfen. Der klassische Durchgang: Entitäten benennen, Kanten zeichnen, Umsetzungen nach der Tabelle oben wählen – vor der ersten Zeile Code.
• Die Verknüpfung-mit-Attributen. Einschreibungen, Mitgliedschaften, Positionen – wenn die Kante selbst Daten trägt (Datum, Menge, Rolle), ist die Verknüpfung (oder eine Kantenklasse mit zwei Pointers) eine vollwertige Entität.
• Ein gewachsenes Schema entwirren. Symptome zeigen auf Kanten: duplizierte Zeilen verraten ein falsch modelliertes Viele-zu-viele; aufgeblähte Dokumente verraten ein unbegrenztes Einbetten.
• Zwischen den Welten migrieren. Relational→dokumentorientiert heißt, jeden FK neu zu entscheiden: einbetten oder Pointer; die Tabelle oben ist das Übersetzungswörterbuch.
• KI- und Analytik-Feeds. Data Warehouses wollen explizite, stabile Kanten – Modellierungsschulden tauchen an dem Tag auf, an dem Sie exportieren wollen.

Wie sollten Sie jede Kante modellieren? Eine Entscheidungsmatrix

Grenzen und Trade-offs

• Modelle frieren Annahmen ein. Kardinalitätsentscheidungen (“ein Benutzer hat eine Adresse”) werden zu Schema; auf dem Papier billig zu ändern, nach dem Start teuer – modellieren Sie für die Kardinalität von morgen.
• Beide Welten bestrafen die nicht indizierte Kante. FK-Spalten und Pointer-Felder sind Join-Pfade; ihre Indizes zu vergessen ist der häufigste stille Performance-Fehler.
• Einbetten tauscht Integrität gegen Lokalität. Keine Engine erzwingt, dass eine eingebettete Kopie mit ihrer Quelle konsistent bleibt – das ist jetzt Ihre Update-Logik.
• Verknüpfungen vervielfachen Joins; Relations verstecken sie. Jeder Viele-zu-viele-Lesevorgang überquert den Kantenspeicher – kalkulieren Sie den Abfragepfad ein, in welcher Welt Sie auch sind.
• Modellieren nach Zugriffsmustern kostet ebenfalls. Auf die Abfragen von heute zu optimieren kann das Schema an das Produkt von heute binden; behalten Sie das konzeptionelle Modell als neutrale Referenz.

Datenmodellierung mit Back4app

Back4app ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine verwaltete Datenbank, automatisch generierte REST- und GraphQL-APIs, Authentifizierung, Dateispeicher und Serverless-Funktionen mit Cloud Code kombiniert. Ihr Modellierungsvokabular ist die Dokumentspalte der Tabellen oben, zur ersten Klasse erhoben: Pointers sind typisierte Eins-zu-viele-Kanten, Relations tragen Viele-zu-viele ohne handgebaute Verknüpfungstabelle, und Arrays decken die begrenzten Wenigen ab. Jede Kante, die Sie deklarieren, ist sofort begehbar – include() folgt Pointers in einer Anfrage, GraphQL verschachtelt Relations in einer Abfrage – und das Schema bleibt im Dashboard sichtbar und bearbeitbar, sodass das physische Modell nie aus dem Blickfeld des Teams gerät, das das konzeptionelle entworfen hat.