Datenmodelle für kleine Webanwendungen entwerfen

Eine kleine Webanwendung beginnt oft mit einer Liste. Später kommen mehrere Ansprechpartner, Projekte oder Aufgaben hinzu. Werden diese Erweiterungen nur als zusätzliche Textspalten angehängt, entstehen schnell doppelte Angaben und unklare Beziehungen. Eine Änderung muss dann an mehreren Stellen gleichzeitig stimmen.

Dieser Leitfaden entwickelt ein bewusst kleines Modell für Kunden, Projekte und Aufgaben. Die Daten sind fiktive Lehrbeispiele. Der ausführbare SQL-Teil verwendet SQLite, damit die Regeln in einer isolierten Datenbank nachvollzogen werden können. Die Übertragung auf MySQL wird als eigener Umsetzungsschritt behandelt und nicht als ungeprüfte Kompatibilitätszusage dargestellt.

1. Fachliche Vorgänge vor Tabellen beschreiben

Beginnen Sie mit den Vorgängen der Anwendung. Im Beispiel wird ein Kunde angelegt, anschließend ein Projekt für diesen Kunden und danach eine Aufgabe im Projekt. Eine Aufgabe besitzt einen Bearbeitungsstatus. Ein Projekt ohne Aufgaben ist erlaubt, eine Aufgabe ohne vorhandenes Projekt dagegen nicht.

Diese Sätze enthalten bereits wichtige Modellentscheidungen. Sie sind aber noch keine allgemeine Wahrheit für jede Agentursoftware. Ein anderes Unternehmen könnte interne Projekte ohne Kunden oder Aufgaben mit mehreren Projektbezügen benötigen. Solche Unterschiede müssen vor der Umsetzung geklärt werden, statt später durch Sonderwerte verdeckt zu werden.

Notieren Sie außerdem, welche Vorgänge ausdrücklich nicht enthalten sind. Unser Modell ist keine Buchhaltung, kein Abrechnungssystem und keine vollständige Kundenverwaltung. Ein Rechnungsbetrag oder eine Vertragslaufzeit wird deshalb nicht beiläufig ergänzt. Jede zusätzliche fachliche Aufgabe kann weitere Regeln und Lebenszyklen benötigen.

Für einen ersten Entwurf reichen kurze Beispiele mit erwarteten Ergebnissen. „Ein bestehendes Projekt wird einem anderen Kunden zugeordnet“ ist etwa eine wichtige Frage. Soll das erlaubt sein? Muss die bisherige Zuordnung nachvollziehbar bleiben? Die Antwort beeinflusst das Datenmodell stärker als die Wahl eines hübschen Tabellennamens.

2. Gegenstände und Eigenschaften unterscheiden

Ein Kunde, ein Projekt und eine Aufgabe können jeweils eigenständig beschrieben werden. Eine Projektbezeichnung ist dagegen eine Eigenschaft des Projekts. Werden mehrere Aufgaben als kommagetrennter Text in eine Projektspalte geschrieben, lassen sie sich später nur schwer unabhängig bearbeiten und zuverlässig verknüpfen.

Diese Trennung hilft bei Änderungen. Wird ein Kundenname korrigiert, muss er nicht in jeder Aufgabe erneut geändert werden. Die Aufgabe verweist über das Projekt auf den Kunden. Die Anwendung kann die zusammengehörigen Informationen bei Bedarf gemeinsam abfragen.

Eine eigene Tabelle ist dennoch nicht für jedes Wort nötig. Ein fester kleiner Statusumfang kann zunächst als kontrollierter Wert gespeichert werden. Wenn Status später zusätzliche Eigenschaften oder frei verwaltete Abläufe bekommen, kann eine eigene Struktur sinnvoll sein. Die Entscheidung folgt dem tatsächlichen Bedarf.

3. Identität von sichtbaren Bezeichnungen trennen

Ein Name ist selten ein geeigneter technischer Schlüssel. Zwei Kunden können gleich heißen und ein Name kann sich ändern. Das Modell verwendet deshalb eine interne ID. Eine sichtbare Kundennummer ist eine zusätzliche fachliche Eigenschaft mit einer eigenen Eindeutigkeitsregel.

Auch eine E-Mail-Adresse ist nicht automatisch die Identität eines Unternehmens. Mehrere Personen können dieselbe Funktionsadresse verwenden und eine Firma kann mehrere Adressen besitzen. Im Beispiel wird deshalb keine E-Mail-Adresse als Kundenschlüssel vorausgesetzt. Kontaktinformationen wären eine gesondert zu klärende Erweiterung.

Für jede Eindeutigkeitsregel ist zu fragen, in welchem Bereich sie gilt. Eine Kundennummer könnte global eindeutig sein oder nur innerhalb einer bestimmten Organisation. In einer Anwendung mit mehreren getrennten Organisationen würde ein alleiniger globaler Vergleich möglicherweise die falsche fachliche Grenze ziehen.

Definieren Sie ebenfalls, wer einen Schlüssel vergeben und ändern darf. Eine automatisch erzeugte interne ID wird anders behandelt als eine von Mitarbeitenden eingetragene Referenznummer. Die sichtbare Nummer sollte nicht unbemerkt dieselbe Rolle wie eine unveränderliche technische Beziehung übernehmen.

4. Beziehungen mit konkreten Mengen prüfen

Im Beispiel besitzt ein Kunde mehrere Projekte. Jedes Projekt gehört genau einem Kunden. Ein Projekt kann mehrere Aufgaben besitzen und jede Aufgabe gehört genau einem Projekt. Diese Beziehungen lassen sich zunächst mit wenigen Kästen und Verbindungslinien aufschreiben.

Kunde 1 ─── n Projekt
Projekt 1 ─── n Aufgabe

Die Zahlen beschreiben die erlaubte Beziehung und keine tatsächlich gemessene Menge. Prüfen Sie besonders die Randfälle. Ist null erlaubt? Darf eine Beziehung später geändert werden? Kann derselbe Gegenstand mehrfach zugeordnet sein? Einfache Beispiele finden Unklarheiten oft schneller als eine große Zeichnung.

Eine Viele-zu-viele-Beziehung benötigt üblicherweise eine eigene Zuordnung. Würde eine Aufgabe mehrere Bearbeiter erhalten, wäre eine Liste von Personennummern in einem Textfeld keine robuste Grundlage. Eine Zuordnungstabelle könnte jede erlaubte Verbindung getrennt speichern und doppelte Zuordnungen verhindern.

Diese Erweiterung ist im folgenden SQL bewusst nicht enthalten. Das Lehrmodell bleibt auf die drei geklärten Gegenstände begrenzt. So werden seine Regeln tatsächlich geprüft, statt eine umfangreiche vermeintliche Universallösung ohne fachliche Abnahme zu präsentieren.

5. Ein ausführbares Schema mit Regeln anlegen

Das folgende Beispiel ist für SQLite geschrieben. Fremdschlüssel werden für die verwendete Verbindung ausdrücklich eingeschaltet. Die offiziellen Erläuterungen zu SQLite-Fremdschlüsseln beschreiben diese erforderliche Behandlung. In anderen Datenbanksystemen werden entsprechende Einstellungen und Voraussetzungen separat geprüft.

PRAGMA foreign_keys = ON;

CREATE TABLE customers (
  id INTEGER PRIMARY KEY,
  customer_number TEXT NOT NULL UNIQUE,
  name TEXT NOT NULL CHECK (length(trim(name)) > 0)
);

CREATE TABLE projects (
  id INTEGER PRIMARY KEY,
  customer_id INTEGER NOT NULL,
  title TEXT NOT NULL CHECK (length(trim(title)) > 0),
  FOREIGN KEY (customer_id) REFERENCES customers(id) ON DELETE RESTRICT
);

CREATE TABLE tasks (
  id INTEGER PRIMARY KEY,
  project_id INTEGER NOT NULL,
  title TEXT NOT NULL CHECK (length(trim(title)) > 0),
  status TEXT NOT NULL DEFAULT 'open'
    CHECK (status IN ('open', 'in_progress', 'done')),
  FOREIGN KEY (project_id) REFERENCES projects(id) ON DELETE RESTRICT
);

CREATE INDEX tasks_project_status ON tasks(project_id, status);

Die CREATE-TABLE-Dokumentation erläutert die eingesetzten Regeln. Das Schema verhindert beispielsweise eine Aufgabe mit einem nicht vorhandenen Projekt. Es entscheidet aber nicht, welcher angemeldete Benutzer diese Aufgabe bearbeiten darf. Berechtigungen bleiben eine zusätzliche Verantwortung der Anwendung.

Die Prüfung auf einen nicht leeren Titel ist bewusst einfach. Sie ersetzt keine vollständige fachliche Eingabeprüfung mit sinnvoller Länge oder speziellen Zeichenregeln. Datenbankregeln und Anwendungsprüfung ergänzen sich. Sie sollten dieselbe fachliche Vereinbarung unterstützen, ohne ihre jeweiligen Grenzen zu verschweigen.

Beachten Sie die genaue Reichweite jeder Regel: NOT NULL verhindert keinen leeren Text. Für die Kundennummer enthält dieses Lehrschema noch keine entsprechende Inhaltsprüfung. Wenn fachlich keine leere Nummer erlaubt ist, muss diese zusätzliche Regel bewusst ergänzt und mit einer leeren Eingabe geprüft werden.

6. Fehlende Werte bewusst behandeln

Ein Pflichtwert wird im Beispiel mit NOT NULL gekennzeichnet. Dabei muss die Fachlichkeit entscheiden, ob eine Information wirklich bei jedem Vorgang vorhanden sein muss. Ein unnötiges Pflichtfeld führt häufig zu Ersatzwerten wie „unbekannt“, die anschließend als scheinbar echte Information weiterverarbeitet werden.

Ein optionales Datum kann unbekannt, noch nicht festgelegt oder für einen Vorgang nicht anwendbar sein. Diese Bedeutungen sind nicht automatisch identisch. Wenn die Anwendung sie unterscheiden muss, braucht sie eine entsprechende Regel. Ein einzelner leerer Text erklärt den Unterschied nicht.

Auch ein Standardwert ist eine fachliche Entscheidung. Der Aufgabenstatus beginnt hier mit „open“. Das ist für das Lehrmodell sinnvoll, weil jede neu angelegte Aufgabe zunächst offen ist. In einem Freigabeverfahren könnte stattdessen ein anderer Anfangszustand erforderlich sein. Ein Standard darf keine notwendige Entscheidung verstecken.

Besprechen Sie typische unvollständige Eingaben mit den späteren Anwendern. Welche Information kann nachgereicht werden? Welche verhindert den Vorgang? Das Ergebnis bestimmt Pflichtfelder und Zwischenzustände. Das Modell sollte die tatsächliche Arbeit abbilden und nicht nur eine formal vollständig ausgefüllte Bildschirmmaske.

7. Zusammengehörige Änderungen als Vorgang betrachten

Das Anlegen eines Projekts und seiner ersten Aufgabe kann ein zusammengehöriger Vorgang sein. Wenn nur einer der beiden Schritte gelingt, wäre der Zustand möglicherweise nicht wie vorgesehen. Eine Transaktion kann dann helfen, die vorgesehenen Änderungen gemeinsam zu bestätigen oder zurückzunehmen.

BEGIN;

INSERT INTO customers (id, customer_number, name)
VALUES (1, 'K-001', 'Fiktiver Beispielbetrieb');

INSERT INTO projects (id, customer_id, title)
VALUES (1, 1, 'Webseitenpflege');

INSERT INTO tasks (id, project_id, title)
VALUES (1, 1, 'Leistungsangaben prüfen');

COMMIT;

Die festen IDs erleichtern das Nachvollziehen der Lehrdaten. Eine reale Anwendung muss ihre Vergabe passend organisieren und konkurrierende Vorgänge berücksichtigen. Die SQL-Anweisungen enthalten ausschließlich feste Beispieldaten. Bei Benutzereingaben werden passende vorbereitete Abfragen und serverseitige Prüfungen verwendet.

Die SQLite-Transaktionsdokumentation beschreibt die Grundoperationen. Eine Transaktion ist kein Ersatz für eine fachlich richtige Grenze. Wenn zusätzlich eine externe Nachricht versendet wird, kann deren Zustand nicht allein durch dieselbe Datenbanktransaktion zuverlässig zurückgesetzt werden.

8. Typische Abfragen bereits im Entwurf bedenken

Ein Datenmodell muss nicht nur Daten aufnehmen, sondern die benötigten Fragen beantworten. Im Beispiel sollen Aufgaben mit Projekt und Kunde angezeigt werden können. Die Beziehungen werden dafür ausdrücklich in einer Abfrage verbunden. Die Namen werden nicht als doppelte Kopien in der Aufgabe gespeichert.

SELECT
  c.customer_number,
  c.name AS customer_name,
  p.title AS project_title,
  t.title AS task_title,
  t.status
FROM customers AS c
JOIN projects AS p ON p.customer_id = c.id
LEFT JOIN tasks AS t ON t.project_id = p.id
WHERE c.id = 1
ORDER BY p.id, t.id;

Der linke Join erhält hier auch ein vorhandenes Projekt ohne Aufgaben im Ergebnis. Ein innerer Join würde diesen Fall anders behandeln. Die Auswahl folgt der tatsächlich gewünschten Liste. Prüfen Sie die Ausgabe deshalb mit leeren und mehrfach belegten Beziehungen.

Ein Index unterstützt bestimmte Zugriffswege, ist aber keine allgemeine Geschwindigkeitsgarantie. Der Beispielindex passt zur Kombination aus Projekt und Status. Welche Indizes eine reale Anwendung benötigt, wird anhand ihrer tatsächlichen Abfragen und Datenmengen untersucht. Jede zusätzliche Struktur beeinflusst auch Schreibvorgänge und Pflege.

9. Löschen und Archivieren früh unterscheiden

Was soll geschehen, wenn ein Kunde noch Projekte besitzt? Im Beispiel verhindert RESTRICT das Löschen über diese bestehende Beziehung. Dadurch muss die Anwendung einen bewussten nächsten Schritt vorsehen. Ein unbemerktes Entfernen aller abhängigen Aufgaben ist nicht Teil der vereinbarten Fachlichkeit.

Ein archivierter Gegenstand bleibt dagegen vorhanden, wird aber möglicherweise in normalen Listen anders behandelt. Archivierung ist kein universeller Ersatz für Löschung. Sie braucht eine eigene Definition: Darf ein archiviertes Projekt noch geändert werden? Bleiben seine Aufgaben sichtbar? Wer darf die Archivierung aufheben?

Die geeignete Aufbewahrung hängt von den konkreten Daten und Vorgängen ab. Dieser technische Entwurf legt keine allgemeine rechtliche Aufbewahrungsfrist fest. Solche Anforderungen werden vor der produktiven Umsetzung mit den zuständigen Verantwortlichen geklärt und anschließend nachvollziehbar abgebildet.

Prüfen Sie Löschfolgen mit Beispieldaten vor einer Veröffentlichung. Ein versehentlicher Automatismus kann mehr zerstören als eine fehlerhafte Listenansicht. Der Rückweg gehört in Sicherungen und kontrollierte Abläufe. Er sollte nicht darauf beruhen, dass jemand eine verlorene Beziehung später aus dem Gedächtnis rekonstruiert.

10. Regeln mit absichtlich falschen Eingaben prüfen

Ein erfolgreicher Eintrag belegt nur einen Teil des Modells. Versuchen Sie zusätzlich, eine doppelte Kundennummer, einen leeren Titel, einen ungültigen Status und einen nicht vorhandenen Projektbezug zu speichern. Die erwartete Ablehnung muss tatsächlich beobachtet werden.

Diese Fälle sind keine Tests gegen produktive Kundendaten. Sie werden in einer isolierten Lern- oder Testdatenbank ausgeführt. Ein vollständiger Testbericht benennt Datenbanksystem, Version und Einstellungen. Besonders eine nicht aktivierte Fremdschlüsselprüfung kann sonst einen falschen Eindruck von erfolgreicher Absicherung erzeugen.

11. Das Modell kontrolliert weiterentwickeln

Neue Anforderungen verändern möglicherweise nicht nur ein Formular, sondern die Bedeutung bestehender Daten. Werden mehrere Ansprechpartner je Kunde benötigt, entsteht eine zusätzliche Beziehung. Ein zweites Feld „Ansprechpartner 2“ kann zunächst bequem wirken, führt aber schnell zu einer künstlichen Obergrenze.

Eine Migration beschreibt die konkrete Strukturänderung und den Umgang mit vorhandenen Daten. Muss ein neuer Pflichtwert rückwirkend gesetzt werden, braucht es eine fachlich begründete Zuordnung. Ein willkürlicher Standard kann die Daten formal gültig und trotzdem inhaltlich falsch machen.

Prüfen Sie die Änderung zunächst mit einer geeigneten Kopie oder synthetischen Daten. Bei produktiven Daten werden Sicherung, Zugriff und Rückweg gesondert behandelt. Eine neue Tabellenstruktur darf keine inzwischen entstandenen Eingaben durch einen alten Gesamtstand ersetzen.

Für die Übertragung auf MySQL müssen unter anderem Datentypen, Schlüsselvergabe, Zeichensatz, Vergleichsregeln und die verwendete Engine geprüft werden. Die MySQL-Dokumentation zu Fremdschlüsseln beschreibt ihre systembezogenen Voraussetzungen. Ein in SQLite bestandener Test belegt nicht automatisch dieselbe Installation in MySQL.

12. Ein kleines Datenwörterbuch pflegen

Dokumentieren Sie für wichtige Felder ihre Bedeutung, Herkunft und erlaubte Änderung. Die Kundennummer ist im Beispiel eine eindeutige fachliche Referenz. Der Status beschreibt den Bearbeitungsstand einer Aufgabe. Solche Definitionen helfen, wenn später eine Schnittstelle oder ein Export hinzukommt.

Benennen Sie außerdem, welche Informationen aus Beziehungen abgeleitet werden. Eine Aufgabenliste kann den aktuellen Kundennamen anzeigen, ohne ihn in jeder Aufgabe zu speichern. Soll dagegen ein historischer Name zu einem bestimmten Zeitpunkt erhalten bleiben, ist das eine andere Anforderung und braucht einen ausdrücklich entworfenen historischen Zustand.

Das Datenwörterbuch sollte mit dem Schema übereinstimmen. Eine lange Beschreibung, die seit mehreren Migrationen veraltet ist, hilft wenig. Halten Sie die wenigen entscheidenden Regeln aktuell und verlinken Sie die zugehörigen Prüffälle. So bleibt der fachliche Grund einer technischen Einschränkung nachvollziehbar.

13. Aktuellen Zustand und Verlauf nicht verwechseln

Der Aufgabenstatus im Beispiel zeigt nur den aktuellen Bearbeitungsstand. Er erklärt nicht, wann die Aufgabe von offen zu in Bearbeitung gewechselt ist oder wer die Änderung vorgenommen hat. Wenn eine solche Nachvollziehbarkeit benötigt wird, muss sie ausdrücklich entworfen werden. Ein zusätzliches Feld für den letzten Änderungszeitpunkt ersetzt keinen vollständigen Verlauf.

Ein Verlauf könnte einzelne erlaubte Zustandswechsel als Ereignisse speichern. Dabei werden die notwendigen Angaben und Zugriffsrechte gesondert festgelegt. Nicht jede kleine Anwendung benötigt diese Erweiterung. Sie sollte jedoch nicht nachträglich behaupten, historische Entscheidungen belegen zu können, wenn bisher nur der letzte Zustand gespeichert wurde.

Auch eine Statistik hängt von dieser Unterscheidung ab. Die Zahl heute erledigter Aufgaben kann bedeuten, dass ihr aktueller Status erledigt ist und ihr letzter Änderungszeitpunkt heute liegt. Das ist nicht zwangsläufig dasselbe wie die Zahl der tatsächlichen Erledigungsereignisse. Eine spätere reine Textkorrektur könnte den Zeitpunkt ebenfalls verändern.

Formulieren Sie deshalb die auszuwertende Frage vor dem zusätzlichen Feld. Welche Tatsache muss später nachweisbar sein? Welche Änderungen sind fachlich relevant? Wie wird ein irrtümlicher Statuswechsel behandelt? Erst diese Antworten bestimmen, ob ein Zeitpunkt, ein gesondertes Ereignis oder eine andere Struktur gebraucht wird.

Für das Lehrmodell bleibt diese Grenze bewusst sichtbar. Es speichert aktuelle Aufgaben mit kontrolliertem Status, aber keinen umfassenden Auditverlauf. Das ist keine verdeckte Schwäche, sondern eine benannte Entscheidung über den begrenzten Umfang. Ein passender erster Entwurf beschreibt seine tatsächlichen Fähigkeiten präzise.

14. Checkliste für den ersten Modellentwurf

• Typische Vorgänge sind vor den Tabellen beschrieben.
• Gegenstände und Eigenschaften sind sinnvoll unterschieden.
• Technische Identität und sichtbare Bezeichnung sind getrennt.
• Beziehungen einschließlich leerer und mehrfacher Fälle sind geklärt.
• Eindeutigkeit, Pflichtwerte und erlaubte Zustände sind ausdrücklich definiert.
• Datenbankregeln wurden in der verwendeten Umgebung tatsächlich geprüft.
• Berechtigungen werden nicht mit Fremdschlüsseln verwechselt.
• Löschung, Archivierung und historische Informationen sind unterschieden.
• Abfragen und Indizes folgen dem tatsächlichen Bedarf.
• Änderungen besitzen einen nachvollziehbaren Migrations- und Prüfweg.

Häufige Fragen

Wie viele Tabellen braucht eine kleine Anwendung?

So viele, wie ihre Gegenstände und Beziehungen sinnvoll benötigen. Eine feste Zahl sagt wenig über Qualität aus. Wenige überladene Tabellen können ebenso problematisch sein wie unnötig viele unklare Strukturen.

Prüft ein Fremdschlüssel die Zugriffsrechte?

Nein. Er kann eine definierte Existenzbeziehung absichern. Welche Person einen Datensatz lesen oder verändern darf, muss die Anwendung zusätzlich entscheiden.

Soll jeder Wert doppelt gespeichert werden, damit Abfragen schneller sind?

Nicht ohne konkreten Grund und klare Pflege der Kopien. Zunächst sollte das fachliche Modell verständlich sein. Gezielte Leistungsmaßnahmen folgen überprüften tatsächlichen Engpässen.

Quellen und passende Vertiefung

Geprüft am 9. November 2026: die verlinkten offiziellen SQLite-Dokumentationen zu Tabellen, Fremdschlüsseln und Transaktionen sowie das MySQL-Handbuch zu Fremdschlüsseln. Modell und Lehrdaten wurden für diesen Beitrag entwickelt.

Die übergeordnete Aufgabenplanung erläutert Was eine professionelle Unternehmenswebseite leisten muss. Die spätere Darstellung der Daten benötigt eine verständliche Oberfläche, deren Grundlagen Semantisches HTML anhand einer vollständigen Beispielseite erklärt.