Denken wie Datenarchitekt:innen

🌐 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)

Mit KI erstelltes Bild

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

Lernleitfaden zu Kapitel 1 des Kurses Data Architect. Lesen Sie zuerst die sieben Module; diese Seite hilft Ihnen zu prüfen, was hängen geblieben ist.

Über diesen Lernleitfaden. Er beruht ausschließlich auf den Inhalten dieses Kurses und der veröffentlichten Liste der Prüfungsziele im Prüfungsleitfaden von Salesforce. Er basiert niemals auf echten Prüfungsfragen und behauptet nicht zu wissen, was in der Prüfung vorkommt. Wenn Sie die Prüfung abgelegt haben, schicken Sie mir bitte keine Fragen daraus: Die Zertifizierungsvereinbarung verbietet es, sie weiterzugeben, und Antworten auswendig zu lernen ist ohnehin der falsche Weg in die Architektur.

Dieses Kapitel enthält bewusst weniger Prüfungsfakten. Es geht darum, wie Architekt:innen denken, und kein Prüfungsziel gehört allein zu ihm. Aber die Prüfung besteht aus Szenarien: ein Unternehmen, ein paar Zahlen, eine Einschränkung und mehrere Antworten, die funktionieren könnten. Die Gewohnheiten aus diesem Kapitel sind die Art, wie Sie diese Szenarien lesen. Die Checkliste unten nennt daher, welches Ziel jeder Punkt unterstützt, statt zu behaupten, er werde direkt geprüft.

Für die Prüfung

Haken Sie die Punkte ab. Jeder verweist auf die Stelle, an der er behandelt wird.

Ein Szenario lesen wie Architekt:innen (unterstützt jedes Ziel)

• Ich trenne die echte Anforderung von dem Entwurf, in dem sie daherkam („Wir brauchen Felder für Genehmiger 2 und Genehmiger 3“ gegenüber „Wir müssen jede Genehmigung erfassen“). (Nehmen Sie die Anforderung nicht einfach hin)
• Ich suche die stillschweigenden Anforderungen, die niemand genannt hat: Verantwortung, Aktualität, Ausfall, Aufbewahrung, Zugriff. (Suchen Sie die stillschweigenden Anforderungen)
• Ich lege Zahlen darauf: Volumen pro Tag, pro Jahr, mit Wachstum, und ich bemerke, wenn eine Null mehr die Antwort ändert. (Kennen Sie Ihre Zahlen)
• Unter mehreren Antworten, die funktionieren, vergleiche ich, was jede gewinnt und aufgibt, gemessen an den genannten Anforderungen und Einschränkungen. (Wissen, was Sie dafür hergeben, Einschränkungen ändern die Antwort)
• Ich behandle Kosten, Lizenzen und Grenzen als Teil der Frage, ob ein Werkzeug passt, nicht als Nachgedanken. (Die neun Fragen)

Das Datenmodell (unterstützt DM-1)

• Ich kann ein Modell danach beurteilen, ob es das Geschäft trägt, mit ihm wachsen kann und Leistung bringt. (Tragen. Wachsen. Leisten.)
• Ich erkenne ein Modell, das zu flach ist (Feld 1, Feld 2, Feld 3), übernormalisiert oder auf dem falschen Standardobjekt aufgebaut. (Zu flach, zu kompliziert oder einfach falsch)
• Ich weiß, warum eine Auswahlliste zu einer kurzen, stabilen Liste passt und eine Nachschlagebeziehung zu einer Liste, die weiterwächst oder aus einer Integration kommt. (Viele Wege, das Problem zu lösen)
• Ich weiß, dass ein Schlüssel, der Bedeutung trägt (etwa einen Teil eines Namens), bricht, wenn sich diese Bedeutung ändert. (Manche Entscheidungen lassen sich billig ändern)

Bestehendes ändern (unterstützt DM-1 und SDM-2)

• Ich weiß, warum es später zu Brüchen führen kann, den Typ eines Felds zu ändern oder ein bestehendes Feld erforderlich zu machen, und warum die Plattform eine Typänderung blockiert, solange Code oder Flows auf das Feld verweisen. (Vorsicht beim Ändern des Skeletts)
• Ich kenne das Muster hinzufügen statt verändern, abkündigen statt überraschen, und weiß, dass Field Usage ein Feld als Kandidaten für die Abkündigung markieren kann. (Vorsicht beim Ändern des Skeletts)
• Ich kenne die Master-Detail-Fakten hinter dem Umkehrbarkeitstest: Zugriff und Eigentümerschaft des Details folgen dem Master, das Löschen eines Masters löscht seine Details, Rollup-Zusammenfassungen brauchen Master-Detail, und eine Nachschlagebeziehung lässt sich nur in Master-Detail umwandeln, wenn jeder Datensatz einen Wert hat. (Der Umkehrbarkeitstest, Weiterlesen)

Lizenzen und Freigabe (unterstützt SDM-1)

• Ich weiß, dass Community-Benutzer mit hohem Volumen (darunter Customer Community) keine Rollen haben und das Freigabemodell nicht nutzen, ihr Zugriff also aus Freigabesätzen und Freigabegruppen kommt und Apex-Freigabe sie nicht erreicht. (Ein durchgerechnetes Beispiel: Apex-Freigabe)

Scheitern (unterstützt MIG-1 und die Integrationskapitel)

• Ich weiß, dass „Job abgeschlossen“ nicht dasselbe ist wie die Daten sind korrekt, und wie ein Abgleich die Datensätze findet, die nicht angekommen sind. (Teilerfolg ist immer noch ein Scheitern, das Sie verstehen müssen)

Über die Prüfung hinaus

Die Prüfung ist der Boden, nicht die Decke. Das sind die Gewohnheiten aus diesem Kapitel, die Architekt:innen brauchen, ob eine Frage je danach fragt oder nicht.

• Jemand muss den Bauplan halten. Architektur heißt, mit unvollständigen Informationen gute Entscheidungen zu treffen und ihre Folgen zu kennen.
• Das Datenmodell ist das Skelett. Alles andere baut darauf auf.
• Der Umkehrbarkeitstest: Wie schwer ist das rückgängig zu machen, und wie viel wird davon abhängen?
• Architektur erzeugt Schwerkraft. Abhängigkeiten machen Veränderung teuer, nicht die Veränderung selbst.
• Denken Sie an den Explosionsradius, in Salesforce und im ganzen Unternehmen. Architektur ist Gegenverkehr.
• Schreiben Sie das Warum auf: Kontext, Optionen, Entscheidung, Folgen, Verantwortlicher, Überprüfung. Ersetzen, nicht löschen.
• Die beste worin? Eine suboptimale Entscheidung kann Teil einer optimalen Architektur sein, wenn Sie wissen, dass Sie sie treffen.
• Tragen Sie ein Bild von optimal im Kopf, damit Sie wissen, in welche Richtung Sie davon abweichen, und warum.
• Think Correct. Think Fast. Geschwindigkeit entsteht aus Denken, das vor dem Moment geschehen ist.
• Für heute bauen. Für morgen planen. Für das Scheitern planen. Und nehmen Sie 30 Prozent Wachstum, wenn Ihnen niemand eine Zahl nennt.
• Lernen Sie die neun Fragen, nicht nur die Antworten.
• KI ist eine Trägerrakete. Generieren ist nicht Urteilen, unumkehrbar bleibt unumkehrbar, und menschliche Prüfung ist keine Zeremonie. Vertrauen, aber überprüfen.

Wichtige Begriffe

Begriff	In einer Zeile
Architekturentscheidung	Eine, die schwer rückgängig zu machen ist und von der viel abhängt
Umkehrbarkeitstest	Wie schwer ist das rückgängig zu machen, und wie viel wird davon abhängen?
Schwerkraft	Die Abhängigkeiten, die sich mit der Zeit um eine Entscheidung sammeln
Explosionsradius	Alles andere, was sich bewegt, wenn sich eine Entscheidung ändert
Entscheidungsaufzeichnung	Kontext, Optionen, Entscheidung, Folgen, Verantwortlicher und Überprüfungszeitpunkt, knapp gehalten
Abwägung	Was eine Option gewinnt und was sie dafür aufgibt
Stillschweigende Anforderung	Etwas, das das Geschäft erwartet, ohne zu fragen, etwa eine Wiederherstellung, wenn ein Ladelauf scheitert
Steves Anzahl der Nullen	Eine Null mehr im Volumen kann die ganze Architektur verändern
Abgleich	Vergleichen, was hätte passieren sollen, mit dem, was passiert ist, Datensatz für Datensatz
Abkündigen	Etwas als auslaufend markieren und dann bewusst stilllegen, statt es an Ort und Stelle zu ändern
Benutzer mit hohem Volumen	Ein Community-Benutzer (darunter Customer Community) ohne Rolle, außerhalb des Freigabemodells
Schema-Wildwuchs	Objekte und Felder, die sich anhäufen, weil sie billig zu erstellen waren, bis niemand mehr das Modell entworfen hat

Prüfen Sie sich

Kurze Szenarien im Stil des Kurses. Entscheiden Sie sich für Ihre Antwort, bevor Sie sie aufklappen.

1. Ein Vertriebsteam möchte auf der Opportunity Felder für Genehmiger 2 und Genehmiger 3, jeweils mit Datum. Was fragen Sie, und was könnten Sie bauen?

Fragen Sie nach dem Warum und danach, wie viele Genehmigungen es geben kann. Wenn es mehr als zwei oder drei sein können, ist die Anforderung, jede Genehmigung zu erfassen, nicht Felder hinzuzufügen: ein untergeordnetes Objekt, ein Datensatz pro Genehmigung. Lesen Sie noch einmal Nehmen Sie die Anforderung nicht einfach hin.

2. Jemand möchte die Beschriftung eines Felds umbenennen, und jemand anderes möchte das Format der Kundenkennung ändern, die fünf Systeme bereits speichern. Was verdient mehr Ihrer Aufmerksamkeit, und warum?

Die Kennung. Die Beschriftung ist billig zu ändern. Die Kennung fällt durch den Umkehrbarkeitstest: schwer rückgängig zu machen, und vieles hängt schon von ihr ab. Verteilen Sie Ihre Aufmerksamkeit im Verhältnis zu den Kosten eines Irrtums. Lesen Sie noch einmal Manche Entscheidungen lassen sich billig ändern.

3. Ein Textfeld ist seit Jahren in Gebrauch. Das Geschäft möchte, dass es jetzt eine Zahl enthält. Wie gehen Sie vor?

Verändern Sie es nicht an Ort und Stelle. Finden Sie heraus, was davon abhängt (Flows, Apex, Berichte, Integrationen, Agenten) und was mit den alten Daten geschieht. Meist: ein neues Feld hinzufügen, bewusst migrieren und das alte abkündigen. Lesen Sie noch einmal Vorsicht beim Ändern des Skeletts.

4. 1.200 Standorte, 100 Termine pro Standort und Tag, etwa 305 Tage im Jahr, zwei Datensätze pro Termin, fünf Jahre Aufbewahrung, 30 Prozent Wachstum. Ungefähr wie viele Datensätze, und warum ist das wichtig?

Etwa 73 Millionen Datensätze im ersten Jahr (36,6 Millionen Termine, je zwei Datensätze) und mit Wachstum über 650 Millionen in fünf Jahren. Dieselbe Funktion, ein paar Nullen mehr, eine ganz andere Architektur. Lesen Sie noch einmal Kennen Sie Ihre Zahlen.

5. Ein nächtlicher Ladelauf meldet „abgeschlossen“ für eine Million Datensätze. Woher wissen Sie, dass er funktioniert hat?

Sie gleichen ab. Die empfangende Seite bestätigt jeden Datensatz, den sie gespeichert hat; der Sender vergleicht, was er gesendet hat, mit dem, was bestätigt wurde. Fehlende Bestätigungen bedeuten, dass es nicht funktioniert hat, ganz gleich, was der Jobstatus sagt, und zeigen Ihnen, welche Datensätze Sie erneut versuchen, an eine Person weiterleiten oder melden müssen. Lesen Sie noch einmal Teilerfolg ist immer noch ein Scheitern, das Sie verstehen müssen.

6. Eine Community mit 15 Millionen Customer-Community-Benutzern braucht komplexen Datensatzzugriff. Jemand schlägt Apex-Freigabe vor. Wo liegt das Problem?

Es sind Benutzer mit hohem Volumen: keine Rollen, außerhalb des Freigabemodells, also gibt es keinen Freigabedatensatz, den Apex schreiben könnte. Der Zugriff kommt aus Freigabesätzen und Freigabegruppen. Die Lizenz hat entschieden, welche Freigabewerkzeuge es gibt. Lesen Sie noch einmal Ein durchgerechnetes Beispiel: Apex-Freigabe.

7. Ein KI-Werkzeug erzeugt in Minuten zwanzig Objekte für eine neue App. Was ist jetzt die Aufgabe der Architektur?

Entscheiden, ob wir fünf haben sollten. Das Modell gut genug verstehen, um es zu verteidigen: warum diese Objekte und Beziehungen, wo die Schlüssel und Stammdaten liegen, was im großen Maßstab passiert. Die Fakten prüfen, auf die es sich gestützt hat. Generieren ist nicht Urteilen. Lesen Sie noch einmal Billige Umsetzung verschiebt den Wert.

Weiterlesen

• Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), Salesforce-Hilfe (auf Englisch, geprüft am 2026-09-25): die offizielle Liste der Ziele und ihrer Gewichtung. Prüfen Sie immer die aktuelle Fassung, bevor Sie die Prüfung buchen.