Bis zur dritten Normalform entwerfen, dann zurückrudern

🌐 Auch in 28 Sprachen

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada)

Mit KI erstelltes Bild

Von KI übersetzt. Noch nicht von der Community geprüft. Auf Englisch lesen

Modul 5 von 6 im Kapitel Daten nach ihrer Bedeutung modellieren, Kapitel 2 des Kurses Data Architect. Jedes Modul steht für sich. Zurück: Daten dorthin, wo sie hingehören · Weiter: Das Modell in Salesforce umsetzen

Die Frage, die dieses Modul beantwortet: Wann sollte ich mich bewusst von einem sauber normalisierten Modell entfernen?

Im letzten Modul habe ich Ihnen gesagt, auf die dritte Normalform hin zu entwerfen.

Jetzt sage ich Ihnen, dass Sie sie brechen sollen.

Manchmal.

Das ist ein wichtiger Unterschied. Es ist etwas ganz anderes, versehentlich ein unordentliches Datenmodell zu bauen oder ein sauberes bewusst zu denormalisieren. Wenn Sie gar nicht verstehen, wohin die Daten gehören, ist es keine Architektur, sie woandershin zu kopieren. Es ist nur Duplizierung.

Aber sobald ich das saubere logische Modell verstehe, kann ich bewusst entscheiden, die Daten für die Menschen und Systeme, die sie nutzen, anders zu formen.

Bis zur dritten Normalform entwerfen, wo es machbar ist. Dann zurückrudern, wo es nötig ist.

Beachten Sie, was dieser Satz nicht sagt. Er sagt nicht, dass die dritte Normalform leichter zu verstehen ist. Manchmal ist sie schwerer: Ein vollständig normalisiertes Modell kann eine Geschäftsidee über fünf Objekte verstreuen, und die Menschen, die damit arbeiten, müssen sie im Kopf wieder zusammensetzen. Die Normalisierung sagt mir, wohin jede Tatsache gehört. Sie verspricht nicht, dass das die am leichtesten zu lesende, zu nutzende oder auszuwertende Form ist. Genau deshalb ist das Zurückrudern eine Entwurfsfähigkeit und kein Versagen.

Modellieren Sie zuerst die Wahrheit. Dann entscheiden Sie, wie diese Wahrheit geliefert werden muss.

Sitz, Bleib, Modell

Zurück zu den Hunden, und diesmal treffen wir ein paar bewusste Entscheidungen.

Rasse: eine Auswahlliste oder eine eigene Tabelle? Gehen Sie die Fragen durch, die ich Ihnen später in diesem Modul gebe. Gibt es mehr als eine Spalte an Informationen? Ja: zumindest die Grösse. Wie viele Werte? Hundezuchtverbände erkennen einige Hundert Rassen an (der American Kennel Club allein führt 205), weit über meiner Faustregel von etwa 20. Also verdient sich die Rasse eine eigene Tabelle, und jeder Hund verweist auf seine Rasse. Damit ist die Frage geklärt, die wir seit Modul 1 mit uns tragen: Die Rasse ist ein eigener Kasten.

Niveau: eine Auswahlliste. Lernt noch, Gut, Profi. Drei Bezeichnungen, sonst gibt es nichts darüber zu sagen, und sie ändern sich nicht. Genau dafür ist eine Auswahlliste da.

Wie viele Tricks kann jeder Hund? Die Antwort steckt schon im Modell: Zählen Sie die Hundetrick-Datensätze des Hundes. Aber die Hundetrainerin will diese Zahl in jedem Bericht, um danach zu sortieren und zu filtern, ohne einen Bericht über zwei Tabellen zu bauen. Also rudere ich zurück und führe eine Zahl Anzahl Tricks direkt beim Hund. Das ist eine Kopie. Die Wahrheit lebt weiterhin im Hundetrick; die Zahl ist eine Darstellung davon und muss Schritt halten. Salesforce gibt uns einen sauberen Weg, genau das zu tun, und den sehen wir in Modul 6.

Jetzt die Wendung: Die Hundeschule nimmt auch Katzen auf. Was tun wir? Eine Möglichkeit: eine Tabelle Katze neben die Tabelle Hund setzen und einen Katzentrick neben den Hundetrick. Alles verdoppelt sich: jede Maske zweimal, jeder Bericht zweimal, und an dem Tag, an dem Kaninchen dazukommen, dreimal. Die andere Möglichkeit: einen Schritt zurücktreten und bemerken, dass eine Katze eine haltende Person hat, vielleicht einen Zuchtbetrieb, eine Rasse, ein Geburtsdatum und, mit Geduld, einen Trick oder zwei. Dieselben Tatsachen und dieselben Beziehungen wie ein Hund. Also verallgemeinern wir: ein Haustier mit einer Tierart, Hund oder Katze. Auch jede Rasse gehört zu einer Tierart, und dort lebt die Tierart wirklich: Ein Labrador ist ein Hund. Das Haustier trägt eine Kopie, mit Absicht, damit jede Maske und jeder Bericht mit «Hund oder Katze?» beginnen kann, ohne die Rasse nachzuschlagen. Noch eine bewusste Kopie, und in Modul 6 bekommt sie eine eigene Aufgabe.

Das ist Entwerfen für Veränderung, und es ist ein Kompromiss. Verallgemeinern Sie zu früh, wird alles zu einem vagen «Ding» mit einem Typfeld, das niemand versteht. Ich verallgemeinere, wenn das Geschäft mir tatsächlich die zweite Art bringt und die beiden fast alles teilen, so wie Hunde und Katzen hier. Bräuchten Katzen ganz andere Tatsachen, würde ich es mir zweimal überlegen.

Click to enlarge

Jetzt dieselbe Art von Entscheidungen bei Steve Trucking, wo mehr auf dem Spiel steht.

Das sauberste Modell ist nicht immer das beste System

Stellen Sie sich eine Crew an einem Stopp vor. Die Lieferung hat ihre Positionen. Die Installation hat eine Checkliste. Jeder Schritt braucht Fotos. Der Empfänger unterschreibt.

Das normalisierte Modell ist wunderschön: Lieferung → Lieferposition → Installations-Checkliste → Foto, jedes an seinem Platz.

Dann setze ich mich mit den Menschen zusammen, die es tatsächlich nutzen. Eine Crew schliesst etwa zehn Stopps am Tag ab, in Einfahrten, oft ohne Empfang. Wenn mein schönes Modell sie durch ein Labyrinth aus Bildschirmen und Themenlisten schickt, um einen einzigen Stopp abzuschliessen, habe ich ein Architekturproblem.

Das Datenmodell ist nicht das Einzige, was wir entwerfen.

Wir entwerfen ein System.

Manchmal gewinnt die Benutzererfahrung

Das ist einer der Gründe, warum ich mich manchmal von einem perfekt normalisierten Modell entferne: Benutzererfahrung.

Vielleicht könnte ein Konzept technisch eine eigene Entität sein, aber die Trennung bringt Komplexität, die sehr wenig Wert liefert. Vielleicht ist ein übergeordneter Datensatz mit mehreren Ebenen untergeordneter Datensätze akademisch sauber, aber eine Qual beim Erfassen und Pflegen. Vielleicht ist das Konzept klein, stabil und wird vor allem als Auswahl verwendet.

Hier höre ich auf, nur zu fragen: «Wohin gehört diese Tatsache theoretisch?», und beginne zu fragen: «Wie wird dieses System tatsächlich genutzt werden?»

Das heisst nicht, dass jede Beschwerde über einen zusätzlichen Klick das Modell flacher macht. Es heisst, dass Benutzerfreundlichkeit ein legitimer Eingang für die Architektur ist.

Manchmal gewinnen die Berichte

Berichte sind ein weiterer häufiger Grund.

Jeder Handelspartner möchte eine Scorecard: pünktliche Lieferungen nach Region, nach Monat. Im sauberen Modell kennt eine Lieferung ihr Verteilzentrum, und das Verteilzentrum kennt seine Region. Technisch können wir das durchlaufen.

Aber kann das Berichtswerkzeug es? Können es die Menschen, die ihre eigenen Berichte bauen? Können sie die Frage beantworten, ohne eine Berichtsarchitektur, die komplizierter ist als die Frage selbst?

Dann kopiere oder leite ich die Region vielleicht auf die Lieferung ab, näher an die Stelle, an der sie gebraucht wird.

Jetzt habe ich Duplizierung eingeführt. Also brauche ich eine weitere Frage: Wem gehört die Wahrheit?

Wenn sich der Quellwert ändert, was passiert mit meiner Kopie? Soll sie sich ändern? Oder soll sie behalten, was galt, als die Lieferung stattfand? Das sind verschiedene Anforderungen.

Denormalisierung beseitigt keine Komplexität.

Sie verschiebt sie.

Nachschlagen oder Auswahlliste?

Hier ein kleineres Beispiel, das einem in der Salesforce-Administration ständig begegnet. Wer mit dem System arbeitet, muss aus einer Menge von Werten wählen. Erstelle ich eine weitere Entität und verknüpfe sie, oder verwende ich eine Auswahlliste?

Nehmen Sie den Status einer Lieferung: geplant, verladen, in Zustellung, kurz vor Ankunft, geliefert, installiert, Ausnahme, zurückgegeben. Eine kurze, stabile Liste von Bezeichnungen. Eine Auswahlliste ist genau das, was ich will.

Nehmen Sie jetzt die Art des Stopps: nur Lieferung, Lieferung mit Installation, Lieferung mit Mitnahme. Die trägt eigene Informationen: wie lange der Stopp dauert, welche Fähigkeiten die Crew braucht, welche Installations-Checkliste gilt. Sie ändert sich unabhängig, und das Geschäft pflegt sie. Das ist eine Entität, keine Bezeichnung.

Wenn ich für jedes Konzept, das sich theoretisch normalisieren liesse, ein Objekt erstelle, kann ich ein technisch wunderschönes System bauen, das niemand gern benutzt. Wenn ich jedes Konzept zur Auswahlliste mache, weil es einfach ist, kann ich mich sehr schnell selbst in eine Ecke manövrieren.

Also frage ich: Hat es eigene Informationen? Beziehungen? Ändert es sich unabhängig? Muss es als Daten gepflegt werden? Könnte das Geschäft irgendwann mehr davon brauchen als eine Bezeichnung?

Das sind die Fragen, die ich in einer Entwurfssitzung tatsächlich stelle.

Gibt es mehr als eine Spalte an Informationen? Wenn der Wert eine Beschreibung, eine Dauer, eine Liste von Fähigkeiten, einen Verantwortlichen braucht, ist er keine Bezeichnung mehr.

Wie viele Werte? Meine Faustregel liegt bei etwa 20. Ab 20 Werten beginnt eine Auswahlliste zu versagen, und es ist Zeit, an ein Objekt zu denken. US-Bundesstaaten mit fünfzig sind die Ausnahme, mit der wir leben, und Länder sind schlimmer; mal ehrlich, liebt irgendjemand Länder-Auswahllisten? Ich finde sie lästig.

Entstehen die Werte im Lauf der Zeit, und durch wen? Einen Auswahllistenwert hinzuzufügen ist eine Konfigurationsänderung, also braucht es die Administration. Wenn das Geschäft jede Woche Werte hinzufügt und die Menschen, die sie hinzufügen, nicht zur Administration gehören, stellt eine Auswahlliste vor jeden neuen Wert ein Ticket.

Müssen Menschen danach filtern und berichten? Dafür sind Auswahllisten grossartig. Nachschlagefelder sind nicht so sauber. Jedes Nachschlagefeld fügt einen Sprung hinzu: Ein Berichtstyp folgt nur einer kurzen Kette verknüpfter Objekte (ein benutzerdefinierter Berichtstyp erlaubt höchstens vier Objektbeziehungen), der Bildschirm wird zu Themenlisten in Themenlisten, und der Code wird komplizierter.

Eine Werteliste beginnt ihr Leben oft als Auswahlliste und verdient sich mit der Zeit ein eigenes Objekt. Lassen Sie es sie sich verdienen.

Click to enlarge

Manchmal ändert das Volumen die Antwort

Ein Entwurf, der mit ein paar Tausend Datensätzen wunderbar funktioniert, kann sich mit Millionen ganz anders verhalten.

Schauen Sie also nicht nur auf das Diagramm. Kennen Sie die Zahlen.

Steve Trucking macht etwa eine Million Lieferungen im Jahr, mit 30 Prozent Wachstum pro Jahr. Jede Lieferung sammelt etwa acht Statusaktualisierungen. Das sind dieses Jahr acht Millionen Statusdatensätze und bis zum dritten Jahr etwa 13,5 Millionen pro Jahr. Dazu kommen vier oder fünf Millionen Fotos im Jahr.

Dasselbe Modell. Eine ganz andere Architektur.

Wir gehen in Architecting at Scale viel tiefer. Merken Sie sich vorerst: Das Volumen kann eine Entscheidung der Datenmodellierung ändern. Eine Beziehung, die logisch richtig ist, ist nicht automatisch in jeder Grössenordnung der beste physische Entwurf.

Jede Nutzung will ihre eigene Form

Bisher haben wir an das operative System gedacht. Die Disposition plant Lieferungen. Crews schliessen Stopps ab. Das System ändert sich, während das Geschäft läuft.

Aber das Geschäft möchte auch Jahre an Historie analysieren. Welche Partner und Regionen sind unpünktlich? Wie hat sich die Lieferzeit verändert? Wie oft braucht eine Installation einen zweiten Besuch?

Ein analytisches System möchte dieselben Informationen vielleicht anders organisiert haben. Sie werden Begriffe wie Data Warehouse, Fakt, Dimension und Sternschema hören. Die entpacken wir hier nicht; bei Steve Trucking ist das das Snowflake-Warehouse, und wir kommen später im Kurs darauf zurück.

Für jetzt: Verschiedene Nutzungen brauchen vielleicht verschiedene Formen derselben Wahrheit.

Auch KI nutzt die Daten

Und jetzt nutzt noch etwas die Daten: KI.

Ein Empfänger schreibt: «Wo ist meine Lieferung?» Ein KI-Assistent könnte Folgendes nachschlagen:

Lieferung 10427, Tour 3312, Stopp 7, Lastwagen 117, Zeitfenster 13:00–15:00.

Eine klassische Anwendung folgt diesen Beziehungen völlig problemlos. Aber um dem Empfänger zu antworten, braucht der Assistent einen Kontext, der aus mehreren Stellen zusammengesetzt ist:

Ihr Redrock-Geschirrspüler ist der siebte Stopp auf der heutigen Tour ab dem Verteilzentrum Phoenix. Der Lastwagen ist drei Stopps entfernt, und Sie liegen noch in Ihrem Zeitfenster von 13 bis 15 Uhr.

Wir haben Informationen aus mehreren verknüpften Entitäten genommen und für eine bestimmte Nutzung eine flachere, kontextreiche Darstellung zusammengesetzt.

Das heisst nicht, dass ich mein normalisiertes Modell zerstöre. Und es heisst ganz sicher nicht: «KI mag flache Daten, also packen wir alles in ein riesiges Objekt.» Tun Sie das nicht.

Die Quelle der Wahrheit bleibt sauber. Die KI bekommt eine Darstellung, die für ihre Aufgabe gebaut ist. Es ist dieselbe Idee, die wir gerade bei den Analysen gesehen haben:

Eine Quelle der Wahrheit kann mehrere Formen für die Nutzung tragen.

Auf Grounding und Retrieval gehen wir später im Kurs viel tiefer ein.

Schaffen Sie keine mehrfachen Wahrheiten

Hier lauert eine Gefahr.

Wenn ich die Region für Berichte auf die Lieferung kopiere, eine flachgeklopfte Version an Snowflake schicke und eine kontextreiche Version für den KI-Assistenten baue, welche ist dann richtig?

Diese Frage braucht eine Antwort. Ich möchte wissen, wo der massgebliche Wert liegt. Alles andere ist eine Darstellung dieser Wahrheit für einen Zweck.

Dieser Ort ist das führende System (System of Record). Denormalisierte Kopien können gut sein: Der Stopp-Bildschirm, die Scorecard, Snowflake und der KI-Kontext erfüllen ihre Aufgabe jeweils besser mit einer für sie gebauten Form, und es ist in Ordnung, sich auf sie zu beziehen. Aber wenn sich etwas ändert, beginnt die Änderung im führenden System, typischerweise dem relationalen Modell, und fliesst nach aussen zu jeder Kopie. Niemand korrigiert die Region in Snowflake oder bearbeitet den Kontext der KI von Hand. Korrigieren Sie es an der Quelle, und lassen Sie die Änderung fliessen.

Click to enlarge

Und am wichtigsten ist das, wenn sich Daten ändern. Wenn ein Verteilzentrum heute in eine andere Region wechselt, sollen die Lieferungen vom letzten Monat dann die neue Region zeigen? Vielleicht. Vielleicht nicht. Für die Historie brauche ich vielleicht die Region, die galt, als die Lieferung stattfand. Das ist kein Synchronisationsproblem mehr. Das ist eine Geschäftsentscheidung.

Deshalb sollte Denormalisierung nie zufällig passieren. Jede duplizierte Tatsache wirft Fragen nach Verantwortung, Synchronisation, Historie und Vertrauen auf. Es ist das Abwägungsdenken aus Kapitel 1: Wissen Sie, was Sie kaufen (einen einfacheren Bildschirm, einen einfacheren Bericht, besseren Kontext für die KI) und was Sie dafür zahlen (doppelte Daten, Synchronisation, kompliziertere Verantwortung für die Wahrheit). Und weil wir von einem sauberen logischen Modell ausgegangen sind, können wir auf jede Kopie zeigen und sagen: «Ich weiss, dass das dort drüben hingehört. Ich lege hier eine Darstellung davon ab, wegen dieser Anforderung.» Das ist eine Entscheidung, die wir prüfen, hinterfragen und aufschreiben können, damit die nächsten Architekt:innen wissen, warum.

Was Architekt:innen hier entscheiden

Wenn ich eine Denormalisierung erwäge, entscheide ich:

• Wo die massgebliche Quelle jeder Geschäftstatsache liegt.
• Ob das saubere Modell echte Probleme für Benutzer, Berichte, Volumen oder Leistung schafft.
• Ob eine einfachere Darstellung die Duplizierung wert ist und wie die Kopie vertrauenswürdig bleibt.
• Ob sich historische Werte ändern sollen, wenn sich die aktuelle Quelle ändert.
• Ob Analysen oder KI eine andere Form der Daten brauchen als das operative System.

Der Ausgangspunkt ändert sich nie: Wissen Sie, wohin die Wahrheit gehört. Dann, wenn die Anforderungen es rechtfertigen, formen Sie sie für die Lieferung.

Als Nächstes kommt Salesforce wieder ins Bild. Wir werden das, was wir entworfen haben, in ein physisches Datenmodell verwandeln.

Weiterlesen

• Build Powerful Reports with Custom Report Types (opens in a new tab), Salesforce Admins, 24. Juni 2019 (auf Englisch, geprüft am 2026-10-12): Ein benutzerdefinierter Berichtstyp «can span up to 4 object relationships» (kann bis zu 4 Objektbeziehungen umfassen).
• Unleash the hounds, terriers and lapdogs: American Kennel Club recognizes 3 more breeds (opens in a new tab), PBS NewsHour, 2. Januar 2026 (auf Englisch, geprüft am 2026-10-12): «The AKC recognizes 205 breeds, including these three newcomers.» (Der AKC erkennt 205 Rassen an, darunter diese drei Neuzugänge.)
• Zum Spass: die FCI-Rassenliste (Breeds Nomenclature) (opens in a new tab), Fédération Cynologique Internationale (auf Englisch, geprüft am 2026-10-12): die Rassenliste des internationalen Dachverbands, in zehn Gruppen. Scrollen Sie durch, und Sie sehen, warum sich die Rasse eine eigene Tabelle verdient hat.