Von Google Sheet zum relationalen Schema: Ein schrittweiser Modellierungsplan

Warum Tabellenkalkulationen unordentlich werden, wenn sie zur Datenbank werden

Eine Tabelle ist großartig für eine kleine Liste. Du kannst Spalten spontan ändern, an beliebiger Stelle Notizen hinzufügen und Probleme mit dem Auge beheben. Diese Freiheit bricht zusammen, wenn die Datei zur gemeinsamen Quelle der Wahrheit wird.

Mit wachsendem Datenvolumen tauchen immer wieder dieselben Probleme auf. Du siehst Duplikate, weil es keinen einzigen Ort gibt, um einen Kunden oder ein Produkt zu speichern. Es entstehen widersprüchliche Werte, weil zwei Zeilen sich über dieselbe Information uneinig sind, zum Beispiel eine Telefonnummer. Filtern und Berichtswesen werden frustrierend, weil manche Spalten Listen verbergen ("Tags", "Products", "Attendees") oder Formate mischen ("$1,200", "1200", "1.2k").

Der Wechsel von einem Google Sheet zu einem relationalen Schema geht um Sicherheit. Eine Datenbank erzwingt klarere Struktur, sodass du Daten abfragen, validieren und aktualisieren kannst, ohne neue Widersprüche zu erzeugen.

Ein nützlicher Denkansatz: Eine Zeile sollte ein reales Ding darstellen. Wenn eine Zeile einen Deal, einen Kunden und eine Liste von Produkten repräsentiert, wird das Aktualisieren eines dieser Dinge später schmerzhaft.

Ein kurzer Test: Braucht eine einzelne Zeile jemals zwei Werte für dasselbe Feld?

• Eine Bestellung hat mehrere Produkte
• Ein Projekt hat mehrere Teammitglieder
• Ein Kunde hat mehrere Adressen

Wenn die Antwort ja ist, ist es kein „breites Zeilen“-Problem. Es ist ein „separate Tabelle“-Problem. Sobald du es sauber modellierst, kannst du Formulare und Validierung darauf aufbauen, anstatt dich auf fragile manuelle Änderungen zu verlassen.

Beginne damit, zu definieren, was das Sheet eigentlich bedeutet

Eine Tabelle kann organisiert aussehen und trotzdem für verschiedene Leute etwas anderes bedeuten. Bevor du ein Google Sheet in ein relationales Schema überführst, stimme ab, was das Sheet verfolgt.

Beginne mit Ergebnissen, nicht mit Spalten. Welche Entscheidungen soll die Datenbasis unterstützen: ein wöchentlicher Umsatzbericht, eine Liste überfälliger Tickets, ein Workflow, der Nachverfolgungen zuweist, oder ein schneller Nachschlag während eines Kundengesprächs? Wenn du keine Entscheidung benennen kannst, gehört dieses Feld oft nicht in die Datenbank.

Zieh als Nächstes die in Kopfzeilen und Notizen versteckten Nomen heraus. Diese werden meist deine zukünftigen Tabellen: customers, orders, products, invoices, tickets, agents, locations. Wenn eine Spalte zwei Nomen mischt (wie „Customer + Company“), speicherst du mehrere Dinge an einem Ort.

Einigt euch früh auf Definitionen

Kleine Bedeutungsunterschiede werden später zu großen Aufräumarbeiten. Klärt die Grundlagen:

• Was zählt als eine „Order“ (ein Angebot, ein bezahlter Kauf oder beides)?
• Was ist ein „Customer“ (Person, Firma oder beides)?
• Kann eine Bestellung mehrere Produkte haben?
• Kann eine E‑Mail mehreren Kunden gehören?
• Was soll „Status“ anzeigen (aktuellen Zustand oder Historie)?

Beispiel: Wenn dein Sheet eine Zeile pro „Order“ hat, das Feld „Products“ aber eine kommaseparierte Liste enthält, entscheide, ob diese Zeile einen Checkout, eine Lieferung oder eine Rechnung repräsentiert. Jede Wahl führt zu einem anderen Schema.

Mache eine Kopie des Originals als nur-lesbar. Du wirst sie verwenden, um zu prüfen, dass die neuen Tabellen weiterhin dieselben Fragen beantworten.

Bereinige das Sheet, damit die Struktur sichtbar wird

Bevor du ein Google Sheet in ein relationales Schema überführst, lass das Sheet wie Daten aussehen, nicht wie einen Bericht. Datenbanken brauchen konsistente Zeilen und Spalten. Dekorative Layouts verbergen Muster, die du modellieren musst.

Entferne Layouttricks wie zusammengeführte Zellen, mehrere Kopfzeilen und Zwischensummen im Datenbereich. Behalte eine Kopfzeile und danach nur Datensätze als Zeilen. Wenn du Summen brauchst, lege sie auf ein separates Zusammenfassungs-Tab, damit sie nicht mit echten Datensätzen vermischt werden.

Mache dann Formate innerhalb jeder Spalte konsistent. Eine Datenbank kann nicht erraten, dass „1/2/24“, „2024-02-01“ und „Feb 1“ dasselbe Datum sind. Gleiches gilt für Telefonnummern, Währungen und Namen. Wähle ein Format und verwende es überall, auch wenn es streng wirkt.

Ein kurzer Cleanup-Durchgang, der sich meist lohnt:

• Stelle sicher, dass jede Zeile ein Ding repräsentiert (eine Bestellung, einen Kunden, ein Ticket).
• Entferne leere Spacer-Zeilen und -Spalten.
• Ersetze „N/A“, „-“ und leere Strings durch eine Regel, die du beibehältst.
• Markiere, welche Spalten berechnet sind vs. manuell eingegeben.

Markiere abschließend jede Zelle, die mehrere Werte enthält, wie „red, blue, green“ in einer Spalte. Repariere das Schema noch nicht. Markiere diese Spalten nur, damit du dich daran erinnerst, dass sie später zu separaten Zeilen werden.

Identifiziere wiederholende Gruppen und Felder, die Listen verbergen

Das größte Warnzeichen in der Datenmodellierung von Tabellenkalkulationen ist Wiederholung. Sheets quetschen oft „mehr als ein Ding“ in eine einzige Zeile, indem sie Spalten wiederholen oder mehrere Werte in einer Zelle zusammenpacken. Das funktioniert zum schnellen Nachverfolgen, bricht aber, wenn du filtern, berichten oder konsistent aktualisieren musst.

Muster, die meist „das sollte eine andere Tabelle sein“ bedeuten

Scanne nach diesen Formen:

• Nummerierte Spalten wie Item 1, Item 2, Item 3 oder Phone 1, Phone 2.
• Wiederholte Blöcke wie Adressfelder, die für „Home“ und „Work“ dupliziert werden.
• Zellen mit Kommas, Zeilenumbrüchen oder „und“, die Werte kombinieren (z. B. „Mouse, Keyboard, Monitor").
• Eine Spalte, die zwei Konzepte mischt, wie „Approved 2025-01-10“ oder „Alex (Manager)“.
• Eine Zeile, die zwei Ebenen zugleich darstellt, wie eine Order-Zeile, die versucht, alle Order Items zu speichern.

Beispiel: Wenn dein Sales-Tracker Order ID, Customer, Product 1, Qty 1, Product 2, Qty 2 verwendet, stößt du an Grenzen. Manche Bestellungen haben 1 Artikel, andere 8. Das Sheet wächst entweder seitlich ins Unendliche oder beginnt, Daten zu verlieren. Im relationalen Modell wird „Orders“ zu einer Tabelle und „Order Items“ zu einer anderen Tabelle mit einer Zeile pro Produkt in der Bestellung.

Bei „Listen in einer Zelle“ behandle jeden Wert als eigenen Datensatz. Eine Zelle mit „Email, SMS“ bedeutet normalerweise, dass du eine separate Tabelle (oder Join-Tabelle) brauchst, um Kanäle sauber zu verfolgen.

Gemischte Spalten sind leiser, aber genauso riskant. Teile sie früh, damit jedes Feld eine klare Tatsache speichert.

Erstelle Tabellen aus den gefundenen Entitäten

Sobald du die realen Dinge im Sheet benennen kannst, verwandle jedes einzelne in seine eigene Tabelle. Dein Spreadsheet ist nicht mehr ein großes Raster, sondern eine Reihe kleiner, zielgerichteter Listen.

Wenn eine Zeile Details über zwei verschiedene Dinge mischt, braucht sie wahrscheinlich zwei Tabellen. Eine Sales-Tracker-Zeile könnte Kundeninfo (Name, Telefon), Bestellinfo (Datum, Status) und Produktinfo (SKU, Preis) enthalten. Kunden ändern sich nicht bei jeder Bestellung, und Produkte hängen nicht von einer einzelnen Bestellung ab. Durch Trennung verhinderst du doppelte Änderungen und falsche Werte.

Bevor du etwas finalisierst, schreibe für jede Tabelle einen Ein-Satz-Zweck. Wenn du nicht beschreiben kannst, was eine Tabelle darstellt, ohne „und außerdem“ zu sagen, ist sie meist zu breit.

Ein paar praktische Regeln:

• Behalte Attribute, die dasselbe Ding beschreiben und denselben Lebenszyklus teilen, zusammen (Kundenname und Kunden-E-Mail).
• Verschiebe alles, das mehrfach auftreten kann, in eine eigene Tabelle (mehrere Order Items, mehrere Adressen).
• Wenn eine Zelle eine Liste enthält (kommaseparierte Werte, wiederholte Spalten), ist das eine separate Tabelle.
• Wenn zwei Feldgruppen aus unterschiedlichen Gründen ändern, trenne sie (Order-Status vs. Kundenkontaktinfo).

Benenne dann Spalten klar und konsistent. Bevorzuge einfache Nomen und vermeide vage Bezeichnungen wie „Info“ oder „Details“.

Wähle Schlüssel, die im Laufe der Zeit stabil bleiben

Wähle für jede Tabelle früh einen Primärschlüssel. Ein guter Schlüssel ist langweilig: Er ändert sich nie, ist immer vorhanden und identifiziert genau eine Zeile.

Natürliche Schlüssel (echte Werte) können funktionieren, aber nur, wenn sie wirklich stabil sind. Ein SKU ist oft ein guter natürlicher Schlüssel, weil er dauerhaft sein soll. E‑Mail-Adressen wirken stabil, aber Menschen ändern E‑Mails, teilen Postfächer oder erzeugen Duplikate wie „john@“ und „john.work@“. Namen, Telefonnummern und Adressen ändern sich und sind nicht garantiert einzigartig.

Eine sichere Standardwahl ist eine automatisch generierte ID (wie customer_id, order_id). Behalte den realen Identifikator als normales Feld und füge bei Bedarf eine Eindeutigkeitsregel hinzu. Wenn sich eine E‑Mail ändert, bleibt customer_id gleich und zugehörige Bestellungen verweisen weiterhin auf den richtigen Kunden.

Einfache Schlüsselregeln:

• Verwende eine Auto-ID, wenn der reale Identifikator sich ändern könnte, fehlen könnte oder wiederverwendet werden kann.
• Verwende einen natürlichen Schlüssel nur, wenn du ihn kontrollierst und er dauerhaft gedacht ist (z. B. SKU).
• Markiere Felder als eindeutig nur, wenn Duplikate wirklich falsch wären.
• Erlaube NULL nur, wenn „unbekannt“ ein gültiger Zustand ist; andernfalls zwinge einen Wert.
• Schreibe auf, was „eindeutig“ bedeutet (eindeutig pro Tabelle, pro Firma oder pro Zeitraum).

Beispiel: In einer Contacts-Tabelle nutze contact_id als Primärschlüssel. Behalte email nur dann als eindeutig, wenn deine Regel lautet, ein Kontakt = eine E-Mail. Erlaube phone, leer zu sein, weil nicht jeder eine Telefonnummer teilt.

Beziehungen abbilden ohne zu raten

Die meisten schlimmen Fehler entstehen, wenn man rät, wie Dinge zueinander stehen. Nutze eine einfache Regel: Wenn eine Zeile viele Dinge „besitzt“, ist das eins-zu-viele. Setze den Fremdschlüssel auf der „vielen“ Seite.

Beispiel: Ein Customer kann viele Orders haben. Die Orders-Tabelle sollte customer_id speichern. Wenn du eine kommaseparierte Liste von Bestellnummern in Customers behältst, tauchen schnell Duplikate und fehlende Daten auf.

Many-to-Many ist die häufige Tabellenkalkulationsfalle. Wenn eine Order viele Products enthalten kann und ein Product in vielen Orders vorkommt, brauchst du eine Join-Tabelle (oft Line Items genannt). Sie enthält typischerweise order_id, product_id sowie Felder wie Menge und den zum Kaufzeitpunkt gültigen Preis.

One-to-One-Beziehungen sind selten. Sie machen Sinn, wenn Zusatzdaten optional sind oder aus Datenschutz-/Performance-Gründen getrennt werden (z. B. User und UserProfile). Sie sind ein Warnsignal, wenn du eine Tabelle nur deshalb geteilt hast, weil das Sheet zwei Tabs hatte.

Historie braucht eine eigene Struktur. Wenn Werte sich über die Zeit ändern können (Status, Preis, Adresse), vermeide das Überschreiben einer einzigen Spalte. Speichere Änderungen als Zeilen in einer History-Tabelle, damit du fragen kannst „Was galt zu diesem Datum?“.

Genug normalisieren, um Widersprüche zu verhindern

Eine einfache Regel: Speichere eine Tatsache an genau einem Ort. Wenn die Telefonnummer eines Kunden in fünf Zeilen auftaucht, wird jemand vier davon aktualisieren und die fünfte vergessen.

Normalisierung in einfachen Worten:

1NF, 2NF, 3NF praktisch erklärt

Die erste Normalform (1NF) bedeutet, jede Zelle hält einen Wert. Wenn eine Spalte „rot, blau, grün" oder „SKU1|SKU2|SKU3" enthält, ist das eine versteckte Liste. Zerlege sie in Zeilen in einer verwandten Tabelle.

Die zweite Normalform (2NF) zeigt sich meist bei Line Items. Wenn du OrderItems hast und der Schlüssel (OrderID, ProductID) ist, gehören Felder wie CustomerName nicht dorthin. Sie hängen von der Bestellung ab, nicht vom Produkt.

Die dritte Normalform (3NF) bedeutet, Nicht-Schlüssel-Felder sollten nicht von anderen Nicht-Schlüssel-Feldern abhängen. Beispiel: Wenn du ZipCode und City speicherst und City durch ZipCode bestimmt wird, riskierst du Inkonsistenzen.

Ein kurzer Selbstcheck:

• Könnte derselbe Wert an mehr als einer Stelle bearbeitet werden?
• Würde eine Änderung dich zwingen, viele andere Zeilen zu aktualisieren?
• Speicherst du Labels, die sich aus einer ID ableiten lassen?
• Werden Summen neben den Rohdaten gespeichert, die sie erzeugen?

Wann Denormalisierung okay ist

Denormalisiere hauptsächlich für leselastige Reports, und tu es sicher: Behandle die Report-Tabelle als Kopie, die du neu aufbauen kannst. Behalte normalisierte Tabellen als Quelle der Wahrheit.

Bei abgeleiteten Werten wie Summen, Salden und Status dupliziere sie nicht, es sei denn, du hast eine klare Regel zur Neuberechnung. Eine praktische Vorgehensweise: Speichere Rohtransaktionen, berechne Summen in Abfragen und cache Summen nur, wenn die Performance es verlangt.

Häufige Modellierungsfallen, die später aufräumen erfordern

Die meisten „hat im Sheet funktioniert“-Probleme kommen von Bedeutung, nicht von Tools. Ziel ist, dass jede Zeile ein klares Ding sagt, jedes Mal auf dieselbe Weise.

Häufige Fallen:

• Verwendung von Namen als IDs. „John Smith“ ist kein eindeutiger Identifikator, und Namen ändern sich. Nutze eine generierte ID (oder eine verifizierte E-Mail oder Telefonnummer) und behandle Anzeige-Namen als Labels.
• Listen in einer Zelle packen. Es sieht einfach aus, bricht aber bei Suche, Validierung und Reporting. Listen gehören in eine verwandte Tabelle.
• Aktuellen Zustand mit Historie mischen. Eine einzige Status-Spalte kann dir nicht den aktuellen Status und die Änderungsgeschichte gleichzeitig sagen. Wenn Zeit wichtig ist, speichere Statusänderungen als Events mit Zeitstempeln.
• Eine Tabelle überladen, sodass sie mehrere Dinge bedeutet. Ein Contacts-Sheet, das Kunden, Lieferanten und Mitarbeiter enthält, endet meist mit Feldern, die nur für manche Zeilen gelten. Trenne nach Rolle oder behalte eine gemeinsame Person-Tabelle und füge rollen-spezifische Tabellen hinzu.
• Benötigte vs. optionale Felder ignorieren. Wenn Schlüsselspalten leer sein können, entstehen Zeilen, die sich nicht sauber joinen lassen. Entscheide, was erforderlich ist, und erzwinge es früh.

Wenn deine Orders-Tabelle Spalten wie Item 1, Item 2, Item 3 hat, siehst du eine wiederholende Gruppe. Plane eine Orders-Tabelle plus eine OrderItems-Tabelle.

Schnelle Checkliste, bevor du das Schema festschreibst

Bevor du das Schema sperrst, mach einen letzten Durchgang zur Klarheit. Die meisten Datenprobleme später entstehen durch kleine Abkürzungen, die sich anfangs harmlos anfühlen.

Frag, ob jede Tabelle eine einfache Frage beantwortet. „Customers“ sollte Kunden bedeuten, nicht Kunden plus deren letzte Bestellung plus Gesprächsnotizen. Wenn du eine Tabelle nicht in einem kurzen Satz beschreiben kannst, mischt sie Dinge.

Letzte Prüfungen:

• Kannst du auf die Spalte (oder Spaltenkombination) zeigen, die jede Zeile eindeutig identifiziert, selbst wenn Namen sich ändern?
• Enthält eine Zelle mehr als einen Wert (kommaseparierte Tags, mehrere E‑Mails, Item1/Item2-Spalten)? Wenn ja, teile in eine Kindtabelle auf.
• Ist jede Beziehung als absichtlicher Fremdschlüssel gespeichert? Hast du bei Many-to-Many eine Join-Tabelle?
• Haben wichtige Felder Regeln (erforderlich, wenn fehlende Daten den Prozess brechen; eindeutig, wenn Duplikate schädlich sind)?
• Kannst du eine Tatsache (Kundenadresse, Produktpreis, Mitarbeiterrolle) genau an einer Stelle aktualisieren?

Realitätstest: Stell dir vor, jemand gibt denselben Kunden leicht unterschiedlich geschrieben zweimal ein. Wenn dein Schema das leicht macht, füge einen besseren Schlüssel oder eine Eindeutigkeitsregel hinzu.

Beispiel: Ein Sales-Tracker-Sheet in saubere Tabellen verwandeln

Stell dir einen Sales-Tracker vor, in dem jede Zeile ein Deal ist. Er hat Spalten wie Customer Name, Customer Email, Deal Amount, Stage, Close Date, Products (eine kommaseparierte Liste) und Notes (manchmal mehrere Notizen in einer Zelle).

Diese einzelne Zeile verbirgt zwei wiederholende Gruppen: products (ein Deal kann viele Produkte enthalten) und notes (ein Deal kann viele Notizen haben). Hier gehen Konversionen oft schief, weil Listen in Zellen schwer abzufragen und leicht widersprechend sind.

Ein sauberes „Nachher“-Modell, das das tatsächliche Verhalten abbildet:

• Customers (CustomerId, Name, Email)
• Deals (DealId, CustomerId, Amount, Stage, CloseDate)
• Products (ProductId, Name, SKU)
• DealProducts (DealId, ProductId, Quantity, UnitPrice)
• DealNotes (NoteId, DealId, NoteText, CreatedAt)

CustomerId, DealId und ProductId sind stabile Identifikatoren. DealProducts löst die Many-to-Many-Beziehung: Ein Deal kann viele Produkte enthalten, und ein Produkt kann in vielen Deals vorkommen. DealNotes hält Notizen getrennt, sodass du nicht mit „Note 1, Note 2, Note 3“-Spalten endest.

Vor dem Modellieren war ein Bericht wie „Umsatz pro Produkt“ ein Zerlegen von Strings und die Hoffnung, dass Namen konsistent eingegeben wurden. Nach dem Modellieren ist es eine einfache Abfrage über DealProducts verbunden mit Deals und Products.

Nächste Schritte: Vom Schema zur funktionierenden App

Wenn dein Schema auf dem Papier richtig aussieht, überführe es in eine echte Datenbank und teste mit echten Daten. Importiere nicht alles auf einmal. Lade zuerst eine kleine Charge, behebe, was bricht, und wiederhole.

Eine praktische Reihenfolge, die das Risiko niedrig hält:

• Erstelle die Tabellen und Beziehungen.
• Importiere 50 bis 200 Zeilen, überprüfe Summen und prüfe Stichproben.
• Behebe Mappings (falsche Spalten, fehlende IDs, Duplikate) und importiere erneut.
• Wenn es stabil ist, lade den Rest.

Füge Validierungsregeln früh hinzu, damit sich schlechte Tabellen-Gewohnheiten nicht einschleichen. Mache Pflichtfelder wirklich verpflichtend, limitiere erlaubte Werte (z. B. Status), validiere Formate (Datumsangaben und E‑Mails) und nutze Fremdschlüssel, damit du keine Bestellung für einen nicht existierenden Kunden anlegen kannst.

Dann hör auf, das Sheet für Updates zu verwenden. Deine Daten zu schützen ist viel einfacher, wenn Menschen einfache Formulare und klare Workflows benutzen.

Wenn du das Schema ohne Programmierung in ein internes Tool übertragen willst, kann AppMaster (appmaster.io) helfen: Du modellierst Tabellen und Beziehungen visuell und generierst daraus ein produktionsreifes Backend, eine Web‑App und native Mobile‑Apps aus demselben Modell.