Das Modell in Salesforce umsetzen
Auch in 28 Sprachen
English · Español · 日本語 · Português (Brasil) · Français · 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) · Deutsch (Schweiz)
Modul 6 von 6 im Kapitel Daten nach ihrer Bedeutung modellieren, Kapitel 2 des Kurses Data Architect. Jedes Modul steht für sich. Zurück: Bis zur dritten Normalform entwerfen, dann zurückrudern · Weiter: der Lernleitfaden zum Kapitel, dann das nächste Kapitel: Salesforce-Datenarchitektur
Die Frage, die dieses Modul beantwortet: Wie wird aus einem logischen Datenmodell ein physisches Salesforce-Datenmodell?
Endlich sprechen wir über Salesforce. Wenn Sie dem Drang widerstanden haben, jeden Kasten in ein Objekt zu verwandeln, dürfen Sie es jetzt. Aber beachten Sie die Reihenfolge, in der wir hierhergekommen sind: Wir haben das Geschäft verstanden, die Daten beschrieben, jede Tatsache dorthin gelegt, wo sie hingehört, und entschieden, wo wir das bewusst biegen. Erst jetzt frage ich, wie Salesforce es umsetzen sollte. Diese Abfolge sollen Sie sich merken: konzeptionell → logisch → physisch. Das konzeptionelle Modell beschreibt das Geschäft. Das logische Modell beschreibt die Daten. Das physische Modell beschreibt, wie wir es tatsächlich bauen.
Sitz, Bleib, Modell
Abschnitt betitelt „Sitz, Bleib, Modell “Der physische Schritt ist an etwas Kleinem am leichtesten zu sehen, also kommen die Haustiere zuerst.
Wer sind die Unternehmen und die Menschen? Der Zuchtbetrieb ist ein Unternehmen, also wird er ein Account mit dem Datensatztyp Breeder (Züchter:in). Halter:innen sind ebenfalls Accounts, oder Personenaccounts, mit dem Datensatztyp Owner (Halter:in). Zwei Arten desselben Standardobjekts, nebeneinander oben im Diagramm, genau dort, wo sie seit Modul 1 stehen.
Was hat kein Standardzuhause? Haustier, Rasse, Trick, Haustiertrick und Trickbewertung werden benutzerdefinierte Objekte. Und erinnern Sie sich an die Tierart, die wir in Modul 5 auf das Haustier kopiert haben? Hier bekommt sie ihre Aufgabe: Sie wird der Datensatztyp des Haustiers, Hund oder Katze. Ein Objekt mit zwei Datensatztypen, jeder mit eigenem Seitenlayout und eigenen Auswahllistenwerten, statt eines Objekts Hund und eines Objekts Katze.
Welche Beziehungen sind Master-Detail? Ich verwende Master-Detail nur dort, wo das untergeordnete Element nie neu zugeordnet wird. Ein Haustiertrick gehört sein Leben lang zu seinem Haustier, und jede Trickbewertung gehört zu ihrem Haustiertrick, also sind beide Master-Detail. Das zahlt sich sofort aus: Master-Detail ist das, was dem Haustier eine Rollup-Zusammenfassung seiner Haustiertricks ermöglicht, sodass die Zahl Anzahl Tricks aus Modul 5 von selbst Schritt hält. Haustiere wechseln aber das Zuhause, also ist die haltende Person eine Nachschlagebeziehung.
Welche sind Nachschlagebeziehungen? Salesforce empfiehlt nicht mehr als 10.000 untergeordnete Datensätze an einem einzigen übergeordneten Datensatz. Ein beliebter Trick wie Sitz, eine häufige Rasse oder ein großer Zuchtbetrieb könnte das leicht überschreiten, also verweist der Haustiertrick mit einer Nachschlagebeziehung auf seinen Trick, und das Haustier verweist auf dieselbe Weise auf seine Rasse und seinen Zuchtbetrieb. Und vermeiden Sie polymorphe Beziehungen, wo Sie können, also solche, bei denen ein Feld auf mehrere Objekttypen verweisen kann. Sie sind am ersten Tag bequem und später schwieriger für alles, was sie lesen muss: Berichte, Integrationen und jetzt auch Agents.
Was bleibt außerhalb der Plattform? Wenn das Haustier ein GPS-Halsband trägt, das meldet, wo es ist, muss dieser Standort überhaupt nicht hineinkopiert werden. Er kann ein externes Objekt sein, live aus dem Ortungssystem des Halsbands gelesen.
Jede Entscheidung in diesem Diagramm geht auf etwas zurück, das wir vorher entschieden haben, und genau darum geht es. Jetzt derselbe Schritt für Steve Trucking.
Beginnen Sie mit dem logischen Modell
Abschnitt betitelt „Beginnen Sie mit dem logischen Modell “Unser logisches Modell von Steve Trucking enthält jetzt Handelspartner, Verteilzentrum, Ladeliste, Lieferung, Lieferposition, Empfänger, Tour, Stopp, Crew, Lkw und Crew-Zuweisung. Das sind Geschäftskonzepte, und jetzt kann ich beginnen, sie auf Salesforce abzubilden.
Ein Handelspartner könnte ein Account sein. Eine Lieferung könnte auf etwas abgebildet werden, das Salesforce schon für geplante Arbeit im Außendienst hat, oder sie wird ein benutzerdefiniertes Objekt. Für eine Ladeliste passt nichts Standardmäßiges, also wird sie wahrscheinlich benutzerdefiniert. Und der Empfänger ist eine wirklich schwierige Frage: ein Personenaccount, ein Kontakt oder einfach Informationen auf der Lieferung? Diese Frage beantworten wir im nächsten Kapitel gründlich.
Das wichtige Wort ist immer noch könnte. Nehmen Sie die Umsetzung nicht an, nur weil ein Geschäftskonzept wie ein Salesforce-Objekt klingt. Deshalb haben wir zuerst das logische Modell gebaut: Es gibt uns etwas, woran wir den Salesforce-Entwurf prüfen können.
Eine Geschäftsentität heißt nicht automatisch ein benutzerdefiniertes Objekt
Abschnitt betitelt „Eine Geschäftsentität heißt nicht automatisch ein benutzerdefiniertes Objekt “Hier ist eine Falle, die man in der Administration meiden sollte: „Wir haben elf Entitäten identifiziert, also brauchen wir elf benutzerdefinierte Objekte.“ Nein. Eine logische Entität sagt uns, dass das Geschäftskonzept wichtig ist. Sie schreibt nicht vor, wie Salesforce es speichern muss. Ein Konzept kann ein Standardobjekt werden, ein benutzerdefiniertes Objekt, eine Beziehung zwischen Objekten, ein Feld oder ein paar Felder, ein in der Konfiguration gepflegter Wert oder Daten, die ganz außerhalb von Salesforce liegen (die Lieferfotos von Steve Trucking sind dafür ein guter Kandidat). Im physischen Modell werden diese Entscheidungen getroffen, und genau deshalb haben wir sie nicht im ersten Gespräch getroffen.
Attribute werden zu physischen Feldern
Abschnitt betitelt „Attribute werden zu physischen Feldern “Derselbe Übergang geschieht bei den Attributen. Unser logischer Lkw hat eine Fahrzeugnummer, eine FIN, Marke, Modell, Baujahr, Kennzeichen und Status. Jetzt entscheiden wir, wie sie physisch existieren: welches Objekt sie besitzt, welche Feldtypen sie verwenden, welche erforderlich sind, welche eindeutig sein müssen, welche externe Kennungen sind, welche eine Validierung brauchen, welche abgeleitet statt gespeichert werden und welche sensibel sind. Auf der logischen Ebene haben wir gefragt, was ein Lkw bedeutet. Auf der physischen Ebene fragen wir, wie Salesforce einen Lkw darstellt. Verschiedene Fragen.
Beziehungen werden zu Plattformentscheidungen
Abschnitt betitelt „Beziehungen werden zu Plattformentscheidungen “Die ganze Zeit, die wir mit den Beziehungen verbracht haben, zahlt sich hier aus. Wir wissen schon, ob jede eins zu eins, eins zu viele oder viele zu viele ist, erforderlich oder optional, und ob ihre Historie zählt. Jetzt entscheiden wir, wie Salesforce sie umsetzt: eine Nachschlagebeziehung, eine Master-Detail-Beziehung oder ein Salesforce-Verbindungsobjekt (Junction Object), vielleicht eine Verbindung mit eigenen Attributen, denn wie wir festgestellt haben, kann die Beziehung selbst eine geschäftliche Bedeutung haben.
Denken Sie an die Crew-Zuweisung zurück. Wir hätten dieses Kapitel mit „Legen wir ein Salesforce-Verbindungsobjekt zwischen Crew und Lkw an“ beginnen können. Sehen Sie, was wir übersprungen hätten: warum die Beziehung existiert, ob sie ein Datum und eine Tour braucht, ob sie einen Status hat und ob eine Schadensmeldung Wochen später ihre Historie braucht. Diese Geschäftsfragen sagen uns, was eine Crew-Zuweisung ist. Erst dann sollten wir entscheiden, wie Salesforce sie baut und ob Salesforce schon etwas hat, das die Aufgabe erfüllt.
Jetzt zeichnen Sie das physische Modell
Abschnitt betitelt „Jetzt zeichnen Sie das physische Modell “Das Diagramm ändert sich wieder. Das konzeptionelle Modell zeigte Geschäftskonzepte und einfache Linien. Das logische Modell fügte Attribute, Schlüssel, Kardinalität und die in Beziehungen versteckten Entitäten hinzu. Jetzt beginnt das physische Modell, wie Salesforce auszusehen: Standardobjekte, benutzerdefinierte Objekte, Felder, Beziehungstypen und das, was außerhalb der Plattform liegt.
Ich möchte, dass Sie diese drei Diagramme nebeneinanderlegen und die Entwicklung sehen können: nicht drei unzusammenhängende Diagramme, sondern dasselbe Geschäft auf drei Ebenen.
Ein Wort dazu, wie ich sie zeichne, denn das Layout ist Teil der Botschaft. Ich setze das Hauptobjekt in die Mitte, etwas nach unten. Wenn es übergeordnete Objekte hat, setze ich sie etwas darüber, sodass Sie das Modell von oben nach unten und von links nach rechts lesen, so wie das Geschäft darüber denkt. Referenzdaten kommen an die Seite. Auch Farbe bedeutet etwas: Salesforce mache ich immer blau, und für die eigenen Systeme des Unternehmens wähle ich eine Farbe, meist Grün, weil Grün eine schöne, freundliche Farbe ist. Rot verwende ich nicht, und Gelbtöne sind etwas grell. Wenn ein Modell so angeordnet ist, klingt es für mich. Viele Diagramme, die man findet, sind eigentlich Platzverwaltung: Wie parke ich alle meine Autos in meiner vollen Garage? Ich male lieber ein logisches Bild, das der Verstand erfassen kann.
Das physische Modell muss die Plattform respektieren
Abschnitt betitelt „Das physische Modell muss die Plattform respektieren “Salesforce ist keine generische relationale Datenbank. Es hat Vorstellungen von Beziehungen, Eigentümerschaft, Sicherheit und Berichten. Es hat Grenzen, ein eigenes Abfrageverhalten und Automatisierung, und eine Architektur, die beeinflusst, wie sich ein Modell im großen Maßstab verhält. Ein logisches Modell, das an der Tafel perfekt aussieht, muss sich also vielleicht ändern, wenn es physisch wird. Das heißt nicht, dass Salesforce im Weg steht. Es heißt, die Plattform hat eine Form, und gute Architekt:innen verstehen diese Form. Genau darum geht es im nächsten Kapitel.
Manchmal weicht das physische Modell auch bewusst vom sauberen logischen Modell ab, wegen der Denormalisierungsentscheidungen, die wir in Modul 5 getroffen haben. Das ist in Ordnung, solange wir erklären können, warum.
Entwerfen Sie nicht aus dem Setup heraus
Abschnitt betitelt „Entwerfen Sie nicht aus dem Setup heraus “Hier ist eine Gewohnheit, die Sie ablegen sollen, falls Sie sie haben: Ihre Datenarchitektur bei Setup → Objekt-Manager → Neues benutzerdefiniertes Objekt zu beginnen und das Modell unterwegs herauszufinden. Salesforce macht es unglaublich leicht, Dinge zu erstellen; das ist eine seiner Stärken und einer der Gründe, warum schwache Datenmodelle so schnell entstehen. Ein paar Klicks, und Sie haben ein Objekt, ein paar mehr, und Sie haben Felder und eine Beziehung. Dann kommen Daten, Flows werden gebaut, Berichte erstellt, Integrationen hängen davon ab, und das Objekt, das Sie in fünf Minuten erstellt haben, wird sehr teuer zu ändern. Das ist der Umkehrbarkeitstest aus Kapitel 1. Bevor Sie also auf Neues benutzerdefiniertes Objekt klicken, zeichnen Sie das Modell.
Physisch heißt nicht dauerhaft
Abschnitt betitelt „Physisch heißt nicht dauerhaft “Es gibt noch einen Grund, warum ich die drei Modelle getrennt halte: Technologie ändert sich. Heute liegen einige Daten von Steve Trucking auf dem Salesforce-Core. Morgen liegt ein Teil davon vielleicht in Data 360, in einem Warehouse oder in einem System, das wir noch nicht gewählt haben, und der KI-Assistent braucht seine eigene Darstellung. Die physische Architektur kann sich ändern, während die Geschäftskonzepte bemerkenswert stabil bleiben: Handelspartner, Lieferungen und Empfänger gibt es weiterhin. Das macht das logische Modell wertvoll. Es ist eine dauerhafte Beschreibung des Geschäfts, die nicht an die heutige Umsetzung gebunden ist.
Was Architekt:innen hier entscheiden
Abschnitt betitelt „Was Architekt:innen hier entscheiden “Wenn ich ein logisches Modell in ein physisches Salesforce-Modell verwandle, entscheide ich:
- Welche Geschäftsentitäten auf Salesforce-Standardfunktionen abgebildet werden und welche benutzerdefinierte Objekte oder eine andere Darstellung brauchen.
- Wie logische Attribute zu physischen Feldern werden und wie Beziehungen auf der Plattform umgesetzt werden.
- Wo bewusste Denormalisierung in den physischen Entwurf gehört.
- Welche Daten auf Salesforce gehören und welche woandershin.
- Welche Eigenschaften der Plattform erfordern, dass das physische Modell vom logischen abweicht.
Vor allem möchte ich jede Entscheidung rückwärts verfolgen können. Wenn Sie auf etwas in meinem physischen Modell zeigen und fragen: „Warum ist das da?“, sollte ich Sie durch das logische und das konzeptionelle Modell zurück zu etwas führen können, das das Geschäft tatsächlich braucht: Geschäft → konzeptionell → logisch → physisch.
Über die Prüfung hinaus: Was KI ändert. KI kann heute ein Anforderungsdokument in einem Sprung bis zu Salesforce-Objekten und -Feldern bringen. Das macht die Abfolge wichtiger, nicht weniger wichtig: Wenn sie von den Anforderungen direkt zur Konfiguration springt, bitten Sie sie zu zeigen, was dazwischen passiert ist: was sie als Entität eingestuft hat, welche Schlüssel sie gewählt hat, welche Beziehungen sie angenommen hat und wo sie denormalisiert hat. Das sind Architekturentscheidungen, und die Architektur muss sie weiterhin sehen.
Wir haben dieses Kapitel mit einem ersten Gespräch begonnen, in dem wir auf Substantive gehört haben, und wir beenden es mit einem physischen Modell, das wir zum Geschäft zurückverfolgen können. Jetzt, da wir uns entschieden haben, auf Salesforce zu bauen, geht die nächste Frage tiefer: Auf was für einer Datenplattform bauen wir eigentlich?
Weiterlesen
Abschnitt betitelt „Weiterlesen “- Designing Record Access for Enterprise Scale: Parent-Child Data Skew (opens in a new tab), Salesforce Developers, Winter ‘27 (auf Englisch, geprüft am 2026-10-02): „configure parent-child relationships with no more than 10,000 children to one parent record“ (Eltern-Kind-Beziehungen mit nicht mehr als 10.000 untergeordneten Datensätzen pro übergeordnetem Datensatz konfigurieren). Eine Richtlinie zur Datenschieflage, keine harte Grenze; Kapitel 7 geht tiefer.
- Roll-Up Summary Field (opens in a new tab), Salesforce-Hilfe (auf Englisch, geprüft am 2026-10-12): Ein Rollup-Zusammenfassungsfeld zählt oder summiert Detaildatensätze über eine Master-Detail-Beziehung.